On Sb, 11 oct 14, 19:57:42, Reco wrote:
> 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 :)
coreutils alone has 107 binaries.
> > - 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.
Oh yes, forgot about that. But my point still stands: why is (almost)
nobody using /etc/inittab to manage their services?
> > , 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.
Yes, but with initscripts you can get slightly different version of the
same bug (e.g. depending on which version of 'skeleton' they are based
on, the script-fu of the respective maintainer, the phase of the moon,
etc), but much more difficult to fix, because you have to inspect each
package.
At least with systemd if you fix a bug it will benefit all daemons using
it.
This is the same reason we are using shared libraries and the Debian
Security Team is doing it's best to track code copies.
The recent method of using a common script goes in the right direction
though.
> > 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.
Sure, but at least a lot of eyeballs are looking at it. How many eyes do
you think look at the average initscript?
> > 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.
You're right, I just went through Policy 9.3 and can't find it
explicitly stated that scripts in /etc/init.d/ should be shell scripts,
but it seems to be an implicit assumption (ha!).
> > 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?
Nope, it just proves my point that sysv-rc is *very* complex.
> > - 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.
Such as?
> > - computers have gotten quite complex themselves with removable devices,
> > complex network connectivity, etc.
>
> 'Removable devices' could been news in 1980s.
True, but sysv-rc still can't deal with them correctly.
> '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.
I'll just give my laptop as example: I have wired & wireless at home,
other wired/wireless network if I take my laptop around plus a dongle
for mobile. And then there's IPv6 (coming... is... coming... whatever).
> > - 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?
No, that was just for the "I'm sole user of this system, why would I
need this logind stuff?" crowd.
> > 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.
http://www.freedesktop.org/wiki/Software/systemd/InterfaceStabilityPromise/
> > - 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…'.
Sure. And the consequence was "OMG, systemd can't be ported to other
kernels!". Of course it can't, it uses Linux specific features.
> > - 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 "simple" one from my home setup:
I have one Raspberry Pi acting as NAS and another one running mpd,
accessing the music stored on the NAS via NFS. To keep all things in one
place I also store mpd's config file on the NAS. How do I make sure mpd
doesn't (try to) start before the NFS share is available?
This used to work, but suddenly isn't and I have no idea why. The NFS is
getting mounted on boot and restarting mpd works. Of course, I've been
doing some changes here and there, and I've also fiddled with the NFS
settings, but it still doesn't explain why the
Required-Start: $remote_fs
in mpd's initscript doesn't do what it implies. As far as I can tell
that information is just used to ensure mpd is started *later* than
mountnfs.sh, but sysv-rc can't actually track that mountnfs.sh has
carried out its job before proceeding with starting all scripts that
require $remote_fs.
> > - 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.
Nope. It's common, but it's not the definition.
http://en.wikipedia.org/wiki/Daemon_(computing)
Also, just because stdout or stderr are detached doesn't imply there's
no output there.
> 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.
And your point is?
> > - 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.
All sound like integration issues, probably fixable. Just curious, why
would a ssh user need a 'seat'?
Kind regards,
Andrei
--
http://wiki.debian.org/FAQsFromDebianUser
Offtopic discussions among Debian users and developers:
http://lists.alioth.debian.org/mailman/listinfo/d-community-offtopic
http://nuvreauspam.ro/gpg-transition.txt
Attachment:
signature.asc
Description: Digital signature