10 ms·

Show me an alternative to systemd that matches its functionality and consistency. The whole point is that systemd replaces a large number of solutions to vario

Show me an alternative to systemd that matches its functionality and consistency. The whole point is that systemd replaces a large number of solutions to various system components and there’s alot to be said for pulling all that together into a consistent solution. The competition to systemd can’t match its power, but there are good solutions for more limited scope situations like embedded. Systemd is incredibly powerful and is very much a welcome part of software that I build. My system architectures depend heavily on systemd. knowing what systemd is capable of is really required knowledge for software developers because it can both save you massive time and also enable the creation of systems that otherwise would have required you to write more code.

kresten 7y ago
Having said all that I’m not convinced about dbus but hey what software gets everything right?
nine_k 7y ago
Systemd is monolithic, and does a lot of things that one might want to do differently. It follows the footsteps of a similar macOS program, and apparently imports a bit of the general philosophy from Apple: one way to do all the things, dictated by the producer of it. It's much more than an init system; it obviates a number of other components. This may be a desired quality for some. "Linux monoculture" is a real thing, and systemd makes it seriously more monocultural. The fact that systemd did not have the highest reliability for years did not help its popularity. It was not entirely gently pushed on everyone by Red Hat, by making Gnome dependent on it. OTOH the history shows that technically poor, and even terrible, things can get wide enough adoption and stick with us for a long time; X is a good example, SysV init is another.
- mateuszf 7y ago
  > OTOH the history shows that technically poor, and even terrible, things can get wide enough adoption and stick with us for a long time; X is a good example, SysV init is another. Funnily Unix and C are also examples of "worse is better". https://www.jwz.org/doc/worse-is-better.html https://www.jwz.org/doc/worse-is-better.html
  - DoctorNick 7y ago
    More testicles mean more iron.
  - nitrogen 7y ago
    Clicking that link from HN will (usually?) give you something NSFW; jwz doesn't like HN, so copy/paste the link if you want to see the real link.
    - SturgeonsLaw 7y ago
      Didn't do it for me after multiple attempts :(
      - mike_d 7y ago
        You end up with a redirect to https://web.archive.org/web/20191014203443/https://www.jwz.org/images/2016/hn.png https://web.archive.org/web/20191014203443/https://www.jwz.o... (Mildly NSFW)
      - DyslexicAtheist 7y ago
        perhaps your browser strips the http referer header (with custom settings or done by some privacy extension)? https://wiki.mozilla.org/Security/Referrer https://wiki.mozilla.org/Security/Referrer
        uwydr 7y ago
        https://addons.mozilla.org/en-US/firefox/addon/smart-referer/?src=search https://addons.mozilla.org/en-US/firefox/addon/smart-referer...
    - pferde 7y ago
      Wait, you do not block HTTP referers by default? In this day and age where vast majority of websites are out to scoop any and all available information about you?
- sjwright 7y ago
  Given that systemd is just a set of interconnecting components, is it really fair to call it monolithic? While it does ship as a unified project, my understanding is that you can substitute individual parts of it easily enough.
  - freedomben 7y ago
    Exactly. Systemd is highly modular, and for the most part can work with a variety of different alternatives and interconnections. There a few hard dependencies but for the most part I don't think it's fair at all to call it monolithic.
    - flukus 7y ago
      If it's highly modular then why (according to TFA) are they struggling to incorporate a fork of a systemd subcomponent? If that's not easy to do then it's not modular.
      - geofft 7y ago
        As I understood the thread, the problem is not that it's hard to get elogind running, the problem is that getting applications to provide tested, supported non-systemd init scripts (or equivalent) requires a commitment from the packager and occasionally from the upstream community. This is an entirely unrelated question to modularity - the "problem" is that systemd supports certain features and if you want to run without systemd, some other component needs to support them. Such components could be designed pretty easily, sure, but people who are using those features are typically happy with systemd's implementation so there's little motivation to write them. In the article, systemd's tmpfilesd mechanism is given as an example. It's straightforward to reimplement as a standalone component, but someone has to actually be interested in writing the implementation and writing tests that it behaves like systemd does and keeping it up to date.
        flukus 7y ago
        What you just described is still very much what I'd call a monolith. Much like if you have a microservice architecure (that we had a system level prior to systemd) then each component should be testable, upgradeable and swappable in isolotation, if you don't have that then what you've really got is a distributed monolith (obligatory xkcd: https://sebiwi.github.io/comics/distributed-monolith/ https://sebiwi.github.io/comics/distributed-monolith/). What we have here is a dependency chain that pulls in all of systemd, therefor it isn't modular. It isn't modular just because it's divided into modules.
- lazyguy2 7y ago
  > Systemd is monolithic, It's monolythic in the same what that the GNU project or FreeBSD is monolithic. It's a large number of utilities, tools, and daemons that is designed to provide the low-level features application developers and users demand from a modern operating system. > It's much more than an init system; Systemd is a init system, but systemd is also a major project that has taken on the task of unifying low-level Linux OS features. > "Linux monoculture" is a real thing, and systemd makes it seriously more monocultural. FreeBSD is a monoculture. OS X is a monoculture. Solaris is a monoculture. OpenBSD is a monoculture. All these systems have their own init systems they designed with no regard towards Linux and replaced older systems and obsoleted them. > It was not entirely gently pushed on everyone by Red Hat, by making Gnome dependent on it. Lies and misrepresentations. > OTOH the history shows that technically poor, and even terrible, things can get wide enough adoption and stick with us for a long time; X is a good example, SysV init is another. Which is why people are working on replacing both X and SysV. You want to know the real problem with anything-but-systemd crowd? This: > Of course, this approach is not viable if it turns out that too few people are interested in init system diversity sufficiently to do the reasonably substantial implementation work required to maintain a competing implementation of the systemd unit features we care about. There is no 'If' there. Some people don't want systemd, but the only people doing the work are Systemd. So their choice is to stick with Linux from 2000's or use systemd. Because nobody wants to commit to making any alternative actually work. Making noise online is annoying, but it ultimately is not something that goes into the decision making of people designing operating systems. People willing to do the work are the ones that get to make the choices. If somebody comes along and makes a better init system then systemd then they can do it and if it is better it will get adopted. You can pretend that this is all Redhat's fault, but they are the only real enterprise that made the transition from sysv in Rhel 5, to upstart in 6, and then to systemd in 7. And, ironically with systemd, migrating to another different init system is massively simplified compared to the work it took to migrate from sysv init. So now moving to a new init system is easier then ever. Why do I say this? Because systemd has unified OS design for Linux in a way that never happened with sysv init. Sure people were using 'sysv' and all used shell scripts, but they were all fundamentally different from one another. Only the most complicated shell scripts imaginable (think Apache init) or the most trivial could be made to work on more then one Linux distribution. Meanwhile systemd uses a declarative configuration syntax that all you need to do is create a parser and you could effectively import any systemd application configuration into a system with equivalent or better capabilities in any operating system. The same can't be said for any of the bash scripts developed by any of the distributions prior to this for their own sysv variant.
- kissgyorgy 7y ago
  It is NOT monolithic at all. It is probably ignorance, but I never really understood why would people say this.
orhmeh09 7y ago
Could you recommend a good guide to systemd? I learned most of my knowledge of *nix systems on FreeBSD, and as systemd has taken over Linux I find a lot of my traditional knowledge is becoming outdated as years go by. I understand basic aspects of systemd but not programming with it or building systems with it.
- freedomben 7y ago
  First and best place to start is the original "Rethinking PID 1" from Lennart. That will give you a great background in the problem he sought to solve and his thought process: http://0pointer.de/blog/projects/systemd.html http://0pointer.de/blog/projects/systemd.html
simion314 7y ago
>Show me an alternative to systemd that matches its functionality and consistency. What I understand from this topic(about the ilogind) is that you can't even create such an alternative because the packages are depending hard on systemd. So you will be forced in future to re-create systemd features and bugs similar how wine does it for Windows API.
- sirn 7y ago
  Many packages that depends on systemd actually depends on the logind part. Most of time you could just s/systemd/elogind/ and it will work. However for a big systemd-based distro such as Debian, that means they need to provide support for _both_ systemd and elogind for all packages, which is not an easy task (elogind basically conflicts with systemd) and not worth doing without also committing to support other init systems.
