15 ms·

Systemd is without doubt one of the most important items of software on a modern Linux today, except perhaps for the Linux kernel itself. It turned the mess of

by boncho 4y ago

Systemd is without doubt one of the most important items of software on a modern Linux today, except perhaps for the Linux kernel itself. It turned the mess of shell scripts and other crap into the rock-solid, foundational system services layer we enjoy nowadays. If we do ever get the year of the Linux Desktop, we will have to thank the authors of systemd for giving us a bedrock of delight to build upon.

tsujamin 4y ago
+1 for systemd-networkd too: it let me declaratively describe some netns/ipvlan interfacing the other day that netplan et al simply couldn't. It could use with some more netns awareness but its pretty great at the current stage
- Avamander 4y ago
  You can still let netplan use systemd-networkd as the renderer, though in some cases some overrides are necessary.
- normaler 4y ago
  systemd-networked + systemd-resolved is also really awesome. It lets you configure DNS Server per link and resolve only certain domains via a specific DNS Server configured from a link. e.g. multiple customer specific wireguard Tunnels that resolve the specific project related domains, but dont resolve all your other DNS.
europeanguy 4y ago
I'm not a Linux expert, but I thought that systemd was generally hated?
- tkuraku 4y ago
  Seems pretty great to me. Never understood the hate.
  - nomel 4y ago
    I was sold after a single session of writing a couple of dependent services. Logging, retries, cleanup. Everything was so ridiculously straightforward, rather than a bunch of bash hacks and lock files. I have trouble believing that people who loath it so much have actually sat down to read the documentation.
- zargon 4y ago
  > bedrock of delight It might be sarcasm?
  - deleted 4y ago
    [deleted]
- plaguepilled 4y ago
  I would say it really depends on the context! Some reasons systemd is bad: - Its a "big" for small docker containers (which is part of why a lot of people like Alpine Linux). - It produces binary logs, which might not work with your workflow and is a kind of vendor lock-in if you don't script a binary-to-text script. - the binaries are all a lot bigger in terms if SLOC and in terms of storage space than the solutions they replace. This makes auditing the code more of a chore and is a big argument against it in certain security environments. - (my main gripe) systemd produces vendor lock-in from seemingly unrelated apps. A lot of packages which indirectly depend on a systemd functionality need to be patched to work on OpenRC Gentoo, for example. Some arguments for systemd: - systemd abstracts process management. This can be fantastic for scripting and security (again, context dependent) - systemd by default kills services on log out (which is great for desktop - but can be an obstacle for servers). This is a good default behavior from a security perspective. - systemd has some parallelization of init, making start up more predictable (because something falling over is less likely to nuke the whole procedure - again good for desktop) - systemd provides a lot of tooling to stop you doing things the "wrong" way. For example, systemd-analyze-security provides configuration tips to harden your system ========== In general, I would say that systemd is a very impressive tool and helped a lot of distributions standardise how they handle boot. I wish it did not impact downstream development the way it does though.
  - yjftsjthsd-h 4y ago
    > Its a "big" for small docker containers Aside size, last I looked it required a lot of hoop-jumping to get systemd to run inside docker at all.
    - klodolph 4y ago
      I think the idea of running systemd inside docker (or vice versa) is a little redundant to begin with—systemd and docker share a number of features.
      - yjftsjthsd-h 4y ago
        It's unusual, but there are occasionally times when it's nice to run multiple processes in one container, and a proper service manager would be useful. Usually I see supervisord used for that kind of thing in practice.
- grepLeigh 4y ago
  I've developed a distrust for anyone who hates on systemd in 2022, especially if their rationale is vague dogma like "it does more than 1 thing, it's not Unix-like!" It's usually a signal that the person is not a practioner. Systemd is the most important and well-developed Linux framework, besides the Linux kernel itself.
  - iotku 4y ago
    Feigned certainty is often a indication of the opposite. In many cases people just absorb someone else's opinion on topics just in an effort to feel informed. I'm not going to say I'm never guilty of it myself, but often asking even for the slightest bit of further explanation collapses that or otherwise just leads to repetition.
  - Jach 4y ago
    I don't trust anyone's opinion, for or against, unless they've used alternatives. I've used systemd, I'll probably use it again, and I'll keep hating on it if someone gets me started. Fortunately on my own systems I've been a happy OpenRC user instead.
    - grepLeigh 4y ago
      My S/O is a Gentoo maintainer so this comes up often in my household!
      - Jach 4y ago
        As a longtime user I thank your S/O, you're lucky to have them!
    - boudin 4y ago
      I've used both (OpenRC and systemd). I like the simplicity of OpenRC and still uses it on a few servers running on Gentoo, but on a laptop/desktop I think systemd is a better fit, having user services with user level logging for example.
  - traverseda 4y ago
- oconnor663 4y ago
  It's one of those things where people who hate it talk a lot about that, but people who like it don't have much to say.
- fuckstick 4y ago
  It’s not generally hated. It has a cadre of permacritics that are very vocal and often dramatic, and some of them often pop up in threads such as this one, that is all. It’s especially pathological since there are alternatives - if you hate Lennart, Redhat or whatever, use something else and move on. Meanwhile millions are using it to get shit done without much drama. It’s been years since I filed a bug on systemd, but that’s what grown ups do when inevitable bugs are encountered, not make themselves and everyone miserable because they deeply integrated some dubious 1970s Unix philosophy into their personality.
- ruuda 4y ago
  There are two types of software: those that everybody complains about, and those that nobody uses.
