3 ms·

I am not seeing any justification for why these tools HAVE to be a single, monolithic tool. > script glue That's what shell scripts[1] are FOR - they are the

by pdkl95 13y ago

I am not seeing any justification for why these tools HAVE to be a single, monolithic tool. > script glue That's what shell scripts[1] are FOR - they are the minimal glue that binds the large applications together. Besides, "big brittle mess" is a matter of opinion. Are you trying to tell me that this OpenRC script is a "mess" that needs to be replaced, taken from /etc/init.d/cupsd my current desktop: #!/sbin/runscript depend() { use net need dbus before nfs after logger } start() { ebegin "Starting cupsd" checkpath -q -d -m 0755 -o root:lp /run/cups checkpath -q -d -m 0511 -o lp:lpadmin /run/cups/certs start-stop-daemon --start --quiet --exec /usr/sbin/cupsd eend $? } stop() { ebegin "Stopping cupsd" start-stop-daemon --stop --quiet --exec /usr/sbin/cupsd eend $? } Yes, some scripts get much longer, because they have more complicated needs. Even in an alternate environment such as systemd, those will always be complicated. Things like changes in power or network addresses have been handled by OpenRC just fine (note: that was opinion, and systemd is better in some cases). More important,y those requirements do not suggest a need to bind tools together into one package, thoug; instead, they suggest a well-defined API* (or ABI) is needed. In OpenRC, that is simply another runlevel that you trigger on power-plug changes, etc. Your argument seems to be that the using many tools is too complex (even though each tool in isolation is much simpler, reduced in scope, and is likely to have fewer bugs), while tying that functionality together is faster to develop (despite makng the problems into a complex, interdependent mess). Despite being labeled an "april fools joke", RFC 1925 [2] has important wisdom. In particular, there seem to be a lot of people ignoring Truth #5: It is always possible to agglutinate multiple separate problems into a single complex interdependent solution. In most cases this is a bad idea. This is really a restatement of the UNIX design philosophy. Or maybe you're prefer this version, written by some old hackers you may have heard of[3] Even though the UNIX system introduces a number of innovative programs and techniques, no single program or idea makes it work well. Instead, what makes it effective is the approach to programming, a philosophy of using the computer. Although that philosophy can't be written down in a single sentence, at its heart is the idea that the power of a system comes more from the relationships among programs than from the programs themselves. Many UNIX programs do quite trivial things in isolation, but, combined with other programs, become general and useful tools. This idea about keeping problems separated was true when those guys wrote UNIX in the first place, it was true wen Dijkstra suggested structured programming instead of "goto", it was true when Alan Kay suggested sending Messages between Objects for yet more encapsulation, and countless other examples throughout the history of software. It is still true now. If you're having a hard time seeing this, I suggest you re-examine the problem and ask if an API could tie the pieces together, because it probably already exist in an unspecified form. > Finally, no one is forcing you to use a systemd based distribution. Of course not, but the monopolistic tactics being used to vertically integrate systemd IS forcing a problem - on purpose - with various other tools such as udev and gnome. I'm obviously going to stick to Gentoo for desktop use, but even there, the disruption caused by systemd has caused a significant mess by breaking previously-working software on purpose. -- 1: If this is merely a hatred of BourneShell/BASH, I would actually understand that as it certainly has its layers of cruft and gotcha/wtf behavior. A new Little Language[4] with special support so the standard "init script" support to make the scripts trivially small in general case could be really nice. 2: http://www.ietf.org/rfc/rfc3439.txt http://www.ietf.org/rfc/rfc3439.txt 3: Brian W. Kernighan, Rob Pike, "The UNIX Programming Environment" 4: http://c2.com/cgi/wiki?LittleLanguage http://c2.com/cgi/wiki?LittleLanguage

