21 ms·

Why I dislike systemd

174 points by geoffbp 11y ago

ChuckMcM 11y ago
Steven, if you're reading, you got your history slightly wrong. System V got its init handling from Sun's SunOS 4.x. It was negotiated as part of the integration between SunOS and System V which would become the "one UNIX for everyone". Unfortunately for all of us, AT&T really really loved "run levels" and Sun really really liked BSD's way of configuring the system. Which got you the unholy love child you saw in Solaris 2.0 and System V release 2.0. For the other Sun folks from the systems group who quit rather than submit to the demands, you were right, I was wrong. We couldn't convince them of the error of their ways.
- deleted 11y ago
  [deleted]
- yuhong 11y ago
  This history looks wrong. Eg it was SVR4 that merged SunOS
  - ChuckMcM 11y ago
    You are correct it was System V, release 4 that merged with SunOS. It was also the release that Sun and AT&T "combined" the BSD init/rc system with the System V init/run-level system.
- StevenJM 11y ago
  Thanks for the info. I've updated that section of the article with a note (and a link to this thread).
tilt_error 11y ago
My eyeballs just exploded... Unreadable.
- dredmorbius 11y ago
  Readability's bookmarklets help: https://www.readability.com/bookmarklets/ https://www.readability.com/bookmarklets/ (But, yeah.)
  - skrause 11y ago
    I recommend the "zap colors" bookmarklet from https://www.squarefree.com/bookmarklets/zap.html https://www.squarefree.com/bookmarklets/zap.html It simply changes all colors so that text is black-on-white, but leaves everything else unchanged.
    - dredmorbius 11y ago
      Sadly, it's not just colours that are the problem. Font sizes, poorly sized and laid-out pages, overlapping divs and other elements, animiations.... Readability fixes most of that quickly.
  - Reefersleep 11y ago
    The newest version of Firefox has a little icon resembling an open book at the right side of address field that does something similar. Quite handy :)
    - dredmorbius 11y ago
      Nice. I'd prefer that was the _default_ browser view, frankly.
- deleted 11y ago
  [deleted]
  - BinaryIdiot 11y ago
    I think OP's issue is with the low contrast between yellow and black; it is suboptimal for reading. It was readable but could have been better with some slight color changes.
empressplay 11y ago
I don't "hate" systemd either, I just think it's a bad approach. It flies in the face of the "open architecture" concept and stifles innovation. It discourages users from learning about how their operating system works, and it unnecessarily puts too much control of a fundamental component of the OS in the hands of a too-small number of people. None of these reflect the Linux I grew up with. Thus, I am not a fan of systemd. #notmylinux
- ossreality 11y ago
  What a completely unsubstantiated load of FUD. >#notmylinux oh, you're just a troll. k..
- cubancigar11 11y ago
  ossreality you are [dead]
  - deleted 11y ago
    [deleted]
  - cubancigar11 11y ago
    People downmodding this have really nothing better to do?
- olau 11y ago
  Interesting way to think about it. IMHO systemd is taking much of the hacks and weird glue that has historically held distributions together and replaced it with an active upstream project. Maybe some of the solutions they've come up with could need some improvements, but I have much higher confidence those improvements would happen now compared to how things used to be. Nowadays you can code something up and come to the systemd mailing list and get feedback and get it integrated. Previously you'd have to convince one or more not-really-connected distro hackers that your new fancy thing is worth rocking the boat for.
  - weland 11y ago
    Unfortunately, the systemd development team is not that easy to work with, which is part of why a lot of people distrust systemd the way they do. In theory, yes, it should be the way you mention it. In practice, even bug reports end up unacknowledged and labeled as features after a few philosophical debates. No one who has used more than one Linux distro would disagree that a unified system to control init services is a good idea. It's this particular implementation that's problematic, not the principle.
keypusher 11y ago
I agree with most of this, especially the fact that complexity has simply been shifted to other places. It's much easier for me to read a systemd unit file than it was for me to read a complex set of init scripts. The problem is that when I have 10 or 20 units with interlocking dependencies, it's an absolute nightmare to try and untangle because I have to jump between so many different files. Having to specify After=X and Requires=X seems like a prime example of optimizing for the 1% usecase. 99% of the time, when A must start after B, it's because A requires B. Having to specify both is something that is easily and often missed, and a hard problem to track down if you didn't read the documentation carefully. There's also the problem that it seems to be metastasizing and taking other parts of the OS. The longstanding /var/log/messages is now replaced by journalctl tool, and the logs are actually in binary. The venerable "hostname" command is now "hostnamectl" because it must go through systemd. They have also replaced chroot with systemd-nspawn, and made it so you cannot even use systemd while in a normal chroot!
- vacri 11y ago
  $0.02: journalctl isn't even tab-completable until you've nearly finished typing it. :)
  - ibotty 11y ago
    depends on what you have in your path.
    - yellowapple 11y ago
      I feel like systemd's tools and Emacs are on a race to achieve the title of "only program(s) necessary in one's path to have a fully-featured operating system". :)
- erikb 11y ago
  Have you tried the systemd tooling that graphs depencies for you? I haven't worked on that area yet, but my colleagues made heavy use of that and actually could resolve problems with these quite fast thanks to the diagrams that systemd can create for you.
ghshephard 11y ago
There is something epically beautiful about OpenBSD's consistency over the last 10 years. I swear that a 2004 OpenBSD sysadmin would be close to 100% efficient with a circa 2015 OpenBSD system, despite the absolutely massive number of improvements and changes that have been made with the operating system. Once systemd starts to get traction, it's cognitive overhead is going to become a real problem for sysadmins who want to be able to model the entire boot process and run-state in their head. For better or worse (I honestly don't know which, btw), you are going to have to start to trust the operating system to manage its boot process/run-state correctly rather than having it be a direct implementation of your mental model. (I would argue other *nix Operating systems, like OS X, have, to some degree, been doing that successfully for a while, so it's certainly possible - just not clear whether you want that type of behavior on your server systems. I guess time will tell.)
- stephen_g 11y ago
  I'm not a professional sysadmin, but as a developer with a bunch of virtual servers systemd has only made things far easier. Writing init scripts used to be a real pain, now I can set up a unit file in two minutes and it works... Maybe there's something to be said for "sysadmins who want to be able to model the entire boot process and run-state in their head" but with correct information about dependencies and so on, I personally think that's something computers are a lot better at solving.
  - empressplay 11y ago
    ...and that's awesome if you don't need 99.9% uptime and thus need to have absolute faith in your system's stability. However, for mission-critical applications that do it's hard to argue that systemd is a better solution than writing all your scripts by hand. Unless you want to be able to blame systemd if it all goes pear-shaped but I doubt your boss will buy it =)
    - bad_user 11y ago
      I would argue that features such as having explicit dependencies are absolutely required for 99.9% uptime. Building systems resilient to failures also means being able to predictably spin up new instances that you can trust. I'm also a developer and for example one problem I had with my servers on AWS was that my process sometimes happened to start before my volume meant for logs was mounted, which meant that all logs were going to my primary volume, with the server crashing at some point due to out of space errors. Another time I was using a local database meant for local caching and again, sometimes it would fully initialize only after my main process was started. And because I was using ELB with auto-scaling, it meant that these incorrectly started servers would be connected to the load-balancer, because the main process was suddenly responding to /ping, even though it wasn't ready yet. And then it would receive thousands of requests per second per server, at a moment in time in which the cluster badly needed fresh instances, which led to an unstable cluster. But only sometimes ;-)
