10 ms·

Tom Gundersen discussed the move to systemd on the Arch Linux forums a couple of years ago. https://bbs.archlinux.org/viewtopic.php?pid=1149530#p1149530 https:

Tom Gundersen discussed the move to systemd on the Arch Linux forums a couple of years ago. https://bbs.archlinux.org/viewtopic.php?pid=1149530#p1149530 https://bbs.archlinux.org/viewtopic.php?pid=1149530#p1149530 Summary: 0) it is hotplug capable 1) we can know the state of the system 2) it is modular 3) it allows dbus/udev to go back to doing the task they are meant to do 4) we can reduce the number of explicit ordering dependencies between daemons 5) we get a lot of security/sandboxing features for free 6) systemd service files can be written and distributed upstream 7) systemd is a cross-distro project 8) logind will finally deliver on what consolekit was supposed to do 9) systemd is fast

antocv 13y ago
DMD has all those advantages as well. Dmd is the gnu daemon managing daemons.
- davexunit 13y ago
  I'm very excited about dmd. It's being developed in conjunction with the Guix project for an official GNU distribution. I hope to soon steer clear of this systemd mess by using a Guix system running dmd.
  - antocv 13y ago
    Yeah me too, and we can help, get on the guix-devel list and try to follow, learn guile/scheme and such. Im planning at least to provide more documentation, when I learn guix and dmd more.
    - davexunit 13y ago
      I'm a Guix contributor. Haven't hacked on dmd yet, though.
      - antocv 13y ago
        Youre doing awesome work!
  - itistoday2 13y ago
    Are you kidding me? Have you actually looked at it? I'm a huge fan of Lisp-based languages, but this thing actually wants people to use Lisp for creating service files! http://www.gnu.org/software/dmd/manual/dmd.html#Service-Examples http://www.gnu.org/software/dmd/manual/dmd.html#Service-Exam... Not even data-based lisp like Clojure's data format (the one that Light Table uses for its configs, forget the name), but full-on lisp!. That would be a maintenance nightmare for sys admins. Not to mention that it seems rather sparse in basic features... I couldn't find any example in the manual for setting users & groups or permissions. These are fundamental.
    - davexunit 13y ago
      Yes, I've looked at it. You need to understand that dmd is still a fledgling project. Note the version number before you trash a software project. It lacks the features of the popular init systems, but it works well enough to run some basic services on the demo Guix VM images. I love the fact that the configuration is written in Guile. Data is code and code is data after all. I think you're exaggerating the maintenance nightmare. In fact, the Guix project has already proven that newcomers who don't really know s-expression style syntax can write software packages.
    - sparkie 13y ago
      Data-based formats are most useful when you know all the requirements one will need up-front, because they need to be coded into your "schema" or DSL - these schemas quickly break down when you have new requirements - and initialization is an extremely diverse area. The only way to actually manage such a DSL/Schema is to provide a way to "break out" of it into a general purpose language - that's what systemd does by allowing you to run shell scripts in the case you're not using a "standard" service, and it's also what the Nix expression language does in order to build software. It's far easier to just provide a fully capable language up front - and abstract the common patterns into functions or macros to simplify the usage for users. sysv has worked well with just shell scripts for years, despite it being a sub-standard general purpose language - although various hacks like the LSB init headers have been added to provide some kind of structure to them - a problem that will be better solved with records in Guile. As for maintenance, I see it as a big plus - with a language like Guile you have access to a useful REPL and debugger - no need to roll your own debugging interface or inspect log files. On top of that, having a dynamic language makes it easier to develop and test patches for new requirements - you're not forced to recompile and restart your DSL.