- otabdeveloper4 4y ago
  Yes, it's so hated that it's impossble to find a Linux system that doesn't use it.
- HNDV 4y ago
  >thought that systemd was generally hated? If it was generally hated there would be a lot more support for the distros that don't have systemd. There isn't. Except for alpine, all of them are extremely niche, half of them are dead, the other half barely have enough people to stick around for a release a year. Even alpine is kinda niche, it's mostly used as a way to make lightweight docker containers, rather than as a distro that stands on its own, the fact it uses musl as its libc means you can't use it on a server that has nvidia gpus for machine learning, you can't use it on a desktop where you need a browser capable of DRM, you can't use it on a personal computer if you ever intend to install a video game etc. I have -yet- to hear anyone in my life actually use something like Devuan, the systemd-less fork of Debian, in a production environment. Six years after their first release, instead of standing on their own as a distribution, they're still deeply angry and obsessed with systemd and this is the level of professionalism they exhibit on social media : https://twitter.com/DevuanOrg/status/1586963662295687169 https://twitter.com/DevuanOrg/status/1586963662295687169 Of course, one of the twitter comments underneath is "systemd macht frei". One of the things the official devuan account retweets : https://twitter.com/jaromil/status/1544618996833583104 https://twitter.com/jaromil/status/1544618996833583104 "It's 2022 and the master of systemd is now working for Micro$oft https://phoronix.com/scan.php?page=news_item&px=Lennart-Poettering-Out-Red-Hat https://phoronix.com/scan.php?page=news_item&px=Lennart-Poet... this the last bit @phoronix omits. This is a classic cybernetic strategy: to become the master of a feedback loop you create and continuously adjust the framework in which nodes interact." I think that says enough about the sort of irrational people we're dealing with? People who hate systemd are very, very vocal, and highly unproductive.
  - encryptluks2 4y ago
    I think that is an overstatement. I use systemd but there is legitimate criticism and even a questionable conflict of interest in the creator now working for the competition. People working against the best interest of the community is a real threat that shouldn't simply be ignored. However, so far systemd has worked out alright for me so I can't complain too much but the documentation is still lacking in certain areas and so doing things that are easy to understand with a traditional script based RC can become frustrating when you are trying to figure out the systemd-way to do things.
- terom 4y ago
  By a vocal minority.
- agumonkey 4y ago
  It started with bad press because author made pulseaudio and its design didn't appeal to many (lots of features but missing pieces, not due to dev but market forces and drivers). So when the same guy says he's gonna rewrite pid1 with a radically different design people went ballistic. My personal opinion is that proper dependency based init systems are amazing but I'm not fond of some slightly superficial aspect of systemd (syntax, parameters, logic, config files).. to the point I think in a few years someone may make a cleaner variant.
- esarbe 4y ago
  From my experience this was never much more than a very vocal minority.
- tux3 4y ago
  A couple years ago, absolutely. To decide whether to generally hate systemd, and with what intensity, you should follow a curve that decreases proportionally with how long ago the change was made, and that starts as high as the multiplication of how much churn it causes times how old the thing it replaced was, all of which is of course multiplied again against the buggyness curve When pipewire replaced pulse, despite pulse being well established and a core desktop component, there was very little churn and few bugs. People not impacted did not mind at all that a major component was changed, or that it did many things and bundled three completely different protocols into one, arguably not very reminiscent of Unix Philosophy™ I would confidently predict that a change as large as systemd, to a component as old, and that causes as much churn (rewriting, relearning) would follow a roughly similar hate curve, only distinguishing itself by whether it was more buggy or less buggy than the predecessor. It's churn people hate, not change. The lesson I learned is that you can make large changes to the system, it's only hated when it forces humans changes.
  - alxlaz 4y ago
    It's worth remembering that much of the churn was caused not by having to rewrite configuration, but by the multitude of bugs that plagued systemd early on, and the way they were treated did not help. systemd upstream was extremely difficult to work with and made a lot of people reluctant to embrace change, because when something didn't work -- which we all understood was natural for software developed in the open -- you were pretty much screwed. Shell scripts and duct tape were bad but it could take less time to fix something than it took to get people "up there" to admit that they're really looking at a bug, not a feature. I ran systemd very early on because it gave me some things I liked from SMF but I completely understand why so many people hated it. It's a (suite of) program(s) with good ideas that was hampered by extremely poor maintainership and relation with other open source projects.
  - how_gauche 4y ago
    Pipewire broke me lots of times during its development and rollout, and that's okay, because new software has bugs and in some of my other use cases "hey it's a lot better than Jack". What I'm not going to do is carry a grudge against the maintainer for decades? I've been using Linux since Slackware installed from a pile of floppy disks. I'm extremely happy with systemd (desktop and server) and view it as one of the most important UX advancements ever made in the Linux sysadmin space. It replaced a smorgasbord of broken nonsense with a unified and thoughtful system that is objectively superior to what it replaced. I suspect a lot of the extreme reaction to systemd is not just resistance to change, but based on an emotional attachment to the rag-tag heterogeneity it made obsolete.
