[sjansen]

There is so much truth to what you say. I used Linux exclusively from January 2000 until April 2012. A lot has changed in that time, but out of all the changes the three I'm most thankful for are:

(1) Xorg replacing XFree86 and making video "just work"

(2) Pulse Audio replacing OSS and making audio "just work"

(3) systemd replacing the dog's breakfast of scripting madness each distro built from scratch instead of collaborating

It amazes me that the same person was responsible for leading 2 of the 3 changes.

I for one welcome an increasingly unified operating system core, instead of the random competing and overlapping components we used to have. Sure they worked 97% of the time, but the other 3% when they didn't could be a royal PITA. Especially when two waring components wasted time pointing blame at each other instead of focusing on solving end user issues.

[guywhocodes]

I don't know about (2). Alsa "just worked" when pulse audio was released and PA did not "just work" for like 8 years after the first release.

Seems like software history revisionism to me.

[esarbe]

While PA in the beginning certainly wasn't manna from heaven, it still was a godsend; pulseaudio exposed all the inconsistencies, flaws and straight out bugs in the alsa driver implementations.

The reason so many people had issues with PA was not PA but the brokenness of the underlying system that PA exposed for the first time when trying to use all these drivers in a systematic way and build functionality on top of it. It took years of fixing all the drivers and PA - unfortunately - got a lot of undeserved flak.

PA is the reason that Linux has a halfway decent audio subsystem, being able to deal with all the modern devices; thank you, PA devs.

I find it hilarious that people are festive about PA being replaced by Pipewire - if PA hadn't paved the way, the Linux driver landscape would not be in such a good shape today and Pipewire would 'fail' in exactly the same way that PA 'failed.

[guywhocodes]

I'm grateful we got a reasonable system out of PA eventually but damn it took time and I agree it is today better than what we had with ALSA. But as I remember it audio sucked with ALSA until it didn't and then we had about two good years of audio before PA came about. Then we had 8~ years of crap again and yes a lot of it was definitely due to really bad drivers and masked inconsistencies in the past.

That's not my point tho, my point is that PA didn't sweep in and save us, in fact it at first pushed us back A LOT. And claiming otherwise is a disservice to ourselves when we consider additional radical change. Such as Pipewire and and Wayland.

[esarbe]

> in fact it at first pushed us back A LOT

That argument I don't quite follow. Would you consider rephrasing it? My question is; how did PA set back Linux sound if it did expose all those flaws in the audio driver in the first place?

[guywhocodes]

Not everyone is a power user. At this time I was in university and Linux went from a reasonable choice to an unreasonable due to sound not working again.

If you care about real world usage, PA set us back years when Ubuntu made it default.

[esarbe]

> Linux went from a reasonable choice to an unreasonable due to sound not working again.

But that's the crux, isn't it? Linux sound was not not-working because of PA. Linux sound was not working because it was fundamentally broken with drivers that had wildly different behaviors. Everyone was hacking around broken drivers all the time, I distinctly remember how I had to recompile the kernel back then to get some custom-fixes for my setup in because the driver was so kaput.

Only with the introduction of PA was there finally a way to test and evaluate the drivers in a systematic fashion.

So, in short, my point is this; any software that - in this broken state of Linux audio - tried to introduce a software that made available the features the drivers proclaimed would have run into exactly the same problem as PA. Because PA didn't introduce the problem, PA made it visible.

It's like blaming the doctor for diagnosing the illness.

So, while your experience was that sound suddenly wasn't working anymore because Ubuntu configured the default setup to use PA, for lots of people that sound never worked this was fine - because their drivers weren't broken.

[rektide]

Alsa is fine, if you needed absolutely no features whatsoever. This weird glamorization of alsa as sufficient or at all adequate feels like itcs true, for only rhe most basic basic basic of users.

Anyone who has ever plugged in a usb headset or connected a bluetooth headset or plugged an hdmi output into their laptop knows the value of pulseaudio. It's role as a modular, pluggable, controllable audio intermediary layer is invaluable: it has a great control panel that lets you say, ok app, start sending your output somewhere else now. Even if you only have one soundcard ever: it let you adjust per app volume! Utterly basic need. To propose that users ought have been fine without these basic capabilities is insanity. Alsa was insanity.

