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).
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.
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.
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)
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.
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.
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)
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...
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).
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.
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.
also, thanks to your comment, unaware folks will probably figure it out, which is the subtler point!
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://www.youtube.com/watch?v=QBES0jOmbCs
(not my project)
https://mirage.io/
This is really a classic exokernel design.
Now that we have a KVM 0day + VM escape vulnerability [0] right now.
[0] https://x.com/PaulosYibelo/status/2106378929158135903