FTL: A new operating system for clouds (ftl-os.org)
drybjed 6 hours ago
itsanaccount 6 hours ago
QuantumNomad_ 4 hours ago
grimgrin 4 hours ago
also, thanks to your comment, unaware folks will probably figure it out, which is the subtler point!
baron3dl 5 hours ago
rand846633 3 hours ago
mikepurvis 3 hours ago
trollbridge 4 hours ago
mlinksva 2 hours ago
[1] https://x.com/seiyanuta [2] https://seiya.me/ [3] https://news.ycombinator.com/item?id=42631873 [4] https://news.ycombinator.com/item?id=28986229
* I do get the reference and releaize I'm changing the class of the referent. Anyway FTL (or the next one...) FTW, godspeed.
sigbottle 5 hours ago
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)
browningstreet 44 minutes ago
comboy 4 hours ago
rfgplk 4 hours ago
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).
smokel 4 hours ago
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.
3eb7988a1663 4 hours ago
I know nothing of hardware, but as far as I know, my keyboard and mouse work everywhere because there is a formal specification on how human interface devices are supposed to operate.
There are probably good (and anti-competitive) reasons for why hardware still needs bespoke drivers, but from the outside, it seems like something we could address. I have no interest in loading your artisanally crafted Wifi driver.
unsnap_biceps 3 hours ago
PunchyHamster 3 hours ago
For actual real hardware, not really
mikepurvis 3 hours ago
mikepurvis 3 hours ago
This led to some hilarious implementation shenanigans for the Wii as a transitional console, where the Home button pause screen is not in fact a task switch to some underlying console OS but rather a piece of the SDK that is separately-delivered from each individual game.
mejutoco 4 hours ago
johannes1234321 an hour ago
Includeos in particular then went towards being a complete "application server" and apparently failed to gain a business as Docker became successful.
killerstorm 3 hours ago
An alternative approach where it is just one big-ass logical expression is just not better.
Same thing with code, I think - you need some intermediate results like a calling convention, helper subroutines, etc.
A sufficiently powerful AI can do compilation "mentally" - i.e. producing machine code conforming to a specific calling convention. It can also decompile machine code. But you, obviously, don't gain anything doing it this way, if there's one-to-one correspondence between high-level code and machine code. You might as well just write high-level code.
I really hope that software becomes more efficient. But I don't think that it can only be done by generating machine code directly.
teddyh an hour ago
Not only was it thinkable, it was common: <https://en.wikipedia.org/w/index.php?title=List_of_self-boot...>
ollybee 5 hours ago
encom 4 hours ago
christophilus 3 hours ago
ivanjermakov 36 minutes ago
aaronbrethorst 4 hours ago
tekacs 6 hours ago
eranation 6 hours ago
convolvatron 5 hours ago
romac 7 hours ago
(not my project)
yjftsjthsd-h 6 hours ago
monocasa 3 hours ago
Basically the point is rather than keeping the absolute minimum in the kernel, you keep the minimum needed to multiplex the hardware with the fewest abstractions possible. So stick a network driver in there, sure. But does the TCP stack need to be in there? Stick a disk driver in there, but does the VFS need to be in there?
Then you add security so that the fast path doesn't need to go to a user space abstraction service. You have something like bpf so that processes only get the packets that correspond to the ports they've opened, directly from the kernel device driver. Your FS service gives out revocable capabilities to the disk blocks corresponding to files a process was able to successfully open, etc.
chubot 3 hours ago
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?
trollbridge 4 hours ago
raggi 4 hours ago
dekdrop 5 hours ago
habitue 5 hours ago
dexterdog 5 hours ago
boredatoms 4 hours ago
rfgplk 4 hours ago
tkz1312 4 hours ago
Banditoz 4 hours ago
GalaxyNova 4 minutes ago
greenavocado 34 minutes ago
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
mrtesthah 4 hours ago
monocasa 4 hours ago
This is really a classic exokernel design.
IshKebab 6 hours ago
convolvatron 5 hours ago
boguscoder 5 hours ago
monocasa 4 hours ago
tamimio 4 hours ago
pmkary 5 hours ago
rvz 6 hours ago
Now that we have a KVM 0day + VM escape vulnerability [0] right now.