6 ms·
The trick is the same: use a popular linux distribution and don't fight the kinks. The people who had no issues with Pulseaudio; used a mainstream distribution
by dijit 9mo ago
The trick is the same: use a popular linux distribution and don't fight the kinks.
The people who had no issues with Pulseaudio; used a mainstream distribution. Those distributions did the heavy lifting of making sure stuff fit together in a cohesive way.
SystemD is very opinionated, so you'd assume it wouldn't have the same results, but it does.. if you use a popular distro then they've done a lot of the hard work that makes systemd function smooth.
I was today years old when I realised this is true for both bits of poetter-ware. Weird.
- blibble 9mo agoI only use debian pulseaudio I had to fight every single day, with my "exotic" setup of one set of speakers and a headset with pipewire, I've never had to even touch it systemd: yesterday I had a network service on one machine not start up because the IP it was trying to bind to wasn't available yet the dependencies for the .service file didn't/can't express the networking semantics correctly this isn't some hacked up .service file I made, it's that from an extremely popular package from a very popular distro (yeah I know, use a socket activated service......... more tight coupling to the garbage software) the day before that I had a service fail to start because the wall clock was shifted by systemd-timesyncd during startup, and then the startup timeout fired because the clock advanced more than the timeout then the week before that I had a load of stuff start before the time was synced, because chrony has some weird interactions with time-sync.target it's literally a new random problem every other boot because of this non-deterministic startup, which was never a problem with traditional init or /etc/rc for what? to save maybe a second of boot time if the distro maintainers don't understand the systemd dependency model after a decade then it's unfit for purpose
- jacquesm 9mo agoI can totally relate to this, it's gotten to the point that I'm just as scared of rebooting my Linux boxes as I was of rebooting my windows machine a couple of decades ago. And quite probably more scared.
- blibble 9mo agoeveryone attacking Microslop for a bug where Windows won't shut down properly well, systemd's got them beat there!
- direwolf20 9mo agoThe good thing about systemd or any other Linux software is that you don't have to use it, until this company gets off the ground.
- jacquesm 9mo agoI think at some point we will see a steep increase in value of old hardware that can still run unsigned binaries.
- direwolf20 9mo agoIt won't be able to interact with any online services like Google or Hacker News.
- esseph 9mo agoWhat distro?
- jorvi 9mo ago> it's literally a new random problem every other boot because of this non-deterministic startup, which was never a problem with traditional init or /etc/rc This gave me a good chuckle. Systemd literally was created to solve the awful race conditions and non-determinism in other init systems. And it has done a tremendous job at it. Hence the litany of options to ensure correct order and execution: https://www.freedesktop.org/software/systemd/man/latest/systemd.service.html https://www.freedesktop.org/software/systemd/man/latest/syst... And outside of esoteric setups I haven't ever encountered the problems you mentioned with service files.
- blibble 9mo agoyeah, many options that are complicated beyond the understanding of the distro maintainers, and yet still don't allow expression of common semantics required to support network services reliably like "at least one real IP address is available" or "time has been synced" and it's not esoteric, even ListenAddress with sshd doesn't even work reliably the ONLY piece of systemd I've not had problems with is systemd-boot, and then it turned out they didn't write that
- jorvi 9mo ago> like "at least one real IP address is available" or "time has been synced" "network-online.target is a target that actively waits until the network is “up”, where the definition of “up” is defined by the network management software. Usually it indicates a configured, routable IP address of some kind. Its primary purpose is to actively delay activation of services until the network has been set up." For time sync checks, I assume one of the targets available will effectively mean a time sync has happened. Or you can do something with ExecStartPre. You could run a shell command that checks for the most recent time sync or forces one.
- bandrami 9mo agoSysadmins really hate the word "usually", and that is at the root of just about every systemd headache I've had
- 9mo ago
- 1vuio0pswjnm7 9mo ago"for what? to save a second of boot time" Doubtful the motivation was /etc/rc being too slow daemontools, runit, s6 solve that problem
- jacquesm 9mo agoThe only parties that really cared about boot time were the big hosting providers and container schleppers. For desktop linux it never mattered as much.
- bee_rider 9mo agoPipeWire is like 10 years newer than PulseAudio. It probably had a chance to learn some lessons! IIRC before PulseAudio we had to mess around with ALSA directly (memory hazy, it was a while ago). It could be a bit of a pain.
- fao_ 9mo agoI remember ALSA. Sure, it was finnicky to use `alsamixer` to unmute the master channels now and then, but I personally never had any trouble with it.
- sam_lowry_ 9mo agoAlsa with dmix is my current setup on ArchLinux.
- account42 9mo agoI still need to use alsamixer to unmute my headphones after accidentally unplugging them and plugging them in again fails to do so. That's with PipeWire - never had that problem with just ALSA.
- fao_ 9mo agoEh, I had to do that with pulseaudio too, but constantly, across all distros and headphones. Pipewire is shonky, I have to restart now and then on my steam deck (I'm using it as a desktop), but it's still much better than pulseaudio. Even ALSA was better than pulseaudio lol
- ahartmetz 9mo agoFor most of the (sadly not shorter) life of PulseAudio, ALSA was more reliable, but at some point, Firefox got a new audio backend that straight up dropped support for ALSA, and a few games started crashing with backtraces indicating audio trouble when not run with PulseAudio. I've had to deal with PulseAudio's dropouts under load, latencies and lockups for 2-3 years before PipeWire became a viable replacement.
- esseph 9mo agoDebian is a darling for which I will always love, but it's inability to deal with systemd is one of the prime reasons I left. I am not seeing these kind of systemd issues with Fedora / RHEL. It just works
- jacquesm 9mo agoThat's because systemd originated at RedHat. If it had been designed distribution agnostic it would have worked a lot better on other distros besides RH.
- NekkoDroid 9mo agoWhat are the non-distribution agnostic parts of systemd? Considering it runs as PID1 (usually) it kinda is the base of distros and not really built on top of any distro other than "the linux kernel".
- braincat31415 9mo agoFor me, randomly missing NFS mounts after boot were the last straw. I could not solve this problem. I am back on sysv init.
- smm11 9mo agoThis. If you set an NFS share, it better be there forever and ever.
- Brian_K_White 9mo ago"The trick is the same: use a popular linux distribution and don't fight the kinks." I believe that you are genuinely being sincere here, thinking this is good advice. But this is an absolutely terrible philosophy. This statement is ignorant as well as inconsiderate. (again, I do believbe you don't intend to be inconsiderate consciously, that is just the result.) It's ignorant of history and inconsiderate of everyone else but yourself. Go back a few years and this same logic says "The trick is, just use Windows and do whatever it wants and don't fight." So why in the world are you even using Linux at all in the first place with that attitude? For dishonest reasons (when unpacked to show the double standard). Since you are using Linux instead of Windows, then you actually are fine with fighting the tide. You want the particular bits of control you want, and as long as you are lucky enough to get whatever you happen to care about without fighting too much, then you have no sympathy for anyone else who cares aboiut anything else. You don't see yourself as fighting any tides because you are benefitting from being able to use a mainstream distro without customizing it. But the only reason you get to enjoy any such thing at all in the first place is because a lot of other people before you fought the tide to bring some mainstream distros into existence, and actually use them for ordinary activities enough despite all the difficulties, to force at least some companies and government agencies to acknowledge them. So now you can say things like "just use a mainstream distro as it comes and don't try to do what you actually want".
- fao_ 9mo agoI read it as sarcastic and bitter, personally! I believe you are both agreeing :)
- Brian_K_White 9mo agohah it fits regardless
- Sophira 9mo ago> Go back a few years and this same logic says "The trick is, just use Windows and do whatever it wants and don't fight." This is basically exactly what I saw people saying in Windows subreddits. There's one post that particularly sticks out in my memory[0] that basically had everybody telling the OP to just not make any of the changes that they wanted to make. The advice seemed to revolve around adapting to the OS rather than adapting the OS to you, and it made me sad at the time. [0] https://www.reddit.com/r/Windows10/comments/hehrqe/what_are_your_musttweakinstall_recommendations/ https://www.reddit.com/r/Windows10/comments/hehrqe/what_are_...
- PunchyHamster 9mo ago> The people who had no issues with Pulseaudio; used a mainstream distribution. Those distributions did the heavy lifting of making sure stuff fit together in a cohesive way. Incorrect. I used mainstream distro, still had issues, that just solved itself moving to pipewire. Issues like it literally crashing or emitting spur of max volume noise once every few months for no discernable reason. Pulseaudio also completely denies existence of people trying to do music on Linux, there is no real way to make latency on it be good. > SystemD is very opinionated, so you'd assume it wouldn't have the same results, but it does.. if you use a popular distro then they've done a lot of the hard work that makes systemd function smooth. Over the years of using the "opinion" of SystemD seems to be "if it is not problem on Lennart's laptop, it's not a real problem and it can be closed or ignored completely". For example systemd have no real method to tell it "turn off all apps after 5 minutes regardless of what silly package maintainers think". Now what happens if you have a server on UPS that have say 5 minutes of battery and one of the apps have some problem and doesn't want to close? In SysV, it gets killed, and system gets remounted read only. You have app crash recovery but at least your filesystem is clean In systemd ? No option to do that. You can set default timeout but it can be override in each service so you'd have to audit every single package and tune it to achieve that. That was one bug that was closed. Same problem also surfaced if you have say app with a bug that prevented it from closing from sigterm and you wanted to reboot a machine. Completely stuck But wait, there is another method, systemd have an override, you can press (IIRC) ctrl+alt+delete 7 times within 2 seconds to force it to restart ( which already confuses some people that expect it to just restart machine clean(ish) regardless https://github.com/systemd/systemd/issues/11285 https://github.com/systemd/systemd/issues/11285 ). ...which is also impossible if your only method of access is software KVM where you need to navigate to menu to send ctrl+alt+del. So I made ticket with proposal to just make it configurable timeout for the CAD ( https://github.com/systemd/systemd/issues/29616 https://github.com/systemd/systemd/issues/29616 ), the ticket wasn't even read completely because Mr. Poettering said "this is not actionable, give a proposal", so I pasted the thing he decided to ignore in original ticket, and got ignored. Not even "pull requests welcome" (which I'd be fine with, I just wanted confirmation that the feature like that won't be rejected if I start writing it). There is also issue of journald disk format being utter piece of garbage ("go thru entire journal just to get app's last few lines bad", hundreds of disk reads on simple systemctl status <appname> bad) that is consistently ignored thru many tickets from different people. Or the issue that resolvconf replacement in systemd will just roll a dice on DNS ordering, but hey, Mr. Lennart doesn't use openvpn so it's not real issue ( https://github.com/systemd/systemd/issues/27543 https://github.com/systemd/systemd/issues/27543 ) I'm not writing it to shit on systemd and praise what was before, as a piece of software it's very useful for my job as sysadmin (we literally took tens of thousands lines of fixed init scripts out because all of the features could be achieved in unit files) and I mean "saved tons of time and few demons running" in some cases, but Mr. Poettering is showing same ignorant "I know better" attitude he got scolded at by kernel maintainers.