Alsa was a dead, impotent, lifeless husk. It let apps output audio to a device, if you knew to try various hardcoded strings like hw:1.0, hw:2.0, hw:2.1. But that was all alsa was good for. One couldnt open a control panel & change the volume of an app. One couldnt send an app to a new output (bluetooth, hdmi, usb audio). Trying to get a sound card to pick between various output modes, for optical output for example, was hell: i spent literally days getting optical audio going. Everything required careful scripting in a shitty awful .alsarc dsl to do anything good.

Pulseaudio made it all much easier.

I have no clue why anyone would valorize alsa. It was incredible finnicky, super hard to configure. It feels like certain sects just want to spread poison against linux & freedesktop. There have always been reactive, outraged camps. Eternally dismayed at progress, at better. I just can't take seriously the thought that alsa was an appropriate & adequate tool for end users, in any way though. It's ridiculous: nothing worked without careful careful delicate scripting & trial by error, and the system was utterly static, unable to respond to change. Alsa was not an end user system, unlike pulseaudio: it was an api for software. Pulseaudio changed the game. I am so tired lf hearing pretenses that alsa was ok or enough. It never was amything remotely adequate. The nonsense hate has to die. Progress was required. I saw it work flawlessly on many systems even in the earliest days. It wasn't & still usually isn't required. I don't see what anyone could be asking for. It just seems like a need to sow doubt.

[jraph]

Alsa just worked but had limitations. Some apps grabbed sound and you could not play sounds from other apps. Often, one app could play sound at a time. It depended on whether your sound card could handle several streams IIRC. Each major desktop environment had its own sound server to work around these limitations (KDE's aRts, Gnome's ESD).

PulseAudio let us have a common stack instead. There were bugs (PulseAudio was probably a bit buggy at first, and also hit audio driver bugs because of the new ways of using them). The transition was rough and PulseAudio is not perfect too but is it there for reasons and solves many issues.

Now it is being replaced by PipeWire, probably for the best (more efficient, can replace JACK too, making sound management much easier on Linux), but PipeWire leverages experience from PulseAudio.

I lived the transition to PulseAudio and it went well for me and probably a lot (the majority?) of people. Some things could probably have been handled better, especially the (too early?) transition. I think PulseAudio still is/was a good thing.

[RedShift1]

Consider me in the same camp. When I set up audio on my linux pc back in the day, the only thing I had to do was enable the alsa daemon to restore volume levels at boot and everything just worked. Then later Pulsaudio was kinda forced on me and I didn't (and still don't) understand why it was needed, it was something about allow multiple applications outputting audio at the same time but that worked just fine with alsa? Plus it didn't work well: under load audio would stutter which was extremely annoying as I listened to music quite frequently while working on my computer, a problem I did not have with alsa. So there I was with a shiny AMD Athlon 64 3500+ that couldn't even play mp3's straight.

[lmm]

The thing is, you used to be able to fix something and have it stay fixed. You used to be able to find a config that worked - which, sure, might have required some manual experimentation and customization - but then you could back it up and keep it.

Maybe pulseaudio and systemd only breaks 2% of the time rather than 3% of the time. But when they do break, you can't understand what's happened and you can't fix them, and even if they worked yesterday they won't necessarily work today. If that was tradeoff I was happy with I'd use windows or OSX.

[trabant00]

> you used to be able to fix something and have it stay fixed

No, I used to patch bash scripts, patch the deb package, deploy to prod, then have to do it all over again when the init script changed upstream in the distribution. Now I just have my configuration management change the options I need in the unit file and never touch it again, so now I sleep while unattended-upgrades works for me.

[rektide]

No idea what you are talking about. Pulseaudio nor systemd have wild crazy "it just stopped running" issues, like you suggest.

