10 ms·

Why Did ArchLinux Embrace Systemd? (2016)

105 points by kbumsik 7y ago

bflesch 7y ago
I wish this kind of opinion would've been spread more widely within the Arch universe (wiki / IRC) so outsiders can understand what we actually gained from switching to systemd. It still feels like many people hate systemd but the reasons that are presented all sound totally valid from a programmers' perspective.
- aidenn0 7y ago
  These reasons are valid; I think the main reason so many people hate systemd is how all-encompasing it has become. Prior to systemd, the lack of a standard init/rc/service monitoring system meant that you could pick and choose 3 different solutions for those 3 problems. systemd is pushing for unifying not just those 3, but other systems too (gummiboot, consolekit, udev). As more software becomes designed to work just with the systemd ecosystem, more people who have love for one of the systems that has been subsumed will feel forced to switch. Say you have a favorite fork. You eat lunch with it everyday. Now at your favorite restaurant for takeout, the manager says "We switched salad dressings, and the new dressing line isn't compatible with that fork, you'll need to use this one instead." The fork that the manager hands you may be perfectly fine (better in some ways, worse in others than your favorite fork), but it's not your fork. So you sadly stop going to that restaurant. But then you notice something: more and more restaurants are switching salad dressing suppliers, so now you have to either give up your favorite fork, or use only salads you make yourself. You're probably going to be mad at the salad dressing company.
  - cwyers 7y ago
    Yeah, it's two sides talking past each other, with very different conceptions of what Linux should be. The systemd detractors tend to view Linux as sort of a grab bag where you can make a nigh infinite number of operating systems, all loosely compatible with each other. The systemd people view that as way too much stuff to test and support.
  - deleted 7y ago
    [deleted]
KingMachiavelli 7y ago
> What most systemd critics consider "bloat", I consider necessary complexity to solve a complex problem generically. As a distro and philosophy, Archlinux was bound to adopt systemd eventually. e.g. Maintaining you're own init system/scripts is not KISS. Creating a custom init file to adapt 90% of software from systemd to another init system is not KISS.
- deleted 7y ago
  [deleted]
- deleted 7y ago
  [deleted]
- m45t3r 7y ago
  Yeah. Most people misunderstand Arch's KISS principle. If you look for most decisions Arch took in the last years, most of them were focused in simplifying the distro and reducing the maintainer burden. So things like removing the TUI installer (does someone remember it?) and migrating to systemd. Even the fact that Arch ships with most packages with few or no changes compared to upstream is focused on it: reduce the burder on maintainer.
- djsumdog 7y ago
  Gentoo, Alpine and Void still default to using their own init systems.
  - MuffinFlavored 7y ago
    It seems Alpine uses Gentoo's OpenRC init system from a quick Google. https://wiki.alpinelinux.org/wiki/Alpine_Linux_Init_System https://wiki.alpinelinux.org/wiki/Alpine_Linux_Init_System https://wiki.gentoo.org/wiki/OpenRC https://wiki.gentoo.org/wiki/OpenRC
  - sterlind 7y ago
    Alpine has to use OpenRC rather than systemd because it's designed to run in containers. Using cgroups or lxc requires running your container with elevated privileges. This doesn't only affect systemd, it also makes it impossible for me to run Nix builds in unprivileged containers with isolation enabled, since isolation requires cgroups.
Mathnerd314 7y ago
(2016)
darkwater 7y ago
Looking back, I still don't get all the hatred that SystemD got (and sometimes is still getting). A part from some nice-to-have missing niche features (I'm looking at you, retries management with one-shots), it Just Works™ for the vast majority of use cases, just like PulseAudio does. The fact is that the minority which indeed have problems is very vocal because those problems come from complex corner-cases that only a a very tech-savvy user could generate in the first place.
- thayne 7y ago
  I think ultimately a lot of the systemd hate is just fear of change and not wanting to give up an init system they are famiiliar with.
  - yarrel 7y ago
    If we're not afraid of change, Let's change away from systemd.
    - lykr0n 7y ago
      To what?
      - msbarnett 7y ago
        RunIt, say.
        Zancarius 7y ago
        I suspect the OP is referencing Void Linux[1] which makes use of runit as its init system. If not, it's the first thing that came to mind. I'm not sure it's necessarily a better solution as it requires more manual interaction out of the box (namely creating symlinks by hand among other duties), but that might be argued as a feature. There appears to be a wrapper or two out there to automate away some of the tedium. [1] https://voidlinux.org/ https://voidlinux.org/
      - 7y ago
