[systemd-devel] Query regarding "EnvironmentFile"

[Kai Krakow]

Am Mon, 21 Dec 2015 22:41:04 +0100
schrieb Marc Haber <mh+systemd-devel at zugschlus.de>:

> On Mon, Dec 21, 2015 at 10:18:05PM +0100, Kai Krakow wrote:
> > Thus: Please maintainers and developers, remove it. Do not let
> > Lennart remove this useful option to force others into removing
> > your shitty cruft.
> 
> This is exactly why systemd is the top one most hated piece of open
> source software. We are not here to be educated about the one and only
> right way of doing things.
> 
> Unix used to be about choice.

I'm not arguing about choice, neither I wrote anything against it. But
a distribution and upstreams should not ship with ugly concepts of
configuration or even tied to specifica of some distributions. How many
upstreams are out there who ship the debian concept as the one and
only, others ship the SuSE concept (sysconfig) which in turn is similar
but incompatible to Redhat.

Please tell me: Where is this about choice?

Choice is if you decide yourself (or your distribution) to adapt a
configuration concept. And that is why I'm pro keeping the
EnvironmentFile option. In essence, this means: You are still and will
stay in choice.

Please read the whole post before answering.
 
> Too bad that we allowed this to be no longer the case. Linux is no
> longer about choice. Linux nowadays is about what the systemd people
> want.

That's wrong. You maybe just cannot adapt to new, more modern, and more
sane concepts and defaults. You are then probably also the type of
people which are forcing upstream to remove options so nobody can misuse
them any longer.

Systemd is vastly different from concepts we had for the last 50 years
(or so), but linux really needs this modernization. Many concepts are
broken in term of modern computing. Yes, it still works. Yes, never
break a working system. But we really need new concepts, we are the
generation of laying out the proper path and a solid foundation for
following generations of sysadmins. This also means that systemd will
stay in flux for a few more years.

Really... Don't get me wrong. I don't mean that personally. But I can
watch the same behavior among my workmates - and it's almost always a
problem of not willing to learn and handle new concepts.

Nobody is taking choice away, we just need to learn to apply it
properly and in a new way. And this forum should be of discussing a way
to do it instead of starting to hate each other because someone else
took our toys away.

If you are using systemd, it's time to rethink some of your concepts
and re-apply them in the most straight-forward way. Mixing runtime,
default, startup (etc etc) configuration with each other is really a
pain - and not the way to do. It has never been. Even in sysvinit. But
many distributions and upstreams weakened this separation.

And shipping default configurations that make it easy to miss issues
with deprecated custom configuration has ever been bad. I think this is
what the devs in this thread are talking about at its core.

> Too bad that we gave the systemd people the power of forcing us to run
> our systems their way.

Then, don't run systemd. Nobody forces you. It was your choice to use a
distribution which migrated to systemd as the one and only option.
Thus, it's not the systemd people forcing you. It's your distribution.
Complain there. Or switch to a distribution which allows for more
choice. Or put simply: Deal with it.

Systemd is also not overtaking upstreams. The concept allows to leave
out all the systemd bits. Configuration concepts may change, however.
Still, if systemd gets pulled in by packages, it's probably the
distributions "fault" (except for maybe Gnome, I don't use it so I
don't know about the options).

But we probably need to find ways to support configurations concepts
which cope with systemd and non-systemd installations. In the end, its
about choice.

I cannot see anything here in the thread which would disallow continue
using non-systemd installations.

-- 
Regards,
Kai

Replies to list-only preferred.