Avoiding Complexity with Systemd • Hacker News Board

Re: Avoiding Complexity with Systemd

#151

Post by rep_movsd » Sun, Jun 27, 2021, 3:36 PM UTC

midasuni wrote: post #13

Dinux wrote: post #10

I'm glad to see more people sway to systemd. Systemd is 10 years in the making and it was met with skepticism right from the first day. Some of that is now slowly changing with systemd being accepted in more and more distributions. Service and runlevel management wasn't any better in the sysv era, nor were any of the multitude of custom start and boot scripts. I remember when it took multiple days testing the configu…

For people who had well working low maintenence environments, systemd came in and changed everything - breaking things, requiring changes to get things working again. Its not just breaking init.d scripts, it’s ntp, dns, syslog. Systems throughout the OS fail to things that were no longer short commands with muscle memeory, there were now ridiculous convoluted commands like systemd-resolve --status instead of 30 years…

If you are using UNIX like environments, you are forced to remember arcane commands - after almost 25 years of using Linux, I still have to open the man page for something as ubiquitous as grep - because there's so many options and you are always finding new use cases.

The best solution is to maintain infinite bash history and stop trying to remember arcane stuff.

Don't even get me started on tools like jq - so convoluted that I use python instead

Re: Avoiding Complexity with Systemd

#152

Post by kaba0 » Sun, Jun 27, 2021, 3:39 PM UTC

spindle wrote: post #46

delusional wrote: post #43

Earlier quoted context omitted.

Naa. I'm young and generally positive about systemd, but I'd happily admit that the complexity gap is huge. It's practically impossible to explain systemd to anyone not intimately familiar with linux and systems programming without a bunch of handwaving.

This. I can easily believe that systemd is an improvement in many ways for people who have time to understand it (especially in NixOS, as noted by another commenter). But I'm not happy that so many parts of Linux now have such a steep learning curve.

But system init is a hard, complex problem. You can’t create a simple solution for that, since there is an inherent complexity. I prefer systemd over having a bunch of bash scripts trying to do service restart, logging, dependency management and failing at it. You would still get the same complexity but at a different (worse) level.

Re: Avoiding Complexity with Systemd

#153

Post by kaba0 » Sun, Jun 27, 2021, 3:41 PM UTC

iso1210 wrote: post #117

throw-8462682 wrote: post #54

Earlier quoted context omitted.

How likely is it that the prolific systemd team and tech decision makers in Linux distributions don’t have a design instinct and came up with this ball of mud full of accidental and unneeded complexity? Have you considered that there may be teams and requirements outside your current sphere of experience?

Maybe there are, but that doesn't help me. The systemd way seems to be "one tool of complexity 40 to 50 things" rather than "50 tools of complexity 1 each doing one thing". When you only need 10 things, you only need 10 simple tools of complexity 10, rather than one tool of complexity 40.

That’s not how complexity works. Inherent complexity can’t really be outsourced meaningfully.

Re: Avoiding Complexity with Systemd

#154

Post by kaba0 » Sun, Jun 27, 2021, 3:43 PM UTC

iso1210 wrote: post #118

tyingq wrote: post #44

My frustration with systemd is that it creeps out over time into other functionality, and that it's difficult to find the right documentation. Like when logind was changed to kill background processes when you log out, by making KillUserProcesses=yes the default. Some Linux distros left that as is, others overrode it in /etc/systemd/logind.conf. So, figuring out what was happening, and how to fix it, was confusing. I…

Ouch, what on earth does "log out" even mean? What a terrible way to run any computer other than maybe a single user laptop.

Not sure if sarcastic, but the systemd default makes sense. Why should random processes linger in a background, with an ill defined “not answering a signal” hack? There is no distinction between a frozen process and tmux. They can easily register a user service and continue running there.

Re: Avoiding Complexity with Systemd

#155

Post by teknopaul » Sun, Jun 27, 2021, 3:49 PM UTC

5e92cb50239222b wrote: post #128

geofft wrote: post #104

Earlier quoted context omitted.

I really don't understand the scenario where binary logging is a problem. journalctl is a command just like, I dunno, gzip, and people are fine with gzipped logs. If something goes horribly wrong with your system, you're not looking at logs with an oscilloscope, you're looking at logs by mounting the disk on some other working OS - whether it's the initramfs, or a live CD, or whatever. You can run gunzip (Not to ment…

A thoughtful comment downvoted into oblivion without any explanation. Classic HN. I too don't get the hate that binary logs receive. They aren't any harder to work with than text logs. journalctl makes it easy to read logs from an offline system, too. The compression it automatically provides saves a lot of space across our machines. I know that it can be achieved without binary logs, but does any popular distributio…

journactl makes it _possible_ to read the log TFTFY.

Re: Avoiding Complexity with Systemd

#156

Post by kevincox » Sun, Jun 27, 2021, 3:50 PM UTC

WesolyKubeczek wrote: post #77

For me, systemd is the best thing since sliced bread. As a programmer, I now don't need to care about dropping privileges, managing logging, daemonization (the moment I need to do the double-fork dance again, chairs will be flying, I swear), dropping into a chroot, and do half-arsed guesses "is it up and running yet?" from a convoluted mess of shell code that looks like a bunch of hair stuck down a drain for a month.…

I agree. It puts the system administrator in control of a lot of these things. Sometimes that can be annoying (the developer knows that systems calls they need) but often it is a huge benefit. I think socket-passing especially is a huge win, it shifts a huge amount of complexity out of each application and gives huge benefits as the administrator can configure the sockets however they want without needing each application to support each feature independently. Furthermore it removes one of the most common reasons why applications need to be started as root.

I wrote about this previously here: https://kevincox.ca/2021/04/15/my-ideal-service/#socket-pass...

Re: Avoiding Complexity with Systemd

#157

Post by kaba0 » Sun, Jun 27, 2021, 3:54 PM UTC

boublepop wrote: post #94

birdyrooster wrote: post #62

Earlier quoted context omitted.

Why are we talking like this? We’ve been using systemd for over 5 years. It’s weird. Time loops.

It took 10 years before the “python2 will never die”-crowd finally accepted they where not going to win at that python3 was here to stay. People spend a couple of years getting used to a stack in their early carrier and then spend decades arguing that it should never change.

But python programs are much more complex than init scripts systemd replace. It is more like people hate change and are lazy to learn a new thing.

Re: Avoiding Complexity with Systemd

#158

Post by teknopaul » Sun, Jun 27, 2021, 3:55 PM UTC

Trying to avoid complexity by being dependent on something horribly complex is not going to work.

Re: Avoiding Complexity with Systemd

#159

Post by knorker » Sun, Jun 27, 2021, 3:55 PM UTC

throw-8462682 wrote: post #83

knorker wrote: post #53

My problem with systemd is that it's just so poorly written. The ideas are not inherently bad. But they're not thought through, and the implementation is pure garbage. Like taking the most stable software in the world[1], and going "nah, I'll just replace it with proof-of-concept code, leaving a TODO for error handling. It'll be fine.". And then the "awesomeness" of placing configuration files whereever the fuck you…

Care to elaborate? Off the bat, your comment comes across as a cynical rant due to its high use of strong words (garbage, fuck) and lack of examples. And even if you have anecdotes, to be convincing, it would have compare something like bug density to the software projects that collectively replaces. As written, your statement is unlikely to convince anyone that isn’t yet already.

It's a pile of proof-of-concept broken pieces duct taped together into a big mess.

Here's an example: Someone read that fd-passing is a thing, so now systemd listens to just about everything and spawns stuff on-demand.

Now, that may seem like a good idea, if you think it up in a vaccuum and don't have experience with the real world. It's a great idea, if you're in high school. But to have it actually accepted? WTF is even happening?

Oh, let's do this for time sync from GPS. Great. All that time that could have been spent verifying the signal and all, completely wasted, because some jerk thought that it's better to waste 15 minutes of the human waiting, just to save 100kB of RAM.

It's a monumentally bad idea.

And more specifics: Like I said, when you replace init you need to have it not crash.

And then restarting daemons with systemctl almost to a rule fails, and fails silently. Often I have to just kill the daemon manually, and systemctl start it again.

But people aren't complaining about systemd anymore because now there's two kinds of people:

1. People to young to remember stable software.

2. People who have given up, and just accepted that Linux too "just needs a reboot every now and then to kinda fix whatever got broken".

But maybe the trend is changing? Pipewire looks like it's not actually shit (unlike PulseAudio which has plagued us forever), and while it has some important bugs in edge cases, it's actually more reliable than what it's replacing(!)

> As written, your statement is unlikely to convince anyone that isn’t yet already.

It's hard to convince people who don't care. Or indeed those who don't know that no, actually, short of a kernel upgrade "reboot to fix that problem whenever it happens" is not normal, and is a serious bug.

Pre-systemd Linux had as a selling point that it's actually stable, compared to Windows at least. But Windows has gotten much better in the past decade in reliability, and Linux much worse.

systemd is on the level of a re-think by a pretty bright high school student. And that's not a good thing. It's a very bad thing.

> to be convincing, it would have compare something like bug density to the software projects that collectively replaces

You're asking me to be data-driven, while being fully aware that systemd isn't, right? Your argument is essentially fallacy by implying that status quo is data-driven.

It's hard to take your suggestion at face value. Especially with many of the same people pushing systemd at the time making up shit like "We know that Unity is objectively the best user experience in the world"[1] (that's why it lost, because nobody liked it, right?[2]).

At the same time I also fall into group (2), above. I don't have time to wrestle in the mud with people who don't care.

[1] a quote like that, I may not have gotten the words just right. but the word "objectively" (without data) was there. [2] and I don't even particularly care about window managers. Before Unity I hadn't bothered switching from "whatever the default is on this system" in most cases.

Re: Avoiding Complexity with Systemd

#160

Post by cesarb » Sun, Jun 27, 2021, 3:56 PM UTC

midasuni wrote: post #13

Dinux wrote: post #10

I'm glad to see more people sway to systemd. Systemd is 10 years in the making and it was met with skepticism right from the first day. Some of that is now slowly changing with systemd being accepted in more and more distributions. Service and runlevel management wasn't any better in the sysv era, nor were any of the multitude of custom start and boot scripts. I remember when it took multiple days testing the configu…

For people who had well working low maintenence environments, systemd came in and changed everything - breaking things, requiring changes to get things working again. Its not just breaking init.d scripts, it’s ntp, dns, syslog. Systems throughout the OS fail to things that were no longer short commands with muscle memeory, there were now ridiculous convoluted commands like systemd-resolve --status instead of 30 years…

> For decades it was /etc/init.d/myserice restart

You should always use "service myservice start" instead of "/etc/init.d/myservice start". Running "/etc/init.d/myservice start" directly means the service ends up accidentally inheriting parts of your shell's state (environment variables, limits, current directory), which is a different environment from when the service is started at boot. The "service" command carefully cleans up most of the environment before running the script, making it much more similar to what will happen when it starts automatically on next boot.

And if you were used to "service myservice start", it now automatically forwards to "systemctl start myservice" when the /etc/init.d/myservice script does not exist, so it keeps working nearly the same after the transition to systemd.