13 ms·

As someone who thinks PulseAudio is conceptually flawed, I don't really get the way old linuxers hate on systemd. I mean ok, from a user perspective certain com

by atoav 4y ago

As someone who thinks PulseAudio is conceptually flawed, I don't really get the way old linuxers hate on systemd. I mean ok, from a user perspective certain common things in systemd could have been friendlier, but I always got the things I needed to work and it is clearly a powerful system. While I don't really like the way Poettering handles projects, I think nobody who does open source software deserves that kind of hatered for a piece of software they have written. Usually if you don't like a piece of software, you just don't use it. And this is the core of the problem: If I got the critics correctly the problem has more to do with the way this has been "forced" onto the community. Most criticism on the substance has been just bias colored by this aspect or people being like "I was used to the old system, now I need to learn something new". The latter is of course a totally valid point. If you want people to change their habits, you need to give them a clear reason why and — more important — they need to want to change that habit themselves. The same greybeard friend of mine who still complains on systemd happily adopted pipewire. Why? Because he saw a clear benefit in doing so and nobody forced this onto him. Critica might argue Pöttering now going to Microsoft is proof that he always has been the devil, I'd argue it is proof that a certain kind of culture can drive people out of open source. I could imagine a different kind of universe in which the communications between the systemd devs and the rest of the community had been different and we would not only have gotten a better systemd, but maybe also a Pöttering who would not go to MS. The saddest thing about the whole affair is that it has a stifeling effect on new devs. Who would dare to write another systemd after that? Certainly not me.

bayindirh 4y ago
The issue not being forced only. It's how valid criticisms are just tossed out of the window and systemd is developed as is because "the lead developer and the team knew way better than the collection wisdom accumulated over the years". Funny thing is they have bitten by the bugs they claimed they're immune to, so they had to apply these principles like they're first adopters of these. I've voiced my criticisms over the years, yet I still use systemd. I don't like it, but I don't hate it either. I want to share them, but, It'll be long, so I'll just leave links to my own comments: 1- https://news.ycombinator.com/item?id=27651567 https://news.ycombinator.com/item?id=27651567 - A general criticism comment. 2- https://news.ycombinator.com/item?id=25616356 https://news.ycombinator.com/item?id=25616356 - A general criticism thread. 3- https://news.ycombinator.com/item?id=29672248 https://news.ycombinator.com/item?id=29672248 - About bugs in systemd. At the end of the day, if a critical component of an OS is being replaced, people at least want their concerns addressed. Want to have some conversation. Being yelled at literally and proverbially as forcing adoption of said software is bound to create some backlash. *Edit:* Initial text contained in this reply misunderstood the parent. Corrected, clarified, softened and re-written. Sorry about that.
- WastingMyTime89 4y ago
  - bayindirh 4y ago
    I was working literally underground with no internet connection when these events were happening, so I was never able to observe them real time. I’m not a person who whines on the net and just does nothing. If I was aware, I would be linking issue tracker ids.
    - Crysstalis 4y ago
      Then you may have also missed the various responses to those criticisms and things that were done to address them.
      - bayindirh 4y ago
        It's indeed possible, but during discussions (here and elsewhere) nobody have said something in the line of "Hey, you're telling this, but the idea behind this is documented there, go take a look". Instead I got angry answers about how systemd is much better than what came before it, and I'm telling these things because I'm used to old ways and just resisting change. The mailing lists I read also had the same echo chambers of finger pointing and blaming. Heck, I even read Lennart's blog w/o knowing the page is his, and thinking "He has a arrogant team, what kind of language is that?" Moreover, do I need to remind that one of the systemd developers has been suspended from contributing to kernel [0]? Does this signal a project which is giving due credit to criticisms directed to it? Again in the same article there a link to a mail message from Ingo Molnar [1], which openly says that systemd refuses to use existing infrastructure and does things their way, w/o listening the kernel developers' advice. As you know, kernel is not an important component of an OS, so a couple of devs can just ignore the maintainers of the platform which underpins their system, and creates the foundation for their software to exist. [0]: https://www.networkworld.com/article/2175826/linus-torvalds-suspends-key-linux-developer.html https://www.networkworld.com/article/2175826/linus-torvalds-... [1]: https://lkml.iu.edu/hypermail/linux/kernel/1404.0/01727.html https://lkml.iu.edu/hypermail/linux/kernel/1404.0/01727.html
origin_path 4y ago
boffinAudio 4y ago
>The same greybeard friend of mine who still complains on systemd happily adopted pipewire. Pipewire is not from Poettering. He did Pulseaudio, which is so terrible it inspired the folks to write Pipewire to replace it.
- AnIdiotOnTheNet 4y ago
  People keep talking about how terrible Pulse is for them, but my decades of experience using Linux desktop recalls that for whatever faults Pulse might have it was a huge improvement over the shitshow that was Linux audio before it.
  - AshamedCaptain 4y ago
    I adopted Pulseaudio back when it was still called Polypaudio, so I am aware of the problems of Linux audio before it, but PA was just yet another sound server in a world that was already full of them and didn't really bring anything to the table. Linux audio world is exactly as much of a shitshow today as it was before PA. Lennart didn't even envision people writing the PA API directly, but rather going through gstreamer (then a fancy new thing) or the like. Pulseaudio got popular and then became "irreplaceable" because it started playing a role that would have been played by HAL back in those days; i.e. setting up audio policy (routing, etc) whenever the kernel would fail at it. I was very critic of Pulseaudio, a sound server, incorporating this role, and argued that this complexity would make this project impossible to replace with a newer sound server when it inevitably came. I was proven wrong, albeit in my defense the replacement Pipewire did require a shitton of effort, and PA was becoming toxic in the meanwhile (see the Bluetooth codecs drama). Pulseaudio's "big" technicaly improvement ("glitch-free" audio, aka interrupt-less, long buffers), and without a doubt its major cause of annoyances to users (since it exercised a lot of rarely used APIs), has not been adopted by Pipewire (which goes back to "low latency" + lots of interrupts) or any other sound server for the matter. (And Pipewire still manages to have better performance...)
    - Crysstalis 4y ago
      >but PA was just yet another sound server in a world that was already full of them and didn't really bring anything to the table I seem to remember that the main thing it did was bring "being maintained" to the table, because esound was unmaintained and stagnating. I still find this to be really ridiculous that people complain about supposed "hostile takeovers" in open source when, for a lot of categories of project, there are still somewhere between zero and one alternatives for any given thing. All you have to do to become the top dog is make something that does the bare minimum and doesn't crash, and has like, one person to triage bugs. >PA was becoming toxic in the meanwhile (see the Bluetooth codecs drama). I also still find this to be really ridiculous when people call maintainers "toxic" for being slow or for rejecting patches. Every open source project does that. >has not been adopted by Pipewire Actually it has, Pipewire implements the pulse protocol for backwards compatibility. The pipewire developers are also still encouraging developers to use it because it is a lot nicer to use than the pipewire API.