If something critical launched by your init system isnt coming up, I'd way way rather be using systemd. There's know wwys to inspect, check out what ran, what didnt, see what dependencies are failing. Check the common logging system. In the dark old days it was a nightmare of different daemons, each with their own custom init scripts, & little common reporting. Every problem was unique & required unique diagnosis.

I dont get what the complaints are. Things work great now. There's great diagnostic tools. Most of them with json/machine readible output. Distros sometimes do break various daemons but systemd and pulseaudio are pretty much bulletproof, and if they worked yesterday, i absolutely have faoth they'll work today. I detest so much that this kind of casual easy convenient Fear Uncertainty g Doubt shade throwing persists, that we so casually malign while making no assertions that could be refuted. There's a spectre of doubt that sabotages the good, that seeds disbelief, and it's never justified, never backed up by anything concrete or real or debateable: it's all just this haunting image that it's not going to work. It's seditious.

[kaba0]

That’s no good reason to ditch a superior solution. A modern combustion engine is pretty much impossible to fix with your ordinary tooling/knowledge, but it doesn’t make me want to use some old, weak/inefficient one instead.

Also, I could not do anything with a bug inside firefox, the kernel and a litany of other complex programs (mind that they are complex due to essential complexity) so I don’t see system booting an exception to that.

[zodiakzz]

Can you elaborate? Systemd also uses text based config files... how did you calculate the "breaks" percentage? I've been using Fedora with Systemd since a few years now. Nothing that broke was Systemd's fault in any way.

[esarbe]

Yeah. Lennart Poettering is one of the unsung heros of modern Linux - and the most maligned one, in my opinion.

While I get that some people are uncomfortable with breaking with traditions, I absolutely do not get all the hostility directed towards this craftsman programmer.

[dschuetz]

> (3) systemd replacing the dog's breakfast of scripting madness each distro built from scratch instead of collaborating

Which goes completely against what Linux stands for - collaboration. The "scripting madness" as you call it was actually completely transparent - if the scripting was bad, you were free to fix it. But now you have to issue a bug report when systemd does something stupid and it's not even your fault to Lennart and his gang only to get it dismissed with "no a bug, won't fix".

Also, Pulse Audio only "just works" because the distribution maintainers do that for you. It's still a stinking pile of "don't no how, but it just works".

Keep telling yourself that Lennart does a great job. Stockholm syndrom much?

[trabant00]

Administering hundreds of linux servers is my job and has been for the past 20 years. Fixing bash scripts left and right was a nightmare. I love bash, but not for this. The right tool for the job and all that. Systemd made my job la lot easier. So yes, I do think Lennart does a great job.

[sjansen]

> Stockholm syndrom much?

Yes, but not how you'd imagine. I spent years as a hard core Linux fanboy. Advocating for Linux. Declaring Linux the future when many thought Windows would obviously eliminate all competition. Volunteering for install fests and wrestling various distros onto unwilling hardware.

I also spent 9 years teaching and writing training materials for RHEL, SUSE, & Ubuntu. As a result I dug deeper into core system details than most. (How many remember SUSE's attempt to achieve faster boot times by introducing an optional alternative to normal init that dynamically generated a makefile to execute init scripts in parallel? That was one of many strange rabbit holes I got to explore.)

Thankfully, I've gotten over it. I still prefer to keep Linux near the center of my career, but I've been able to adapt as "the cloud" has rendered my old school sysadmin skills less relevant. Occasionally I call on them to rescue a pet, but today I find "herding cattle" and going "serverless" much more enjoyable.

And you?

[esarbe]

> Which goes completely against what Linux stands for - collaboration.

Have a look at the contributor stats[0] for systemd and then repeat that with a straight face.

> Lennart and his gang

Also known as the Linux Plumbers[1]. You know, the guys that actually tie everything together and that enjoy the well-deserved trust of most distributions and users.

> dismissed with "no a bug, won't fix".

Usually with very good technical reasons.

> The "scripting madness" as you call it was actually completely transparent - if the scripting was bad, you were free to fix it.

You're still free to fix it; systemd is open-source.

[0] https://github.com/systemd/systemd/graphs/contributors

[1] https://www.linuxplumbersconf.org/