1. 47
  1.  

  2. 25

    Well, this is going to start some fights.

    I think it’s fair to say that we needed a better abstraction layer in this area, but personally I do feel that systemd has taken on a lot that perhaps it didn’t need to. The various non-core components can now handle init, boot, login, network, logging, udev, tempfile management, time sync…

    The argument that systemd is “not a monolithic binary” is all well and good but realistically if you install it, you’re still getting the whole package.

    I use systemd at work and (currently) at home and we mostly get on fine, but I’d be keen to see more lightweight alternatives to a modern init system being promoted.

    1. 10

      Well, this is going to start some fights.

      There’s a reason there’s a systemd tag, and that the bot in IRC replies “sigh” when the term is mentioned ;)

      I’m curious, is the dichotomy between large-scale Linux users who presumably would like more affordances for centralized control and logging, and the small-scale hobbyist whose comfortable with init scripts and just doesn’t feel the need for all the complexity?

      1. 21

        I think it’s a little more nuanced than those two extremes, right? I’d sketch out maybe these flavors of users:

        • Sysadmins doing massive fleets of Linux servers (FANG and banking and enterprise folks)
        • devs doing devops, who shove everything in containers
        • Hobbyists who specifically enjoy tinkering with Linux
        • “normal users” who just shove Ubuntu onto a box and basically just use it as a web browser or whatever
        • “normal” devs running a Linux because it looks a lot like prod
        • devs running a Linux because that’s where their software lives (people doing ML, some other types of work)

        In the case of enterprise folks, odds are that a lot of the systemd stuff (centralized logging, etc.) is already being handled by a different service, but appreciate not having to mess with sysv init or cron as much. The “normal” devs and users don’t really care. Container folks have containers specifically so they don’t have to mess with sysadminning (har har har), so they probably don’t care as much. Hobbyists are weirdos who recompile kernels for fun, and so have infinite patience to learn fuckery. None of those folks object, I think. The last two categories, though, are probably better served by boring and simple init scripts and text logs and so forth.

        The real split though, if I had to limit it to just two sides, is:

        • People who are ever in search of new technology that might make their life easier.
        • People who, once they’ve learned a system, are happy to get it going and who don’t like changes from without.

        The thorniness is, of course, that those groups talk past each other. The former group (Poettering et al.) bring in neat ideas (PulseAudio, DBugs, systemd) and uproot everything and talk about their (rightful) technical superiority, and tend to frankly come off as rather condescending–and then leave the 80% of the remaining work for the adults to do.

        The latter group hate having to rejigger or debug working systems or put in unpaid extra labor to figure out how to keep up with the times, and also tend to gloss over the (very real) deficiencies of the tools they already use–because they’re so used to them.

        1. 6

          I suppose I qualify as a “normal” dev. I run various sites and services on Linux, because that’s simpler overall. I want to get things working, and I don’t find these debates about what is the most “Unix-y” architecture very meaningful. I find myself liking systemd because it works right for the things I want it to do with a short, simple config file. This is compared to pre-systemd init systems that required long, confusing scripts that didn’t quite work right and I never got around to figuring out how to debug/fix.

          When working with previous init systems, I found myself wishing there was something as good as the Windows service system - maybe not architecturally perfect, but is proven and reliable, has all of the features that I realistically need, and doesn’t completely change between Windows versions.

          SystemD may be a change from previous systems, which is a little annoying in and of itself, but just being simpler and more reliable makes up for it IME. As of right now, I’m happy to stick with it. I even just read about using it to replace Cron in this thread, and feel a bit of enthusiasm about checking that out, what with all of the warts and obscurity that Cron has.

          1. 1

            Thanks for adding your views! I must admit the systemd debate hit when I was a bit out of the Linux sphere so I appreciate the background.

          2. 6

            I think a lot of people are overbuilding infrastructure in some twisted vision of ‘devops,’ but systemd is actually pretty nice. Using systemd means I never have to write another init script or remember cron syntax again, which is a net positive.

            1. 8

              My experience with systemd is kinda “it does everything sysadmins want, in all the ways that make programmers cringe”. The problem really isn’t what it does: for managing services in a fairly sophisticated and centralized ways, it’s far nicer than init scripts. But just yesterday I was digging into the logging tools it provides with the intent of making various programs tie into them, and was left saying “sigh, this is so dumb. Yes a flexible and annotate-able log format is great, but a) it didn’t need to be quite so centralized, and b) making it binary is completely unnecessary. A set of JSON files in one folder per service, plus a tiny key-value database or such as an index, would have worked just fine.”

              1. 4

                A set of JSON files in one folder per service

                Or S-expressions, which can represent programs.

                Were it all in Lisp, it’d be more memory-safe, more elegant and cleaner!

                1. 6

                  Much as I like Lisp, there are reasons that most of the time full programming languages are not used for configuration files.

        2. 15

          This fellow seems to be defending the use of systemd; it gets the job done, he argues. But even he won’t defend the attitude of its creator. When anyone says “systemd” the first thing that comes to mind for most people is outrageous arguments, name-calling, and vitriol on both sides.

          I’m somewhat hopeful that if we’ve learned anything in the time since systemd gained wide adoption, it’s that we can’t continue to ignore bad behavior from project leads. Ignoring social factors because you think the technology is solid is not a good strategy. Even Linus has realized this now.

          1. 0

            We only should care about social attitudes when a project has no more technical issues to resolve. Until then, the technology should come first, always.

            1. 9

              Not only will there always be technical issues to resolve (meaning we will never get around to the social issues), but software artifacts are an embodiment of social attitudes the same way any other work of engineering is (which means that our technical choices still be influenced by social ones).

              SystemD is centralized and monolithic because its governance is centralized around a single BDFL. It follows a design that is as consistent as its creator’s vision is. It replaces several daemons, which are inconsistent and don’t talk to each other very well because they were created by people with different visions who didn’t talk to each other very much.

              In other words, a compiler project with five teams will produce a five pass compiler. News at 11.

              1. 6

                “which means that our technical choices still be influenced by social ones”

                One of favorite examples: assignment being := vs = (or just not = vs =). The original ones used = for equality with a different symbol for assignment. One guy tweaking a language for an important project had a personal preference to use = for assignment. When it took off, we’ve been having = vs == errors ever since. Many designs followed the = pattern just assuming it made engineering sense or would be familiar. Just a social choice with long-term effects.

                1. 2

                  Exactly. We will always have technical issues to resolve, and never get to social issues. We work with technology. Social issues are not relevant in technical forums. To use an extreme example, I will watch movies starring Kevin Spacey despite his personal checkered past, since I watch movies to be entertained, not for some meta purpose.

                  Technical choices grow from our social understanding, but those choices can not be judged by that social understanding any more than software written by a black man, white man, Muslim, Jew, or Christian can be judged on the merits of the author’s beliefs or culture.

                  SystemD provides a case study in how organizational groups effect the software produced, surprising nobody and shedding no light on the technical merits or problems with the monolithic approach. Argue why SystemD should be done differently or the same way, don’t stop your examination with the team that built it.

                  1. 2

                    surprising nobody and shedding no light on the technical merits or problems with the monolithic approach.

                    But shedding light on the technical merit of a monolithic organization. Because there is a technical output, it is relevant to technical forums.

                    If a reader here see this and starts to ponder how they want to structure their next project community, because it will have an impact on the kind of technical architecture that will naturally grow out of it, then the discussion was a productive one on a technical forum.

                2. 4

                  I wish we could do this. Unfortunately, technology is there for humans to use, to try to serve human goals, so completely decoupling the two is not feasible.

                  On a more practical level, if I’m reporting an obvious mistake in a piece of vital infrastructure that I’m being paid to deal with, and offer to put my time into fixing it if someone who knows what they’re doing can give me a big of guidance, I really don’t want to get told “working as intended” and have to spend hours arguing otherwise.

                  1. 1

                    Would you have any qualms about using reiserfs?

                    1. 3

                      It’s practically unmaintained as I understand it, so yes, I’d have qualms about trusting it with my data.

                      1. 2

                        Though it didn’t say it explicitly, it seems pretty obvious to me that the question wasn’t about trusting it with your data, it was about the author being convicted of first-degree murder of his wife. Even if the filesystem were maintained, would that not give you pause before using it?

                        1. 3

                          I understood the point. No, even though the author has definitely killed his wife, the software is not necessarily bad.

                3. 13

                  Benno Rice is a FreeBSD core committer and openly speaks about why FreeBSD would be better off adopting a service like systemd: https://www.youtube.com/watch?v=6AeWu1fZ7bY

                  Definitely not what I was expecting. Which ironically would be my part in feeding the tragedy that is the systemd story.

                  1. 7

                    Adopting the idea behind systemd is good, take SMF (svcs) on Solaris/Illumos for example, its very good.

                    But adopting systemd is very bad idea.

                  2. 20

                    I actually don’t mind systemd, but the community around it just seems awful.

                    The way in which this article ridicules anyone who had/has a problem with systemd or the way in which it was adopted (“oh, they didn’t like systemd – how traaagic”) is just as contemptful as anything I saw from the anti-systemd crowd a few years back.

                    Based on the amount of childish and immature behavior I saw on both sides of this ugly debate, I don’t think anyone has a moral leg to stand on, here.

                    1. 1

                      Which is why we must stand only on technical legs

                    2. 14

                      I just liked the change of not having to write specifically crafted & commented bash scripts to specify a pretty simple daemon which just has 4 requirements. The same goes for checking of PID files & automatically restarting. Also the Interface works pretty well.

                      I don’t think I can blame Lennart for getting a thicker skin over the time of systemds development. The community seems to be pretty draining when you hit certain problems. Lennart starting to react in less polite ways is sad but understandable. Also I don’t see why one always has to measure systemd by its creator. If anything I’m watching from distance and hope that it turns out for the best, but I’d much rather stick with systemd than going back to bash-scripts for everything. And last but not least: If systemd is so bad, why did major distributions choose to switch? I should trust the distribution I run along with its decisions.

                      1. 5

                        And last but not least: If systemd is so bad, why did major distributions choose to switch?

                        One of the first ones to move was Arch Linux. Here’s a brilliant reddit comment from the primary init script maintaner of Arch Linux around the time of the change: https://www.reddit.com/r/archlinux/comments/4lzxs3/why_did_archlinux_embrace_systemd/d3rhxlc/

                        IMHO, some bot should perhaps paste this to every systemd discussion in the world.

                        Given that a proper, maintained, better system exists, relying on sh scripts for service initialization is something I would never go back to.

                      2. 18

                        I still don’t get it. I’ve actively avoided systemd for years now, because it is the most tightly coupled, bloated piece of software that solves none of my issues.

                        Really, who needs a convoluted init system, with that much dependency management? My desktop machine doesn’t, my OpenBSD web server works fine with a shell script, and complicated cloud deployments are done with Kubernetes anyway.

                        I’ve had systemd hang in various weird ways over time (reminds me of the opaque pain of Windows boot/shutdown). It regularly loses track of PIDs for daemon processes. Configuration of services is unclear and opaque. Journalctl is assanine. There have been a plethora of CVEs due to poor code (which may have been mitigated by a simpler design and proper process isolation).

                        Systemd is absolutely not following the Unix philosophy. DBus doesn’t either. The entire idea behind Unix utils is that they’re loosely coupled, and play nice with any new or old utilities. I can run cat (a utility implemented in the 70s) with a modern util like fzf with no problems.

                        Meanwhile, systemd devs can’t figure out how to deaminize a process without killing it on logout, and, instead of fixing the problem on their end, asked everyone else to start using their API instead. (https://github.com/tmux/tmux/issues/428). That’s like breaking CI and asking someone else to fix it for you.

                        It’s gotten so much adoption that I assume everyone must love it. It just seems like complicated solution that fails to solve a simple problem to me.

                        I’ll be happily using my systemd-less distros like devuan and Void Linux. OpenRC is significantly more elegant and easy to maintain.

                        1. 7

                          I’d like to see articles like this compare systemd to one of the good competitors (like runit). I can’t help but feel suspicious of articles that compare systemd only to older init systems.

                          I would love to see one of the big journal sites (such as LWN) do an article comparing modern alternatives.

                          1. 20

                            systemd is not a tragedy because there are people that oppose it! Quite the opposite. If anything, systemd is a tragedy because its proponents so ruthlessly denigrated any opposition as naysaying and social signalling.

                            The very prevalent idea that systemd can only be compared with what it replaced and not modern alternatives is another of the major issues I have with its community. systemd is frequently defended on the basis that it’s better than sysvinit in ways X, Y and Z which is better for use case A, B and C. This ignores that systemd is not competing with sysvinit, but with openrc and other modern alternatives.

                            This sort of contempt certainly plays into this story, where large groups identify themselves primarily by their disdain for systemd and those who work with it.

                            There’s much more disdain in the other direction. systemd’s developers have no respect for those working on alternatives, of which there are many. They put no effort at all into designing for interoperability or separating functionality into separate modules that can be swapped out with alternative implementations.

                            This is something other operating systems figured out a while back. Windows NT had a strong service model from the beginning, he said, and Mac OS has one now in the form of launchd. Other systems had to play a catch-up game to get there.

                            ‘Windows and OS X do this’ is quite the opposite of an argument for doing it. Windows and Mac have famously confusing and arcane service models, and unsurprisingly exactly the same thing is now true of systemd: it’s horribly complicated.


                            systemd is bloated crapware, both as a project overall, as a project to create an init system, and as a system process. It’s unreliable and full of security holes.

                            There are good arguments for retaining it, like ‘it’s less effort to improve systemd than to replace it’.

                            There are bad arguments for retaining it, like ‘you are just emotionally invested in disdain for systemd’.

                            Less of the latter and more of the former please.

                            1. 9

                              The whole systemd battle, Rice said, comes down to a lot of disruptive change; that is where the tragedy comes in. Nerds have a complicated relationship to change; it’s awesome when we are the ones creating the change, but it’s untrustworthy when it comes from outside. Systemd represents that sort of externally imposed change that people find threatening. That is true even when the change isn’t coming from developers like Poettering, who has shown little sympathy toward the people who have to deal with this change that has been imposed on them. That leads to knee-jerk reactions, but people need to step back and think about what they are doing. “Nobody needs to send Lennart Poettering death threats over a piece of software”. Contempt is not cool.

                              So, everyone’s talking about the technical merits of systemd but I think this is actually one of the more interesting bits of the write-up.

                              When I read people’s commentary on systemd, my first blush reaction is always “This just isn’t rational.”.

                              Sure, people can make some good points, but I think you can learn a lot about people’s reactions to things by looking at the adjectives they use. “Bloated” “Crap” “Buggy” “Complicated” “awful” etc.

                              Now, I don’t happen to enjoy some of the changes systemd has brought. I’m an old school UNIX guy and I miss being able to tail -f /var/log/messages to be sure, BUT I recognize that change is inevitable, and that if we want UNIX to continue to be a viable operating system choice it must continue to evolve.

                              Whether or not you feel that systemd is the correct next step in that evolution is up for debate, but nothing lasts forever.

                              1. 14

                                Now, I don’t happen to enjoy some of the changes systemd has brought. I’m an old school UNIX guy and I miss being able to tail -f /var/log/messages to be sure, BUT I recognize that change is inevitable, and that if we want UNIX to continue to be a viable operating system choice it must continue to evolve.

                                But – is this a positive evolution? What, in practical terms, was the ability to tail -f /var/log/messages actually holding back?

                                These kinds of claims seem to presuppose that all change is an evolutionary good in-and-of-itself. Sometimes, frequently even, change can be a step backwards.

                                1. 4

                                  That’s a valid question, and a very hard one to answer. Technology is both tool and craft, right?

                                  As a tool, I can tell you that SystemV init feels good in my hand. I could craft /etc/rc.d scripts in my sleep. Does that make SysV init superior to systemd?

                                  One of the accusations I see leveled at systemd is that it’s a solution without a problem, and that’s totally valid. Determining whether or not systemd is positive or negative evolution strikes me as a difficult problem and I suspect the answer will vary from person to person and use case to use case.

                                  1. 4

                                    This reddit thread linked by https://lobste.rs/s/hwsvmc/systemd_as_tragedy#c_zxl9it up the thread contains some of the problems that systemd was designed to be the solution for.

                                  2. 3

                                    Here is what Poettering wrote:

                                    Why doesn’t the journal generate traditional log files?

                                    Well, for starters, traditional log files are not indexed, and many key operations very slow with a complexity of O(n). The native journal file format allows O(log(n)) complexity or better for all important operations. For more reasons, refer to the sections above.

                                    Why do you guys reinvent the wheel, again? Why not just add what you need to existing syslog? If you just clean up your log formatting, syslog should be fine!

                                    Well, sometimes improving an existing solution is the way to go, but when the changes necessary are too major a reinvention is a good thing, if it is done for the right reasons, and provides good compatibility with previous solutions. We believe we are doing it for the right reasons, and we try hard to provide greatest possible compatibility.

                                    And no, just fixing the log formatting won’t get you much. Not even the most basic requirements like binary blobs or sensible structured logging. Let alone stuff like indexing or proper access control.

                                    1. 5

                                      Is there a list of important operations on log files?

                                      1. 4

                                        Yeah, and he also wrote:

                                        Finally, you are actually wrong in believing that systemd was an abomination.

                                        1. 6

                                          Well, for starters, traditional log files are not indexed, and many key operations very slow with a complexity of O(n)

                                          Very slow, huh? [1]

                                          I have never heard of anyone complaining that plaintext logs took too long to search. grep has always been fast enough for any problem I’ve ever seen or heard of. You’d have to have hundreds of GBs of logs (or a very slow platter disk).

                                          The only situation I can imagine a situation involving hundreds of GBs of logs is in a distributed system. And at that point, it probably is worth using something like ELK or Splunk to do log aggregation…

                                          It’s yet example of a “problem” that no one has that systemd attempts to solve. And the solution is quite poor, in my opinion.

                                          [1] I also hate when devs grandstand with Big-O notation. Yes, it’s useful in some cases as a high-level comparison of various algorithms. But performance of any real world application is improved by instrumentation and benchmarking. Not thinking really hard.

                                          1. 2

                                            Fwiw, I would much rather have Systemd and perhaps some helper do the log aggregation for me if that meant that we could burn all the world’s ELK stacks with fire.

                                        2. 3

                                          I basically do the tail -f /var/log/messages both at home and at work (I’m a developer). I have a system set up to get a live feed of syslog output, which is also color coded (warnings are yellow, debug messages blue, errors red, etc). and typically have a terminal set aside for this view. Most of my work is writing server software, so when debugging, I can see its output during testing.

                                          I can see problems that happen in real time. It’s also interesting to see how Mac OS-X is closing down over time (WARNING! THIS EXECUTABLE YOU WROTE IS UNSIGNED! WARNING! WARNING!). And there’s an attempt to ssh into my box. And I just noticed that my UPS monitoring software is down.

                                          Granted, I’m only monitoring a few servers, not hundreds of them. But I find it fun to just watch the logs flow by (oh look, com.apple.CDScheduler is spewing debug messages again).

                                        3. 5

                                          People realize that journalctl can replicate the tail follow behavior as well, right? Honestly journald is basically my favorite systemd feature.

                                          1. 3

                                            I suspect a huge amount of the grar over systemd could have been avoided if the systemd developers had written up a short cheat sheet with all the common use cases for the tools systemd replaced shown as systemd commands to smooth over that initial “argh! why has everything changed for no reason!” response.

                                            tail -f /var/log/syslog => journalctl -f
                                            etc etc
                                            

                                            (Maybe there was one & I just never saw it?)

                                        4. 5

                                          My homeserver died recently and I had to set it up anew. Before I use Ubuntu, but this time I tried Alpine. It has this lean and mean vibe. Indeed the RAM use is better now. I do miss Ubuntu though and one big aspect is Systemd.

                                          1. 5

                                            I’ve actually spent a lot of time thinking about what’s good about systemd’s design and what’s not, and what makes it more usable and what seems like a mistake. For example, I really enjoy the declarative config file format, and the ability to override vendor-provided services in /etc is really nice (and made possible by the declarative nature of unit files). Likewise I find systemctl quite usable; I particularly like systemctl status which shows me all at once a) whether a unit’s enabled, b) the unit’s active state (started/stopped/failed/etc.), c) why the unit has failed, if indeed it has, and d) recent stdout and stderr output. It’s super nice to be able to just say “show me a summary of this service’s state” and get it immediately.

                                            That being said, systemd’s all-encompassing design makes me very uncomfortable. Lennart says systemd being monolithic is a myth, but he says that it’s not monolithic because it’s split up into different binaries. I don’t really buy that argument. As many people have pointed out (some on this page) generally speaking it is extremely difficult to swap one of those pieces out and replace it with something that works differently, without basically reimplementing what was there before.

                                            I feel like a good way to solve this would be basically to stop hard-coding unit types. One of the problems with systemd is that PID 1 ends up being extremely large due to handling services, mounts, sockets, logins(?), etc. all at once. What if all that stuff was taken out of PID 1 and outsourced to different daemons? All that would be left in PID 1 was the dependency resolution. “a.service needs b.mount, and I need to bring up a.service” would result in talking to a different daemon handling mounts and a different daemon handling services (or possibly the service-handling daemon would even report back what a.service’s dependencies were). That’s it. And the whole thing would be decoupled and have a formal API such that you could even make up your own unit types and hook them into PID 1, so you could express “a.service depends on c.foobar” and it would work fine, because the foobar unit daemon would know how to bring up c.foobar.

                                            Don’t like systemd’s notion of targets? Replace it with a daemon that tells PID 1 about .runlevel units. Think timers are implemented poorly? Replace it with a lightly-modified cron. Notice that in this design it’s assumed that most things will take systemd’s config file format (perhaps the final config after overrides are applied, etc. is passed to the relevant unit handling daemon?), but the unit handling daemon is free to ignore that and use something else if it wants.

                                            I dunno. I’m sure there are lots of issues with this that I haven’t thought of, and it’s definitely just a strawman that I haven’t thought all the way through. It also doesn’t solve every problem people have with systemd. But it seems interesting, at least to me, and it makes it so that you don’t have to patch systemd every time you don’t like something about it. PID 1 does one thing and does it well: dependency ordering.

                                            (I’ve been meaning to write a blog post on this for a while; if anyone’s interested in a more detailed and thought-out writeup of these ideas, I can prioritize it higher.)

                                            1. 7

                                              one of those is that it violates the Unix philosophy. This argument, he said, seems to be predicated on the notion that systemd is a single, monolithic binary.

                                              Somehow, I had the impression that the primary unix-philosophy-violation in systemd was the heavy use of binary configs & binary logs (as opposed to human-readable textual configs & logs) – a tendency that makes one think of the Windows registry. Has this issue been resolved? Am I misremembering? Or, has the argument been basically misrepresented here?

                                              1. 4

                                                Yes the binary IO argument is made by systemd critics and does make historical sense in terms of a real or imagined “UNIX philosophy” (as well as concerns about system robustness). See the quote from Poettering elsewhere on this page for how not to answer that criticism. It has not been resolved, but logging has advanced despite systemd’s attempts to take ownership of it and so to a degree systemd’s logs are just damage that modern system administration tools have routed around.

                                                The “monolithic binary” argument is a misrepresentation that systemd advocates use to misrepresent actual criticsms of systemd’s structure and its consequences.Systemd’s different elements (the names of which are unimportant here) are tightly coupled, buggy, and wrongly opinionated about minor matters like the POSIX standard. The harm is not done by a single ginormous binary blob though.

                                                1. 0

                                                  Rice addresses this later in the presentation.

                                                  My own view is that systemd’s logs are perfectly human-readable – you just have to use journalctl instead of, say, less.

                                                  1. 11

                                                    journalctl is a single implementation & thus a single point of failure. Part of the reason why plain text formats are preferred in unix is that if your copy of less gets corrupted, you can instead use more, or tail, or cut, or reimplement bits of less in awk or in shell using read. There’s a huge amount of independent stuff in any unix system that needs to break in order for a text-based format to become unviewable or uneditable. Meanwhile, if you’ve got a proprietary binary format (particularly if it keeps changing periodically), any user who’s stuck without the officially vetted tool (say, because a dependency broke or something) has to reverse-engineer the format to read it.

                                                    1. 1

                                                      You can have both, though. Nothing’s stopping you from also running a syslog daemon to export logs to a text format while keeping the indexable and structured journal around for when you want to dig through logs in a more involved way.

                                                      1. 4

                                                        Sure, but the unixy way to do this would privilege the text format & have the binary format be an optional secondary processed form.

                                                        (I’m not saying that one is more technically sensible than the other – only that unix tends to privilege human-readable text streams with line- and whitespace-based formats, ideal for processing with standard unix tools like awk & sed, & so a binary-first attitude comes off as ignorance of or a rejection of unix norms.)

                                                        1. 3

                                                          Poettering wrote about “10. Myth: systemd is not UNIX”:

                                                          Ultimately, UNIX is something different for everybody. For us systemd maintainers it is something we derive inspiration from. For others it is a religion, and much like the other world religions there are different readings and understandings of it. Some define UNIX based on specific pieces of code heritage, others see it just as a set of ideas, others as a set of commands or APIs, and even others as a definition of behaviours. Of course, it is impossible to ever make all these people happy.

                                                          Ultimately the question whether something is UNIX or not matters very little. Being technically excellent is hardly exclusive to UNIX. For us, UNIX is a major influence (heck, the biggest one), but we also have other influences. Hence in some areas systemd will be very UNIXy, and in others a little bit less.

                                                          1. 6

                                                            Sure. I’m not making the normative argument that ‘all things should be unixy because unixy is technically superior’.

                                                            You can minimize social friction with your user base by making your software violate as few of that base’s expectations & norms as possible – which, when making a unix component, means behaving in ways that sysadmins are used to dealing with & being amenable to their usual means of investigation.

                                                            I get the impression that minimizing social friction is not one of Poettering’s priorities. It therefore shouldn’t be surprising that there’s an awful lot of it. It could be easily avoided, & systemd doesn’t.

                                                            1. 2

                                                              You can minimize social friction with your user base by making your software violate as few of that base’s expectations & norms as possible

                                                              Wait, what do you mean “your userbase?” Pottering works for Red Hat. They sell to the kind of enterprises that are often fine with stuff like this. Red Hat and IBM, now same company, were huge contributors to the kernel, too. If anything, they should continue to focus on their users doing it their way while others outdo them in both design and kernel contributions. We’re not seeing both happen since most folks griping about Systemd aren’t the kind whose ideas generate funds and developer time for the kernel enough to counter it.

                                                              1. 3

                                                                The folks griping about systemd are sysadmins who are displeased that their bag of tricks for dealing with sysvinit problems won’t work when systemd presents those same problems. I’d consider that group to be the userbase (as opposed to, say, an average ubuntu user – who doesn’t know they’re running systemd because they’ve never had to interact with it).

                                                                I’d be extremely surprised if the elements being complained about have any deep entanglement with the elements that make Red Hat, Canonical, & others prefer systemd to its competitors. It could be made more conventional in the ways sysadmins care about while remaining wildly unconventional in whatever internal ways Poettering cares about.

                                                                Of course, a big point of contention is that these sysadmins feel locked into it. There isn’t an easy way to opt out of systemd without losing support for important things that have decided to integrate into it.

                                                                (A similar thing happened with pulse: I got stuck using pulse long before it was really reliable enough for daily use, because my web browser & other applications decided to drop alsa support. This caused me endless problems for the subsequent ~5 years until pulse got to a level of stability where I didn’t need to wrestle with it. I can’t blame anybody for having the same kind of rage against systemd that I had against pulseaudio.)

                                                                This feeling of lock-in can be assuaged by… not locking people in (i.e., by keeping the project experimental for as long as possible & dissuading people from making their projects target it until it’s really stable), but it can also be assuaged by sticking to conventions when they make sense – so that switching away requires less work, and the scale of change seems less extreme.

                                                                1. 1

                                                                  You made good points about technical and design aspects. That’s not what I’m talking about, though. I’ll start with the point of divergence:

                                                                  I’d consider that group to be the userbase

                                                                  Companies work for who pays them. If the sysadmins do, then it would be as you said. They’d be worried about losing massive amounts of money. They’d kill systemd in favor of alternatives those sysadmins were pushing. They’re not doing that.

                                                                  Makes me think that people who aren’t the sysadmins are buying the product, talking to their important people at conference, and so on. They work for whoever those people are. As big companies, they also do whatever their internal management believes is good. Those bosses apparently aren’t listening to sysadmins that much.

                                                                  So, I still think their intended users are their customers which aren’t the people griping about systemd. It’s a market reality vs what the people in the field think. Following OP, a market tragedy.

                                                                  1. 2

                                                                    Yeah, I don’t think the users are paying the bills. (This is one of these situations where open source can make things worse: when decision-makers & developers have extremely little contact with or influence from the majority of users.)

                                                            2. 5

                                                              Yes that’s a good example of the ignorant and dismissive attitude that systemd is burdened with. It’s not an answer to the claim that it objects to, and adds nothing of substance to the debate.

                                                              1. 5

                                                                Yes that’s a good example of the ignorant and dismissive attitude that systemd is burdened with.

                                                                It’s also an example of the dismissive attitude the inventors of UNIX had when they were designing a system that worked better for them for their use cases. They threw out significant parts of MULTICS and BCPL philosophy to adapt concepts in them to their own circumstances and needs. They didn’t give a damn about existing philosophy. Like in that quote, it at some point becomes a religion where people are obsessive about preserving prior style, terms, and philosophy. Ironically, opposite UNIX’s own inventors.

                                                                1. 4

                                                                  I don’t think the source of the friction is that people think UNIX is the second coming, but that people expect UNIX components to work in a particular way & are frustrated when they are forced by distro maintainers to use something that works very differently.

                                                                  In other words, systemd working the way it did wouldn’t be a problem if it didn’t also become widespread extremely quickly by what a lot of folks felt was fiat. Likewise, systemd’s nigh-universality wouldn’t be a problem if it behaved more similarly to other systems (even if shallowly).

                                                                  It’s only when people feel like they are being forced to accept sudden changes by outside forces that they bristle. (Nobody begrudges the existence of APL, but if you told a bunch of javascript devs that they needed to work exclusively in APL from now on they wouldn’t be happy.)

                                                                  1. 2

                                                                    There’s a lot of truth to what you’re saying. That’s different than conformance to a philosophy or UNIX one specifically. I’m saying there’s been less and less of that over time. Plus, even UNIX’s inventors were against such conformance. They supported radical change for personal utility. If anything, what came after UNIX is more like what they did than extensions to UNIX.

                                                                    1. 2

                                                                      Absolutely. The folks who criticize systemd for being insufficiently unixy would not, generally speaking, move to plan9 either (despite plan9 being the natural progression of unix’s philosophical ideas toward purity). Their complaint is a practical one: they were experts on the old system, and the new one has them on the back foot.

                                                                      1. 3

                                                                        “ they were experts on the old system, and the new one has them on the back foot.”

                                                                        This is probably true for a lot of them. Then, there are people who are willing to change if the new thing has the right attributes. A subset of them are concerned with its complexity for reliability and security reasons. They say smaller components are better in such a critical process. I’m with them even though I’m not an admin, follower of UNIX philosophy, or anything like that. I just combat complexity reflexively for same reasons.

                                                                        It’s actually amusing from a high-assurance, security view. Many people say it’s a critical component that should be as tiny as possible with other functionality in deprivileged processes. Some are saying UNIX way is to make each process good at doing one thing, which shouldn’t be in systemd. Yet, they still aren’t hitting the logical conclusion of that kind of thinking which is microkernel architecture. It does that with everything or at least most critical if doing performance tradeoffs. Some are self-healing, too. Support VM’s or containers easily. Give them a few more decades to slowly reinvent the concept within traditional monoliths with less benefits of one and same problems of the other. ;)

                                                          2. 0

                                                            Now you have two problems.

                                                    2. 3

                                                      First as tragedy, then as SystemD.

                                                      1. 0

                                                        I gave it a shot back when I was on Arch. Didn’t like it, I just didn’t get it. Many things didn’t made sense. 2018. was the year I got my home server back on Gentoo, and I have to say I love OpenRC. I just don’t see myself coming back to anything on Systemd.