Re: implicit linkage (was: Re: Effectively criticizing decisions you disagree with in Debian)
Hi.
On Sat, 11 Oct 2014 20:47:36 +0300
Andrei POPESCU <andreimpopescu@gmail.com> wrote:
> 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.
Yup. Please calculate how many of them are actually used
in /etc/init.d. You'll lower your number by the point of magnutude.
Besides, coreutils is an essential package in Debian, systemd is not.
> > > - 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?
Because one does not start services only, one sometimes needs to stop
them. That's something that dbus people didn't learn in all these
years, it seems.
> > > , 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.
And with systemd you can have the same based on the same criteria.
I mean, do you really expect a sane behavior from the project with a
code quality like this - [1]?
> At least with systemd if you fix a bug it will benefit all daemons using
> it.
No, quite the contrary. By fixing such jack-of-all-trades
libsystemd library you're risking to *break* some other daemons.
But, pretending your point is valid, fixing /etc/init.d/skeleton grants
the same benefits.
> This is the same reason we are using shared libraries and the Debian
> Security Team is doing it's best to track code copies.
Consider /etc/init.d/skeleton a library then. It's sources to
any /etc/init.d script anyway.
> 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?
As recent 'shellshock' vulnerability shows, many eyeballs are good, but
hardly enough (hint - shellshock was introduced in 1989). And it also
shows, that there're curious minds that are finding bugs everywhere,
including shell scripts. Especially now, after shellshock 'fired'.
> > > 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.
Hardly. It proves that starting daemons is complex. Sysv-rc is simple
by itself, and that's about the only good thing that can be said about
sysv-rc IMO.
> > > - 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?
Please see an arbitrary systemd's changelog. Observe phrases such as
"we've added phrase FooBar to the unit files". Such phrases are the
sign of DSL change, and it only happen for two reasons:
a) Sudden irresistible urge (or voices in someone's head) to add a
phrase.
b) There's some daemon that genuinely need it.
I prefer explanation b), what about you?
> > > - 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.
It does not have to deal with the hardware, as it not its' job. That's
udev's job. By pure coincidence, systemd ships with udev too.
And they use the same udev in Debian regardless of whenever systemd is
installed or not.
> > '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).
Ok. You have wired, that's one stanza in /etc/network/interfaces. Or
one obscure systemd's unit, if you prefer *that*.
You have wireless, and while it's possible to
use /etc/network/interfaces for that too (I do, for example), Joe the
Average User would probably use NetworkDestroyer (sorry, Manager), or
wicd. Anyway, wireless requires usage of wpa_supplicant, which is not a
part of systemd. Presumably one can use a systemd's unit for that too,
but I've never tried it.
A dongle for a mobile is probably a good old g_ether network interface
aka usb0. It's complicated somewhat as one may need to use
usb-modeswitch (not a part of systemd, btw), but it's nothing more
complex than yet another stanza in /etc/network/interfaces.
As for the IPv6 - unless you're turning your own PC into a router,
configuring IPv6 is something that kernel does for you already without
any intervention from the userspace (it's called a Router Advertisment).
Also, [2]. Network configuration on client side can be complex, but it
does not mandate using any init per se.
> > > - 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.
Thanks, I'm perfectly aware why I don't need logind - it does not solve
any of the problems I need to solve. Same for it's predecessor,
ConsoleKit.
If I ever need a computer with the multiple X servers running
simultaneously - I'll consider using logind.
> > > 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/
They modify their DSL with *every* systemd release. Currently they do
it on 'add more stuff' basis indeed, as per your link.
So what - stability of interfaces does not eliminate
ever-growing complexity. And, 'the unit configuration file format' (to
quote your link), does not imply invariant *semantics* of units' DSL.
> > > - 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?
You don't have to, in this specific case. NFS should be mounted long
before any daemon starts, mpd included. Things can break, as your
example show.
A better example would be 'how I can ensure that mpd will
stop if I unmount a NFS share?'.
Still, I agree that's a valid point, *if* you disregard an existence
of automount(5). Because, mounting NFS from an fstab is *so* AIX.
> > > - 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.
If these file descriptors are detached why bother collecting output from
there? A good daemon either has its' own logs, or is using syslog
anyway.
> > 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?
If you're boasting systemd, please consider choosing actual benefits,
not questionable ones.
> > > - 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'?
[3] tells us "systemd 30 and newer include systemd-logind. This is a
tiny daemon that manages user logins and seats in various ways."
I had an impression that an ssh login is an actual login.
And, since you can easily start an X session over ssh - there's need to
consider it a ssh login a seat too.
As for the x11vnc - I doubt that it could be fixed. x11vnc attaches to
an existing X server, and is translating said server I/O over VNC to
anyone. It does not spawn its' own session, so there's nothing that can
be tracked.
[1]
http://cgit.freedesktop.org/systemd/systemd/tree/src/core/dbus-manager.c?id=3731acf1acfb4a6eb68374a5b137f3b368f63381#n638
[2] https://www.debian.org/doc/manuals/debian-reference/ch05.en.html
[3] http://www.freedesktop.org/wiki/Software/systemd/logind/
Reco
Reply to: