5 ms·

I have the feeling that things will settle into a Microsoft-like "things mostly work, most of the time, because so much effort was put into it rather than good

by badsock 11y ago

I have the feeling that things will settle into a Microsoft-like "things mostly work, most of the time, because so much effort was put into it rather than good design" kind of world. Sort of like how PulseAudio is now. Most people are cool with that kind of OS, so I don't think there will be much more than occasional grumbling. People like me who can't stand it will all have left.

chris_wot 11y ago
Pulseaudio had bugs which caused problems, but what in particular is it about the design of PA that is flawed?
- badsock 11y ago
  Massively overdesigned while trying to solve a problem that almost no one had (network transparency). FreeBSD's implementation of /dev/dsp is a good example of how simple it can be.
  - the_why_of_y 11y ago
    Yes, doing the mixing in kernel space is nice: it's obvious, simple, reliable, monolithic. Unfortunately the Linux developers don't want to go that way, because they think mixing is a problem for user-space.
  - upofadown 11y ago
    Pulseaudio does network audio right and I have been using it for that purpose since it first existed. So from my prospective the mistake was adding in all the other junk. The root cause of all the complexity is (was?) the lack of standardization for hardware interfaces. The lack of some globally usable way of dealing with latency at the OS level is another issue. A thing like Pulseaudio is a natural reaction to the current situation in that it tries to both hide the complexity of the hardware interfaces and deals with the latency issue entirely in one program. So the problem isn't Pulseaudio. The problem is the environment that media is forced to exist in.
    - badsock 11y ago
      If you end up with a giant ball of hidden complexity, that's a strong indication that you're dealing with that complexity at the wrong level. Both PulseAudio and systemd seem to have the "throw everything out, start from a beautiful abstract interface and work down" mentality, which is a recipe for the mess that they've ended up as. Sometimes the best thing to do is pass the ugly complexity one layer up - which is, I think, one of the things that Unix does mostly right.
  - andor 11y ago
    PulseAudio supports network streaming, but it's certainly not the main selling point. Important features are: * Mixing several streams in software, if there's no hardware support (th e FreeBSD sound driver does that as well) * Dynamic switching between several audio interfaces without stopping the stream, e.g. switching to a Bluetooth headset during a phone call * Reducing power usage by supporting different latencies for each client application, and then running the hardware with the lowest currently requested latency
  - digi_owl 11y ago
    Supposedly network transparency came later. Best i could find, Poettering started work on Pulseaudio because he picked up a usb headset (basically a usb soundcard with tethered headset) and ran into issues with switching the IO streams around mid-use (say plugging it in while in the middle of a Skype call). Not sure why he passed on using JACK though, or if it was not mature enough for him at that stage. Also, i don't think Alsa had dmix (user-space software mixing) at that point in time. As best i can find the one thing Alsa is missing is a interface other than .alsarc for configuring pr user virtual devices.
- fapjacks 11y ago
  Particularly that it doesn't work. I always hear about people for whom It Just Works, but that hasn't been the case for me over the course of a couple handfuls of machines. For what it's worth, LP and his gang seem like people for whom "it mostly works" is satisfactory, and that's not something I'm comfortable with in something like an init system, to be frank, because what about when it doesn't? The answer there unfortunately seems to be WONTFIX or outright hostility.
  - chris_wot 11y ago
    Your implementation doesn't work. My question is what part of the design is flawed?
    - fapjacks 11y ago
      > Over the course of a couple handfuls of machines That's more than "your implementation" considering that it spans at least ten machines across about the same number of distros including Fedora (and one FreeBSD). But it's cute that you're so quick to say it's "implementation" when it's clearly broken across so many different environments. Pulseaudio is a stinking pile of shit.
blueflow 11y ago
Similar feelings here, this "it kinda works"-feeling was the reason why I switched to Linux in the first place. What are your plans? Where do you go when you 'leave'?
- Jach 11y ago
  To a distro that doesn't force things down the throats of its users in the same degree Ubuntu et al. do. e.g. Gentoo. (You can even run a FreeBSD kernel in Gentoo if you want.) That isn't to say it's been all rosy in Gentoo-land. It was an effort to keep Gnome3 off my system, to keep the existing Gnome2 versions of everything until MATE (and the Gentoo community packaging) was ready enough to replace Gnome2. But my system is happily free of Gnome3, systemd, and pulseaudio. And because Gentoo doesn't really have release versions, I can keep my other packages up to date indefinitely.
  - digi_owl 11y ago
    I do wonder how much effort and forks will be required to keep Gentoo, well, Gentoo going forwards, as more and more stuff either is either lumped into Systemd or depends on/assumes its presence. One can already see how you at least have to keep the libsystemd package installed on Debian's latest, even if you use something other than systemd as the init etc, or else apt throws a tantrum. http://ewontfix.com/15/ http://ewontfix.com/15/ may be the most interesting read in all this. Notice how everything but dbus and the systemd lib have various issues. And if kdbus hits the kernel, systemd is poised to position itself as the mediator between (legacy) dbus and kdbus. All in all there is some serious "one true way"-ism coming out of the systemd camp.
- badsock 11y ago
  I switched all my servers and desktops to FreeBSD. It's like going back in time in many, many good ways (commandline/text-config focus, less magic, etc.), and one bad way (HW support).
  - fapjacks 11y ago
    One more for FreeBSD, and the hardware support issues are a lot less frustrating than for example what I remember of Linux in the early part of the last decade. I expect with the renewed interest in FreeBSD because of systemd, that we'll see things improve greatly overall (for example the million dollar donation to the FreeBSD Foundation).

