On 2015-11-27 at 13:14, Brian wrote: > On Fri 27 Nov 2015 at 09:09:37 -0500, The Wanderer wrote: > >> On 2015-11-22 at 19:45, Brian wrote: >>> It's the first time I've heard using a bash alias described as a >>> "kludge". >> >> It's the difference between "configuring foo to do bar" and "telling foo >> to do bar every time". The latter is a workaround for either foo's lack >> of the ability to do the latter, *sigh* Lack of ability to do the *former*, obviously. >> or a lack of knowledge about how to do the former. >> >> If it is desirable to have this to happen every time (which it plainly >> is, since it has happened every time for over a decade), then it should >> be possible to configure it in X, rather than having to tell X every >> time to do it this way. Using a shell alias avoids the manual retyping >> effort of doing it every time, but is still The Wrong Way To Do It from >> a design perspective. > > Could we look at this hallowed tradition of startx starting X on vt7 and > examine why it happened? 10/15 years ago most (if not all) distributions > shipped with a /etc/inittab which set up 6 ttys. I'd guess there was > nothing magical about 6. Its choice was not dictated by some underlying > principle of OS design but was plucked out of the air, maybe as some > sort of compromise. The tradition continues today with systems which use > and do not use inittab. People have got used to getting 6 ttys. All well > and good up to now. > > When X is started on a tty with startx Xorg picks the first free vt it > can locate, Consequently, with an inittab it will come up on vt7, People > got used to that behaviour too. All well and good up to now. > > Along came distributions which did not use inittab to establish ttys, > but you still got 6 with login prompts on them. Tradition rules. :) Log > in on tty1 and type startx. The next available tty is tty2 (there is no > login on it) so X starts there. Xorg behaves as it should and the > tradition of X on the next available vt is maintained. Again, all is > well and good. Agreed. I'm not wedded strictly to having X start on vt7 in particular; the advantage of using the traditional vt7 is that it's predictable, but as long as I can reasonably figure out which VT it's going to be in any given case, I don't overmuch mind if it's a different one. (It would probably still bother me in some instances, but it's the sort of thing I can deal with.) I do insist on retaining all of "start on a VT different from the one where startx was run", "dynamically pick (a / the first available) VT", and "launch X while logged in as a (possibly specified) non-root user, without needing the root password" - and as far as I can see, the current changed behavior loses at least the first two of those. > Now (because of the requirements of logind) we depart from tradition > (sometimes hard to stomach) in Jessie and have X on the the tty it is > started from with startx. Which may or may not be fine for those who use logind, but should not have to affect those - such as me - who do not. (Indeed, on my system, logind - which is shipped in Debian within the systemd package - is not even installed. That's on purpose; even if it were in a separate package, I'd remove or disable it, because it has undesirable side effects.) > If the patches applied to xinit were reverted we would be back to the > situation described in bug #743015 > > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=743015 > > where, with or without an alias, 'start -- vt7' would be the standard > and traditional way, as it is on Jessie, to have X on vt7. I consider the behavior reported there as a bug to be the desired behavior, and any breakage which it causes in systemd to be systemd's problem. Fixing that breakage in a way which causes changes for those who do not use systemd, especially without providing (and discoverably documenting!) a clear and straightforward way to revert those changes without departing from the as-packaged-in-Debian software versions, is unacceptable. The logic in that bug report appears to be "we switched our default init system to systemd, so we should change other things to work properly with that". There's nothing inherently wrong with that approach, so long as you do not force those changes on environments which do not use that default - but as far as I've managed to learn to date (with no personal testing yet), at least one of those changes does seem to be so forced. This change getting made is an example of the boogeyman of "systemd getting its tentacles into everything". It's not a super-major one, but every straw adds to the camel's burden, to abuse a metaphor a little. >> (Plus, using a shell alias means that either you have to use a different >> command - not just 'startx' - to do the launch, or you lose the ability >> to run 'startx -- foo bar baz' to pass other - or additional - options >> to X at launch time. I've needed to do that for debugging purposes at >> least once, and the loss of the ability to make one-off launch-time >> changes that way would be aggravating.) > > A fair point. I'd leave it to the user to sort this out. _How_?? I don't see any practical way to avoid this problem without compromising in some other area. The goal here is approximately "have zero behavior change for people who would not see the problems which led this change to be made". As far as I can see, the only possible way to achieve that would be to build the appropriate X-related packages locally, without the patches which introduce this change, and keep updating them every time a new package version is released. That's not practical or desirable. >>> Quoting: >>> >>> There are 2 reasons for this change: >>> >>> 1) It is needed to make Xorg run without root rights >> >> Which has never been necessary before... >> >> I can see why it would be desirable to make it possible to run (as >> opposed to launch) X under the UID of a non-root user, but IMO the >> tradeoff here is not worth it - or, rather, pushing that tradeoff on >> every user automatically (rather than leaving the existing behavior in >> place, and enabling each user to decide for him- or herself on the >> relative merits of the tradeoff) is not worth it. > > Running Xorg without root rights is a separate issue from the previous > one and does not affect Jessie. On present testing/unstable a user can > choose to run Xorg with root rights or not in /etc/Xwrapper.config. AFAICT, only if xserver-xorg-legacy is installed - which apparently will not be the case on a fresh Debian install, or on an ordinary dist-upgrade. I didn't discover that package until this thread, and then had to install it manually. >>> 2) The old behavior creates a new session-id (as returned by getsid()), >>> without registering it with PAM, this breaks session managers such >>> as systemd-logind. >>> >>> https://patchwork.freedesktop.org/patch/23004/ >> >> That sounds like a problem for systemd-logind, which should be fixed on >> that side. If you're going to introduce a change which is incompatible >> with the existing ecosystem, that does not mean the existing ecosystem >> should change to accommodate you, especially when doing so will break >> existing behaviors for other software. > > This is not to do with Xorg and root rights. > > 'startx -- vt7' is at hand in Jessie with and without systemd-logind. No > ecosystems have been harmed. I'm not sure what you're trying to say here. The change I was referring to with the above paragraph was the introduction, in logind, of the requirement that "X must run on the VT from which it was launched". (For all I know, this may date back to the first introduction of logind. Even if so, it is still a change from the status quo prior to that point, and one which can be laid at the feet of logind.) The "ecosystem" includes X.org, and the Debian packaging thereof. logind's having introduced that change does not mean X.org, or the Debian packaging thereof, should change to accommodate that change - especially not when doing so will change existing behaviors for people who do not use logind. -- The Wanderer The reasonable man adapts himself to the world; the unreasonable one persists in trying to adapt the world to himself. Therefore all progress depends on the unreasonable man. -- George Bernard Shaw
Attachment:
signature.asc
Description: OpenPGP digital signature