@technicallydifficult >systemd is the best example of Suck.
this should be self-explanatory, but suck is these guys' word for software that's too complicated and tries to be too clever instead of just having a single, clearly defined purpose and executing it precisely. they aren't all talk either. their whole schtick is that they make software out the wazoo that conforms to their ideals so you know exactly what they mean when they say something "sucks".
@dcc would be the guy to ask about the details of the suckless philosophy since he, to my knowledge, is fairly involved in those circles.
you mentioned you don't understand a lot of stuff on these guys' website. that's because they're enthusiasts and they're writing for enthusiasts, not beginners. i promise it's not too difficult to understand if you just stick around, though i fully understand if this isn't your interest in the first place -- not everybody cares about minimalism, and you seem to care more about your software working than about the minutiae of correct design. still, i recommend understanding it for the same reason i try to understand meter and music theory -- for its own sake and out of respect for any future works you might consume, that you may appreciate the craft behind them.
>There is a menace which is spreading like a disease throughout the Linux world, it is called systemd.
again, self-explanatory. these guys don't like systemd. more on that in a minute.
>Short Historical Summary
>systemd is a replacement for the standard init command, which normally runs as process id 1 on initialisation of a UNIX bootup.
you boot up your computer, and one of the first things that runs is this init system thingy. its job is to start and manage certain processes that need to be started and kept alive at bootup, such as (again) your display manager, your network manager, etc.
systemd is a piece of software that is written for this purpose. it is therefore in the same category as s6, openrc, etc. you can only have one init system at a time.
>There has been a movement, especially around the Red Hat-related developers to copy Microsoft Windows and all of its features.
this is a relevant tangent. the author is setting up the antagonist. red hat is an "open source software" organization whose purpose is the corporatization and goysloppification of gnu.
>Now this interpretation of how a userspace should look like is implemented and was introduced with big criticism and change in the Open Source world into many distributions.
the phrasing here is kind of esl, so i'll reword it somewhat: this idea of having a 1:1 windows-like experience, down to the impossible-to-debug errors, is a massive and unwelcome change in the world of free software and unix-like operating systems. we didn't want it, but corproate pressures and funding all seemed to force it through anyway.
>The debacle in Debian is the best example in how to not introduce such a changing technology into a distribution.
this is a historical anecdote. the way debian pushed systemd as its only available init, in what i can only describe as the software equivalent of a tiktok trend, despite anybody with two braincells to rub together telling them this was a horrible idea and completely unprincipled, was truly a sight to behold.
>What PID 1 Should Do
>When your system boots up the kernel is executing a given binary in its known namespace. To see what are the only tasks the application running as pid 1 has to do, see sinit.
sinit (suckless init) is the suckless guys' init system. like everything else they make, it's hilariously simple and promises nothing other than functioning and being modifiable.
>The SystemD Platform: an Unbiased Critique
this is a dead link, goes nowhere for me, i don't know what is supposed to be here. presumably a restatement of everything that's already been said.
>systemd breaks POSIX IPC
posix is the iso standard to which most modern unix-likes conform. ipc is interprocess communication. posix provides a standard way for processes to talk to each other, and systemd treats this standard with flagrant disregard, breaking functionality. as discussed in the github issue this links to, this makes it difficult to let systemd work with third-party software. for example, i have an init script to run the i2p router, followed by another init script that runs my eepsite server feohtan forked from darkhttpd. i am fairly certain that it would not be as simple to set this up on systemd and that i'd need to carve out special exceptions to run it as a systemd service.
>systemd-logind deletes your message queues
>systemd breaks the mouse(again)
these are fairly arcane treatments of bugs that are hideously relevant to the end user. you want to be able to read message queues and use your mouse, but systemd frequently breaks these exact things.
>systemd does {,U}EFI bootload
>Should systemd's PID be changed from 1 to a negative, or imaginary, number? It now exists before the kernel itself, during a bootup. See also systemd-boot.
this is a tongue-in-cheek statement but the criticism is serious. why is systemd putting itself before boot? it is supposed to initialize software. as in the second of my pictures, what the fuck?
>systemd replaces sudo and su
>Please note the command name, machinectl and its features at the manpage. In exchange for a program which contains sudo, su and kill (and does some functions which historically ssh/telnet did), bare metal users have a tons of bloat and a lot of things to disable, if even possible, useful only to people which deal with virtual machines.
sudo and su are two different ways of achieving the same thing: privilege escalation and de-escalation when executing certain commands. for instance, if you want to move a file into /usr/bin, which in my experience is always write-protected, you can't do that as a normal user. you need to prove you are the administrator of your system. this makes less (but not zero) sense on a single-user laptop but it is very important for shared workstations, which is what unix-likes were originally for.
second line is further context. you're trading the convenience of multiple tools who all have exactly one job they do well for some bloated jack of all trades that doesn't even get used unless you're one specific kind of poweruser
>systemd-journald can do log-rotate
>...
the rest of these are more complaints about systemd doing stuff it has zero business doing. worth noting the following:
>systemd-nspawn can patch at will any kind of file in a container
>Paired with transient units and user escalation performable remotely, this can mean that if you house VPS instances somewhere, your hosting provider has means and tools to spy, modify, delete any kind of content you store there. Encrypt everything, read your TOS.
to reiterate: the base complaint is that if you use docker or any equivalent SYSTEMD CAN JUST PATCH WHATEVER IT WANTS INTO AND OUT OF THAT CONTAINER.
imagine having a software that can do that. running constantly. BEFORE EVEN THE FUCKING KERNEL. now imagine if somebody gave you a modified version with a vulnerability. now imagine somebody figured out how to exploit that vulnerability and put INFINITY MORE VULNERABILITIES ON YOUR SYSTEM.
and now finally realize that IBM/Red Hat has EVERY INCENTIVE ON PLANET EARTH to put backdoors into systemd.
look up whose side IBM was on in the early half of world war two. do you trust that corporation?
>systemd locks down /etc and makes it read-only
/etc is a directory (the correct word for "folder") which contained all miscellaneous files on unix. in unix descendants such as gnu (including gnu/linux), convention has gradually become that /etc contains configuration files that tell various system applications how to behave. these include your shell, your package manager, etc.
/etc also contains information about your timezone, certain system libraries, who can and cannot use sudo (recall, sudo is how you do what normal users aren't permitted to), etc.
systemd once made this read-only. i don't think it does anymore but i wouldn't be surprised if it still did. read-only means you can't change it, full stop.
>systemd hates when you adapt your system (graphics on other than vt1)
linux (yes, linux, this is one of the only things linux does that anything approaching the median user will interact with) gives you multiple virtual terminals. they're bare screens with no windows or decorations of any sort, just a command line.
ideally, i can run `Hyprland` or `startx` on any of them and see a graphical session pop up.
i can do that now.
systemd wouldn't let me do that.
>systemd was introduced to decrease the boot up time. Now that they do not understand all implications and dependencies, let us add some artifical time we found out might work for the developers laptops. More on this small world hypothesis of the systemd developers below.
worth dwelling on this line because it's hilarious. small world hypothesis of systemd developers is a jab at how, mysteriously, systemd adds and removes features based on what would be most convenient for its own developers. almost as if there's only one group of users they care about...
>screen brightness
>Screen brightness is something that should crash your boot up when it is not working.
presented without comment.
>hostnamed
>There really should be a process running which exposes the content of a file. Complexity is without cost.
i trust you're starting to understand the flavor of bitter sarcasm here. that bitterness is hard-won. systemd worked hard to turn people against them. ibm/red hat killed their credibility, and, in their own words: "we worked hard to kill it."
>seqnum removed
>The sequential ordering of requests was one reason why udevd was introduced. Now remove it, because the developer laptops do not have a problem anymore.
this supports the small world hypothesis disucssed above.
>sysv removed
>We have won. Now remove all remains of our defeated enemy as fast as we can. As said in the beginning of the systemd crusade against the UNIX infidels: ยปYou can patch it out.ยซ It is no more there.
sysv was an old unix suite, comprising notably its own init system sysvinit. it predated systemd which was based on taking sysv, and tearing every seam and fissure in it wide open into gaping holes in the fabric of spacetime. also, because such would not produce enough holes, systemd imported more holes from elsewhere.
this line is a jab at systemd for removing the last of the legacy sysv code from systemd -- which feels more like a mฤori mocking the shrunken head of his slain foe than serious software engineering.
>abnormal processes
>Now systemd is getting deep into philosophy. What is ยปabnormalยซ? Well, let us just define it. There is no technical merit to accept this.
again, ibm think they know better than you.
>journald
>This is a bit longer. Because the systemd developers were not able to contribute to any syslog daemon they had to write their own with some binary format so the principle of being able to read your log files after a critical crash was violated. To be nice invaders the old systems were allowed to order the system log through the specified mechanism. Now that they implemented our specifics, turn off the neutral syslog delivery. You will see this pattern of ยปnow that we conquered your culture, obeyยซ more often in systemd.
no comment
>systemd-terminal
>Why does the kernel have tty handling? So in serious situations you will be able to debug it over the last standing PIN on your motherboard. Let us remove this, run it in pid 1.
no comment
>Timezone hack
>systemd is too complex for such a simple transaction with the kernel. Do not inform the kernel and add another assumption which is only documented in the changelog.
no comment
>the web is a session
>For the future generations: In 2015 nearly everyone was trying to connect all you do to the web. In the UNIX model it is just a client which should be simple and integrate into the system. systemd is doing it the other way around and does integrate itself into the web.
again, no comment.
>We have taken over your culture, now die! Another flaw in the systemd small world theory: When something is getting optional it will be removed.
this is preserved orphaned because it is simply eternally relevant.
>X11 in systemd
X11 is a protocol that lets certain applications present as windows if an x11 session is currently running, managed by the user through the window manager.
why does my init system speak something like X11 which is a good five, six layers of abstraction above its pay grade?
>Practical systemd
>Here is what happens on a stock Arch Linux system, powered by systemd, when a non-root user tries to restart the system:
>$ reboot
<Failed to set wall message, ignoring: The name org.freedesktop.PolicyKit1 was not provided by any .service files
<Failed to reboot system via logind: The name org.freedesktop.PolicyKit1 was not provided by any .service files
<Failed to talk to init daemon.
>In contrast, here is the equivalent error message on a system powered by runit:
>$ reboot
<init: fatal: unable to create /etc/runit/stopit: access denied
>And on the oldest and best, Slackware:
>$ reboot
<reboot: must be superuser.
>systemd is driving "just google the problem" attitude, because how the hell are you expected to troubleshoot this kind of error otherwise?
this section is self-explanatory. if you don't understand, the point is that when something goes wrong, the error message should tell you what you did wrong and give you a way to fix it (to the extent that is possible)
slackware does this.
runit does this, kinda. "access denied" tells you that you want to do an auth step.
systemd does not do this. it vomits numbers and words at you.