I wish rather than saying “it solves my problems” and pretty much leaving it there that the author had detailed what problems systemd solved that alternatives don’t and how fixing those problems is more important than any new problems systemd brings with it.
I’ve written another (earlier) article on what I think systemd gets right, if people want to read about that. I linked to it from this article but clearly not visibly enough. I’ve also recently written an article (partly) on the things that System V init has problems with, some of which are solved by other init systems.
I don’t have a particular opinion on the balance of new problems systemd brings with it because from the outside (as a sysadmin) I haven’t really observed any. Pragmatically, even before systemd came along and swallowed udev et al I felt that Linux booting was already an increasing magic black box of udev, initial ramfses, ConsoleKit, and so on. Systemd may make this a bit worse (I haven’t had to peer through the layers yet with it) but I don’t think it’s much worse; the real sea change happened some time ago.
My overall personal view is that systemd is part of a healthy experimentation and exploration of alternatives that’s going on in Unix and Linux. I don’t think it’s the ultimate init system, especially the ultimate Unixy init system, but it is an attempt to move forward, just as Upstart, SMF, and others have been. We’ll collectively learn from this and either improve systemd or come up with better solutions and replace it.
Strong agree. I’m just following this as an outsider, but I like to keep abreast of various happenings.
Apparently systemd lets your system start faster. My OpenBSD laptop goes from mounting / to the login prompt in about two seconds, which is less time than it spends probing for a floppy disk controller I don’t have. I imagine Linux has given up probing for floppy disks, but those two seconds that systemd could hope to optimize are not the reason I dislike rebooting.
I’ve also read systemd incorporates dbus? The only time I’ve wondered what dbus is or does did not end well. http://marc.info/?l=openbsd-ports&m=136781198206250&w=2 I would not be thrilled having that much awesomeness integrated into init or having even more programs depend on it.
Maybe this is just another sign I’ve turned the corner and become a full blown luddite.
“Socket activation” is not substantially different than inetd stream/wait mode. Nobody bothered for a long time; I suspect that the reason is that inetd configuration requires root, so by that point, in years past when systems stayed up for months or more at a time, it was worth it for any persistent service to bear the start-up costs once, at system boot, have problems reported immediately while someone is watching and get the system to a steady-state of baseline resource utilisation. What’s changed is the ability for users to register services which should be started on-demand, much like MacOS launchd.
I wish rather than saying “it solves my problems” and pretty much leaving it there that the author had detailed what problems systemd solved that alternatives don’t and how fixing those problems is more important than any new problems systemd brings with it.
I’ve written another (earlier) article on what I think systemd gets right, if people want to read about that. I linked to it from this article but clearly not visibly enough. I’ve also recently written an article (partly) on the things that System V init has problems with, some of which are solved by other init systems.
I don’t have a particular opinion on the balance of new problems systemd brings with it because from the outside (as a sysadmin) I haven’t really observed any. Pragmatically, even before systemd came along and swallowed udev et al I felt that Linux booting was already an increasing magic black box of udev, initial ramfses, ConsoleKit, and so on. Systemd may make this a bit worse (I haven’t had to peer through the layers yet with it) but I don’t think it’s much worse; the real sea change happened some time ago.
My overall personal view is that systemd is part of a healthy experimentation and exploration of alternatives that’s going on in Unix and Linux. I don’t think it’s the ultimate init system, especially the ultimate Unixy init system, but it is an attempt to move forward, just as Upstart, SMF, and others have been. We’ll collectively learn from this and either improve systemd or come up with better solutions and replace it.
Strong agree. I’m just following this as an outsider, but I like to keep abreast of various happenings.
Apparently systemd lets your system start faster. My OpenBSD laptop goes from mounting / to the login prompt in about two seconds, which is less time than it spends probing for a floppy disk controller I don’t have. I imagine Linux has given up probing for floppy disks, but those two seconds that systemd could hope to optimize are not the reason I dislike rebooting.
I’ve also read systemd incorporates dbus? The only time I’ve wondered what dbus is or does did not end well. http://marc.info/?l=openbsd-ports&m=136781198206250&w=2 I would not be thrilled having that much awesomeness integrated into init or having even more programs depend on it.
Maybe this is just another sign I’ve turned the corner and become a full blown luddite.
“Socket activation” is not substantially different than inetd stream/wait mode. Nobody bothered for a long time; I suspect that the reason is that inetd configuration requires root, so by that point, in years past when systems stayed up for months or more at a time, it was worth it for any persistent service to bear the start-up costs once, at system boot, have problems reported immediately while someone is watching and get the system to a steady-state of baseline resource utilisation. What’s changed is the ability for users to register services which should be started on-demand, much like MacOS launchd.