devnonymous 11y ago
One of the more sensible ^rants^ I've read against systemd (it is KISS for some weirdly convoluted definition of KISS). Too bad these naysayers are not/will not be taken seriously.
- vacri 11y ago
  The naysayers are taken seriously, but they're in the decision-making minority. Linux distro maintainers wanted to move on from SysV Init, and systemd looked promising. Just because the naysayers didn't get their way (and on some distros, they did) doesn't mean that their criticisms aren't noted.
  - thaumaturgy 11y ago
    Which distros? Slackware is the only near-mainstream Linux distro I know of that is even possibly not moving immediately to systemd, and even then, the Slackware folks have said that once it becomes too difficult to maintain upstream packages, they'll switch too. They're just being pragmatic about it.
    - vacri 11y ago
      I thought there were others in addition to Slackware, but that pretty much all the distros are jumping ship shows the naysayers don't have enough political oomph.
      - digi_owl 11y ago
        Those that has adopted systemd are either precursors for commercial distros, said commercial distros, or based of same. The really early adopters seems to have been offshots of Fedora. And i do wonder if Debian was a holdout until systemd started sprouting containerization features, and Canonical (Ubuntu) was feeling the heat.
    - cubancigar11 11y ago
      Gentoo by default prefers OpenRC over systemd, though you can chose which one you want while installing.