wsc981 7y ago
How does Apple’s launchd [0] compare? It’s open source, but perhaps not yet ported to Linux-based operating systems. —— [0]: https://en.m.wikipedia.org/wiki/Launchd https://en.m.wikipedia.org/wiki/Launchd
- sjwright 7y ago
  Launchd is arguably the inspiration for systemd and other modern alternatives. Therefore it's very similar in scope and principle. But many parts of how it works, most notably the configuration file format, are distinctly Apple-isms (or more precisely NeXT-isms) so it probably wouldn't feel "native" to the Linux ecosystem without some substantial retooling of the code.
  - chungy 7y ago
    > many parts of how it works, most notably the configuration file format, are distinctly Apple-isms (or more precisely NeXT-isms) Basically every type of systemd configuration files are just INI files, which I seem to remember originating in MS-DOS...
    - TazeTSchnitzel 7y ago
      Well, it's also very dependent on running on Darwin.
      - saagarjha 7y ago
        Apparently it's been ported to some extent to run on FreeBSD: https://wiki.freebsd.org/launchd https://wiki.freebsd.org/launchd. I'd expect this job gets harder and harder with each passing year, as the last time Apple released source code for launchd was alongside OS X Mavericks.
    - sjwright 7y ago
      I'm not sure about systemd, but launchd uses a rather verbose yet generic xml schema that is used throughout macOS, iOS etc.
pvg 7y ago
A lot of the systemd criticism (whether right or wrong) makes the claim the design is wrong. You can't really address that by asking critics for a precisely equivalent/capable implementations of something they feel is fundamentally misdesigned.
- mateuszf 7y ago
  No, he's asking for something with the same features and consistency, it can be designed however you like.
  - beatgammit 7y ago
    The issue is that many believe that the feature set is the problem. Why do you need consistency across services that have little in common? The basic idea of an init system is pretty simple: start services in such a way that the system comes up reliably. There are two main approaches here, simple but inefficient or complex and more efficient. The FreeBSD/rsysv approach is the former, while the systemd/launchd approach is the latter. If I just want to make sure services start on boot in the right order, why not just have a script run it all? For 99% of use cases, it's good enough, so why complicate matters? I do appreciate systemd and the faster boots I get from it, but I still find myself longing for similar init systems.
evil-olive 7y ago
For a service manager, yes systemd is great. For a replacement for cron...sure, that's nice too. The benefit of being able to manually activate a timer in order to test it is completely worth it. For an NTP implementation? Eh. I'm not sure why that needs to be bundled in under the same umbrella as the service manager. It's also just an SNTP implementation, not full NTP, so it's notably feature-crippled relative to better options like chrony. Network management? Meh. Again, that strikes me as something that should be loosely coupled to the service manager. A UEFI implementation? gummiboot was assimilated and become systemd-boot. Was that necessary for technical reasons, or was it just moving a project under the systemd umbrella similar to how there's an umbrella of GNU projects? Container management? Another place where systemd-nspawn doesn't strike me as notably better than the alternatives. At a certain point "systemd" becomes a brand more than anything else, sort of like what IBM has been trying to do with Watson. Yes, it beat Ken Jennings at Jeopardy and that's great. That doesn't mean anything associated with the overall brand is automatically equally amazing.
- freedomben 7y ago
  Many of those things are not all or nothing. For example you can use chrony with systemd. RHEL 8 does that by default. You can even install rsyslog to consume logs if you want, and it works just fine. I agree systemd tries to do a lot (maybe too much) and often isn't better than alternatives, but I don't think that's a big deal since you can still use the alternatives quite easily.
  - newnewpdro 7y ago
    You can't replace journald with rsyslog. You can use rsyslog in addition to journald, but there's no way to get journald out of the picture - it's intertwined with the service manager.
    - freedomben 7y ago
      Yes, sorry if what I wrote was misleading. You can't replace journald with rsyslog, but the only complaints I hear about journald are that it's binary so you have to use journalctl to read them. By installing rsyslog you basically get the classic log behavior back. So technically under the hood you're still using journald, but you never have to know it.
jangid 7y ago
I built a RPi-Distro using pi-gen a couple of months back. I still have to figure out how to enable wifi using systemd. There are lots of pieces here and there. Earlier it was just one (config) file and one start/stop script.
- fsh 7y ago
  What does systemd have to do with your wifi? Handling that is the distro's job.
  - shakna 7y ago
    systemd-networkd handles network configuration. For WiFi, you still need WPA supplicant or similar, but you'll have those two things playing together.
    - bonzini 7y ago
      Just install ConnMan instead.
    - fsh 7y ago
      systemd-networkd is completely optional. In raspbian it is disabled by default and a very simple unit-file that calls ifup/ifdown is used. For wifi you obviously have to configure wpa-supplicant or use NetworkManager.
      - shakna 7y ago
        You asked what systemd had to do with WiFi. There are other options, but the parent wanted systemd.
  - rkangel 7y ago
    Systemd is part of the distro, as is the kernel and anything else you end up with on your machine after installation.
