Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Why systemd?

blog.jorgenschaefer.de

Post reply on HN
Print view View original

101–110 of 263 posts

Re: Why systemd?

#101

Post by clarry »

mmagin wrote: post #40
ultramancool wrote: post #32

Earlier quoted context omitted.

Classic sysvinit or BSD-style init doesn't rely upon this sort of functionality at all. Just some simple scripts. No need to complicate it any further. A few signals are all that are needed.

Simple scripts? Have you looked at the shit in /etc/init.d in a modern linux distribution? $ wc -l * | sort -n | tail 274 exim4 286 apache2 290 dnsmasq 298 nfs-common 350 clamav-freshclam 364 udev 386 checkroot.sh 420 clamav-daemon 465 clamav-milter 9893 total If you look into these, you'll find tons of near-duplicate code between scripts, and frequently every script reinvents the wheel in one way or another.

Yes, modern linux and sysvinit are pigs compared to some alternatives (though systemd is worse). The choice isn't a binary choice between sysvinit and systemd. How about this? init + rc + all the scripts combined are smaller than your handful of daemon-specific scripts. And I understand exactly how all of this works (the kernel parts included). I can easily change any part of it, I can easily debug any part of it, I can easily extend any of it if I need special features. With systems that comprise hundreds of thousands of lines of code, just beginning to understand how all of it works together takes much more time...

