Reddit discussion: https://www.reddit.com/r/linux/comments/1qw4r71/microsofts_n...

Project lead James Morris announcing it on social.kernel.org: https://social.kernel.org/notice/B2xBkzWsBX0NerohSC

* Many of them are part of families of crates maintained by the same people (e.g. rust-crypto, windows, rand or regex).

* Most of them are popular crates I'm familiar with.

* Several are only needed to support old compiler versions and can be removed once the MSRV is raised

So it's not as bad as it looks at first glance.

Linux excels over Windows in the area of security by a wide margin, I have no qualms about running an app on Linux versus Windows, any day of the week.

That's the theory, but I don't know how far LiteBox is along to supporting that workflow.

There is also sandboxing configuration via Intune for enterprises.

The "North" part seems to be what I think you'd traditionally think of as a library OS, and then the "South" part seems to be shims to use various userlands and TEEs as the host (rather than the bare hardware in your example).

I'm really confused by the complete lack of documentation and examples, though. I think the "runners" are the closest thing there is.

> It focuses on easy interop of various "North" shims and "South" platforms.

For replacing wine on Linux the "North" would be kernel32 API or similar, the "South" would be Linux sys all API.

However this is meant as a library, thus require linking the Windows program to it and eine is more than the system interface, it has all the GUI parts etc of win32 API

  grep 'name = ' ms-litebox-Cargo.lock | wc -l
     238

  grep 'name = ' ms-litebox-Cargo.lock | sort -u | wc -l
     221

There has to be a better way. I think Linux's flatpak is a reasonable approach here, although the execution might be rather poor. I want a basic set of trusted tool that I can do anything with, and run less trusted tools like GUI programs in sandboxes with limited filesystem access.

Still, the fact that it's open source is a good thing. People can now take that code and make something better (ripping out the AI for example) or just use bits and pieces for their own totally unrelated projects. I can't see that as anything but a win. I have no problem giving shitty companies credit where its due and they've done a good thing here.

Basically it lets your program run directly on a hypervisor VM, though this one will also run as a Linux/Windows/BSD process.

What is unclear is if it uses its own common ABI or if you use the one of the host os. I don't know why but from the project description I have a little bit of feeling that this is another vibe coded project.

This is how most unikernels work; the "OS" is linked directly into the application's address space and the "external interface" becomes either hardware access or hypercalls.

Wine is also arguably a form of "library OS," for example (although it goes deeper than the most strict definition by also re-implementing a lot of the userland libraries).

So for example with this project, you could take a Linux application's codebase, recompile it linked to LiteBox, and run it on SEV-SNP. Or take an OP-TEE TA, link it to LiteBox, and run it on Linux.

The notable thing here is that it tries to cut the interface in the middle down to an intermediate representation that's supposed to be sandbox-able - ie, instead of auditing and limiting hundreds of POSIX syscalls like you might with a traditional kernel capabilities system, you're supposed to be able to control access to just a few primitives that they're condensed down to in the middle.

OP wasn't suggesting it was, just that the lack of quality in one significant area of the company's output leads to a lack of confidence in other products that they release.

A dissatisfied Windows end user might reason this only makes the company look more pathetic

As if "100,000 engineers" is not enough to fix or replace Windows

Possibly these "100,000 engineers" do a wide variety of tasks, including producing high quality software, but to the outside observer producing better Windows software is not amongst them

Perhaps these "100,000 engineers" love working for Microsoft and they think Windows is good enough

As such, a dissatisfied Windows user such as the parent commenter might have no reason to care that these "100,000 engineers" exist, what they produce or the allleged quality of their work product

The perspective of (a) someone promoting "AI" alongside Microsoft, (b) a satisfied Windows user, (c) a Windows developer, (d) etc., might be different. Depending on their situation, different people may have different opinions

Moreover, the issue being addressed by this "library OS"^1 and by the parent commenter is _trust_, which of course is broader than product quality ("good vs bad")

Microsoft, its leadership, has violated the trust of so many people for so long, going back to its earliest days as a company, it is entirely reasonable to distrust Microsoft no matter how many people collect a paycheck from the company, what any of those people do or whether what they do is "good" or "bad"

1. The Reddit commenter seems to suggest publishing this source code may be a preemptive measure aimed at Azure "Confidential Computing" customers who have been alarmed by recent events

https://www.forbes.com/sites/thomasbrewster/2026/01/22/micro...

If Microsoft states that they don't have any for a project like this, I would be wary of taking it too seriously.

That's also what I thought this was, and came to the comments expecting to see something neat about why libraries might need bespoke operating systems.

This. A while ago a build of Win 11 was shared/leaked that was tailored for the Chinese government called "Windows G" and it had all the ads, games, telemetry, anti-malware and other bullshit removed and it flew on 4GB RAM. So Microsoft CAN DO IT, if they actually want to, they just don't want to for users.

You can get something similar yourself at home running all the debloat tools out there but since they're not officially supported, either you'll break future windows updates, or the future windows updates will break your setup, so it's not worth it.

In their intended applications, which might or might not be the ones you need.

The slowness of the filesystem that necessitated a whole custom caching layer in Git for Windows, or the slowness of process creation that necessitated adding “picoprocesses” to the kernel so that WSL1 would perform acceptably and still wasn’t enough for it to survive, those are entirely due to the kernel’s archtecture.

