5 ms·

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

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.

dschuetz 5y ago
> (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?
- sjansen 5y ago
  > 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?
- trabant00 5y ago
  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.
- esarbe 5y ago
  > 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 https://github.com/systemd/systemd/graphs/contributors [1] https://www.linuxplumbersconf.org/ https://www.linuxplumbersconf.org/
lmm 5y ago
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.
- kaba0 5y ago
  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.
- trabant00 5y ago
  > 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.
- zodiakzz 5y ago
  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.
- rektide 5y ago
  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.
guywhocodes 5y ago
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.
- jraph 5y ago
  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 5y ago
  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.
- esarbe 5y ago
  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.
esarbe 5y ago
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 5y ago

> (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?

sjansen 5y ago
> 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?
trabant00 5y ago
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.
esarbe 5y ago
> 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 https://github.com/systemd/systemd/graphs/contributors [1] https://www.linuxplumbersconf.org/ https://www.linuxplumbersconf.org/

lmm 5y ago

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.

kaba0 5y ago
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.
trabant00 5y ago
> 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.
zodiakzz 5y ago
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.
rektide 5y ago
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.

guywhocodes 5y ago

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.

jraph 5y ago
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 5y ago
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.
esarbe 5y ago
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.

esarbe 5y ago

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.