Simplicity really does buy me something.

    $ wc -l /usr/src/sbin/init/init.c
        1450 /usr/src/sbin/init/init.c

    $ wc -l /etc/rc
        537 /etc/rc

    $ wc -l /etc/rc.d/*

      21 /etc/rc.d/amd
      11 /etc/rc.d/apmd
      21 /etc/rc.d/avahi_daemon
      21 /etc/rc.d/avahi_dnsconfd
      11 /etc/rc.d/bgpd
      15 /etc/rc.d/bootparamd
       9 /etc/rc.d/cron
      14 /etc/rc.d/cvsyncd
      16 /etc/rc.d/dbus_daemon
      15 /etc/rc.d/dhcpd
      11 /etc/rc.d/dhcrelay
      12 /etc/rc.d/dvmrpd
      11 /etc/rc.d/ftpd
      11 /etc/rc.d/ftpproxy
       9 /etc/rc.d/hostapd
       9 /etc/rc.d/hotplugd
      11 /etc/rc.d/httpd
      13 /etc/rc.d/identd
       9 /etc/rc.d/ifstated
      17 /etc/rc.d/iked
       9 /etc/rc.d/inetd
      17 /etc/rc.d/isakmpd
      17 /etc/rc.d/iscsid
      11 /etc/rc.d/ldapd
      15 /etc/rc.d/ldattach
      11 /etc/rc.d/ldomd
      11 /etc/rc.d/ldpd
      11 /etc/rc.d/lockd
       9 /etc/rc.d/lpd
      16 /etc/rc.d/mopd
      17 /etc/rc.d/mountd
       9 /etc/rc.d/mrouted
      18 /etc/rc.d/nfsd
      11 /etc/rc.d/npppd
      38 /etc/rc.d/nsd
      12 /etc/rc.d/ntpd
      11 /etc/rc.d/ospf6d
      11 /etc/rc.d/ospfd
      24 /etc/rc.d/pflogd
      11 /etc/rc.d/popa3d
      11 /etc/rc.d/portmap
      16 /etc/rc.d/rarpd
       9 /etc/rc.d/rbootd
     289 /etc/rc.d/rc.subr
      11 /etc/rc.d/relayd
      11 /etc/rc.d/ripd
       9 /etc/rc.d/route6d
      11 /etc/rc.d/rsyncd
      11 /etc/rc.d/rtadvd
      11 /etc/rc.d/rtsold
       9 /etc/rc.d/rwhod
      11 /etc/rc.d/sasyncd
      13 /etc/rc.d/sendmail
       9 /etc/rc.d/sensorsd
      11 /etc/rc.d/slowcgi
      13 /etc/rc.d/smtpd
      11 /etc/rc.d/sndiod
      12 /etc/rc.d/snmpd
      26 /etc/rc.d/spamd
      25 /etc/rc.d/spamlogd
      13 /etc/rc.d/sshd
      11 /etc/rc.d/statd
      15 /etc/rc.d/syslogd
      12 /etc/rc.d/tftpd
      11 /etc/rc.d/tftpproxy
       9 /etc/rc.d/tor
      32 /etc/rc.d/unbound
       9 /etc/rc.d/watchdogd
      11 /etc/rc.d/wsmoused
       9 /etc/rc.d/xdm
      16 /etc/rc.d/ypbind
      11 /etc/rc.d/ypldap
      28 /etc/rc.d/yppasswdd
      13 /etc/rc.d/ypserv
    1285 total

Re: Why systemd?

#102

Post by andrewflnr »

cbsmith wrote: post #91
Karunamon wrote: post #57

Earlier quoted context omitted.

> systemd is not taking away your freedom in any meaningful sense of the word "freedom" This is absolutely incorrect. We're to the point where certain software packages (GNOME comes to mind) are requiring hard dependencies on it. I was just today reading about some incompatibility that arises if your kernel is set up with no IPv6 support which is explicitly caused by systemd. (To which the response from the systemd f…

> We're to the point where certain software packages (GNOME comes to mind) are requiring hard dependencies on it. Wow... we've come a long way baby! Now freely available software that you can modify as needed without interference is taking away your freedom! ;-) > I was just today reading about some incompatibility that arises if your kernel is set up with no IPv6 support which is explicitly caused by systemd. Actual…

Call it flexibility, then. I don't think you can reasonably deny that a package that requires major surgery to work with a different init system is less flexible than one that simply doesn't care, even if said surgery is perfectly legal with the source available. That flexibility is a large part of why a lot of us came to Linux, and regardless of whether it's technically "freedom", losing it feels like losing freedom.

Re: Why systemd?

#103

Post by allegory »

ultramancool wrote: post #63
uselessdguy wrote: post #51

Disclaimer: I develop uselessd, probably have a warped mindset from being a Luddite who values transparency, and evil stuff like that. The author of this piece makes the classic mistake of equating the init system as the process manager and process supervisor. These are, in fact, all separate stages. The init system runs as PID 1 and strictly speaking, the sole responsibility is to daemonize, reap its children, set t…

Well said. I recently migrated to FreeBSD after trying sytemd on Arch and seeing that Debian and Ubuntu are planning to move too. The dead simple rc.conf file seems so much nicer than the stuff I was dealing with in the entire world of Linux-based systems, like going back to the way Arch used to be when I really liked it.

This. The FreeBSD rc system just works, is well documented and is small enough to understand by one person without too much effort.

Re: Why systemd?

#104

Post by rodgerd »

mhogomchungu wrote: post #6

Lots of people do not seem to understand the criticism of systemd. systemd = init system + a whole lot of other things. When people complain about systemd,they usually do not complain about what it does or how it does it in the init system part.That part is pretty solid as far as functionality is concerned. When people complain about systemd,they usually complain about the "whole lot of other things" part.Lots of peo…

> udev is a core component in any modern linux system I see systemd absorbing it as nothing but a political move and a power grab.

So you're complaining about politics, while your only substantive criticism is a purely political one?

Re: Why systemd?

#105

Post by rodgerd »

codemac wrote: post #50
AceJohnny2 wrote: post #14

Earlier quoted context omitted.

> dbus-dependent pile of crap? This seems to come up frequently. I'm curious: how alternatively would a local process communicate with the Init daemon?

I'm curious: Why is the init daemon what a local process should communicate with? A daemon that managaes other daemons doesn't need to be PID 1, even to reap zombies. Secondly, daemons shouldn't care what process is managing them, a principled approach to communication between the daemon manager and a daemon would probably include handing off sockets/ports/fds, but probably not much else.

> Why is the init daemon what a local process should communicate with?

Because there could, and I know this is a crazy thought, be some benefit in having more meaningful information flow between the master of processes and the processes it manages?

Re: Why systemd?

#106

Post by dredmorbius »

na85 wrote: post #10
dsr_ wrote: post #4

The reason people use UNIX-like systems is because they work reliably. In order to make a complex system work reliably, it needs to be easily fixed. In order to fix a system, a person needs to understand it as well as be able to make a change in it. And in order to understand a system, it helps very much if that system is straightforward and lucidly verbose. I hope systemd will live or die on its merits; I fear that…

It already has taken over despite being mediocre at best. Mostly I feel that it got an undue jumpstart thanks to RedHat trying too hard to be bleeding edge, and Upstart/OpenRC not having as high-profile a backer.

The fact that upstart is covered under Canonical's developer contribution agreement and copyright license counted materially against it in the Debian debate.

Canonical's insistence on control and ownership ended up torpedoing its project. Which is really quite sad.

Re: Why systemd?

#107

Post by aerique »

allegory wrote: post #103
ultramancool wrote: post #63

Earlier quoted context omitted.

Well said. I recently migrated to FreeBSD after trying sytemd on Arch and seeing that Debian and Ubuntu are planning to move too. The dead simple rc.conf file seems so much nicer than the stuff I was dealing with in the entire world of Linux-based systems, like going back to the way Arch used to be when I really liked it.

This. The FreeBSD rc system just works, is well documented and is small enough to understand by one person without too much effort.

Are there reasons why Linux couldn't just adopt it?

Re: Why systemd?

#108

Post by Andys »

aerique wrote: post #107
allegory wrote: post #103

Earlier quoted context omitted.

This. The FreeBSD rc system just works, is well documented and is small enough to understand by one person without too much effort.

Are there reasons why Linux couldn't just adopt it?

There's nothing stopping a Linux distro doing this.... but

It would be a step backwards: it is simpler, and does less stuff, so booting would be slower and some features are missing.

Re: Why systemd?

#109

Post by dschiptsov »

Out of confused mind.)

There is no fundamental problem that it "solves" which other UNIXes presumably still does have. The problem does not exist. AIX, Solaris, *BSD and many old-school Linux guys will tell you that.

Also, any old-school guy will tell you that a kitchen-sink, put-it-all-in design is a wrong way.

btw, user processes supervision is a task of an OS kernel, which it handles via a bunch of specialized syscalls, not of some "man-in-the-middle" user-level daemons.

There is actually nothing to talk about, except some ambitions and bad designs.

Re: Why systemd?

#110

Post by vidarh »

uselessdguy wrote: post #51

Disclaimer: I develop uselessd, probably have a warped mindset from being a Luddite who values transparency, and evil stuff like that. The author of this piece makes the classic mistake of equating the init system as the process manager and process supervisor. These are, in fact, all separate stages. The init system runs as PID 1 and strictly speaking, the sole responsibility is to daemonize, reap its children, set t…

> The init system runs as PID 1 and strictly speaking, the sole responsibility is to daemonize, reap its children, set the session and process group IDs, and optionally exec the process manager.

The process manager gets killed. How do you recover?

If you have respawn logic for it in PID 1, how do you log information about a failure to respawn the process manager?

Perhaps you build in some basic logic for logging. Where do you store the data? What if the user level syslog the user wants you to feed data to can't be brought up yet, because it depends on a file system that is not yet mounted?

There may very well be alternatives to the systemd design, but I've yet to see any that are remotely convincing, in that most of them fail to recognise substantial aspects of why systemd was designed the way it is, and just tear out stuff without proper consideration of the implications.

Most proposed alternative stacks to systemd falls down on the very first question above.

I agree with you that it doesn't seem like a great idea to stuff everything in the init system, but I don't agree that "one must delegate" unless the delegation reduces complexity, and I've not seen any convincing demonstrations that it does.

I'd love it if someone came up with something that provided the capabilities and guarantees that systemd does with indepenent, less coupled component, though.

But there's no way I'm giving up on the capabilities systemd are providing again.

Post reply on HN