account42 4y ago
> The same greybeard friend of mine who still complains on systemd happily adopted pipewire. Why? Because he saw a clear benefit in doing so and nobody forced this onto him. I still use OpenRC + ALSA (with apulse for those programs that shit on backwards compatibility) and I too am looking at PipeWire. Beyond the not being forced aspect and actually adding something that is useful (to me), PipeWire also seems to take much more care about working with existing programs/interfaces rather then wanting to get them on the shiny new API.
gavinhoward 4y ago
> The saddest thing about the whole affair is that it has a stifeling effect on new devs. Who would dare to write another systemd after that? Certainly not me. Me! I want systemd capabilities in a small package. I also want it to not take over my machine like systemd did. I want to be able to compose individual daemons, not have the init subsume them. I do like the idea of supervision systems, though, and I am glad systemd popularized (not invented) them. So since the alternatives are quite...user unfriendly (s6), I'm making my own. It's called Ur (universal runner, also after the ancient city of Ur), and I'm building the dependency management for it, which will also go into a build system. So why wasn't this affair stifling to me? It's because I see why people got angry: Poettering used politics to limit user choice. User choice has been a theme of Linux use for decades, and people were not happy about it. I'm not going to limit user choice, so I'm not worried about angering people in that way. I'm also not going to advertise and push Ur like systemd was. I'm going to advertise my build system, and Ur will be bundled with it, and I will help people use Ur, but I'm not going to push Ur because an init and supervision system is just too central to Linux machines to push it on people. Actually, the dichotomy between build systems and init systems is a good example. If a distro choose a build system to base their package manager off of, and you are on that distro when they make the change, their choice does not affect your use of another build system, unless your build system does not come installed by default, in which case, you install it and then continue as normal. But if your distro changes the init, you're in for a long period of relearning and retooling everything. I think Poettering pushed systemd through politics because he wanted to have a popular piece of software, and that's only the real way to do it because distros adopt init systems, not users. I don't blame him for wanting a popular piece of software; I do too. That's why I have another piece of software to advertise, just so I don't have to advertise the init. So why make it? Because I want it, and I'm on Gentoo, so I have the skills to switch out the current init (OpenRC). It's for me alone, and maybe for people who like it.
- Crysstalis 4y ago
  >I also want it to not take over my machine like systemd did. You will not have this without changing the kernel itself, /sbin/init needs to run as the root process of all other processes on the machine. By design, any implementation has to "take over the machine" in some sense. >I want to be able to compose individual daemons, not have the init subsume them. I don't understand why anyone says this, they are individual daemons in systemd. If you are talking about just the init itself, there is no benefit to splitting that into individual daemons. The most complex part is the probably the code in between fork() and exec() that spawns services, this has to be done in all the same place, because this is the part that is actually going to be setting up the rest of the daemons. Also it is complex to write because it has to be async-signal-safe. Everything else is just configuration around that part. >Poettering used politics to limit user choice. This is a really nonsense statement. He didn't limit anything or use politics, you can just not use his programs. It's incredibly easy to do that in fact. The "user choice" you have is the same as it always was, it's exactly what allows you to develop your own init or use Gentoo. If you ask me, most of the drama (with both systemd and pulseaudio) was because of botched distro rollouts, not politics. >I'm also not going to advertise and push Ur like systemd was. I'm going to advertise my build system, and Ur will be bundled with it, and I will help people use Ur, but I'm not going to push Ur because an init and supervision system is just too central to Linux machines to push it on people. I don't know what it is about engineers that makes them reluctant to promote their own work. I see this so often. If you work is good, please advertise and promote it. Please encourage people to use it. This is a forum about start-ups, that's what you do here. Users deserve to have good solutions and they deserve to have those promoted far and wide if it can help a lot of people. Don't worry about the comments from the peanut gallery. If you are confident that your work is good and useful, you can ignore the haters. Your users will know that it's doing something good for them and that's all that matters. It does not matter that anything is "central to a Linux machine" or not, good products are good for whatever place they fit in. Don't take this to mean you should promote bad and unproven work, your seed users should be able to tell you what's good and what isn't. >But if your distro changes the init, you're in for a long period of relearning and retooling everything. No, this isn't true. You could just make the init backwards compatible, which systemd actually is with sysvinit scripts. Actually, to prevent any amount of friction you can make yours backwards compatible with systemd.

by atoav 4y ago

bayindirh 4y ago

The issue not being forced only. It's how valid criticisms are just tossed out of the window and systemd is developed as is because "the lead developer and the team knew way better than the collection wisdom accumulated over the years". Funny thing is they have bitten by the bugs they claimed they're immune to, so they had to apply these principles like they're first adopters of these. I've voiced my criticisms over the years, yet I still use systemd. I don't like it, but I don't hate it either. I want to share them, but, It'll be long, so I'll just leave links to my own comments: 1- https://news.ycombinator.com/item?id=27651567 https://news.ycombinator.com/item?id=27651567 - A general criticism comment. 2- https://news.ycombinator.com/item?id=25616356 https://news.ycombinator.com/item?id=25616356 - A general criticism thread. 3- https://news.ycombinator.com/item?id=29672248 https://news.ycombinator.com/item?id=29672248 - About bugs in systemd. At the end of the day, if a critical component of an OS is being replaced, people at least want their concerns addressed. Want to have some conversation. Being yelled at literally and proverbially as forcing adoption of said software is bound to create some backlash. *Edit:* Initial text contained in this reply misunderstood the parent. Corrected, clarified, softened and re-written. Sorry about that.