- UI_at_80x24 4y ago
  On my laptop, systemd is awesome; I love it. Everything works together nicely. On my servers, systemd gets in my way, tries to do too many things, and gets in my way more then it helps. On a laptop things are much more dynamic. From sleep/hibernation/wifi-LAN-wifi (+/- VPN) switching/etc.... these fiddly bits were much harder to manage on Linux for DECADES then they are now. The reboot interval on laptops is huge compared to servers. An init system (plus all the extra plumbing) work well together. On servers however; I HATE systemd. For logging, networking (and DNS) alone systemd wastes so much more of my time and gets in my way. I think the need for an 'improved' init system was always a red herring. I've never had a service race-condition, or other conflict that didn't take more then 10 minutes to fix in the 30 years I've managed *nix servers. There was one time where I was stumped why my VPN server kept failing to start at boot but came up fine if I restarted manually. My dyslexic ass inverted the script number (ie. 13 instead of 31 or something like that). That was just a face-palm embarrassment.
  - lrvick 4y ago
    Systemd should never be used on a server. Or any other desktop init system for that matter. Production systems should never be changed or administered in place, only replaced. Servers should be immutable appliances. They do not need a package manager, or systemd, or ssh, or even a shell. Such things are developer tools and only belong in development environments like workstations. A production filesystem should contain a kernel, an init binary, and either a container runtime or a static binary of your target application. At most a production init binary just needs to setup virtual filesystems and be a reaper for a target application binary.
    - effie 4y ago
      > Production systems should never be changed or administered in place, only replaced. Servers should be immutable appliances. They do not need a package manager, or systemd, or ssh, or even a shell. Such things are developer tools and only belong in development environments like workstations. That is a very restrictive work methodology (unikernels,exokernels). Although interesting and certainly useful in some cases (high security, rare updates), Bryan Cantrill was partially right on this - in the real world, we often need to debug stuff running in production and support paying customers who require that. Your idea of "production systems" and "servers" seems very specific and the "should" statements are often not true in practice. Developer tools definitely belong on the server too, you need them to determine how to build your stack binaries in the best way for the OS and HW architecture there and keep them updated and secure.
- excsn 4y ago
  Hehe, I remember some people complaining about it. I never could hate SystemD once introduced to it as an infrastructure engineer. The difference was night and day in Debian (from wheezy to jessie). Setting common sig handlers, restart on exit, etc. are just one-liners with unit files. In the previous one, SysV, it was an annoying incantation especially if you were a newbie, like me at the time, or product engineer who was dabbling. You could easily screw it up. Some non infra engineers cursed the SysV files and loved the SystemD unit files. Now I use dynamic user and the other security features in my unit files and wonder how many lines it would have taken to do that in SysV, so the complaints are laughable at this point.
- traverseda 4y ago
  Less hated ad time goes on. I still think it's architecturally stupid (look at openrc for something that accomplishes similar goals but better), but it's been a while since it's broken anything terribly for me, or introduced any terrible security vulnerability. It's not great, but it's not actively hurting.
Scarbutt 4y ago
Alpine linux seems to be doing fine without systemd.
- stevefan1999 4y ago
  But I almost never saw anyone using Alpine as the infrastructural distro for their, say like desktop environment akin to Manjaro and Fedora. Without systemd, bootstrapping a complicated desktop environment would be a hot mess. Well, maybe you would say Alpine is not intented to run heavyweight stuff like that and is mostly focused on security and containers. That's exactly what Alpine is, the OpenBSD of Linux distros. OpenBSD likewise cannot be used as your production powerhouse as well.
  - HNDV 4y ago
    >never saw anyone using Alpine as the infrastructural distro for their, say like desktop environment akin to Manjaro and Fedora Alpine runs musl libc. This makes it buggy with all sorts of software that rely on glibc-isms, that makes it incompatible with proprietary drivers like NVIDIA and make it harder to run proprietary/binary software on the userland. musl is developed by people with that sort of break-everything attitude : https://twitter.com/RichFelker/status/994629795551031296 https://twitter.com/RichFelker/status/994629795551031296 There is a world of pain that awaits anyone with the expectation that this sort of distro could be used on a workstation. Musl is really meant to be run.. with software vetted by communities like https://suckless.org/ https://suckless.org/ Meaning things like dwm, dmenu, st. Which may or may not be one's cup of tea. It certainly ain't mine.
    - biorach 4y ago
      That's an inaccurate and quite uncharitable representation of what musl is about.
    - blueflow 4y ago
      Bad argument, glibc and musl are not always compatible, and you can use that as argument against either. When it comes to standards, musl is actually the more conformant one. The glibc 2.26 release with the ucontext breakages made me stick with musl. Plus, when i did multiarch support in Alpine later, i found that LDSO paths for musl are much more systematically and don't have name collisions like glibc.
qbasic_forever 4y ago
I wish Windows ran systemd--seriously. Windows services and low level functionality is just a hot mess of cruft, decade plus old UI and configs, etc. Please jettison it all and give a consistent declarative way to manage it all like systemd does for Linux.
- cat_plus_plus 4y ago
  Yeah, imagine if Windows was made up of many simple and interchangeable components for which alternatives were easily available from sources other than Microsoft? Don't like services? Choose among half a dozen alternative background process management options, without affecting logging or file system layout, or listening to inbound network connections...
  - pjmlp 4y ago
    Yes, because it has been such a success conquering the desktop workloads.
- lrvick 4y ago
  You can run virtually any Windows application on top of Systemd already via Wine. Unless you have some particular attachment to the NT kernel, there near zero reasons to use Windows today.
  - dTal 4y ago
    If only that were true. "Virtually any Windows application" is a fantasy I'm afraid, many important applications run poorly or not at all on Linux. Then there's the "particular attachment to the NT kernel" caused by driver support for $HARDWARE - there's tons of niche hardware that just can't be driven from Linux. If you use a computer for actual industrial work, you will hit one of these problems very quickly.
    - lrvick 4y ago
      Can you give an example? Even modern AAA games run as well, and often better, on Linux these days.
