FTL: A new operating system for clouds

romac

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)

drybjed

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

IshKebab

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

tekacs

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

rvz

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

yjftsjthsd-h

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.

pmkary

What a nice thing!

dekdrop

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

ollybee

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

sigbottle

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)

trollbridge

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.

aaronbrethorst

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

raggi

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)

mrtesthah

MirageOS also bills itself as an OS in a library — is this similar? https://mirage.io/

tamimio

How’s this different from say openbalena?

comboy

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

Banditoz

Why is the diagram on the home page all misaligned?

chubot

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?

greenavocado

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

catlifeonmars

Does FTL stand for anything? “Faster than light” is the only thing that comes to mind