* ALSA: Focusses on providing a unified API for audio driver and audio application authors to code to.
* JACK: Focusses on very low-latency audio.
* PulseAudio: Sits on top of ALSA and makes it trivial to move audio streams on-the-fly between audio output devices.
There are three major GUI toolkits:
* QT: Used if you don't hate C++.
* GTK: Used if you do hate C++.
* WxWidgets: Used if you want to always use whatever the "native" widget style is on your target platform.
If you want your audio and widgets to work on Linux, Windows and Mac, and you only want to use one toolkit, use SDL. If you want a higher-level widget toolkit than what SDL provides, use QT or GTK, or -I guess- WxWidgets.
There's neither a mess, nor a jungle here. I suspect that you've been paying way too much attention to what Poettering has to say about the state of Linux. :)
You're right - as a programmer, it's simple - there are plenty of choice. But I'm looking at this from desktop machine user perspective.
And I really do have a desktop with eight different somewhat differently looking and behaving (although they try to co-operate and it's possible to bring some consistency to be not too bothered) widget toolkits.
I'm not exaggerating - it's really 8 different toolkits here. Ok, I got lazy and run KDE those days so it's primarily KDElibs+Plasma and plain Qt (which has its own differences, like file dialogs being notorious one), which are mostly consistent between each other. Then I have a few apps that use GTK2 and GTK3, a few Wine apps, too. There are also KDE3libs for kTechLab, WxWidgets used by pgAdmin3 and Swing for IntelliJ-based IDEs. There are also some old Tk apps but I run those once in a blue moon, so they doesn't count. But on the other hand, LibreOffice and Firefox have their own widget sets...
I've long given up on OSS4 (which, in my personal opinion, is^W was the only Linux sound system with a KISS API) and surrendered to ALSA+PA stack many years ago. And don't have apps that need JACK anymore (used to run some streaming-related software). And ESD & aRts are dead. So, no objections here, although I had quite unpleasant experiences making ESD+JACK+ALSA combo working (that was at least a decade ago). That was before Poettering's rants - honest - although I won't deny that the "jungle" part is obvious reference.
> But I'm looking at this from desktop machine user perspective.
From a desktop machine user perspective, there is no difference between the various audio libraries. So, I'm not sure why you brought them up if that is the perspective from which you were speaking.
> Then I have a few apps that use GTK2 and GTK3, a few Wine apps, too. There are also KDE3libs for kTechLab, WxWidgets used by pgAdmin3 and Swing for IntelliJ-based IDEs.
1) It's the same story on Windows. GTK, QT, Swing, WxWidgets are all cross-platform UI toolkits.
2) The look and feel of a given piece of native Windows software (and its stock dialogs) often differs drastically depending on when the software was written and whether or not someone has bothered to update its look & feel recently. I can't speak to OS X, but given how iTunes and QuickTime player's UI were so dramatically different from what I understood the Mac look & feel to be, I would be surprised if this "problem" was completely absent.
3a) There enough variance in the way you interact with different programs that I have a hard time being sympathetic to the complaint that moving from QT's file picker to GTK's file picker to the WIN32 file picker to a modern Windows file picker is tremendously hard on the computer operator.
3b) Most of have been required to hop into a one-ton missile whose control layout and handling characteristics are radically different from all other such missiles we've operated in the past. Despite these challenges, we almost universally have great success in operating these unfamiliar missiles at highway speed with only the most fleeting of self-generated and self-guided training programs.
Unrelated to all that: I'm finding that I'm substantially more happy with JACK than PulseAudio. I started using PA maybe around 0.9.2 or so. I was -for the longest time- SUPER excited about both transparent network audio transmission and about the ability to move streams between audio sinks on the fly. As time wore on, I discovered a few things:
* Apart from the week or so of demos to myself and friends, I never made use of network audio streaming. [0]
* I almost never had more than one audio sink attached to my computer.
* PA -on my hardware- has widely variable audio latency. (I'm 100% okay with rather large audio latency. I cannot tolerate unpredictable audio latency.)
Recently, I decided to take another look at JACK. I'd been shying away from it because it had a reputation as being really hard to configure and work with. Turns out that that reputation is undeserved! Additionally, JACK has -AFAICT- rock solid audio latency, and manages to use less CPU in the process.
[0] I make constant use of SSH's X11 forwarding, even between my desktop machine and my laptop. This is something that I would conceivably use, and thought that I would use all the time.
1&2) Yes, you're right. All popular operating systems out there are more or less plagued with the same issues. I'm not bashing GNU/Linux (or any other OS) here - I use it and it's a good system. My only point is, that designing protocols (as opposed to designing apps/services) doesn't really help to get rid of inconsistencies and bring compatibility. Sometimes, yes, I bet having a well-defined protocol saved many from inventing their own. But - in my personal perceptions (and I surely could be wrong) - not even remotely enough.
3) They're not hard, just inconvenient to some degree. Given enough time and patience, everything can be worked around (and there are compatibility wrappers/hacks). But - honestly - it's still a mess, both on the surface and under the hood. I really don't want to even think that this particular file picker is unaware of "recent documents" list of another framework. Don't want remember that PgAdmin3 has its own peculiarities interacting with clipboard and selection. And, back to the original article's topic, surely don't even ask myself whenever a smart bulb would be compatible with some phone app, especially one that I may haven't even encountered yet.
@Unrelated: Thanks for the advice. I don't use those features either. Although I don't have any complaints with PA, next time I'll have time and consider messing up with my system I guess I'll give JACK a try.
> All popular operating systems out there are more or less plagued with the same issues. I'm not bashing GNU/Linux (or any other OS) here...
Except that you did. From the comment that started this sub-thread:
> There are many examples of non-interoperable protocols that do the same thing in a mutually incompatible manner. The most famous one, I suppose is GNU/Linux-surrounding ecosystem with its GUI toolkit mess and audio subsystem jungle. [0]
> 3) They're not hard, just inconvenient to some degree.
More inconvenient and more of a mess than than operating a new and unfamiliar car? :)
* ALSA: Focusses on providing a unified API for audio driver and audio application authors to code to.
* JACK: Focusses on very low-latency audio.
* PulseAudio: Sits on top of ALSA and makes it trivial to move audio streams on-the-fly between audio output devices.
There are three major GUI toolkits:
* QT: Used if you don't hate C++.
* GTK: Used if you do hate C++.
* WxWidgets: Used if you want to always use whatever the "native" widget style is on your target platform.
If you want your audio and widgets to work on Linux, Windows and Mac, and you only want to use one toolkit, use SDL. If you want a higher-level widget toolkit than what SDL provides, use QT or GTK, or -I guess- WxWidgets.
There's neither a mess, nor a jungle here. I suspect that you've been paying way too much attention to what Poettering has to say about the state of Linux. :)