14 ms·

When writing software, it’s comparatively easy to come up with grand new ideas and turn them into lines of code and files filled with modules. What’s much hard

When writing software, it’s comparatively easy to come up with grand new ideas and turn them into lines of code and files filled with modules. What’s much harder is (1) to expand ones code without coupling everything together (2) present it in a persuasive way that naturally builds a user base. SystemD feels like the new grad hire who decided the first thing the would do after joining — the opening power play — is to convince the PHB we should rewrite everything in Haskell. At this point the gentler folk start quietly honing their CVs and sneaking their personal belongings off their desks, one night at a time, in the hope no one notices they are all about to quit. It felt like Unix systems administration was a haven from this sort of politics — I don’t remember tmux, git, or python trying to push behavior changes on upstream components of the OS[1]. I’m sure it’s why Unix attracted a certain type of personality for so many years and I’m sad to see that changing. [1] If you are thinking “but those are command line utilities, whereas the init process is a much more specialized case” then I’d encourage you to revisit the Unix principles of every component being a small and simple program! Even init, cron, and login! It’s not some grand ideal to be zealously adhered to: it’s the principles of small components that mean the same OS can run on a quad core Xeon as runs on a $45 network switch.

theamk 7y ago
I think you underestimate how badly the old sysvinit sucked in the world with many good distribution-provided packages. It was pretty good in the good, old days, where a sysadmin could list every daemon the system runs by heart, but it was breaking apart when you had tons of random packages: Package X uses "start-stop-daemon" in ini file, so there is no way to get error messages if config file is incorrect. Package B has no disable switch, so you get to stick "exit" in /etc/default. Package C has this weird logging format which cannot be rotated daily, and is not integrated with anything. Package D likes to die and leave PID file around, and then it fails to restart because of that. Package E likes to bury its settings in /etc/init.d/ file, so there are conflicts every time it updates. User A likes to leave their executables on their machine after logout, so we need a cleanup script. This was seriously getting old -- after you apply a hack after hack, you start wanting something better. There were a few candidates -- upstart, daemontools/runit, systemd. Only two of them actually did the work to add backward compatibility and integrate with upstream. Upstart sucked even worse than systemd. This left only one candidate. Remember, even if you can claim for Fedora that someone "convinced the PHB", this does not apply to other distros. Debian, Ubuntu, Arch all chose the systemd voluntarily. This is because sysvinit sucks, and no one came up with a better option.
- AnthonyMouse 7y ago
  What you are missing is that it is possible for two things to be true at once. It is possible for sysvinit to suck and for systemd to suck in entirely different and potentially much worse ways. It's as though someone is complaining about having to live under the USSR and how bad things are, and then someone responds that the German rocket program has been dismantled and the British never really had much of one and the Americans are doing okay but the fact is that the USSR was the first to put a man into space. As if that justifies everything else they did.
  - cycloptic 7y ago
    Sysvinit is still around, you can always go back to it if you really want. The package is even still in debian.
    - AnthonyMouse 7y ago
      The problem is not that sysvinit doesn't exist, it's that other packages now have dependencies on systemd, so it doesn't just swap out.
      - cycloptic 7y ago
        I don't see how that is the problem. It's exactly what you asked for. If you're replacing a low-level component with something else that hasn't been updated in years and doesn't implement features that other packages do then yeah, you have to be prepared to accept that some newer things will break, and you'll have to revert a lot of other packages to older versions too. What else can we do? This isn't even a systemd-specific thing.
        AnthonyMouse 7y ago
        They didn't used to break if you wanted to switch from one init system to another. What you could do is to reduce unnecessary interdependencies. And where there is inherently interaction between separate packages, use a stable interface and publish the standard so that alternative implementations can replace a single package in a standard way without breaking several others.
