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

3: Brian W. Kernighan, Rob Pike, "The UNIX Programming Environment"

4: http://c2.com/cgi/wiki?LittleLanguage