WastingMyTime89 4y ago
- bayindirh 4y ago
  I was working literally underground with no internet connection when these events were happening, so I was never able to observe them real time. I’m not a person who whines on the net and just does nothing. If I was aware, I would be linking issue tracker ids.
  - Crysstalis 4y ago
    Then you may have also missed the various responses to those criticisms and things that were done to address them.
    - bayindirh 4y ago
      It's indeed possible, but during discussions (here and elsewhere) nobody have said something in the line of "Hey, you're telling this, but the idea behind this is documented there, go take a look". Instead I got angry answers about how systemd is much better than what came before it, and I'm telling these things because I'm used to old ways and just resisting change. The mailing lists I read also had the same echo chambers of finger pointing and blaming. Heck, I even read Lennart's blog w/o knowing the page is his, and thinking "He has a arrogant team, what kind of language is that?" Moreover, do I need to remind that one of the systemd developers has been suspended from contributing to kernel [0]? Does this signal a project which is giving due credit to criticisms directed to it? Again in the same article there a link to a mail message from Ingo Molnar [1], which openly says that systemd refuses to use existing infrastructure and does things their way, w/o listening the kernel developers' advice. As you know, kernel is not an important component of an OS, so a couple of devs can just ignore the maintainers of the platform which underpins their system, and creates the foundation for their software to exist. [0]: https://www.networkworld.com/article/2175826/linus-torvalds-suspends-key-linux-developer.html https://www.networkworld.com/article/2175826/linus-torvalds-... [1]: https://lkml.iu.edu/hypermail/linux/kernel/1404.0/01727.html https://lkml.iu.edu/hypermail/linux/kernel/1404.0/01727.html

origin_path 4y ago

boffinAudio 4y ago

>The same greybeard friend of mine who still complains on systemd happily adopted pipewire. Pipewire is not from Poettering. He did Pulseaudio, which is so terrible it inspired the folks to write Pipewire to replace it.

AnIdiotOnTheNet 4y ago
People keep talking about how terrible Pulse is for them, but my decades of experience using Linux desktop recalls that for whatever faults Pulse might have it was a huge improvement over the shitshow that was Linux audio before it.
- AshamedCaptain 4y ago
  I adopted Pulseaudio back when it was still called Polypaudio, so I am aware of the problems of Linux audio before it, but PA was just yet another sound server in a world that was already full of them and didn't really bring anything to the table. Linux audio world is exactly as much of a shitshow today as it was before PA. Lennart didn't even envision people writing the PA API directly, but rather going through gstreamer (then a fancy new thing) or the like. Pulseaudio got popular and then became "irreplaceable" because it started playing a role that would have been played by HAL back in those days; i.e. setting up audio policy (routing, etc) whenever the kernel would fail at it. I was very critic of Pulseaudio, a sound server, incorporating this role, and argued that this complexity would make this project impossible to replace with a newer sound server when it inevitably came. I was proven wrong, albeit in my defense the replacement Pipewire did require a shitton of effort, and PA was becoming toxic in the meanwhile (see the Bluetooth codecs drama). Pulseaudio's "big" technicaly improvement ("glitch-free" audio, aka interrupt-less, long buffers), and without a doubt its major cause of annoyances to users (since it exercised a lot of rarely used APIs), has not been adopted by Pipewire (which goes back to "low latency" + lots of interrupts) or any other sound server for the matter. (And Pipewire still manages to have better performance...)
  - Crysstalis 4y ago
    >but PA was just yet another sound server in a world that was already full of them and didn't really bring anything to the table I seem to remember that the main thing it did was bring "being maintained" to the table, because esound was unmaintained and stagnating. I still find this to be really ridiculous that people complain about supposed "hostile takeovers" in open source when, for a lot of categories of project, there are still somewhere between zero and one alternatives for any given thing. All you have to do to become the top dog is make something that does the bare minimum and doesn't crash, and has like, one person to triage bugs. >PA was becoming toxic in the meanwhile (see the Bluetooth codecs drama). I also still find this to be really ridiculous when people call maintainers "toxic" for being slow or for rejecting patches. Every open source project does that. >has not been adopted by Pipewire Actually it has, Pipewire implements the pulse protocol for backwards compatibility. The pipewire developers are also still encouraging developers to use it because it is a lot nicer to use than the pipewire API.

account42 4y ago

