Re: I'm not a huge fan of systemd
-----BEGIN PGP SIGNED MESSAGE-----
On 07/05/2014 03:59 PM, Sven Joachim wrote:
> On 2014-07-05 20:25 +0200, Steve Litt wrote:
>> Now comes systemd, which, from what I've heard, is a further step
>> away from the Unix Philosophy, in that it is more monolithic and
>> exerts more control and more continuous control over all programs,
>> from what I understand.
> Systemd is anything but monolithic, it includes several dozen
> programs many of which are precisely "doing one thing and doing it
> well". E.g. the common task of creating a directory/file/socket etc.
> under /tmp or /run is accomplished by systemd-tmpfiles, and packages
> can just drop a snippet in /usr/lib/tmpfiles.d do declare what they
Can you run systemd without logind or journald?
Can you run logind without systemd or journald?
Can you run journald without systemd or logind?
(Et cetera, for any other theoretically-separate systemd components.)
If you can, then why is it that libpam package dependencies which appear
(if I've understood the discussion correctly) to be about functionality
now provided by logind are pulling in systemd *as the active init
system* automatically? (Much less doing it without notifying the user
that they're making such a big switch, which is an entire separate
argument that's been had at least twice by now.)
If not, then these elements are not independent modules, even though
they do very different things and the things they replaced were
independent of one another.
>> The DOS (and Windows) Philosophy was one of monolith, with hooks
>> into the monolith via autoexec.bat, config.sys, and (later) the
>> registry. Programs were big and binary, with binary inputs and
>> output files readable only by the specific program, or a converter
>> or program with an importer or exporter. The Unix philosophy is a
>> bunch of parts configured together, mainly communicating with
>> readable text, and if you want to change things, you reconfigure.
> That's exactly how systemd units work. One notable difference to
> init scripts is that they are much shorter and easier to understand,
> plus you can exactly override the parts you want to change - no need
> to answer questions at the dpkg conffile prompt and merge your
> changes back in later (I have done that often enough to know how
> annoying it is).
But you can't easily see exactly what logic is being carried out for
each step, and/or in what order; doing that would require looking at the
systemd source code.
Rather than multiple standard tools whichare also used for other
purposes and which have multiple available implementations (e.g. sh,
grep), parsing standard and fully transparent syntax (e.g. shell code,
regular expressions), you have a single-purpose tool which exists only
in one implementation parsing a more limited syntax designed to work
with that tool and supported by little if anything else.
Maybe it really is the best way to go overall; there are certainly
advantages to what I've heard described of it, which would offset the
disadvantages to at least some degree. But it still looks like a more
monolithic system to me.
>> It looks to me like the main goals are to boot faster, and to tie
>> everything together better.
> Booting faster is not really a main goal, tighter integration - yes,
> systemd aims to reduce the differences between the various Linux
I'm a bit confused - what does "tighter integration" have to do with
differences between Linux distributions?
Integration is sort of like the flip side of "multiple independent
components", as opposed to "integrated components". That's got nothing
to do with multiple distros, or the differences between them, as far as
I can tell.
Tighter integration has its advantages, in efficiency and so forth if
nothing else, but it also makes it harder to swap out one component for
another and/or otherwise try something new - which is a very big
disadvantage, especially considering that that swappability has for a
long time been one of the strengths of *nix.
Secrecy is the beginning of tyranny.
A government exists to serve its citizens, not to control them.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
-----END PGP SIGNATURE-----