On Tue 24 Nov 2015 at 17:36:49 +0100, Vincent Lefevre wrote: > On 2015-11-23 00:45:57 +0000, 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: > > > > > > > On Sun, Nov 22, 2015 at 05:56:04PM -0500, The Wanderer wrote: > > > > > > > >>> startx -- vt7 > > > >> > > > >> That requires specifying it by hand every time startx is run. As I > > > >> indicated, that is unacceptable; I don't have to specify the VT > > > >> manually every time I lanch X now in order to get the current > > > >> behavior, and I shouldn't have to specify it manually at every > > > >> launch in order get that behavior after a change of the default. > > > >> > > > >> Where/how would it be possible to specify this in a config file, so > > > >> that it can be set-and-forget if desired? > > > > > > > > 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. It's the first time I've heard > > using a bash alias described as a "kludge". > > Users tend to forget that they have aliases. One day, they want to > add other arguments, and things start to break because the order > of arguments matters, and they wonder why.
That's tangential. I have a TV setup with a Debian thin client and have been known to forget why it is connected as it is and what it does. :) > > Quoting: > > > > There are 2 reasons for this change: > > > > 1) It is needed to make Xorg run without root rights > > Do you mean that the user now needs to be root to do "startx -- vt7"? *I* don't mean anything. I was quoting what a developer said. But "no", the user does not have to be root. > > 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. > > Couldn't registering it with PAM have been a better solution? Above my pay grade, I'm glad to say.
