4 ms·

This is what happens when everyone focuses on services, rather than protocols.

drdaeman 11y ago
Not quite. This is what happens when everyone doesn't give a damn about interoperability. Whenever they build new protocols (that no one else uses because not caring about interop) or unique services doesn't really matter. 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.
- simoncion 11y ago
  There are three major ways to do audio on Linux: * 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. :)
  - drdaeman 11y ago
    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.
    - simoncion 11y ago
      > 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.
pjc50 11y ago
You can make money on a service, but not on a protocol. You're never going to build a "unicorn" company around an open protocol. (Unless it's a patented protocol, but then people avoid it like the plague)

Not quite. This is what happens when everyone doesn't give a damn about interoperability. Whenever they build new protocols (that no one else uses because not caring about interop) or unique services doesn't really matter. 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.

simoncion 11y ago
There are three major ways to do audio on Linux: * 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. :)
- drdaeman 11y ago
  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.
  - simoncion 11y ago
    > 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.

pjc50 11y ago

You can make money on a service, but not on a protocol. You're never going to build a "unicorn" company around an open protocol. (Unless it's a patented protocol, but then people avoid it like the plague)