vidarh 13y ago
To your openrc example: How do you statically determine what state the system is meant to be in this moment? Without doing that, you are unable to determine whether the system is in that state, and so unable to take corrective actions. Furthermore, how do you even determine whether or not a service is still running? Init can not sanely do that for anything but the simplest cases, and a non-pid-1 process can not do that without the risk of losing the capability when that process dies (it's when, not if when you run more than a handful of servers or vms - when you have aggregate uptimes across a system measured in centuries and individual uptimes on most servers measured in years, it does not matter how robust a component has been written - you will see them fail, not necessarily of their own doing). And a "new litle language" would not solve the issue unless it is purely declarative. A large part of the point is to be able to reason about system state, in part by being able to tell what the state should be, in part by being able to verify what the state actually is and operate on it (start/stop etc.). The former requires you to be able to statically determine the current intended state; the latter requires you to be able to accurately track which processes forms part of a service, even if the parent daemon dies and orphans a bunch of stuff (and in that case it is not helpful if the process trying to do this can die and orphan everything and lose the state information).
- jude- 13y ago
  I'm pretty sure openrc uses (or has the option to use) cgroups for dealing with just this. Containerizing services isn't a new idea--Solaris and FreeBSD can do this already, for example. Regardless of the init system, we've had the ability to control daemons with cgroups already for some time (cgexec and friends). Even in humble sysvinit, I can edit an initscript and ensure that the service it starts runs in a cgroup. Hypothetically, I could even do this inside of start-stop-daemon.
hactually 13y ago
So my cups.service is: [Unit] Description=CUPS Printing Service [Service] ExecStart=/usr/sbin/cupsd -f PrivateTmp=true [Install] Also=cups.socket cups.path WantedBy=printer.target It requires no extra things - Your cups script depends on checkpath and start-stop-daemon. More executables, more dependencies so yeah, I'd argue it suffers coupling and is a mess. You say that systemd makes things a "complex, interdependent mess" but it's better than the brittle dependent mess of the status quo. The usage of start-stop-daemon doesn't even ensure that the app was killed - it acts just as a killall <servicename>. It doesn't catch a process in a Disk Wait state or even if the process has trapped the SIGTERM - It's not just useless, it's deceptive as to its functionality. People continually spew the line about the UNIX philosophy. If you want to use Unix, use Unix. Linux is [becoming] better than Unix.

by pdkl95 13y ago

vidarh 13y ago

To your openrc example: How do you statically determine what state the system is meant to be in this moment? Without doing that, you are unable to determine whether the system is in that state, and so unable to take corrective actions. Furthermore, how do you even determine whether or not a service is still running? Init can not sanely do that for anything but the simplest cases, and a non-pid-1 process can not do that without the risk of losing the capability when that process dies (it's when, not if when you run more than a handful of servers or vms - when you have aggregate uptimes across a system measured in centuries and individual uptimes on most servers measured in years, it does not matter how robust a component has been written - you will see them fail, not necessarily of their own doing). And a "new litle language" would not solve the issue unless it is purely declarative. A large part of the point is to be able to reason about system state, in part by being able to tell what the state should be, in part by being able to verify what the state actually is and operate on it (start/stop etc.). The former requires you to be able to statically determine the current intended state; the latter requires you to be able to accurately track which processes forms part of a service, even if the parent daemon dies and orphans a bunch of stuff (and in that case it is not helpful if the process trying to do this can die and orphan everything and lose the state information).

jude- 13y ago
I'm pretty sure openrc uses (or has the option to use) cgroups for dealing with just this. Containerizing services isn't a new idea--Solaris and FreeBSD can do this already, for example. Regardless of the init system, we've had the ability to control daemons with cgroups already for some time (cgexec and friends). Even in humble sysvinit, I can edit an initscript and ensure that the service it starts runs in a cgroup. Hypothetically, I could even do this inside of start-stop-daemon.

hactually 13y ago

So my cups.service is: [Unit] Description=CUPS Printing Service [Service] ExecStart=/usr/sbin/cupsd -f PrivateTmp=true [Install] Also=cups.socket cups.path WantedBy=printer.target It requires no extra things - Your cups script depends on checkpath and start-stop-daemon. More executables, more dependencies so yeah, I'd argue it suffers coupling and is a mess. You say that systemd makes things a "complex, interdependent mess" but it's better than the brittle dependent mess of the status quo. The usage of start-stop-daemon doesn't even ensure that the app was killed - it acts just as a killall <servicename>. It doesn't catch a process in a Disk Wait state or even if the process has trapped the SIGTERM - It's not just useless, it's deceptive as to its functionality. People continually spew the line about the UNIX philosophy. If you want to use Unix, use Unix. Linux is [becoming] better than Unix.