swhipple 11y ago
The author mentions that he believes the biggest problem of systemd is repeating some mistakes of SysV init, but I think it's actually pretty important that familiarity is preserved to help people upgrade. For example, the author mentions babysitting the users (systemctl edit) and config/daemon reloading as things that could be made automatic, I'm assuming with e.g. inotify change events. But you often want some confidence that the change you're making to your system is what you expect, and we've had them all along: - visudo(8) sanity checks, for atomicity and syntax, to help prevent you from bricking your authorization - an explicit SIGHUP to reload the configuration file for your daemon, after you've checked the config, rather than accidentally saving your file while you're editing it and bringing down your daemon. You could expect everyone to adopt new practices for editing the configurations, but the behavior would be very surprising to anyone used to the old way.
- bluejekyll 11y ago
  What I think your getting at is that essentially you need a mechanism to commit your changes before the thing that's reading those changes receives them. In essence, an atomic operation for the change. Completely agree.
  - pjc50 11y ago
    I'm hearing "we need to build a version control system or a transactional database into our init daemon" here :)
    - bad_user 11y ago
      Version control systems and transactional databases are built over atomic operations. Transactions in particular refer to having multiple operations that either succeed or fail all at once, making in essence atomic operations composable (they normally aren't). Editing a file and saving it multiple times is not an atomic operation, but reading a file can be, so having the user issue a reload command only after he's finished editing a file is an entirely reasonable approach that has been used in Linux since forever and it only shares some basic building blocks with version control or transactions, but there's nothing fancy about the approach. Fancy and very error-prone would be to apply configuration changes automatically, which is what the article seems to suggest. In other words the joke is lame :-P
jveld 11y ago
It got the job done by making the 99% majority of use cases more difficult in order to make the 1% minority simpler. This is a design pattern I think is being repeated in systemd. I kinda had the opposite impression. I first encountered systemd when I started messing around with arch for a couple little vps projects. At the time I was doing sysadmin that involved both Ubuntu and CentOS, and I definitely found day-to-day tasks easier with systemd (better built in monitoring, consistent syntax, etc). For simple cases, writing a unit file sucks a lot less than writing an initscript. The warts in systemd only started to irritate me when I was first setting up my personal machines (one laptop, one tower) to run arch [1]. Even then, the bloat in the design irked me more than actually using it. So, I'm in favor of systemd, but not thrilled (dbus everywhere is annoying). Then again, I don't maintain any packages with strange and/or complex daemons. If anybody's had a really hard time getting their stuff to work with systemd, I'd be interested to hear stories. 1: Not completely true. I want my damn log files back.
- thaumaturgy 11y ago
  This is why I suspect that most of the divisions in the sysadmin community regarding systemd are generational. For people (like me!) who have been writing init scripts forever and can do it in their sleep, they'd prefer the flexibility and familiarity of init scripts to a new system that at first glance appears more limited. For people who are less experien^H^H^H^H^H^H^H^Hcrusty :-), init scripts look like a horrifying way to manage a startup process, and just about anything -- including Yet Another Config File Format -- looks preferable. I think this is also why so little progress is being made on resolving conflicts over systemd. There really isn't a whole lot of room for compromise; one group simply wants things to stay more or less the same (or evolve incrementally), the other group simply wants to throw it all out and start over. I bet there would've been a lot less argument and vitriol about systemd if Debian hadn't made the decision to default to it, basically leaving all the crusty sysadmins homeless. Once Debian switched, there was a near guarantee that all of Linux was going to move to systemd. That suits one group just fine, another one not so much. On the plus side, the BSDs should be seeing a really nice upswell of installations over the next couple of years, which is great, because they've been quietly building some pretty great operating systems that deserve more love.
stoplight 11y ago
Am I missing something? The author states: > Try to find the answer to "which units are going to be started on next boot?". Isn't this just `ls /etc/systemd/{user,system,network}//*` (bah HN formatting is messing this up) Also the other states: > Speaking of which, why is systemctl daemon-reload even a thing? Because configuration changes while things are running. Otherwise we wouldn't need apache2 reload, nginx reload, haproxy reload, etc. Also, according to the man page: > After the units have been edited, systemd configuration is reloaded (in a way that is equivalent to daemon-reload). As for systemctl edit, it allows you to add diffs to the unit file. For example, let's say I am using redis and I want to ensure it always restarts (for whatever reason). Rather than manually editing the unit file (which will have issues if an upstream change happens), I can simply use systemctl edit to add a diff for my change. This way I can still maintain compatibility with the upstream unit file instead of having to deal with potential conflicts. It's not so much babysitting the user as it is a potentially better experience.
- ploxiln 11y ago
  > Isn't this just `ls /etc/systemd/{user,system,network}//*` (bah HN formatting is messing this up) Nope. There are many virtual units for which there are no files. One example is the on-demand getty units. There are two for "plymouth" boot-splash stuff (I see these attempted-and-failed units on archlinux where plymouth never exists). There's some autofs thing. There's auditd. I'm actually not booted into linux right now so I'm struggling to remember the specifics... but if you also count all the simple mounts and devices which clutter up the output of "systemd --all" as "units which are not files in /etc/systemd" then the count is around 100.
  - INTPenis 11y ago
    Couldn't/Shouldn't this be solved with some script that traces the dependencies of units? I'm not familiar enough with systemd to understand how to trace dependencies and create a complete list of all units that will run at next boot but I expect this to be doable by someone with that expertise.
    - 11y ago
belorn 11y ago
With System V and Debian, one added some new apache or bind configuration and then called invoke-rc.d daemon reload to inform the daemon to reread the configuration files. With systemd, you do the exact same thing and then call systemctl reload daemon. Is the author making an argument here based some other distributions way of handling System V?
- JdeBP 11y ago
  No. The author is not getting reloading the daemon's configuration mixed up with reloading systemd's configuration. You, however, are. The systemctl manual page warns about this mistake. See what it says under daemon-reload.
weland 11y ago
I'm one of the people who jumped ship to OpenBSD in the last year or so. I think I first touched a Linux machine in 1997 or 1998. systemd has been part of the reasons I did that for precisely the same reason. There is a lot of development in the ecosystem dominated by Freedesktop.org, Gnome and (to some degree) large commercial players like RedHat and SUSE. It's more efervescent than it's ever been. Fifteen years ago, I'd have been ecstatic to see so much development being done. Yet for all this fierce code churning, there's absurdly little innovation. Even in systemd, there's a lot of focus on non-issues like booting without needing a shell, while still inventing service startup notification types because none of the gazillion startup notification types already existent can actually solve precisely the problem systemd claims it solves -- managing complex startup chains. In the last three or four years, my Linux systems have become increasingly blackboxed, and consequently harder and harder to configure, let along debug when they stop working. Over the span of six months, a tool you just got to learn how to work with (mostly because the documentation seems to have been written by very bored and very verbose monkeys who had only a typewriter to pass the time with) becomes obsolete or is revamped to be unrecognizable. Which would be fine if that actually solved any problems. Instead, it replaces the old set of problems with a new, even more complicated set of problems that developers claim you shouldn't have, while insisting that the old problems were simply due to the old architecture and we'll have none of that now that we have this shiny new thing. Ironically, systemd is actually one of the better pieces of software to come out of that ecosystem. No, seriously. It's decently documented and as long as you don't need anything more complex than "here, start this daemon after this other daemon started", it does its job. If you want to peck at something, have a look at Polkit, where someone brilliantly figured out that the best way to configure policies is to write basically undebugable JavaScript code in .rules files.
- anon3_ 11y ago
  > I'm one of the people who jumped ship to OpenBSD in the last year or so. Ha. FreeBSD here. And so long as you get the right hardware, I find BSD to be far simpler than linux distributions out there. Ports? Beautifully elegant and simple. Configurable. Magnitudes easier than configuring rpm/debs. Getting a package approved in debian? Alioth? No offense, the wiki, all these pages on the debian website - they have no concept they have of "Handbook", in the sense FreeBSD has. It's so adhoc, they're healthy, but they're in denial about how hard they make it for new people. By the time you've taken to time to learn Debian's dev warts, you're apart of the convent and no longer care about fixing the onboarding problems. But to be fair. I have day to day gripes with FreeBSD just because we're short on the manpower Linux distributions have in excess: On FreeBSD 10.1, chromium crashing easily, settings doesn't work. Firefox just clogs up and stops working. No skype (CURRENT will be in a better position to since epoll support has been added). No Dropbox (as of now, we don't have inotify, and kqueue may not be able to handle it, don't quote me on that). I do my 90% of daily routines simpler and better on FreeBSD. If only Google / Mozilla (with all the resources they have) gave someone who could work to fix this stuff.
octref 11y ago
This page's horrible readability is a perfect reflection of the kind of folks that dislike systemd. Yeah, newcomers to the Linux land without the expertise you guys acquired through 10 years of using Linux, would apparently appreciate how easy it is to manage a server by invoking some lengthy commands they learned through reading the often overly-dense manual instead of `systemctl start/stop x`. Nowadays some of those so-called "hackers" tend to ignore the part of work that makes the user experience better. They claim that they want simplicity and avoid bloat but most of the times they are just being lazy and not sympathetic to their users. I'm not saying that things should be dumbed down to clicking GUI buttons on Linux. But if you want your program to become mainstream you need to think about providing good and practical docs and making your program easier to use, even for text-based programs. Accept that most people would like Bootstrap'ed sites more than yours: body { background-color: #080808; color: #ffff70; font-family: sans; } That's why I opt for Ubuntu 15.04 instead of 14.04 LTS on my VPS, since 15.04 has systemd.
- cthalupa 11y ago
  Are we really using website design choices as a valid target to discredit someone's opinion on the technical merit of an init system? Can I use Lennart's inability to buy a properly sized polo as a reason why systemd is bad? Yeah. The guy has an ugly website. But he has specific points about mistakes that systemd didn't learn from and is repeating. Did he list 'it's too user friendly' as one of those mistakes? In fact, one of his core arguments is that there will actually be an increase in complexity and reduction in user friendliness due to design choices that have been made.
  - octref 11y ago
    I'm saying that, if people keep responding to those less-experienced Linux users who complain init scripts too complex by saying "Quite. Deal with it." like this author (http://www.steven-mcdonald.id.au/ugly.shtml http://www.steven-mcdonald.id.au/ugly.shtml), I fail to see how systemd is gonna fail. My comment is not about design choices but attitude and sympathy to users. This is not intended as an ad-hominem. The author seems to think systemd "babysits" its users, but as a user I find systemd "cares" about its users.
pjmlp 11y ago
I don't care about systemd, as I want to use OSes that embrace modern architectures, unikernels, containers, safer programming languages, improved UI stacks,.... This rant is a good example how luddite users rather stay stuck in a UNIX System V world with their green phosphor VT100 terminals.
- IshKebab 11y ago
  Well said. This reads like someone complaining about the metric system because you can't easily divide metres into twelfths. Those kinds of people will always exist - they've spent many hours learning it the good old hard way, and I'm damned if you kids are going to make it any easier! You lazy so-and-sos.
- digi_owl 11y ago
  Thing is, Linux used to be flexible. This because of some stuff it inherited from Unix about user space being made out of loosely coupled parts with solidified interfaces between them. Meaning that it could accomodate both the latest and "greatest" coming out of the labs, and the tried and tested stuff that had been sitting in production for a decade. systemd instead gloops it all into a lightly coupled shoggoth of a project that is chasing the future come hell or high water.
xroche 11y ago
> nearly everyone (or at least the most vocal crowd) seems to either love it or hate it "At least the most vocal crowd". Which means that most people DO NOT CARE, and the systemd war is beyond ridiculous. As Linus said, > "I don't actually have any particularly strong opinions on systemd itself."
- jfindley 11y ago
  The systemd war is probably the best thing that could have happened to ensure widespread adoption of systemd. It allowed the supporters to lump anyone with any concerns or objections in with the frothing-at-the-mouth haters, and completely ignore them. I don't hate systemd. I like what it's trying to do, and I don't hate the big-picture implementation either. But I, and many others, have a bunch of concerns around some specific details of the system, that got ignored and swept under the rug in the tide of vitriol between the two sides of the "war". If the discussion had been more civil, maybe the more rational objections might have got heard, and we might have been able to pressure Lennart and Kay into not rolling their own, un-reviewed, crypto for journald[0]. We might have been able to avoid some of the feature-creep[1] that seems to have grown out of a NIH-mentality, and a better relationship with the community might have made the core developers more willing to play nicely with others[2][3]. 0: http://lwn.net/Articles/512895/ http://lwn.net/Articles/512895/ 1: http://www.freedesktop.org/software/systemd/man/systemd-resolved.service.html http://www.freedesktop.org/software/systemd/man/systemd-reso... 2: https://bugs.freedesktop.org/show_bug.cgi?id=76935 https://bugs.freedesktop.org/show_bug.cgi?id=76935 3: https://bugzilla.redhat.com/show_bug.cgi?id=1116651 https://bugzilla.redhat.com/show_bug.cgi?id=1116651
  - EmanueleAina 11y ago
    Why is resolved feature-creep? It's rather nice to have working name resolution out of the box when coupling it with networkd and firing up a container. I mean, it's not my standard usecase in this moment of my life, but I see how it can be useful. (Also, your last link reports that "This bug is for livecd-tools which has been fixed", I don't know what's the point you're trying to make.)
eleitl 11y ago
Pretty much the same reason why I'm slowly moving to FreeBSD. OpenBSD is another possibility.
stefantalpalaru 11y ago
Why would you punish yourself with various *BSDs when you can have OpenRC and more advanced ports on Gentoo? Do people really associate systemd, Gnome and other nuisances with Linux?
- rockdoe 11y ago
  Given that it's the default and sometimes only working option for many of the most popular Linux distros: yes.
  - yellowapple 11y ago
    Given also that systemd is Linux-only due to its reliance on cgroups: yes.
    - rockdoe 11y ago
      That doesn't stop you from having a Linux system without systemd, though.
      - yellowapple 11y ago
        True (as I know firsthand, thanks to several Slackware-running machines that I own). My remark was just in response to the question of systemd being tied to Linux.
- BFay 11y ago
  Don't you have to build every package from source with Gentoo? I can see where that would be useful, but isn't it really time-consuming (or punishing, if you prefer that word)?
  - stefantalpalaru 11y ago
    It wasn't a deterrent when I had a Pentium 3 at 600 MHz, it sure isn't now when I have a FX-8320E at 4.5 GHz. I actually prefer from-source package installs because I get a higher degree of control over configuration options.
deleted 11y ago
[deleted]
vezzy-fnord 11y ago
To all those who complain about unreadable initscripts, please see: http://homepage.ntlworld.com./jonathan.deboynepollard/FGA/run-scripts-and-service-units-side-by-side.html http://homepage.ntlworld.com./jonathan.deboynepollard/FGA/ru...
davexunit 11y ago
Some of the complaints resonate with me. In particular, the limited power of systemd's unit file DSL is why I think it's better to allow services to be written using a general purpose programming language. GNU dmd, while still not developed enough to do cool things like socket activation, gives the user the full power of Scheme to configure their system services as they like. I run it as PID 1 on two of my machines, and I also run it as an unprivileged user to manage my gpg agent, emacs daemon, offlineimap, mpd, development web servers, etc. on all of the computers I use, including at work. I think people that aren't happy with systemd, that are also interested in rolling up their sleeves and hacking on an init system, should give dmd some love. https://gnu.org/s/dmd https://gnu.org/s/dmd
Tiksi 11y ago
About a year ago, we started switching over new servers to systemd instead of openrc at work. I knew sysv/openrc/bsdinit and I liked them so for the first month or two I utterly despised systemd. (Plus as a sysadmin it seems like I have to hate it or risk losing my linux card) I just wanted my damn scripts back instead of dealing with the .ini-inspired config file crap. If I had a choice at the time, I would've been willing to move to busybox-init just to get away from systemd. Had I spent less time complaining to my coworkers about how much it sucked, I probably would've written this post myself. But little by little it grew on me. Oh, so if an nfs mount fails on boot, it's not going to just sit there and hang? I guess that's pretty cool, saves me from having to throw a console on it while muttering under my breath. And it didn't start nginx either, so it's not going to serve a half broken site and tell the loadbalancer all is good? Maybe it's not all that bad. No no, what am I thinking, this is still crap, I could've written all this in to the init scripts (but I didn't). This client's service is irritatingly unreliable, maybe I should write a wrapper to supervise it. Someone must have done something like this for syst... Restart=OnFailure... well that's nifty. Ugh, monitoring daemon ate up all the memory again, why can't the vendor get their shit together or the client switch to something that isn't useless. Guess I'll google some ideas for a watchdog script. Hmm, looks like I can just throw MemoryLimit and Restart=onfailure in the unit? No way it's that easy. (it was) After a couple months of this, systemd actually started to seem useful, I even started having a little bit of dread when hopping on an older server and having to deal with openrc. All of the complaints here really seem off base to me now that I've had a chunk of time to figure it out. Init scripts pissed me off when I didn't have much experience with them too. Now, thats not to say I like everything about the systemd switch. netctl is utterly worthless for anything other than a static ipv4 address (and reenable, really?). I still forward all my logs to syslog, because I prefer text files (and all the awk/sed/grep/cut/sort/column/etc goodness that comes with them) for anything more than running `systemctl status <service>` and seeing that I accidentally the config file for something. I also don't buy the whole "It should be on desktops, not servers" because I don't see much of an advantage for desktops, other than maybe the trivially faster boots. Wifi is a pain in the ass with netctl and netctl doesn't seem play well with anything else. But for servers, I've found it to be pretty awesome. To address a few things straight from the article that I disagree with: >At least one Debian package (memcached) is already invoking a wrapper script from ExecStart. This is exactly why I don't understand the whole argument around it being inflexible. If you need to call a script that does some setup that's incompatible with systemd, call the script? It's no different from helper scripts that many packages used with init scripts. If you still want to do some checks and call start-stop-daemon, go right ahead, nothing is stopping you. It seems pretty strange to consider it a fault that you can't use a bash script, and then complain that you'll have to use a bash script. >Here, let me helpfully tell you that you should run systemctl daemon-reload, but perform the action you requested using the old configuration anyway. This really seems like a trivial complaint. I guess you could always alias systemctl="systemctl daemon-reload; systemctl" if it's that much of an issue. Personally it's saved me after an accidental :wq (damn that muscle memory). "File has changed on disk" uhhh it shouldn't have. crap. I guess it's a matter of preference. Also I didn't even know systemctl edit was a thing. That does seem kinda pointless, but it also seems kinda pointless to be bent out of shape over it. Do you also cat `* * * * * command >> /var/spool/cron/crontabs/$USER` because crontab -e is babysitting you? (I used to do that, but because e and r are too close together and reconstructing a crontab from logs is painful. Now I just alias crontab="crontab -l; crontab") >Now, systemd does rely heavily on D-Bus I've never run into issues with it, but I do agree with you on that point from a philosophical standpoint. >And yes, you can avoid the whole issue just by masking any units you don't want to start, but that's missing the point. The only point I see is that it's different. Of course whatever you're used to is going to be more effecient to you than something new. >I believe it creates more problems than it solves. Sadly, many of those problems will take years to become apparent, by which time all the major Linux distributions will have fully integrated it. Well it definitely seems to solve more problems for me than it creates, and saying those problems will only be apparent years down the road is not only impossible to argue against, it's a hand wavy cop out of "Trust me, its just bad! Because reasons!" However this does touch on what is probably my biggest gripe with systemd, and that is that ALL the big distros seem to be switching. Granted I don't mind from a having-to-use-it angle, since I personally prefer it and would probably stick with distros that do anyways, but it does give me a certain unease, it may be my choice but it shouldn't be the only one, and I'd have the same problem if it was sysv that everyone switched to. All in all, these complaints really just seem like complaining that it's different. And it is different, but that doesn't necessarily make it better or worse, just takes time to get used to.
exelius 11y ago
This is the first anti-systemd article that I've read that focuses exclusively on the technical issues with it (well, mostly: the last one kind of gets touchy on the politics). And this article is a good summarization of them. Linux in the server world is rapidly turning into a thin platform hosting containers (docker, kubernetes, etc) of "fat" Linux distros. Systemd makes a lot more sense if you consider it in that context: a container can use systemd to have the host start a monitoring process whenever any processes are executed, etc. Sure, this probably could have been grafted on to sysvinit, but it would have been an ugly hack just like every other thing that's been grafted on to sysvinit. Linux everywhere else but the server world is all about low power usage and tight integration with custom hardware. Embedded devices, mobile phones, tablets, wearables, etc. All of these use cases demand an init system that is aware of and able to manage the system power state as a gradient, not a binary value. Again, this could probably be hacked on to sysvinit or the kernel itself, but would require big kernel changes and likely a fork for "Mobile Linux" and "Server Linux" as the market begins to demand power-aware schedulers, memory mappers, etc. If the computing world were to remain in a paradigm where we run small physical or virtual servers dedicated to tasks, then sysvinit would be fine. But that's not where we are today nor where we will be, and sysvinit simply isn't flexible enough for a lot of the use cases where Linux is seen today. The *BSDs exist if you want a rock-solid and simple x86 Unix system for hosting traditional applications in a client-server setup; but if you want a flexible platform for building arbitrary products, Linux is the way to go.
- jeffreyrogers 11y ago
  Thanks, I think your perspective on the different use cases for Linux vs *BSD were helpful and something I hadn't seen all in one place before.
monksy 11y ago
Thats one responsive site!
jingo 11y ago
"It babysits its users"
mm_aa 11y ago
It seems that the author completely disregards the modern tendency to treat boxes as commodities. While pondering a "what's going to start on this particular machine" question is interesting in the "old world", it is hardly a question anyone asks when your fleet starts to be measured in tens of thousands of cloud instances.
- digi_owl 11y ago
  No, his issue is that because others choose to do so he has to do so because the fad of the year is tramping all over the alternatives.
tfft 11y ago
I love the valid html/css icons at the bottom while the whole page is just a yellow text on a black background.

174 points by geoffbp 11y ago

Steven, if you're reading, you got your history slightly wrong. System V got its init handling from Sun's SunOS 4.x. It was negotiated as part of the integration between SunOS and System V which would become the "one UNIX for everyone". Unfortunately for all of us, AT&T really really loved "run levels" and Sun really really liked BSD's way of configuring the system. Which got you the unholy love child you saw in Solaris 2.0 and System V release 2.0. For the other Sun folks from the systems group who quit rather than submit to the demands, you were right, I was wrong. We couldn't convince them of the error of their ways.

deleted 11y ago
[deleted]
yuhong 11y ago
This history looks wrong. Eg it was SVR4 that merged SunOS
- ChuckMcM 11y ago
  You are correct it was System V, release 4 that merged with SunOS. It was also the release that Sun and AT&T "combined" the BSD init/rc system with the System V init/run-level system.
StevenJM 11y ago
Thanks for the info. I've updated that section of the article with a note (and a link to this thread).

tilt_error 11y ago

My eyeballs just exploded... Unreadable.

dredmorbius 11y ago
Readability's bookmarklets help: https://www.readability.com/bookmarklets/ https://www.readability.com/bookmarklets/ (But, yeah.)
- skrause 11y ago
  I recommend the "zap colors" bookmarklet from https://www.squarefree.com/bookmarklets/zap.html https://www.squarefree.com/bookmarklets/zap.html It simply changes all colors so that text is black-on-white, but leaves everything else unchanged.
  - dredmorbius 11y ago
    Sadly, it's not just colours that are the problem. Font sizes, poorly sized and laid-out pages, overlapping divs and other elements, animiations.... Readability fixes most of that quickly.
- Reefersleep 11y ago
  The newest version of Firefox has a little icon resembling an open book at the right side of address field that does something similar. Quite handy :)
  - dredmorbius 11y ago
    Nice. I'd prefer that was the _default_ browser view, frankly.
deleted 11y ago
[deleted]
- BinaryIdiot 11y ago
  I think OP's issue is with the low contrast between yellow and black; it is suboptimal for reading. It was readable but could have been better with some slight color changes.

empressplay 11y ago

I don't "hate" systemd either, I just think it's a bad approach. It flies in the face of the "open architecture" concept and stifles innovation. It discourages users from learning about how their operating system works, and it unnecessarily puts too much control of a fundamental component of the OS in the hands of a too-small number of people. None of these reflect the Linux I grew up with. Thus, I am not a fan of systemd. #notmylinux

ossreality 11y ago
What a completely unsubstantiated load of FUD. >#notmylinux oh, you're just a troll. k..
cubancigar11 11y ago
ossreality you are [dead]
- deleted 11y ago
  [deleted]
- cubancigar11 11y ago
  People downmodding this have really nothing better to do?
olau 11y ago
Interesting way to think about it. IMHO systemd is taking much of the hacks and weird glue that has historically held distributions together and replaced it with an active upstream project. Maybe some of the solutions they've come up with could need some improvements, but I have much higher confidence those improvements would happen now compared to how things used to be. Nowadays you can code something up and come to the systemd mailing list and get feedback and get it integrated. Previously you'd have to convince one or more not-really-connected distro hackers that your new fancy thing is worth rocking the boat for.
- weland 11y ago
  Unfortunately, the systemd development team is not that easy to work with, which is part of why a lot of people distrust systemd the way they do. In theory, yes, it should be the way you mention it. In practice, even bug reports end up unacknowledged and labeled as features after a few philosophical debates. No one who has used more than one Linux distro would disagree that a unified system to control init services is a good idea. It's this particular implementation that's problematic, not the principle.

keypusher 11y ago

I agree with most of this, especially the fact that complexity has simply been shifted to other places. It's much easier for me to read a systemd unit file than it was for me to read a complex set of init scripts. The problem is that when I have 10 or 20 units with interlocking dependencies, it's an absolute nightmare to try and untangle because I have to jump between so many different files. Having to specify After=X and Requires=X seems like a prime example of optimizing for the 1% usecase. 99% of the time, when A must start after B, it's because A requires B. Having to specify both is something that is easily and often missed, and a hard problem to track down if you didn't read the documentation carefully. There's also the problem that it seems to be metastasizing and taking other parts of the OS. The longstanding /var/log/messages is now replaced by journalctl tool, and the logs are actually in binary. The venerable "hostname" command is now "hostnamectl" because it must go through systemd. They have also replaced chroot with systemd-nspawn, and made it so you cannot even use systemd while in a normal chroot!

vacri 11y ago
$0.02: journalctl isn't even tab-completable until you've nearly finished typing it. :)
- ibotty 11y ago
  depends on what you have in your path.
  - yellowapple 11y ago
    I feel like systemd's tools and Emacs are on a race to achieve the title of "only program(s) necessary in one's path to have a fully-featured operating system". :)
erikb 11y ago
Have you tried the systemd tooling that graphs depencies for you? I haven't worked on that area yet, but my colleagues made heavy use of that and actually could resolve problems with these quite fast thanks to the diagrams that systemd can create for you.

ghshephard 11y ago

There is something epically beautiful about OpenBSD's consistency over the last 10 years. I swear that a 2004 OpenBSD sysadmin would be close to 100% efficient with a circa 2015 OpenBSD system, despite the absolutely massive number of improvements and changes that have been made with the operating system. Once systemd starts to get traction, it's cognitive overhead is going to become a real problem for sysadmins who want to be able to model the entire boot process and run-state in their head. For better or worse (I honestly don't know which, btw), you are going to have to start to trust the operating system to manage its boot process/run-state correctly rather than having it be a direct implementation of your mental model. (I would argue other *nix Operating systems, like OS X, have, to some degree, been doing that successfully for a while, so it's certainly possible - just not clear whether you want that type of behavior on your server systems. I guess time will tell.)

stephen_g 11y ago
I'm not a professional sysadmin, but as a developer with a bunch of virtual servers systemd has only made things far easier. Writing init scripts used to be a real pain, now I can set up a unit file in two minutes and it works... Maybe there's something to be said for "sysadmins who want to be able to model the entire boot process and run-state in their head" but with correct information about dependencies and so on, I personally think that's something computers are a lot better at solving.
- empressplay 11y ago
  ...and that's awesome if you don't need 99.9% uptime and thus need to have absolute faith in your system's stability. However, for mission-critical applications that do it's hard to argue that systemd is a better solution than writing all your scripts by hand. Unless you want to be able to blame systemd if it all goes pear-shaped but I doubt your boss will buy it =)
  - bad_user 11y ago
    I would argue that features such as having explicit dependencies are absolutely required for 99.9% uptime. Building systems resilient to failures also means being able to predictably spin up new instances that you can trust. I'm also a developer and for example one problem I had with my servers on AWS was that my process sometimes happened to start before my volume meant for logs was mounted, which meant that all logs were going to my primary volume, with the server crashing at some point due to out of space errors. Another time I was using a local database meant for local caching and again, sometimes it would fully initialize only after my main process was started. And because I was using ELB with auto-scaling, it meant that these incorrectly started servers would be connected to the load-balancer, because the main process was suddenly responding to /ping, even though it wasn't ready yet. And then it would receive thousands of requests per second per server, at a moment in time in which the cluster badly needed fresh instances, which led to an unstable cluster. But only sometimes ;-)

