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.
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)
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)
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.
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.
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/
(not my project)
Now that we have a KVM 0day + VM escape vulnerability [0] right now.
[0] https://x.com/PaulosYibelo/status/2106378929158135903