Re: terminal servers

[Gregory Merchan <merchan phys lsu edu>]

I am very distrubed to see this thread appear at this time in GNOME's
development. I would never have known about X or Linux or GNOME had I not
wanted to stop travelling across town to the U. to use a real computer.

If such matters had been considered earlier we might now have:

 1) Bandwidth and latency testing of apps.
 2) Pre-release usability testing enabled by a single test host to
    user-testing labs almost anywhere on earth.
 3) Better collaboration and idea sharing by allowing others to run apps
    without having to ship source and recompile.

(further ranting censored for your protection)

This paper should bring to the fore some of what we should expect of GNOME:

  http://www.usenix.org/publications/library/proceedings/lisa95/full_papers/gittler.txt

On Mon, Nov 12, 2001 at 03:17:26PM -0500, Havoc Pennington wrote:
> 
> Hi,
> 
> At ALS several of us talked to guys doing terminal server stuff
> (http://www.ltsp.org). They pointed out:
> 
>  a) it's a big deal to be able to do terminal servers, because
>     this is what makes Linux a cheap desktop; cf. KDE in Largo, 
>     Florida
>  b) GNOME is relatively easy to fix for this environment
>  c) this could make a big difference in adoption
> 
> A terminal server basically means you have a bunch of thin clients
> that simply run the X server, and a central machine with tons of RAM
> that has all home directories and runs the desktop and applications,
> displaying on the remote X servers. This is a relatively easy remote
> setup, we aren't dealing with e.g. using the same home directory from
> two machines; all apps are running on the same server.
> 
> Here are the problems we need to address to work well:
>  
>  - right now, logging in twice from different terminals blows 
>    up the desktop, because .gnome files lack locking. 
>    fixed automatically by port to GConf, but we have to port 
>    to GConf to get the fix.
> 
>  - Nautilus doesn't properly register itself per-display or something,
>    so trying to start it on a second terminal results in displaying a
>    new window on first terminal
> 
>  - as a start, we could at least cope with the above by refusing 
>    to log in a second time (gnome-session could hold a lockfile
>    perhaps). But it'd be nice to actually work with two logins at 
>    once.
> 
>  - we need to be able to lock down settings so users don't mess it
>    up. GConf already supports locking settings, but apps need to
>    handle it correctly using the key_is_writable() call to turn off
>    the prefs dialog. Also, we probably need a global
>    lock_everything_down setting to cover stuff not in GConf.
> 
>  - of course we need to work on remote displays, but that already
>    works (for the all-apps-on-same-machine case anyway), we just 
>    can't break it
> 
> I think GConf lets us have a really excellent solution in this area,
> if we can get it all working, so it could give us an edge.
> 
> The guys at ALS suggested that it would be a good idea for hackers to
> set up a cheap $200 remote terminal box just so we'll notice when
> stuff breaks. It's cheap, it's handy to keep your web browser open on
> anyway, and if we aren't trying to use GNOME this way we won't notice
> if it doesn't work.
> 
> Havoc
> _______________________________________________
> gnome-hackers mailing list
> gnome-hackers gnome org
> http://mail.gnome.org/mailman/listinfo/gnome-hackers
> 

Oddly not trimming quotes,
Greg Merchan