I totally agree. I used to hate systemd for breaking the traditional Unix philosophy, but the reality is that a tight init and service-tracking integration tool really was required. I work with and appreciate systemd every day now. It certainly didn’t make things simplier and easier to debug, but it goes a long way towards making a Linux system predictable and consistent.
Poettering can go fuck himself though - and for PulseAudio too. I suspect half of the hate systemd attracted over the years was really because of this idiot.
Linux audio has been a cluster^$%< of epic proportions since the mid 1990s. At least you can make single application systems work well these days, but Windows has really whipped the llamas ass on the audio front for 30+ years now, in terms of “it just works” user experience - without being hyper-draconian on the application ecosystem.
It definitely depends on what you are trying to get out of it.
I’ll grant: low lag audio performance in Windows is… dismal. Which is why everyone had conference call lag adjustment issues in 2020, “go ahead”, “no you go ahead”, “ok” - both start talking simultaneously again… It seems better these days, I’m sure that’s at least in part due to training of the conference participants, but maybe they have been working on getting the lag down without too many dropout / stutters.
We have a bespoke low lag audio system that was specifically implemented in Linux even though we put the GUI in Windows because of those lag / stutter issues, years back the audio was done on a dedicated DSP chip, but a Core i7 is more than up to the task on Linux these days.
The Linux audio pains I refer to were: A) audio just doesn’t work at all, and B) audio works, until you start to try to use two audio applications simultaneously - then they start to mess each other up. Both of those were better in Windows long before Linux came up to speed. But a lot of how Windows audio gets acceptable performance is big laggy buffers.
Is it really breaking it? As far as I’m aware, it’s more like gnu. It has components and you can select what you use (here meaning distros and packagers).
People mistake this for a monolith because it’s all named systemd-thing. Integration, like you said, was and is needed. But what if all those separate utilities and services are actually disconnected and speak some protocol different to pipe? Does it make it less unixy?
And poettering is an absolute good guy here. Pulseaudio wasn’t perfect, but did it improve things compared to what was there before? Sure it did. Even now, pulesaudio protocol is used within pipewire and it works just fine.
Perfect is the enemy of good. And while all these tools might not be perfect, they are the best in the Linux world.
Agreed. But he’s also an abrasive know-it-all. A modicum of social skills and respect goes a long way towards making others accept your pet projects.
pulesaudio protocol is used within pipewire and it works just fine.
I wasn’t talking about the protocol, I was talking about the implementation: PulseAudio is a crashy, unstable POS. I can’t count the number of hours this turd made me waste, until PipeWire came along.
Pulseaudio was introduced in 2004. How come it took almost 20y for it to be replaced if it was that bad?
Implementation, being what it is, improved the situation compared to alsa and other things before it. Again, while not perfect it made things better for everyone.
It’s funny that this is a thing attributed to poettering as bad since things before were way worse… why not throw Sticks and stones at those people?
I really don’t get it.
And all of these things are optional. The fact that distro people and companies select them is because they solve real world problems.
things before were way worse… why not throw Sticks and stones at those people?
My earliest memories of Linux audio were in Slackware in the mid 90s, reading and re-reading the HOWTO that started off with a bunch of attitude about how real computer users don’t need audio, but we can do it anyway “so, if you must hear Biff bark…” and then a bunch of very unhelpful things to try following that never ever worked on any system I ever tried to use them on. Diverse systems that, of course, all played audio through Windows flawlessly.
I always assumed that Poettering is an arse to people because of the hate he got for systemd. I imagine it’s hard to see the best in people when there’s a crowd of haters everywhere you go. Though I have no idea what he was like beforehand.
Everybody who is hated and popular gets death threats. Hell, even the nicest actors get death threats.
They are easy to write and send, and there’s 0.01% of the population that is mentally unstable enough to actually do so. You and I don’t get death threats because we aren’t popular enough.
Nah bugger that. Famous actors are known by a vast majority of people. It is not normal for open source programmers to receive abuse to the level of death threats. That only happens when you get the attention of kiwi farms types.
I feel that generally, when the issue is that the person is an arse, then the complaints are often not about the software. You might see people campaigning to boicot the software out of spite, but they won’t give you a technical reason, other than them not wanting the creator to get any credit for it.
When the complaints are about discrepancies in the way the software is designed (like it was with systemd), there’s no reason to expect the person to be an arse. Though him not being an arse does not make the criticism about his software invalid… in the same way as him being an arse would not have made the software technically worthless. Don’t fall for the ad-hominem.
Agreed. But he’s also an abrasive know-it-all. A modicum of social skills and respect goes a long way towards making others accept your pet projects.
This isn’t what I get when reading bug reports he interacts in. Yeah, sometimes he asks if something can’t be done another way – but he seems also very open to new ideas. I rather think that this opinion of him is very selective, there are cases where he comes off as smug, but I never got the impression this is the majority of cases.
I wasn’t talking about the protocol, I was talking about the implementation: PulseAudio is a crashy, unstable POS. I can’t count the number of hours this turd made me waste, until PipeWire came along.
PipeWire for audio couldn’t exist nowadays without PulseAudio though, in fact it was originally created as “PulseAudio for Video”; Pulse exposed a lot of bugs in the lower levels of the Linux audio stack. And I do agree that PipeWire is better than PulseAudio. But it’s important to see it in the context of the time it was created in, and Linux audio back then was certainly different. OSS was actually something a significant amount of people used…
You are correct. GNU has the bad habit of only working with itself as well. Systemd only works with Glibc so it fits in well.
The reality is that GNU is just a subset of the Red Hat Linux platform these days. Systemd is another part. GNOME is the other big chunk. They are all designed to work with each other and do not care if they work with anything else.
From what i understand the problem is that while systemd is technically split up into different components, you can’t really use it with the stuff you don’t want ripped out.
You obviously weren’t actually around when he was granted mini-king status and acted like a jackass to literally anyone who objected to pulse or systemd. As a result, redhat, canonical, and Debian had to eat criticism over pushing these before they were ready… because of “superstar” poettering.
I totally agree with the functionality of systemd. We need that. But the implementation… Why the fuck do we need to cram everything into pid 1? At least delegate the parsing into another process, god damn. And could we all just agree that ’systemd-{networkd,resolved,homed}’ don’t really have a reason to exist, and definitely not that coupled to a fucking init system. Systemd-timers are wonderful, but why are we running cron-but-better in pid 1?
We have an init-system where the developers are afraid of using things like processes and separation of privileges. I’m just tired of patching fleets of servers in panic every time Pöttering’s bad design decisions hit the fan with their CVEs and consequences.
The coupling in PID 1 is a bit much. I actually quite like systemd-networkd for some use cases, though. It lets me declaratively manage the network interfaces on my headless servers in a way that’s very similar to how I’m managing the services. Sure, it’s coupled to systemd, but it’s mostly one-way coupling; if I want to use NetworkManager (which I do on my laptop), I can switch over, and nothing in the init system breaks.
I don’t know why they are downvoting you, it’s true. I’m dealing with this kind of problem currently… sometimes the boot lasts forever to the point that I have to use AltGr+SysRq commands to force kill everything… other times it simply boots as normal. It’s not consistent at all.
At least before with the old init it was relatively simple to dig into the scripts and make changes to them… I feel now with systemd it’s a lot more opaque and harder to deal with. I wouldn’t even know how to approach the problem, systemd-analyze blame does not help, since the times I actually get to boot look normal. But I do believe it must have to do with the mountpoints because often they are what takes the longest.
Any advice on what should I do would be welcome.
Also, I have a separate Bazzite install in my living room TV, and while that one does not get locked, sometimes NetworkManager simply is not running after boot… I got fed up to the point that I wrote a workaround by creating a rc.local script to have it run, so I can have it available reliably when the system starts (that fixed it… though some cifs mountpoints often do not get mounted… so I’m considering adding the mount command to the same rc.local script too…).
You can play around with the mount option nofail, if that’s set, systemd will not wait for the mount point to be ready and continue booting normally. Can be useful with HDDs that take a while to spin up and aren’t needed for the boot process (e.g. backup drives, etc.).
Another thing to look out for: SDCards or USB flash drives that might randomly fail to “spin up” and hang, unplugging those helps.
I totally agree. I used to hate systemd for breaking the traditional Unix philosophy, but the reality is that a tight init and service-tracking integration tool really was required. I work with and appreciate systemd every day now. It certainly didn’t make things simplier and easier to debug, but it goes a long way towards making a Linux system predictable and consistent.
Poettering can go fuck himself though - and for PulseAudio too. I suspect half of the hate systemd attracted over the years was really because of this idiot.
Linux audio has been a cluster^$%< of epic proportions since the mid 1990s. At least you can make single application systems work well these days, but Windows has really whipped the llamas ass on the audio front for 30+ years now, in terms of “it just works” user experience - without being hyper-draconian on the application ecosystem.
I had (and still have) way more issues with Audio on Windows then I ever had on Linux.
And I have seen it all, OSS, ALSA, aRts, EsounD, pulseaudio, pipewire and most likely some more that I have forgotten.
It definitely depends on what you are trying to get out of it.
I’ll grant: low lag audio performance in Windows is… dismal. Which is why everyone had conference call lag adjustment issues in 2020, “go ahead”, “no you go ahead”, “ok” - both start talking simultaneously again… It seems better these days, I’m sure that’s at least in part due to training of the conference participants, but maybe they have been working on getting the lag down without too many dropout / stutters.
We have a bespoke low lag audio system that was specifically implemented in Linux even though we put the GUI in Windows because of those lag / stutter issues, years back the audio was done on a dedicated DSP chip, but a Core i7 is more than up to the task on Linux these days.
The Linux audio pains I refer to were: A) audio just doesn’t work at all, and B) audio works, until you start to try to use two audio applications simultaneously - then they start to mess each other up. Both of those were better in Windows long before Linux came up to speed. But a lot of how Windows audio gets acceptable performance is big laggy buffers.
Is it really breaking it? As far as I’m aware, it’s more like gnu. It has components and you can select what you use (here meaning distros and packagers).
People mistake this for a monolith because it’s all named systemd-thing. Integration, like you said, was and is needed. But what if all those separate utilities and services are actually disconnected and speak some protocol different to pipe? Does it make it less unixy?
And poettering is an absolute good guy here. Pulseaudio wasn’t perfect, but did it improve things compared to what was there before? Sure it did. Even now, pulesaudio protocol is used within pipewire and it works just fine.
Perfect is the enemy of good. And while all these tools might not be perfect, they are the best in the Linux world.
Agreed. But he’s also an abrasive know-it-all. A modicum of social skills and respect goes a long way towards making others accept your pet projects.
I wasn’t talking about the protocol, I was talking about the implementation: PulseAudio is a crashy, unstable POS. I can’t count the number of hours this turd made me waste, until PipeWire came along.
You mean like Linus Torvalds?
Pulseaudio was introduced in 2004. How come it took almost 20y for it to be replaced if it was that bad?
Implementation, being what it is, improved the situation compared to alsa and other things before it. Again, while not perfect it made things better for everyone.
It’s funny that this is a thing attributed to poettering as bad since things before were way worse… why not throw Sticks and stones at those people?
I really don’t get it.
And all of these things are optional. The fact that distro people and companies select them is because they solve real world problems.
Did you learn nothing from X11 usage? May I remind you that X11 was invented by Xerox in the fucking 80s?!
Bad software attaches itself to OSs like a cancer.
My earliest memories of Linux audio were in Slackware in the mid 90s, reading and re-reading the HOWTO that started off with a bunch of attitude about how real computer users don’t need audio, but we can do it anyway “so, if you must hear Biff bark…” and then a bunch of very unhelpful things to try following that never ever worked on any system I ever tried to use them on. Diverse systems that, of course, all played audio through Windows flawlessly.
I always assumed that Poettering is an arse to people because of the hate he got for systemd. I imagine it’s hard to see the best in people when there’s a crowd of haters everywhere you go. Though I have no idea what he was like beforehand.
People are idiots.
Poettering got death threats for systemd.
Everybody who is hated and popular gets death threats. Hell, even the nicest actors get death threats.
They are easy to write and send, and there’s 0.01% of the population that is mentally unstable enough to actually do so. You and I don’t get death threats because we aren’t popular enough.
Nah bugger that. Famous actors are known by a vast majority of people. It is not normal for open source programmers to receive abuse to the level of death threats. That only happens when you get the attention of kiwi farms types.
Fucking hell, what is wrong with people? Looks at the US. Oh right.
Attitudes develop over time… his may indeed be a defense mechanism or simply a response to all that hate.
I feel that generally, when the issue is that the person is an arse, then the complaints are often not about the software. You might see people campaigning to boicot the software out of spite, but they won’t give you a technical reason, other than them not wanting the creator to get any credit for it.
When the complaints are about discrepancies in the way the software is designed (like it was with systemd), there’s no reason to expect the person to be an arse. Though him not being an arse does not make the criticism about his software invalid… in the same way as him being an arse would not have made the software technically worthless. Don’t fall for the ad-hominem.
This isn’t what I get when reading bug reports he interacts in. Yeah, sometimes he asks if something can’t be done another way – but he seems also very open to new ideas. I rather think that this opinion of him is very selective, there are cases where he comes off as smug, but I never got the impression this is the majority of cases.
PipeWire for audio couldn’t exist nowadays without PulseAudio though, in fact it was originally created as “PulseAudio for Video”; Pulse exposed a lot of bugs in the lower levels of the Linux audio stack. And I do agree that PipeWire is better than PulseAudio. But it’s important to see it in the context of the time it was created in, and Linux audio back then was certainly different. OSS was actually something a significant amount of people used…
“It’s more like gnu”
You are correct. GNU has the bad habit of only working with itself as well. Systemd only works with Glibc so it fits in well.
The reality is that GNU is just a subset of the Red Hat Linux platform these days. Systemd is another part. GNOME is the other big chunk. They are all designed to work with each other and do not care if they work with anything else.
From what i understand the problem is that while systemd is technically split up into different components, you can’t really use it with the stuff you don’t want ripped out.
You obviously weren’t actually around when he was granted mini-king status and acted like a jackass to literally anyone who objected to pulse or systemd. As a result, redhat, canonical, and Debian had to eat criticism over pushing these before they were ready… because of “superstar” poettering.
Poettering is a disrespectful clown.
systemd is easy to work with, other init systems introduce kinks, I rather break philosophy than deal with that shit
I’ll just go ahead and start the flame war.
I totally agree with the functionality of systemd. We need that. But the implementation… Why the fuck do we need to cram everything into pid 1? At least delegate the parsing into another process, god damn. And could we all just agree that ’systemd-{networkd,resolved,homed}’ don’t really have a reason to exist, and definitely not that coupled to a fucking init system. Systemd-timers are wonderful, but why are we running cron-but-better in pid 1?
We have an init-system where the developers are afraid of using things like processes and separation of privileges. I’m just tired of patching fleets of servers in panic every time Pöttering’s bad design decisions hit the fan with their CVEs and consequences.
The coupling in PID 1 is a bit much. I actually quite like
systemd-networkdfor some use cases, though. It lets me declaratively manage the network interfaces on my headless servers in a way that’s very similar to how I’m managing the services. Sure, it’s coupled tosystemd, but it’s mostly one-way coupling; if I want to use NetworkManager (which I do on my laptop), I can switch over, and nothing in the init system breaks.Or none of those.
Oh. My NIC didn’t ‘start’ because systemd and network manager are fighting again? Neet.
Just use systemd-sudo to replace network manager with systemd-networking
I don’t know why they are downvoting you, it’s true. I’m dealing with this kind of problem currently… sometimes the boot lasts forever to the point that I have to use AltGr+SysRq commands to force kill everything… other times it simply boots as normal. It’s not consistent at all.
At least before with the old init it was relatively simple to dig into the scripts and make changes to them… I feel now with systemd it’s a lot more opaque and harder to deal with. I wouldn’t even know how to approach the problem,
systemd-analyze blamedoes not help, since the times I actually get to boot look normal. But I do believe it must have to do with the mountpoints because often they are what takes the longest. Any advice on what should I do would be welcome.Also, I have a separate Bazzite install in my living room TV, and while that one does not get locked, sometimes NetworkManager simply is not running after boot… I got fed up to the point that I wrote a workaround by creating a rc.local script to have it run, so I can have it available reliably when the system starts (that fixed it… though some cifs mountpoints often do not get mounted… so I’m considering adding the mount command to the same rc.local script too…).
You can play around with the mount option
nofail, if that’s set, systemd will not wait for the mount point to be ready and continue booting normally. Can be useful with HDDs that take a while to spin up and aren’t needed for the boot process (e.g. backup drives, etc.).Another thing to look out for: SDCards or USB flash drives that might randomly fail to “spin up” and hang, unplugging those helps.
Thanks! I’ll try with
nofailand see if the lockups stop!Honestly, that could be it now that you mention it… I have had for a while an external hard drive plugged in that I’ve used for some backups.
What is the Unix philosophy?
https://en.wikipedia.org/wiki/Unix_philosophy