okasaki 4y ago
I had to chattr +i /etc/resolv.conf because my resolv.conf would keep getting truncated (as in empty) every time I restarted an lxd container. Rock solid my ass.
- boudin 4y ago
  lxd is not part of systemd.
- Avamander 4y ago
  Why is lxd touching that file?
- chris_wot 4y ago
  How is that a systemd issue?
  - tyingq 4y ago
    systemd-resolved
    - encryptluks2 4y ago
      Never had this issue. Sounds like they need to recreate the symlink.
      - tyingq 4y ago
        It apparently needs specific tweaking for lxd: https://linuxcontainers.org/lxd/docs/master/howto/network_bridge_resolved/ https://linuxcontainers.org/lxd/docs/master/howto/network_br...
        lmz 4y ago
        Maybe I'm wrong, but that just seems to show that if you want to resolve lxd domains (hostnames?), you need to inform systemd-resolved to ask lxd for those domains, which is... sensible? > you should notify resolved of the domains that LXD can resolve You'd have the same issues if you replaced systemd-resolved with e.g. dnsmasq. Split DNS always needs resolver configuration.
conradev 4y ago
From an outsider perspective these stick out to me as most important: - Unified logging subsystem - On-demand launching, memory limits, and general resource management - Advanced security features, i.e. sandboxing, DynamicUser - Well thought out and implemented given the constraints (feels like Linux quality) In general it represents a shifting of code from daemon developers (who previously handled daemonization themselves) to the system. On-demand launching is good for performance: work can be deferred from boot and inactive daemons can be stopped. This is critical on battery and RAM constrained devices
blueflow 4y ago
"rock-solid". Right now my mom is nagging me to fix her Ubuntu laptop, which doesn't shutdown anymore because some of the units got messed up. I'm at the verge of telling her to install windows.
- encryptluks2 4y ago
  That is a really simple fix. Sounds like one of the units is hanging. This actually shouldn't prevent shutdown but may make it hang for like 2 minutes.
esarbe 4y ago
Absolutely. I've started managing my user services using systemd --user and portable services and it's just amazing how well the individual components work together to create fully isolated, containerized, per-user services. I'm lovin' it and I'm not missing the hot mess of the dozens of shell scripts that I needed before.
- effie 4y ago
  What kind of user services and "portable services" are you managing? I have trouble imagining what that means. User pulseaudio daemon on your laptop/desktop? Or some server services for many clients?
  - esarbe 4y ago
    Portable services are a systemd thing: https://systemd.io/PORTABLE_SERVICES/ https://systemd.io/PORTABLE_SERVICES/ In short it allows you to bundle your application in one file and have it run in a sandbox. Like a docker container, but without docker, managed by systemd. https://wiki.archlinux.org/title/Systemd/User https://wiki.archlinux.org/title/Systemd/User User services are also a systemd thing; you can create systemd unit files (service descriptions) and have them run as a user. So as a user you can manage your own running processes using the same systemctl interface as system processes. If you are allowed to "linger" on a system, you can run user processes as a service, set them up and tear them down without root permissions. I have several systems where I run i.e. webservices without having full root access. I build an portable systems image, deploy it to the server and then can manage that service with my unprivileged user account. Systemd does all the usual things, like logging, supervision, resource quotas, and so on.
pluijzer 4y ago
...the year of the Linux Desktop I keep wondering about this year of the Linux Desktop. So often I see it used as a snide towards Linux users (not by you). I think it shows naivety. What does it mean? Is it about having a stable easy to maintain and full featured Linux Desktop. I really do think we have reached that point. Especially now that many workflows have moved to the web I am having a hard time coming up with use cases for which Linux would really not be suited. Even gaming has become very viable. Or does it mean that Linux for overtake the market share of Windows and macOS. For that I would caution to be careful about what you wish for. Being an underdog brings an added benefit of having more flexibility and the option to think outside of the box. For Linux to overtake Windows it would slowly turn into Windows itself in my opinion.
- AnIdiotOnTheNet 4y ago
  > Is it about having a stable easy to maintain and full featured Linux Desktop. I really do think we have reached that point. Especially now that many workflows have moved to the web I am having a hard time coming up with use cases for which Linux would really not be suited. Even gaming has become very viable. Damning with faint praise. The success of Linux gaming is due to the efforts of projects that re-implement Windows APIs, and things moving to the web are obviously not targeting Linux either.
tapoxi 4y ago
I'd argue the success of the Steam Deck is evidence of the Linux desktop's maturity. The normal game UI is just another Wayland session, and it's a fully functional PC running Arch Linux. KDE is installed and easily accessible.
- AnIdiotOnTheNet 4y ago
  I'd say the success of the Steam Deck is a testament to the maturity of the Windows API[0]. Old enough and reliable enough that it is a better target for games on Linux than Linux Desktop's own shit show. [0] and of course the efforts of the WINE project and proton.
  - tristanbvk 4y ago
    You're not wrong regarding Wine but that may be the ONLY good aspect of Windows on a technical note.
    - AnIdiotOnTheNet 4y ago
      There's a lot of good aspects of Windows. The NT kernel is actually really good, the driver model is largely user mode, it had application-specific sound mixing, PowerShell is really good, etc. Don't succumb to fanboyism.
      - tristanbvk 4y ago
        Having a lot of user mode stuff does tickle my fancy, being someone who is very keen on microkernels (despite windows being a hybrid), I can appreciste some of their design choices.
