Hi!

> don't think the right response should be to just fix it one way
> for everyone, especially not since those people in charge of hundreds
> of systems have exactly one vote, similar to those who just develop
> for their own home workstation.

I'm sorry, but this is a very bad argument. People who are in charge
of hundreds of systems almost never use the default settings but use
something like FAI, Puppet or ansible to configure their systems
exactly the way they need them. No one is installing hundreds of
computers manually with the d-i images like you would do on a single
machine, that would just be nuts. And in these scenarios, changing
the default settings of configuration files in packages is a daily
routine and nothing special. So, this change has *zero* negative
impact for these users.

As for the usefulness of this change: I used to work at the IT departmant
of a large university in the past and I have some experience in this regard.
In fact, this particular change in systemd solves a *very* common problem in
these setups which are leftover processes on the computers in the student 
computer
pools as around at least a dozen different users are logging in and out again
on these machines per day with many different processes still staying around, 
and,
no, this is not particularly a GNOME problem - it's a general problem which
is usually solved with a cron job which kills leftover processes regularly.

Some people here suggested that, instead of adding such a functionality to
the session manager, affected projects should just fix their software which
effectively translates to "People should write bug-free software" which
is, of course, an unrealistic goal and therefore not really adding to
the discussion in any fruitful manner.

Thus, the systemd approach is actually sane and exactly what most admins of
larger setups with many users want. And it's not that the systemd developers
did not provide an opt-out solution. As it was clearly documented in the
release notes, users are free to disable this feature or use systemd-run
to explicitly prevent a process from being killed upon logout which is
*exactly* what every admin wants: Processes should be killed upon logout
by default and anything that should remain running should request an
explicit permission from the session management. There is really no other
good way to tackle this problem. Admins will neither be able to prevent
buggy software (since users could just write and run their own buggy
software) nor is it practical to keep a long black list with runaway
processes which are being killed upon logout.

It's honestly very frustrating to read bug reports like these as they
are usually written by people who lack the necessary background or refuse
to accept that their particular use case is not the common use case. And I
have more the impression that these bug reports are merely written to
stir up emotions because, again, the systemd developers dared to touch
something in the Linux software stack which has not been touch for years
while solving yet another long-existing problem. A reasonable person wouldn't
even mind about such changes. They would either just disable the feature
completely or use the provided mechanisms to white-list individual processes
which takes less time than writing up such a bug report and stirring up
emotions.

Thanks,
Adrian

-- 
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer - glaub...@debian.org
`. `'   Freie Universitaet Berlin - glaub...@physik.fu-berlin.de
  `-    GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913

Reply via email to