LiteBox is a sandboxing library OS that drastically cuts down the interface to the host, thereby reducing attack surface. It focuses on easy interop of various "North" shims and "South" platforms. LiteBox is designed for usage in both kernel and non-kernel scenarios.
LiteBox exposes a Rust-y nix/rustix-inspired "North" interface when it is provided a Platform interface at its "South". These interfaces allow for a wide variety of use-cases, easily allowing for connection between any of the North--South pairs.
Example use cases include:
- Running unmodified Linux programs on Windows
- Sandboxing Linux applications on Linux
- Run programs on top of SEV SNP
- Running OP-TEE programs on Linux
- Running on LVBS
To be expected, given how many organisations now require employees to use AI if they want to meet their OKRs, especially all that sell AI tools.
outofpaper 2 hours ago [-]
What's dumb, on top of everything, is needing to store non special standard operating procedures in specific AI folders and files when wanting to work with AI tooling.
andai 2 hours ago [-]
[flagged]
UqWBcuFx6NV4r 1 hours ago [-]
The funniest thing about this take, and I mean “laugh at you” funny, is that it’s so singularly focused on hating AI that in the process of doing so it takes a CEO soundbite at face value.
I’m sick to death of seeing this image and the million others like it. If you were sleeping on the fact that Microsoft was releasing third-rate software well before GPT-1 existed then that’s on you. That, or you’re simply too young, in which case, go to bed.
llama052 1 hours ago [-]
Both can be true.
embedding-shape 1 hours ago [-]
> Extremely simple changes do not require explicit unit tests.
I haven't used Copilot much, because people keep saying how bad it is, but generally if you add escape hatches like this without hard requirements of when the LLM can take them, they won't follow that rule in a intuitive way most of the time.
CasualSuperman 4 hours ago [-]
With how buggy their flagship OS has become, why would I trust anything else they release to be better? Or even if it does work well now, why should I expect it to stay that way? Microsoft has burned through all possible goodwill at this point, at least for me.
simonw 2 hours ago [-]
Microsoft employ over 100,000 engineers. I'd advise against assuming that everything produced by any of them is bad because of bugs in Windows.
replooda 44 minutes ago [-]
The criticism was directed at the company's product, not the employees...
22 minutes ago [-]
trimethylpurine 16 minutes ago [-]
The response appears to be pointing out that with so many employees (engineers), it's unlikely that they all work on Windows.
1vuio0pswjnm7 16 minutes ago [-]
If true, what difference would this make to the end user stuck with Windows
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
This is also still small/unimportant enough not to be poisoned by their broken corporate culture.
rafram 4 hours ago [-]
This isn't supposed to replace Windows, and it isn't a GUI desktop operating system at all. I doubt anyone working on this has anything to do with the modern Windows desktop UX.
dspillett 2 hours ago [-]
> This isn't supposed to replace Windows,
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.
Reddit_MLP2 2 hours ago [-]
but if the host OS is already comprised, what is the point of sandbox inside of it?
necovek 59 minutes ago [-]
Maybe we need secure attestation for sandbox to be protected against compromised host :)
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.
necovek 47 minutes ago [-]
Windows is ultimately a lot more complex, and not open source. This also builds on the Linux ecosystem, so even if it comes from Microsoft, I imagine engineering culture is different from that on Windows and especially their online platforms (that's even worse than Windows if you ask me!).
hudo 4 hours ago [-]
UI of Windows is buggy and inconsistent. Kernel and low level stuff are actually very stable and good.
joe_mamba 4 hours ago [-]
>Kernel and low level stuff are actually very stable and good.
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.
Talked about back in the Vista days publicly (I cannot find the articles now) - Microsoft has commitments to their hardware partners to help keep the hardware market from collapsing.
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.
necovek 50 minutes ago [-]
If anything, Microsoft has a lot of problems because they support a wide variety of crappy hardware and allow just about anyone to write kernel level sw (drivers). Not sure if this changed, but they used to run in the ring0 even.
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).
joe_mamba 2 hours ago [-]
>Microsoft has commitments to their hardware partners to help keep the hardware market from collapsing.
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.
ssl-3 3 minutes ago [-]
Windows 11 is running on my ThinkPad T530. Its CPU is very nearly 14 years old.
What is missing here that was present when this same computer was running Windows 10?
TkTech 4 hours ago [-]
Is this not just Windows LTSB/LTSC? Which has been a thing forever.
joe_mamba 4 hours ago [-]
Maybe, could also be that for a 9 figure government contract they'll provide a custom LTSC branch just for you with only the features you want.
hilti 2 hours ago [-]
Never heard of Windows G .. that sounds exactly what I want for my older Thinkpads :-)
WarOnPrivacy 1 hours ago [-]
> Windows G .. sounds exactly what I want for my older Thinkpads
I'm running 11 IoT Ent LTSC on a some T420; it runs pretty okay.
mananaysiempre 2 hours ago [-]
> Kernel and low level stuff are actually very stable and good.
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].
This is not due to slowness of the file system. Native ntfs tools are much faster than Unix ones in some situations. The issue is that running Unix software on windows will naturally have a performance impact. You see the same thing in reverse using Wine on Linux. Windows uses a different design for IO so requires software to be written with that design in mind.
m132 41 minutes ago [-]
> Native ntfs tools are much faster than Unix ones in some situations. The issue is that running Unix software on windows will naturally have a performance impact. You see the same thing in reverse using Wine on Linux.
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.
MadnessASAP 1 hours ago [-]
It's pretty typical these days for software, particularly games of the DX9-11 eras to perform better on Wine/Proton then they do under native Windows on the same hardware.
noumenon1111 2 hours ago [-]
[flagged]
p_ing 2 hours ago [-]
The file system isn't slow. The slowness will be present in any file system due to the file system filters that all file system calls pass though.
mananaysiempre 38 minutes ago [-]
Right, by “file system” here I mean all of the layers between the application talking in terms of named files and whatever first starts talking in terms of block addresses.
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).
dgxyz 2 hours ago [-]
This is on the mark.
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...
exceptione 3 hours ago [-]
NTFS, not so great.
p_ing 2 hours ago [-]
NTFS is just fine. Stable, reliable, fast, plenty of features for a general purpose file system.
exceptione 35 minutes ago [-]
Even with Defender etc off, it is not fun. Lots of small file IO brings it on its knees. Some wants to blame the Windows I/O system, I don't know, but what I do know is that when people choose NTFS it is because they haven't an alternative. Nobody chooses it based on its quality attributes. I dare to say there is no NTFS system that is faster than an EXT4 system.
...But no way can you wrap it into something that looks posix-y from the inside
p_ing 2 hours ago [-]
Why would you want to?
repelsteeltje 2 hours ago [-]
From the article, first use case:
> 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.
dooglius 41 minutes ago [-]
MSR is a somewhat independent org; you should be making predictions based on other MSR projects
autoexec 3 hours ago [-]
Microsoft doesn't have a very good track record with security or privacy. Maybe it works, but yeah you'll probably get screwed over at some point.
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.
gdevenyi 4 hours ago [-]
What is a 'library OS'?
bri3d 3 hours ago [-]
It's a library that is linked to in place of an operating system - so whatever interface the OS provided (syscalls+ioctls, SMC methods, etc.) ends up linked / compiled into the application directly, and the "external interface" of the application becomes something different.
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.
kccqzy 3 hours ago [-]
> So for example with this project, you could take a Linux application's codebase, recompile it linked to LiteBox
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.
bri3d 3 hours ago [-]
Looking more closely, it looks like there are some "North" sides (platforms) with ABI shims (currently Linux and OP-TEE), but others (Windows, for example), would still require recompilation.
> 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?
kccqzy 44 minutes ago [-]
I had previous experience with WASM on TEE. Just use the foreign function interface. Remember WASM isn’t native code so you still need other native code to run WASM (such as wasmtime), and you can import other native functions into WASM through the runtime.
charles_f 3 hours ago [-]
I think that's an OS in the form of a library, like Wine for example. From what I get from the description it allows you to run programs on your real OS and make it see a cut down API to your actual system to reduce the attack surface.
at first I thought library OS might have meant an OS meant for use at a library.
Honestly far less interesting to know I was wrong.
rendaw 2 hours ago [-]
Is it not? You link the "library os" and you no longer need an os (when running in a supervisor) IIUC.
stackghost 17 minutes ago [-]
I think parent poster was referring to an actual library, i.e. where you would borrow books.
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.
yeah, same here, I was like "wow what an interesting side to their business, a whole operating system intended to serve public and academic libraries!"
bg24 46 minutes ago [-]
Would be nice to see an OCI runtime and if it can give high-performant I/O as opposed to other we have today (eg. Gvisor).
tombert 3 hours ago [-]
I’m not sure I understand what a library OS is; can someone here elaborate?
greatgib 3 hours ago [-]
My understanding of this is that it is a sandbox. Providing a common interface like if it was an OS for the program to run inside, but avoiding the program to use the OS directly.
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.
wrs 3 hours ago [-]
A library OS is an OS that is linked directly to your program instead of being a separate program accessed through a syscall to kernel mode. About the same as a “unikernel”, but a more recent term.
Basically it lets your program run directly on a hypervisor VM, though this one will also run as a Linux/Windows/BSD process.
throwoutway 3 hours ago [-]
No mention of starting with a design specification & then tied to formal verification the whole way?
It sounds interesting and a step forward (never heard of library Os itll now), but why won't this run into hundreds of the same security bugs that plague Windows if it's not spec'd and verified?
anon291 3 hours ago [-]
People seem to believe writing things in rust means it's correct.
kvuj 4 hours ago [-]
The cargo.lock file is 2200+ lines long. Did they spend a reasonable amount of time auditing these dependencies?
CodesInChaos 4 hours ago [-]
That's 238 dependencies (counting multiple versions of the same crate).
* 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.
shikon7 4 hours ago [-]
What would be a reasonable amount of time to audit the dependencies?
kvuj 4 hours ago [-]
I would let them decide based on their security policy.
If Microsoft states that they don't have any for a project like this, I would be wary of taking it too seriously.
Andrex 4 hours ago [-]
They ran it through Copilot which gave it the all-clear.
TheSilva 4 hours ago [-]
[flagged]
RoyTyrell 3 hours ago [-]
Nope, that's a very fair poke at MS. They've gone so far into AI adoption that it's become absurd.
- They have VPs posting on Linkedin about rewriting existing code using AI and adhering to arbitrary metrics of a x% rewrite and laying off y% of engineers that used to work on it.
- Renaming one of their major flagship product lines (MS Office) to (MS Copilot Apps 365).
- Forcing AI features on users despite not wanting it, and overriding OS configuration that should turn it off.
- Executives publicly shaming the general public for not wanting "all the AI all the time".
Package windows-sys has the highest number of versions included, 3: 0.59.0, 0.60.2, and 0.61.2.
Edit: Also, beware of the unsorted uniq count:
cat <<EOF | uniq -c
> a
> a
> b
> a
> a
> EOF
2 a
1 b
2 a
dundarious 4 hours ago [-]
grep -v '1 name' excludes 11, 21, etc., but I take your point.
jrm4 4 hours ago [-]
Given, you know, Microsoft, I'd demand proof even if they said they did.
loufe 4 hours ago [-]
The lack of integrated sandboxing in windows compared to android/iphone is still frankly unacceptable. I've become increasingly paranoid about running any application on Windows (not that your average linux distro is even remotely better) and yet Apple and Google seem to be far, far ahead in user permissions (especially with GrapheneOS, god bless that team) and isolation of processes.
Consumers and businesses deserve better. It's crazy to me that in 2026 Notepad++ being compromised means as much potential damage as it does, still.
digiown 4 hours ago [-]
The sandboxing on mobile platforms puts the OS vendor in a special position to enforce a monopoly on apps and features. Apple enforces it aggressively, while Google only reluctantly so far. It also prevents the user from exerting full control of the system. Apple does it by locking things down directly, while Google punishes you for owning your devices with attestation.
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.
wat10000 3 hours ago [-]
Those are policy decisions not really connected to the sandboxing technology. They control what sort of signing the system will accept and make it so that it only runs things they approve, and they only approve things that are sandboxed a certain way. The exact same sandboxing could be used with a system where an admin user can decide what gets to run and what kind of sandboxing is required for each thing.
> I've become increasingly paranoid about running any application on Windows (not that your average linux distro is even remotely better)
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.
pjmlp 3 hours ago [-]
UWP, and MSIX on Win32 via Appstore.
There is also sandboxing configuration via Intune for enterprises.
runjake 2 hours ago [-]
For others as lost as I am and want the tl;dr:
A library OS is an operating system design where traditional OS services are provided as application-linked libraries, rather than a single, shared kernel serving all the programs.
ukuina 4 hours ago [-]
No deployment instructions?
3 hours ago [-]
ho_schi 3 hours ago [-]
Another layer (ouch) to abstract away Windows (ouch * ouch).
Use Linux or BSD and ignore that approach for Vendor Lock-in* into their “library OS”.
sscarduzio 4 hours ago [-]
Can it replace Wine to run Windows apps on Linux?
marklar423 4 hours ago [-]
IIUC, if you have the source you can recompile said Windows app with LiteBox to statically link in the Windows OS kernel dependencies, so it'll run on any compatible processor regardless of OS (since it won't be making syscalls anymore). It's a unikernel basically.
That's the theory, but I don't know how far LiteBox is along to supporting that workflow.
johannes1234321 3 hours ago [-]
They say
> 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
anon291 4 hours ago [-]
A library os to me would typically mean it's aimed at hosting a single user program on bare hardware. I don't see that here, but maybe I'm just confused
bri3d 3 hours ago [-]
It's both; it's aimed at hosting a single user program on another userspace, but also seems to have its own kernel as well?
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.
richardlblair 4 hours ago [-]
The reddit conversation seems to allude to you being correct.
5o1ecist 2 hours ago [-]
Hmmm. Another, admittedly interesting, step towards the complete digital lockdown. Isolate and virtualize everything, now also governed by AI!
I wonder if they, the industry as a whole, eventually will make being able to freely use a PC a subscription, bastardizing "freedom" completely.
hypfer 3 hours ago [-]
"We did not find any viable commercial use for it, but maybe you will."
cmrdporcupine 51 minutes ago [-]
I know we're not supposed to complain about comment quality, but -- I came here to look for interesting technical analysis but instead it's Slashdot level snipes about Microsoft the company. And yes, I also dislike Windows and Microsoft generally but this looks like a very interesting project and I'm frankly frustrated at the level of discussion here, it's juvenile. This has nothing to do with Windows, and it looks like most people didn't even read past the title.
I'll play with this later today after work and see how mature it is and hopefully have something concrete and constructive to say. Hopefully others will, too.
Just assume the only thing a human did was name write the initial prompt.
portly 3 hours ago [-]
I read this type of (sour) comment more and more on this forum. To me it reads very cynical and I wonder what the author is trying to say with this. Are you perhaps negatively impacted by automatic coding?
blibble 3 hours ago [-]
we are ALL negatively impacted by generative excrement
I have to use Windows at my day job
and my god, I'd prefer Windows 3.1
PunchyHamster 2 hours ago [-]
Do you want to enable Copilot ?
| Yes | | Remind me later |
RoyTyrell 3 hours ago [-]
Nope, not at all.
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.
burnermore 3 hours ago [-]
Baaah! Microsoft, security-focused in a single sentence!
R_Spaghetti 3 hours ago [-]
I'm not sure whether Microsoft, the makers of Windows 95 (after which I stopped taking them seriously), are the sharpest tool in the box when it comes to security.
3 hours ago [-]
Rendered at 20:02:21 GMT+0000 (Coordinated Universal Time) with Vercel.
LiteBox is a sandboxing library OS that drastically cuts down the interface to the host, thereby reducing attack surface. It focuses on easy interop of various "North" shims and "South" platforms. LiteBox is designed for usage in both kernel and non-kernel scenarios.
LiteBox exposes a Rust-y nix/rustix-inspired "North" interface when it is provided a Platform interface at its "South". These interfaces allow for a wide variety of use-cases, easily allowing for connection between any of the North--South pairs.
Example use cases include:
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
https://github.com/microsoft/litebox/blob/main/.github/copil...
I haven't used Copilot much, because people keep saying how bad it is, but generally if you add escape hatches like this without hard requirements of when the LLM can take them, they won't follow that rule in a intuitive way most of the time.
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...
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.
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.
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.
https://www.windowscentral.com/software-apps/windows-11/leak...
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.
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).
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.
What is missing here that was present when this same computer was running Windows 10?
I'm running 11 IoT Ent LTSC on a some T420; it runs pretty okay.
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
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.
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).
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...
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
> 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.
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.
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.
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.
> 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?
Honestly far less interesting to know I was wrong.
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.
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.
Basically it lets your program run directly on a hypervisor VM, though this one will also run as a Linux/Windows/BSD process.
It sounds interesting and a step forward (never heard of library Os itll now), but why won't this run into hundreds of the same security bugs that plague Windows if it's not spec'd and verified?
* 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.
If Microsoft states that they don't have any for a project like this, I would be wary of taking it too seriously.
- They have VPs posting on Linkedin about rewriting existing code using AI and adhering to arbitrary metrics of a x% rewrite and laying off y% of engineers that used to work on it.
- Renaming one of their major flagship product lines (MS Office) to (MS Copilot Apps 365).
- Forcing AI features on users despite not wanting it, and overriding OS configuration that should turn it off.
- Executives publicly shaming the general public for not wanting "all the AI all the time".
Edit: Also, beware of the unsorted uniq count:
Consumers and businesses deserve better. It's crazy to me that in 2026 Notepad++ being compromised means as much potential damage as it does, still.
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.
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.
There is also sandboxing configuration via Intune for enterprises.
A library OS is an operating system design where traditional OS services are provided as application-linked libraries, rather than a single, shared kernel serving all the programs.
Use Linux or BSD and ignore that approach for Vendor Lock-in* into their “library OS”.
That's the theory, but I don't know how far LiteBox is along to supporting that workflow.
> 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
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.
I wonder if they, the industry as a whole, eventually will make being able to freely use a PC a subscription, bastardizing "freedom" completely.
I'll play with this later today after work and see how mature it is and hopefully have something concrete and constructive to say. Hopefully others will, too.
https://news.ycombinator.com/item?id=45077654 - "Generated comments and bots have never been allowed on HN"
I have to use Windows at my day job
and my god, I'd prefer Windows 3.1
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.