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)
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.
It might be better, but you can't strike out network effects. Because then you just end up with another rant why your thing is superior to that other thing everyone is using.
I am wondering if good old things are not just predestined to be unpopular. Probably only new things can get popular (even if they are just miserable copies of great old ideas). Next generation is more inclined to pick up something from the news than from history books. Next generation has their new lingo, so they will not understand easily old lingo. Next generation is cheaper to employ than older generation, so it's easier to get more in terms of quantity. Most (young?) people want everything, even if mediocre, now, than having few perfect things now, few perfect things later. The world belongs to the youth.
OTOH, some of the above you mentioned isn't bad. Linux's "just a kernel" philosophy can be useful, and allows people to experiment with new inits (s6, runit, &c) and new systems that come in handy.
And go see Brendan Gregg's talk on Linux tracers. It's not as simple is dtrace, given the tracing war hasn't been won, but it's at a place where you CAN do most of the things dtrace does.
Yes I am, because I picked a highly reliable, stable substrate to build my own private infrastructure on.
As for using Linux, I'm not dropping Linux until LX-branded zones can run Steam, and my game library. And I don't see that happening for a while yet.
It may not be ideal for infrastucture, but if you want a UNIX on your desk, for all its flaws, Linux is pretty hard to beat.
I chuckled when I read that, and I want you to know that I appreciated it.
but if you want a UNIX on your desk, for all its flaws, Linux is pretty hard to beat.
I have Mac OS X for UNIX on the desktop. Works like a charm, and never gets in the way of what I'm trying to do.
Have you looked at alternatives to GNU/Linux, like PC-BSD or FreeBSD? Did you find those inadequate / too much overhead?
I agree, that makes perfect sense.
and in any case I doubt they're good enough to get the games talking to my GPU properly.
Now that's a whole different story: NVIDIA provides Solaris-native packages for their drivers, and they JustWork(SM). Way back in the day, NVIDIA engineers were stunned that they didn't have to produce a completely recompiled driver for every Solaris release: thanks to device driver interfaces/driver development kit[1], one could develop the driver on an ancient version of Solaris and have it work flawlessly on the latest-and-greatest one.
When I wrote that I'm using Mac OS X, that was the truth, but it wasn't the entire truth: I am typing this on my intel-based workstation I put together myself, with Solaris 10 running on it. And it has an NVIDIA GTX 980 accelerator, the top of the line model one could buy at the end of 2014. Downloaded the driver from NVIDIA's site, installed it with pkgadd(1M), and it JustWorks(SM)[2]:
> pkginfo -l NVDAgraphics NVDAgraphicsr
PKGINST: NVDAgraphics
NAME: NVIDIA Graphics System Software
CATEGORY: system,graphics
ARCH: i386
VERSION: 343.22,REV=2014.09.11.17.06
BASEDIR: /usr
VENDOR: NVIDIA Corporation
DESC: X and OpenGL Drivers for NVIDIA Quadro graphics
INSTDATE: Dec 04 2014 22:37
HOTLINE: Please contact your local service provider
STATUS: completely installed
FILES: 188 installed pathnames
30 shared pathnames
2 linked files
42 directories
7 executables
405482 blocks used (approx)
PKGINST: NVDAgraphicsr
NAME: NVIDIA Graphics System Device Driver
CATEGORY: system,graphics
ARCH: i386
VERSION: 343.22,REV=2014.09.11.17.06
BASEDIR: /
VENDOR: NVIDIA Corporation
DESC: Kernel Drivers for NVIDIA Quadro graphics
INSTDATE: Dec 04 2014 22:37
HOTLINE: Please contact your local service provider
STATUS: completely installed
FILES: 6 installed pathnames
3 shared pathnames
3 directories
52151 blocks used (approx)
As for Mac, OS X has plenty of major and indie titles in the Apple app store. But, it's for people who are actually willing to pay for that.
And now, because you didn't ask for it, Game Reccomendations:
Have you tried out TIS-100? You can get it through Steam, and maybe a few other places, it runs on Mac, and I'm willing to bet it'll run in an LX-brand. It bills itself as "the assembly language puzzler nobody asked for," and has a focus on minimal instruction count, maximum speed, and paralellism. You should know by this point if you're interested.
You also may want to check out Xonotic, which is an arena FPS with a relatively lively community, which may compile on Solaris. Think a mixture of Quake and UT.
Apropos Qt, it is not for the faint of heart: even on platforms it officially supports, it is very hard to build, at least it was last I had to do it professionally, back in 2013. Qt is really unprofessional as a product, I remember it involved a lot of hacking and coercion of the build engine to get it to build. And it's monstrously large.
Post scriptum:
ah, "Xonotic" is a fork of "Nexuiz". Okay, that's clear now. "TIS-100" is a puzzle game. So these are individual titles, not technology which enables running on a different operating system. "The Ur-Quan Masters" used to build and run superbly on Solaris; it showcased just how good of a gaming platform Solaris could be if the code is good and clean.
lx-brand could be made to work, this screenshot shows it's possible:
https://www.perkin.org.uk/posts/whats-new-in-pkgsrc-2013Q2.h...
I haven't researched how to translate that into the lx-branded zone though (what the package equivalents would be), primarily because I viewed even the above as too much work: for example, the desktop would have to be brought over to somewhere with an X server. I don't see how it could be made to start on the bare metal's display when it's running in one of the hypervisor's zones?
Xonotic should run on Solaris. DarkPlaces, the engine codebase, is fairly portable last I checked.
TIS-100 runs atop Mono, but it's probably not using GPU heavily, so it'll probably run in an LX brand if you can get X up and running. As for running X11 on LX, the answer is both simple in its phrasing and hellish in its implications: X Forwarding.
I kid. Although it does seem like X forwarding is the easiest option. Luckily, you're not forwarding over the net, so you should be fine.
But yeah, it's nice to have a simple discussion about running video games in ways not intended, and what games are good, after spending a while explaining why systemd is a bad idea for the 15th time, because some people are still taken in by the sparkly unit files, and aren't paying attention to the beast lurking below the surface. (If such people are reading this thread, I'll give you a hint: Separation of concerns is a good thing, and if the process will panic the kernel if it crashes, I want it doing the job it's required to do. AND NOTHING ELSE.)
And while all that is constantly changing, its still possible to compile very old user space software and run it in on a current kernel.
On SunOS, I can install a driver built on SunOS 5.5.1 (Solaris 2.5.1) on the latest illumos or Solaris-based OS, without recompilation, thanks to the device driver interface / device driver kit ("DDI / DDK"). Solaris 2.5.1 came out in 1993; illumos came out, well, today (multiple commits every day).
Is the same possible on GNU/Linux?
The guys didn't have to get out of Oracle to reinvent the wheel: the engineering they did is sound and tenable enough for decades into the future, so they built upon it.
The illumos kernel has been stable for decades now. Teams of five people here, three people there, four people over there, they roll up their sleeves, look at the issues the customers have had and are actually having now, professional engineers with formal education and insight, and in two years they have a working product which only needs a small fix here or there, and is tenable decades into the future. It goes to show that the number of programmers does not a quality, working product make.
For example: it's 2016, and my Linux filesystems in Vertica suddenly go into read-only mode, nobody knows why yet. In 2016! I cannot believe I just typed that, but it's true.
I've been running ZFS since 2006 both professionally and privately on Solaris and SmartOS at several large companies and I have never seen it go into read-only mode. The team which designed ZFS was only five people, not an army.
Bryan Cantrill summed it up so profoundly when, upon showing SmartOS running Linux applications, he ran /native/bin/dtrace and proclaimed:
I have clean water!!!