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.
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
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.
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.
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.
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.
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).
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...
well you can just have much stronger safety guarantees in a theorem prover than in the rust type system, and C is a much easier thing to embed in a theorem prover than rust.
Rust isn't C. There are plenty of theorem provers that are proc macros. C doesn't have proc macros so that's why you wrap it instead, but there's no need to wrap Rust like that.
Corporate environment over here, the reason is easy, that is what many SDKs support out of the box without extra tooling, added complexity building the missing pieces ourselves or relying in whatever community project, and finally the human part of actually wanting to use something else.
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)
> 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/
Wow. This is genuinely the first time I have come across this idea. Are there Kernels build to be completely async? I understand they would be experimental. And the whole stack runs in a async environment from say the web server rendering templates - down to the kernel loading data into the cpu cache? Does it offer performance advantages? I got so many questions…
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.
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)
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
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.
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.
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!
66 comments
[ 2.1 ms ] story [ 37.6 ms ] thread(not my project)
Edit: there was so much drama now I remember
I did recognize it when it was brought up here but not before.
also, thanks to your comment, unaware folks will probably figure it out, which is the subtler point!
[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.
Now that we have a KVM 0day + VM escape vulnerability [0] right now.
[0] https://x.com/PaulosYibelo/status/2106378929158135903
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.
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)
https://mirage.io/
This is really a classic exokernel design.
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?
Each application gets its own fine grained security.
https://github.com/unikraft/unikraft
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
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.