On Sat, 2016-06-04 at 19:36 +0200, Roberto Ragusa wrote: > On 06/02/2016 01:04 PM, Lennart Poettering wrote: > > > > > Well. Let's say you are responsible for the Linux desktops of a > > large > > security-senstive company (let's say bank, whatever), and the > > desktops > > are installed as fixed workstations, which different employees > > using > > them at different times. They log in, they do some "important > > company > > stuff", and then they log out again. Now, it's a large company, so > > it > > doesn't have the closest control on every single employee, and > > sometimes employees leave the company. Sometimes even the employees > > browse to the wrong web sites, catch a browser exploit and suddenly > > start runing spam bots under their user identity, without even > > knowing. > Do you really want to support a disruptive change in default > behaviour > with such a specific use case? It is a common *enterprise* concern -- which is fine for enterprises that can afford to pay full-time sysadmins to configure systemd, policykit, SELinux, etc. The problem here is that there are a large number of non-enterprise users who are going to have to deal with yet another unexpected behavior and yet another hard-to-locate configuration option. Yes, hard-to-locate, not because systemd's documentation is lacking but because it will take time to even realize that systemd is the problem. It took me three days to find the problem the last time systemd caused unexpected behavior on my system. What possible reason is there to think that systemd is killing processes? There are dozens of other things that would need to be ruled out first, and when you are not a full-time admin that is unacceptable. -- Ben
Attachment:
signature.asc
Description: This is a digitally signed message part
-- devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxxx https://lists.fedoraproject.org/admin/lists/devel@xxxxxxxxxxxxxxxxxxxxxxx