by badsock 11y ago

chris_wot 11y ago

Pulseaudio had bugs which caused problems, but what in particular is it about the design of PA that is flawed?

badsock 11y ago
Massively overdesigned while trying to solve a problem that almost no one had (network transparency). FreeBSD's implementation of /dev/dsp is a good example of how simple it can be.
- the_why_of_y 11y ago
  Yes, doing the mixing in kernel space is nice: it's obvious, simple, reliable, monolithic. Unfortunately the Linux developers don't want to go that way, because they think mixing is a problem for user-space.
- upofadown 11y ago
  Pulseaudio does network audio right and I have been using it for that purpose since it first existed. So from my prospective the mistake was adding in all the other junk. The root cause of all the complexity is (was?) the lack of standardization for hardware interfaces. The lack of some globally usable way of dealing with latency at the OS level is another issue. A thing like Pulseaudio is a natural reaction to the current situation in that it tries to both hide the complexity of the hardware interfaces and deals with the latency issue entirely in one program. So the problem isn't Pulseaudio. The problem is the environment that media is forced to exist in.
  - badsock 11y ago
    If you end up with a giant ball of hidden complexity, that's a strong indication that you're dealing with that complexity at the wrong level. Both PulseAudio and systemd seem to have the "throw everything out, start from a beautiful abstract interface and work down" mentality, which is a recipe for the mess that they've ended up as. Sometimes the best thing to do is pass the ugly complexity one layer up - which is, I think, one of the things that Unix does mostly right.
- andor 11y ago
  PulseAudio supports network streaming, but it's certainly not the main selling point. Important features are: * Mixing several streams in software, if there's no hardware support (th e FreeBSD sound driver does that as well) * Dynamic switching between several audio interfaces without stopping the stream, e.g. switching to a Bluetooth headset during a phone call * Reducing power usage by supporting different latencies for each client application, and then running the hardware with the lowest currently requested latency
- digi_owl 11y ago
  Supposedly network transparency came later. Best i could find, Poettering started work on Pulseaudio because he picked up a usb headset (basically a usb soundcard with tethered headset) and ran into issues with switching the IO streams around mid-use (say plugging it in while in the middle of a Skype call). Not sure why he passed on using JACK though, or if it was not mature enough for him at that stage. Also, i don't think Alsa had dmix (user-space software mixing) at that point in time. As best i can find the one thing Alsa is missing is a interface other than .alsarc for configuring pr user virtual devices.
fapjacks 11y ago
Particularly that it doesn't work. I always hear about people for whom It Just Works, but that hasn't been the case for me over the course of a couple handfuls of machines. For what it's worth, LP and his gang seem like people for whom "it mostly works" is satisfactory, and that's not something I'm comfortable with in something like an init system, to be frank, because what about when it doesn't? The answer there unfortunately seems to be WONTFIX or outright hostility.
- chris_wot 11y ago
  Your implementation doesn't work. My question is what part of the design is flawed?
  - fapjacks 11y ago
    > Over the course of a couple handfuls of machines That's more than "your implementation" considering that it spans at least ten machines across about the same number of distros including Fedora (and one FreeBSD). But it's cute that you're so quick to say it's "implementation" when it's clearly broken across so many different environments. Pulseaudio is a stinking pile of shit.

blueflow 11y ago

Similar feelings here, this "it kinda works"-feeling was the reason why I switched to Linux in the first place. What are your plans? Where do you go when you 'leave'?

Jach 11y ago
To a distro that doesn't force things down the throats of its users in the same degree Ubuntu et al. do. e.g. Gentoo. (You can even run a FreeBSD kernel in Gentoo if you want.) That isn't to say it's been all rosy in Gentoo-land. It was an effort to keep Gnome3 off my system, to keep the existing Gnome2 versions of everything until MATE (and the Gentoo community packaging) was ready enough to replace Gnome2. But my system is happily free of Gnome3, systemd, and pulseaudio. And because Gentoo doesn't really have release versions, I can keep my other packages up to date indefinitely.
- digi_owl 11y ago
  I do wonder how much effort and forks will be required to keep Gentoo, well, Gentoo going forwards, as more and more stuff either is either lumped into Systemd or depends on/assumes its presence. One can already see how you at least have to keep the libsystemd package installed on Debian's latest, even if you use something other than systemd as the init etc, or else apt throws a tantrum. http://ewontfix.com/15/ http://ewontfix.com/15/ may be the most interesting read in all this. Notice how everything but dbus and the systemd lib have various issues. And if kdbus hits the kernel, systemd is poised to position itself as the mediator between (legacy) dbus and kdbus. All in all there is some serious "one true way"-ism coming out of the systemd camp.
badsock 11y ago
I switched all my servers and desktops to FreeBSD. It's like going back in time in many, many good ways (commandline/text-config focus, less magic, etc.), and one bad way (HW support).
- fapjacks 11y ago
  One more for FreeBSD, and the hardware support issues are a lot less frustrating than for example what I remember of Linux in the early part of the last decade. I expect with the renewed interest in FreeBSD because of systemd, that we'll see things improve greatly overall (for example the million dollar donation to the FreeBSD Foundation).