sirn 7y ago
> Show me an alternative to systemd that matches its functionality and consistency. As for init system, I would argue nosh[1] is a better init system. It’s based on daemontools design (same as s6, runit, etc, where it’s just a process that monitors a service directory). nosh can even semi-automatically convert systemd unit files[2] to a run script (including socket activation and all). For everything else that is not part of the system initialization process (initialize/running/shutdown) I don’t think they need to be tie into PID 1. elogind aims to do this job of taking the logind part out of systemd into its own service, which I found to be a good way of living in systemd world without using systemd (e.g. GNOME works) but it requires a lot of commitment of patching everything to link against elogind instead of systemd (Void Linux/Artix Linux are doing a good job at this). [1]: https://jdebp.eu/Softwares/nosh/ https://jdebp.eu/Softwares/nosh/ [2]: https://jdebp.eu/Softwares/nosh/worked-example.html https://jdebp.eu/Softwares/nosh/worked-example.html
sprash 7y ago
> Show me an alternative to systemd that matches its functionality and consistency. I'm using runit on void for years now. It has no functionality besides being a service manager. Having more functionality is a non feature. > because it can both save you massive time It also can cost you massive time whenever it doesn't work. Then you have to dig yourself through an opaque mess caused by literally millions of lines of C code. I wouldn't trust it with any mission critical. The only usecase for systemd I can think of is grandmas laptop. Maybe that is the target audience for debian, who knows. It is certainly not me.
StreamBright 7y ago
Not sure which part of systemd you are talking about. Everything? The init replacement part? DNS? NTP? All?
eadmund 7y ago
> Show me an alternative to systemd that matches its functionality and consistency. My issues with systemd do not pertain to functionality and consistency: rather, they are issues of taste, style, competence, design and size. The basic ideas behind systemd are, frankly, great. The free desktop really really needs something like it. 100% behind the idea and the functionality. The consistency is pretty good too, I think. It would be taste if it were less consistently in bad taste and more consistently in good taste. Which brings us to taste. First, systemd is security-important system software written in C. Why? There is no good reason to write software in C in 2019. Use a safer language like Go or Common Lisp (both of which are performant enough). I don't know if Java or other JVM languages would work. Perl probably would, although ensuring that a Perl project produces sane code is … difficult. Also on the issue of taste: systemd incorporates Windows-style .INI files wholesale into Unix-like systems. The freedesktop.org folks were already doing this, but why encourage it? The world has at least two better text-based alternatives to .INI files: S-expressions and YAML. Even JSON would be better, even without comments. Also on the issue of taste: systemd just doesn't feel like Unix. In order to get anything done one has to hand-edit lots of little files rather than run a few commands. It's a bit like if you had to run a text editor on a directory to add a file, rather than just creating the file. I'd love to see some commands like mktimer, mkservice or somesuch. I am mostly over the binary logfile issue — after all, ultimately everything on a computer is stored in binary — but I do wish that the tools were a little saner. It's still a pain to figure out where error outputs and so forth are going. The manner in which systemd takes over the world is completely inexcusable. I fully expect to see systemd-browser within the next decade, no doubt with just a few hooks to prevent using Firefox or Chromium, and of course with a few security issues just to spice things up. I really wish that someone with good taste had managed to get the attention of and money from Red Hat in order to design a clean, intelligent, 21st-century init system.
- blt 7y ago
  not trying to nitpick your comment, but yaml has some serious drawbacks: https://www.arp242.net/yaml-config.html https://www.arp242.net/yaml-config.html
teknopaul 7y ago
Re:"Show me an alternative to systemd that matches its functionality and consistency." This misses the point about init diversity. Let me show you one that has _less_ fuctionality, and is thus more suited to LXC os containers.
kazinator 7y ago
Systemd doesn't replace a large number of solutions; it contains a large number of solutions. Also, in the article: > Others, including Triplett, said that not only do the developers of other init systems lack the desire to implement systemd features, but they argue that those features should not exist in the first place. Something with all the functionality of systemd is just another systemd, which some people don't want in any shape or form.
ryanmccullagh 7y ago
Systems is awesome because writing a service is as simple as writing a unit file. You don’t have to worry about daemonizing, you don’t have to worry about logging (use systemd syslog option).

