Come up with a commercial solution to a simple problem. Ex: file sharing or password management. Make it slow, insecure, privacy violating, lose people's data. Make millions, become a hero.
(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.
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?
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?
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.
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.
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.
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.
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.
Seems like software history revisionism to me.
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.
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.
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.
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?
If you care about real world usage, PA set us back years when Ubuntu made it default.
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.
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.
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.
My only real big pet peeve with Systemd is the documentation is somewhat lacking..., like it's all there in the manual, but its laid out poorly and makes it hard to understand. The interaction between unit files and dependencies is also quite convoluted when you start digging into how things are ordered. There's a ton of unit file options that enable weird conditional behavior. The moment you need to start comprehending the difference between Wants vs. Requires and not hooking into running when multi-user.target is reached (the most common situation) you are in for a world of trial-by-error testing.
Systemd is great for starting simple background services on simple desktop and server environments. It becomes a real pain in the ass once you get beyond that.
And the worst is that the tooling to test is very limited ( non-existent). I had a problem with conflicting/circular ndependencies ( my service had to be launched before networking but after dbus, which is just impossible because dbus needs networking itself), which worked 9 times out of 10. It was nearly impossible to debug, i had to use the graph tool that shows you visually how much time each service took to start, and completely by chance i noticed that dbus started after networking, which led me to look into it.
Thing is, it also forcibly changed a bunch of things by introducing defaults that were not at all what people expected. They might have been better overall, but it still caused some nasty surprises.
Let me try and explain a bit more concretely -
An easy example (not a hypothetical one, btw): if you have a physical server with multiple hard drives and one of them doesn't start, old school unix would boot everything it -could- boot anyway. SystemD changed that behaviour to "if a filesystem doesn't come up, and you don't set an option to tell systemd it's ok if that doesn't happen, don't finish booting".
Now, imagine you're somebody who has a physical server somewhere that has a big cache disk that you use a cheap drive for because if it fails, well, you've lost some cache space. Now imagine your server used to run a pre-systemd setup, and when you upgraded it to a systemd using version of the same distro you left all your settings as-is because everything seemed to be working fine. Now ... imagine that drive dies during a reboot ... and so the server doesn't finish booting, and so you can't even ssh in to it to figure out what's going on, and the only way to figure it out is to get physically in front of the console.
If that server is four hours' drive away, you might not be very impressed.
I still, overall, think systemd is pretty nice. But while some of the people annoyed with it are annoyed with it on a purely aesthetic/principle sort of basis, there are definitely some decisions the authors made that caused -very- surprising results for people who had been running servers for years already, and some of the dislike being thrown around is very much understandable.
I still have to find a way to let it digest sshfs filesystems that may hang at boot without stopping the whole boot process.
(I don't particularly blame him for the specific non-booting bug, but I do blame him for the arrogance. Everyone makes mistakes, but most people learn from them and develop a bit of humility. Pottering continues to break people's computers every couple of years)
- Gnome started to depend on systemd features. Now non-systemd systems become second class citizens.
- You used to be able to freely swap out window managers, taskbars, and so on, because everything was working with common standards. In the modern world, everything is integrated in your wayland compositor, and if you want to change the way window decorations look, you will also have to change everything else. Systemd is similar, it wants to take over so many responsibilities (task scheduling, DNS, session management), and if you want to swap out one part it is going to be difficult.
- Pulseaudio, NetworkManager, Polkit: Written in the same spirit, in part from the same people. Work great if everything works as expected, if they break it is a nightmare to figure out why. But code depends on them, so they become de facto standard on desktop linux.
My Linux workstation and servers are not something I want to tinker with, I want solidity and stability and a fragmented user space ecosystem is not the solution.
If I want the stabilty and flexibility of Linux (the kernel) and the GNU command line tools, and the flexibility to choose a UX paradigm that I prefer and visuals that I like, I go to desktop Linux. In that sense, choice is the USP of linux (linux as in: desktop distribution). If I loose the flexibilty, I go back to Windows or Mac. Opinionated ("not fragmented") systems like Gnome only work if you're fully on board with their choices. If not, then there is really no benefit for me over just sticking with windows.
Now, on a server the situation is of course different, and stability is paramount. I like for example that services are declarative and not imperative in systemd. But on a desktop, I don't really care.
Again, no. You call it choice, I call it chaos, it was anarchy, and that's the default state for any loosely-coupled systems. There is no manifesto, no underlying philosophy that decided that yes, Linux is about choice. Don't conflate lack of organisation with choice.
Linux has always been about creating a libre UNIX-like kernel for x86 processors. And converging toward the same set of libre techonologies isn't against the Linux spirit.
I still don't understand why people keep harping on about choice. I've used Linux full time since 2001, and the anarchy has just made a libre desktop an utopia because everyone wants every software to support every single option, with no understanding that the number of bugs scales exponentially with the number of choices.
Because they don't want the choices other people made for them.
So everyone who uses or develops alternative init systems like runit and openrc and alternative DEs like KDE and package managers like apk and pacman should just stop and work on and use systemd, GNOME, and flatpak instead because that is the One True Way of using Linux on desktop?
Quite a power trip attitude I'd say. I can't imagine why I would use Linux if choices I don't agree with were shoved down my throat.
Ok I will give that a go.
That reminds me when will Wayland be able to support disparate displays say one big display on 4k with 30 bit colour and two others on QHD and 24 bit colour?
This is not about the problems systemd solves, but how they solve them and how they act while solving them.
Linux itself was mostly unusable when it first started. And a kernel is even more important.
There's a distinction between labeling it as a hobby project and something ready for production.
Linux started as a hobby OS, and being buggy is OK in that regard.
systemd is way more buggy than it should when it's deemed production ready. This is my point.
I'm using Linux for a long time, and I know the meanings of unstable, buggy and experimental; as well as production ready.
I don't hate or I'm not against systemd, I'm against the attitude behind it.
Systemd is exceptionally voluminous, fast moving, feature-laden (which is part of why it is so exciting to so many people), and buggy.
I for one am very grateful for Lennart/Red Hat's vast contributions. Leading modern Linux.
Systemd broke my ability to login, once. That was fun.
Now yes, it gives you more functionality, but it was a pain until it got there. Systemd was just Pulseaudio all over again (except now in init, so if it breaks your whole system can't boot).
Now, yes. initd is jurassic. Systemd got stable eventually and has gone beyond it. And this is more complicated than it seems. But still, it's the attitude that made things hard.
Not really
> For versions 3.28 and earlier, the GNOME desktop environment contained components that required systemd-logind[5] (among them, notably, its display manager, GDM). However, as of version 3.30, Gentoo's packaging of GNOME allows it to work once again with sysvinit + OpenRC as the init system
It became a question of "are you going to have GNOME 3.8 or later, or not"
I'm too tired to write them all over again, but here's a rundown, from me.