oauea 7y ago
Meanwhile http://without-systemd.org/ http://without-systemd.org/ (linked from the post) throws database errors. Maybe they forgot to 'enable' their mysql systemd service?
- cipherboy 7y ago
  I don't think so. It has been a while since I've done PHP but that reads like an inclue-gone-missing (likely with MySQL connection configuration information) causing the database to fail rather than MySQL breaking the include.
peterwwillis 7y ago
From the thread, 2brainz, the person maintaining the init scripts, responding to why systemd: >> I haven't heard a good explanation of why systemd and not a different, new init system > There is none. Systemd came along, we thought it was great, some of us were already involved with systemd and pushed the change. We could have done many different things, but we didn't. > Runit was suggested by users at some point, and I think there is/was a runit implementation in AUR. However, runit was never considered in detail. > First, we don't know if the other systems were really alternatives (at least I don't know). The answer is boring: Systemd solved many problems, it was there, it worked and we already used many of its tools in our initscripts at the time. There is no specific reason why we did not use $WHATEVER over systemd. > About launchd: it was never considered. As I said elsewhere, systemd seemed to do what we want and we went with it.
djsumdog 7y ago
After listening to the BSD Canada talk on systemd and BSD, I agree Linux does benefit from a system layer. But I still hate the implementation, and you can't easily swap out stuff. I really like logrotate and syslog and not needing journalctl for stdout/err logs from services. It's one of the things that makes working with Docker containers so much nicer too, because you have sane commands to get logs for services; way easier than remember all the weird switches for journalctl. I like NetworkManager (this still hasn't been replaced in systemd, right?) I still use OpenRC and Runit on Gentoo/Void respectively. OpenRC does dependency management but runit not so much. When it comes to building out VMs and stuff, I see the use of systemd for mount targets, but like I said earlier, I really hate the implementation in target files. It's so hard to make drop-in replacements for systemd that can run the same target files because of just how far it goes into the system. For VMs at this point, I honestly prefer minimal startup and running everything in Docker. Alpine or RancherOS seem to fit this bill nicely. If FreeBSD had a current Docker API implementation, it would be perfect. For my desktop, I prefer OpenRC or runit. It's just easier to do things and I'm not fighting with the system layer like I am in Windows. Then again I use i3 and prefer to have more control over my hardware, so that's just my use case I suppose.
- kbumsik 7y ago
  > After listening to the BSD Canada talk on systemd and BSD For someone who don't know, here is the video "The tragedy of systemd". This is a really good talk. https://youtu.be/6AeWu1fZ7bY https://youtu.be/6AeWu1fZ7bY
  - dijit 7y ago
    All respect to the author of that talk.. but "just get over it" and "embrace change" is not compelling to those who have very searing issues with systemd. I do not consider this to be a good talk because it paints dissenters as "not embracing change" because.. they are stupid? It also makes the argument that the only thing that exists outside of systemd is sysvinit. He also seeks to make Lennart a martyr because of death threats. (which, btw, seriously it shouldn't even be said that that is unacceptable, some people are fucked up). Oh, and systemd definitely didn't invent cgroups, an engineer at google did and they don't even use systemd to run GCP compute hypervisors. Benno so thoroughly misrepresents those that have issues with systemd that I can't help but feel it was intentional.
dijit 7y ago
Ah, I'm going to lose karma here because I'm a sysadmin and not a programmer and programmers seem to really like systemd, and this forum is represented strongly by programmers. Regardless, every time these types of threads come about I feel like I _have_ to speak because there's a lot of bitterly divided people regarding this issue. (or, rather the people who are bitterly opposed and the people who don't care, think systemd is a net good in the vast majority of cases or those who think the backlash is very much unwarranted). I'd like to say first off: SystemD solves real problems that nothing before it was solving, maybe it doesn't solve those issues in the way I personally like, but it definitely does and was one of the first to do so- so for this reason the original maintainers should be warranted respect, it's also a given that it's not the developers fault that this is so widely adopted or even forced. I see them as problem solvers first and foremost so any gripes I have with systemd as a thing which is foisted upon me is definitely not on them. However, I do consider that systemd as a new -layer- between user land and kernel space (called "system space" by Poettering) necessitates a lot of breaking changes. I do not consider this by itself as a bad thing, but having a poorly defined interface for these things does not enable systemd to be replaced without some form of "systemd-esque" emulation in future. Thus while we have improved from where we were, we do not have fertile ground to improve in the future. Additionally; SystemD as a "modular" system is, in my opinion, a myth; even if you take for granted the fact that systemd+journald are the only core dependencies, you then quickly start to drag in more and more rapidly (udev and systemd-resolved being famous examples). Some design paradigms are scary, for instance socket activation leaves PID1 listening for traffic on the network, by default bound to all interfaces. (a good example is to look at cockpit) this could be a very large footgun if there exists any form of exploit in systemd.. and since systemd is not written in a memory safe language, and the overwhelming majority of security bugs are memory safety bugs... this is mildly concerning. There are other concerns regarding opacity of the dependency system, the fact that no-two-boots are the same and thus some race conditions are likely to never be solved by me. (a lowly sysadmin type who only knows enough C to make linked lists). The design very much reminds me of Microsoft Windows in many ways, but perhaps that was a good design to choose from? FWIW: SystemD is amazing on my laptop, I am really happy with it. But for my servers I am very unhappy with it, but the major distributions chose to use systemd and I'm a sysadmin so I'm beholden to what the company considers stable and developers. I very much begrudge the fact that I'm not allowed to have a dissenting opinion on this. I also hate that when people talk about systemd vs "anything", invariably people assume I am talking about openRC or sysvinit, but there are much better init systems available today, such as Runit. SystemD is not a panacea, it should leave fertile ground for replacement. If that cannot be done it should not be adopted because that is a scary amount of lock-in.
axaxs 7y ago
I don't particularly care for Systemd, just out of principle, but I don't mind using it. Personally, I feel Arch Linux went downhill after Judd left. Maybe I'm naive, but I absolutely loved Arch's 'rc.conf', which was basically an entire system config in one file. That going away, and the adoption of Systemd, really made it feel like a different distro. Not better or worse, mind you, just different.
- DenseComet 7y ago
  Take a look at NixOS, the entire OS is declarativily defined and can be stored in git.
valeg 7y ago
I prefer this approach: >Systemd is included by default but not enabled. You can scan your MX system and discover files bearing "systemd" names, but those simply provide a compatibility hook/entrypoint when needed. >MX Linux uses systemd-shim, which emulates the systemd functions that are required to run the helpers without actually using the init service. This means that SvsVinit remains the default init yet MX Linux can use Debian packages that have systemd dependencies such as CUPS. This approach also allows the user to retain the ability to choose his/her preferred init. Source: https://mxlinux.org/about-us/ https://mxlinux.org/about-us/
- znpy 7y ago
  > MX Linux is a cooperative venture between the antiX and former MEPIS communities Ah! SimplyMEPIS (a live version of MEPIS) was the first gnu/linux system I booted on my (dad's) P3 desktop computer in circa 2003-2004!
megous 7y ago
I agree with an event driven supervisor daemon architecture, and that shell scripts are inefficient. But writing everything in C in non-scriptable way may be a bit of over-reaction to the old ways of having everything scripted in the least efficient way possible. I also write my init systems in C (not for generic Linux distro, mostly for embedded HW/mobile use), but I'm planning to make it so that I have a program in C that offers some primitives and the core logic will be implemented using an embedded JS engine, so that it's scriptable and fixable without re-compilation.
bitwize 7y ago
Ah, systemd. It's one of those things where I'm glad it exists, but I hate it. I'm glad it exists because more open source is good, and diversity of implementations is good. I hate it because it complicates my machine's startup process, and my life, unnecessarily, and puts a lot of shit in pid 1 that shouldn't be there. I don't want it to become a hard dependency of my entire software stack. (Same with PulseAudio, hence why I am not currently a Firefox user.) I left Arch after the systemd transition and didn't look back, but I wish Arch devs and users well.
- mos_basik 7y ago
  As someone who's been slowly picking their way along the narrow crooked path towards free software / tinfoilhattery / unixbeardedness for the past several years, I'm interested to know which browser you use. I assume given context that Safari and IE are right out. Chromium and variants are probably out? If Firefox and variants are out (not sure if all of them have the pulse dependency, because honestly your comment was the first time I learned about it - probably because I'm using Arch), what's left? Qutebrowser? Konqueror? I guess implicit in the above is an assumption of certain (non-basic) functionality that many people would consider table stakes in a web browser. Given that choosing to use any software involves making certain compromises (like "if you don't use Chrome, some Google applications will likely not perform as well") I guess my underlying desire is to know which compromises you are willing to make, given that you aren't willing to compromise your desire to keep pulseaudio off your machine in order to be able to use Firefox. On a scale I'm having trouble naming but that goes from about 1 ("my son bought me this iPad so I can see my grandchildren on Facebook") to 10 ("I wget webpages to my server then email them to my Trisquel laptop") your pulse/firefox constraint seems to me to be solidly in the upper half, which I respect, but which also makes me expect you are willing to accept compromises that I'm not (yet) in choosing a browser. Maybe I'm wrong, though, because there's a lot of browsers on this chart: https://upload.wikimedia.org/wikipedia/commons/thumb/7/74/Timeline_of_web_browsers.svg/3560px-Timeline_of_web_browsers.svg.png https://upload.wikimedia.org/wikipedia/commons/thumb/7/74/Ti...
  - bitwize 7y ago
    Currently? PaleMoon. It doesn't have a Pulse dependency and it works with every site I throw at it. We'll see if that holds up.
combatentropy 7y ago
I would like to know what Arch Linux and the other distros thought of alternatives like runit, openrc, and BSD-style init. I can at least sympathize with the arguments for systemd if the only other choice was SysV init scripts. As Richard Gooch once said, "These boot scripts, in the tradition of SysV, can do anything. They are flexible. They are scalable. They can run industrial-strength systems. Unfortunately, they're bloated and ugly. OK, maybe they're not ugly to everyone (not that I've ever heard anyone admit they're elegant, only 'it works'), but they sure are bloated. They are complex and hard to navigate." (http://www.safe-mbox.com/~rgooch/linux/boot-scripts/ http://www.safe-mbox.com/~rgooch/linux/boot-scripts/) But the choice was never just between SysV init or systemd. Couldn't Linux have done something like FreeBSD's rc? Or I read about the daemontools family of init systems, like runit, which is what Void Linux uses. These systems sound like they solved SysV's problems without adding systemd's. That is, they are more declarative, easier to maintain, can handle complex dependencies, and can run things in parallel. But they remained unixy: they are small, file-oriented, and don't swallow up adjacent software.
ddevault 7y ago
I think very few people criticise systemd for its init system, which is pretty decent as far as init systems go. The main complaint is everything else systemd does. It's trying to swallow the universe and there seems to be no limits to where its "scope" will end.
upofadown 7y ago
This is a very good point. The reason that you have trouble if you just use a bunch of scripts to start up a contemporary Linux is that the underlying system has become quite complex. Now you have to deal with the effects of stuff like udev and dbus. Systemd can be seen as an attempt to paper over the underlying complexity problem with another layer on top. That of course if not likely to work but is depressingly common in the world of OSs. People add things to a simple system until it is no longer a simple system. Eventually it becomes unreliable enough that no one dares extend it further. As a nice counterexample, OpenBSD doesn't have stuff like udev or dbus usage during boot. The rc.d system they use is literally just a bunch of scripts and is dead simple and reliable.

105 points by kbumsik 7y ago

I wish this kind of opinion would've been spread more widely within the Arch universe (wiki / IRC) so outsiders can understand what we actually gained from switching to systemd. It still feels like many people hate systemd but the reasons that are presented all sound totally valid from a programmers' perspective.

aidenn0 7y ago
These reasons are valid; I think the main reason so many people hate systemd is how all-encompasing it has become. Prior to systemd, the lack of a standard init/rc/service monitoring system meant that you could pick and choose 3 different solutions for those 3 problems. systemd is pushing for unifying not just those 3, but other systems too (gummiboot, consolekit, udev). As more software becomes designed to work just with the systemd ecosystem, more people who have love for one of the systems that has been subsumed will feel forced to switch. Say you have a favorite fork. You eat lunch with it everyday. Now at your favorite restaurant for takeout, the manager says "We switched salad dressings, and the new dressing line isn't compatible with that fork, you'll need to use this one instead." The fork that the manager hands you may be perfectly fine (better in some ways, worse in others than your favorite fork), but it's not your fork. So you sadly stop going to that restaurant. But then you notice something: more and more restaurants are switching salad dressing suppliers, so now you have to either give up your favorite fork, or use only salads you make yourself. You're probably going to be mad at the salad dressing company.
- cwyers 7y ago
  Yeah, it's two sides talking past each other, with very different conceptions of what Linux should be. The systemd detractors tend to view Linux as sort of a grab bag where you can make a nigh infinite number of operating systems, all loosely compatible with each other. The systemd people view that as way too much stuff to test and support.
- deleted 7y ago
  [deleted]

KingMachiavelli 7y ago

> What most systemd critics consider "bloat", I consider necessary complexity to solve a complex problem generically. As a distro and philosophy, Archlinux was bound to adopt systemd eventually. e.g. Maintaining you're own init system/scripts is not KISS. Creating a custom init file to adapt 90% of software from systemd to another init system is not KISS.

deleted 7y ago
[deleted]
deleted 7y ago
[deleted]
m45t3r 7y ago
Yeah. Most people misunderstand Arch's KISS principle. If you look for most decisions Arch took in the last years, most of them were focused in simplifying the distro and reducing the maintainer burden. So things like removing the TUI installer (does someone remember it?) and migrating to systemd. Even the fact that Arch ships with most packages with few or no changes compared to upstream is focused on it: reduce the burder on maintainer.
djsumdog 7y ago
Gentoo, Alpine and Void still default to using their own init systems.
- MuffinFlavored 7y ago
  It seems Alpine uses Gentoo's OpenRC init system from a quick Google. https://wiki.alpinelinux.org/wiki/Alpine_Linux_Init_System https://wiki.alpinelinux.org/wiki/Alpine_Linux_Init_System https://wiki.gentoo.org/wiki/OpenRC https://wiki.gentoo.org/wiki/OpenRC
- sterlind 7y ago
  Alpine has to use OpenRC rather than systemd because it's designed to run in containers. Using cgroups or lxc requires running your container with elevated privileges. This doesn't only affect systemd, it also makes it impossible for me to run Nix builds in unprivileged containers with isolation enabled, since isolation requires cgroups.

Mathnerd314 7y ago

(2016)

darkwater 7y ago

Looking back, I still don't get all the hatred that SystemD got (and sometimes is still getting). A part from some nice-to-have missing niche features (I'm looking at you, retries management with one-shots), it Just Works™ for the vast majority of use cases, just like PulseAudio does. The fact is that the minority which indeed have problems is very vocal because those problems come from complex corner-cases that only a a very tech-savvy user could generate in the first place.

thayne 7y ago
I think ultimately a lot of the systemd hate is just fear of change and not wanting to give up an init system they are famiiliar with.
- yarrel 7y ago
  If we're not afraid of change, Let's change away from systemd.
  - lykr0n 7y ago
    To what?
    - msbarnett 7y ago
      RunIt, say.
      - Zancarius 7y ago
        I suspect the OP is referencing Void Linux[1] which makes use of runit as its init system. If not, it's the first thing that came to mind. I'm not sure it's necessarily a better solution as it requires more manual interaction out of the box (namely creating symlinks by hand among other duties), but that might be argued as a feature. There appears to be a wrapper or two out there to automate away some of the tedium. [1] https://voidlinux.org/ https://voidlinux.org/
    - 7y ago

oauea 7y ago

Meanwhile http://without-systemd.org/ http://without-systemd.org/ (linked from the post) throws database errors. Maybe they forgot to 'enable' their mysql systemd service?

cipherboy 7y ago
I don't think so. It has been a while since I've done PHP but that reads like an inclue-gone-missing (likely with MySQL connection configuration information) causing the database to fail rather than MySQL breaking the include.

peterwwillis 7y ago

From the thread, 2brainz, the person maintaining the init scripts, responding to why systemd: >> I haven't heard a good explanation of why systemd and not a different, new init system > There is none. Systemd came along, we thought it was great, some of us were already involved with systemd and pushed the change. We could have done many different things, but we didn't. > Runit was suggested by users at some point, and I think there is/was a runit implementation in AUR. However, runit was never considered in detail. > First, we don't know if the other systems were really alternatives (at least I don't know). The answer is boring: Systemd solved many problems, it was there, it worked and we already used many of its tools in our initscripts at the time. There is no specific reason why we did not use $WHATEVER over systemd. > About launchd: it was never considered. As I said elsewhere, systemd seemed to do what we want and we went with it.

djsumdog 7y ago

After listening to the BSD Canada talk on systemd and BSD, I agree Linux does benefit from a system layer. But I still hate the implementation, and you can't easily swap out stuff. I really like logrotate and syslog and not needing journalctl for stdout/err logs from services. It's one of the things that makes working with Docker containers so much nicer too, because you have sane commands to get logs for services; way easier than remember all the weird switches for journalctl. I like NetworkManager (this still hasn't been replaced in systemd, right?) I still use OpenRC and Runit on Gentoo/Void respectively. OpenRC does dependency management but runit not so much. When it comes to building out VMs and stuff, I see the use of systemd for mount targets, but like I said earlier, I really hate the implementation in target files. It's so hard to make drop-in replacements for systemd that can run the same target files because of just how far it goes into the system. For VMs at this point, I honestly prefer minimal startup and running everything in Docker. Alpine or RancherOS seem to fit this bill nicely. If FreeBSD had a current Docker API implementation, it would be perfect. For my desktop, I prefer OpenRC or runit. It's just easier to do things and I'm not fighting with the system layer like I am in Windows. Then again I use i3 and prefer to have more control over my hardware, so that's just my use case I suppose.

kbumsik 7y ago
> After listening to the BSD Canada talk on systemd and BSD For someone who don't know, here is the video "The tragedy of systemd". This is a really good talk. https://youtu.be/6AeWu1fZ7bY https://youtu.be/6AeWu1fZ7bY
- dijit 7y ago
  All respect to the author of that talk.. but "just get over it" and "embrace change" is not compelling to those who have very searing issues with systemd. I do not consider this to be a good talk because it paints dissenters as "not embracing change" because.. they are stupid? It also makes the argument that the only thing that exists outside of systemd is sysvinit. He also seeks to make Lennart a martyr because of death threats. (which, btw, seriously it shouldn't even be said that that is unacceptable, some people are fucked up). Oh, and systemd definitely didn't invent cgroups, an engineer at google did and they don't even use systemd to run GCP compute hypervisors. Benno so thoroughly misrepresents those that have issues with systemd that I can't help but feel it was intentional.

dijit 7y ago

Ah, I'm going to lose karma here because I'm a sysadmin and not a programmer and programmers seem to really like systemd, and this forum is represented strongly by programmers. Regardless, every time these types of threads come about I feel like I _have_ to speak because there's a lot of bitterly divided people regarding this issue. (or, rather the people who are bitterly opposed and the people who don't care, think systemd is a net good in the vast majority of cases or those who think the backlash is very much unwarranted). I'd like to say first off: SystemD solves real problems that nothing before it was solving, maybe it doesn't solve those issues in the way I personally like, but it definitely does and was one of the first to do so- so for this reason the original maintainers should be warranted respect, it's also a given that it's not the developers fault that this is so widely adopted or even forced. I see them as problem solvers first and foremost so any gripes I have with systemd as a thing which is foisted upon me is definitely not on them. However, I do consider that systemd as a new -layer- between user land and kernel space (called "system space" by Poettering) necessitates a lot of breaking changes. I do not consider this by itself as a bad thing, but having a poorly defined interface for these things does not enable systemd to be replaced without some form of "systemd-esque" emulation in future. Thus while we have improved from where we were, we do not have fertile ground to improve in the future. Additionally; SystemD as a "modular" system is, in my opinion, a myth; even if you take for granted the fact that systemd+journald are the only core dependencies, you then quickly start to drag in more and more rapidly (udev and systemd-resolved being famous examples). Some design paradigms are scary, for instance socket activation leaves PID1 listening for traffic on the network, by default bound to all interfaces. (a good example is to look at cockpit) this could be a very large footgun if there exists any form of exploit in systemd.. and since systemd is not written in a memory safe language, and the overwhelming majority of security bugs are memory safety bugs... this is mildly concerning. There are other concerns regarding opacity of the dependency system, the fact that no-two-boots are the same and thus some race conditions are likely to never be solved by me. (a lowly sysadmin type who only knows enough C to make linked lists). The design very much reminds me of Microsoft Windows in many ways, but perhaps that was a good design to choose from? FWIW: SystemD is amazing on my laptop, I am really happy with it. But for my servers I am very unhappy with it, but the major distributions chose to use systemd and I'm a sysadmin so I'm beholden to what the company considers stable and developers. I very much begrudge the fact that I'm not allowed to have a dissenting opinion on this. I also hate that when people talk about systemd vs "anything", invariably people assume I am talking about openRC or sysvinit, but there are much better init systems available today, such as Runit. SystemD is not a panacea, it should leave fertile ground for replacement. If that cannot be done it should not be adopted because that is a scary amount of lock-in.

axaxs 7y ago

I don't particularly care for Systemd, just out of principle, but I don't mind using it. Personally, I feel Arch Linux went downhill after Judd left. Maybe I'm naive, but I absolutely loved Arch's 'rc.conf', which was basically an entire system config in one file. That going away, and the adoption of Systemd, really made it feel like a different distro. Not better or worse, mind you, just different.

DenseComet 7y ago
Take a look at NixOS, the entire OS is declarativily defined and can be stored in git.

valeg 7y ago

I prefer this approach: >Systemd is included by default but not enabled. You can scan your MX system and discover files bearing "systemd" names, but those simply provide a compatibility hook/entrypoint when needed. >MX Linux uses systemd-shim, which emulates the systemd functions that are required to run the helpers without actually using the init service. This means that SvsVinit remains the default init yet MX Linux can use Debian packages that have systemd dependencies such as CUPS. This approach also allows the user to retain the ability to choose his/her preferred init. Source: https://mxlinux.org/about-us/ https://mxlinux.org/about-us/

znpy 7y ago
> MX Linux is a cooperative venture between the antiX and former MEPIS communities Ah! SimplyMEPIS (a live version of MEPIS) was the first gnu/linux system I booted on my (dad's) P3 desktop computer in circa 2003-2004!

megous 7y ago

I agree with an event driven supervisor daemon architecture, and that shell scripts are inefficient. But writing everything in C in non-scriptable way may be a bit of over-reaction to the old ways of having everything scripted in the least efficient way possible. I also write my init systems in C (not for generic Linux distro, mostly for embedded HW/mobile use), but I'm planning to make it so that I have a program in C that offers some primitives and the core logic will be implemented using an embedded JS engine, so that it's scriptable and fixable without re-compilation.

bitwize 7y ago

Ah, systemd. It's one of those things where I'm glad it exists, but I hate it. I'm glad it exists because more open source is good, and diversity of implementations is good. I hate it because it complicates my machine's startup process, and my life, unnecessarily, and puts a lot of shit in pid 1 that shouldn't be there. I don't want it to become a hard dependency of my entire software stack. (Same with PulseAudio, hence why I am not currently a Firefox user.) I left Arch after the systemd transition and didn't look back, but I wish Arch devs and users well.

mos_basik 7y ago
As someone who's been slowly picking their way along the narrow crooked path towards free software / tinfoilhattery / unixbeardedness for the past several years, I'm interested to know which browser you use. I assume given context that Safari and IE are right out. Chromium and variants are probably out? If Firefox and variants are out (not sure if all of them have the pulse dependency, because honestly your comment was the first time I learned about it - probably because I'm using Arch), what's left? Qutebrowser? Konqueror? I guess implicit in the above is an assumption of certain (non-basic) functionality that many people would consider table stakes in a web browser. Given that choosing to use any software involves making certain compromises (like "if you don't use Chrome, some Google applications will likely not perform as well") I guess my underlying desire is to know which compromises you are willing to make, given that you aren't willing to compromise your desire to keep pulseaudio off your machine in order to be able to use Firefox. On a scale I'm having trouble naming but that goes from about 1 ("my son bought me this iPad so I can see my grandchildren on Facebook") to 10 ("I wget webpages to my server then email them to my Trisquel laptop") your pulse/firefox constraint seems to me to be solidly in the upper half, which I respect, but which also makes me expect you are willing to accept compromises that I'm not (yet) in choosing a browser. Maybe I'm wrong, though, because there's a lot of browsers on this chart: https://upload.wikimedia.org/wikipedia/commons/thumb/7/74/Timeline_of_web_browsers.svg/3560px-Timeline_of_web_browsers.svg.png https://upload.wikimedia.org/wikipedia/commons/thumb/7/74/Ti...
- bitwize 7y ago
  Currently? PaleMoon. It doesn't have a Pulse dependency and it works with every site I throw at it. We'll see if that holds up.

combatentropy 7y ago

I would like to know what Arch Linux and the other distros thought of alternatives like runit, openrc, and BSD-style init. I can at least sympathize with the arguments for systemd if the only other choice was SysV init scripts. As Richard Gooch once said, "These boot scripts, in the tradition of SysV, can do anything. They are flexible. They are scalable. They can run industrial-strength systems. Unfortunately, they're bloated and ugly. OK, maybe they're not ugly to everyone (not that I've ever heard anyone admit they're elegant, only 'it works'), but they sure are bloated. They are complex and hard to navigate." (http://www.safe-mbox.com/~rgooch/linux/boot-scripts/ http://www.safe-mbox.com/~rgooch/linux/boot-scripts/) But the choice was never just between SysV init or systemd. Couldn't Linux have done something like FreeBSD's rc? Or I read about the daemontools family of init systems, like runit, which is what Void Linux uses. These systems sound like they solved SysV's problems without adding systemd's. That is, they are more declarative, easier to maintain, can handle complex dependencies, and can run things in parallel. But they remained unixy: they are small, file-oriented, and don't swallow up adjacent software.

ddevault 7y ago

I think very few people criticise systemd for its init system, which is pretty decent as far as init systems go. The main complaint is everything else systemd does. It's trying to swallow the universe and there seems to be no limits to where its "scope" will end.

upofadown 7y ago

This is a very good point. The reason that you have trouble if you just use a bunch of scripts to start up a contemporary Linux is that the underlying system has become quite complex. Now you have to deal with the effects of stuff like udev and dbus. Systemd can be seen as an attempt to paper over the underlying complexity problem with another layer on top. That of course if not likely to work but is depressingly common in the world of OSs. People add things to a simple system until it is no longer a simple system. Eventually it becomes unreliable enough that no one dares extend it further. As a nice counterexample, OpenBSD doesn't have stuff like udev or dbus usage during boot. The rc.d system they use is literally just a bunch of scripts and is dead simple and reliable.