(Phew. Sorry for the delay in replying.) 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. > 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. (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.) >> (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. (This also doesn't explain _why_ achieving that goal requires this change... and although I can guess, the details might still be helpful.) > 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. -- 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
signature.asc
Description: OpenPGP digital signature
