> Aha, you mean like redhat and IBM did, where there are now "kernel developers" who can't find their way out of a wet paper bag,

No, I mean like I can find any number of actual maintainers with a known track record and make them an offer to pay to have work done. Been there. Done that. Got good results.

> in order to have a look at what your presumption looks like in the real world...

It's not a presumption. It's actual experience in finding people to do work.

> ...Because we need more beta filesystems

Not everything is about need. While I work full time with Linux, a lot of what I use my computer for is fun, experimentation, learning. So yes: We need more beta filesystems. It's great that people experiment and learn. Everyone should try their hand at kernel changes, to learn - it's not magic.

> ...which ext3, which was on this Veritas disk group, wasn't able to recover, let alone detect. In the 21st century. Because community. I last saw a problem like this on Solaris ten years ago, since it has been a solved problem since 2006 there. Bryan is correct, I do have clean water, and even modern medical care facilities!

So use Solaris then, if you have so many problems with Linux. We're not forcing you to use Linux. It's not a dictatorship. I'll happily admit to all kinds of warts in Linux - I explicitly made the point that Linux has plenty.

> I have zero interest in how much of a community Linux has

Good for you. Meanwhile, for me, the community makes all the difference in making sure that I, e.g., has a decent sized hiring pool at all levels when I need developers, or which means that pretty much no matter what I try to do, there are people who have done it before I can ask questions of.

To me, that matters far more than avoiding a few warts.

You exhibit a weird mixture of snobbery and incompetence. How odd.

I've decided to stop interacting with Annatar, it's not worth the rage. Especially when he starts misrepresenting GNU/Linux technology that you are deeply into the development of (runC and containers in my case).

Part of engineering a good solution is being able to recognize when you are in knee deep, and that it's not the best solution, and ditch it. That's what turns a good engineer into a great one, because then she or he turns around and builds the solution. You might not believe the grandpa here, but you're in knee deep, if not deeper.

On a personal note, I'm happy that you've stopped interacting with me. Good luck.

Ah, my apologies for that: I did not realize that shoddy NFS software is due to my incompetence. I also apologize that I wasn't able to get something which kind-of worked in RHEL 5 to work in RHEL 6.5 because things which are completely unnecessary on UNIX (like worrying about separate portmapper service) and which were in userland are now suddenly in the kernel. But only for NFS 4. Because the documentation is actually unclear on whether that's the case for NFS 2 and 3. And because the NFS protocol specifies that client and the server should auto-negotiate which version they will use. Because of course the community can't figure out where what should be, so flux. Again.

I guess it's really snobby of me to except things which work on UNIX according to specification to behave the same way on Linux. Because Linux is cool. And it's great. And it has the biggest, bestest community. And because I don't appreciate just how great that is, instead being focused on getting work done with computers.

Now let's rehash inter-process communication again. Because it's fun rehashing things which work in other operating systems, over and over and over in Linux. Because Linux is cool like that.