* I do get the reference and releaize I'm changing the class of the referent. Anyway FTL (or the next one...) FTW, godspeed.
itsanaccount 15 hours ago [-]
I dont think the kids are gonna get the reference.
grimgrin 13 hours ago [-]
thanks to your comment we all understood that you got it though, which is the point!
also, thanks to your comment, unaware folks will probably figure it out, which is the subtler point!
QuantumNomad_ 13 hours ago [-]
I think they will. It’s a pretty famous quote, even among people who were not old enough to see it first-hand at the time when Linus made that Usenet post.
flemhans 3 hours ago [-]
I read about it some 20 years ago in an (auto?) biography about Linus, saunas, that thing where he had to reverse engineer posix specs. And minix was either evil or an academic purist
Edit: there was so much drama now I remember
3 hours ago [-]
ollybee 14 hours ago [-]
I saw FTL and "new" and got very excited. sadly is is not the game.
christophilus 12 hours ago [-]
Same guy made Into the Breach which is similar and really fun.
ivanjermakov 10 hours ago [-]
It's 2026 and we've mostly ran out of good product names...
encom 14 hours ago [-]
This immediately started playing in my head, before I fully parsed the headline.
Does this mean you still delegate to something like KVM/paravirtualzation for your device models, but your FTL guest OS can run multiple secure workloads inside a VM?
Or are you designing a custom OS from the ground up to run on native hardware? What constraints are you putting on hardware support to make this a tractable that's not re-implementing all of the stuff that linux has? I assume that's why it's advertised for the "cloud", because you know a priori the deployment machines you're gonna run on? Or is hardware support known by kernel devs to be a (relatively) trivial problem in the OS space, compared to the user-facing features (like processes, scheduling, memory management, etc)?
Or is the bet that microkernel = win = can implement everything linux has and more?
I'm curious about the eventual end goal for the project is, not just what currently exists (as otherwise the answer currently seems to be sentence 1)
veqq 2 hours ago [-]
> The user space is the easy part. A historical issue defining our computer landscape is that modern kernels try really hard to provide the illusion of a blocking API. You write a file, which takes time then you continue when it’s done. This is smoke and mirrors, this isn’t how hardware works at all! It’s always fire and forget: Write this, here’s a region of memory, wake me up when it’s over. It’s fundamentally asynchronous. The OS provides these thread and process abstractions which make you think the API’s blocking. The horrible side effect’s that language designers get an out of jail card for async programming, they don’t have to think about it! When writing to a file, they don’t need to make sure the bytes aren’t moved during the operation while running something. No, you just bind to the POSIX API and enjoy this blocking world illusion. - Matklad https://alexalejandre.com/interviews/interview-with-matklad/
browningstreet 10 hours ago [-]
There’s only one OS… BIOS!
chanux 3 hours ago [-]
Ah the Business Intelligence OS!
comboy 13 hours ago [-]
I just make agents generate assembly for my app and my hardware and boot directly into that.
rfgplk 13 hours ago [-]
Is this written in jest? Because it's very likely where the future of computing is heading. See https://www.youtube.com/watch?v=kZRE7HIO3vk; a lot of people were nagging on Casey because he implied that software was more efficient back when everyone "wrote their own kernel" and how "impossible it would be today". He even mentions how awesome it could be if every game came with it's own bootable USB. Now back then it truly was unthinkable, but today we're edging ever closer to that reality.
For instance, I have a working microkernel written in a Lisp dialect for embedded devices. Compiled to native machine code. 100% LLM generated. ~70k loc. In benchmarks it outperforms most other embedded kernel projects by a significant margin. And it only took around ~$1500 in tokens (API costs all included).
smokel 13 hours ago [-]
A problem with this approach is that it would put a large burden on the application developer (or development system) to support other devices (or services) than initially planned.
Of course, it would be possible to add new drivers only when necessary, but that would also allow for security problems.
So, in theory it might work, but in practice it would require quite a bit of thought.
johannes1234321 10 hours ago [-]
There are/were approaches around in kernels like includeos, which promised to do as little as possible before hading control to you. So not everybody has to create their own driver's etc, but you get a bootable executable for your application.
Includeos in particular then went towards being a complete "application server" and apparently failed to gain a business as Docker became successful.
Now that we are out of the Cambrian explosion of computing hardware - are drivers such a concern anymore? Is there any chance we start consolidating on a few core interfaces?
I know nothing of hardware, but as far as I know, my keyboard and mouse work everywhere because there is a formal specification on how human interface devices are supposed to operate.
There are probably good (and anti-competitive) reasons for why hardware still needs bespoke drivers, but from the outside, it seems like something we could address. I have no interest in loading your artisanally crafted Wifi driver.
mikepurvis 12 hours ago [-]
Game consoles worked a lot like this until around the PS3 era, where the disc/cartridge the game came on was shipping binaries for everything including all the hardware support.
This led to some hilarious implementation shenanigans for the Wii as a transitional console, where the Home button pause screen is not in fact a task switch to some underlying console OS but rather a piece of the SDK that is separately-delivered from each individual game.
As AI reduces the cost for writing closer to the metal, it's also reducing the cost for creating new metal to target. I suspect we'll see an explosion in new hardware as it's cheaper and easier to design custom solutions.
PunchyHamster 12 hours ago [-]
If you're writing for VM and don't need stuff like GPUs, you can.
For actual real hardware, not really
mikepurvis 12 hours ago [-]
GPUs, wifi, power/thermal management, firmware. Especially in portable computing there is still a huge amount of hardware support surface area to contend with.
mejutoco 13 hours ago [-]
You could use a library as a base.
killerstorm 12 hours ago [-]
When AI proves theorems, it uses divide-and-conquer approach just as humans - it breaks a big theorem into lemmas and tackles lemmas one by one.
An alternative approach where it is just one big-ass logical expression is just not better.
Same thing with code, I think - you need some intermediate results like a calling convention, helper subroutines, etc.
A sufficiently powerful AI can do compilation "mentally" - i.e. producing machine code conforming to a specific calling convention. It can also decompile machine code. But you, obviously, don't gain anything doing it this way, if there's one-to-one correspondence between high-level code and machine code. You might as well just write high-level code.
I really hope that software becomes more efficient. But I don't think that it can only be done by generating machine code directly.
teddyh 10 hours ago [-]
> He even mentions how awesome it could be if every game came with it's own bootable USB. Now back then it truly was unthinkable,
Can you share a link to this? This aligns with my interests. Me and the homies love lisp machines
aaronbrethorst 13 hours ago [-]
Here's the author: https://seiya.me -- he works at Vercel, sounds pretty legit.
Foobar8568 45 minutes ago [-]
FTL stands for "For The Lose" or "For The Loose"?
fastball 24 minutes ago [-]
Fitter Than Linux?
tekacs 15 hours ago [-]
Sounds kinda like gVisor more than Unikraft? With a maybe-faster intercept path?
eranation 15 hours ago [-]
That was my first thought. I think adoption will increase if projects will have a clear FAQ about prior / related work, and not leave this to the reader (human or AI) to figure out.
convolvatron 14 hours ago [-]
I think it's a kind of like both? it runs as its own guest, but instead of implementing syscalls that are 1:1 with linux, it looks like linux runs as a library, and uses a different more pared down set to take a normal sys call path to the guest. so my guess is not cheaper at all, since instead of the gvisor syscall->vmexit for the common path, its maybe process->sys call to guest->vmexit to hypervisor.
romac 16 hours ago [-]
FTL v0.1.0 was just released, adding async Rust support (multi-thread Tokio runtime) and lots of missing pieces in the Linux compatibility layer.
(not my project)
yjftsjthsd-h 15 hours ago [-]
So it's a microkernel...ish? And it runs Linux programs and supports enough features to serve its own website. Excellent; I hope it takes off.
monocasa 12 hours ago [-]
It's a classic exokernel. Which unfortunately feels like there's some secret cabal paying those writing operating systems textbook writers to explain poorly.
Basically the point is rather than keeping the absolute minimum in the kernel, you keep the minimum needed to multiplex the hardware with the fewest abstractions possible. So stick a network driver in there, sure. But does the TCP stack need to be in there? Stick a disk driver in there, but does the VFS need to be in there?
Then you add security so that the fast path doesn't need to go to a user space abstraction service. You have something like bpf so that processes only get the packets that correspond to the ports they've opened, directly from the kernel device driver. Your FS service gives out revocable capabilities to the disk blocks corresponding to files a process was able to successfully open, etc.
hn_submit 9 hours ago [-]
In my opinion this is a more logical way of running multiple operating systems on a host since hypervisors run the entire operating system virtually, including hardware specific code like device drivers.
It's much more logical to merely run the operating system core as a user space library enabling you to run its binaries without needing to emulate hardware. I do wonder whether you can run everything that the guest system offers, such as hardware graphics acceleration.
Another drawback is that it depends on operating system vendors making available their core OS components as a library. This is especially a problem for closed-source vendors like Microsoft who may not want to do this for strategic business reasons.
chubot 12 hours ago [-]
I would like something Unix-y and Linux-compatible that follows the principle of least authority.
Linux namespaces and cgroups and seccomp are a mess ... but actually they are probably more functional than what OS X or Windows provides.
I wonder if we can do better. But maybe not in this project?
trollbridge 13 hours ago [-]
This is actually interesting, since most containers don’t actually need an independent kernel at all. Of course, this moves a container a lot closer to effectively being a chroot jail (but that’s a good thing) + having some capabilities taken away.
trunnell 6 hours ago [-]
It'd be great to see a quick comparison to firecracker rather than to a non-hypervisor linux system. The homepage and blog post only compare with the latter.
whattheheckheck 2 hours ago [-]
Align your ascii diagrams. What else is misaligned and unreviewed?
dekdrop 14 hours ago [-]
written in rust, doesn't say written in rust on the site - i guess that phase is over
habitue 14 hours ago [-]
Now people just wonder why you didn't write it in rust
dexterdog 14 hours ago [-]
Especially when you can just ask for that in your prompt
boredatoms 13 hours ago [-]
I mean starting a new project in C or C++ does kinda need a defensible reason at this point, at least in any corporate environment
tkz1312 13 hours ago [-]
I fully expect formally verified C to become the standard for any reasonably critical software. It's astonishing how easy it is to crank out program equivalence proofs these days...
LoganDark 7 hours ago [-]
Is there a benefit to formally verified C over formally verified Rust? Maybe platform support?
rfgplk 13 hours ago [-]
The real defensible reason is that with current tools available you can write perfectly safe (safer than Rust even) C++ code, while avoiding the horrid Rust compile times and without needing to pepper your code with unsafe all over the place. LLM's can help you formally verify your code and extensively fuzz/test it to the point where you can actually be sure (ie prove) that the code is safe, without really relying on Rusts compiler. Lastly, C++ lends itself more naturally to hardcore optimizations than Rust. But ultimately it really, _really_ comes down to a) Rust's horrid compile times and b) Rust's horrid metaprogramming support (this even kills it for LLM generated output because it wastes tokens).
raggi 13 hours ago [-]
parts of the kernel design remind me of zircon (handle oriented objects, vmo's, and so on), but then various lines are cut in different places (kernel knows of threads but not processes, maybe handles slightly higher level networking)
catlifeonmars 9 hours ago [-]
Does FTL stand for anything? “Faster than light” is the only thing that comes to mind
mrtesthah 13 hours ago [-]
MirageOS also bills itself as an OS in a library — is this similar?
Kind of, but this still has a kernel/user seperation, unlike mirage.
This is really a classic exokernel design.
Banditoz 13 hours ago [-]
Why is the diagram on the home page all misaligned?
GalaxyNova 9 hours ago [-]
Seems like it's only an issue on mobile.
kittikitti 4 hours ago [-]
This is really good! I was always very happy with the implementation of HomeAssistant and their Buildroot OS, and wondered if this pattern could be applied to other projects. My cloud VM's are already containerized and have minimal interaction with the base OS so FTL is intuitive for me. I hope for the best in your endeavor with this!
tamimio 13 hours ago [-]
How’s this different from say openbalena?
IshKebab 15 hours ago [-]
Is this a unikernel? Your ASCII art diagram is broken.
monocasa 13 hours ago [-]
It's an exokernel. It's kind of like if you modified a hypervisor specifically for running unikernels instead of classic VMs.
boguscoder 14 hours ago [-]
Fwiw diagram renders OKay in Brave on iOS
convolvatron 14 hours ago [-]
having looked at the briefly, is really a kernel that's meant to take system calls. I think the unikernel terminology is kinda broken. it's explicitly pared down to talk to a hypervisor rather than supporting a lot of hardware drivers. is a unikernel something you link in like a library? then its not. is a unikernel something that's intended to support a single process? then sure.
A single BOOTX64.EFI that boots a Hyper-V VM straight into a chat prompt, streams replies from an OpenAI-compatible /v1/chat/completions endpoint (DeepSeek by default), and boots whatever the model is asked to: Omarchy, netboot.xyz, or any UEFI image at an http(s) URL. No OS, no history. Dressed up like omp, for the memes
rvz 15 hours ago [-]
Maybe it is time to look at other new operating systems that are more memory safe by default and don't have any legacy bloat.
Now that we have a KVM 0day + VM escape vulnerability [0] right now.
[1] https://x.com/seiyanuta [2] https://seiya.me/ [3] https://news.ycombinator.com/item?id=42631873 [4] https://news.ycombinator.com/item?id=28986229
* I do get the reference and releaize I'm changing the class of the referent. Anyway FTL (or the next one...) FTW, godspeed.
also, thanks to your comment, unaware folks will probably figure it out, which is the subtler point!
Edit: there was so much drama now I remember
https://www.youtube.com/watch?v=QBES0jOmbCs
Does this mean you still delegate to something like KVM/paravirtualzation for your device models, but your FTL guest OS can run multiple secure workloads inside a VM?
Or are you designing a custom OS from the ground up to run on native hardware? What constraints are you putting on hardware support to make this a tractable that's not re-implementing all of the stuff that linux has? I assume that's why it's advertised for the "cloud", because you know a priori the deployment machines you're gonna run on? Or is hardware support known by kernel devs to be a (relatively) trivial problem in the OS space, compared to the user-facing features (like processes, scheduling, memory management, etc)?
Or is the bet that microkernel = win = can implement everything linux has and more?
I'm curious about the eventual end goal for the project is, not just what currently exists (as otherwise the answer currently seems to be sentence 1)
For instance, I have a working microkernel written in a Lisp dialect for embedded devices. Compiled to native machine code. 100% LLM generated. ~70k loc. In benchmarks it outperforms most other embedded kernel projects by a significant margin. And it only took around ~$1500 in tokens (API costs all included).
Of course, it would be possible to add new drivers only when necessary, but that would also allow for security problems.
So, in theory it might work, but in practice it would require quite a bit of thought.
Includeos in particular then went towards being a complete "application server" and apparently failed to gain a business as Docker became successful.
https://includeos.org/
I know nothing of hardware, but as far as I know, my keyboard and mouse work everywhere because there is a formal specification on how human interface devices are supposed to operate.
There are probably good (and anti-competitive) reasons for why hardware still needs bespoke drivers, but from the outside, it seems like something we could address. I have no interest in loading your artisanally crafted Wifi driver.
This led to some hilarious implementation shenanigans for the Wii as a transitional console, where the Home button pause screen is not in fact a task switch to some underlying console OS but rather a piece of the SDK that is separately-delivered from each individual game.
ref. https://www.copetti.org/writings/consoles/wii/
For actual real hardware, not really
An alternative approach where it is just one big-ass logical expression is just not better.
Same thing with code, I think - you need some intermediate results like a calling convention, helper subroutines, etc.
A sufficiently powerful AI can do compilation "mentally" - i.e. producing machine code conforming to a specific calling convention. It can also decompile machine code. But you, obviously, don't gain anything doing it this way, if there's one-to-one correspondence between high-level code and machine code. You might as well just write high-level code.
I really hope that software becomes more efficient. But I don't think that it can only be done by generating machine code directly.
Not only was it thinkable, it was common: <https://en.wikipedia.org/w/index.php?title=List_of_self-boot...>
(not my project)
Basically the point is rather than keeping the absolute minimum in the kernel, you keep the minimum needed to multiplex the hardware with the fewest abstractions possible. So stick a network driver in there, sure. But does the TCP stack need to be in there? Stick a disk driver in there, but does the VFS need to be in there?
Then you add security so that the fast path doesn't need to go to a user space abstraction service. You have something like bpf so that processes only get the packets that correspond to the ports they've opened, directly from the kernel device driver. Your FS service gives out revocable capabilities to the disk blocks corresponding to files a process was able to successfully open, etc.
It's much more logical to merely run the operating system core as a user space library enabling you to run its binaries without needing to emulate hardware. I do wonder whether you can run everything that the guest system offers, such as hardware graphics acceleration.
Another drawback is that it depends on operating system vendors making available their core OS components as a library. This is especially a problem for closed-source vendors like Microsoft who may not want to do this for strategic business reasons.
Linux namespaces and cgroups and seccomp are a mess ... but actually they are probably more functional than what OS X or Windows provides.
I wonder if we can do better. But maybe not in this project?
https://mirage.io/
This is really a classic exokernel design.
A single BOOTX64.EFI that boots a Hyper-V VM straight into a chat prompt, streams replies from an OpenAI-compatible /v1/chat/completions endpoint (DeepSeek by default), and boots whatever the model is asked to: Omarchy, netboot.xyz, or any UEFI image at an http(s) URL. No OS, no history. Dressed up like omp, for the memes
Now that we have a KVM 0day + VM escape vulnerability [0] right now.
[0] https://x.com/PaulosYibelo/status/2106378929158135903