The destructive desktop — Linux in trouble?

I'm sure you tried a couple things before you decided that it's just not working the way you like it, but for me it seems that static IPs, your way, should be no problem [1,2,3] with the on-board tools.

Sound: Never had that (or any related) issue since I stopped running weird apps under wine and I light a candle for Lennart every other day for a sound solution that just works in my world, whatever I throw at it.

1: http://wiki.debian.org/NetworkManager#Enabling_Interface_Man...

2: http://manpages.ubuntu.com/manpages/oneiric/man5/NetworkMana...

3: http://wiki.debian.org/NetworkManager#FAQ

The real problem here is that if you set multiple static IPs in NM GUI it will lie to you and tell you that it has done it when it hasn't. This is pretty dire UX.

The audio issues with spotify were from running the native Linux client, oddly the volume control in the Windows/Wine version works fine with alsa (although a recent update to spotify seems to have broken wine compatibility almost entirely).

A general point, the changes described here have been over the course of something like 15 years. So the article seems to be making a "stuff keeps changing!" point... but we are talking about over 15 years. Think about changes to hardware, the Internet, etc. over that time. And most indicators are that the Linux desktop has moved much too slowly compared to say Windows, Mac, Android, and iOS.

Some examples of errors:

"So the Gnome developers wanted to reduce the complexity of their protocol as well and started working on a protocol which was supposed to join the advantages of DCOP and CORBA. The result was called the Desktop Bus (dbus) protocol. Instead of complete remote objects it just offers remote interfaces with functions that can be called."

This is false on several levels. dbus was mostly a kind of cleanup of DCOP for general use, with no intent to "join the advantages of CORBA" which were essentially none. I can make no sense of "instead of objects it offers interfaces" - it has both objects and interfaces, and pretty much can implement the same kind of API that DCOP does (I believe KDE even did that). Basically this paragraph doesn't mean anything I can relate to the actual technology.

"APIs to abstract the uses of OSS, esound and ALSA: gstreamer for Gnome and Phonon for KDE"

This is wrong. GStreamer is for making graphs of elements, where elements are decoders, encoders, effects, filters, etc. and can be both audio and video. There is one kind of element ("sound sink") that does abstract sound output, as you would imagine. There are some other elements that use sound APIs too. But GStreamer is not the same thing as a sound API like ALSA, in any way shape or form. It's for building multimedia _apps_, sort of a media toolkit.

Moreover, the main reason to replace the older tech here (OSS, esound) was just that it didn't work very well and didn't support a lot of the things sound cards do. It's not like keeping that old stuff was an option, since it could barely play beeps.

"it is no longer possible to run the system without a graphical user interface"

I'm just not sure what planet that's on. There sure are a lot of headless Linux servers out there in the world, and it's pretty obvious that the large Linux distributions care about this intensely.

Re: NetworkManager, if it's somehow needed when headless and not configurable headless, that would be considered a bug by all involved. Just a matter of tracking down the details and reporting them if they have not been. All the Linuxes aspire to (and in my experience do) support headless operation.

"they don't implement the original X11 protocol directly and rely on so-called window manager hints."

This sentence is total word salad. X11 has had window manager hints for two decades. What's new is "extended window manager hints" which are some new hints in the same spirit ... in order to do new things. They don't "wrap" anything, so "directly" is just gibberish. Kind of like how CSS 2.0 isn't the same as CSS 1.0, you know? This complaint is equivalent to bitching because you can't use IE5 on the modern web anymore. The protocols are documented, and you have to use an implementation that implements something from within the last 5 years. The extended window manager hints range from 6 years old to 10 years old, so that's how old a crap we're talking about.

An almost exact translation of this claim to the web is: "they don't implement the original CSS 1.0 directly and rely on so-called CSS 2.0 properties" ... see how that makes no sense?

"Writing X11 programs with xcb and proper RPC APIs like SUNRPC or Thrift should be more than good enough."

This 100% misunderstands why dbus is used. The first goal of dbus is not to send a message from process A to process B; it's to keep track of processes (help A find B, have them each know when the other goes away). The messaging is important but in many ways secondary.

Overall, the article doesn't understand the big picture of why all this new stuff was needed. I think there's one big reason: dynamic change. The old ways of doing things almost all involve editing a text file and then restarting all affected applications. But to implement the UIs that people expect (as you'd find on iOS, Android, Windows, Mac), everything has to be "live"; you change a setting in the dialog, and the whole system immediately picks up on the change. You unplug a cable, everything notices right away. etc. The daemons are because so many pieces of dynamically-updated live state are relevant to more than one process or application. That's why you have a "swarm of little daemons" design. And guess what: some other OS's have the same design.

That's (at least one of) the major problems being solved. And the author here gives no indication he knows it exists, let alone his proposed alternative approach.

I sort of get the inspiration for the article: Linux has been trying to keep up with modern UI expectations without having enough staffing for that really, and certainly regressions have been introduced and there have been bugs and things that could have been better. On the 6-month distribution release cycles, users are going to see some of that stuff. It's software, people. And it's understaffed open source software to boot. So yeah, legitimate frustration, shit changes, sometimes it breaks. I get it.

But there's no need to wrap that frustration up in pseudo-knowledge as if it were a technical problem, or say inane things about getting back to the "unix way"; if someone could show up and make the desktop UI stuff behave well with the "unix way" they would have done it. Or maybe they did do it, and the critics understand neither the problem requirements nor the "unix way." Just saying.