On Fri 27 Nov 2015 at 09:09:37 -0500, The Wanderer wrote: > On 2015-11-22 at 19:45, Brian wrote: > > > On Sun 22 Nov 2015 at 19:00:36 -0500, The Wanderer wrote: > > > >> On 2015-11-22 at 18:52, Chris Bannister wrote: > > >>> In .bashrc (if using bash) > >>> > >>> alias startx="startx -- vt7" > >> > >> While that would technically work, it's a bit of a kludge, and I'm not > >> fond of those. Perhaps I should have specified an _X-related_ config > >> file (by a definition in which xinit, including startx, qualifies as > >> being X-related). > > > > Passing arguments to startx is X-related. > > But ~/.bashrc is not X-related.
Ok. > > 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, 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. 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. 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. > (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. > >> (Sorry if this looks like moving the goalposts - that's not my > >> intention, I'm just trying to clarify what I was originally asking for.) > > > > 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. > (This also doesn't explain _why_ achieving that goal requires this > change... and although I can guess, the details might still be helpful.) The best I can do here is present http://hansdegoede.livejournal.com/14268.html?page=1 > > 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.