kresten 7y ago

Having said all that I’m not convinced about dbus but hey what software gets everything right?

nine_k 7y ago

Systemd is monolithic, and does a lot of things that one might want to do differently. It follows the footsteps of a similar macOS program, and apparently imports a bit of the general philosophy from Apple: one way to do all the things, dictated by the producer of it. It's much more than an init system; it obviates a number of other components. This may be a desired quality for some. "Linux monoculture" is a real thing, and systemd makes it seriously more monocultural. The fact that systemd did not have the highest reliability for years did not help its popularity. It was not entirely gently pushed on everyone by Red Hat, by making Gnome dependent on it. OTOH the history shows that technically poor, and even terrible, things can get wide enough adoption and stick with us for a long time; X is a good example, SysV init is another.

mateuszf 7y ago
> OTOH the history shows that technically poor, and even terrible, things can get wide enough adoption and stick with us for a long time; X is a good example, SysV init is another. Funnily Unix and C are also examples of "worse is better". https://www.jwz.org/doc/worse-is-better.html https://www.jwz.org/doc/worse-is-better.html
- DoctorNick 7y ago
  More testicles mean more iron.
- nitrogen 7y ago
  Clicking that link from HN will (usually?) give you something NSFW; jwz doesn't like HN, so copy/paste the link if you want to see the real link.
  - SturgeonsLaw 7y ago
    Didn't do it for me after multiple attempts :(
    - mike_d 7y ago
      You end up with a redirect to https://web.archive.org/web/20191014203443/https://www.jwz.org/images/2016/hn.png https://web.archive.org/web/20191014203443/https://www.jwz.o... (Mildly NSFW)
    - DyslexicAtheist 7y ago
      perhaps your browser strips the http referer header (with custom settings or done by some privacy extension)? https://wiki.mozilla.org/Security/Referrer https://wiki.mozilla.org/Security/Referrer
      - uwydr 7y ago
        https://addons.mozilla.org/en-US/firefox/addon/smart-referer/?src=search https://addons.mozilla.org/en-US/firefox/addon/smart-referer...
  - pferde 7y ago
    Wait, you do not block HTTP referers by default? In this day and age where vast majority of websites are out to scoop any and all available information about you?
sjwright 7y ago
Given that systemd is just a set of interconnecting components, is it really fair to call it monolithic? While it does ship as a unified project, my understanding is that you can substitute individual parts of it easily enough.
- freedomben 7y ago
  Exactly. Systemd is highly modular, and for the most part can work with a variety of different alternatives and interconnections. There a few hard dependencies but for the most part I don't think it's fair at all to call it monolithic.
  - flukus 7y ago
    If it's highly modular then why (according to TFA) are they struggling to incorporate a fork of a systemd subcomponent? If that's not easy to do then it's not modular.
    - geofft 7y ago
      As I understood the thread, the problem is not that it's hard to get elogind running, the problem is that getting applications to provide tested, supported non-systemd init scripts (or equivalent) requires a commitment from the packager and occasionally from the upstream community. This is an entirely unrelated question to modularity - the "problem" is that systemd supports certain features and if you want to run without systemd, some other component needs to support them. Such components could be designed pretty easily, sure, but people who are using those features are typically happy with systemd's implementation so there's little motivation to write them. In the article, systemd's tmpfilesd mechanism is given as an example. It's straightforward to reimplement as a standalone component, but someone has to actually be interested in writing the implementation and writing tests that it behaves like systemd does and keeping it up to date.
      - flukus 7y ago
        What you just described is still very much what I'd call a monolith. Much like if you have a microservice architecure (that we had a system level prior to systemd) then each component should be testable, upgradeable and swappable in isolotation, if you don't have that then what you've really got is a distributed monolith (obligatory xkcd: https://sebiwi.github.io/comics/distributed-monolith/ https://sebiwi.github.io/comics/distributed-monolith/). What we have here is a dependency chain that pulls in all of systemd, therefor it isn't modular. It isn't modular just because it's divided into modules.
