[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Please more fish (was: so long and thanks for all the fish)

On Sun, 2014-11-09 at 22:38 +0100, Simon Richter wrote: 
> I can completely understand why we (and that includes me) want systemd
> as a default: it gives the best possible integration of desktop
> components possible.
I even think it's best on a server (that means, if it was used as it
could be)...

With sysvinit it was basically not possible to make any guarantees, e.g.
like start XYZ only when firewall rules were successfully loaded, at
least not in a systematic fashion.
Or things like: When iptables rules are reloaded, stop fail2ban before,
restart it afterwards.

Unforunately, even if systemd would support such nice things, nothing of
this is deployed to the masses,... which is also why I wrote, that it
sometimes feels as if we'd only try to map sysvinit into systemd.

> However, there are use cases where systemd does not work because of
> software design choices that, again, are in the best interest of its
> users.
Well I guess that goes back into the init-system discussion ^^

That being said, I personally would welcome, if it was policy that it's
not allowed to require a specific init-system (unless specifically
related software).

> This is a common pattern in software development. When designing a
> complex system, you have two extremes:
> 1. A system that covers all use cases by building a minimal framework
> and letting users fill in the rest via a scripting language.
... which, especially in the complex cases, often lead to just more

I mean it's of course nice to be able to edit the init-scripts, add
debug output, or adapt something to one's own very personal need.
But often this also just means that either one isn't doing things right
in the first place OR that the init script wasn't generically
configurable enough.

> 2. An elaborate system that simplifies use for the majority of cases,
> uses a descriptive language for configuration, and falls flat for any
> case that is out of scope.
> Neither approach is inherently "better" than the other, but they can
> be better suited for particular applications, and the choice which to
> use is up to the user.
Which is why I'm definitely in favour of init-system diversity.

> I think it is immediately clear which one is preferable. However, I
> doubt you'd get far trying to move the Linux kernel to automake, as it
> has additional requirements that cannot be represented in this way,
> and extending automake to handle these is a herculean task.
Well I for the matter always hated autotools... (perhaps one should
lobby Linus for CMake? ;) )...

I think: an init-system shouldn't be programming,... one could always
see that this basic idea is somehow broken, when programs (shell
scripts) need to go to /etc,... and when people realised that this
causes only troubles, they've started trying to make them generic enough
to handle all cases and configurable via /etc/default/*

> The systemd architecture is, in my opinion, similar to automake.
Well, in a way, surely... but then one need to question: Should an init
system be a universal programming language or should it be a
systematised framework to boot the system, start software and perhaps
manage all this after boot.

And *I* don't think it should be a universal programming language.
In most cases where I've ever needed to manipulate init-scripts and
doing "advanced" things, like not only starting one apache http but
several, running as different user and that like (which is IIRC nowadays
even supported by the init script, at least partially), one could also
simply say, that the original init script was simply not powerful enough
and should have been implemented better in the first place, to avoid any
need to manipulate it.

And speaking of things like autotools,... I'd also say that the world
has mostly just benefit from systematising build procedures.

> Restricting ourselves to a conservative default policy without any
> assumptions thus sounds sensible to me. One such assumption is whether
> we're running on a server, desktop or laptop system, which basically
> limits us to starting programs on conditions because we cannot really
> define a one-size-fits-all power policy.
Uhm, I absolutely agree with that,... but I don' think it's a problem of
systemd per se - it's rather a problem of how it's used/configured.

Unfortunately the general direction seems to be to assume a single user
PC or even tablet,... which is why we have default settings like: mount
a USB stick if plugged in, or what I recently found in
virt-manager/libvirt/spice,... forward any usb stick plugged in
automatically to guest VMs.

But these problems aren't inherent to systemd or polkit,... it's rather
bad default decisions being made by people who have only their won usage
scenario in mind.

This is one of the main reasons why I got more and more of a gnome and
utopia-stuff critic.

I also think it's potentially dangerous when systemd upstrem tries to
"revolutionise" more and more things, which go far beyond any init
system or process manager (like the recent adventure of how software
should be installed o.O)
But even then, systemd seems to be better (actually especially in the
server case - well at least if it was used correctly) than sysvinit.

Anyway... let's not start this discussion again ^^


Attachment: smime.p7s
Description: S/MIME cryptographic signature

Reply to: