I also disagree with his take that the Kernel could be replicated in Rust by 6 motivated volunteers in 4 or 5 years. That could be said of many projects, you could probably reproduce AAA entertainment software with such a team in such a span of time, but the trick is getting these people to stay on track, fed, and satisfied for that time. Who's going to pay for their rent/mortgages? Are they just not going to work for the duration?
It's naive grandstanding in the best of cases, and malicious proselytizing in the worst.
You are misrepresenting the original article. Drew did not say six volunteers or 4 or 5 years. Those are your numbers, so feel free to agree to disagree with yourself.
A Linux kernel clone is the epitome of a large Rust community project (for many reasons, some noble, some not so noble). It would likely pull in hundreds if not thousands of developers in an arms race assuming the end goal is well defined.
Nobody claims it's a small task, but I believe it can probably be accomplished. Particularily in the scope of the original claim "applied to a new Linux-compatible OS we could have something production ready for some use-cases within a few years."
I disagree. There is already a project for a Rust OS, and its been around for years and I don't even know if it'll actually function on real hardware or just in VMs.[1] Or even enough to matter. There is already a project, where are the hundreds, if not thousands, of developers?
But that's not the project discussed in the article.
Now I'm not saying I agree, but his premise was a Linux-compatible kernel, which Redox most definitely is not. Redox explicitly does not intend to be POSIX, has its own custom (in-house) filesystem, desktop environment, and is a microkernel as well. A better comparison for Redox would be Hurd, not Linux.
This isn't a Linux kernel clone. The whole argument is that producing a "bug-by-bug compatible" Linux kernel clone should be much easier to pull off than a "research kernel" where you may get lost in exploring design dead ends.
Or, the original claim: How small a team, and how quickly?
Sure, the Linux development process was inefficient. There were a lot of false directions and dead ends and things that were OK ideas but were superseded by better ideas. If you know the destination, you can drive straight there without all the wandering around.
But, fine, how inefficient was the development process? 90% wandering around? It probably wasn't 99% wandering around. So you're going to need something like 10% of the man-hours that went into Linux.
You say Rust is more productive? How much more? Maybe a factor of two? OK, you need 5% of the man-hours that went into Linux, over the last 20+ years.
That's still not a small team and quickly, no matter how you slice it.
I don't know where that image is from, so you are working on information I do not have, but still, the first "paragraph" sets up a possibility reinforced by an anecdote in the second. It's not asserting that only 5 contributors could re-create the entirety of the Linux kernel in 5 years.
I very much took his argument as an open-source project with a small number of leaders, with the help of the larger OSS community, could make a mature subset of a Linux compatible kernel in a small amount of time (years)
nanos wrote a quite reasonable subset of the linux kernel in C using less than 5 people at a time on average and somewhat less than 5 years. this can totally be done.
> Nanos aims to be a much more secure system than Linux. It does this through several thrusts. Not having the notion of users, running a single process per vm, and limiting the amount of code that is incorporated into each vm.
> 2. Minimalist:
> KISS. As Nanos is not intended to be ran on bare metal we strive to keep the core as simple as possible.
How do the current Rust/Linux maintainers pay their rent?
Also your estimate for AAA game development is massively optimistic, AAA team sizes are in the hundreds today (not a good thing for quality and innovation, but that's how it is).
I can't give you a complete answer, just partial stuff I am aware of
1. Rust fanboys poping up on other language topic and shitting on them and promoting Rust
2. Ton of low quality promotion, like you would get on HN crap like TODO application in Rust, and the Rust community would just upvote and promote this low level 1 weekend project just because is Rust
3. RIR rewrite it in rust, toxic Rust fans would popup on projects communities and demand to rewrite it in rust, or why is this not in Rust, or I would contribute if you rewrite it in rust.
I am not sure why this community is so toxic, I do not remember Java,Python to have this problem, I suspect that the toxic part is just a portion of the developers but the community of Rust devs did not manage to keep the toxic people in check.
But honestly use a search engine and find more details, I am avoiding this kind of drama so I do not have latest gossip (just seen a link here that the ladybird devs also called the Rust people toxic , probably because they are butt hurt that people are making a more popular browser then their Rust alternatives)
It's naive grandstanding in the best of cases, and malicious proselytizing in the worst.