lazyguy2 7y ago
> Systemd is monolithic, It's monolythic in the same what that the GNU project or FreeBSD is monolithic. It's a large number of utilities, tools, and daemons that is designed to provide the low-level features application developers and users demand from a modern operating system. > It's much more than an init system; Systemd is a init system, but systemd is also a major project that has taken on the task of unifying low-level Linux OS features. > "Linux monoculture" is a real thing, and systemd makes it seriously more monocultural. FreeBSD is a monoculture. OS X is a monoculture. Solaris is a monoculture. OpenBSD is a monoculture. All these systems have their own init systems they designed with no regard towards Linux and replaced older systems and obsoleted them. > It was not entirely gently pushed on everyone by Red Hat, by making Gnome dependent on it. Lies and misrepresentations. > OTOH the history shows that technically poor, and even terrible, things can get wide enough adoption and stick with us for a long time; X is a good example, SysV init is another. Which is why people are working on replacing both X and SysV. You want to know the real problem with anything-but-systemd crowd? This: > Of course, this approach is not viable if it turns out that too few people are interested in init system diversity sufficiently to do the reasonably substantial implementation work required to maintain a competing implementation of the systemd unit features we care about. There is no 'If' there. Some people don't want systemd, but the only people doing the work are Systemd. So their choice is to stick with Linux from 2000's or use systemd. Because nobody wants to commit to making any alternative actually work. Making noise online is annoying, but it ultimately is not something that goes into the decision making of people designing operating systems. People willing to do the work are the ones that get to make the choices. If somebody comes along and makes a better init system then systemd then they can do it and if it is better it will get adopted. You can pretend that this is all Redhat's fault, but they are the only real enterprise that made the transition from sysv in Rhel 5, to upstart in 6, and then to systemd in 7. And, ironically with systemd, migrating to another different init system is massively simplified compared to the work it took to migrate from sysv init. So now moving to a new init system is easier then ever. Why do I say this? Because systemd has unified OS design for Linux in a way that never happened with sysv init. Sure people were using 'sysv' and all used shell scripts, but they were all fundamentally different from one another. Only the most complicated shell scripts imaginable (think Apache init) or the most trivial could be made to work on more then one Linux distribution. Meanwhile systemd uses a declarative configuration syntax that all you need to do is create a parser and you could effectively import any systemd application configuration into a system with equivalent or better capabilities in any operating system. The same can't be said for any of the bash scripts developed by any of the distributions prior to this for their own sysv variant.
kissgyorgy 7y ago
It is NOT monolithic at all. It is probably ignorance, but I never really understood why would people say this.

orhmeh09 7y ago

Could you recommend a good guide to systemd? I learned most of my knowledge of *nix systems on FreeBSD, and as systemd has taken over Linux I find a lot of my traditional knowledge is becoming outdated as years go by. I understand basic aspects of systemd but not programming with it or building systems with it.

freedomben 7y ago
First and best place to start is the original "Rethinking PID 1" from Lennart. That will give you a great background in the problem he sought to solve and his thought process: http://0pointer.de/blog/projects/systemd.html http://0pointer.de/blog/projects/systemd.html

simion314 7y ago

>Show me an alternative to systemd that matches its functionality and consistency. What I understand from this topic(about the ilogind) is that you can't even create such an alternative because the packages are depending hard on systemd. So you will be forced in future to re-create systemd features and bugs similar how wine does it for Windows API.

sirn 7y ago
Many packages that depends on systemd actually depends on the logind part. Most of time you could just s/systemd/elogind/ and it will work. However for a big systemd-based distro such as Debian, that means they need to provide support for _both_ systemd and elogind for all packages, which is not an easy task (elogind basically conflicts with systemd) and not worth doing without also committing to support other init systems.

wsc981 7y ago

How does Apple’s launchd [0] compare? It’s open source, but perhaps not yet ported to Linux-based operating systems. —— [0]: https://en.m.wikipedia.org/wiki/Launchd https://en.m.wikipedia.org/wiki/Launchd

