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.
On a personal note, I'm happy that you've stopped interacting with me. Good luck.
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.
This warrants a reply of its own, since it is the core idea of my essays: it is the very difference between a stable, working, reliable product and Linux: the people. The right people. Competent people. People with the neccessary education, experience, and insight.
If if ever need heart surgery, I guarantee you that I won't go to the local shaman, no matter how happy he will be to perform the operation voluntarily and for free. Same goes for the local exorcist. If I ever need one, I'll get my surgery done by a specialist in cardiology, because they have been formally educated, formally trained, and have the requisite experience to operate on a human heart. And in the case of illumos / SmartOS, they will even do it gratis, like "medical doctors without borders" organization does. Right people for the job. For some reason, people here and at large believe that when it comes to inter-process communication, NFS, or writing operating system kernels anyone can do it.
Why exactly people believe that computer science is different from surgery, I haven't discovered yet, but based on empirical evidence of Linux and other crappy software, I have a hypothesis, and since the sample size is large, I might have a theory soon...
Which is why I wrote what I did.
Your reply manages to turn it entirely on its head.
People believe computer science is different from surgery because it is: Nobody dies when my half-assed experiments with OpenGL crashes. Nobody dies if my laptop crashes.
There are certainly niches where it is life and death. Let others take care of that - I don't want anything to do with it.
And it shows. However, just because you can get something to work, in some way, does not suddenly make you (or anyone else) a professional. Case in point:
http://meta.serverfault.com/questions/6229/frustration-when-...
...Nor does it make your playful experiment fit for production where people like me are trying to get work done.
"I got something to work. Because Linux! Because community! Um... I think I'll go get a job as a computer professional now. What could possibly go wrong? Linux is so awesome!"
People believe computer science is different from surgery because it is: Nobody dies when my half-assed experiments with OpenGL crashes. Nobody dies if my laptop crashes.
An operating system's kernel is an extremely complex, special piece of software. A bug in such software can cause many people to die, which is why someday you might see disclaimers about running a nuclear facility and fitness of purpose. (Interprocess communication, the original topic, is part of an operating system's kernel.) Writing and diagnosing such software requires very deep insights, which very few have, even among computer professionals. Additionally, it absolutely and without fail requires formal education in the problem domain, it requires experience, and it requires apprenticeship, and I'm writing about physical one on one mentorship. It's not something one can pick up "from the community", never has been, and never will be, and if anybody tells you any different, they're either dangerously ignorant, or lying to you for the purpose of their own agenda.
Experimenting is all good and well, but when the entire armies of you start deploying your experiments in production and it becomes a trend and then the rest of us are, in fact, forced to take on such jobs because there aren't better ones, then it becomes a systemic problem. Not to mention that armies of you are currently in the process of artificially driving salaries down and it will be years before the market self-corrects, so make that a double whammy.
Now, me, I don't so much mind that cheap Linux labor is artificially driving salaries down, since cream always rises to the top, as they say, but I do so very much mind being forced by contract to work with things like ext3, which is based on concepts from the past century and which have since been long abandoned elsewhere, or that my really cool super slick database becomes unstable because of your experiment ticking underneath it (and before you ask, if it were up to me, I'd never put my database on your experiment). I mind even more when your (plural) experiements end up causing a priority 1 incident in the wee hours in the morning, when I'm busy getting my beauty sleep. In my case, you see, it's "because client contract!" Slightly different slant on things than in your case. Welcome to the industry.
I'm sure we could have something cleaner with a single, coherent team. But we also would have something that'd be useful to far fewer people.
Linux wins not by being best at everything. It has plenty of ugly warts. It wins by being accessible ranging from e.g. my ability to just take a job 20 years ago to port it to a custom x86 board with no bios or hard drive, because everything I needed was easily available, to the ability to hire any of a "an army" of past or current kernel developers to help solve my problems or do my custom development, to the ability for people to just write "yet another filesystem" and have actual real people try to use it and give feedback and contribute code.
The most important part of the success and value of Linux is that community. Without the community, it'd have little to offer over any number of other kernels that are better in some areas, worse in others.
But with it, it stands head and shoulder above all kinds of technically very impressive solutions because I can do things with and to Linux that I can't do, or can't do cheaply enough or in short enough time, with alternatives (and yes, that can be because of lack of knowledge of alternatives, but that too is part of the community/network effect).
Don't underestimate the importance of people.
> The team which designed ZFS was only five people, not an army.
And that's great. But the whole ZFS saga is also an illustration of how licensing early on can hamper adoption (KDE vs Gnome is another good illustration of how important license is; and how lasting the effect can be even after the licensing issues are sorted)