- fullstop 4y ago
  It's also worth mentioning that the Steam Deck uses systemd as well.

by boncho 4y ago

tsujamin 4y ago

+1 for systemd-networkd too: it let me declaratively describe some netns/ipvlan interfacing the other day that netplan et al simply couldn't. It could use with some more netns awareness but its pretty great at the current stage

Avamander 4y ago
You can still let netplan use systemd-networkd as the renderer, though in some cases some overrides are necessary.
normaler 4y ago
systemd-networked + systemd-resolved is also really awesome. It lets you configure DNS Server per link and resolve only certain domains via a specific DNS Server configured from a link. e.g. multiple customer specific wireguard Tunnels that resolve the specific project related domains, but dont resolve all your other DNS.

europeanguy 4y ago

I'm not a Linux expert, but I thought that systemd was generally hated?

tkuraku 4y ago
Seems pretty great to me. Never understood the hate.
- nomel 4y ago
  I was sold after a single session of writing a couple of dependent services. Logging, retries, cleanup. Everything was so ridiculously straightforward, rather than a bunch of bash hacks and lock files. I have trouble believing that people who loath it so much have actually sat down to read the documentation.
zargon 4y ago
> bedrock of delight It might be sarcasm?
- deleted 4y ago
  [deleted]
plaguepilled 4y ago
I would say it really depends on the context! Some reasons systemd is bad: - Its a "big" for small docker containers (which is part of why a lot of people like Alpine Linux). - It produces binary logs, which might not work with your workflow and is a kind of vendor lock-in if you don't script a binary-to-text script. - the binaries are all a lot bigger in terms if SLOC and in terms of storage space than the solutions they replace. This makes auditing the code more of a chore and is a big argument against it in certain security environments. - (my main gripe) systemd produces vendor lock-in from seemingly unrelated apps. A lot of packages which indirectly depend on a systemd functionality need to be patched to work on OpenRC Gentoo, for example. Some arguments for systemd: - systemd abstracts process management. This can be fantastic for scripting and security (again, context dependent) - systemd by default kills services on log out (which is great for desktop - but can be an obstacle for servers). This is a good default behavior from a security perspective. - systemd has some parallelization of init, making start up more predictable (because something falling over is less likely to nuke the whole procedure - again good for desktop) - systemd provides a lot of tooling to stop you doing things the "wrong" way. For example, systemd-analyze-security provides configuration tips to harden your system ========== In general, I would say that systemd is a very impressive tool and helped a lot of distributions standardise how they handle boot. I wish it did not impact downstream development the way it does though.
- yjftsjthsd-h 4y ago
  > Its a "big" for small docker containers Aside size, last I looked it required a lot of hoop-jumping to get systemd to run inside docker at all.
  - klodolph 4y ago
    I think the idea of running systemd inside docker (or vice versa) is a little redundant to begin with—systemd and docker share a number of features.
    - yjftsjthsd-h 4y ago
      It's unusual, but there are occasionally times when it's nice to run multiple processes in one container, and a proper service manager would be useful. Usually I see supervisord used for that kind of thing in practice.
grepLeigh 4y ago
I've developed a distrust for anyone who hates on systemd in 2022, especially if their rationale is vague dogma like "it does more than 1 thing, it's not Unix-like!" It's usually a signal that the person is not a practioner. Systemd is the most important and well-developed Linux framework, besides the Linux kernel itself.
- iotku 4y ago
  Feigned certainty is often a indication of the opposite. In many cases people just absorb someone else's opinion on topics just in an effort to feel informed. I'm not going to say I'm never guilty of it myself, but often asking even for the slightest bit of further explanation collapses that or otherwise just leads to repetition.
- Jach 4y ago
  I don't trust anyone's opinion, for or against, unless they've used alternatives. I've used systemd, I'll probably use it again, and I'll keep hating on it if someone gets me started. Fortunately on my own systems I've been a happy OpenRC user instead.
  - grepLeigh 4y ago
    My S/O is a Gentoo maintainer so this comes up often in my household!
    - Jach 4y ago
      As a longtime user I thank your S/O, you're lucky to have them!
  - boudin 4y ago
    I've used both (OpenRC and systemd). I like the simplicity of OpenRC and still uses it on a few servers running on Gentoo, but on a laptop/desktop I think systemd is a better fit, having user services with user level logging for example.
