[chmln]

That's definitely true as well - some responses by poettering in systemd issues in particular are unnecessarily condescending and very unprofessional.

Also, while systemd and pulseaudio were heavily pushed by many distros, alsa was and still is an option and systemd alternatives exist for those who care that much.

[resfirestar]

Compared to systemd I feel like most of the issues with pulseaudio circa 2009 were distro or application specific, like the current situation with Wayland. You could run Ubuntu and have PA eat all your RAM and not even work, but switch to Fedora and not have so many problems (performance was still unacceptable on the toaster I used back then, though). Whereas if you dislike how systemd works and Poettering’s often narrow minded approach, using a different systemd based distro probably won’t change your mind.

[AsyncAwait]

> using a different systemd based distro probably won’t change your mind

There's plenty of non-systemd based distros. Yes, they're way less popular, but that's because systemd works and does wonders if you know how to use it, compared to that mess of bash scripts inconsistent in quality and across distro implementations that we had before, so users and developers find value in it.

systemd has certainly made my job as a user, sysadmin and developer a whole lot more pleasant.

If you prefer OpenRC or s6, there's distros for you out there. I won't bother supporting them, but you're free to use them.

Granted, you get outcomes such as [1], but if you're fine with that, the choice is there.

1 - https://gitlab.com/postmarketOS/pmaports/-/issues/719

[resfirestar]

Sorry if I wasn’t clear - I was saying that people who are unsatisfied with systemd vs earlier or current alternatives are usually better off using a distro based on openrc or runit or s6, as you suggest. Not that there is any lack of good alternatives. The point was that the most common complaints about systemd are indeed issues people have with systemd and not with poor packaging or something. This contrasts with pulseaudio where most of the early criticism was caused more by distros doing a poor job with it than the users having fundamental issues with the design of pulseaudio.

What does that pinephone issue have to do with systemd? Sounds more like a bootloader issue (or if not, the kernel lacking a feature) to me.

[AsyncAwait]

> The point was that the most common complaints about systemd are indeed issues people have with systemd and not with poor packaging or something. This contrasts with pulseaudio where most of the early criticism was caused more by distros doing a poor job with it than the users having fundamental issues with the design of pulseaudio.

Fair. I think many would contest that and say they indeed had issues with PulseAudio itself, not because you're wrong, but because the understanding as to why PA sucked for many is just not there and never was. I feel systemd is in a similar position. It's not poor distro packaging, bur it is rather a fundamental misunderstanding of what systemd even is.

From most of the complaints I've heard, they fundamentally misunderstand what systemd is even trying to do, there are certainly better ways of doing them, but I feel the debate is not even at the level where there's understanding of systemd and critiquing it.

In a sense, OpenRC is not even a direct competitor.

> What does that pinephone issue have to do with systemd? Sounds more like a bootloader issue (or if not, the kernel lacking a feature) to me.

It's not bootloader related or kernel related. There are other distros for the PinePhone, like Mobian, where suspend works properly. The issue is Alpine's init system can't do the job. systemd can.

[ComputerGuru]

The biggest problem with all the discussions is that 90% of the people don’t know what they are talking about. A lot of people (and I don’t mean you specifically) treat alsa and PulseAudio as interchangeable but they’re at different levels of the stack. Most PulseAudio installs run on top of Alsa and it’s almost always possible to skip the PA layer and output to Alsa directly so long as the applications were built against libasound as well (and you configure PA not to automatically open your Alsa device).