viraptor 13y ago
While systemd has some good parts... 0: udev did that. They merged udev in. Now systemd does it. I'd rather see them play nice by communicating with other projects than controlling everything on their own. 1: Apart from internal watchdog, the features he listed are also available in upstart. (others are not, but his list is actually common) 3: This is a strange claim when talking about an init system that effectively starts managing devices. 6: Not sure why it's on the good things list - it already happened before for rc/init/upstart. It's inevitable rather than new awesome - we'll all have to rewrite the configs once again. 8: Why is that part of systemd? Ubuntu was happily running with it being a separate daemon. If it doesn't depend on systemd why is it included (same for udev really). Convenience for developers is not a great answer here. There seems to be a lot of exaggerated claims going both ways - at least that shows not everyone is happy about the change. Hopefully the next project that replaces init will be what many claim systemd is right now...
- RVuRnvbM2e 13y ago
  0: Kay wrote udev. He is now a lead contributor to systemd... 1: Upstart was hobbled by the Canonical CLA. Several systemd contributors cite this as the reason for starting systemd in the first place. 3: See 0 6: See 1 8: logind is developed as part of the systemd suite, but is entirely modular and in fact is used with non-systemd inits via systemd-shim.
  - viraptor 13y ago
    I don't believe the CLA was the main reason for starting systemd. Otherwise they'd just fork upstart and continue to work on it without signing anything. CLA has nothing to do with technical features either. I'm not sure why the same maintainer matters for merging. Take openstack as a counter-example. It's mostly the same pool of contributors working on a number of related projects. Not only have they been split into components (nova, nova-volume, nova-network -> nova, cinder, quantum projects), common functionality has been split into separate library projects of their own (oslo-messaging, oslo-logging, etc.) with their own releases, versioning, leadership. This is what I really like and it's exactly the opposite of what systemd is doing (merging device, network, logging, etc. into one system). If systemd is modular (doesn't require logind) and logind is standalone (requiring only systemd as a library) - what's the point of bundling them. (apart from making it harder for others to use) Systemd owns too much at the same time and I believe it's going to lead to problems in the future.
lawl 13y ago
0) That's not the init systems job. 1) That's not the init systems job. Use something like http://cr.yp.to/daemontools.html 2) Less modular than any init system out there. Having *everything* (including a dhcp deamon soon) in PID 1 is not modular just because you can configure it. 3) See 1. 4) Never bothered me, but fair enough. 5) That's not the init systems job. 6) Not if the path's differ. E.g. are debianized. 7) So was sysvinit. 8) That's not the init systems job. 9) It actually is. Edit: And if you downvote me, at least add an explanation please. Thanks. I'd like to know if I'm factually wrong or you just disagree.
- cnvogel 13y ago
  > 2) Less modular than any init system out there. Having everything (including a dhcp deamon soon) in PID 1 is not modular just because you can configure it. I can understand the issue that people have with systemd swallowing more and more functionality, but this fact is just false. dhcp is in /usr/lib/systemd/systemd-networkd, which is not the systemd binary running as PID 1 (/usr/lib/systemd/systemd/systemd). chris@raspberrypi /usr/lib/systemd $ ls -la systemd systemd-networkd -rwxr-xr-x 1 root root 907340 Apr 14 23:10 systemd -rwxr-xr-x 1 root root 329604 Apr 14 23:09 systemd-networkd chris@raspberrypi /usr/lib/systemd $ ./systemd --version systemd 212 +PAM -AUDIT -SELINUX -IMA -SYSVINIT +LIBCRYPTSETUP +GCRYPT +ACL +XZ +SECCOMP -APPARMOR
- RVuRnvbM2e 13y ago
  You clearly don't understand systemd. It is a suite of tools for managing the system state. Going from runlevel 0 to runlevel 3 is just one such transition. systemd is referred to as monolithic because it is developed in a single repository, but it is in fact extremely modular. "PID 1" is only one of the ~70 binaries which make up the systemd suite. Saying "That's not the init systems job" seems dogmatic and short sighted when there's currently no other approach which offers the hotplug, service management, security and performance features that systemd brings to the table.
- zokier 13y ago
  I think you are missing the forest for the trees. Systemd is not just PID1, it is an umbrella project for various core system bits and pieces. Most stuff in systemd project do not run in systemd PID1.
binaryapparatus 13y ago
For me, systemd broke beautiful Arch setup into some monstrosity. That's not what Arch was or at least what it was for me. I do (rarely) install Linux on some new PC but I think I stopped installing Arch after this changes. I mean what's the point installing Arch if there is no very elegant and beautiful rc.conf? What is that killer feature that Arch offers, apart from being rolling release?
- zokier 13y ago
  > What is that killer feature that Arch offers, apart from being rolling release? Like being good solid rolling release distro is not good enough? Frankly I prefer my distros to be free of any "killer features".
  - cursork 13y ago
    It's Wiki is pretty killer. That may not sound like much, but it's pretty awesome. I use it as a reference on a few things even when dealing with other Linux distros. e.g. The page on SSH basically starts with how to restrict users who can log in and disabling root. https://wiki.archlinux.org/index.php/Secure_Shell https://wiki.archlinux.org/index.php/Secure_Shell Haven't used Arch in a while - not dealt with a non-company Linux box for a while. But it remains my go-to Linux (for development purposes) for good reasons.
    - mitosis 13y ago
      Seconding this: the killer app of Arch Linux is its community support.
