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.

Comments

Code first, talk after

[Anonymous Coward]

Show me the code first, then start shittalking everybody.

Re:Code first, talk after

[gweihir]

Show me the code first, then start shittalking everybody.

That is not the Rust Way. The Rust Way means that you feel vastly superior to everybody else and let them know, no actual facts required. This must be the most arrogant and at the same time one of the most clueless tech-communities ever.

So what?

[Desler]

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.

Re:So what?

[Desler]

These people fail to realize that 99% of users care about applications not the OS nor the purity level of its code or APIs. A handful of Rust hipsters will jump ship and the rest of the world will go "What's RedoxOS and why should I care?"

Re:So what?

[Anonymous Coward]

Over and over again, people say "I'm going to create a new [programming language, OS, whatever] and this time it's going to be done right". And then they create something that is just as buggy and unusable as everything else. It's just buggy and unusable in different ways. Starting over from scratch is rarely a good idea.

Re:So what?

[mwvdlee]

I think 99% is an underestimation.
Unless they can make it trivially easy to migrate, they're dead in the water.
And even then, they need to offer significant and measurable advantages to justify end-user migration.
Wake me up when it runs Apache, MySQL and PHP or some other complete web stack.

Re:So what?

[allquixotic]

Of course, but that's only 10% of the job. The real hard parts include things like:

1. "Scripting the scripts": learning how and when to use each script and in what context. Often it is difficult to express exactly what conditions may prompt a given script to be run, especially if those conditions involve human factors (soandso forgets their password; the company gets sued and needs to put a legal hold on email deletion; etc.) If people could write scripts to automate the triggering of lower level scripts under the right conditions, they'd already have done that (for example, scripts that merely need to be run periodically get set up as a cron job) because we all know that most sysadmins are lazy and will seek to automate things to make life easier for them -- unless those things turn out to be difficult-to-impossible to automate.

2. Change: except for a few niche areas like Certificate Authorities, IRC servers, mail servers, and OS package repositories, the software configuration of many environments necessarily needs to change over time. Not only to keep ahead of obsolescence curves (end of security updates / support from vendors, etc.) but to actually provide new functionality and features requested by the customers (external or internal). There are very few server services that can just remain static for decades. The more change and upheaval you have in your environment, the less valuable it is to "button everything up" into a nice, well-oiled, automated machine. And the process of that automation requires significant manpower and extremely good documentation of exactly what everything does. Even in the best case, though, you'll probably end up re-doing large parts of it every six to seven years, since that's the support period (security updates lifecycle) for RHEL, Ubuntu LTS, etc.

3. Cost-benefit: Higher-level server automation can't write itself, because you have to tell the computer when to do what, under what conditions. Writing management engines that intelligently keep track of this stuff requires significant development time, and if the conditions are complex, you'd better write it in a robust language like C/C++/Java/C#/Rust/.... instead of Bash (shell scripts are not especially good at error handling and are not especially well optimized for large bodies of code). So after you have invested all that time in whiz-banging the whole thing into a web app with a few buttons, is it really worth the savings vs. waiting for a sysadmin to type a few commands manually into the console?

4. Frequency: Many (most?) system administration tasks are not done with terrible frequency. If something's only done once or twice a year, it's almost guaranteed not to be worth automating, even if the process takes a full day or two for the admin. So we typically only focus on automating tasks that need to be done multiple times per week. The more frequent, the more automated it probably is.

5. External environment: This mostly falls under "Change" above, but major vulnerabilities like the SHA1 weakness, Heartbleed, etc. occur once in a while and they can require an arbitrary amount of major change and upheaval on the server side, sometimes with very high priority (timetable doesn't allow for figuring out how to automate it). These things can happen at any time and they require someone to always be standing-by, at the ready, possessing the general knowledge of the system architecture as well as detailed knowledge of the commands to make changes on the system, so that they can implement the solution to the problem (which can't possibly be known in advance because the problem comes from an external source, so you can't automate it in advance).

Until/unless we get True AI (which I don't believe will ever happen), the world will need sysadmins. While the general trend towards higher level automation continues, it's not such a severe problem that admins will just get laid off if they don't know how to code. I don't buy that for a second, even though I strongly believe that it's beneficial for admins

Purity is easy

[The-Ixian]

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.

Meh

[Anonymous Coward]

It's easy to make something clean early on. Stuff gets ugly when it meats the real world.

I mean best of luck to them I guess, but I doubt this is the next great Linux killer.

In other words ...

[gstoddart]

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 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.

Re:They are right, but will they get it right?

[Desler]

Microsoft can barely get people to use WinRT and yet this group of nobodies expect to displace POSIX? Sure, brahs.

As Jeff Goldblum said...

[hughbar]

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.

Both funny and impressive

[Bruce Perens]

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.

Talking easy. Doing hard.

[Qbertino]

Old Kung Fu proverb.

GPL was a good choice for Linux

[caseih]

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.

Re:GPL was a good choice for Linux

[Bruce Perens]

Say share-and-share-alike. "viral" is pejorative and it's not in our interest to continue its usage.

What could possibly go wrong?

[TheDarkMaster]

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?

Re:They are right, but will they get it right?

[Anonymous Coward]

systemd is all about reinventing past mistakes and bringing them into the present in an entirely new way.

Oh please.....

[mlwmohawk]

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

[david_thornley]

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.

Mistakes

[wonkey_monkey]

we will not replicate the mistakes made by others

Nope, you'll just brand new mistakes of your own!

Why not use the GPL?

[duckintheface]

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.

Re:Why not use the GPL?

[duckintheface]

Copyright reassignment is necessary to enforce the provisions of the GPL. If the holder of the copyright is not aware that his code has been stolen, or if he has died or can't afford to pay a lawyer, then the GPL is worthless because it can't be enforced. If the copyright is reassigned to the FSF, for example, they will pay the lawyer to sue on behalf of the GPL. The GPL is silent of reassignment. If a project leader is requiring it, the contributor is free to take all the existing project code and fork the whole thing. That's how the GPL prevents any one person from having leverage over the code.