devnonymous 11y ago

One of the more sensible ^rants^ I've read against systemd (it is KISS for some weirdly convoluted definition of KISS). Too bad these naysayers are not/will not be taken seriously.

vacri 11y ago
The naysayers are taken seriously, but they're in the decision-making minority. Linux distro maintainers wanted to move on from SysV Init, and systemd looked promising. Just because the naysayers didn't get their way (and on some distros, they did) doesn't mean that their criticisms aren't noted.
- thaumaturgy 11y ago
  Which distros? Slackware is the only near-mainstream Linux distro I know of that is even possibly not moving immediately to systemd, and even then, the Slackware folks have said that once it becomes too difficult to maintain upstream packages, they'll switch too. They're just being pragmatic about it.
  - vacri 11y ago
    I thought there were others in addition to Slackware, but that pretty much all the distros are jumping ship shows the naysayers don't have enough political oomph.
    - digi_owl 11y ago
      Those that has adopted systemd are either precursors for commercial distros, said commercial distros, or based of same. The really early adopters seems to have been offshots of Fedora. And i do wonder if Debian was a holdout until systemd started sprouting containerization features, and Canonical (Ubuntu) was feeling the heat.
  - cubancigar11 11y ago
    Gentoo by default prefers OpenRC over systemd, though you can chose which one you want while installing.

