The Linux Thread - The Autist's OS of Choice

  • 🐕 I am attempting to get the site runnning as fast as possible. If you are experiencing slow page load times, please report it.
Because the two are intrinsically connected. An init system runs a set of services on boot, cron runs a set of services at certain intervals. If my service says “run at boot and once an hour after”, it makes sense for the init to handle that. That it’s also much easier to configure than cron, and will log nice and neatly into journalctl is just a bonus.
It's the "and this, and this, and this..." syndrome why I don't care for systemd. No service lives in a vacuum, surely, but coupling/deferring its duties after init to init makes init the most responsible party when it ought not to be. That's just not its job and it's not going to do better than the services that should be doing them. It blows my mind that systemd still causes shutdown lockups and I suspect that is why.
 
It's the "and this, and this, and this..." syndrome why I don't care for systemd. No service lives in a vacuum, surely, but coupling/deferring its duties after init to init makes init the most responsible party when it ought not to be. That's just not its job and it's not going to do better than the services that should be doing them. It blows my mind that systemd still causes shutdown lockups and I suspect that is why.
The Unix philosophy was "Do one thing and do it well." SystemD does not do one thing and it doesn't do any of them well.

I remember swapping a disk once. Hot swap array. Unmount and remove old, install new, partition, mkfs, mount. And it didn't mount. No errors on the command line, no errors in dmesg. Fucking systemd was helpfully unmounting it because it was the "wrong drive" for the mount point and I hadn't asked for its consent to use a different drive.
 
Has anyone ever tried Bodhi Linux? I did once, it seemed weird. Not sure what kind of people use it.
 
Has anyone ever tried Bodhi Linux? I did once, it seemed weird. Not sure what kind of people use it.

I hadn't tried it but I've messed around with distributions (EasyOS, Puppy Linux, etc.) that have the same focus. It's really for those who have limited access to hardware, and that hardware might lack support for future windows updates and upgrades, or even lack any sort of Hard Drive or Solid State Drive and only RAM configurations (hence live medium). You can flash Bodhi or similar distros to a USB drive as a rescue tool.

If you have an old netbook laying around, Antix, Bodhi, Puppy and others would be perfect.
 
Last edited:
  • Like
Reactions: DrNow
I am nowhere near a Linux/Unix historian to fully grasp the diferences between init and SystemD but judging by what I've read so far -and to bring up a somewhat apt analogy- this is like people discussing the Ford Flathead V8 against the 5.2L Voodoo. As in, some things need to move on and improve with time.

Rolling Linux like it's still the '70s can't be good in the long term.
 
This is the part of the debate I don't really get, as someone who is neither pro systemd nor pro any other init system. I am not too convinced by systemd timers either, so I just continue using cron, since it's easier to use for me. Nothing about systemd forces me to systemd timers, and my crontab happily coexists with it. I do not understand what the issue here is. Am I missing something?
While I think systemd sperging can be excessive, I'll play some devils advocate in this situation. Having multiple programs that run scheduled tasks can be messy and makes it harder to diagnose unintended behaviors. For example, I had this annoying instance where everything I rebooted my laptop my torrent client would open. I assumed it would be systemd, but it became clear that wasn't the case.

It turned out that KDE had a setting enabled to reopen programs I had open before, and because the torrent client's background process was running, it would open a new instance on startup. If KDE hadn't implemented a separate feature for this, and just interfaced with systemd for these startup apps, it would have taken much less time to fix.

In this case systemd was totally innocent, but the same concept applies. If you are using cron to manage your task scheduling, and systemd then starts scheduling tasks on its own or at the whim of another program, you might have trouble realizing what's going on.

I think linux autists have much bigger problems to address these days (seriously fuck Ubuntu for trying to install their shitty snap packages when you use apt), but there are some reasons to dislike systemd bundling extra features when you already have another standard program that addresses the problem.
 
I am nowhere near a Linux/Unix historian to fully grasp the diferences between init and SystemD but judging by what I've read so far -and to bring up a somewhat apt analogy- this is like people discussing the Ford Flathead V8 against the 5.2L Voodoo. As in, some things need to move on and improve with time.

Rolling Linux like it's still the '70s can't be good in the long term.
It's not a great analogy, given the role the init takes, but to extend it a little: using systemd would be like replacing your perfectly good engine with almost an entire separate car under the hood. It has its own wheels, its own exhaust, its own cooling, for some reason it has a boat propeller attached to it, and it has a little driver who regularly tries to steer you in the direction he wants to go.

The problem with systemd is not that it's a drop-in replacement for an older component, but rather that it has subsumed so much of the functionality of previously independent systems. Arbitrary parts of the system are now reliant on a single, core library that is written by a team who regularly refuse to fix bugs and who seem to believe that separation of concerns - avoiding the mingling of unrelated functions - is something for boring people.
 
it's not really systemd's fault that various linux components were fairly mediocre and failed to be interoperable for a couple decades before they came along

I love the way that systemd-networkd, systemd-resolved, systemd timers, systemd units, and systemd-nspawn all come together to manage my container setup with zero docker involved.
 
it's not really systemd's fault that various linux components were fairly mediocre and failed to be interoperable for a couple decades before they came along
This is just a straight-up lie.

Besides, I don't want my init making dns requests, especially not to a default dns system outside of my control, and I certainly don't want it managing my network interfaces. Every time I've had to interact with systemd-networkd, it has caused nothing but trouble, with its bizarre assumptions that are based on Poettering's personal requirements for his laptop's network activity. It breaks basic network expectations with its behaviour.

SyStEmD doesn't need to subsume device management, cron, home drive management, networking, dns, system logging, user logins, the fucking boot drive, and whatever else they're cramming into it this week. It could have used already standardised interfaces to those components, or even D-Bus given most of them were already using it in some fashion, but that would require acknowledging that Linux userspace development isn't the solely-owned, proprietary playground of Poettering and Red Hat.

And it's still not even a very good init. Processes will break for no reason and it will still hang on zombie processes on shutdown. It still fails to reliably perform the one task it was originally touted as performing.
 
I like systemd. I know how to use it and it works. I think it's greatest selling point though is how much it annoys the boomers.
I don't like flatpak, snap, netplan, docker (or containers) so I just don't use them. None of these annoy people like systemd does though, and that's sad.
I'm lucky that i'm not tortured by something i'm not forced to use I guess.
 
I think it's greatest selling point though is how much it annoys the boomers.
Personally I'd want the biggest selling feature be something that benefits me, not something I tolerate because it annoys people I don't like.
Spite is something that's used to take advantage of a shitty situation, not a substitute for a good situation.
 
Last edited:
I'm lucky that i'm not tortured by something i'm not forced to use I guess.
I am forced to use it. The fact that it has consumed most of the userspace daemons and tools means that every distro that is remotely popular for any sort of hosting situation defaults to systemd, which consequently means I am forced to interact with it every time I shell in to fix a problem. Usually, it's a problem caused by systemd being stupid.

With you on snaps and flatpack and such, though. That shit drives me crazy as well, not least the fact that you're required to have a daemon running constantly and sucking up resources, just for that one application that only comes as a snap package.

Maybe my real problem is that I hate computers...
 
This is just a straight-up lie.

Besides, I don't want my init making dns requests, especially not to a default dns system outside of my control, and I certainly don't want it managing my network interfaces. Every time I've had to interact with systemd-networkd, it has caused nothing but trouble, with its bizarre assumptions that are based on Poettering's personal requirements for his laptop's network activity. It breaks basic network expectations with its behaviour.

SyStEmD doesn't need to subsume device management, cron, home drive management, networking, dns, system logging, user logins, the fucking boot drive, and whatever else they're cramming into it this week. It could have used already standardised interfaces to those components, or even D-Bus given most of them were already using it in some fashion, but that would require acknowledging that Linux userspace development isn't the solely-owned, proprietary playground of Poettering and Red Hat.

And it's still not even a very good init. Processes will break for no reason and it will still hang on zombie processes on shutdown. It still fails to reliably perform the one task it was originally touted as performing.
Systemd's main problem is that it is opinionated, and its opinions are stupid.

It's been 10 years, but it still pisses me off that it renames network adaptors from eth0 etc. to something unmemorable and nonsensical. For 99% of people this is a change for the worse, but it still went ahead because Poettering.
 
Last edited:
Personally I'd want the biggest selling feature be something that benefits me, not something I tolerate because it annoys people I hate.
Oh man, you took the joke and just ran with it huh?
Usually, it's a problem caused by systemd being stupid.
Are you actually being honest here?
Where I work has somewhere around 6,000 servers and they run ubuntu. I probably have to ssh into maybe 100 a day and I think the last systemd issue I saw was a corrupted log about 2 months ago. Given the amount of servers I'd expect to see a lot more problems. For comparison, I have to unfuck ceph & glusterfs several times a day and usually waste an hour daily speaking with either [cloud provider] about dead hardware. I simply don't experience these problems at all, and I should be.
 
Back