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.
What does "OS" for clouds mean?
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)
Is it just a hobby, and won't be big and professional like gnu?
quick, let's find the author's shirtless beer drinking pictures before they get deleted
I dont think the kids are gonna get the reference.
I saw FTL and "new" and got very excited. sadly is is not the game.
This immediately started playing in my head, before I fully parsed the headline.
https://www.youtube.com/watch?v=QBES0jOmbCs
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.
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)
Sounds kinda like gVisor more than Unikraft? With a maybe-faster intercept path?
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.
written in rust, doesn't say written in rust on the site - i guess that phase is over
Now people just wonder why you didn't write it in rust
Especially when you can just ask for that in your prompt
What a nice thing!
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.
[0] https://x.com/PaulosYibelo/status/2106378929158135903
Is this a unikernel? Your ASCII art diagram is broken.
Fwiw diagram renders OKay in Brave on iOS
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.