| |
| ▲ | blibble 3 hours ago | parent [-] | | yeah, the fix for pulseaudio was to throw it away entirely for systemd, I don't think I have a single linux system that boots/reboots reliably 100% of the time these days | | |
| ▲ | dijit 3 hours ago | parent [-] | | 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 3 hours ago | parent | next [-] | | I 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 | | |
| ▲ | bee_rider 24 minutes ago | parent | next [-] | | PipeWire 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. | |
| ▲ | jacquesm 3 hours ago | parent | prev | next [-] | | I 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 3 hours ago | parent [-] | | everyone attacking Microslop for a bug where Windows won't shut down properly well, systemd's got them beat there! | | |
| ▲ | direwolf20 an hour ago | parent [-] | | The 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 17 minutes ago | parent [-] | | I think at some point we will see a steep increase in value of old hardware that can still run unsigned binaries. |
|
|
| |
| ▲ | 1vuio0pswjnm7 41 minutes ago | parent | prev | next [-] | | "for what? to save a second of boot time" Doubtful the motivation was /etc/rc being too slow daemontools, runit, s6 solve that problem | |
| ▲ | jorvi 3 hours ago | parent | prev [-] | | > 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/syst... And outside of esoteric setups I haven't ever encountered the problems you mentioned with service files. | | |
| ▲ | ethin 4 minutes ago | parent | next [-] | | Same. I run a server with a ton of services running on it which all have what I think are pretty complex dependency chains. And I also have used Linux with systemd on my laptop. Systemd has never, once, caused me issues. | |
| ▲ | direwolf20 2 hours ago | parent | prev | next [-] | | systemd was created to solve the problems of a directory full of shell scripts. A single shell script has completely different problems. And traditional init uses inittab, which is not /etc/init.d, and works more like runit. runit's approach is to just keep trying to start the shell script every 2 seconds until it works. One of those worse–is–better ideas. You can check for arbitrary conditions and error–exit, and it will keep trying. If you need the time synced you can just make your script fail if the time is not synced. | |
| ▲ | blibble 2 hours ago | parent | prev [-] | | yeah, 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 2 hours ago | parent [-] | | > 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. | | |
| ▲ | blibble an hour ago | parent | next [-] | | it's the "usually" that's the problem this service (untouched by me) had: After=local-fs.target network-online.target remote-fs.target time-sync.target but it was still started without an IP address, and then failed to bind just like this sort of problem: https://github.com/systemd/systemd/issues/4880#issuecomment-... the entire thing is unreliable and doesn't act like you'd expect > Or you can do something with ExecStartPre. You could run a shell command that checks for the most recent time sync or forces one. at that point I might as well go back to init=/etc/rc | |
| ▲ | direwolf20 an hour ago | parent | prev [-] | | Is it possible for network-online to mean that, or does network-on actually mean that? It is possible for a specification to be so abstract that it's useless. |
|
|
|
| |
| ▲ | Brian_K_White 21 minutes ago | parent | prev [-] | | "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". |
|
|
|