[bangaladore]

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

[tcmart14]

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?

[1] https://www.redox-os.org/

[KAMSPioneer]

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.

[flohofwoe]

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.

[AnimalMuppet]

Much easier? How much easier?

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.

[brezelgoring]

https://imgur.com/a/FcmNLbx

I’m extrapolating but this would hardly be “misrepresenting” his position.

[bangaladore]

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)

[convolvatron]

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.

[_nalply]

https://github.com/nanovms/nanos

> A kernel designed to run one and only one application in a virtualized environment

    ---

https://github.com/nanovms/nanos/blob/master/CHARTER.md

> 1. Security:

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

    ---

https://github.com/nanovms

They patched erlang and gpu-nvidia to work with Nanos

    ---

https://ops.city/

A product based on Nanos