swhipple 11y ago

The author mentions that he believes the biggest problem of systemd is repeating some mistakes of SysV init, but I think it's actually pretty important that familiarity is preserved to help people upgrade. For example, the author mentions babysitting the users (systemctl edit) and config/daemon reloading as things that could be made automatic, I'm assuming with e.g. inotify change events. But you often want some confidence that the change you're making to your system is what you expect, and we've had them all along: - visudo(8) sanity checks, for atomicity and syntax, to help prevent you from bricking your authorization - an explicit SIGHUP to reload the configuration file for your daemon, after you've checked the config, rather than accidentally saving your file while you're editing it and bringing down your daemon. You could expect everyone to adopt new practices for editing the configurations, but the behavior would be very surprising to anyone used to the old way.

bluejekyll 11y ago
What I think your getting at is that essentially you need a mechanism to commit your changes before the thing that's reading those changes receives them. In essence, an atomic operation for the change. Completely agree.
- pjc50 11y ago
  I'm hearing "we need to build a version control system or a transactional database into our init daemon" here :)
  - bad_user 11y ago
    Version control systems and transactional databases are built over atomic operations. Transactions in particular refer to having multiple operations that either succeed or fail all at once, making in essence atomic operations composable (they normally aren't). Editing a file and saving it multiple times is not an atomic operation, but reading a file can be, so having the user issue a reload command only after he's finished editing a file is an entirely reasonable approach that has been used in Linux since forever and it only shares some basic building blocks with version control or transactions, but there's nothing fancy about the approach. Fancy and very error-prone would be to apply configuration changes automatically, which is what the article seems to suggest. In other words the joke is lame :-P

jveld 11y ago

It got the job done by making the 99% majority of use cases more difficult in order to make the 1% minority simpler. This is a design pattern I think is being repeated in systemd. I kinda had the opposite impression. I first encountered systemd when I started messing around with arch for a couple little vps projects. At the time I was doing sysadmin that involved both Ubuntu and CentOS, and I definitely found day-to-day tasks easier with systemd (better built in monitoring, consistent syntax, etc). For simple cases, writing a unit file sucks a lot less than writing an initscript. The warts in systemd only started to irritate me when I was first setting up my personal machines (one laptop, one tower) to run arch [1]. Even then, the bloat in the design irked me more than actually using it. So, I'm in favor of systemd, but not thrilled (dbus everywhere is annoying). Then again, I don't maintain any packages with strange and/or complex daemons. If anybody's had a really hard time getting their stuff to work with systemd, I'd be interested to hear stories. 1: Not completely true. I want my damn log files back.

thaumaturgy 11y ago
This is why I suspect that most of the divisions in the sysadmin community regarding systemd are generational. For people (like me!) who have been writing init scripts forever and can do it in their sleep, they'd prefer the flexibility and familiarity of init scripts to a new system that at first glance appears more limited. For people who are less experien^H^H^H^H^H^H^H^Hcrusty :-), init scripts look like a horrifying way to manage a startup process, and just about anything -- including Yet Another Config File Format -- looks preferable. I think this is also why so little progress is being made on resolving conflicts over systemd. There really isn't a whole lot of room for compromise; one group simply wants things to stay more or less the same (or evolve incrementally), the other group simply wants to throw it all out and start over. I bet there would've been a lot less argument and vitriol about systemd if Debian hadn't made the decision to default to it, basically leaving all the crusty sysadmins homeless. Once Debian switched, there was a near guarantee that all of Linux was going to move to systemd. That suits one group just fine, another one not so much. On the plus side, the BSDs should be seeing a really nice upswell of installations over the next couple of years, which is great, because they've been quietly building some pretty great operating systems that deserve more love.

stoplight 11y ago

Am I missing something? The author states: > Try to find the answer to "which units are going to be started on next boot?". Isn't this just `ls /etc/systemd/{user,system,network}//*` (bah HN formatting is messing this up) Also the other states: > Speaking of which, why is systemctl daemon-reload even a thing? Because configuration changes while things are running. Otherwise we wouldn't need apache2 reload, nginx reload, haproxy reload, etc. Also, according to the man page: > After the units have been edited, systemd configuration is reloaded (in a way that is equivalent to daemon-reload). As for systemctl edit, it allows you to add diffs to the unit file. For example, let's say I am using redis and I want to ensure it always restarts (for whatever reason). Rather than manually editing the unit file (which will have issues if an upstream change happens), I can simply use systemctl edit to add a diff for my change. This way I can still maintain compatibility with the upstream unit file instead of having to deal with potential conflicts. It's not so much babysitting the user as it is a potentially better experience.

ploxiln 11y ago
> Isn't this just `ls /etc/systemd/{user,system,network}//*` (bah HN formatting is messing this up) Nope. There are many virtual units for which there are no files. One example is the on-demand getty units. There are two for "plymouth" boot-splash stuff (I see these attempted-and-failed units on archlinux where plymouth never exists). There's some autofs thing. There's auditd. I'm actually not booted into linux right now so I'm struggling to remember the specifics... but if you also count all the simple mounts and devices which clutter up the output of "systemd --all" as "units which are not files in /etc/systemd" then the count is around 100.
- INTPenis 11y ago
  Couldn't/Shouldn't this be solved with some script that traces the dependencies of units? I'm not familiar enough with systemd to understand how to trace dependencies and create a complete list of all units that will run at next boot but I expect this to be doable by someone with that expertise.
  - 11y ago

belorn 11y ago

With System V and Debian, one added some new apache or bind configuration and then called invoke-rc.d daemon reload to inform the daemon to reread the configuration files. With systemd, you do the exact same thing and then call systemctl reload daemon. Is the author making an argument here based some other distributions way of handling System V?

JdeBP 11y ago
No. The author is not getting reloading the daemon's configuration mixed up with reloading systemd's configuration. You, however, are. The systemctl manual page warns about this mistake. See what it says under daemon-reload.

weland 11y ago

I'm one of the people who jumped ship to OpenBSD in the last year or so. I think I first touched a Linux machine in 1997 or 1998. systemd has been part of the reasons I did that for precisely the same reason. There is a lot of development in the ecosystem dominated by Freedesktop.org, Gnome and (to some degree) large commercial players like RedHat and SUSE. It's more efervescent than it's ever been. Fifteen years ago, I'd have been ecstatic to see so much development being done. Yet for all this fierce code churning, there's absurdly little innovation. Even in systemd, there's a lot of focus on non-issues like booting without needing a shell, while still inventing service startup notification types because none of the gazillion startup notification types already existent can actually solve precisely the problem systemd claims it solves -- managing complex startup chains. In the last three or four years, my Linux systems have become increasingly blackboxed, and consequently harder and harder to configure, let along debug when they stop working. Over the span of six months, a tool you just got to learn how to work with (mostly because the documentation seems to have been written by very bored and very verbose monkeys who had only a typewriter to pass the time with) becomes obsolete or is revamped to be unrecognizable. Which would be fine if that actually solved any problems. Instead, it replaces the old set of problems with a new, even more complicated set of problems that developers claim you shouldn't have, while insisting that the old problems were simply due to the old architecture and we'll have none of that now that we have this shiny new thing. Ironically, systemd is actually one of the better pieces of software to come out of that ecosystem. No, seriously. It's decently documented and as long as you don't need anything more complex than "here, start this daemon after this other daemon started", it does its job. If you want to peck at something, have a look at Polkit, where someone brilliantly figured out that the best way to configure policies is to write basically undebugable JavaScript code in .rules files.

anon3_ 11y ago
> I'm one of the people who jumped ship to OpenBSD in the last year or so. Ha. FreeBSD here. And so long as you get the right hardware, I find BSD to be far simpler than linux distributions out there. Ports? Beautifully elegant and simple. Configurable. Magnitudes easier than configuring rpm/debs. Getting a package approved in debian? Alioth? No offense, the wiki, all these pages on the debian website - they have no concept they have of "Handbook", in the sense FreeBSD has. It's so adhoc, they're healthy, but they're in denial about how hard they make it for new people. By the time you've taken to time to learn Debian's dev warts, you're apart of the convent and no longer care about fixing the onboarding problems. But to be fair. I have day to day gripes with FreeBSD just because we're short on the manpower Linux distributions have in excess: On FreeBSD 10.1, chromium crashing easily, settings doesn't work. Firefox just clogs up and stops working. No skype (CURRENT will be in a better position to since epoll support has been added). No Dropbox (as of now, we don't have inotify, and kqueue may not be able to handle it, don't quote me on that). I do my 90% of daily routines simpler and better on FreeBSD. If only Google / Mozilla (with all the resources they have) gave someone who could work to fix this stuff.

octref 11y ago

This page's horrible readability is a perfect reflection of the kind of folks that dislike systemd. Yeah, newcomers to the Linux land without the expertise you guys acquired through 10 years of using Linux, would apparently appreciate how easy it is to manage a server by invoking some lengthy commands they learned through reading the often overly-dense manual instead of `systemctl start/stop x`. Nowadays some of those so-called "hackers" tend to ignore the part of work that makes the user experience better. They claim that they want simplicity and avoid bloat but most of the times they are just being lazy and not sympathetic to their users. I'm not saying that things should be dumbed down to clicking GUI buttons on Linux. But if you want your program to become mainstream you need to think about providing good and practical docs and making your program easier to use, even for text-based programs. Accept that most people would like Bootstrap'ed sites more than yours: body { background-color: #080808; color: #ffff70; font-family: sans; } That's why I opt for Ubuntu 15.04 instead of 14.04 LTS on my VPS, since 15.04 has systemd.

cthalupa 11y ago
Are we really using website design choices as a valid target to discredit someone's opinion on the technical merit of an init system? Can I use Lennart's inability to buy a properly sized polo as a reason why systemd is bad? Yeah. The guy has an ugly website. But he has specific points about mistakes that systemd didn't learn from and is repeating. Did he list 'it's too user friendly' as one of those mistakes? In fact, one of his core arguments is that there will actually be an increase in complexity and reduction in user friendliness due to design choices that have been made.
- octref 11y ago
  I'm saying that, if people keep responding to those less-experienced Linux users who complain init scripts too complex by saying "Quite. Deal with it." like this author (http://www.steven-mcdonald.id.au/ugly.shtml http://www.steven-mcdonald.id.au/ugly.shtml), I fail to see how systemd is gonna fail. My comment is not about design choices but attitude and sympathy to users. This is not intended as an ad-hominem. The author seems to think systemd "babysits" its users, but as a user I find systemd "cares" about its users.

pjmlp 11y ago

I don't care about systemd, as I want to use OSes that embrace modern architectures, unikernels, containers, safer programming languages, improved UI stacks,.... This rant is a good example how luddite users rather stay stuck in a UNIX System V world with their green phosphor VT100 terminals.

IshKebab 11y ago
Well said. This reads like someone complaining about the metric system because you can't easily divide metres into twelfths. Those kinds of people will always exist - they've spent many hours learning it the good old hard way, and I'm damned if you kids are going to make it any easier! You lazy so-and-sos.
digi_owl 11y ago
Thing is, Linux used to be flexible. This because of some stuff it inherited from Unix about user space being made out of loosely coupled parts with solidified interfaces between them. Meaning that it could accomodate both the latest and "greatest" coming out of the labs, and the tried and tested stuff that had been sitting in production for a decade. systemd instead gloops it all into a lightly coupled shoggoth of a project that is chasing the future come hell or high water.

xroche 11y ago

> nearly everyone (or at least the most vocal crowd) seems to either love it or hate it "At least the most vocal crowd". Which means that most people DO NOT CARE, and the systemd war is beyond ridiculous. As Linus said, > "I don't actually have any particularly strong opinions on systemd itself."

jfindley 11y ago
The systemd war is probably the best thing that could have happened to ensure widespread adoption of systemd. It allowed the supporters to lump anyone with any concerns or objections in with the frothing-at-the-mouth haters, and completely ignore them. I don't hate systemd. I like what it's trying to do, and I don't hate the big-picture implementation either. But I, and many others, have a bunch of concerns around some specific details of the system, that got ignored and swept under the rug in the tide of vitriol between the two sides of the "war". If the discussion had been more civil, maybe the more rational objections might have got heard, and we might have been able to pressure Lennart and Kay into not rolling their own, un-reviewed, crypto for journald[0]. We might have been able to avoid some of the feature-creep[1] that seems to have grown out of a NIH-mentality, and a better relationship with the community might have made the core developers more willing to play nicely with others[2][3]. 0: http://lwn.net/Articles/512895/ http://lwn.net/Articles/512895/ 1: http://www.freedesktop.org/software/systemd/man/systemd-resolved.service.html http://www.freedesktop.org/software/systemd/man/systemd-reso... 2: https://bugs.freedesktop.org/show_bug.cgi?id=76935 https://bugs.freedesktop.org/show_bug.cgi?id=76935 3: https://bugzilla.redhat.com/show_bug.cgi?id=1116651 https://bugzilla.redhat.com/show_bug.cgi?id=1116651
- EmanueleAina 11y ago
  Why is resolved feature-creep? It's rather nice to have working name resolution out of the box when coupling it with networkd and firing up a container. I mean, it's not my standard usecase in this moment of my life, but I see how it can be useful. (Also, your last link reports that "This bug is for livecd-tools which has been fixed", I don't know what's the point you're trying to make.)

eleitl 11y ago

Pretty much the same reason why I'm slowly moving to FreeBSD. OpenBSD is another possibility.

stefantalpalaru 11y ago

Why would you punish yourself with various *BSDs when you can have OpenRC and more advanced ports on Gentoo? Do people really associate systemd, Gnome and other nuisances with Linux?

rockdoe 11y ago
Given that it's the default and sometimes only working option for many of the most popular Linux distros: yes.
- yellowapple 11y ago
  Given also that systemd is Linux-only due to its reliance on cgroups: yes.
  - rockdoe 11y ago
    That doesn't stop you from having a Linux system without systemd, though.
    - yellowapple 11y ago
      True (as I know firsthand, thanks to several Slackware-running machines that I own). My remark was just in response to the question of systemd being tied to Linux.
BFay 11y ago
Don't you have to build every package from source with Gentoo? I can see where that would be useful, but isn't it really time-consuming (or punishing, if you prefer that word)?
- stefantalpalaru 11y ago
  It wasn't a deterrent when I had a Pentium 3 at 600 MHz, it sure isn't now when I have a FX-8320E at 4.5 GHz. I actually prefer from-source package installs because I get a higher degree of control over configuration options.

deleted 11y ago

[deleted]

vezzy-fnord 11y ago

To all those who complain about unreadable initscripts, please see: http://homepage.ntlworld.com./jonathan.deboynepollard/FGA/run-scripts-and-service-units-side-by-side.html http://homepage.ntlworld.com./jonathan.deboynepollard/FGA/ru...

davexunit 11y ago

Some of the complaints resonate with me. In particular, the limited power of systemd's unit file DSL is why I think it's better to allow services to be written using a general purpose programming language. GNU dmd, while still not developed enough to do cool things like socket activation, gives the user the full power of Scheme to configure their system services as they like. I run it as PID 1 on two of my machines, and I also run it as an unprivileged user to manage my gpg agent, emacs daemon, offlineimap, mpd, development web servers, etc. on all of the computers I use, including at work. I think people that aren't happy with systemd, that are also interested in rolling up their sleeves and hacking on an init system, should give dmd some love. https://gnu.org/s/dmd https://gnu.org/s/dmd

Tiksi 11y ago

About a year ago, we started switching over new servers to systemd instead of openrc at work. I knew sysv/openrc/bsdinit and I liked them so for the first month or two I utterly despised systemd. (Plus as a sysadmin it seems like I have to hate it or risk losing my linux card) I just wanted my damn scripts back instead of dealing with the .ini-inspired config file crap. If I had a choice at the time, I would've been willing to move to busybox-init just to get away from systemd. Had I spent less time complaining to my coworkers about how much it sucked, I probably would've written this post myself. But little by little it grew on me. Oh, so if an nfs mount fails on boot, it's not going to just sit there and hang? I guess that's pretty cool, saves me from having to throw a console on it while muttering under my breath. And it didn't start nginx either, so it's not going to serve a half broken site and tell the loadbalancer all is good? Maybe it's not all that bad. No no, what am I thinking, this is still crap, I could've written all this in to the init scripts (but I didn't). This client's service is irritatingly unreliable, maybe I should write a wrapper to supervise it. Someone must have done something like this for syst... Restart=OnFailure... well that's nifty. Ugh, monitoring daemon ate up all the memory again, why can't the vendor get their shit together or the client switch to something that isn't useless. Guess I'll google some ideas for a watchdog script. Hmm, looks like I can just throw MemoryLimit and Restart=onfailure in the unit? No way it's that easy. (it was) After a couple months of this, systemd actually started to seem useful, I even started having a little bit of dread when hopping on an older server and having to deal with openrc. All of the complaints here really seem off base to me now that I've had a chunk of time to figure it out. Init scripts pissed me off when I didn't have much experience with them too. Now, thats not to say I like everything about the systemd switch. netctl is utterly worthless for anything other than a static ipv4 address (and reenable, really?). I still forward all my logs to syslog, because I prefer text files (and all the awk/sed/grep/cut/sort/column/etc goodness that comes with them) for anything more than running `systemctl status <service>` and seeing that I accidentally the config file for something. I also don't buy the whole "It should be on desktops, not servers" because I don't see much of an advantage for desktops, other than maybe the trivially faster boots. Wifi is a pain in the ass with netctl and netctl doesn't seem play well with anything else. But for servers, I've found it to be pretty awesome. To address a few things straight from the article that I disagree with: >At least one Debian package (memcached) is already invoking a wrapper script from ExecStart. This is exactly why I don't understand the whole argument around it being inflexible. If you need to call a script that does some setup that's incompatible with systemd, call the script? It's no different from helper scripts that many packages used with init scripts. If you still want to do some checks and call start-stop-daemon, go right ahead, nothing is stopping you. It seems pretty strange to consider it a fault that you can't use a bash script, and then complain that you'll have to use a bash script. >Here, let me helpfully tell you that you should run systemctl daemon-reload, but perform the action you requested using the old configuration anyway. This really seems like a trivial complaint. I guess you could always alias systemctl="systemctl daemon-reload; systemctl" if it's that much of an issue. Personally it's saved me after an accidental :wq (damn that muscle memory). "File has changed on disk" uhhh it shouldn't have. crap. I guess it's a matter of preference. Also I didn't even know systemctl edit was a thing. That does seem kinda pointless, but it also seems kinda pointless to be bent out of shape over it. Do you also cat `* * * * * command >> /var/spool/cron/crontabs/$USER` because crontab -e is babysitting you? (I used to do that, but because e and r are too close together and reconstructing a crontab from logs is painful. Now I just alias crontab="crontab -l; crontab") >Now, systemd does rely heavily on D-Bus I've never run into issues with it, but I do agree with you on that point from a philosophical standpoint. >And yes, you can avoid the whole issue just by masking any units you don't want to start, but that's missing the point. The only point I see is that it's different. Of course whatever you're used to is going to be more effecient to you than something new. >I believe it creates more problems than it solves. Sadly, many of those problems will take years to become apparent, by which time all the major Linux distributions will have fully integrated it. Well it definitely seems to solve more problems for me than it creates, and saying those problems will only be apparent years down the road is not only impossible to argue against, it's a hand wavy cop out of "Trust me, its just bad! Because reasons!" However this does touch on what is probably my biggest gripe with systemd, and that is that ALL the big distros seem to be switching. Granted I don't mind from a having-to-use-it angle, since I personally prefer it and would probably stick with distros that do anyways, but it does give me a certain unease, it may be my choice but it shouldn't be the only one, and I'd have the same problem if it was sysv that everyone switched to. All in all, these complaints really just seem like complaining that it's different. And it is different, but that doesn't necessarily make it better or worse, just takes time to get used to.

exelius 11y ago

This is the first anti-systemd article that I've read that focuses exclusively on the technical issues with it (well, mostly: the last one kind of gets touchy on the politics). And this article is a good summarization of them. Linux in the server world is rapidly turning into a thin platform hosting containers (docker, kubernetes, etc) of "fat" Linux distros. Systemd makes a lot more sense if you consider it in that context: a container can use systemd to have the host start a monitoring process whenever any processes are executed, etc. Sure, this probably could have been grafted on to sysvinit, but it would have been an ugly hack just like every other thing that's been grafted on to sysvinit. Linux everywhere else but the server world is all about low power usage and tight integration with custom hardware. Embedded devices, mobile phones, tablets, wearables, etc. All of these use cases demand an init system that is aware of and able to manage the system power state as a gradient, not a binary value. Again, this could probably be hacked on to sysvinit or the kernel itself, but would require big kernel changes and likely a fork for "Mobile Linux" and "Server Linux" as the market begins to demand power-aware schedulers, memory mappers, etc. If the computing world were to remain in a paradigm where we run small physical or virtual servers dedicated to tasks, then sysvinit would be fine. But that's not where we are today nor where we will be, and sysvinit simply isn't flexible enough for a lot of the use cases where Linux is seen today. The *BSDs exist if you want a rock-solid and simple x86 Unix system for hosting traditional applications in a client-server setup; but if you want a flexible platform for building arbitrary products, Linux is the way to go.

jeffreyrogers 11y ago
Thanks, I think your perspective on the different use cases for Linux vs *BSD were helpful and something I hadn't seen all in one place before.

monksy 11y ago

Thats one responsive site!

jingo 11y ago

"It babysits its users"

mm_aa 11y ago

It seems that the author completely disregards the modern tendency to treat boxes as commodities. While pondering a "what's going to start on this particular machine" question is interesting in the "old world", it is hardly a question anyone asks when your fleet starts to be measured in tens of thousands of cloud instances.

digi_owl 11y ago
No, his issue is that because others choose to do so he has to do so because the fad of the year is tramping all over the alternatives.

tfft 11y ago

I love the valid html/css icons at the bottom while the whole page is just a yellow text on a black background.