FTL: A new operating system for clouds

[delayed]

Is it just a hobby, and won't be big and professional like gnu?

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)

I just make agents generate assembly for my app and my hardware and boot directly into that.

I saw FTL and "new" and got very excited. sadly is is not the game.

Here's the author: https://seiya.me -- he works at Vercel, sounds pretty legit.

Sounds kinda like gVisor more than Unikraft? With a maybe-faster intercept path?

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)

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.

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?

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)

written in rust, doesn't say written in rust on the site - i guess that phase is over

Why is the diagram on the home page all misaligned?

MirageOS also bills itself as an OS in a library — is this similar?

https://mirage.io/

Wrong. That would be https://github.com/H4vC/oh-my-uefPi

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

Is this a unikernel? Your ASCII art diagram is broken.

How’s this different from say openbalena?

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