Slashdot Mirror
Rust-Based Redox OS Devs Slam Linux, Unix, GPL
Freshly Exhumed writes: Redox OS, a project on GitHub aimed at creating an alternative OS able to run almost all Linux executables with only minimal modifications, is to feature a pure Rust ecosystem, which they hope will improve correctness and security over other OSes. In their own words, 'Redox isn't afraid of dropping the bad parts of POSIX, while preserving modest Linux API compatibility.' They also level harsh criticisms at other OSes, saying "...we will not replicate the mistakes made by others. This is probably the most important tenet of Redox. In the past, bad design choices were made by Linux, Unix, BSD, HURD, and so on. We all make mistakes, that's no secret, but there is no reason to repeat others' mistakes." Not stopping there, Redox documentation contains blunt critiques of Plan 9, the GPL, and other mainstays.
Jeez, doesn't anybody know how to make a link any more? Standards.
This. I still remember how Java was advertised as a "simple" language when it first came out. And it was, but as time passed they decided they'd better keep up with the features and language fashions that the competition were rolling out.
Unix is indeed a regression relative to the memory-safe operating systems from
ICL (now Fujitsu)
Burroughs (now Unisys)
Elbrus (Moscow Institute of Precision Mechanics)
Unix and C are attempts to dumb down and cheap down computer science. The result is the cyber war domain and pervasive insecurity of modern information systems.
Security-wise, Unix* (and also Windows, because it is done in C) is a big-time regression from the days of Paper Files. Proof: Chinese hacking of OPM and a boatload of other sensitive installations, including aerospace design and manufacturing companies.
* including Linux and 99% of other unixoid OSs
While I generally like the idea of new people coming up with new projects and hacking away, the linked documentation reads like flamebait and doesn't have much in the way of substance. Some of their contentions are rather strange. For example,
There are numerous other OS's, kernels, whatever that lack for contributors, and are in desperate need of more coders. Many times, this is for a good reason. Failures in management, a lack of money, inspiration, or innovation, or a limited set of applications have all caused projects to dwindle and eventually fail. ...
Take Linux for example:
Ok, let me stop you there. Linux is not a perfect project by any means, but you can hardly say that it is mismanaged, uninspired, or lacking in innovation or money. It had 4000 contributors over about a 1 year period, and 12,000 over a 10 year period. It runs on everything from embedded systems to big iron mainframes and balances the often conflicting needs pretty well, in my opinion. Of all the things you can say about Linux, it does not lack in number of contributors or vitality of the project.
Legacy until infinity: Old syscalls stay around forever, drivers for long-unbuyable hardware stay in the kernel as a mandatory part.
Uh, yes. Because, shocking I know, quite a bit of hardware out there still depends on that code. And anyway, as long as somebody is there to maintain it, who cares if it is old. Admittedly, there is some cruft in the kernel. It's an old project, so I think it is natural to expect that. But at the same time there are people working on it and trying to keep the codebase modern.
While they can be disabled, running them in kernel space is essentially unnecessary, and is, by far, the biggest source of system crashes, security issues, and unexpected bugs.
I'll need a citation for that one. I won't dispute that old code has occasionally caused bugs and crashes, but the statement is hyperbole. The majority of crashes on Linux distributions have nothing to do with the kernel at all. Of the ones that do, it usually has something to do with the binary blobs used to run graphical hardware, which is certainly not old code.
Huge codebase: To contribute, you must find a place to fit in to nearly 25 million lines of code, in just the kernel. This is due to Linux's monolithic architecture.
Hurray, this useless debate continues. I'll tell you what. Show me a working performant microkernel (no, XNU is not a microkernel) and I'll concede you have a point. Until then, it is just useless chatter. As to their point, just because the kernel architecture is monolithic doesn't mean the codebase isn't organized. One can in fact easily work on something like a filesystem without touching the network code, for example. Linux has had separate subsystems maintainers since at least 2003.
Restrictive license: Linux is licensed under GPL2. More on this in Why MIT?.
Non-sequitur to say the least. While commonly debated on Slashdot, really doesn't contribute anything useful to the discussion.
Lack of memory safety: Linux has had numerous issues with memory safety throughout time. C is a fine language, but for such a security critical system, C doesn't fit.
This is really the only interesting thing they have said, but not a lot of detail on what they mean other than that they think the whole kernel should be reimplemented in Rust. Well, let's see how that goes. Check back in what, 5 years?
Compared to BSD, Linux is completely frontal-lobe-missing, in every imaginable way. The code base is one big, ugly hack, and the design is bad
I'm not saying Python is just right... but its development was started because the, then current, mature programming languages (C and shellscript) didn't support the mix of features Guido van Rossum needed... and a language that had many features he did like (ABC), he 'had a number of gripes about' (mainly it was a PITA to extend) so he started making Python.
It was a typical case of 'developer not happy with current tools, starts making his own almost from scratch'. I see a lot of parallels with this Redux case, and yes I know Python had 27 years to come where it is today. It's already been very usable for most of that time... version 1.0 was released in 'just' 5 years. Same with Linux, by the way, that was made by Torvalds because he wanted a quick and dirty Unix like OS on his 386 and the Hurd didn't cut it. Neither did Minix, which was 16 bit. It took 4 years there to get to 1.0.
So... let's see in 5 years, shall we? Maybe Redux will be something interesting. But, as I said, they need to do a lot of work first, and then, maybe, there will be others willing to help out. Making a lot of noise first is probably not going to help them get more 'eyeballs'.
Eternal moral vigilance, such as that provided by the Vigil language, is the only way to keep it that way.
The Rust community criticizes C++ in exactly the same way.
They go on and on and on about how much better and safer than C++ that Rust is.
But the reality appears to be so much different.
They conveniently ignore that the safety of Rust depends fully on the Rust implementation working properly. Yet the Rust implementation is full of bugs!
Rust supporters will point out that GCC and Clang/LLVM have bugs, too, but they fail to realize that both of those systems are absolutely massive compared to Rust's implementation!
Rust's implementation is basically just a front end and a standard library for a single language. GCC and Clang/LLVM both include support for numerous programming languages, along with the more generic compiler backend systems.
Then there's the whole issue with the Rust implementation being the only Rust implementation. It's not like C++, which has numerous production-ready implementations from different projects/vendors available for use.
If the Rust implementation has a bug, you're fucked. If GCC's C++ compiler has a bug, you can at least try Clang, or the compilers from Intel, Microsoft, and others.
The Rust implementation also depends very heavily on C++ since it uses LLVM, and since its standard library calls out to C code.
Then there's the problem with Rust's semantics actually being far more awkward to use properly than C++'s are, and C++ isn't exactly an easy language to learn and use.
On top of that, Rust's standard library actually makes C++'s standard library look good, and C++'s standard library is often seen as very lacking.
And beyond even that, we find that the Rust supporters conveniently ignore how modern C++ techniques render moot so many of Rust's supposed advantages and safety.
C++ has proven itself many times over. UNIX, BSD and Linux have proven themselves many times over. Rust? It has given us nothing but extreme levels of hype, with very little to show.