sjwright 7y ago
Launchd is arguably the inspiration for systemd and other modern alternatives. Therefore it's very similar in scope and principle. But many parts of how it works, most notably the configuration file format, are distinctly Apple-isms (or more precisely NeXT-isms) so it probably wouldn't feel "native" to the Linux ecosystem without some substantial retooling of the code.
- chungy 7y ago
  > many parts of how it works, most notably the configuration file format, are distinctly Apple-isms (or more precisely NeXT-isms) Basically every type of systemd configuration files are just INI files, which I seem to remember originating in MS-DOS...
  - TazeTSchnitzel 7y ago
    Well, it's also very dependent on running on Darwin.
    - saagarjha 7y ago
      Apparently it's been ported to some extent to run on FreeBSD: https://wiki.freebsd.org/launchd https://wiki.freebsd.org/launchd. I'd expect this job gets harder and harder with each passing year, as the last time Apple released source code for launchd was alongside OS X Mavericks.
  - sjwright 7y ago
    I'm not sure about systemd, but launchd uses a rather verbose yet generic xml schema that is used throughout macOS, iOS etc.

pvg 7y ago

A lot of the systemd criticism (whether right or wrong) makes the claim the design is wrong. You can't really address that by asking critics for a precisely equivalent/capable implementations of something they feel is fundamentally misdesigned.

mateuszf 7y ago
No, he's asking for something with the same features and consistency, it can be designed however you like.
- beatgammit 7y ago
  The issue is that many believe that the feature set is the problem. Why do you need consistency across services that have little in common? The basic idea of an init system is pretty simple: start services in such a way that the system comes up reliably. There are two main approaches here, simple but inefficient or complex and more efficient. The FreeBSD/rsysv approach is the former, while the systemd/launchd approach is the latter. If I just want to make sure services start on boot in the right order, why not just have a script run it all? For 99% of use cases, it's good enough, so why complicate matters? I do appreciate systemd and the faster boots I get from it, but I still find myself longing for similar init systems.

evil-olive 7y ago

For a service manager, yes systemd is great. For a replacement for cron...sure, that's nice too. The benefit of being able to manually activate a timer in order to test it is completely worth it. For an NTP implementation? Eh. I'm not sure why that needs to be bundled in under the same umbrella as the service manager. It's also just an SNTP implementation, not full NTP, so it's notably feature-crippled relative to better options like chrony. Network management? Meh. Again, that strikes me as something that should be loosely coupled to the service manager. A UEFI implementation? gummiboot was assimilated and become systemd-boot. Was that necessary for technical reasons, or was it just moving a project under the systemd umbrella similar to how there's an umbrella of GNU projects? Container management? Another place where systemd-nspawn doesn't strike me as notably better than the alternatives. At a certain point "systemd" becomes a brand more than anything else, sort of like what IBM has been trying to do with Watson. Yes, it beat Ken Jennings at Jeopardy and that's great. That doesn't mean anything associated with the overall brand is automatically equally amazing.

freedomben 7y ago
Many of those things are not all or nothing. For example you can use chrony with systemd. RHEL 8 does that by default. You can even install rsyslog to consume logs if you want, and it works just fine. I agree systemd tries to do a lot (maybe too much) and often isn't better than alternatives, but I don't think that's a big deal since you can still use the alternatives quite easily.
- newnewpdro 7y ago
  You can't replace journald with rsyslog. You can use rsyslog in addition to journald, but there's no way to get journald out of the picture - it's intertwined with the service manager.
  - freedomben 7y ago
    Yes, sorry if what I wrote was misleading. You can't replace journald with rsyslog, but the only complaints I hear about journald are that it's binary so you have to use journalctl to read them. By installing rsyslog you basically get the classic log behavior back. So technically under the hood you're still using journald, but you never have to know it.

jangid 7y ago

I built a RPi-Distro using pi-gen a couple of months back. I still have to figure out how to enable wifi using systemd. There are lots of pieces here and there. Earlier it was just one (config) file and one start/stop script.

fsh 7y ago
What does systemd have to do with your wifi? Handling that is the distro's job.
- shakna 7y ago
  systemd-networkd handles network configuration. For WiFi, you still need WPA supplicant or similar, but you'll have those two things playing together.
  - bonzini 7y ago
    Just install ConnMan instead.
  - fsh 7y ago
    systemd-networkd is completely optional. In raspbian it is disabled by default and a very simple unit-file that calls ifup/ifdown is used. For wifi you obviously have to configure wpa-supplicant or use NetworkManager.
    - shakna 7y ago
      You asked what systemd had to do with WiFi. There are other options, but the parent wanted systemd.
