Re: implicit linkage (was: Re: Effectively criticizing decisions you disagree with in Debian)
On Sat, 11 Oct 2014 15:18:58 +0300
Andrei POPESCU <andreimpopescu@gmail.com> wrote:
> On Vi, 10 oct 14, 08:36:23, Joel Rees wrote:
> >
> > Some complexities you can encapsulate or hide, or expose in an
> > organized manner so that that are easier to deal with. Others, no.
>
> [big snip]
>
> The complexity argument can be used both ways:
>
> - the Unix way (do one thing and do it well) leads to many small
> tools that can be combined in different ways, where each tool has its
> own quirks, bugs, release schedules, etc. that only increase
> complexity
At first, yes. But over time these do-one-thing-and-do-it-well pieces
become battle-hardened and fully tested, and they change very slowly.
And, they're not subject to feature creep.
> - sysvinit (/bin/init) is indeed quite simple, but in practice it's
> own mechanisms (/etc/inittab) are only used to start sysv-rc
> (/etc/init.d/rc), which starts all other initscripts, poorly
> written (/etc/init.d/skeleton itself is known to have bugs) in a
> (poor) programming language (shell script) with many different
> implementations (bash, dash, etc.). The scrips are not even enough,
> they have to rely on additional tools like start-stop-daemon(8)
> with their own quirks and bugs.
:-)
sysvinit is an idea whose time has gone. sysvinit is a poor way to
showcase the Unix Way. First of all, the whole idea of runlevels is
bizarre, and adds a lot of complexity to init scripts. If you
compare a daemontools /service/myserviced/run to an init script, you'll
see an order of magnetude simplification, without sacrificing the
flexibility of a shellscript.
>
> - each service/daemon is implemented in its own unique way, with
> different methods of running (quite often multiple ways, depending
> on start-up switches, like foreground, forking, etc.), reloading,
> logging, etc.
Daemontools, and I'd assume all the PID1 softwares based on
daemontools, handles the backgroundization itself. So you just use a
flag to run your daemon in the foreground, and it's taken care of. For
those developers who insist on making their lives difficult by
backgrounding it themselves, with no foreground switch, daemontools
includes a program which *sometimes* can foregroundize the
backgroundized service, although obviously the real way to do it is to
have the original programmer provide a way to run his program in the
foreground.
>
> - computers have gotten quite complex themselves with removable
> devices, complex network connectivity, etc.
>
> - multiple users on the same system (GNU/Linux is supposed to be a
> multiuser system, isn't it) with different backgrounds, level of
> technical understanding, expectations, etc.
>
> It feels to me like systemd (the project) is rather *trying* to
> reduce complexity, by providing:
>
> - a clear and simple way (unit files) to declare what a service needs
> and how it should be run and a clear and simple method for the
> daemon to notify when it is ready to provide its service if its
> authors choose to implement it
>
> - mechanisms to deal with badly behaved daemons as well as provide
> proper isolation (e.g. cgroups, tmp files handling, etc.)
>
> - mechanisms to deal with the complex interactions between daemons,
> devices, networks, etc.
>
> - a logging mechanism that can capture *all* output of a daemon
> (stdout, stderr, logging)
>
> - a unified way to manage users (as in humans) and their complex ways
> of interacting with the computer (different privileges, local,
> remote, etc.)
I *might* characterize the preceding as trying to reduce complexity for
the dufus who can't even write a shellscript. However, the cost of this
reduced complexity for the dufus is huge complexity within the program:
complexity even smart people can't work around without some truly
ridiculous kludges.
Also, and this is just my opinion, reducing complexity is not what I
think Red Hat is trying to do. I think they're trying to make an
operating system so complex that their help is necessary for anything
but the most plain vanilla installations, and they're trying to create
a Linux ecosystem where all distributions must march to the Red Hat
drummer, with the ultimate goal of monopolism and divergence from
standards (POSIX for one). Like I said, this is my opinion. You might
say "Hanlon's razor", and I'd reply "follow the money."
>
> - etc.
>
> Is systemd (the project) trying to do too much? Possibly.
:-) Nice understatement.
> Would it be better if this was done in a modular design *done right*?
> Probably.
I'd say modular design done right would be for systemd to be PID1 and
nothing else. It should be able to accept all PAM implementations
currently accepted. It shouldn't need to subsume all sorts of other OS
functions. And if that were the case, it would be done already, with
not a bit of resistance from users.
>
> Yet, none of the solutions so far has *really* caught on.
> daemontools, runit, s6, init-ng, etc. and even upstart were either
> never adopted on a large scale or eventually abandoned in favor of
> systemd.
I have a theory on that. runit, s6, init-ng, etc never caught on
because sysvinit was considered good enough, and it was easier for the
average person to work around its rough edges rather than learn a new
init system.
Then Red Hat decided to subsume all of Linux with systemd, and to do
so, they convinced everyone that the sysvinit they'd used for years was
horrible, and *we must instantly* move on. Meanwhile, read
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=727708 . runit, s6,
init-ng, etc, never stood a chance, because *all of a sudden*, after
years of sysvinit being though manageable, it was considered the kiss
of death, and we didn't have no damn time to explore runit, s6,
init-ng, etc.
Follow the money. I contend Red Hat's vilification of sysvinit was as
much self serving "disease mongering" as drug maker Burroughs Wellcome's
late 1970's stigmatization of herpes, just after they invented an
anti-herpes drug:
http://en.wikipedia.org/wiki/Herpes_simplex#Society_and_culture
Similar tactics, exact same exact motivation.
> As far as I understand Linus Torvalds himself admits that a modular
> kernel design is better, yet he choose to make Linux monolithic. On
> the other hand Hurd is still not even in a releasable state.
The difference is that the kernel doesn't reach out and try to take
over subsystems that are obviously outside its normal sphere of
influence.
> Could it be that a modular design for such complex tasks becomes too
> difficult to *do it right*?
There's no doubt that for a small, self contained subsystem, it's often
easier to write your own, perhaps less modularly than might be ideal,
rather than grab all sorts of modules which kinda-sorta fit but you
need to massively code to make them mesh.
On the other hand, when something gets big, like as big as systemd is
trying to be, a monolithic solution, or even a modular solution with
wide and detailed interfaces, is a constant bug risk, and disables
smart people from making things with building blocks.
> Is systemd going to change the GNU/Linux ecosystem? Definitely.
>
> Will this change be good or bad? Only time will tell, but I'm quite
> sure that even if the change will turn out to be bad it will *not*
> destroy GNU/Linux, but help it evolve in better ways.
Not if Red Hat has their way, and it appears they're on their way
to getting their way.
SteveT
Steve Litt * http://www.troubleshooters.com/
Troubleshooting Training * Human Performance
Reply to: