and was impressed about the implications of writing memory safe kernel, in my amateur perspective, it sounded like an OS written in Rust would be orders of magnitude safer than even the safest OS written in C today. ( Safe in terms of potential exploitability of the kernel and kernel drivers )
Does anyone with more knowledge than I care to chime in with their thoughts on an OS purely written in Rust vs C, as well as the ambition of this OS called Nuta/Kerla?
seL4 is seriously impressive! You kind of have to be careful when saying stuff like ‘proven safe’ (more info on the proof’s assumption here and in the FAQs, but it’s definitely impressive, and goes beyond just verifying that the implementation matches memory safety properties.
“I’m doing a (free) operating system (just a hobby, won’t be big and professional like gnu) for 386(486) AT clones.” – Linus Torvalds http://www.linux.org/people/linus_post.html
I wonder if there will end up being a Linux flavour of POSIX: a subset of the Linux ABI that is common across Linux, gVisor, WSL, the FreeBSD Linux ABI, and all of the other Linux compat implementations that seem to be springing up. Python uses an old RHEL to build Linux binary libraries so that they can target a glibc that is old enough that every GNU/Linux distro can be backwards compatible with it. Having a well-defined subset of Linux that builds could target and get guaranteed binary compat (rather than the best-effort that they get today) from many operating systems would be interesting.
CloudABI is dead, unfortunately. I’m interested to see if WASI stabilises into something useful because it is basically CloudABI + WebAssembly. You could quite easily separate these and provide a WASI syscall interface and a WebAssembly runtime as different components.
I’m not sure - emails to Ed started bouncing a few years ago and I’ve not heard from him since. The GitHub repo says that the project is dead and encourages people to look at WASI instead. When LLVM dropped the CloudABI targets a few months back, no one spoke up. It should probably be removed from FreeBSD at some point as well.
I think the big problem for CloudABI was that it was a bit ahead of its time. The real use case for it is in function-as-a-service workloads, where you want strong isolation between runners and you want the runtime to provide you with a network socket and any other resources you’ll require up-front. The hosting platform could then use whatever OS it wanted (Linux, FreeBSD, or something lightweight and custom). AWS Lambda and Azure Functions now allow you to run Linux binaries as functions but I don’t know how they sandbox them. CloudABI would be perfect for this. I suspect that the current Linux approach will be replaced with WAsm / WASI as a distribution format and each function being ahead-of-time compiled to whatever the hosting platform prefers.
Sure you don’t mean the worst Linux will always be Linux?
Depends on your criteria. Linux is the only one that has 100% Linux binary compatibility and application support tends to matter in the industry far more than security, performance, or any other concerns.
This project is absolutely fascinating and I’ve already shown it to several people. I cannot wait to learn from it.
I recently watched a talk by Bryan Cantrill called Rust, Wright’s Law, and the Future of Low-Latency Systems, here… https://www.youtube.com/watch?v=cuvp-e4ztC0
and was impressed about the implications of writing memory safe kernel, in my amateur perspective, it sounded like an OS written in Rust would be orders of magnitude safer than even the safest OS written in C today. ( Safe in terms of potential exploitability of the kernel and kernel drivers )
Does anyone with more knowledge than I care to chime in with their thoughts on an OS purely written in Rust vs C, as well as the ambition of this OS called Nuta/Kerla?
There’s also SeL4, which is proven-safe.
seL4 is seriously impressive! You kind of have to be careful when saying stuff like ‘proven safe’ (more info on the proof’s assumption here and in the FAQs, but it’s definitely impressive, and goes beyond just verifying that the implementation matches memory safety properties.
Well sure, there are things not covered in the proof, but stuff that is, to the best of what we know, it’s actually correct.
[Comment removed by moderator pushcx: Dismissive scorn is not OK.]
There are many ways for this to be a success that don’t involve replacing or competing directly with Linux. The author’s blog post about the project opens with “I’m writing a Linux clone in Rust just for fun. It does NOT aim to replace the Linux kernel”.
“I’m doing a (free) operating system (just a hobby, won’t be big and professional like gnu) for 386(486) AT clones.” – Linus Torvalds http://www.linux.org/people/linus_post.html
Lol, yes indeed! Who knows where it might end up.
My point is more that it can be exactly what it is now and still be successful and interesting.
Yes, and Linux became a thing because of licensing, not on technical merit.
Not really. It became a thing because of licensing in comparison with UNIX and BSD, but it beat Hurd on technical technical merit. Namely working.
I wonder if there will end up being a Linux flavour of POSIX: a subset of the Linux ABI that is common across Linux, gVisor, WSL, the FreeBSD Linux ABI, and all of the other Linux compat implementations that seem to be springing up. Python uses an old RHEL to build Linux binary libraries so that they can target a glibc that is old enough that every GNU/Linux distro can be backwards compatible with it. Having a well-defined subset of Linux that builds could target and get guaranteed binary compat (rather than the best-effort that they get today) from many operating systems would be interesting.
CloudABI?
CloudABI is dead, unfortunately. I’m interested to see if WASI stabilises into something useful because it is basically CloudABI + WebAssembly. You could quite easily separate these and provide a WASI syscall interface and a WebAssembly runtime as different components.
What happened to CloudABI?
I’m not sure - emails to Ed started bouncing a few years ago and I’ve not heard from him since. The GitHub repo says that the project is dead and encourages people to look at WASI instead. When LLVM dropped the CloudABI targets a few months back, no one spoke up. It should probably be removed from FreeBSD at some point as well.
I think the big problem for CloudABI was that it was a bit ahead of its time. The real use case for it is in function-as-a-service workloads, where you want strong isolation between runners and you want the runtime to provide you with a network socket and any other resources you’ll require up-front. The hosting platform could then use whatever OS it wanted (Linux, FreeBSD, or something lightweight and custom). AWS Lambda and Azure Functions now allow you to run Linux binaries as functions but I don’t know how they sandbox them. CloudABI would be perfect for this. I suspect that the current Linux approach will be replaced with WAsm / WASI as a distribution format and each function being ahead-of-time compiled to whatever the hosting platform prefers.
As I understand, this was the goal of LSB(Linux Standard Base).
LSB assumes a Linux kernel.
Sure you don’t mean the worst Linux will always be Linux?
Every alternative I have seen has cleaner, better organized code.
All Linux has is inertia.
Depends on your criteria. Linux is the only one that has 100% Linux binary compatibility and application support tends to matter in the industry far more than security, performance, or any other concerns.
Linux absolutely doesn’t have 100% Linux binary compatibility. Although it is true they do try.
“Linux is the worst operating system, except for all the others”.