- rkangel 7y ago
  Systemd is part of the distro, as is the kernel and anything else you end up with on your machine after installation.

sirn 7y ago

> Show me an alternative to systemd that matches its functionality and consistency. As for init system, I would argue nosh[1] is a better init system. It’s based on daemontools design (same as s6, runit, etc, where it’s just a process that monitors a service directory). nosh can even semi-automatically convert systemd unit files[2] to a run script (including socket activation and all). For everything else that is not part of the system initialization process (initialize/running/shutdown) I don’t think they need to be tie into PID 1. elogind aims to do this job of taking the logind part out of systemd into its own service, which I found to be a good way of living in systemd world without using systemd (e.g. GNOME works) but it requires a lot of commitment of patching everything to link against elogind instead of systemd (Void Linux/Artix Linux are doing a good job at this). [1]: https://jdebp.eu/Softwares/nosh/ https://jdebp.eu/Softwares/nosh/ [2]: https://jdebp.eu/Softwares/nosh/worked-example.html https://jdebp.eu/Softwares/nosh/worked-example.html

sprash 7y ago

> Show me an alternative to systemd that matches its functionality and consistency. I'm using runit on void for years now. It has no functionality besides being a service manager. Having more functionality is a non feature. > because it can both save you massive time It also can cost you massive time whenever it doesn't work. Then you have to dig yourself through an opaque mess caused by literally millions of lines of C code. I wouldn't trust it with any mission critical. The only usecase for systemd I can think of is grandmas laptop. Maybe that is the target audience for debian, who knows. It is certainly not me.

StreamBright 7y ago

Not sure which part of systemd you are talking about. Everything? The init replacement part? DNS? NTP? All?

eadmund 7y ago

> Show me an alternative to systemd that matches its functionality and consistency. My issues with systemd do not pertain to functionality and consistency: rather, they are issues of taste, style, competence, design and size. The basic ideas behind systemd are, frankly, great. The free desktop really really needs something like it. 100% behind the idea and the functionality. The consistency is pretty good too, I think. It would be taste if it were less consistently in bad taste and more consistently in good taste. Which brings us to taste. First, systemd is security-important system software written in C. Why? There is no good reason to write software in C in 2019. Use a safer language like Go or Common Lisp (both of which are performant enough). I don't know if Java or other JVM languages would work. Perl probably would, although ensuring that a Perl project produces sane code is … difficult. Also on the issue of taste: systemd incorporates Windows-style .INI files wholesale into Unix-like systems. The freedesktop.org folks were already doing this, but why encourage it? The world has at least two better text-based alternatives to .INI files: S-expressions and YAML. Even JSON would be better, even without comments. Also on the issue of taste: systemd just doesn't feel like Unix. In order to get anything done one has to hand-edit lots of little files rather than run a few commands. It's a bit like if you had to run a text editor on a directory to add a file, rather than just creating the file. I'd love to see some commands like mktimer, mkservice or somesuch. I am mostly over the binary logfile issue — after all, ultimately everything on a computer is stored in binary — but I do wish that the tools were a little saner. It's still a pain to figure out where error outputs and so forth are going. The manner in which systemd takes over the world is completely inexcusable. I fully expect to see systemd-browser within the next decade, no doubt with just a few hooks to prevent using Firefox or Chromium, and of course with a few security issues just to spice things up. I really wish that someone with good taste had managed to get the attention of and money from Red Hat in order to design a clean, intelligent, 21st-century init system.

blt 7y ago
not trying to nitpick your comment, but yaml has some serious drawbacks: https://www.arp242.net/yaml-config.html https://www.arp242.net/yaml-config.html

teknopaul 7y ago

Re:"Show me an alternative to systemd that matches its functionality and consistency." This misses the point about init diversity. Let me show you one that has _less_ fuctionality, and is thus more suited to LXC os containers.

kazinator 7y ago

Systemd doesn't replace a large number of solutions; it contains a large number of solutions. Also, in the article: > Others, including Triplett, said that not only do the developers of other init systems lack the desire to implement systemd features, but they argue that those features should not exist in the first place. Something with all the functionality of systemd is just another systemd, which some people don't want in any shape or form.

ryanmccullagh 7y ago

Systems is awesome because writing a service is as simple as writing a unit file. You don’t have to worry about daemonizing, you don’t have to worry about logging (use systemd syslog option).