Rust-Based Redox OS Devs Slam Linux, Unix, GPL 354
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.
I'm getting a feeling (Score:2, Funny)
It feels like this https://xkcd.com/927/
Re:I'm getting a feeling (Score:4, Interesting)
Jeez, doesn't anybody know how to make a link any more? Standards [xkcd.com].
Re:I'm getting a feeling (Score:5, Funny)
Why not use the GPL? (Score:5, Insightful)
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? (Score:4, Insightful)
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.
Code first, talk after (Score:5, Insightful)
Show me the code first, then start shittalking everybody.
Re: (Score:3, Informative)
Show me the code first, then start shittalking everybody.
https://github.com/redox-os/redox
Did you miss this part or something?
Re: (Score:3)
because of their rant, the criterion is not "do I have three lines of code in source control" but "do I have a working OS that I can compare to Linux or BSD"
Re: (Score:3)
Re: (Score:3)
Re: (Score:3)
Re: (Score:3)
There's an image viewer. There's a taskbar/launcher with icons. Pop up menus. Fonts. Pointer device: check.
Where is the source for those things?
Re:Code first, talk after (Score:5, Insightful)
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.
Re:Code first, talk after (Score:5, Funny)
Like the crossfit of programming?
Re: (Score:3)
I would kind of expect at least an RC version before the level of shit they are talking.
So what? (Score:5, Insightful)
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? (Score:5, Funny)
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.
You're right, operating systems are a solved problem. Things are fine right now.
Re:So what? (Score:5, Insightful)
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? (Score:4, Insightful)
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: (Score:3)
That your prefer an alternative is irrelevant. Their goal is to be able to run standard linux apps. So you can't hide behind "I like a different flavor," no it really needs to be able to run these things. Apache is a given. That is non-negotiable.
Re: (Score:3)
I don't believe the current designs are perfect, but I do believe the current designs benefit from thousands to millions of users constantly exposing weaknesses and problems.
It's probably not for me either. I'd be interested if they were making something that might improve my life as a system admin or even as a home user in the foreseeable future, but right now that's hard to see from where I stand.
Re: (Score:2)
It's happening already, with process overhead being discovered as the limiting factor applications are being designed to use a single process and threa
Re: (Score:3)
The sysadmin of the future is a few automated scripts managed by developers and a few call center guys clicking buttons in a browser that trigger scripts worked out by those developers.
That's extremely unlikely without significant AI. Sysadmin work is rarely rote and thus difficult to automate. There are some portions that can be enhanced using new tools and that will likely lead to productivity increases and reduced total need for sysadmins, but that's no where near what you're talking about. Scripting is not a new thing.
Re:So what? (Score:4, Insightful)
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
Re: (Score:2, Insightful)
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? (Score:4, Funny)
But this OS runs on 200% more smug than other OSes. Clearly that makes it superior.
Re:So what? (Score:4, Funny)
But this OS runs on 200% more smug than other OSes. Clearly that makes it superior.
Considering that at this point it's one big circle jerk, I think you misspelled smeg.
Re: (Score:3)
Well, most of the time you are right. And then there was Python.
Sometimes it works. But there never is an 'easy fix'. If you believe you're doing it better, it still needs a lot of work and convincing to be perceived as being better, let alone actually be better than what there was previously. A quick '0.1' and some documentation is not enough to convince the majority of users to join your band wagon. If you think all the work to get to '1.0' is preferable over fixing what's wrong in the established stuff t
Re: (Score:3)
Note that even if you think python is just right, it came about in 1994. It's the same generation roughly as the Linux kernel.
Re:So what? (Score:5, Interesting)
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'.
Purity is easy (Score:5, Insightful)
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.
Re: (Score:3, Interesting)
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.
Re:Purity is easy (Score:4, Funny)
The more adoption you gain, the more the purity is corrupted.
Enjoy the view from your high horse while it lasts I guess.
This deserves to transcend the limits of Slashdot and get (Score:6, Insightful).
Re:Purity is easy (Score:4, Interesting)
Meh (Score:2, Insightful)
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.
Re: (Score:2)
Indeed. Anyone can talk big about how, unlike every other project in the same arena, they're doing everything the right way from the ground up and it'll be the best thing ever. Inevitably, somewhere down the line they'll either wind up doing things 'wrong' for the sake of practicality like the others, or continue being 'right' and thus impractical so almost no-one uses it for real world stuff.
But hey, even if it itself doesn't take off, it might introduce some feature or other that Linux or BSD or Hurd or w
In other words ... (Score:4, Insightful)
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: (Score:3)
get the job done.
Plenty of IT work is done exactly to that spec, almost like Larry the Cable Guy was the project lead, "Geterdone!"
And you can see this in all the projects that looked fantastic in concept, but failed to execute on practicality or worse, Security.
Build me a website they said. Just get it running they said. We'll add security later they said. Just get the job done they said. We'll fix it later they said.
Re: (Score:3)
It's not just IT but all industry of any kind. A company - or anyone doing business - isn't going to spend more than they have to, and if they do, they'll be undercut by the competition. That's why regulation exists - to set the minimum bar no one is allowed to go below - and why IT is going to get its share as it keeps getting more and more important for the functioning of th
Re: (Score:3)
I've seen this before. If it has enough backers, it will eventually divide into two main "camps", one of which is caught up on the exclusive purity angle and the other thinks that it is already superior to what other people are using and should be shared with the world.
Just the other day I was trying (AGAIN) to remind myself of the difference between the Sunni and Shia sects of Islam. This about covers it.
Re: (Score:2)
Re: (Score:2)
sudo shut up
There, spoke your language.
Re:Yes Mr Ritchie ! (Score:4, Informative)
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.
Re: (Score:3)
As Jeff Goldblum said... (Score:4, Insightful)
Easy to know when people are smarter than you... (Score:2)
Easy to know when people are smarter than you...Because they tell you they are smarter than you.
Re: (Score:3)
That is one big pile of shit.
It seems to work for a lot of situations.
Microaggressive (Score:5, Funny)
Re: (Score:2)
VirtualBox?
Both funny and impressive (Score:5, Insightful)
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.
Re: (Score:3)
Re: (Score:2)
I'm not sure we can take Hurd as an indictment of all microkernels. There have been other successful ones.
Re: (Score:2)
Re: (Score:3)
It is true that microprocessor hardware interfaces have become complicated due to all of the hardware tricks that are done for power management, virtualization, and performance optimizations.
QNX Neutrino, however, seems to run on modern CPUs while remaining a microkernel. I haven't taken a close look at it.
Re: (Score:3)
I just spent a bunch of time in the technical details of the Hurd, and this is pretty funny.
They acknowledge if they had simply chosen an existing kernel (that they almost used) it would have turned out better than it did writing their own.
Also... OSX. It made it farther than Hurd. ;)
Hurd isn't intended to ever be "ready for production" so it is silly to measure the time in that way. It was worked on for a few years as a serious project, and it has been continued as a research project. It has known architec
Microkernel (Score:3)
Re: (Score:3)
Hi David,
I didn't take much time, but the first thing I found in there was a disk driver. A real microkernel would have that in user mode. So, maybe it's an incipient microkernel.
Re: (Score:3)
Unfortunately, your assumptions only apply when memory-mapped hardware is not involved. In other words, when the code in question isn't a device driver. Once it is, you have the potential to bus-fault when you mis-program the hardware and it fails to respond to your mapped reference, wild DMAs to any address can happen due to incorrect programming, etc.
Re: (Score:2)
Re: (Score:2)
Having filesystem drivers take near-arbitrary strings isn't a bad idea. Making them all URLs is too constraining, though, Because the first element of a URL is a transfer protocol rather than any designation of the data source/sink - that comes later which is sort of backwards. Consider, for example, how the ISO model is layered. They probably are thinking of overlaying other things on the transfer protocol. Not so clean, IMO. A real URL has the implication of running on an IP-like network before the first
Re: (Score:3)
You mean this [wikipedia.org]?
One of the big mistakes being made is that filesystem and communication services need not come from the local operating system. Process and memory management and just enough networking to open the filesystem/communication server connection needs to come from the local OS.
Re:Both funny and impressive (Score:4, Informative)
Well, I read the code. Which isn't a microkernel yet, as far as I can tell. To back that up, note their comment on wishing to move more of the kernel into user space.
Well they are problems? (Score:2)
Often our zeal towards such systems will often blind us to the problems. Then you combine nostalgia, with familiarity makes it very easy to ignore problems that are right in your face.
Many of these designs are almost a half century old, while some of them are still really good, others are just showing its age, linking processes to tape based processing of data. Which makes it hard to train because the style of working isn't the same as with modern computing anymore.
So blissfully naive... (Score:3)
But BSD isn't quite there yet: most importantly, it has a monolithic kernel, written in C. This means that a single buggy driver can crash, hang, or cause damage to the system.
They're in for a rude awakening when they realize that the wrong bits sent to a piece of hardware can in theory kill it no matter if the OS keeps running.... so you got a desktop with no working graphics, a server with no working NIC and so on. Without an IOMMU you can't even keep any DMA-enabled device from writing stuff all over system memory, unless of course you disable DMA and run all memory access over the CPU which will make performance glacial. Oh and Linux isn't quite monolithic, for example all USB devices have user mode drivers. Just the basic read/write functions are in the kernel.
Re: (Score:2)
Oh and Linux isn't quite monolithic, for example all USB devices have user mode drivers. Just the basic read/write functions are in the kernel.
Can the GPU drivers be moved to userspace as well? Windows has done this since Vista, and a GPU driver crash results only in a small notification telling that the driver restarted. Isn't Linux all about these kind of hi-tech features?
Re: (Score:2)
I wish more people would take a look at Minix3.
BSD license.
Microkernel.
Drives run in userspace and can heal.
It needs a lot of work still. Last time I checked it was only 32bit, single cpu/core, no USB support, and frankly lacking a lot of hardware support.
Re: (Score:2)
Re: (Score:2)
Re: (Score:2)
NT 3.51 also had user-mode graphics - since NT4 it went into the kernel.
Not making the same mistakes? (Score:2)
They already made the first big mistake - not writing the entire thing in ASM for utter speed.
Since they did that, I can safely assume they're clueless, and continue using master-race MenuetOS.
Talking easy. Doing hard. (Score:5, Insightful)
Old Kung Fu proverb.
good job they didn't go gpl (Score:2)
gpl is a killer. We can see from Linux that companies just won't touch gpl code, which is why no one every contributes from a company
Re: (Score:2)
I can't tell if you are trolling, trying to be funny, or if you are serious. I feel compelled to respond, though, as this sort of FUD has to stop because the last part of your statement, that no one ever contributes from a company is patently untrue with the GPL and Linux.
Yes companies that don't understand the GPL and just want to take code like they can from BSD or MIT fear the GPL. And from what I can see, companies that fear the GPL are the ones that would like to simply take the free code without any
Re: (Score:2)
I can't tell if you are trolling, trying to be funny, or if you are serious.
I'm being facetious. They list the GPL as a problem under the section about why most OSs don't get enough contributors. That's clearly vacuous as Linux gets far more contributors than the OSs with "less restrictive" licenses.
Even the supre-proprietary companies which seem to fear open source with burning irrationality have caved to the inevitable and accepted both GCC and Linux (and often Android) since they don't have a choice. An
GPL was a good choice for Linux (Score:5, Insightful)
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: (Score:2)
If you're just writing something for yourself, your choice of license is a matter of preference. If you want wide adoption, you need to provide an incentive or requirement for improvements to your software to come back to the original project. GNU Public License, Lesser GNU Public License, Eclipse Public License, and Mozilla Public License all provide the requirements. MIT, BSD, and Apache licenses do not.
The
Re: (Score:3)
I think it's good that they choose a permissive license for their source code, but their reason for it, Why MIT? [redox-os.org] is just... someone is wrong on the Internet [xkcd.com]
The GPL is upstream-centric, the MIT license is downstream-centric. We happen to prioritize downstream more than upstream, since downstream is what really matters: the userbase, the community, the availability.
It is the GPL that is downstream-centric and MIT that is upstream-centric. The GPL was designed to ensure that the entire program, source code, and ability to use it, are available to the userbase and community. The MIT license is primarily about avoiding liability, so anybody upstream of the userbase has greater privileges than the community.
I wish the
Re:GPL was a good choice for Linux (Score:4, Insightful)
Say share-and-share-alike. "viral" is pejorative and it's not in our interest to continue its usage.
Re: (Score:3)
What could possibly go wrong? (Score:4, Insightful)
Oh please..... (Score:5, Insightful)
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 (Score:4, Insightful)
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 (Score:5, Insightful)
we will not replicate the mistakes made by others
Nope, you'll just brand new mistakes of your own!
Re:Mistakes (Score:4, Funny)
Like me, when I accidentally a word. Fuckit.
(I nearly accidentally a word just then, too)
Good Luck with that (Score:2)
This feels like Donald Trump meets OS (Score:2)
If I yell enough, people will look at me.
Well (Score:3)
The userspace, sure. The kernel? How do you intend to access hardware without using a pointer-type that could (if used incorrectly) crash the kernel? And how are you going to program those drivers etc. BETTER than the Linux people who - if they don't use their pointers correctly - will crash the kernel too.
The userspace can surely benefit from a complete rewrite, but I'm not at all sure what kind of investment in time it would be to rewrite the vast swathes of existing software to be "Redox" compatible, or what would benefit from it. If you're going to do this for security reasons, you can't have unsafe raw pointers, which Rust supports but again "You're on your own, I hope you manage them properly" is the mantra there.
But a kernel? Or even a set of drivers? Love to see how you're going to get close to that, even if you just convert the existing code and abstract out the memory references.
Mild Irony, but very telling (Score:2)
So, on their flame page of "why we rulez and you dr00lz" page, they have TODO - rewrite this. [redox-os.org]
So, you expect to do a full OS, take over the world, and you can't even finish a c.300 word rant. Sure....
Besides running on PCs, BSD and Linux are the core of iOS/watchOS/tvOS/macOS and android. We're talking billions of devices here. I'd be interested to know what they call a failure. If you have one of these "failure OS"s in your pocket, you may reconsider your zealotry.
Ahh the bliss of youthful ignorance (Score:2)
I wish I still was of that beautiful age where you think that technological superiority and general betterness means anything in the real world :(
Strange flamebait article (Score:5, Interesting)
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 [linuxfoundation.org] 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. [slashdot.org] 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
Re:Strange flamebait article (Score:4, Informative)
L4 and QNX are working, performant microkernels that have seen plenty of deployment in the real world. Not on the desktop granted, but performant microkernels aren't some mythical unicorn, they're everywhere and have been for over a decade.
Re: (Score:3)
Virtually by definition, ALL system crashes HAVE TO BE in the kernel.
Um, ok. I wasn't being pedantic enough. The majority of crashes on Linux distributions that disturb the end user are not caused by the kernel. Meaning, userspace programs crash all the time and this bothers the end user, whatever they may have actually been doing with their system. A daemon locks up and you have to restart it or something, fine ok, not technically a "crash" but still annoying to the end user. How often do true kernel crashes happen relative to userspace program crashes? Small. Maybe a bit h
Where have I heard this attitude before...? (Score:4, Funny)
Theo de Raadt, is that you?
Re: (Score:3)
I'm sure someone is registering the domain name UbuntuRedox.com as we speak! :)
Re: (Score:3, Insightful)
Microsoft can barely get people to use WinRT and yet this group of nobodies expect to displace POSIX? Sure, brahs.
Re:They are right, but will they get it right? (Score:5, Funny)
They are going to base it on systemd, aren't they? Since throwing away past mistakes is a central criteria?
Re: (Score:3, Insightful)
systemd is all about reinventing past mistakes and bringing them into the present in an entirely new way.
Re: (Score:2)
Re: (Score:2)
Which is an improvement. We can all use new mistakes to learn from.
Re: (Score:2)
Seems like it's all politically motivated. The only parts filled out in the wiki have to do with philosophy and politics. The rest is rust centric hipsterism with vague descriptions of design concepts. In their favor, though, they do have source available. Most of these projects don't get that far.