Re: support for merged /usr in Debian
On Sun, 17 Jan 2016 15:19:43 +0100, Tom H <tomh0665@gmail.com> wrote:
>Johann (I can't think of the other "fanboi" to whom you're referring)
>has argued in the past for the removal of rc.local and sysvinit
>compatibility.
People like him should be silenced on development mailing lists. They
don't care about the common sysadmin at all.
>Let's assume that Lennart removes support for them as
>well as for "EnvironmentFile=", will it really be something that'll be
>worth getting upset about?
It is worth getting upset when people try to "educate" me in a field
that doesn't need educating. It just triggers childhood aversions, and
I am surely not the only one.
>For EnvironmentFile, does it really matter whether you edit a file
>under "/etc/default/" or under "/etc/systemd/system/"? As I said
>up-thread, I'm wouldn't like setting up nfs without "EnvironmentFile="
>but it's something that'll just take a little longer initially,
>whether I'm using config management or not. And then it'll be the
>same, since I only change these files at setup.
Being forced to change things as a systadmin just for the sake of
change is always bad. People not caring about backwards compatibility
do not care about their users. "Gut feeling" is an important
instrument in the seasoned sysadmin's life, and when the gut feeling
says "this should be a variable here" and you can't do it because the
darn system doesn't support variables, it leaves you with a bad
feeling. And I don't want to have bad feelings during my work. It's
not only my work, it's my passion. And it hurts to have it made worse
by people not caring about my passion.
This is the case for systemd, and, sadly, has become the case for
Debian in the last year or so.
>For rc.local, does it really matter whether you edit "/etc/rc.local"
>or a file under "/etc/systemd/system/"?
It matters if I have had rc.local on hundreds of systems for decades
and now need to change every one of them. I don't care so much how
configuration works in new installs (where I only need to change the
installation automatism), but if rc.local has been ticking away in
existing installs without the need for configuration management, this
change is unnecessary and means to have implementation and testing and
rollout and change management, which can easily amount to at least
half a work day even on a single big installation.
> Personally, even if I've used
>rc.local when in a hurry, I've always made a point of creating a
>sysvinit script, upstart job, or systemd service unit later.
Yes. rc.local is not something I care about. Removing the support for
/etc/default files just for the sake of educating people to do things
"right" and "in the correct systemd way" is outright evil.
>There's residual anger at systemd because it more or less snookered
>distros and users into adopting it,
... and now uses its leverage to force people into doing things their
way by slowly removing compatibility features. This is rearing its
ugly head, destroys trust and makes me feel that systemd should be
forked as soon as possible so that removed features can be patched in
again.
But I fear that systemd upsteam will promptly engage into "educating"
the people who dared to fork about that it is a bad idea to fork
systemd by starting needless refactoring in the code so that the
compatibility patches in the forked code don't apply as nicely, thus
causing lots of unnecessary work.
How did we allow these people to gain this much power over us?
Greetings
Marc
--
-------------------------------------- !! No courtesy copies, please !! -----
Marc Haber | " Questions are the | Mailadresse im Header
Mannheim, Germany | Beginning of Wisdom " | http://www.zugschlus.de/
Nordisch by Nature | Lt. Worf, TNG "Rightful Heir" | Fon: *49 621 72739834
Reply to: