Linux power-users hate it when a tool tries to become a platform.
It breaks the principle of single responsibility and becomes a threat to the evolution of alternatives.
It’s pros and cons. Having a platform is better because everyone works together on a single effort. But it also becomes a risk because now everyone depends on a single thing that does too much.
For a desktop it’s suitable for 99% of what you’d want to do. Might not be the best tool for large servers or something (I really don’t know) but I’m sure all that depends on use case.
Are you using Linux for ordinary daily tasks like browsing, gaming, and coding? Then SystemD is perfect for such systems. No need to use distros that sell the lack of SystemD as their main selling point—it’s more trouble than it’s worth. Avoid SystemD haters like the plague.
Do you use Linux for enterprise servers? Then SystemD is just one of the options for you, go try all of them out to see what’s best for such workflow.
It’s a pretty bridge, they’d say, but be careful you don’t look at the supports. It was built using bad techniques, bad procedures, no coordination and no inspection.
Just cross your fingers as you drive over and hope it doesn’t blow up because of its flawed construction.
I find it’s a great way to cross the river, today.
In a quiet village, two monks stood on the bank of a wide river. The older monk asked the younger, “How do you cross this river?”
The younger monk pointed at the grand bridge a short distance away, “Through that bridge, master.”
The older monk shook his head, "You see a bridge, yet the river flows beneath. In seeking to cross, you are already on the other side. Tell me, where is the true bridge?
At that moment, the young monk became enlightened, supposedly, because that’s how most zen koans end.
ya see, when i ssh into a server and i run some commands, sometimes i mess up, see, and i wanna reboot to get the system back to a known state, right
and even if the system is in an unknown or invalid state, right,
i don’t wanna wait half a bloody hour for systemd to get tired of waiting for 1m30s countdowns and actually bounce the damn machine, if it bounces at all
and i can’t just hold the power button, see, because i’m 2000 miles away from the bloody box
(I did not make that number up, by the way. I once has a hard drive get hot removed while it was mounted, couldn’t umount it so I had to reboot, and it confused systemd so bad it took 27 minutes to shut down)
EDIT: aw come on, are you really gonna downvote without leaving a reply?
I can quite clearly remember the long shutdown times back when Ubuntu was still using Upstart.
Generally speaking, long shutdown times are an indication of a system issue (e.g. HDD going bad or slow network) or just scripts being written poorly, and could be worked around by changing the timeout value. Systemd defaults to 90 seconds, but you can change that to 30 secs or lower.
Every new tools (especially those being pushed by big corporations) meets resistance and suspicion. It’s a new thing to learn instead of something proven to work, usually more resource-hungry…
I don’t have anything against systemd that is until I tried void linux for the first time. The working of runit seemed very simple and efficient compared to the complexity of systemd.
I still don’t hate systemd, but I just wish it was simpler.
And most importantly you don’t have to deal with things like environment variables or other session state leaking into your startup scripts as you had with all the init script based init systems.
I seriously do not miss services that worked when starting them from an ssh session but did not work on startup (because e.g. PATH had fewer directories).
Roughly speaking, it is because it does not follow the Unix philosophy and proposes to do several tasks making the code very complex and therefore more susceptible to bugs.
As opposed to which other tools that respect Unix philosophy. Philosophy which I might add is severely outdated. That could have been a thing when you have simple command line interfaces but pretty much every application today violates that philosophy and nothing of value was lost.
The joke being “systemd does everything poorly”. First heard someone say this about X and Wayland. People were saying Wayland violated Unix philosophy and the speaker said “name one thing X does well” lol.
The linux kernel unfortunately does not follow unix philosophy.
It would be better in various ways if the linux kernel used a micro kernel architecture following the unix philosophy, something Torwalds acknowledged in the past.
Philosophical ideas being lost does not mean they’re outdated.
How old in the past did Linus acknowledge it? my source says he dislikes/disliked microkernel, it dates to 2001 ,if you have a more recent source proving that he no longer thinks it I’ll look at it
Unfortunately I can’t remember the timestamp, but it’s right around when he starts speaking about when the MINIX creator bashed him, IIRC (not to bash on you, but this implies the point you’re making, that Linux shouldn’t have a monolithic kernel is 30 years old,)
Systemd was half baked literally when it came out and figuratively as an idea, so much so that there’s already a replacement for it in the works.
A longer version:
Systemd replaced the init script style of boot and process management, which had been in place for decades. init scripts were so simple they could be understood just by looking at the name: the computer is Initialized by Scripts. Systemd was much more complex and allowed many more tools to interact with the different parts of the computer, but people had to learn these tools. Previously all a person had to understand to deal with the computer was how to edit a text file and what various commands and programs did. After systemd a person has to understand how to use the dozens of invocations of systemctl and it’s variants and if they are dealing with a problem, —you know, the only reason a person would ever be dealing with initializing services— they gotta know what’s going on with the text files that systemd uses to run different commands and programs.
So a person who already understood what was going on might rightly say “hey, this systemd thing is just the same shit with different file locations and more to learn”.
People complain about the creator and maintainer of systemd, lennart poettering . Poettering is also the person behind pulseaudio, an powerful but complex audio management daemon in Linux whose name you only recognize because it’s caused you no end of trouble. Pulseaudio was also replaced relatively quickly by pipewire.
The argument could be made (and probably has) that poetterings work is indicative of the problems with foss developers working as employees of major companies with their job responsibilities inclusive of their foss projects. The developer in that situation has an incentive to make big sweeping changes, they’re being paid for it after all, instead of being more careful and measured.
When every big foss maintainer is trying to find a way to justify being paid for it, their projects are never done.
At least poettering is working for Microsoft, ruining windows now…
E: oh my god I forgot about the binary log files! So before (and now), the universal format for log files was plain text. You know, because it’s a log that’s text. Systemd uses binary log files that need a special tool to open and parse. So if you want to look through them on a computer without that tool you’re kinda screwed. Now systemd isn’t the only software package with binary log files, but many people have made the very persuasive argument that it’s not a trait to copy.
E2: actually spelled the man’s name right. Thanks @floofloof !
To ask a different question… what was wrong with initd? I’m the better part of a decade stale at this point but I don’t know that I ever ran into an edge case that initd couldn’t handle with a little massaging
When systemd first showed up there wasn’t much parallelized init systems. People managing complex systems with many services may find the tools of systemd make their lives easier. Of course, nowadays all that complex multi service machine stuff is containerized and none of those containers run systemd 🤔
If I were gonna psychologize it, poettering and kay typify what the Linux user of the 0s felt when they actually looked at what windows of the time had going on under the hood. “Look at you, tla username, pathetic creature of twenty text files under a trench coat!”
The problem with that sentiment is that there’s an honesty to recognizing and accepting that you’re not too far removed from the z80 and it keeps you from believing all this computer stuff is more than it’s cracked up to be.
No one who’s happy with python also keeps a loaded gun next to the server for when it acts up and that’s the problem.
Pulseaudio was also replaced relatively quickly by pipewire.
I really wouldn’t say that… PulseAudio has been around since like 2004, and PipeWire’s initial release was in 2017 (13 years later). I don’t think PulseAudio was incorporated into most distros by default until like 2007 or so, but that’s still 10 years before PipeWire was even released. PipeWire is only recently becoming the default in popular distros. We’ve had to deal with Pulse for a long time.
pulseaudio, an powerful but complex audio management daemon in Linux whose name you only recognize because it’s caused you no end of trouble. Pulseaudio was also replaced relatively quickly by pipewire.
PulseAudio never gave me trouble but I guess I’m just lucky or some shit. Also PipeWire took forever to come out.
In games after I press button to shoot, animation plays and then eternity later comes shooting sound when animation ends. JACK compared to PA is super responsive in games, direct ALSA reduces lag by additional 15ms.
Oh man you reminded me of bad init scripts that would prevent you from getting to multi-user login. I hope you remembered your root password so you can get into single user mode!
The log files only have binary markers within the text. You could run the raw log files through strings and get the plain log files with everything important intact.
Pottering is also the person behind pulseaudio, an powerful but complex audio management daemon in Linux whose name you only recognize because it’s caused you no end of trouble. Pulseaudio was also replaced relatively quickly by pipewire.
Powerful? No, JACK is more powerful and was created 2 years before pulseaudio.
For context back then OSS was primary audio api, and unlike ALSA it did not have software mixing. So sound servers were created. Lots of sound servers, so it was and still it yet another sound server without extra functionality. Meanwhile dmix existed since at least 2001 and JACK allowed route output of one application to input of another.
At least pottering is working for Microsoft, ruining windows now…
They weren’t that bad. You had to look in like 3 places, depending on the distro, but you could find them. And you could see exactly what they were doing once you found them.
systemd gets a job done but I’d much prefer something simpler.
Yep, to add on as well as summarized this… Linux has historically had a design methodology of “everything is a file”. If your not familear with the implications of this, it means your command line tools just kind of work with most things, and everything is easy to find.
For instance, there’s no “registry / regedit” on Linux… There’s just a folder with a config file that the application stores settings in. There’s no control panel application to modify your network settings… Just a text file on your OS. Your system logs and startup tasks were also (you guessed it) sinole filea on the system. Sure there might be GUI apps to make these things easier for users, but under the hood it reads and writes a file.
This idea goes further than you might assume. Your hard drive is a file on the file system (a special file called a block device). You can do something like “mount /dev/sda1 /home/myuser/some_folder” to “attach” the drive to a folder on the system, but that special block device (dev/sda1 in this case) can be read and written to byte by byte if you want with low level tools like dd.
Even an audio card output can show as a file in dev (this is less the case now with pipewire and pulse), but you used to be able to just echo a raw audio file (like a wav file) and redirect the output to your audio device “file” and it would play out your speaker.
Systemd flipped this all around, and now instead of just changing files, you have to use applications to specify changes to your system. Want to stop something from starting? Well, it used to be that you just move it out of the init directory, but now you have to know to “systemctl disable something.service”, or to view logs " journalctl -idk something.service" I dont even remember the flags for specifying a service, so I have to look it up, where it used to just be looking at a file (and maybe use grep to search for something specific)
Want to stop something from starting? Well, it used to be that you just move it out of the init directory, but now you have to know to “systemctl disable something.service”,
That is still the case, nothing stops you from manually moving a file and its dependencies into or out of /etc/systemd/system/
Systemd flipped this all around, and now instead of just changing files, you have to use applications to specify changes to your system. Want to stop something from starting? Well, it used to be that you just move it out of the init directory, but now you have to know to “systemctl disable something.service”, or to view logs " journalctl -idk something.service" I dont even remember the flags for specifying a service, so I have to look it up, where it used to just be looking at a file (and maybe use grep to search for something specific)
not true, SystemD still uses files for this very reason…
and what is the last time you used the text version of a syslog.8.xz file?
you are basically complaining that you need to learn how your system works… before you can use it. and there is nothing preventing you from making your own distro that doesn’t uses SystemD, or using rSyslog instead of systemd-journal for logging.
want to see the status of a daemon : systemctl status want it for the system systemctl statuswant to see the logs of only a specific daemon journalctl -xefu . this all, means that its easier to find the logs for diffrent services since there not scattered somewhere in the /var/log dir… (is it in the syslog, does it have its own log file, is it in the kernel log)…
You are free to setup your system in whatever way you like… but whining about that something works differently is “Microsoft mentality”… lets leave that with them.
Not the really the point of your post but I personally tend to use journalctl -fu something.service. That brings you to the end of the logs for that unit and I get to smile about flipping off systemd.
Systemd flipped this all around, and now instead of just changing files, you have to use applications to specify changes to your system. Want to stop something from starting? Well, it used to be that you just move it out of the init directory…
Enable and disable just create symlinks of the “just changing files” files in your example. It tells you this every time you install something that enables a service.
Want to do it manually? ln -s (or rm the link to “disable” it).
Want it to happen later in the init sequence? Put the link in a different .target directory.
All “systemctl enable” does is put the symlink in the target directory that’s specified in the Install section of the unit file.
As for “specifying a service”… Everything is a unit file (yes, file), journalctl -u just means “only show me logs for this unit”.
There’s no flag for “specifying a service”, you just type in the service name. If there’s any ambiguity (eg. unit.service and unit.socket), you type the service name followed by .service
A flag you might find useful is -g, which means “grep for this string”. You can combine this with -u to narrow it down.
init scripts were so simple they could be understood just by looking at the name: the computer is Initialized by Scripts. Systemd was much more complex and allowed many more tools to interact with the different parts of the computer, but people had to learn these tools. Previously all a person had to understand to deal with the computer was how to edit a text file and what various commands and programs did.
It’s complex because it solves a complex problem. before people had to hack that together with complex init scripts, now they can let systemd do the hard work.
so “relatively quickly” is a time span of 13 years in your idea… or the difference between 2004 and 2017.
if that’s your level of detail… your whole “rant” is worthless…
But lets be generous and look into it,
init scripts were so simple they could be understood just by looking at the name
this is blatantly false, for the old system you need to know about runlevels, what they mean, how the half backed init annotations work, and its dependency check works.
<span style="font-style:italic;color:#969896;">### BEGIN INIT INFO
</span><span style="font-style:italic;color:#969896;"># Provides: myrec
</span><span style="font-style:italic;color:#969896;"># Required-Start: $all
</span><span style="font-style:italic;color:#969896;"># Required-Stop:
</span><span style="font-style:italic;color:#969896;"># Default-Start: 2 3 4 5
</span><span style="font-style:italic;color:#969896;"># Default-Stop:
</span><span style="font-style:italic;color:#969896;"># Short-Description: your description here
</span><span style="font-style:italic;color:#969896;">### END INIT INFO
</span>
you needed special tools to watch if an application actually was running and not crashed, and to keep it running.
add to that that the difference between systemd.service file and a sysv / init / initd script is more or less the same complexity (just different standards).
the universal format for log files was plain text false, the universal format for logging was plain text…
which is currently (slowly) getting replaced with structured logging. (which is objectively better, imho). there are a number of different log formats, most use a binary (compressed) format. logging to plain text was generally only used for the most recent log entries. a binary format for logging, as long as there’s is tooling to get it to a (structured) textual output, is better than a pure text log. I mean, if its good enough for MySQL / MariaDB it ought to be good enough for you…
SysV was just intuitive for me and my knowledge. There was just one directory with all the startup scripts in it. And they were run in their alphanumerical ordner. Just that simple. If I wanted to change the order in which the scripts started, I just had to rename the file. You don’t want a script to run at all? Just remove it.
I assume, systemd has many advantages for a knowledged user. But for me, it still is just a hassle.
Never really, because they don’t contain logic. You craft a command line and stuff works.
The problem with sysv was that almost all of the logic lived in the scripts. They all worked slightly different and all the duplication introduced bugs. Systemd has APIs that take over all the duplicated stuff and implement it once. Bugs have to get fixed once only.
I just debuged it like every other of my scripts that failed. Again, I didn’t need any special knowledge of the init process, just general (and for me: very limited) knowledge.
The answer to your other questions: I don’t thing I ever did that.
I think the main difference is that one option is easier for the end user to occasionally take a look at what’s happening and debug without needing much context or previous knowledge, while the other is much easier for the actual maintainer to actually keep the thing working properly and predictably, as well as supporting every sort of edge case for their users in advance.
An exaggerated stupid analogy: “back in the day we had horse carts and if it wasn’t moving we could just look at the tires to check if they were stuck in a hole or blocked by some rock, but now with cars there are so many things going on that the tires depend on some internal parts that are connected to an engine that depend on some fuel and there are so many elements that can go wrong in-between that often if the car is not moving it requires someone with very specific expertise to diagnose”
(analogy is extra stupid because the horse cart is by nature inferior to the car and this is not the case with the init files and systemd, analogy would work better if the cart still had engines and fuel but that operated with the same simplify as the carts tires).
Add comment