- nvarsj 13y ago
  For me, systemd on Arch reduced my boot time from 45s or so to pretty-much-instant-on. Which is pretty damn nice for a distro where one tends to reboot a lot. > I mean what's the point installing Arch if there is no very elegant and beautiful rc.conf? rc.conf removal had nothing to do with systemd, I think. And was removed prior. > What is that killer feature that Arch offers, apart from being rolling release? Vanilla upstream packages.

antocv 13y ago

DMD has all those advantages as well. Dmd is the gnu daemon managing daemons.

davexunit 13y ago
I'm very excited about dmd. It's being developed in conjunction with the Guix project for an official GNU distribution. I hope to soon steer clear of this systemd mess by using a Guix system running dmd.
- antocv 13y ago
  Yeah me too, and we can help, get on the guix-devel list and try to follow, learn guile/scheme and such. Im planning at least to provide more documentation, when I learn guix and dmd more.
  - davexunit 13y ago
    I'm a Guix contributor. Haven't hacked on dmd yet, though.
    - antocv 13y ago
      Youre doing awesome work!
- itistoday2 13y ago
  Are you kidding me? Have you actually looked at it? I'm a huge fan of Lisp-based languages, but this thing actually wants people to use Lisp for creating service files! http://www.gnu.org/software/dmd/manual/dmd.html#Service-Examples http://www.gnu.org/software/dmd/manual/dmd.html#Service-Exam... Not even data-based lisp like Clojure's data format (the one that Light Table uses for its configs, forget the name), but full-on lisp!. That would be a maintenance nightmare for sys admins. Not to mention that it seems rather sparse in basic features... I couldn't find any example in the manual for setting users & groups or permissions. These are fundamental.
  - davexunit 13y ago
    Yes, I've looked at it. You need to understand that dmd is still a fledgling project. Note the version number before you trash a software project. It lacks the features of the popular init systems, but it works well enough to run some basic services on the demo Guix VM images. I love the fact that the configuration is written in Guile. Data is code and code is data after all. I think you're exaggerating the maintenance nightmare. In fact, the Guix project has already proven that newcomers who don't really know s-expression style syntax can write software packages.
  - sparkie 13y ago
    Data-based formats are most useful when you know all the requirements one will need up-front, because they need to be coded into your "schema" or DSL - these schemas quickly break down when you have new requirements - and initialization is an extremely diverse area. The only way to actually manage such a DSL/Schema is to provide a way to "break out" of it into a general purpose language - that's what systemd does by allowing you to run shell scripts in the case you're not using a "standard" service, and it's also what the Nix expression language does in order to build software. It's far easier to just provide a fully capable language up front - and abstract the common patterns into functions or macros to simplify the usage for users. sysv has worked well with just shell scripts for years, despite it being a sub-standard general purpose language - although various hacks like the LSB init headers have been added to provide some kind of structure to them - a problem that will be better solved with records in Guile. As for maintenance, I see it as a big plus - with a language like Guile you have access to a useful REPL and debugger - no need to roll your own debugging interface or inspect log files. On top of that, having a dynamic language makes it easier to develop and test patches for new requirements - you're not forced to recompile and restart your DSL.

viraptor 13y ago

While systemd has some good parts... 0: udev did that. They merged udev in. Now systemd does it. I'd rather see them play nice by communicating with other projects than controlling everything on their own. 1: Apart from internal watchdog, the features he listed are also available in upstart. (others are not, but his list is actually common) 3: This is a strange claim when talking about an init system that effectively starts managing devices. 6: Not sure why it's on the good things list - it already happened before for rc/init/upstart. It's inevitable rather than new awesome - we'll all have to rewrite the configs once again. 8: Why is that part of systemd? Ubuntu was happily running with it being a separate daemon. If it doesn't depend on systemd why is it included (same for udev really). Convenience for developers is not a great answer here. There seems to be a lot of exaggerated claims going both ways - at least that shows not everyone is happy about the change. Hopefully the next project that replaces init will be what many claim systemd is right now...