> The same greybeard friend of mine who still complains on systemd happily adopted pipewire. Why? Because he saw a clear benefit in doing so and nobody forced this onto him. I still use OpenRC + ALSA (with apulse for those programs that shit on backwards compatibility) and I too am looking at PipeWire. Beyond the not being forced aspect and actually adding something that is useful (to me), PipeWire also seems to take much more care about working with existing programs/interfaces rather then wanting to get them on the shiny new API.

gavinhoward 4y ago

> The saddest thing about the whole affair is that it has a stifeling effect on new devs. Who would dare to write another systemd after that? Certainly not me. Me! I want systemd capabilities in a small package. I also want it to not take over my machine like systemd did. I want to be able to compose individual daemons, not have the init subsume them. I do like the idea of supervision systems, though, and I am glad systemd popularized (not invented) them. So since the alternatives are quite...user unfriendly (s6), I'm making my own. It's called Ur (universal runner, also after the ancient city of Ur), and I'm building the dependency management for it, which will also go into a build system. So why wasn't this affair stifling to me? It's because I see why people got angry: Poettering used politics to limit user choice. User choice has been a theme of Linux use for decades, and people were not happy about it. I'm not going to limit user choice, so I'm not worried about angering people in that way. I'm also not going to advertise and push Ur like systemd was. I'm going to advertise my build system, and Ur will be bundled with it, and I will help people use Ur, but I'm not going to push Ur because an init and supervision system is just too central to Linux machines to push it on people. Actually, the dichotomy between build systems and init systems is a good example. If a distro choose a build system to base their package manager off of, and you are on that distro when they make the change, their choice does not affect your use of another build system, unless your build system does not come installed by default, in which case, you install it and then continue as normal. But if your distro changes the init, you're in for a long period of relearning and retooling everything. I think Poettering pushed systemd through politics because he wanted to have a popular piece of software, and that's only the real way to do it because distros adopt init systems, not users. I don't blame him for wanting a popular piece of software; I do too. That's why I have another piece of software to advertise, just so I don't have to advertise the init. So why make it? Because I want it, and I'm on Gentoo, so I have the skills to switch out the current init (OpenRC). It's for me alone, and maybe for people who like it.

Crysstalis 4y ago
>I also want it to not take over my machine like systemd did. You will not have this without changing the kernel itself, /sbin/init needs to run as the root process of all other processes on the machine. By design, any implementation has to "take over the machine" in some sense. >I want to be able to compose individual daemons, not have the init subsume them. I don't understand why anyone says this, they are individual daemons in systemd. If you are talking about just the init itself, there is no benefit to splitting that into individual daemons. The most complex part is the probably the code in between fork() and exec() that spawns services, this has to be done in all the same place, because this is the part that is actually going to be setting up the rest of the daemons. Also it is complex to write because it has to be async-signal-safe. Everything else is just configuration around that part. >Poettering used politics to limit user choice. This is a really nonsense statement. He didn't limit anything or use politics, you can just not use his programs. It's incredibly easy to do that in fact. The "user choice" you have is the same as it always was, it's exactly what allows you to develop your own init or use Gentoo. If you ask me, most of the drama (with both systemd and pulseaudio) was because of botched distro rollouts, not politics. >I'm also not going to advertise and push Ur like systemd was. I'm going to advertise my build system, and Ur will be bundled with it, and I will help people use Ur, but I'm not going to push Ur because an init and supervision system is just too central to Linux machines to push it on people. I don't know what it is about engineers that makes them reluctant to promote their own work. I see this so often. If you work is good, please advertise and promote it. Please encourage people to use it. This is a forum about start-ups, that's what you do here. Users deserve to have good solutions and they deserve to have those promoted far and wide if it can help a lot of people. Don't worry about the comments from the peanut gallery. If you are confident that your work is good and useful, you can ignore the haters. Your users will know that it's doing something good for them and that's all that matters. It does not matter that anything is "central to a Linux machine" or not, good products are good for whatever place they fit in. Don't take this to mean you should promote bad and unproven work, your seed users should be able to tell you what's good and what isn't. >But if your distro changes the init, you're in for a long period of relearning and retooling everything. No, this isn't true. You could just make the init backwards compatible, which systemd actually is with sysvinit scripts. Actually, to prevent any amount of friction you can make yours backwards compatible with systemd.