44 comments
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).
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.
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.
also, thanks to your comment, unaware folks will probably figure it out, which is the subtler point!
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?
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)
Read the full thread on Hacker News →
Related stories
- Hacker News · 3 points · 5 days ago
- Hacker News · 1 points · 5 days ago
- Hacker News · 421 points · 9 days ago
- Hacker News · 6 points · 1 day ago
- Hacker News · 1 points · 7 days ago
- Hacker News · 1 points · 9 days ago