RVuRnvbM2e 13y ago
0: Kay wrote udev. He is now a lead contributor to systemd... 1: Upstart was hobbled by the Canonical CLA. Several systemd contributors cite this as the reason for starting systemd in the first place. 3: See 0 6: See 1 8: logind is developed as part of the systemd suite, but is entirely modular and in fact is used with non-systemd inits via systemd-shim.
- viraptor 13y ago
  I don't believe the CLA was the main reason for starting systemd. Otherwise they'd just fork upstart and continue to work on it without signing anything. CLA has nothing to do with technical features either. I'm not sure why the same maintainer matters for merging. Take openstack as a counter-example. It's mostly the same pool of contributors working on a number of related projects. Not only have they been split into components (nova, nova-volume, nova-network -> nova, cinder, quantum projects), common functionality has been split into separate library projects of their own (oslo-messaging, oslo-logging, etc.) with their own releases, versioning, leadership. This is what I really like and it's exactly the opposite of what systemd is doing (merging device, network, logging, etc. into one system). If systemd is modular (doesn't require logind) and logind is standalone (requiring only systemd as a library) - what's the point of bundling them. (apart from making it harder for others to use) Systemd owns too much at the same time and I believe it's going to lead to problems in the future.

lawl 13y ago

0) That's not the init systems job. 1) That's not the init systems job. Use something like http://cr.yp.to/daemontools.html 2) Less modular than any init system out there. Having *everything* (including a dhcp deamon soon) in PID 1 is not modular just because you can configure it. 3) See 1. 4) Never bothered me, but fair enough. 5) That's not the init systems job. 6) Not if the path's differ. E.g. are debianized. 7) So was sysvinit. 8) That's not the init systems job. 9) It actually is. Edit: And if you downvote me, at least add an explanation please. Thanks. I'd like to know if I'm factually wrong or you just disagree.

cnvogel 13y ago
> 2) Less modular than any init system out there. Having everything (including a dhcp deamon soon) in PID 1 is not modular just because you can configure it. I can understand the issue that people have with systemd swallowing more and more functionality, but this fact is just false. dhcp is in /usr/lib/systemd/systemd-networkd, which is not the systemd binary running as PID 1 (/usr/lib/systemd/systemd/systemd). chris@raspberrypi /usr/lib/systemd $ ls -la systemd systemd-networkd -rwxr-xr-x 1 root root 907340 Apr 14 23:10 systemd -rwxr-xr-x 1 root root 329604 Apr 14 23:09 systemd-networkd chris@raspberrypi /usr/lib/systemd $ ./systemd --version systemd 212 +PAM -AUDIT -SELINUX -IMA -SYSVINIT +LIBCRYPTSETUP +GCRYPT +ACL +XZ +SECCOMP -APPARMOR
RVuRnvbM2e 13y ago
You clearly don't understand systemd. It is a suite of tools for managing the system state. Going from runlevel 0 to runlevel 3 is just one such transition. systemd is referred to as monolithic because it is developed in a single repository, but it is in fact extremely modular. "PID 1" is only one of the ~70 binaries which make up the systemd suite. Saying "That's not the init systems job" seems dogmatic and short sighted when there's currently no other approach which offers the hotplug, service management, security and performance features that systemd brings to the table.
zokier 13y ago
I think you are missing the forest for the trees. Systemd is not just PID1, it is an umbrella project for various core system bits and pieces. Most stuff in systemd project do not run in systemd PID1.

binaryapparatus 13y ago

For me, systemd broke beautiful Arch setup into some monstrosity. That's not what Arch was or at least what it was for me. I do (rarely) install Linux on some new PC but I think I stopped installing Arch after this changes. I mean what's the point installing Arch if there is no very elegant and beautiful rc.conf? What is that killer feature that Arch offers, apart from being rolling release?

zokier 13y ago
> What is that killer feature that Arch offers, apart from being rolling release? Like being good solid rolling release distro is not good enough? Frankly I prefer my distros to be free of any "killer features".
- cursork 13y ago
  It's Wiki is pretty killer. That may not sound like much, but it's pretty awesome. I use it as a reference on a few things even when dealing with other Linux distros. e.g. The page on SSH basically starts with how to restrict users who can log in and disabling root. https://wiki.archlinux.org/index.php/Secure_Shell https://wiki.archlinux.org/index.php/Secure_Shell Haven't used Arch in a while - not dealt with a non-company Linux box for a while. But it remains my go-to Linux (for development purposes) for good reasons.
  - mitosis 13y ago
    Seconding this: the killer app of Arch Linux is its community support.
nvarsj 13y ago
For me, systemd on Arch reduced my boot time from 45s or so to pretty-much-instant-on. Which is pretty damn nice for a distro where one tends to reboot a lot. > I mean what's the point installing Arch if there is no very elegant and beautiful rc.conf? rc.conf removal had nothing to do with systemd, I think. And was removed prior. > What is that killer feature that Arch offers, apart from being rolling release? Vanilla upstream packages.