Reiser4 File-System Port To The Linux 4.20 Kernel

[SystemCrasher]

I guess we should have shutdown Linus early on then. I'm not disagreeing that it isn't true, it's just fundamentally wrong.

Since Linux has began WITHOUT corporate sponsorship, it seems it IS doable. But challenging. Then, I do not see how or why it fundamentally wrong to get companies to pay if they would benefit from this activity. Should these corporate nuts get free ride all the time instead? Should something good appear, they would use it, one way or another, you can't forbid it, lol. If one thinks it rocks to do things like that, go use something like BSDs and feel free to check how it performs in the wild. Somehow Linux example showcases companies can be integrated into development processes much better than THAT. Somehow half-abandoned upstream + bunch of private proprietary forks does not rocks the world, leads to duplicate efforts and overall performs like crap.

And on side note, corporations usually don't consist of green aliens with 3 eyes - so they don't necessarily have terribly unique demands. Sometimes they can be awkward or annoying - but it doesn't means they can't do something sane

[nils_]

You didn't.

One of the Kernel inclusion requirements has always been that there must be someone that can actually maintain it once it is mainlined, and something as complex as a modern filesystem does require some kind of company backing to be properly maintained. This is not new information.

I don't think corporations can be maintainers, only individuals can.

[V10lator]

I don't think corporations can be maintainers, only individuals can.

So will you maintain it? Cause Reiser devs are known to not do it (just see what they did with Reiser3 after mainlining). It you will, how can we trust you to have the skills and long-term will to do this job?

[nils_]

So will you maintain it? Cause Reiser devs are known to not do it (just see what they did with Reiser3 after mainlining).

To what are you referring? The unfortunate situation with Reiser and his wife?

It you will, how can we trust you to have the skills and long-term will to do this job?

You could make it a condition for parole

[SystemCrasher]

I don't think corporations can be maintainers, only individuals can.

That's what prompts companies to hire individuals...

As for Reiser4, if I remember, one of major objections has been utter ignorance of Linux kernel facilities, resulting in heavy code duplication, overall fragility and very well expected issues when it comes to long-term maintenance. Btrfs has been grilled a lot on these grounds - and it eventually ended up using Linux kernel facilities everywhere it can, and having very well justified use cases where it can't do that. Linux kernel devs wouldn't buy abstract mumblings. Historically, Reiser4 devs attempted exactly that kind of thing and it (predictably) failed.

[starshipeleven]

I guess we should have shutdown Linus early on then. I'm not disagreeing that it isn't true, it's just fundamentally wrong.

The belief that FOSS can be anything more than a curiosity without companies that use it investing in it is fundamentally wrong.

[starshipeleven]

Since Linux has began WITHOUT corporate sponsorship, it seems it IS doable.

It was a much simpler thing back then. Once a project reaches a critical mass you need more resources than volunteers can provide.

[starshipeleven]

To what are you referring? The unfortunate situation with Reiser and his wife?

Afaik shortly after the filesystem was mainlined they more or less refused to do much in the way of maintaining it or fixing new issues, while claiming it was stable.

[starshipeleven]

I don't think corporations can be maintainers, only individuals can.

I don't think I said corporations can be maintainers, only that company backing is usually required.

[Vistaus]

So, now FOSS requires big closed IP company sponsorship, right? Just making sure I heard that correctly.

Funny. I thought you'd mention mr Reiser's actions for the gazillionth time, like people do on every Reiser4 article.