I've used Linux for years and have never had these problems. I think the issue is that getting everything working requires a deep understanding of each component and the system as a whole. If you just follow advice on forums, you will make things worse because you're doing things you don't understand to a system that you don't understand. That's not going to lead to success. You need to be able to think critically about what's wrong and what needs to change, and then execute those changes. No, that's probably not worth doing if you already like Windows or OS X. If you don't, though...
(And, there are of course Linux-based systems that were built by someone controlling the whole experience, and those work really well. Android and ChromeOS come to mind, though those aren't really desktops per se.)
The other day, someone here was complaining about udev. It has ruined Linux forever, or something. I have a different experience: udev has made my life very easy. I have a rule for each device I care about, and that device is automatically made available at a fixed location when it is plugged in. For example, I have a rule that detects a microcontroller that is waiting to be programmed with avrdude in avr109 mode that symlinks the raw device (/dev/ttyUSB<whatever>) to /dev/avr109. I then have a script that waits for inotify to detect the symlink, and then call avrdude to program the microcontroller. A few lines of shell scripting (actually, it's in my Makefile), and I can just plug in a microcontroller, press the programming button on it, and everything just works. No screwing around with figuring out which device address it's assigned to. How do you do that in Windows?
I have used Linux as my main desktop and laptop OS for 17 years, and see these problems frequently. It used to be a system I could keep completely in my head, and understand what was happening and why. But from maybe 2005 onwards there has been a persistent and accelerating trend of replacing the old working and transparent (though possibly a bit baroque) infrastructure with fancy new components that are completely inscrutable. And the lack of transparency gets worse and worse the thicker these layers of garbage get. It's mostly fine as long as things work. But things never seem to work if you have a configuration that differs even a bit from the default.
Want to log in from a terminal and start X? Well, too bad there's some new infrastructure this month that makes sure you'll only get access to the sound device when you log in from a properly configured gdm. Want to modify the keyboard layout? Whoops, the xmodmap format that had been stable for a couple of decades now changed for the third time in a year. Want to add a tmpfs on /tmp to fstab? Well, too bad. Some implicit and undebuggable circular dependencies in systemd will make the system unbootable.
And the sad parts are that the problems this new infrastructure is supposed to solve never actually existed. "Great, now audio doesn't work at all. But if it worked, it would have full support for network transparency". It's easy to understand why the problem exists - creating something new tends to be more rewarding than working on the old stuff. It's much harder to see how to fix this madness.
Move to a simpler distribution that won't bother you. I've been on Arch for the last few years because once I set it up, new updates won't add new "functionality". It isn't perfect, but I can keep the entire system in my head. Nothing opaque, nothing inscrutable -- the design philosophy is KISS. It won't hold your hand, but it also won't get in your way.
PulseAudio doesn't depend on GDM, you just need to create a config for it; What I do (on fedora) is move the default.pa from /var/lib/gdm/.pulse/default.pa to ~/.pulse...
You can't expect everything to work when you tear out components then fail to configure things properly...
I wasn't tearing out components. I was doing everything exactly the way I'd been doing forever, and it no longer worked. Which is bad in itself, but maybe it's understandable that niche usecases break every now and then. It's just that it's happened so often and for so many parts of the system that it's hard for at least me to think it's isolated incidents rather than a cultural issue.
The truly toxic part is that every single transition adds complexity and reduces transparency, making it harder and harder to understand the system. It's just not the breakage alone, or the complexity alone, or even the lack of transparency. It's the combination of all of those.
In the start of this thread jrockway proudly says that all you need is deep understanding all the components and the system as a whole. Back in the day this was not actually an unreasonable thing. But it's been getting less and less reasonable for a long time.
(Incidentally the audio example in my original message wasn't even directly related to pulseaudio. It was a few years back, but IIRC it was some daemon tweaking the device permissions, and something else adding users to a special group in the GDM login path but not the console one.)
Well, GDM tends to handle a lot of initialization that it shouldn't be the one doing, using a distribution that doesn't assume you're using GNOME may help with this.
About the transitions supposedly adding complexity; I don't know about you, but systemd, for example, has greatly simplified configuration and management of services, mountpoints, timers, and all sorts of things.
I use awesome in Fedora 17 on some early-2010 entry-level consumer intel hardware, everything is zippy, easy to configure, and doesn't break on me all the time; I feel bad for you man.
It sounds like you're agreeing with the article - things work on Linux when you have a deep understanding of them. While it's good to encourage a deep understanding, the group of people using any given OS will always follow a curve of some sort. There will always be beginners; there will always be people who know just enough to be dangerous; there will always be experts.
Requiring everyone to be an expert will prevent Linux from being a dominant OS, because most people do not care enough to gain a deep understanding of any OS, so they'll pick one that's easier to learn the easy bits.
You'll hit the same problem with any OS. OS X will just get slower and slower, and Windows will become infected with malware. General purpose computers are not easy to use, yet: with the infinite flexibility they provide, there's infinite opportunity to fubar them. The average Linux distributions exposes the flexibility by default, making it seem hard to use. But if you switch to a less-flexible Linux, like ChromeOS, many of the problems go away. So I don't really understand what the article is trying to achieve other than trolling by stating the obvious in an inflammatory manner.
"I've used Linux for years and have never had these problems."
Agreed. That is two desktops and four laptops worth in a decade.
"I think the issue is that getting everything working requires a deep understanding of each component and the system as a whole. "
Not so sure. I'm an end user and tend to just shove the CD-ROM in and cross my fingers. Most 'stuff' works. My stuff is simpler than yours however (audio interface, cameras, keyboard (musical) controller)
IMHO; Android and to a lesser degree ChromeOS (as well as other similar platforms) don't quite count as "Linux" for purposes of "the Linux desktop" as they've replaced nearly everything above the kernel with their own stack[0].
[0] Last time I used ChromeOS it was still mostly in line with ordinary Linux (thought it might have been partially Gentoo based?); but a rather impractical one as it's less than simple to run [things that aren't Chrome]. Heard about Xorg getting replaced at some point, I'm unclear on if that actually happened.
So... one of his key problems is that when (not if) things break, you need to learn more than you ever wanted to know about the low-level internals of an OS to fix it. And you say you've never had that had that problem; you should have a deep understanding of each component and the system as a whole in order to be able to use Linux.
But that's exactly one of the major problems he's complaining about!
It's a different philosophy. Some of us come at it from the perspective that we want to know how our machine works. And when something goes wrong, we want to dig into it and fix it ourselves. The monolithic and opaque OSs that "just work" aren't for us. Oddly, the only place I've seen this attitude described/explained is in Zen and the Art of Motorcycle Maintenance.
(And, there are of course Linux-based systems that were built by someone controlling the whole experience, and those work really well. Android and ChromeOS come to mind, though those aren't really desktops per se.)
The other day, someone here was complaining about udev. It has ruined Linux forever, or something. I have a different experience: udev has made my life very easy. I have a rule for each device I care about, and that device is automatically made available at a fixed location when it is plugged in. For example, I have a rule that detects a microcontroller that is waiting to be programmed with avrdude in avr109 mode that symlinks the raw device (/dev/ttyUSB<whatever>) to /dev/avr109. I then have a script that waits for inotify to detect the symlink, and then call avrdude to program the microcontroller. A few lines of shell scripting (actually, it's in my Makefile), and I can just plug in a microcontroller, press the programming button on it, and everything just works. No screwing around with figuring out which device address it's assigned to. How do you do that in Windows?