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.
It feels like this https://xkcd.com/927/
Their name is missing a syllable
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.
Another flavor of the month OS that will change nothing.
Good luck with that, guys.
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.
There is always scope to improve over POSIX, which I admit are pretty bad at many places. However, getting another set of API's right is also a task in itself.
why repeat others' mistakes... when you make new ones!
Someone got a bad case of 'Not invented here'.
Modern app appers use the AppOS Apperating App, which is apped using AppScript, NOT LUDDITE RUST!
Apps!
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.
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.
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!
To these folks, the mistake linux has is a fundamental intention of the original designer.
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.
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.
If something is so important that you feel the need to post it on the internet... It probably isn't that important.
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.
Live today, because you never know what tomorrow brings
Finally someone is doing MS Windows right.
Until Microsoft isn't suing.
Redox is based on a microkernel: http://www.redox-os.org/book/b... They seem to be emphasizing a very small number of system calls, and making "everything a URL" (instead of everything a file): http://www.redox-os.org/book/b... I'm skeptical this will get very far, but let 'em try!
- David A. Wheeler (see my Secure Programming HOWTO)
There might be people with sensitive dispositions reading, donchaknow.
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.
Still waiting on Serviscope_minor to wake up to fucking reality and realize that Jessica Price isn't going to fuck him.
Old Kung Fu proverb.
We suffer more in our imagination than in reality. - Seneca
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
SJW n. One who posts facts.
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.
POSIX does not:
i. Specify a portable way to isolate processes into groups? (This is why it's possible to build an advanced init system on Linux and Solaris)
ii. Have an API to expose the features of the next gen file-systems, like Zfs and Btrfs.
iii. Deal with virtualization at the OS level.(Containers[Linux] and Zones[Solaris])
POSIX compatibility cripples server software and the major desktop operating systems ignore POSIX(Windows) or abstract most of the core functionality from the app developer(Mac OS X).
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
Starting out with a series of principles and critiques is a little weird. If you really want to make a new OS, cool. But make it useful to someone. Nobody really cares that "you're not doing to make the same mistakes as everyone else did!". It's more than a little odd to define yourself against others, and especially against "others mistakes".
Tell me what this thing is going to do, and the role it's going to play. What is it good for? How can I do cool new things with it that can't be done, or done easily now with what exists?
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.
If I wanted to end my marriage I would just ask my wife if she wanted to program an OS in rust. This is literally how unappealling I find this language, their rhetoric aside.
I have little faith that we are going to see another OS other than Linux/Winodws/OSX dominate in general computing. The biggest reason is drivers. It's funny that in one of their blurbs they mention that they like BSD over Linux but they mostly still use Linux. I wonder why? Probably because the driver situation is much more comprehensive on Linux. Redox will suffer from the same problem. Don't color me surprised when in a few years this project is stagnant or dead and the developers are all still using Linux.
Time makes more converts than reason
And it's a unix.
If I yell enough, people will look at me.
"Don't teach a man to fish, feed yourself. He's a grown man. Fishing's not that hard." - Ron Swanson
If I wanted DOS 1.1, but I don't.
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.
So, on their flame page of "why we rulez and you dr00lz" page, they have TODO - rewrite this.
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.
I wish I still was of that beautiful age where you think that technological superiority and general betterness means anything in the real world :(
I am condemned to reinvent it, poorly.
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
Cyber War is a major concern for the entirety of humans.
The U.S. military alone has thousands of cyber weapons engineers in their employ. Similar numbers must be assumed for Russia, China, Israel and so on.
China also demonstrates what a load of insecure crap computers are which build on the C language. See OPM hack and hosing down of the entire USG personnel.
"We do not reinvent things, just to reinvent them. Don't fix things that are already fixed, fix things which are broken."
Then they proceed to reinvent an entire kernel, and pinky swear they'll just stick to what's broken. Excuse me, I'm still laughing hysterically over that whopper...
The icing is that they immediately lurch into quagmires that everyone with a lick of sense has been carefully avoiding for years, and for good reasons.
Yea, sure guys. Go away and play with your toy quietly somewhere. The adults are busy.
Easy to know when people are smarter than you...Because they tell you they are smarter than you.
I only look human.
My mother is a halfling and my dad is an ogre, so that makes me an Ogreling
Theo de Raadt, is that you?
The whole Microkernel idea is only necessary because a single bug in a process can subvert THE ENTIRE F. PROCESS !
So these "smart" people came up with the idea of Fault Isolation by means of creating lots of MMU-protected processes. What they did not realize was their STUPID PREMISE.
If you use a memory safe language, faults will be isolated at the smallest possible level and you will actually not need an MMU. Because there are no wild, uninitialized pointers. There are no out of bounds reads and writes.
The Microkernel idea belongs to the crapheap of Bell Laboratories.
http://www.economist.com/node/16478792
https://en.wikipedia.org/wiki/Cyberwarfare
https://en.wikipedia.org/wiki/Office_of_Personnel_Management_data_breach
https://en.wikipedia.org/wiki/Stuxnet
http://www.bbc.com/news/business-31482985
All enabled by the C language and everything built on that steaming pile of cheapness.
In one of the Jurassic Parks. 'Hold onto your butts'.
No relevance, but if we're going to be throwing great Jurassic Park quotes out there...
Chuuch. Preach. Tabernacle.
Because there were (and still are) much better systems in existence when they came up with their memory-unsafe DRECK language and MMU based security:
https://en.wikipedia.org/wiki/Burroughs_large_systems
https://en.wikipedia.org/wiki/ICL_VME
https://en.wikipedia.org/wiki/Elbrus_%28computer%29
ssia!
And here i thought it was a interesting looking project.
Sounds like it may well be PotteringOS, as the guy seems to have much the same attitude regarding POSIX...
According to your link, VME is later than Unix. The same for Elbrus.
Cool story, bro. Get back to me when most computer users actually care.
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.
Does that make Donald Trump a SUPERGENIUS?
Funny, I remember the same ostentatious hubris out of the Ruby community. Great, an OS full of REST APIs and a snappy retort from a hipster idiot if you don't like that.
Piss all over them. The OpenBSD community must feel pretty vindicated now!
Bye!
Read "The development program for the New Range system started on the merger of International Computers and Tabulators (ICT) and English Electric Computers in 1968. "
I mean, the way this sounds, I'm expecting Leannart Pottymouth to move to RUST, so he can have *everything* right (according to him).
mark "die, systemd"
Everything they've said is perfectly reasonable. Of course every other OS has made mistakes. Redox will too, and the devs acknowledge this. Hardly a "slam".
Higher Logics: where programming meets science.
Again, C is a regression relative to the Algol history and there is no real need to use C.
Apple and Mozilla are right in correcting this massive regression.
I did have a serious part in this and you are right that I actually did this while living with my mother in our house :-)
The details are not relevant, what matters is that we now have Rust and Swift, so given my limited resources I venture to say that I played this game rather successfully. I also hear the C++ folks are now trying hard to get some memory safety into their language, another validation of my work.
I also learned that one does not have to do all the work by oneself. Show other people the light and they will realize your project !
This is the microkernel debate, all over again. Check the discussion between Torvalds and Tanenbaum. These guys built another Tanenbaum OS using Rust as their dev language. Same arguments as before.
How many times are you intending on spamming this topic with your copypasta?
In the real world, most people have weekends. Clue in, you can have a weekend too if you're any good.
If we could just put it into the minds of the Rust team that systemd has to be re-implemented in Rust and have the systemd team push for a strict requirement that Rust must only be run under systemd-control. Maybe then these two ultra-toxic communities could annihilate each other, to the benefit of everybody else.
Most ACs are not even worth the keystrokes to insult them. Be generically insulted by this and ignored otherwise.
The docs roughly say, "POSIX is crufty and a bad API, we're not afraid to not implement those parts in order to get a cleaner interface".
Okay, but what does this new API look like instead? Will the features enabled by these not-implemented APIs be reimplemented in some other, cleaner fashion? Or will that functionality just not be provided at all?
-Bucky
We heard you the first 10 times. How about a nice cup of STFU now?
That was awesome. Wish I had mod points.
apk?
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
So Redox is maintained and developed by raging 25~30 yr old Hipsters...
~ People that think they are better than anyone else for any reason are the cause of all the strife in the world.
I like reading about different designs, architectures and designing very half baked OS's in my imagination.
What seems to be missing is really anything innovative or new here.. Message is basically Microkernel + use a different language. Things people have already done.
Legacy until infinity: Old syscalls stay around forever
Why can't backwards compatibility be considered an important part of systems design and be architected to be manageable and nimble from the start? I've always strongly disagreed with notion by supporting old ***x*** you necessarily stand in the way of progress. If there was some kind of view based infrastructure to specifically address these things it wouldn't be an issue. The whole essence of programming is managing complexity... asserting you don't have to care about existing systems because it is a drag is a cop out in my opinion.
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 like saying you got lost because there are 4 million miles of roads in your country.
I would very much like to see a new OS rise from the ashes with minimal effort (say a handful of developers over a few years time) everyone agrees is better as a general purpose operating system than what exists now. The problem always seems to be there is just no tool or architecture based replacement for sweat equity. While better architecture and better tools certainly provide an advantage in the end it just never seems to matter. I very much welcome serious efforts to change this.
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.
Fuckwit.
> Legacy until infinity: Old syscalls stay around forever, drivers for long-unbuyable hardware stay in the kernel as a mandatory part. 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.
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.
Restrictive license: Linux is licensed under GPL2. More on this in Why MIT?.
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.
They want to mix
- Some micro-kernel HURD style design
- BSD no-contribution-to-proprietary license
- Functional languages radicals
- No standard / home made API
Everything that fails since 20 years in fact, sounds like a project with a bright future.
Anything written to such an ideological agenda is doomed to fail. Arguing that people such contribute their work to be exploited for no return by proprietrary entities is subversive, ideological, and quite a fanatical viewpoint to have. This is particularly true, for a project that still has everything to prove. It is arguing for developers to become slaves. Having such a publically right wing agenda attached to your project from the start, is not a good way to encourage participation, which is unlikely anyway, since there simply isn't the strength of technical underpinning to lend it any credibility.
And according to your link, VME wasn't developed until the mid '70s.
Is there an OS:
That does not freeze or crash if an application crashes, and instantly can close the crashed application?
Where crashing an application using a known bug (by a hacker/malware) does not give the hacker/malware root privileges?
Is there such an OS today?
Why does this remind me of the Trump campaign? "Make OSes great again!" - "How?" - "We'll get rid of everything bad and replace it with good stuff!" - "How?" - "Shut up, Rust is great".
be useful in 10 years?
By keeping its developers busy and away from other projects.
For years people have been complaining about some opensource developers and their attitude. Often a fork wasn't motivated by technical issues but by the lack of social skills of some of the key developers. (I can think of at least four major projects.)
Finally we have the answer:
Start a honeypot project that attracts all the uber- egos and under-socials.
- Thanks.
A crash will notify you of a problem. Silently continuing to run the program (as it is the typical C behaviour) enables a cybernetic attacker to subvert your system undetected.
So, a well-defined crash notifies the user of the problem and enables the system developer to inspect the coredump and fix the problem.
But I am quite confident all the brain-dead adherents of C and the NSA operatives will claim the opposite.
So they believe that MIT is more open while GPL is restrictive. I really feel they are feeding FUD and not clearly understand why GPL is actually open. I used to consider BSD license to be as good. But when I see PS4 and OS X, I realise why GPL is required. SONY and Apple make a lot of money by making creating products out of other people's work and they are not at all bound to open source their modifications; let alone pay back royalty. And we hardly see any communities and software ecosystems as rich and diverse around Orbis OS (PS4) or Mach (OS X). A simple reason why Linux grew so fast is because of the openness it mandated. GCC, Emacs, Grub, libc and everything developed in open and remained open. Even changes from Android find their way in Linux. And when technology moves through time, hardware changes, new requirements come, you would want those changes to be put back in upstream! They seem to want to get big companies to adopt their stuff and climb the hardware compatibility list sooner than Linux.
Plan 9 was approved by our Great Ruler! Sure, resurrection of the recently dead Earthlings didn't seem to pan-out well, but that was due to their stupid,stupid, minds.