It’s not necessarily a huge deal that NT makes a bad substrate for Unix, even if POSIX support has been in the product requirements since before Win32 was conceived. I agree with the MSR paper[1] on fork(), for instance. But for a Unix-head, the “good” in your statement comes with important caveats. The filesystem is in particular so slow that Windows users will unironically claim that Ripgrep is slow and build their own NTFS parsers to sell as the fix[2].

[1] https://lwn.net/Articles/785430/

[2] https://nitter.net/CharlieMQV/status/1972647630653227054

If you have to recompile, you might as well choose to recompile to WASM+WASI. The sandboxing story here is excellent due to its web origins. I thought the point of LiteBox is that recompilation isn’t needed.

       -c, --count
              prefix lines by the number of occurrences

"Microsoft bad, Linux good" kind of comments are all over the place. There is no more in depth discussions about projects anymore. Add the people linking their blogs only to sell you thier services for an imaginary problem, and you get HN 2026.

It's maybe the time to find another tech media. If you know one, I would be glad to know.

https://www.windowscentral.com/software-apps/windows-11/leak...

It does sound hard, and might need to employ homomorphic encryption with hw help for any memory access after code has been also verifiably unaltered through (uncompromised) hw attestation.

But there's another issue which is what cripples windows for dev! NTFS has a terrible design flaw which is the fact that small files, under 640 bytes, are stored in the MFT. The MFT ends up having serious lock contention so lots of small file changes are slow. This screws up anything Unixy and git horribly.

WSL1 was built on top of that problem which was one of the many reasons it was slow as molasses.

Also why ReFS and "dev drive" exist...

So they are not incentivized to keep Win32_Lean_N_Mean, but instead to put up artificial limits on how old of hardware can run W11.

I have no insider knowledge here, just this is a thing which get talked about around major Windows releases historically.

> If you have to recompile, you might as well choose to recompile to WASM+WASI.

I disagree here; this ignores the entire swath of functionality that an OS or runtime provides? Like, as just as an example, I can't "just recompile" my OP-TEE TA into WASM when it uses the KDF function from the OP-TEE runtime?

This was most evident back in the 90s when they shipped NT4: extremely stable as opposed to Win95 which introduced the infamous BSOD. But it supported everything, and NT4 had HW support on par with Linux (i.e. almost nothing from the cheap vendors).

I'm running 11 IoT Ent LTSC on a some T420; it runs pretty okay.

Citation needed since that makes no logical sense. You want to sell your SW product to the most common denominator to increase your sales, not to a market of HW that people don't yet have. Sounds like FUD.

>but instead to put up artificial limits on how old of hardware can run W11

They're not artificial. POPCNT / SSE4.2 became a hard requirement starting with Windows 11 24H2 (2024) (but that's for older CPUs), and only intel 8th gen and up have well functioning support for Virtualization-Based Security (VBS), HVCI (Hypervisor-protected Code Integrity), and MBEC (Mode-Based Execution Control). That's besides the TPM 2.0 which isn't actually a hard requirement or feature used by everyone, the other ones are way more important.

So at which point do we consider HW-based security a necessity instead of an artificial limit? With the ever increase in vulnerabilities and attack vectors, you gotta rip the bandaid at some point.

Also, as far as my (very limited) understanding goes, there are more architectural performance problems than just filters (and, to me, filters don’t necessarily sound like performance bankruptcy, provided the filter in question isn’t mandatory, un-removable Microsoft Defender). I seem to remember that path parsing is accomplished in NT by each handler chopping off the initial portion that it understands and passing the remaining suffix to the next one as an uninterpreted string (cf. COM monikers), unlike Unix where the slash-separated list is baked into the architecture, and the former design makes it much harder to have (what Unix calls) a “dentry cache” that would allow the kernel to look up meanings of popular names without going through the filesystem(s).

If even MS internal teams rather want to avoid it, it seems like it isn't a great offering. https://news.ycombinator.com/item?id=41085376#41086062

Not true. There are increasingly more cases where Windows software, written with Windows in mind and only tested on Windows, performs better atop Wine.

Sure, there are interface incompatibilities that naturally create performance penalties, but a lot of stuff maps 1:1, and Windows was historically designed to support multiple user-space ABIs; Win32 calls are broken down into native kernel calls by kernel32, advapi32, etc., for example, similar to how libc works on Unix-like operating systems.

I have to use Windows at my day job

and my god, I'd prefer Windows 3.1

    | Yes |    | Remind me later |

I read your comment as ignorant to AI's capabilities and their negative outcomes with relying on vibe coding.

The implication is that MS is forcing AI adoption on users at a point of absurd recklessness, and that they should not be trusted - especially not blindly trusted.

Perhaps the reason you're seeing comments similar to my original comment more frequently is because actual software engineers whom know the capabilities of AI and how much of a bad decision it is to assume it's as good as a competent engineer. Many engineers have had years of experience working with management, whom while have legit concerns about the capabilities of software as they are ultimately responsible for it and the financials, see them turning to vibe coding and relying on it. Non technical folks think software is kinda easy to do, and because LLMs can generate code that it just proves their assumptions.

  grep 'name = ' ms-litebox-Cargo.lock | sort | uniq -c | grep -v '1 name' | sort -n

Edit: Also, beware of the unsorted uniq count:

  cat <<EOF | uniq -c
  > a
  > a
  > b
  > a
  > a
  > EOF
   2 a
   1 b
   2 a

> Example use cases include:

> * Running unmodified Linux programs on Windows

> * ...

That won't work if the unplugged Linux program assumes that mv replaces a file atomically; ntfs can't offer that.