Rust might prove to be a possible candidate because it can help with safety. This is a different rationale than what the argument for C++ was about, so we cannot say.
The bigger problem I see is how premature the Rust eco-system and understanding is. It needs to go quite a long way people people start believing in it and before the language is well understood by more than a niche group of people who learn it just out of interest.
A project like this might attract new developers because it might be less intimidating than joining the Linux kernel proper. There would also be the attraction of learning Rust in a very real world context.
edit:s/in/it
One would fork Linux on GitHub, name it something other than Linux, and just have the existing branches track Linux.
Linus has stated that he isn't particularly interested in security bugs. Other people take a different view. Eg. [1], [2]
Another incremental step to improved security in Linux after a Rust fork might be to take the lessons learned to create a conservative set of Rust inspired extensions to C without all the hoariness of C++.
[1] https://news.ycombinator.com/item?id=2539839
[2] https://www.schneier.com/blog/archives/2015/11/linus_torvald...
edit 1: removed apparently dead link to original source http://lkml.org/lkml/2008/7/15/296
edit 2: clarify that one wouldn't use the name Linux for the fork
That's already hard given how many commits go into Linux. One must always remember it's not just some volunteer project: most of the commits are by paid programmers working at companies. That's where the labor comes from. You'd need a lot of volunteers to keep up with the paid programmers. Even Linux itself couldn't achieve that. Hence, all the paid programmers working on it.
"might be to take the lessons learned to create a conservative set of Rust inspired extensions to C without all the hoariness of C++."
Now you're thinking on the right track. That sort of thing has been done multiple times at the compiler level where they automagically make C safe with a performance hit. Several teams did it at CPU level. These projects have been used on FreeBSD mostly but also Linux. The strongest one so far is CheriBSD on CHERI processor.
Alternatively, for a safer C that you're manually using, what you describe has already been designed and actually inspired Rust's safety model:
https://en.wikipedia.org/wiki/Cyclone_(programming_language)
It could be revived and improved if people wanted. It got nowhere with C programmers, though, in the past.
Slight tangent: I started my programming career in 1989.
The product was Parasolid and the language was AGA - a C inspired language that preceded C++.
I vaguely remember the following extensions:
* built in logging with Undo
* overloaded operators leading to vector and interval types that worked better than C++
* a proper module system
http://www.adacore.com/knowledge/technical-papers/safe-and-s...
There's also a variant called SPARK that can automatically prove the absence of errors like buffer overflow in a way that would normally take a theorem prover.
You wouldn't of. It was developed internally to write Parasolid. Probably they still use it - several of the original devs are still there 30 years later.
http://www.semdesigns.com/Products/Parlanse/index.html
https://web.archive.org/web/20130303055647/http://www.founda...
https://en.wikipedia.org/wiki/Pike_(programming_language)
https://en.wikipedia.org/wiki/Roxen_(web_server)
Parlanse is used in Semantic Designs' powerful toolkit. Flow was used to make a Spanner competitor, FoundationDB, that was good enough in some way for Apple to buy & pull off the market. Pike was used to build Roxen server that had significant advantages in its time period. A number of companies also used LISP and REBOL for their advantages with at least one asking LispWorks to do a real-time implementation for telecom or something. So, usually it pays to go with a common, often-crappy language with its ecosystem. However, doing one's own language with competitive edge does pay off at times. I think these days one can just do a DSL in Racket or Haskell on top of main language to negate benefits of totally rolling own stuff. People got far with it, though. Galois is on a roll with that in high-assurance systems with this as an example:
https://ivorylang.org/ivory-introduction.html
So, just some fun examples of homebrew for you in return. :)
I guess the market will decide.
Ransomware will explode in the next few years.
If a big enough exploit gets pinned on Linux then sentiment could change and there could be a well-funded hard fork.
edit: saw this quoted on Twitter today (but can't recall where):
“Only a crisis - actual or perceived - produces real change. When that crisis occurs, the actions that are taken depend on the ideas that are lying around. That, I believe, is our basic function: to develop alternatives to existing policies, to keep them alive and available until the politically impossible becomes the politically inevitable.”
Milton Freidman
http://www.goodreads.com/quotes/110844-only-a-crisis---actua...
That's only true if you believe that the only possible accomplishment is to become the #1 kernel in the world.
Meanwhile, it's a very interesting project and it's a clear proof of technical proficiency. There are not many people in the world who can claim that they've written a kernel, let alone one in a cutting-edge programming language like Rust. I would love to have something like that on CV. Meanwhile, criticizing other people's projects does nothing to advance your career.
I was responding to a comment about doing the whole Linux kernel, not the original project. The original project makes sense. You gave another, good reason for that.
"Meanwhile, criticizing other people's projects does nothing to advance your career."
Professors grading things, peer review of research, managers reviewing performance, consumer organizations reviewing products... there's a lot of reasons that statement is wrong. I try to critique with an alternative solution presented and citations for both statements where possible. In the Linux case, I've often recommended tech at hardware and compiler level that automatically makes C code safe some of which have been used on FreeBSD and Linux. Alternatively, running it as a VM on top of a secure microkernel with security-critical apps running outside the VM.
Quite possible, but for the new project to be successful, existing _users_ will have to see clear benefits. The only way I can see those "new developers, using Rust" make a better product than "current developers with sometimes decades of experience, using C" if those experienced developers currently create lots of ownership related bugs.
IMO, _any_ argument claiming the way forward is a (partial) rewrite in Rust should start with some estimate of the number of ownership related bugs in the current code base.
So what? It got built.