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.
Show me the code first, then start shittalking everybody.
Who cares? It's a toy OS written in a toy language. It'll join the thousands of other pet project OSes that no more than a handful of people will ever use.
When you are just starting out or if the project is relatively small.
The more adoption you gain, the more the purity is corrupted.
Enjoy the view from your high horse while it lasts I guess.
My eyes reflect the stars and a smile lights up my face.
Jeez, doesn't anybody know how to make a link any more? Standards.
This basically means their special little pony of an OS will be kinda sorta compatible, they will take some "principled" stand and break whatever they choose, and will screech and whine about how the rest of the world is doing it wrong.
Go ahead, be a bunch of yowling zealots, write an OS nobody will care about ... and sit around being all smug about how awesome the thing you've written is while wondering why nobody is using it.
If you want to have a manifesto of childishness and stern disapproval, don't expect to get taken seriously.
I worked with a guy who wouldn't bend on his perceived form of "correctness" ... he usually failed to deliver what was required of him and was an ass to work with, because he couldn't get past being a smug prick to get the job done. Delivering nothing is worse than griping it isn't aesthetically and ideologically perfect.
So, whatever. Throw your tantrum.
Lost at C:>. Found at C.
Microsoft can barely get people to use WinRT and yet this group of nobodies expect to displace POSIX? Sure, brahs.
They are going to base it on systemd, aren't they? Since throwing away past mistakes is a central criteria?
In one of the Jurassic Parks. 'No, you're making a whole load of brand new mistakes'. Sorry to be so down on this, but operating systems are quite complex and the open source ones need a decent community as well.
On y va, qui mal y pense!
This type of microaggressive behavior SHOULD NOT be tolerated in the Rust community. We should all have safe spaces available to create our own OS, no matter what your views are on POSIX. Who is to say what is "correct" or not?
It's impressive that they are out to make both their own kernel and their own runtime. At first glance it looks like a monolithic kernel, someone should page Andy Tannenbaum to harass them, and if it's really monolithic that takes a point from the "not making other people's mistakes" column.
It takes a lot of computer science smarts to even understand what the mistakes in other operating systems were and how to avoid them. And as others have commented, it's easy to point at other's mistakes when your project is in its infancy, much harder when your project is grown up.
I'll really be impressed if they don't map graphics cards into user space. Nothing's ever stable once you do that. That's the biggest mistake in the whole industry. But I bet they don't take fixing that one on.
Bruce Perens.
I believe he was enabling you to pick your own linking standard :)
Build a Man a Fire, and He'll Be Warm for a Day. Set a Man on Fire, and He'll Be Warm for the Rest of His Life.
Old Kung Fu proverb.
We suffer more in our imagination than in reality. - Seneca
The GPL may not be appropriate for many projects, and Redux' choice not to use it is understandable (they chose MIT), but for Linux, being a very large, multi-corporation affair, the GPL is not only appropriate, it's made Linux what it is today. The so-called viral nature of the GPL is what protects it from corporate interest, keeps it open, and keeps the playing field level for the various contributors and interested companies while being steadily improved by all interested parties.
It's true that the modified GPLv2 that the Linux kernel uses has loopholes in it, and has been taken advantage of by some (Tivo!), but overall it's been a good choice.
Had Linux been BSD, or MIT, I just don't think it would be as big or successful as it has been, and so widely contributed to by many competing companies. The BSD and MIT licenses lend themselves to widespread adoption and use without fear of any copyright repercussion. However nothing in them prevents companies from taking the code they want for their own proprietary purposes, never to release it back to the community for mutual benefit.
I am not saying Redux should not be MIT -licensed. I'm just saying their criticism of Linux using the GPL is debatable.
Hum... Writing an entire operating system in an immature language made by people who apparently only understand javascript and the "web way" of developing things... What can go wrong?
Religion: The greatest weapon of mass destruction of all time
systemd is all about reinventing past mistakes and bringing them into the present in an entirely new way.
Unics, Unix, UNIX, unix, posix, bsd, linux, minix, plan9, etc. They all come from the same basic design philosophy, and it is a very good starting point, simple, clean, wonderful.
Then you want applications to run on it. Then you get performance issues. Then you get security issues. Then you get new types of peripherals. Then you get new types of processors and memory architectures. Then it shrinks to be a raspberry PI, then it grows to be massively parallel and fill a room.
After all that, tell me again about what mistakes you are not going to make.
Heartbleed is a really bad example of what's wrong with C as a development language. If the developers had used C's safety features, Heartbleed, while still a bug, would not have been a problem. Substitute "calloc" calls for "malloc" calls and there's no problem.
Heartbleed is an excellent example of what can go wrong when the developers abandon all thought of safety measures, preferring to make everything run as fast as possible at the expense of safety in security-related software. While there are things wrong with C, Heartbleed wasn't one of them.
"When you have eliminated the unacceptable, whatever is left, however improbable, must be the truthiness" - Holmes
we will not replicate the mistakes made by others
Nope, you'll just brand new mistakes of your own!
systemd is Roko's Basilisk.
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
Theo de Raadt, is that you?
You know, there comes a time when you develop software for a living that "do your fucking job" becomes a real thing.
If you have the luxury of pursuing ideological purity in software, congratulations, either your mom is really understanding, or you have a tenured position and nobody is relying on you for anything real. But in the real world, that level of bullshit onanism and self congratulatory crap is something nobody has time for.
That guy who refuses to write the stuff he's being paid to write because it lacks sufficient ideological purity, and instead endless refactors stuff which already works? That guy is asking to get canned because he thinks his job is an outlet for his political agenda. That guy sitting in his basement doing the same thing? Well, he's entitled to do whatever the hell he wants, no matter how detached from reality he is.
Oh, now that's some fucking rewriting of history. Someone didn't take some pure fucking temple of computer science and "dumb down/cheap down" by using UNIX and C ... someone solved actual real damned problems decades before whiny punks like you come along and whine about your elegance and theoretical perfection.
Go ahead, pursue ideological perfection as a goal. But do it on your own time, and don't expect the rest of the world to do anything but roll their eyes at you -- because you're so far detached from actual reality as to be laughable and irrelevant.
Sitting around saying how the rest of the world has done it wrong and your toy nobody will ever use will be so much more better and perfect? Well, put up or shut up, but don't expect applause or interest based on your own level of smug -- that's your damned problem.
Because the smugness does nothing at all to make anybody think you're anything but a whiny little prat who hasn't actually been exposed to reality.
But in my direct experience, the people who go on the loudest about the theoretical and ideological purity of software are the ones who have delivered the least working software in the room -- right up to several people who couldn't deliver the stuff they were being paid to because they were so focused on trivia they failed to do their jobs.
And those people usually delivered badly written, brittle code which was so 'elegant' as to be a useless pile of shit.
Lost at C:>. Found at C.
The "freedom" of the MIT license is the freedom to deny others access to source code. ReDox claims that they aren't worried about someone adding proprietary code because it would, by definition, have to be an improvement in order to be successful. Yes, except Windows is successful without being an improvement on Linux. How did that happen? It happens because people become dependent on a particular feature, a particular standard Over time that may become inferior but because it's now proprietary, it can't be improved without violating copyright.
So why not use GPL? ReDox never really answers that obvious question. If the ReDox folks have a great idea, just implement it in the GPL and then everyone can enjoy that great idea. But what they really want is for many people to donate their code so they can then make a profit off it. And that's why the GPL wins over time.
Also, note that the attack on the GPL specifically focuses on libraries. But in general Linux libraries are covered under the LGPL and not the GPL. So ReDox is setting up a straw man argument. If libraries are a problem, then compare your license to the LGPL.
"He took a duck in the face at 250 knots." -- William Gibson, Pattern Recognition