Re: implicit linkage (was: Re: Effectively criticizing decisions you disagree with in Debian)
Hi.
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:
Indeed. In fact:
> - 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
On the other hand, full blown systemd comes with 69 binaries on board,
and such number of binaries reduce complexity somehow :)
> - 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)
You're wrong. At least gettys are started via /etc/inittab, and
Ctrl-Alt-Del handling goes there too.
> , which starts all other initscripts, poorly written
> (/etc/init.d/skeleton itself is known to have bugs)
Every software more complex than 'Hello World' has bugs. Heck,
*systemd* has bugs.
> in a (poor)
> programming language (shell script)
As latest development of OpenSSL show us, C isn't that great
programming language either, and more complex than shell.
> with many different
> implementations (bash, dash, etc.).
As long as shell in question conforms with POSIX specification, it does
not matter. And nobody forbids one to put a binary into /etc/init.d,
it'll work. Or a Perl script. It's just a convention that everyone put
shell scripts there.
> The scrips are not even enough,
> they have to rely on additional tools like start-stop-daemon(8) with
> their own quirks and bugs.
That's the intended usage of shell scripts - to be a glue between
utilities. Does it surprise you?
> - 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.
Given that said 'services' are written by different people - that's
nothing unusual. In fact, ever-growing DSL of systemd's units clearly
shows that 'one size fits all' approach constantly fail to account for
various corner cases.
> - computers have gotten quite complex themselves with removable devices,
> complex network connectivity, etc.
'Removable devices' could been news in 1980s.
'Complex network connectivity' usually requires one to configure a
network interface or two, and start a bunch of helper daemons. It would
be fair argument if systemd suite contained implementations of all VPN
clients known to the man - but it does not.
> - 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.
Wait, wait, wait. You mean there was no multiuser systems based on
GNU/Linux before systemd invention? Or said multiuser systems were
unusable?
> 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
By inventing its' own DSL [1] to write such unit files, therefore
moving complexity from writing a shell script to learning constantly
changing DSL.
> - mechanisms to deal with badly behaved daemons as well as provide
> proper isolation (e.g. cgroups, tmp files handling, etc.)
You've probably meant 'using existing kernel mechanisms to deal with…'.
> - mechanisms to deal with the complex interactions between daemons,
> devices, networks, etc.
Please provide an example of such interaction. And, while we're at it, a
definition of a 'network' you're using here.
> - a logging mechanism that can capture *all* output of a daemon (stdout,
> stderr, logging)
Which any daemon shouldn't have at all to start with. The very
definition of daemon implies it detached own stdout, stderr and stdin.
Systemd has couple of interesting tricks for starting daemons
(ptrace, clearing environment, to name a few), but logging
mechanism (aka journald) is an optional part of systemd.
> - a unified way to manage users (as in humans) and their complex ways of
> interacting with the computer (different privileges, local, remote,
> etc.)
Said unified way is unable to distinguish a user at the console from a
user who's connecting to a computer by means of x11vnc :) Does not
assign a 'seat' to the ssh-connected user. And is only good for a
typical desktop. Clearly there's much work to be done here.
[1] https://en.wikipedia.org/wiki/Domain-specific_language
Reco
Reply to: