On Sun, Jun 25, 2017 at 01:02:01PM -0700, Rick Moen wrote:
> Quoting Enrico Weigelt, metux IT consult (enrico.weig...@gr13.net):
> 
> > Could anyone please enlighten me, what all these "seat" and "session"
> > stuff is really about ? What is the underlying problem to solve here ?
> 
> Below are a couple of things I've written on the subject here and
> elsewhere.
> 
> 
> 
> Date: Tue, 19 Jul 2016 01:29:23 -0700
> From: Rick Moen <r...@linuxmafia.com>
> To: dng@lists.dyne.org
> Subject: Re: [DNG] F1 and special usernames on the login screen
> 
> Quoting Arnt Gulbrandsen (a...@gulbrandsen.priv.no):
> 
> > Multiseat is unimportant, barely significant.  The price of computers
> > has dropped enough that the ones with UIs are now personal devices.
> 
> Might be obvious, but just mentioning:  'Multiseat' (GNOME/system
> implementation of which proximately caused the systemd-logind
> omnishambles of several years ago) needs to be distinguished from
> multiuser.
> 
> Unix has been inherently, by design, _multiuser_ since its beginning,
> and I for one would be quite sad if my Linux servers were suddenly
> 'personal devices':  E.g., a Web / SMTPd / ftpd / sshd / rsyncd / NTPd
> server like the one in my garage suddenly failing to serve remote users
> would be a misfortune.
> 
> I have to confess that I personally didn't understand how multiseat
> differs from multiuser on Linux until quite recently.  Pro bono publico:
> It concerns simultaneous _local_ users.  The Linux kernel[1] can,
> unaided, make _only one_ (local) virtual terminal active at a time.  Sure,
> you can (e.g.) have one X11 server attached to /dev/tty7 and another to
> /dev/tty8, but it turns out that any time one's active, the other can't
> be -- even if two physical sets of console hardware are attached.
> So, multiseat is, in short, a system software elaboration to fix that.
> 
> This missing kernel functionality isn't important to either you, Simon
> Walter, or me, but it's a genuine limitation nonetheless, and there's
> nothing wrong _per se_ with offering ways around that limitation.  Note
> that systemd-consoled is not the only candidate:  kmscon preceded it,
> albeit development is currently stalled.
> https://en.wikipedia.org/wiki/Kmscon
> https://en.wikipedia.org/wiki/Multiseat_configuration#GNU.2FLinux also
> mentions several other current implementations.
> 
> So, multiseat is _not_ a systemd invention, nor a systemd monopoly.
> 
> Latter page mentions 'Multiseat setups are great for schools, libraries,
> and family computers.'  Arguably true, _maybe_.  Depends on the economics
> of additional consoles versus extra complete computers, I guess.  I
> enjoyed using minicomputers during high school:  A modern revival of that
> computing model using Linux might make money sense or might not, depending.
> Otherwise, I wouldn't say today that it'll necessarily be 'unimportant' in
> years to come.
> 
> [1] Some other *ixes such as SunOS and Irix allegedly (per Wikipedia)
> had multiseat capability since early days, though I have no further
> details.

Rond about 1990 I was using an X terminal.  8 megabytes of memory, 
impleented the X protocol, and almost nothing else.  It presented a 
login screen on sshich I could tell it which coputer on the network I 
wanated to log in to, as sell as the usual name and password, and after 
that I had X with a window manager.  If I wanter a so-called desktop, 
I'd tell the remote machine to start it.

It worked just fine.  Nothing special needed on the remote machine.

THe X terminal could even boot over the net.  It did not need much in 
the way of local permanent storage.

-- hendrik
_______________________________________________
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Reply via email to