- traverseda 4y ago
oconnor663 4y ago
It's one of those things where people who hate it talk a lot about that, but people who like it don't have much to say.
fuckstick 4y ago
It’s not generally hated. It has a cadre of permacritics that are very vocal and often dramatic, and some of them often pop up in threads such as this one, that is all. It’s especially pathological since there are alternatives - if you hate Lennart, Redhat or whatever, use something else and move on. Meanwhile millions are using it to get shit done without much drama. It’s been years since I filed a bug on systemd, but that’s what grown ups do when inevitable bugs are encountered, not make themselves and everyone miserable because they deeply integrated some dubious 1970s Unix philosophy into their personality.
ruuda 4y ago
There are two types of software: those that everybody complains about, and those that nobody uses.
otabdeveloper4 4y ago
Yes, it's so hated that it's impossble to find a Linux system that doesn't use it.
HNDV 4y ago
>thought that systemd was generally hated? If it was generally hated there would be a lot more support for the distros that don't have systemd. There isn't. Except for alpine, all of them are extremely niche, half of them are dead, the other half barely have enough people to stick around for a release a year. Even alpine is kinda niche, it's mostly used as a way to make lightweight docker containers, rather than as a distro that stands on its own, the fact it uses musl as its libc means you can't use it on a server that has nvidia gpus for machine learning, you can't use it on a desktop where you need a browser capable of DRM, you can't use it on a personal computer if you ever intend to install a video game etc. I have -yet- to hear anyone in my life actually use something like Devuan, the systemd-less fork of Debian, in a production environment. Six years after their first release, instead of standing on their own as a distribution, they're still deeply angry and obsessed with systemd and this is the level of professionalism they exhibit on social media : https://twitter.com/DevuanOrg/status/1586963662295687169 https://twitter.com/DevuanOrg/status/1586963662295687169 Of course, one of the twitter comments underneath is "systemd macht frei". One of the things the official devuan account retweets : https://twitter.com/jaromil/status/1544618996833583104 https://twitter.com/jaromil/status/1544618996833583104 "It's 2022 and the master of systemd is now working for Micro$oft https://phoronix.com/scan.php?page=news_item&px=Lennart-Poettering-Out-Red-Hat https://phoronix.com/scan.php?page=news_item&px=Lennart-Poet... this the last bit @phoronix omits. This is a classic cybernetic strategy: to become the master of a feedback loop you create and continuously adjust the framework in which nodes interact." I think that says enough about the sort of irrational people we're dealing with? People who hate systemd are very, very vocal, and highly unproductive.
- encryptluks2 4y ago
  I think that is an overstatement. I use systemd but there is legitimate criticism and even a questionable conflict of interest in the creator now working for the competition. People working against the best interest of the community is a real threat that shouldn't simply be ignored. However, so far systemd has worked out alright for me so I can't complain too much but the documentation is still lacking in certain areas and so doing things that are easy to understand with a traditional script based RC can become frustrating when you are trying to figure out the systemd-way to do things.
terom 4y ago
By a vocal minority.
agumonkey 4y ago
It started with bad press because author made pulseaudio and its design didn't appeal to many (lots of features but missing pieces, not due to dev but market forces and drivers). So when the same guy says he's gonna rewrite pid1 with a radically different design people went ballistic. My personal opinion is that proper dependency based init systems are amazing but I'm not fond of some slightly superficial aspect of systemd (syntax, parameters, logic, config files).. to the point I think in a few years someone may make a cleaner variant.
esarbe 4y ago
From my experience this was never much more than a very vocal minority.
tux3 4y ago
A couple years ago, absolutely. To decide whether to generally hate systemd, and with what intensity, you should follow a curve that decreases proportionally with how long ago the change was made, and that starts as high as the multiplication of how much churn it causes times how old the thing it replaced was, all of which is of course multiplied again against the buggyness curve When pipewire replaced pulse, despite pulse being well established and a core desktop component, there was very little churn and few bugs. People not impacted did not mind at all that a major component was changed, or that it did many things and bundled three completely different protocols into one, arguably not very reminiscent of Unix Philosophy™ I would confidently predict that a change as large as systemd, to a component as old, and that causes as much churn (rewriting, relearning) would follow a roughly similar hate curve, only distinguishing itself by whether it was more buggy or less buggy than the predecessor. It's churn people hate, not change. The lesson I learned is that you can make large changes to the system, it's only hated when it forces humans changes.
- alxlaz 4y ago
  It's worth remembering that much of the churn was caused not by having to rewrite configuration, but by the multitude of bugs that plagued systemd early on, and the way they were treated did not help. systemd upstream was extremely difficult to work with and made a lot of people reluctant to embrace change, because when something didn't work -- which we all understood was natural for software developed in the open -- you were pretty much screwed. Shell scripts and duct tape were bad but it could take less time to fix something than it took to get people "up there" to admit that they're really looking at a bug, not a feature. I ran systemd very early on because it gave me some things I liked from SMF but I completely understand why so many people hated it. It's a (suite of) program(s) with good ideas that was hampered by extremely poor maintainership and relation with other open source projects.
- how_gauche 4y ago
  Pipewire broke me lots of times during its development and rollout, and that's okay, because new software has bugs and in some of my other use cases "hey it's a lot better than Jack". What I'm not going to do is carry a grudge against the maintainer for decades? I've been using Linux since Slackware installed from a pile of floppy disks. I'm extremely happy with systemd (desktop and server) and view it as one of the most important UX advancements ever made in the Linux sysadmin space. It replaced a smorgasbord of broken nonsense with a unified and thoughtful system that is objectively superior to what it replaced. I suspect a lot of the extreme reaction to systemd is not just resistance to change, but based on an emotional attachment to the rag-tag heterogeneity it made obsolete.