jiggawatts 7y ago
> rewrite everything in Haskell. Yes please! Pure functional languages are very well suited to declarative configuration, especially where you need significant flexibility not afforded by purely static "data" formats such as YAML or JSON.
ChuckMcM 7y ago
The other component here is "where you came from." When I joined Sun there were two very distinct programmer/hacker cultures; the PC and its spawn and "real" computers (mini and mainframe computers) and their OSes. The cultures were very different, I straddled them with my hobby working being CP/M->PC->Amiga, and my professional work being RSX-11M->TENEX->TOPS20->UNIX. Linux (and Minix) started out very much being a PC version of UNIX and PC-BSD jumped in there too. But Linus ceded userland to the community and as the community's membership has grown the people who wanted Linux to be the perfect UNIX lost out to the people who wanted Linux to be an open source version of Microsoft Windows. It appeared to me that the folks who liked UNIX semantics fled to MacOS, although the complaints on that front are getting louder as well. So here we are.
anewvillager 7y ago
Why do systemd detractors keep styling it as SystemD? I'm honestly curious. You know it's written all lowercase, right?
- aerique 7y ago
  Basically to annoy you. Yes, it's childish but also very satisfying. Do you want us to even give that up now that we're stuck with SystemD?
  - sjwright 7y ago
    You seem to be under the misapprehension that anyone remotely cares. Childish tantrums are counter-productive as they almost entirely blowback onto your own psychological state rather than affecting anyone else's. You are permanently stuck with the contents of your brain; everyone else has a quick chuckle at the troll and continues scrolling past. Clearly you are immensely frustrated. I suspect this stems from the fact that nearly everyone else either doesn't know and is unaffected, or prefers SyStEmD over sysvinit, or doesn't care one way or the other. For me the whole debate is hilarious because every single objection I've heard about sYsTeMd is one or more of the following: 1. Factually incorrect; 2. Resolved with a trivial config change; 3. Preference for the familiar; 4. Preference for theoretical principles over pragmatism; 5. The kernel is orders of magnitude worse ("but that's different").
    - rini17 7y ago
      6. Very reasonable systemd issues met with unreasonable hostility. There are plenty of linked examples in the article.
      - sjwright 7y ago
        Name one that doesn't fit any of my five categories.
        rini17 7y ago
