Comment by rakoo
5 years ago
> I know this kind of stuff spark the ``it's meaningless to rewrite everything (especially Linux) in Rust'' debate. I agree 100% that rewriting Linux in Rust (or your favorite language) is just a waste of time and such a project won't live long.
Considering that this is exactly how Linux was born (just a hobby project for fun), I wouldn't assume so fast that it's useless. Moreover, you don't need to justify yourself if you just want to have fun !
Any rust project like this inevitably gets sardonic replies about rewrite-in-rust fanaticism.
I agree they shouldn't have to justify themselves, but it is handy to preempt that.
Also, the rust community is too nice to openly admit it, but it's goal IS to displace C as the main low level language especially for the kernel. This is doomed to attract a lot of attention
I don't see why we need to pretend that every hobby has the potential for greatness. Being a hobby is a good enough end to itself.
In fact in this instance I think it's a little disingenuous to quote Linux and say it could happen again. The industry is totally different now. There's much more competition than there was when Linux was released and that competition is much more mature too. Plus the bar for a production-quality kernel is a lot higher than it was when Linux was released.
> In fact in this instance I think it's a little disingenuous to quote Linux and say it could happen again.
Seems apropos to me, given the fact that a Linux ABI compatible hobby project is under discussion - and that everyone here is familiar with the famous Usenet announcement.
> The industry is totally different now. There's much more competition than there was when...
I wonder how you define "competition"? Because there were way more operating systems in use then, and the industry was far more fractured. Fractured in a way that was meaningful - not like today where you can spin up a VM and be productive in short order, thanks to the significant lack of distinguishing difference. That is the really interesting thing about these hobby projects - they introduce possibilities that are either completely ignored by organizations suffering from inertia constraints, or can't be mimicked because they're diametrically opposed to present designs.
> I wonder how you define "competition"? Because there were way more operating systems in use then, and the industry was far more fractured.
There is way more competition now:
This isn't even an exhaustive list of UNIX-like platforms that are new since Linux and free.
Don't conflate standardisation of the industry with a lack of options. More options do exist today and are in use (eg some games consoles run FreeBSD, Netflix uses BSD, Nexenta is used in some enterprise storage solutions, Darwin may not be used in any free capacity but macOS is clearly used heavily by HN readers, and so on and so forth).
Moreover, I've used FreeBSD, Solaris, OpenSolaris, Nexenta and OpenBSD on production systems over the last 10 years (and the list gets more esoteric if we look past 10 years). So just because you might exist in a Linux-only ecosystem it doesn't mean that's the case for the entire IT industry.
6 replies →
> Being a hobby is a good enough end to itself.
Indeed, there's a word for it which I find particularly lovely, autotelic.
> There's much more competition than there was when Linux was released and that competition is much more mature too.
I think it's the opposite. When Linux was released, basically every major tech company had their own variant of Unix. Now almost everyone has migrated to Linux or Windows.
Competing with modern Linux by creating a drop-in replacement for Linux would be a pretty difficult task given that people have been optimizing Linux for decades now, but on the other hand I think there are ways to improve dramatically on the traditional POSIX-style API that Linux mostly adheres to. For a random example, why can't a given process have more than one "current working directory" at a time? That seems like an arbitrary limitation imposed by an implementation detail in early Unix system, and it causes problems for modularity. There are many other little details like that. I think if Linux is replaced by something eventually, it'll most likely be because the new thing has a cleaner, more powerful, or more generally usable API.
(Kerla is apparently not trying to invent a new API; I'm just saying that's the direction I would recommend to anyone project with a goal of seriously competing with Linux.)
Follow up to add: another way to compete with Linux is on security. The Linux kernel generally has a pretty good security record I think, but there have been plenty of serious bugs over the years. How many exploitable array-out-of-bounds errors or use-after-free errors remain in the Linux kernel? No one knows. If you can rule those out by using a safer language, that might be compelling to a lot of users who care about security above other concerns.
Of course that's hard to pull off in practice. Linux might have classes of errors that wouldn't exist if it were written in Rust, but even if using Rust eliminates three fourths of the code defects, the end result could be less secure if Linux gets ten or a hundred times as much scrutiny from people actively looking through the code for bugs to fix.
1 reply →
> I think it's the opposite. When Linux was released, basically every major tech company had their own variant of Unix. Now almost everyone has migrated to Linux or Windows.
There wasn't many UNIXes that targeted x86 aside from 386BSD. And even those that were available were often expensive. Even Minix wasn't free at that time. Which is exactly the reason Linus created his hobby OS.
Now we have a dozen different flavours of BSD, countless Linux distributions and several OpenSolaris spin offs too. Plus many other underdogs used in speciality domains. And that's before even looking at the commercial offerings like QNX, Solaris and macOS.
Just because there are a couple of industry heavyweights that take up the majority of common use cases, don't be fooled into thinking there is a lack of choice nor even that the industry is scared to use anything outside of Linux and Windows.
> Competing with modern Linux by creating a drop-in replacement for Linux would be a pretty difficult task given that people have been optimizing Linux for decades now, but on the other hand I think there are ways to improve dramatically on the traditional POSIX-style API that Linux mostly adheres to. For a random example, why can't a given process have more than one "current working directory" at a time? That seems like an arbitrary limitation imposed by an implementation detail in early Unix system, and it causes problems for modularity. There are many other little details like that. I think if Linux is replaced by something eventually, it'll most likely be because the new thing has a cleaner, more powerful, or more generally usable API.
That's not the goal of this nor any other project that aims for ABI compatibility with Linux and there are plenty of research kernels out there if that's your thing.
> (Kerla is apparently not trying to invent a new API; I'm just saying that's the direction I would recommend to anyone project with a goal of seriously competing with Linux.)
The only way to seriously compete with Linux would be to get large commercial backing. And even then, good luck. Linux won not because it is the best but instead because it's "good enough". Same is true with Windows. Any engineer with aspirations of creating a "better kernel" or "better OS" needs to remember that.
Thanks! I'll keep doing Just for Fun :D