UI_at_80x24 4y ago
On my laptop, systemd is awesome; I love it. Everything works together nicely. On my servers, systemd gets in my way, tries to do too many things, and gets in my way more then it helps. On a laptop things are much more dynamic. From sleep/hibernation/wifi-LAN-wifi (+/- VPN) switching/etc.... these fiddly bits were much harder to manage on Linux for DECADES then they are now. The reboot interval on laptops is huge compared to servers. An init system (plus all the extra plumbing) work well together. On servers however; I HATE systemd. For logging, networking (and DNS) alone systemd wastes so much more of my time and gets in my way. I think the need for an 'improved' init system was always a red herring. I've never had a service race-condition, or other conflict that didn't take more then 10 minutes to fix in the 30 years I've managed *nix servers. There was one time where I was stumped why my VPN server kept failing to start at boot but came up fine if I restarted manually. My dyslexic ass inverted the script number (ie. 13 instead of 31 or something like that). That was just a face-palm embarrassment.
- lrvick 4y ago
  Systemd should never be used on a server. Or any other desktop init system for that matter. Production systems should never be changed or administered in place, only replaced. Servers should be immutable appliances. They do not need a package manager, or systemd, or ssh, or even a shell. Such things are developer tools and only belong in development environments like workstations. A production filesystem should contain a kernel, an init binary, and either a container runtime or a static binary of your target application. At most a production init binary just needs to setup virtual filesystems and be a reaper for a target application binary.
  - effie 4y ago
    > Production systems should never be changed or administered in place, only replaced. Servers should be immutable appliances. They do not need a package manager, or systemd, or ssh, or even a shell. Such things are developer tools and only belong in development environments like workstations. That is a very restrictive work methodology (unikernels,exokernels). Although interesting and certainly useful in some cases (high security, rare updates), Bryan Cantrill was partially right on this - in the real world, we often need to debug stuff running in production and support paying customers who require that. Your idea of "production systems" and "servers" seems very specific and the "should" statements are often not true in practice. Developer tools definitely belong on the server too, you need them to determine how to build your stack binaries in the best way for the OS and HW architecture there and keep them updated and secure.
excsn 4y ago
Hehe, I remember some people complaining about it. I never could hate SystemD once introduced to it as an infrastructure engineer. The difference was night and day in Debian (from wheezy to jessie). Setting common sig handlers, restart on exit, etc. are just one-liners with unit files. In the previous one, SysV, it was an annoying incantation especially if you were a newbie, like me at the time, or product engineer who was dabbling. You could easily screw it up. Some non infra engineers cursed the SysV files and loved the SystemD unit files. Now I use dynamic user and the other security features in my unit files and wonder how many lines it would have taken to do that in SysV, so the complaints are laughable at this point.
traverseda 4y ago
Less hated ad time goes on. I still think it's architecturally stupid (look at openrc for something that accomplishes similar goals but better), but it's been a while since it's broken anything terribly for me, or introduced any terrible security vulnerability. It's not great, but it's not actively hurting.

Scarbutt 4y ago

Alpine linux seems to be doing fine without systemd.

stevefan1999 4y ago
But I almost never saw anyone using Alpine as the infrastructural distro for their, say like desktop environment akin to Manjaro and Fedora. Without systemd, bootstrapping a complicated desktop environment would be a hot mess. Well, maybe you would say Alpine is not intented to run heavyweight stuff like that and is mostly focused on security and containers. That's exactly what Alpine is, the OpenBSD of Linux distros. OpenBSD likewise cannot be used as your production powerhouse as well.
- HNDV 4y ago
  >never saw anyone using Alpine as the infrastructural distro for their, say like desktop environment akin to Manjaro and Fedora Alpine runs musl libc. This makes it buggy with all sorts of software that rely on glibc-isms, that makes it incompatible with proprietary drivers like NVIDIA and make it harder to run proprietary/binary software on the userland. musl is developed by people with that sort of break-everything attitude : https://twitter.com/RichFelker/status/994629795551031296 https://twitter.com/RichFelker/status/994629795551031296 There is a world of pain that awaits anyone with the expectation that this sort of distro could be used on a workstation. Musl is really meant to be run.. with software vetted by communities like https://suckless.org/ https://suckless.org/ Meaning things like dwm, dmenu, st. Which may or may not be one's cup of tea. It certainly ain't mine.
  - biorach 4y ago
    That's an inaccurate and quite uncharitable representation of what musl is about.
  - blueflow 4y ago
    Bad argument, glibc and musl are not always compatible, and you can use that as argument against either. When it comes to standards, musl is actually the more conformant one. The glibc 2.26 release with the ucontext breakages made me stick with musl. Plus, when i did multiarch support in Alpine later, i found that LDSO paths for musl are much more systematically and don't have name collisions like glibc.

qbasic_forever 4y ago

I wish Windows ran systemd--seriously. Windows services and low level functionality is just a hot mess of cruft, decade plus old UI and configs, etc. Please jettison it all and give a consistent declarative way to manage it all like systemd does for Linux.

cat_plus_plus 4y ago
Yeah, imagine if Windows was made up of many simple and interchangeable components for which alternatives were easily available from sources other than Microsoft? Don't like services? Choose among half a dozen alternative background process management options, without affecting logging or file system layout, or listening to inbound network connections...
- pjmlp 4y ago
  Yes, because it has been such a success conquering the desktop workloads.
lrvick 4y ago
You can run virtually any Windows application on top of Systemd already via Wine. Unless you have some particular attachment to the NT kernel, there near zero reasons to use Windows today.
- dTal 4y ago
  If only that were true. "Virtually any Windows application" is a fantasy I'm afraid, many important applications run poorly or not at all on Linux. Then there's the "particular attachment to the NT kernel" caused by driver support for $HARDWARE - there's tons of niche hardware that just can't be driven from Linux. If you use a computer for actual industrial work, you will hit one of these problems very quickly.
  - lrvick 4y ago
    Can you give an example? Even modern AAA games run as well, and often better, on Linux these days.

okasaki 4y ago