BiteCode_dev 7y ago
> SystemD feels like the new grad hire who decided the first thing the would do after joining — the opening power play — is to convince the PHB we should rewrite everything in Haskell. I've seen this scenario played out, and it always fails. The product never ships, of ships in such a bad shape the users have a terrible user experience. That's not what happened with systemd. It shipped. And after a few iterations, it actually provided a better user experience. I don't know about sysadmins, but as a simple end user of Ubuntu, systemd is the best user experience I ever had for what matters to me: setuping my services. It's quite easy to create your unit files, declare service dependencies, stop, restart, and so on. It's declarative, conf is reasonably straighforward to read an understand, documentation is there, and my system boot is stable on laptop and on my servers. Maybe for "advanced case X", there is problem. Apparently, a lot of power users say there is. But I also know the FOSS community has some people advocating purity over practicality, don't care much about the people with less skills than them, don't understand user friendliness or will fight for their ego. So I have no way to be sure if the problem is real, or just another free software drama. But at this point I don't care: for the average Joe like me, it's great, and I'm very happy it has been chosen by Centos and Debian as the default. Apparently nobody in the entire history of init system have managed to provide something decent for, you know, initializing the system. I never heard a herd of devs claiming that one is the fantastic, and they were all terrible to use when I tried. Well, I don't care for choice in my init system. I want it to work. And systemd works fine for me.
- zapttt 7y ago
  > it shiped you completely missed the point of the comment and the article. yes, it shipped, completely broken. lots and lots of functionality was lost for a while (and some not deemed enterpise-worthy still are). what seems more correct for you in this car anaology: suppose - some cars have the turn signal on top left stalk - other cars have the wiper and healigth control on the top stalk. would you standardize them by: a) set a industry standard and wait for them to follow, with a period or brands permanently Opting out (let's say golf carts without turn signals) or b) force legislation from top down to immediately repurpose the top left stalk for turn signals via sopftware update, no matter if some companies will make the headlight control not work for years or keep the now-wrongly marked control permanently? systemd is option B. the same system did could easily have been done with a standards for init scritpts and opt-in. yet it was done with a top down idiotic decision that was self serving to some players.
AsyncAwait 7y ago
> SystemD I don't know why, but it bothers me when someone's trying to criticize systemd, without even bothering to get the case right. It smells of not having looked at it any more than to form the run of the mill opinion on systemd, while looking at what came before with healthy dose of romantic nostalgia. I don't want my init system to be a series of garage-quality bash scripts with slightly different error rate tolerances etc, systemd solves that. I don't want my system to just blindly shut down, even if it's not necessarily safe to do so immediately, systemd solves that. What systemd critics often miss is that it's also a rather valuable resource manager in general. I know that many would say this should not be part of systemd, but the thing is while that sounds nice, nobody built anything remotely as convenient for Linux as systemd in this area. It's nice to say what systemd got wrong, but I haven't seen anything actually built that can seriously compete with it. I now actively avoid distros without systemd, because the admin experience of those distros has generally been much less consistent. We can all talk about the right way to do things, but unless there's code that's clearly superior to what systemd offers me today, am not interested.

theamk 7y ago

I think you underestimate how badly the old sysvinit sucked in the world with many good distribution-provided packages. It was pretty good in the good, old days, where a sysadmin could list every daemon the system runs by heart, but it was breaking apart when you had tons of random packages: Package X uses "start-stop-daemon" in ini file, so there is no way to get error messages if config file is incorrect. Package B has no disable switch, so you get to stick "exit" in /etc/default. Package C has this weird logging format which cannot be rotated daily, and is not integrated with anything. Package D likes to die and leave PID file around, and then it fails to restart because of that. Package E likes to bury its settings in /etc/init.d/ file, so there are conflicts every time it updates. User A likes to leave their executables on their machine after logout, so we need a cleanup script. This was seriously getting old -- after you apply a hack after hack, you start wanting something better. There were a few candidates -- upstart, daemontools/runit, systemd. Only two of them actually did the work to add backward compatibility and integrate with upstream. Upstart sucked even worse than systemd. This left only one candidate. Remember, even if you can claim for Fedora that someone "convinced the PHB", this does not apply to other distros. Debian, Ubuntu, Arch all chose the systemd voluntarily. This is because sysvinit sucks, and no one came up with a better option.

AnthonyMouse 7y ago
What you are missing is that it is possible for two things to be true at once. It is possible for sysvinit to suck and for systemd to suck in entirely different and potentially much worse ways. It's as though someone is complaining about having to live under the USSR and how bad things are, and then someone responds that the German rocket program has been dismantled and the British never really had much of one and the Americans are doing okay but the fact is that the USSR was the first to put a man into space. As if that justifies everything else they did.
- cycloptic 7y ago
  Sysvinit is still around, you can always go back to it if you really want. The package is even still in debian.
  - AnthonyMouse 7y ago
    The problem is not that sysvinit doesn't exist, it's that other packages now have dependencies on systemd, so it doesn't just swap out.
    - cycloptic 7y ago
      I don't see how that is the problem. It's exactly what you asked for. If you're replacing a low-level component with something else that hasn't been updated in years and doesn't implement features that other packages do then yeah, you have to be prepared to accept that some newer things will break, and you'll have to revert a lot of other packages to older versions too. What else can we do? This isn't even a systemd-specific thing.
      - AnthonyMouse 7y ago
        They didn't used to break if you wanted to switch from one init system to another. What you could do is to reduce unnecessary interdependencies. And where there is inherently interaction between separate packages, use a stable interface and publish the standard so that alternative implementations can replace a single package in a standard way without breaking several others.

jiggawatts 7y ago

> rewrite everything in Haskell. Yes please! Pure functional languages are very well suited to declarative configuration, especially where you need significant flexibility not afforded by purely static "data" formats such as YAML or JSON.

ChuckMcM 7y ago

The other component here is "where you came from." When I joined Sun there were two very distinct programmer/hacker cultures; the PC and its spawn and "real" computers (mini and mainframe computers) and their OSes. The cultures were very different, I straddled them with my hobby working being CP/M->PC->Amiga, and my professional work being RSX-11M->TENEX->TOPS20->UNIX. Linux (and Minix) started out very much being a PC version of UNIX and PC-BSD jumped in there too. But Linus ceded userland to the community and as the community's membership has grown the people who wanted Linux to be the perfect UNIX lost out to the people who wanted Linux to be an open source version of Microsoft Windows. It appeared to me that the folks who liked UNIX semantics fled to MacOS, although the complaints on that front are getting louder as well. So here we are.

anewvillager 7y ago

Why do systemd detractors keep styling it as SystemD? I'm honestly curious. You know it's written all lowercase, right?

aerique 7y ago
Basically to annoy you. Yes, it's childish but also very satisfying. Do you want us to even give that up now that we're stuck with SystemD?
- sjwright 7y ago
  You seem to be under the misapprehension that anyone remotely cares. Childish tantrums are counter-productive as they almost entirely blowback onto your own psychological state rather than affecting anyone else's. You are permanently stuck with the contents of your brain; everyone else has a quick chuckle at the troll and continues scrolling past. Clearly you are immensely frustrated. I suspect this stems from the fact that nearly everyone else either doesn't know and is unaffected, or prefers SyStEmD over sysvinit, or doesn't care one way or the other. For me the whole debate is hilarious because every single objection I've heard about sYsTeMd is one or more of the following: 1. Factually incorrect; 2. Resolved with a trivial config change; 3. Preference for the familiar; 4. Preference for theoretical principles over pragmatism; 5. The kernel is orders of magnitude worse ("but that's different").
  - rini17 7y ago
    6. Very reasonable systemd issues met with unreasonable hostility. There are plenty of linked examples in the article.
    - sjwright 7y ago
      Name one that doesn't fit any of my five categories.
      - rini17 7y ago

BiteCode_dev 7y ago

> SystemD feels like the new grad hire who decided the first thing the would do after joining — the opening power play — is to convince the PHB we should rewrite everything in Haskell. I've seen this scenario played out, and it always fails. The product never ships, of ships in such a bad shape the users have a terrible user experience. That's not what happened with systemd. It shipped. And after a few iterations, it actually provided a better user experience. I don't know about sysadmins, but as a simple end user of Ubuntu, systemd is the best user experience I ever had for what matters to me: setuping my services. It's quite easy to create your unit files, declare service dependencies, stop, restart, and so on. It's declarative, conf is reasonably straighforward to read an understand, documentation is there, and my system boot is stable on laptop and on my servers. Maybe for "advanced case X", there is problem. Apparently, a lot of power users say there is. But I also know the FOSS community has some people advocating purity over practicality, don't care much about the people with less skills than them, don't understand user friendliness or will fight for their ego. So I have no way to be sure if the problem is real, or just another free software drama. But at this point I don't care: for the average Joe like me, it's great, and I'm very happy it has been chosen by Centos and Debian as the default. Apparently nobody in the entire history of init system have managed to provide something decent for, you know, initializing the system. I never heard a herd of devs claiming that one is the fantastic, and they were all terrible to use when I tried. Well, I don't care for choice in my init system. I want it to work. And systemd works fine for me.

zapttt 7y ago
> it shiped you completely missed the point of the comment and the article. yes, it shipped, completely broken. lots and lots of functionality was lost for a while (and some not deemed enterpise-worthy still are). what seems more correct for you in this car anaology: suppose - some cars have the turn signal on top left stalk - other cars have the wiper and healigth control on the top stalk. would you standardize them by: a) set a industry standard and wait for them to follow, with a period or brands permanently Opting out (let's say golf carts without turn signals) or b) force legislation from top down to immediately repurpose the top left stalk for turn signals via sopftware update, no matter if some companies will make the headlight control not work for years or keep the now-wrongly marked control permanently? systemd is option B. the same system did could easily have been done with a standards for init scritpts and opt-in. yet it was done with a top down idiotic decision that was self serving to some players.

AsyncAwait 7y ago

> SystemD I don't know why, but it bothers me when someone's trying to criticize systemd, without even bothering to get the case right. It smells of not having looked at it any more than to form the run of the mill opinion on systemd, while looking at what came before with healthy dose of romantic nostalgia. I don't want my init system to be a series of garage-quality bash scripts with slightly different error rate tolerances etc, systemd solves that. I don't want my system to just blindly shut down, even if it's not necessarily safe to do so immediately, systemd solves that. What systemd critics often miss is that it's also a rather valuable resource manager in general. I know that many would say this should not be part of systemd, but the thing is while that sounds nice, nobody built anything remotely as convenient for Linux as systemd in this area. It's nice to say what systemd got wrong, but I haven't seen anything actually built that can seriously compete with it. I now actively avoid distros without systemd, because the admin experience of those distros has generally been much less consistent. We can all talk about the right way to do things, but unless there's code that's clearly superior to what systemd offers me today, am not interested.