1. 44
  1. 50

    Honestly I think that suckless page is a terrible criticism of systemd. It’s the kind of rantings that are easy to dismiss.

    A much better – and shorter – criticism of systemd is that for most people, it does a lot of stuff they just don’t need, adding to a lot of complexity. As a user, I use systemd, runit, and OpenRC, and I barely notice the difference: they all work well. Except when something goes wrong, in which case it’s so much harder to figure out systemd than runit or OpenRC.

    Things like “systemd does UNIX nice” are rather unimportant details.

    I’m a big suckless fan, but this is not suckless at their best.

    1. 11

      A much better – and shorter – criticism of systemd is that for most people, it does a lot of stuff they just don’t need, adding to a lot of complexity.

      How many things does the Linux kernel support that you don’t use or need, and how many lines of code in the kernel exist to support those things?

      1. 3

        If we’re going there, we might as well mention that Linux supports a whole freaking lot of hardware I don’t need. Those are most probably the biggest source of complexity in the kernel. Solving that alone would unlock many other thing, but unfortunately, with the exception of CPUs the interface to hardware isn’t an ISA, it’s an API.

        1. 5

          If we’re going there, we might as well mention that Linux supports a whole freaking lot of hardware I don’t need.

          While, simultaneously, not supporting all the hardware that you want.

          I think it’s a good example that the Linux model is culturally inclined to build monolithic software blocks.

          1. 7

            While, simultaneously, not supporting all the hardware that you want.

            Ah, that old bias:

            • Hardware does not work on Windows? It’s the hardware vendor’s fault.
            • Hardware does not work on Linux? It’s Linux’s fault.

            We could say the problem is Linux having a small market share. I think the deeper problem is the unbelievable, and now more and more unjustified, diversity in hardware interfaces. We should be able by now be able to specify sane, unified, yet efficient hardware interfaces for pretty much anything. We’ve done it for mouses and keyboards, we can generalise. Even graphics cards, which are likely hardest to deal with because of their unique performance constraints, are becoming uniform enough that standardising a hardware interface makes sense now.

            Imagine the result: one CPU ISA (x86-64, though far from ideal, currently is it), one graphics card ISA, one sound card ISA, one hard drive ISA, one webcam ISA… You get the idea. Do that, and suddenly writing an OS from scratch is easy instead of utterly intractable. Games could take over the hardware. Hypervisors would no longer be limited to bog standard server racks. Performance wouldn’t be wasted on a humongous pile of subsystems most single applications don’t need. Programs could sit on a reliable bed rock again (expensive recalls made hardware vendors better at testing their stuff).

            But first, we need hardware vendors to actually come up with a reasonable and open hardware interface. Just give buffers to write to, and a specification of the data format for those buffers. Should be no harder than to write an OpenGL driver with God knows how many game specific fixes.

            1. 8

              Nah, that’s not what I’m implying. It’s not Linux fault, it’s still a major practical sore from a users perspective. I’m well aware that this is mainly the hardware vendors fault in all cases.

              Also, it should be noted that Linux kernel development is in huge parts driven by exactly those vendors, so even if it were Linux fault, there’s a substantial overlap.

              It’s still amazing how much of hardware is supported in the kernel, of very varying quality and is committed to be maintained.

              1. 3

                It’s still amazing how much of hardware is supported in the kernel, of very varying quality and is committed to be maintained.

                One thing that amused me recently was the addition of SGI Octane support in Linux 5.5, hardware that’s basically extinct since 2 decades and was never particular popular to begin with. But the quixotism of this is oddly endearing.

                1. 2

                  was never particular popular to begin with

                  Hey, popular isn’t always the best metric. SGI’s systems were used by smart folks to produce a lot of interesting stuff. Their graphics and NUMA architecture were forward-thinking with me still wanting their NUMAlink on the cheap.The Octanes been behind a lot of movies. I think the plane scene in Fight Club was SGI, too. My favorite was SGI’s Onyx2 being used for Final Fantasy given how visually groundbreaking it was at the time. First time I saw someone mistake a CG guy for a real person.

          2. 2

            Device drivers are the most modular part of the kernel. Don’t compile them if you don’t want them

            1. 1

              True, but (i) pick & choose isn’t really the default, and (ii) implementing all those drivers is a mandatory, unavoidable part of writing an OS.

              I don’t really care that the drives are there, actually. My real problem is the fact they need to be there. There’s no way to trim that fat without collaboration from hardware vendors.

              1. 1

                Well mainstream distribution kernels are still built modularly and the device driver modules are only loaded if you actually have hardware that needs them, at least as far as I understand it.

                I don’t really care that the drives are there, actually. My real problem is the fact they need to be there. There’s no way to trim that fat without collaboration from hardware vendors.

                Yeah that is a big PITA. It’s getting worse, too. It used to be that every mouse would work with basically one mouse driver. Now you need special drivers for every mouse because they all have a pile of proprietary interfaces for specifying LED colours and colour patterns, different special keys, etc.

          3. 3

            a lot, and it’s also a criticism of linux. but sometimes people must use linux, and now sometimes people must use systemd.

            linux’s extra features are also much better modularized and can be left out, unlike systemd’s.

            1. 3

              linux’s extra features are also much better modularized and can be left out, unlike systemd’s.

              But they can. The linked article describes that many of the features that people wrongly claim PID1 now does are just modules. For example you don’t have to use systemd-timesyncd, but you can and it works way better on the desktop than the regular server-grade NTP implementations.

              1. 2

                I’m sorry but how does syncing time every once in a while get much improved by systemd-timesyncd? NTP is like the least of my worries.

                1. 2

                  Somehow my computer was insisting on being 2 minutes off and even if I synced manually and wrote to my BIOS RTC clock NTPd and chrony were insisting on messing it up (and then possibly giving up since the jump was 2 minutes). Both these daemons feel like they aren’t good matches on a system that’s not on 24/7.

                  1. 2

                    sounds like a configuration issue and nothing to do with the program itself. what distro did you use ntpd and chrony with? what distro are you using systemd-timesyncd with?

                    by default, void linux starts ntpd with the -g option which allows the first time adjustment to be big.

          4. 7

            And there are no real alternatives to a full system layer. I like runit and openrc and I use them both (on my Void laptop and Gentoo desktop). When I use Debian or Ubuntu at work, for the most part I don’t have to worry about systemd, until I try to remember how to pull up a startup log.

            systemctl/journalctl are poorly designed and I often feel like I’m fighting them to get the information I really need. I really just prefer a regular syslog + logrotate.

            It’d be different if dbus had different role endpoints and you could assign a daemon to fulfill all network role messages and people could use NetworkManager or systemd-networking or … same with systemd being another xinitd type provider and everything get funneled through a communication layer.

            Systemd is everything, and when you start going down that route, it’s like AWS really. You get locked in and you can’t easily get out.

            1. 5

              As a note to those reading: there is murmur of creating a slimmed down systemd standard. I think it’d satisfy everyone. Look around and you’ll find the discussions.

              1. 4

                I can’t really find anything about that at a moment’s notice other than this Rust rewrite; is that what you mean?

                Personally, I think a lot of fundamental design decisions of systemd make it complex (e.g. unit files are fundamentally a lot more complex than the shell script approach in runit), and I’m not sure how much a “systemd-light” would be an improvement.

                1. 17

                  As someone who just writes very basic unit files (for running IRC bots, etc). I find them a lot simpler than shell scripts. Everything is handled for me, including automatically restarting the thing after a timeout, logging, etc. without having to write shell scripts with all the associated bugs and shortcomings.

                  1. 12

                    Have you used runit? That does all of that as well. Don’t mistake “shell script approach” with “the SysV init system approach”. They both use shell scripts, but are fundamentally different in almost every other respect (in quite a few ways, runit is more similar to systemd than it is to SysV init).

                    As a simple example, here is the entire sshd script:

                    ssh-keygen -A >/dev/null 2>&1 # Will generate host keys if they don't already exist
                    [ -r conf ] && . ./conf
                    exec /usr/bin/sshd -D $OPTS

                    For your IRC bot, it would just be something like exec chpst -u user:group ircbot. Personally, I think it’s a lot easier than parsing and interpreting unit files (and more importantly, a lot easier to debug once things go wrong).

                    My aim here isn’t necessarily to convince anyone to use runit btw, just want to explain there are alternative approaches that bring many of the advantages that systemd gives, without all the complexity.

                    1. 2

                      I have never tried it. But then, if it’s a toplevel command, not even in functions, how can you specify dependencies, restart after timeout, etc.? It seems suspiciously too simple :-)

                      1. 3

                        Most of the time I don’t bother with specifying dependencies, because if it fails then it will just try again and modern systems are so fast that it rarely fails in the first place.

                        But you can just wait for a service:

                        sv check dhcpcd || (sleep 5; exit 1)
                        sv check wpa_supplicant || (sleep 5; exit 1)
                        exec what_i_want_to_run

                        It also exposes some interfaces via a supervise directory, where you can read the status, write to change the status, roughly similar to /proc. This provides a convenient platform-agnostic API in case you need to do advanced stuff or want to write your own tooling.

                        1. 25

                          No offense, but this snippet alone convinces me that I’m better off using systemd’s declarative unit files (as I am doing currently, with for similar uses than @c-cube ‘s). I’ve never been comfortable with the shell semantics generally speaking, and overall this feels rather fiddly and hackish. I’d rather just not have to think about it, and have systemd (or anything similar) do it for me.

                          1. 5

                            Well, the problem with Unit files is that you have to rely on a huge parser and interpreter from systemd to do what you want, which is hugely opaque, has a unique syntax, etc. The documentation for just systemd.unit(5) it is almost 7,000 words. I don’t see how you can “not have to think” about it?

                            Whereas composition from small tools in a shell script is very transparent, easy to debug, and in essence much easier to use. I don’t know what’s “fiddly and hackish” about it? What does “hackish” even mean in this context? What exactly is “fiddly”?

                            Like I said before, systemd works great when it works, it’s when it doesn’t work. I’ve never been able to debug systemd issues without the help of The Internet because it requires quite specific and deep knowledge, and you can never really be certain if the behaviour is a bug or error on your part.

                            1. 13

                              Well, the problem with Unit files is that you have to rely on a huge parser and interpreter from systemd to do what you want, which is hugely opaque, has a unique syntax, etc. The documentation for just systemd.unit(5) it is almost 7,000 words. I don’t see how you can “not have to think” about it?

                              To me it seems a bit weird to complain about the unit file parser but then just let the oddly unique and terrible Unix shell syntax just get a free pass. If I were to pick which is easier to parse, my money would be on unit files.

                              Plus, each shell command has its own flags and some have rather intricate internal DSLs (find, dd or jq come to mind).

                              1. 2

                                The thing with shell scripts is that they’re a “universal” tool. I’d much rather learn one universal tool well instead of many superficially.

                                I agree shell scripts aren’t perfect; I’m not sure what (mature) alternatives there are? People have talked about Oil here a few times, so perhaps that’s an option.

                                1. 10

                                  The thing with shell scripts is that they’re a “universal” tool.

                                  But why do you even want that in an init system? The task is to launch processes, which is fairly mundane except having lots of rough edges. With shell scripts you end up reinventing half of it badly and hand-waving away the issues that remain because a nicer solution in shell would be thousands of lines and not readable at all.

                                  I would actually my tools to be less turing-complete and give me more things I can reason about. With unit files it is easier to reason about and see that they are correct (since the majority functionality is implemented in the process launcher and if bugs there are fixed it fixes them in all unit files).

                                  I actually don’t get the sudden hate for configuration files, since sendmail, postfix, Apache, etc all have their configuration formats instead of launching scripts to handle HTTP, SMTP and whatnot. The only software I have in recent memory that you configure with code is xmonad.

                                  1. 1

                                    I wrote a somewhat lengthy reply to this this morning, but then my laptop ran out of battery (I’m stupid and forgot to plug it in) so I lost it :-(

                                    Briefly: to be honest, I think you’re thinking too much about SysV init style shell scripts. In systems like runit/daemontools, you rarely implement logic in shell scripts. In practice the shell scripts tend to be just a one-liner which runs a program. Almost all of the details are handles by runit, not the shell script, just like with systemd.

                                    In runit, launching an external process – which doesn’t even need to be a shell script per-se, but can be anything – is just a way to have some barrier/separation of concerns. It’s interesting you mention postfix, because that’s actually quite similar in how it calls a lot of external programs which you can replace with $anything (and in some complex setups, I have actually replaced this with some simple shell scripts!)

                                    I agree the SysV init system sucked for pretty much the same reasons as you said, and would generally prefer systemd over that, but runit is fundamentally different in almost every conceivable way.

                                    1. 1

                                      Is runit supported by any mainstream distro?

                                      1. 1

                                        Void uses it by default; I’ve also used it on Alpine Linux and Arch Linux where I just have OpenRC or systemd start runit and then use that for most things.

                                  2. 6

                                    This is hardly unique to systemd unit files, though.

                                    /etc/fstab is a good example of something old. There’s nothing stopping it from being a shell script with a bunch of mount commands. Instead, it has its own file format that’s been ad-hoc extended multiple times, its own weird way of escaping spaces and tabs in filenames (I had to open the manpage to find this; it’s \040 for space and \011 for tab), and a bunch of things don’t wind up using it for various good reasons (you can’t use /etc/fstab to mount /etc, obviously).

                                    But the advantage? Since it doesn’t have things like variables and control flow, it’s easy to modify automatically, and basic parsing gives you plenty of useful information. You want to mount a bunch of different filesystems concurrently? Go ahead; there’s nothing stopping you (which is, of course, why systemd replaced all those shell scripts while leaving fstab as-is).

                                    In other words: banal argument in favour of declarative file formats instead of scripts.

                                2. 5

                                  I don’t know what’s “fiddly and hackish” about it?

                                  It’s fiddly, because you can’t use any automatic tool to parse the list of dependencies, and it’s hackish, because the build system doesn’t know what it’s doing, it just retries starting random services until it matches the proper order. It’s nondeterministic, so it’s impossible to debug in case of any problems.

                                  1. 3

                                    You can pipe it through grep, c’mon dude. And framing it as “starting random services” is just wrong, that’s the opposite of what’s happening.

                                    1. 6

                                      And framing it as “starting random services” is just wrong, that’s the opposite of what’s happening.

                                      This doesn’t look very convincing ;)

                                      Well, you can cat the startup script and see the list of dependencies if you’re only worried by one machine. But from the point of view of a developer, supporting automatic parsing of such startup scripts is impossible, because it’s defined by a Turing-complete language.

                                      Again, it’s still fine if you’re an administrator of just one machine (i.e. you’re the only user). But it’s not an optimized method when you have farms of servers (physical or VMs), and that’s the majority of cases where UNIX systems are used.

                                      Also it’s easier to install some rootkit inside shell scripts, because it’s impossible to reliably scan a bash script for undesirable command injections.

                                  2. 3

                                    While I agree that systemd.unit files syntax sometimes is weird and I would much more prefer for it to use for example TOML instead, I do not think that shell syntax is any better. TBH it is even more confusing sometimes (as @Leonidas said).

                                  3. 6

                                    I’d rather just not have to think about it, and have systemd (or anything similar) do it for me.

                                    Don’t be surprised when you pay the price this thread speaks of for the privilege of thinking slightly less ;)

                                    1. 10

                                      Sometimes abstractions are, in fact, good. I am glad I don’t have to think how my CPU actually works. And starting services is such a run-off the mill job that I don’t want to write a program that will start my service, I just want to configure how to do it.

                                    2. 3

                                      Dependencies in general are a mistake in init systems: Restarting services means that your code needs to handle unavailability anyways – so use that to simplify the init system. As a bonus, you ensure that the code paths to deal with dependencies restarting gets exercised.

                          2. 2

                            I really like systemd’s service files for the simple stuff I need to do with them (basically: execute daemon command, set user/group permission, working dir, dependencies, PID file location, that’s it). But there are other aspects of systemd I dislike. I wish someone would implement a service file parser for something like OpenRC that supports at least those basic systemd service files. It would ease cooperation among init systems quite a bit I think and make switching easier. It would also ease the life of alternative init system makers, because many upstream projects provide systemd service files already.

                          3. 4

                            A much better – and shorter – criticism of systemd is that for most people, it does a lot of stuff they just don’t need, adding to a lot of complexity.

                            This sort of computing minimalism confuses me. Should we say the exact same about the computing platforms themselves? x86 has a lot of things we don’t need so we should simply use a RISC until you need just the right parts of x86… That motherboard has too many PCI slots, I’m going to have to rule it out for one with precisely the right amount of PCI slots… If you can accomplish the task with exactly a stick and a rock why are you even using a hammer, you fool!

                            1. 3

                              It’s really a long-standing principle in engineering to make things as simple as feasible and reduce the number of moving parts. It’s cheaper to produce, less likely to break, easier to fix, etc. There is nothing unique about software in this regard really.

                              I never claimed to be in favour of absolute minimalism over anything else.

                              1. 4

                                It’s not ‘minimalism’ that makes me balk at systemd’s complexity. It’s that that complexity translates directly to security holes.

                            2. 57

                              systemd solves some very real problems that absolutely, 100% needed to be solved.

                              The problem is that it also solves a lot of problems that were already solved.

                              1. 17

                                And creates some new problems with its “solutions” to some of the old already-solved problems.

                                1. 5

                                  what problems absolutely 100% needed to be solved?

                                  1. 7

                                    A unified way to setup an auto start mechanism for an application is one example.

                                    1. 8

                                      I yearn for the day when everyone can accept two truths:

                                      1. systemd solves real problems
                                      2. systemd isn’t the unique solution to any problems

                                      It seems like accepting either of them almost universally results in being somehow mentally blocked from accepting the other.

                                      1. 10

                                        Systemd solves problems faced by the companies currently financing most of the development of GNU/Linux.

                                        I’m not implying any moral value in the above statement. It is what it is. Developer time is expensive. The problems systemd aim to solve require time and planning, while traditional FLOSS development is focussed on tools that are loosely coupled to each other.

                                      2. 1

                                        What does that mean? I assume you don’t mean to include init scripts, but as far as I can tell they automatically start applications when run with the “start” argument, which is standardized across a system.

                                    2. 3

                                      The main issue IMO is that the way in which it solves those problems; it is a significant step away from the UNIX way of computing and towards what pappp calls the FLOS way.

                                      1. 2

                                        Since Gancarz’s piece in 1994, Moore’s Law has gone through 17 doublings. Hundreds of millions of people have a Linux in their pocket or purse. Developers routinely run Linux instances in VMs and deploy them in remotely just to run one service.

                                        Linux is a UNIX that has gone from a system designed to be accessed remotely by multiple users, sharing scarce resources (remember disk quotas?) to one that’s embedded into $50 appliances, and running on machines that users expect to be able to close the lid on and make it save its state until its woken up again.

                                        The UNIX way isn’t some law of nature. It’s a stunningly succesful set of design principles, but time and requirements have moved on.

                                    3. 17

                                      After reading this article, I feel like it is just at the same level as the suckless one, just from the other side of the fence.

                                      Most arguments are countered with « I see nothing wrong here », or « nobody needs that anymore ». This simply doesn’t help sorting out the real problem, which is to know wether systemd is helping fix a real problem for each topic, or reinventing the wheel without taking past experience into account.

                                      This post unfortunately falls into the “anti-anti-systemd rant” part of the topic, without bringing much on the table. I have yet to see a somehow neutral article explaining (calmly!) why systemd (as a toolkit, not an init system) took the decision to reimplement every single function from scratch, and what is their goal with this all. I must admit that systemd-hostnamed still look weird to me for example, and make me think they went too far in their design. I do however realise that on their way to being able to handle every single part of the desktop, they need absolute control over everything over a single interface type…

                                      1. 1

                                        After reading this article, I feel like it is just at the same level as the suckless one, just from the other side of the fence.

                                        Exactly. It’s a rant from someone who has strong views, and it descends into flippancy and hyperbole pretty quickly. If systemd was less popular and less all-encompassing I could see people switching sides, but part of the problem stems from distro makers piling on features from systemd that lead to breaking edge cases for people.

                                      2. 16

                                        Moreover we don’t live in 1980 anymore. The view and the purpose of computers had changed completely since this time.

                                        I feel that the view and purpose of computers hasn’t changed too much. We still solve a lot of the same problems, and even work with a lot of the same tools (especially in unixes). How we interact with computers has changed dramatically (see smartphones, the internet), but things on the “system” level are relatively the same. Operating systems try to provide the same higher-level abstractions on processes as they did in 1980.

                                        1. 12

                                          To be fair, the article brings up some strong points, but in the end it all depends on your norms. It’s obvious why suckless disregards systemd, you all know our philosophy. If you’re happy with systemd, keep using it. We won’t be knocking on your door and demand you to uninstall it.

                                          Just don’t complain when Red Hat in the form of Lennart Poettering et. al. centralizes more and more subsystems of the userspace. They started with PulseAudio and systemd, who knows what will come next. What’s really shocking is the indifference toward this hostile (due to corporate interests) takeover. The Linux community has voluntarily put on shackles on itself, and when they sense them in a few years we, and many many others, will have told you so.

                                          Yes, systemd solves some problems, but can we really stomach the baggage it brings to the table? Can’t we as a community come up with a better solution? We have our own proposal: The suckless core, a set of different tools to manage your userspace needs. You can replace any component you like, write your own and improve it. We do not claim it’s an end-all solution, it’s just a proposal. Systemd claims to be an open standard and is theoretically reimplementable as an interface, but have you seen any serious attempt to reimplement this beast?

                                          The flexibility of the userspace is Linux’ both biggest strength, due to adaptability, and weakness, due to fragmentation. We should not throw it away and accept that it’s a difficult problem that needs to be solved differently than with centralization.

                                          1. 3

                                            What’s really shocking is the indifference toward this hostile (due to corporate interests) takeover. The Linux community has voluntarily put on shackles on itself

                                            feel free to not like systemd, but debian, at least, voted overwhelmingly to keep systemd as their main init system. What you call “centralization” is what I call having a computer that actually works. systemd wouldn’t be popular if it didn’t solve real problems that real people have.

                                            1. 4

                                              What you call “centralization” is what I call having a computer that actually works.

                                              The only systems I have ever had that had literally undebuggable problems were computers running systemd. I followed all of the instructions on the arch wiki, and any I could scrounge up elsewhere, and I still have no idea why my one computer running systemd decides to hang for literally 30 minutes randomly on boot, I still don’t know why the other computer, a thinkpad, takes 5 minutes to start up despite having dependency management (compared to my other, much older thinkpad running alpine linux, which takes about 30 seconds to boot up to a terminal, after I toggled with it and removed some blocking processes that are ready by the time I log in anyway), I still have no idea why my network will randomly fail on another computer running Ubuntu, or sometimes the entire computer will just freeze up, leaving me to remember the sysreq keys to reboot it, and sometimes they fail entirely and I just have to power cycle! I have been running linux on almos all these computers for a little over ten years and the only times I have ever had problems of this sort were after systemd was introduced.

                                              I would love to live in this world where, magically, systemd just works.

                                              Even putting all of that aside, whenever I try to futz about with init scripts on the only piece of hardware I have systemd that works reliably, my Pi W, I realise how horrifying the systemd init process is! There are about 3 different places unit files can reside, some of them are symlinks, some of them override others, and (last time I checked) there isn’t a sure way to figure out what part is overriding another part.

                                            2. 1

                                              I agree with most of your points, but indifference? There’s been a pretty vocal opposition to PulseAudio, systemd, etc. Problem is the big bodies like Red Hat just keep going on this course.

                                              Luckily there’s still enough distributions without systemd. I’m personally fond of Void Linux and use OpenBSD on my servers. (Since I can finally play most of my Steam library on Linux I’m not going to make it harder again on myself in that respect.)

                                              1. 2

                                                Maybe I was a bit unclear in this regard. With indifference I addressed the “majority” and those that just accepted this situation. I remember back when Debian adopted systemd there were, of course, the Devuan-forkers, but many many developers who just let it happen and still let it happen, given Debian is currently in the process of rediscussing this choice.

                                                1. 8

                                                  many many developers who just let it happen

                                                  If by letting it happen you mean “explicitly chose to make it happen”; let’s not frame Debian’s adoption of systemd as a thing some people snuck through in through some relatively obscure vote. It was voted for once, adopted and the second, more recent vote reaffirmed to continue with systemd.

                                            3. 12

                                              I don’t like the systemd-resolved, it has caused me a lot of trouble with captive portals.

                                              1. 15

                                                It’s also great fun when you install something yourself like dnsmasq (because you didn’t know that systemd provides its own) and then have to wonder why it doesn’t work or why is it milling one of your CPU cores at 100% – been there, done that. The downside of systemd putting its feet everywhere is that it’s much easier to step on its toes at every opportunity.

                                                1. 9

                                                  wanted to set up unbound on fedora recently. I followed the docs, stuff didn’t work, Networkmanager, dnssec-trigger conflicted, resolv.conf was flaky on a supposedly static setup. Removed the integration to Lennartware, disabled NM managing resolv.conf (it can still be done), and did stuff manually the old way. Works like a charm since then.

                                                  I’m no fan of the direction Linux is heading. The vision would be acceptable for me, but the route taken is duct taping and untested low quality code. This way the road will be long and bumpy, and I’d prefer to stay behind.

                                                  edit: I took a glimpse inside the dnssec-trigger scripts. I demand cleaner and thoroughly tested code from my junior colleagues. (it did not work according to the poor docs)

                                                  1. 9

                                                    NM has a long history of forcefully taking over interfaces and network config. For most folks that just want to ‘get online’ it’s OK and actually pretty easy to use because of it. But the moment you try to do anything more than that, you’re better off completely removing it. At least systemd-network will allow you to do some fairly complex network configurations.

                                                    1. 3


                                                      I should probably have gone that way. For some reason it is using NM currently, and was working since install (only a DHCP config was needed), but when I started to customize it it really bite me. Next time I’ll check that out, because seems far better now after having read about it.

                                                      My only excuse that I haven’t used fedora for 10+ years (only windows, obsd, and other people’s linuxes, which had their networking working ootb/handled by other crew)

                                                2. 11

                                                  suckless might or might not be wrong (I suspect both simultaneously, as this seems absolutely like two arguments flying past each other without even the slightest pretence of engagement one with the together), but this article doesn’t really engage with their argumentation.

                                                  1. 14

                                                    Is this intended to be ironic? After reading this text I feel that systemd is a really poor tool and suckles is right in its criticism.

                                                    1. 14

                                                      Really? I feel the author makes great points all the way down.

                                                      I’ve said this many times and I’ll say it again: systemd is a collection of programs, just like the old systems before it. It’s just more cohesive, which benefits everyone.

                                                      1. 12

                                                        I’m not judging the merits of systemd, but the consistency of the text. It is a sequence of ridiculous non-sequiturs. At the beginning, for example, you find this paragraph:

                                                        First of all: systemd was never, is not and will never be an init system. It is a system-daemon. Thats why it’s called systemd. Moreover we don’t live in 1980 anymore. The view and the purpose of computers had changed completely since this time. We want to have access on logs in pre-early-boot-time and we want to be sure that several things are done during the boot process. Computers are not just a server in some university anymore. Many people use GNU/Linux in their workstations or notebooks nowadays.

                                                        Say what? what does the PID of systemd have to do with reading logs on boot time and running linux on a laptop? Even if I like systemd, it seems that this article is trying to steer me away from it by mocking its staunch defenders.

                                                        1. 5

                                                          and the suckless quoted text isn’t?

                                                          1. 1

                                                            I think they’re talking about writing logs, not reading logs.

                                                          2. 6

                                                            It has some good points, but it also has some parts that make it look like an elaborate joke.

                                                            This is what systemd does because it is increasing the speed a lot. What is nicer than a laptop that boots up in 0.5 seconds?

                                                            Erm… living in a real world? Perhaps I’ve been installing my linuxes wrong for the last 15 years, but I’ve never had one realistically boot under 5, even if I ignore the time spent typing in the LUKS password.

                                                            This blazingly fast bootup may be a real benefit to RedHat and their Openstack clusters, but let’s not pretend that any desktop/laptop user will ever notice or care. The init system is not the slow part of the bootup process.

                                                            1. 2

                                                              Yes it’s an exaggeration. IIRC there was something done awhile ago showing systemd is faster than older init systems, but I agree it’s irrelevant (and may no longer be the case today).

                                                              We can’t forget this is an opinion piece, and what I meant by my comment above is in general the points are good. I understand what they are trying to convey and can separate exaggeration from fact.

                                                              1. 3

                                                                (and may no longer be the case today)

                                                                It was shown to cause issues with certain features, iirc, and the cheat to speed up boot was removed.

                                                                1. 1

                                                                  Not only that, but comparing systemd to sysvinit might have been relevant 10 years ago but it isn’t relevant today.

                                                              2. 1

                                                                It’s a little more cohesive at the cost of being very tightly coupled. That’s not a tradeoff I think is worth making.

                                                            2. 8

                                                              I installed OpenBSD on my laptop today. I was astonished by every stage of the process of setting it up because it was all so simple and easy compared to modern Linux. I ran ps aux and it didn’t even scroll off my screen, much unlike a modern Linux distribution with its dbuses and Kits and systemd-*ds infecting my system with Lennart Poettering’s idea of progress.

                                                              I wrote a whole lot debunking every point made in this article but it just got too long. This article is just fanboyism and it made me feel sick reading it. People parroting ‘systemd can’t do anything right’ is pretty tiring, but people parroting ‘systemd can’t do anything wrong’ is downright dangerous.

                                                              1. 8

                                                                As an OpenBSD enthusiast, and disliking systemd, I find your point unfair.

                                                                Systemd has nothing to do with the simplicity of installation. This is purely the fault of distro makers at this stage, and to be fair. Systemd actually helps making this setup easier (no need to configure DNS for example, because it defaults to google’s. You might not like that default, but it ensure it works on first try). And this is also the case for “non-modern” Linux distros as well (think Gentoo, Slackware, Crux, Alpine, …). Their installation process is pretty complex and none of them use systemd.

                                                                As for the process tree, It is definitely not systemd which makes it unreadable on Linux, it’s the modules. The following is ran on my distro (Crux 3.3), which does not run on systemd, and you can clearly see that ps output is cluttered by the modules:

                                                                $ ps aux | wc -l
                                                                $ ps aux | grep -cE '\[.+\]'

                                                                For reference, my OpenBSD server only counts 42 processes overall.

                                                                As for systemd & friends, while not perfect, it still isn’t that bad (debian 10, buster):

                                                                $ ps aux | grep -cE 'dbus|kit|systemd'

                                                                There are many things that OpenBSD gets better than Linux, starting with modules, security, documentation, configurations, … But SystemD isn’t one of them, because it is a userland Framework. If it was compatible with BSD kernels, it would have been adopted by FreeBSD already, and probably more. Hopefully, they locked themselves with Linux so we’re safe here at least ;)

                                                                The point I am trying to make is that systemd obviously has flaws, both in its design and implementations (reimplementing everything to fit its interface, rather than improving the current tools), but its biggest strength is that it became a flamewar starter over the years, and as nobody can discuss its flaws while remaining calm, they can keep going within this status quo, swallowing and extinguishing everything in their path like it doesn’t matter.

                                                                1. 1

                                                                  It’s not that systemd is responsible for all ill in the Linux world or anything. I think that’s too strong. But systemd is emblematic of the general problems in the Linux world: making everything much too complicated. You can see this whenever you look at any GNU source code. You can see it whenever you try to configure anything. It’s layers upon layers of unnecessary complexity. Gnome is particularly bad here too.

                                                                  Defaulting to google’s DNS is just crazy. I’ve never had to configure DNS in my life and why should I? It defaults to the DNS servers provided by my dhcp server, which should be my ISPs. I wasn’t aware that systemd defaulted to Google’s DNS servers, but if that true then it’s absolutely disgusting. It’s probably the single worst thing systemd has ever done and I’m not joking. Google has far too much of internet traffic already.

                                                                  Making things very slightly easier in the default use case with massive side effects and big costs for every other use case is basically the epitome of systemd’s design philosophy.

                                                                  1. 5

                                                                    The complexity comes from the fact it does not provide a userland, only the kernel. As such, different vendors (GNU, systemd, freedesktop) have to settle on a common interface to make stuff work together. It is a best effort though, as there is no standard beyond POSIX, which has a limited scope. They add layers on top of each others to counter the fact that there are different interfaces, and it’s us, the users, that pay for this added complexity. At least systemd (by swallowing every single project out there) managed to force itself as a common interface. This was needed. But many persons (me included) dislike this new interface.

                                                                    As for the DNS, it would only default to if eveything fails (eg. with static ipv4 and no DNS set manually), and this is only a default value that is possible to change when packaging systemd-resolved IIRC. Of course your DHCP would overwrite it if it sets one. Same with your config filed. Nothing to get mad at really. This is probably the most reliable IP address on the internet, so I can understand why one would settle on it to serve as a default value. I wouldn’t be surprised either to find it in the default resolv.conf of a few distros or livecd.

                                                                    edit: There is also cloudfare in the fallback DNS list: commit def3c7c.

                                                                    Now don’t grt me wrong, we’re on the same side, and I despise systemd. It is opaque, huge, makes bad assumptions about a lot of things and so on… But to demonstrate how it affects the Linux worldin a bad way, we must see the big picture. Every program has flaws, be it systemd, vim or ffmpeg. We shouldn’t point each flaw specifically because we see a problem with it, as each “flaw” can be a “feature” for someone else, it is subjective. What must be pointed at is the impacts it has on the Linux ecosystem as a whole: many distros are disappearing because they don’t want to integrate it, some well established distros that everyone agreed to mark as “robust” now see their community split. Some programs to play videos must rely on an authentication library to run… This sounds wrong, and this is caused not because systemd has a daemon to serve a static file (systemd-hostnamed), this is happening because they are swallowing everything and making the whole framework a hard dependency when you only want a single process (eg. dbus). And this scares me because I see it happen, and have no idea what to do to prevent it.

                                                                    I guess the Linux userbase changed over the years. They used to be people that liked the freedom to run whatever they wanted on their machine, at the cost of having to learn new interfaces everytime. And now they just want things to work out-of-the-box, without caring about how it works at all. The only problem I see is that the former group has no other choice than dealing with it or moving on…

                                                                    1. 1

                                                                      people that liked the freedom to run whatever they wanted on their machine, at the cost of having to learn new interfaces everytime.

                                                                      This is exactly what eg freebsd offers. It’s no longer what linux offers, though.

                                                                      FWIW I use both freebsd and linux daily. Linux where I want things to work out of the box, and freebsd where I want things to work the way I configure them.

                                                              2. 6

                                                                The title is misleading: I was looking forward to a critical discussion about the suckless philosophy and principles. However this post is mere reaction to their particular opinion (they criticize much more technologies than just systemd – actually almost every widespread technology).

                                                                Better title would be: „Why suckless is wrong about systemd“.

                                                                1. 2

                                                                  I don’t need to learn systemd to explain why it sucks. I can’t be expected to learn every new bloated piece of crap inside and out to say why I don’t want it. That’s why I just say “I don’t want bloated crap”.

                                                                  Maybe systemd is good for the OS you want in your car or your smartphone. It’s not good for the OS that runs on any computer I’ve used or managed.

                                                                  How many unix fans stopped using linux finally because of systemd? 2. Me and some other guy.

                                                                  Systemd sucks.

                                                                  1. -3

                                                                    About implemented useless features: “What is so wrong about […]”
                                                                    About non-implemented useless features: “Support has borders”
                                                                    We really don’t need to get too detailed to affirm that ShitDSystemD sucks, even because most people that says the contrary are not aware of the internal details (or do not care about technical quality at all)

                                                                    1. 5

                                                                      To not let people completely aimless about my statement (and let new downvotes consider using “unkind” instead of “troll”).

                                                                      Main Problems:
                                                                      • Too big
                                                                      • Is becoming a hard dependency of many projects

                                                                      Those are the biggest problems (the rest, such as bricking your BIOS, are bonus), because as we become more dependent of it, the harder it becomes to use alternatives (gl trying to re-implement the necessary interfaces, especially when it grows ad-infinitum); Otherwise people who still cares about quality could simply use an alternative.

                                                                      1. 12

                                                                        Don’t you think that the reason why it’s becoming a hard dependency of many projects is because it’s actually pretty useful?

                                                                        1. 1

                                                                          Does a bad thing being useful mean it’s use should be supported?

                                                                          1. 3

                                                                            Bad is a moral judgement, and software doesn’t have moral character.

                                                                            A more obvious form of the question is “Does a complex, buggy, opaque thing being useful mean it’s use should be supported?”.

                                                                            This form of the question is unpopular with people who insist the answer should be “no” - possibly because it makes clear the reasons why it might sometimes be “yes”.

                                                                            1. 3

                                                                              Your question is too generic to answer ;), also I think it’s too generic to be adequate for our “should we use systemd’ problem.

                                                                              • Should you use your car to travel? It contains complex, buggy, opaque and user-hostile systems (user-hostile when you’re trying to fix it yourself), it influences the environment in a negative way, it’s loud, kills people, and is designed to be replaced few years after buying. But because ambulances use it, people’s lives can be saved.

                                                                              • Do you have the source code of the UEFI implementation of your motherboard? It’s complex, buggy, closed, nobody knows what it’s doing, and it’s running every time you power on your computer. But because it can be used to bootstrap your operating system, it allows you to connect with other people.

                                                                              • Do you eat sugar / do you smoke / drink alcohol? It’s bad for your health, but it’s tasty / can help with social interaction.

                                                                              1. 2

                                                                                Wether or not you should use a car is a personnal concern. Some people don’t want to be bothered and need it (ambulances, police, etc..). The problem is that distros are getting rid of the bike lanes and sidewalks because they don’t want to be bothered with alternative transportation methods, as the car do it well. And me, a longboard enthusiast that don’t need a car at all to move around the city is forced into it, even though I neither need or want it.

                                                                                1. 1

                                                                                  Wether or not you should use a car is a personnal concern.

                                                                                  I don’t agree. There are lots of people who would like to limit other people to have cars. Also lots of people who are bothered because 1 person has more than one car. Also, the environment that we live in is influenced by other people having cars (noise, pollution, sidewalks as parking spots, etc). So, I understand that me having a car can influence another person in a negative way. So since it influences another person, it’s not a personal concern. There’s also a non-zero risk that the car owner does some damage with it, since using a car involves manipulating a high energy object, that’s why the car insurance exists (disclaimer: I own a car and I’m not against using it).

                                                                                  The example with removing bike lanes and sidewalks seems adequate, but maybe the distro does it because the majority of people uses cars. So I’m not sure is it sensible to try to limit the optimization of the city for the majority, because a small percent of citizens desn’t want it. Also, removing sidewalks and bike lanes is not the goal here. Future features that will be possible to be implemented by optimizing the city for cars are the goals.

                                                                                  1. 3

                                                                                    the environment that we live in is influenced by other people having cars (noise, pollution, sidewalks as parking spots, etc). So, I understand that me having a car can influence another person in a negative way

                                                                                    This is where the metaphor stops applying. Of course an init system has zero impact on the environment, and does not directly impact other people. If we both use gentoo, and my system runs systemd while yours uses openrc, you won’t be bothered at all, no matter how bad I tune/use my system.

                                                                                    Back when systemd appeared, I was running archlinux, so I mostly remember the design choice for this particular distro. When they decided to make systemd the default init, many people asked why a tinkerer distro like this would enforce the init system on its users (it was possible at the time to replace the init system, SysV with openrc or runit fairly easily). The developers/maintainers stated that they chose systemd because it would unify how the services would be managed, so they would not have to maintain all the scripts for other daemon managers. They wanted a single way to write service files so they won’t be bothered with bugs in shell init scripts.

                                                                                    They did not remove the sidewalks and bike lanes because people used cars. They forced users into it so they won’t have to maintain the sidewalks and bike lanes. The choice didn’t come from the users at all, it cames from the distro makers.

                                                                                    edit: Found to official communication from 8 years ago! https://bbs.archlinux.org/viewtopic.php?pid=1149530#p1149530 There were more than just the initscripts part obviously, as systemd solves real problems. I just remember getting into a discussion where the main argument was that maintaining init scripts was a waste of time for the devs because with systemd provides a unique interface for them, that distro can share together in a common effort (I still believe each distro maintain their own service files and don’t use a common source…).

                                                                          2. 7

                                                                            such as bricking your BIOS

                                                                            This was buggy firmware that bricked itself when no EFI variables were set; such behaviour should be a factory reset instead. And it’d be exposed regardless of init system if you mounted the EFI variable filesystem.

                                                                            1. 3

                                                                              yep, but in SystemD case specifically, it needs the efivars to be mounted writable, according to Poettering because SystemD writes to it (with systemctl reboot --firmware)

                                                                              1. 4

                                                                                And that is systemd’s fault exactly how?

                                                                                1. 3

                                                                                  Why does it need to write to the EFI filesystem every single boot?

                                                                                  No seriously, the whole point of having EFI on a separate filesystem is to protect the security and integrity of the boot process. systemd writes data to what should be a read-only partition unless you’re altering your bootloader.

                                                                                  1. 2

                                                                                    First, I think you’re mistaking EFI Filesystem (the FAT32 blob store with kernels) for EFIvars, NAND-backed kv configuration store. Systemd only writes to the latter when you explicitly invoke a reboot-to-firmware. And for that you need efivars mounted as rw.

                                                                                    EDIT: Also, traditionally, the former has always been mounted as rw somewhere under /boot, just like in BIOS days. And no one complains about it. And for EFIvars there are other customers too: gdisk, syslinux, grub2, efibootmgr, fwupd’s fwupdmgr and Gnome-Software frontends…

                                                                                    1. 1

                                                                                      If systemd needs to write to the EFI filesystem it should mount it read-write in a private namespace, not in the global namespace. I understand that namespaces are a relatively new feature but they’re not that new honestly.

                                                                                      1. 5

                                                                                        That’s much more actionable feedback. Makes sense to me.

                                                                                        1. 4

                                                                                          If systemd needs to write to the EFI filesystem it should mount it read-write in a private namespace, not in the global namespace.

                                                                                          Fine, but what about the half-dozen other clients, that expect writable efivars in the global namespace? Especially efibootmgr and fwupd.

                                                                                          1. 1

                                                                                            They should do the same IMO. This is an area you can permanently brick your machine, needing a little bit of inconvenience is a good thing

                                                                                            1. 1

                                                                                              Okay, that might work, can’t disagree here.

                                                                                2. 2

                                                                                  I don’t see how that’s an excuse. It wouldn’t have happened if not for the actions of systemd’s developers.

                                                                                  1. 9
                                                                                    1. The EFI spec says you can reboot to firmware by wiping EFI vars.
                                                                                    2. Someone shipped hardware that is bricked if you follow the EFI spec.
                                                                                    3. Someone else shipped free software that follows the EFI spec.

                                                                                    How is it that the free software that follows the spec attracts more blame than the paid hardware that doesn’t?