I had to chattr +i /etc/resolv.conf because my resolv.conf would keep getting truncated (as in empty) every time I restarted an lxd container. Rock solid my ass.

boudin 4y ago
lxd is not part of systemd.
Avamander 4y ago
Why is lxd touching that file?
chris_wot 4y ago
How is that a systemd issue?
- tyingq 4y ago
  systemd-resolved
  - encryptluks2 4y ago
    Never had this issue. Sounds like they need to recreate the symlink.
    - tyingq 4y ago
      It apparently needs specific tweaking for lxd: https://linuxcontainers.org/lxd/docs/master/howto/network_bridge_resolved/ https://linuxcontainers.org/lxd/docs/master/howto/network_br...
      - lmz 4y ago
        Maybe I'm wrong, but that just seems to show that if you want to resolve lxd domains (hostnames?), you need to inform systemd-resolved to ask lxd for those domains, which is... sensible? > you should notify resolved of the domains that LXD can resolve You'd have the same issues if you replaced systemd-resolved with e.g. dnsmasq. Split DNS always needs resolver configuration.

conradev 4y ago

From an outsider perspective these stick out to me as most important: - Unified logging subsystem - On-demand launching, memory limits, and general resource management - Advanced security features, i.e. sandboxing, DynamicUser - Well thought out and implemented given the constraints (feels like Linux quality) In general it represents a shifting of code from daemon developers (who previously handled daemonization themselves) to the system. On-demand launching is good for performance: work can be deferred from boot and inactive daemons can be stopped. This is critical on battery and RAM constrained devices

blueflow 4y ago

"rock-solid". Right now my mom is nagging me to fix her Ubuntu laptop, which doesn't shutdown anymore because some of the units got messed up. I'm at the verge of telling her to install windows.

encryptluks2 4y ago
That is a really simple fix. Sounds like one of the units is hanging. This actually shouldn't prevent shutdown but may make it hang for like 2 minutes.

esarbe 4y ago

Absolutely. I've started managing my user services using systemd --user and portable services and it's just amazing how well the individual components work together to create fully isolated, containerized, per-user services. I'm lovin' it and I'm not missing the hot mess of the dozens of shell scripts that I needed before.

effie 4y ago
What kind of user services and "portable services" are you managing? I have trouble imagining what that means. User pulseaudio daemon on your laptop/desktop? Or some server services for many clients?
- esarbe 4y ago
  Portable services are a systemd thing: https://systemd.io/PORTABLE_SERVICES/ https://systemd.io/PORTABLE_SERVICES/ In short it allows you to bundle your application in one file and have it run in a sandbox. Like a docker container, but without docker, managed by systemd. https://wiki.archlinux.org/title/Systemd/User https://wiki.archlinux.org/title/Systemd/User User services are also a systemd thing; you can create systemd unit files (service descriptions) and have them run as a user. So as a user you can manage your own running processes using the same systemctl interface as system processes. If you are allowed to "linger" on a system, you can run user processes as a service, set them up and tear them down without root permissions. I have several systems where I run i.e. webservices without having full root access. I build an portable systems image, deploy it to the server and then can manage that service with my unprivileged user account. Systemd does all the usual things, like logging, supervision, resource quotas, and so on.

pluijzer 4y ago

...the year of the Linux Desktop I keep wondering about this year of the Linux Desktop. So often I see it used as a snide towards Linux users (not by you). I think it shows naivety. What does it mean? Is it about having a stable easy to maintain and full featured Linux Desktop. I really do think we have reached that point. Especially now that many workflows have moved to the web I am having a hard time coming up with use cases for which Linux would really not be suited. Even gaming has become very viable. Or does it mean that Linux for overtake the market share of Windows and macOS. For that I would caution to be careful about what you wish for. Being an underdog brings an added benefit of having more flexibility and the option to think outside of the box. For Linux to overtake Windows it would slowly turn into Windows itself in my opinion.

AnIdiotOnTheNet 4y ago
> Is it about having a stable easy to maintain and full featured Linux Desktop. I really do think we have reached that point. Especially now that many workflows have moved to the web I am having a hard time coming up with use cases for which Linux would really not be suited. Even gaming has become very viable. Damning with faint praise. The success of Linux gaming is due to the efforts of projects that re-implement Windows APIs, and things moving to the web are obviously not targeting Linux either.

tapoxi 4y ago

I'd argue the success of the Steam Deck is evidence of the Linux desktop's maturity. The normal game UI is just another Wayland session, and it's a fully functional PC running Arch Linux. KDE is installed and easily accessible.

AnIdiotOnTheNet 4y ago
I'd say the success of the Steam Deck is a testament to the maturity of the Windows API[0]. Old enough and reliable enough that it is a better target for games on Linux than Linux Desktop's own shit show. [0] and of course the efforts of the WINE project and proton.
- tristanbvk 4y ago
  You're not wrong regarding Wine but that may be the ONLY good aspect of Windows on a technical note.
  - AnIdiotOnTheNet 4y ago
    There's a lot of good aspects of Windows. The NT kernel is actually really good, the driver model is largely user mode, it had application-specific sound mixing, PowerShell is really good, etc. Don't succumb to fanboyism.
    - tristanbvk 4y ago
      Having a lot of user mode stuff does tickle my fancy, being someone who is very keen on microkernels (despite windows being a hybrid), I can appreciste some of their design choices.
fullstop 4y ago
It's also worth mentioning that the Steam Deck uses systemd as well.