On 08/31/2015 05:36 PM, The Wanderer wrote: > Two, I base this assessment on the things he has said and the ways in > which he has reacted when people have objected to various of the things > he has done - on his public comments and discussion, I get the opposite impression, that's why I responded they way I did to your assertion. I don't want to talk behind the back about someone without them being present, so I'll not go into further detail - but just the fact that I have a completely different impression than you do may indicate that you are indeed subconsciously not trying to assume good faith on his part. >> Sure, but I would rather come to the situation where people can air >> their honest disagreements here without resorting to name-calling, >> greatly exaggerated hyperbole and assumptions of bad faith. > > I entirely agree, but given how far apart philosophically the sides of > this disagreement are, I'm not at all sure that it's reasonable to > expect that there will not be anyone even in the lowest grades of either > side who does not go that far. The problem is not that there is every once in a while somebody who crosses the line a bit, because things got a bit emotional - the problem is that I see it far too often that systemd opponents cross that line - just take my two initial replies in this thread as an example. >> And while this has not been the worst exchange on this topic, the >> very first posting in this thread is a prime example for people >> assuming bad faith. Just look at the title of this thread and thus >> the framing of the discussion. Instead of talking about what actually >> happened (that there's a new alternative to su that fits slightly >> different use cases) the title claims that su will disappear. Note >> that _nobody_ working on su, neither upstream nor maintaining it in >> distributions, has claimed that they will stop. > > Nobody working on sysvinit claimed that they would stop doing that when > systemd came along and Lennart started claiming that it was the vastly > better approach, either, and yet sysvinit is well on the way to becoming > marginalized. It doesn't seem entirely unreasonable at first glance to > expect something similar to happen again, There are two very important distinctions: 1. Most importantly, there can only be one central init system active at any given time. init systems are special in that way. This is definitely not the case with su - there are already alternatives to su installed on many systems - take sudo and pkexec. So the fact that there's now another alternative - even if it happens to be installed on every system by default - will not mean that su is going to be disappear - just because su will still work as it did before even if an alternative is present. 2. Also, very many people were yearning desperately for an alternative to sysvinit. You might not have been, other people opposed to systemd might not have been - but there's a reason why sysvinit wasn't even a strong contender in the TC decision in Debian (that was systemd vs. upstart vs. maybe openrc) - because a lot of people were actively looking for something that fixed a lot of the conceptual problems it has. You might disagree here, and I really don't want to reiterate the discussion on that specific topic - my point just is that there were a lot of people (myself included) that were really glad when systemd came along, because it really filled a need that was present in at least parts of the community. I don't see anything even remotely similar going on with su. Most people who use su are perfectly happy with it and are not looking for something new. > * There is apparently an interaction between su and the collection of > binaries which are known collectively as "systemd" which produces > undesirable results, and is at least arguably a bug. Yes, but if you look closely the problem is the following: a certain environment variable that is set by libpam-systemd upon login, namely XDG_RUNTIME_DIR, is not set when using su. If you don't use the systemd components, that environment variable isn't set at all - and from my personal experience, I have never needed the functionality for which the variable is used in shells I've opened with su. So it's not like su is suddenly broken - it's just that some specific new use cases don't work properly with it. If you're currently happy with su, nothing will change for you. > * Lennart refuses to change that collection of binaries in order to > prevent this interaction from causing these results, on the grounds that > A: su is ill-defined to begin with (or so he asserts), Well, kind of. The problem is that there are lots of bits an pieces that go into the concept of what a 'session' is under Linux - and su has historically altered some of those things, but kept others to be the same as the session it was called from. Since the part of the session that XDG_RUNTIME_DIR is tied to is not changed by su, the systemd developers decided to also not change XDG_RUNTIME_DIR. On the other hand, keeping the variable as-is would have security implications, so they decided to opt for the solution of simply unsetting it. Given the context, that is a perfectly sound decision in my eyes. > and B: an > alternative tool which he thinks is better is already available as part > of the collection of binaries which are known collectively as "systemd". His initial reaction was to just close the bug as wontfix - only after pressure from a user did he augment the machinectl tool (which already had similar functionality for containers) and added this functionality. So "B:" is definitely not the reason for his decision. Also, there's nobody stopping the su developers implementing a new --full-session switch or so that also creates a real separate session. > * Therefore, the only way to avoid the friction which arises from that > interaction and its undesirable results is to either not use su or not > use systemd. As I said above: if you weren't using systemd, you wouldn't have had the problem in the first place. The friction will only occur if you use software in your root shell that expects that environment variable to be there - which most commands you run as root don't do. I've never needed it as root. Christian
Attachment:
signature.asc
Description: OpenPGP digital signature