Re: [tlug] Running without Gnome/KDE/xfce/whatever. (was: Ubuntu 16.04-LTS Japanese Text Input)

["Stephen J. Turnbull" <stephen@example.com>]

Curt Sampson writes:

 > So do I just remove /usr/bin/x-session-manager then, and the standard
 > startup routines will work ok?

I think so, that's the configuration I have on my Debian box.  FWIW,
the actual test on Debian is "[ -x /usr/bin/x-session-manager ]".

 > I was working with this earlier statement from you:
 > 
 > > *If* you provide your own .xinitrc or .Xsession, that will completely
 > > replace the corresponding system script, but that's rarely necessary.
 > 
 > So, you're basically saying that this is one of those situations? (If
 > so, fair enough.)

Yes, I'd say this is one of those situations.  Only one user can
control /usr/bin/foo.  QED FUD BSBS ;-)

 > Not exactly. I'm not sure how much of this was in their original
 > idea, but at this point they've had separate user systemd instances
 > available for a long time, and they're explicitly aiming at being
 > able to use systemd as a session manager for X11+whatever systems.

Sure.  I wonder, maybe systemd would be more powerful in "switching
personalities" than /etc/alternatives is.  I think the basic idea of
/usr/bin/x-*-manager is the one-user workstation, and even if you
"switch personalities" with a word-processing user and a BEAMing JVM
user and ..., you probably aren't so schizo as to change SM and WM.
 
 > > But I don't need user level session management -- *I* am my session
 > > manager.
 > 
 > Well, you *can* do that,

Ah, I was excusing my ignorance, not suggesting that that's a good way
to do things in general.  WFM donchano.

 > > However the Unix philosophy pushes in the direction of minimal
 > > assumptions....
 > 
 > Oh, so it was the MIT guys who were always writing programs that
 > sacrificed completeness, working in in 80% of cases and breaking in the
 > other 20%? :-)
 
Smiley notwithstanding, you have a point there.  But I'll resist the
temptation to ask when the RightThing GNU HURD is going to be
delivered, because I think your point is somewhat superficial.  For
example, grep output is pretty painful on the kernel -- even
decompressed ;-) -- and I have grepped large binaries without
strings(1) when I needed to dig out Japanese.  But grep --text
doesn't crash on those files.  (This is a case where I grant the
usefulness of making the user ask for the pain, because many terminal
emulators will crash, of course.)

 > >  > Most software developers and their managers, like most humans,
 > >  > are inherently hugely optimistic, and so thinking about
 > >  > failure modes is not something that they do well.
 > > 
 > > Who needs to *think*?
 > 
 > Anybody who wants to do something the simple way, rather than the easy
 > way. In my experience, doing something simply requires a lot of thought,
 > which nobody finds particularly easy, though some like the challenge.
 > 
 > > Just observe your own pratfalls and listen to your users. ;-)
 > 
 > Yeah, I'm not buying that one. I've seen too many people stack hacks on
 > top of hacks to fix their own pratfalls.

I didn't mean that it was easy to do a good job of dealing with design
issues posed by observed failures.  Just that "the security mindset"[1]
isn't necessary to identify failures in most cases, simple observation
will do.  I'm more pessistic than you -- I don't think "most software
developers and their managers" are as much optimistic as they are
willing to impose the costs on users rather than do the necessary
thinking to get to a good solution.

But then, I get to watch the Python developers at work, so what do I
know about how ordinary "managed mortals" build software? ;-)

Footnotes: 
[1]  https://www.schneier.com/blog/archives/2008/03/the_security_mi_1.html