Re: Thin-X-Client-Laptop
On Wed, Jul 11, 2001 at 03:20:26PM -0700, Tony Godshall wrote:
> On Wed, Jul 11, 2001 at 05:01:36PM -0300, Peter Cordes wrote:
> > On Wed, Jul 11, 2001 at 12:27:05PM +0200, Schoppitsch Dieter wrote:
> > > Hi,
> > >
> > > I want to run X-Applications on my (old) laptop (486; Debian 2.0) while connected (via PLIP) to the Server (Pentium, Suse 7.1).
> > >
> > > On the laptop I installed the X-server - that means - I am able to move the mouse-cursor on the screen only (no menues, no window).
> > > On the server I installed the whole X-stuff (KDE, applications).
> >
> > You might want a less graphics-heavy window manager, since KDE makes
> > the X server work harder than e.g. WindowMaker or AfterStep. I use
> > uwm or fvwm2 myself.
>
> I second that. Gnome and KDE made my OB800 (P166, 48MB RAM)
> run like a dog, but it is slick under blackbox or flwm.
>
> I've also found the vncserver/vncviewer combo to be very useful
> in this context: even the window manager runs on the server,
> so the laptop load is very thin indeed.
Why is that better than using the X protocol to run the window
manager on the remote/fast machine, like both sets of instructions
already posted would accomplish? If your WM is a resource hog, you
definitely want to run it on the fast machine. I suggested running it
locally for better performance, but running DISPLAY=laptop:0 start-kde
(or whatever the command is) on the fast machine will do all the work
except drawing on the screen using the fast machine.
> And it protects you
> from laptop glitches (have to reboot that old laptop, no
> problem; just reconnect to the vnc session after.
Ok, that's a small advantage.
> The other
> day I started an email (in mutt) in a vnc session on my
> fiance's computer, then had to go eat, then came back and
> continued it on my laptop in my7 living room, and finished
> it off the next day from the office. That's cool.
And is also easy, no matter what you're using. Just save the message
and exit the editor, and tell mutt you don't want to send it. It will
ask you if you want to keep it, and if you say yes, it will ask you
later if you want to recall saved messages. Almost all mailers
support resuming composition later.
> And one
> of the machines was a Windoze box!
PuTTY is all you need on the 'doze side, at least if you are used to
the command line. (Without a handy 'nix machine, you need cygwin, and
maybe XFree86-win32 (see sourceware.redhat.com. I haven't tried it, but
it would be great if it was nicer than the demo versions of some
commercial X servers.)).
> (The debian package is
> made from the AT&T sources BTW, and doesn't include the
> tightvnc.org patch, so it is kind of slow over ssh over
> DSL/cable modem but is fine over 10M or 100Mbps ethernet.
>
> > > In textmode I am able to ping and telnet the server.
> >
> > Use ssh. It's a good idea to get in the habit of _always_ using ssh
> > instead of telnet, even when the extra security isn't needed. A 486
> > is fast enough for login sessions, if not file copying and forwarding
> > X connections over ssh.
>
Let me add: disable telnet access to all your computers. There is
no reason to ever use telnet. ssh clients are available for all
common and not so common computer systems (any unix, win, mac (using
niftytelnet+ssh), vms, probably others.) There are reasons to keep
using FTP, since it is more convenient in some cases. I have never
seen a case where telnet was more convenient than ssh. (BTW, netcat
does a better job than the telnet client for random poking around at
TCP ports that aren't using the telnet protocol, so you can trash it
too.)
Err, ok, I thought of one. My local library allows telnet access to
the catalog and some services. They probably service a lot of
connections at once, so all that encrypting might take up some CPU
time. Also, requiring people to get ssh when they could use the
telnet client that came with their system would make things less
convenient for the casual user.
I still think that telnet should never be used for interactive logins
to a shell. MUDs and catalogs and stuff are different.
> Again, second that. I use ssh with -c blowfish and it is
> plenty fast on even my old P166.
Me too. BTW, you should put Cipher blowfish in
/etc/ssh/ssh_config, so you don't have to type it all the time.
> And I transfer files with
> rsync -e ssh instead of ftp.
Or just scp, for single files. It has a -r option. If you're used
to rsync, then there's no need to learn to use scp, I guess.
> > > What do I have to do now? - as I am a beginner in Linux please send me 'foolproof`' instructions and hints.
>
> Easier said than done ;)
Yeah, really :) There's a lot of gotchas waiting to get you. It's
pretty easy if you know how everything works, since this is the kind
of thing the X window system is good at, and was designed to be able
to do. If not, you'll be tearing your hair out until you understand
how xauth and xhost work, and how the window manager interacts with
the X server, and how the DISPLAY environment variable works, and some
other stuff that haven't leapt to mind. ;)
If you understand _how_ this stuff works, it will make sense, I can
assure you. This understanding requires at least some kind of
understanding of TCP connections. I find understanding stuff like
this is easier when you approach it by thinking from the perspective
of the software designer, since for one thing it probably made sense
to the people who made it up. Also, you can see why a lot of stuff is
the way it is, especially in Unix, by thinking about what would be a
good way to accomplish whatever task.
If you're not up to understanding it, or you don't have time, you can
probably find yourself a cookbook solution for yourself. One of
Unix's problems is that cookbook solutions are terribly non-obvious
and don't make much sense to those using them. Besides that, they are
prone to breakage under conditions that only someone who understands
the whole system could predict. The Unix-haters web site has many
great examples of this:
http://catalog.com/hopkins/unix-haters/handbook.html
If you find that X is giving you grief, maybe you can take comfort in
knowing that you're not alone, and that at least you're not trying to
run it on a Unix workstation with less power than your 486 laptop:
http://catalog.com/hopkins/unix-haters/x-windows/disaster.html
There are a couple good rants in there about xauth, etc.
We are fortunate that the Free software world has settled on XFree86,
so common extensions are used by lots of programs without trouble,
unlike during the time when th X disaster page was written. Anyway, X
is still very far from perfect.
> Sorry to say it, but you gotta
> read a lot to get all this stuff figgered out and treat all
> the "foolproof" instructions people give you with a certain
> amount of skepticism. After all, we are all learning and we
> all tend to forget certain details (they become assumptions)
> as we move on. Try the howtos (e.g. /usr/doc/HOWTO/ if you
> have them installed or http://www.linuxdoc.org/HOWTO/ -
> they've been through a peer review process that's a lot more
> thorough than what you get on a mailling list).
>
> > Log in to the fast machine, and run
> > DISPLAY=laptop:0 xterm &
>
> Uh, I don't think this will work. You need some kind of X magic
> authorization cookie or something. IIRC you can maybe
> transfer the ~/.Xauthority file or use xauth so the other
> machine/user has permission to use your X display. Suggest
> you check man xauth and/or XFree86-HOWTO and/or Thinclient-HOWTO .
It depends on how you started the X server. If you ran X on the
console, xauth stuff won't be on. In that case, I forgot to mention
that you will have to use xhost +fast-machine to allow X connections
from it. Sorry for the omission. If you used startx, then it will
have set up xauth, so you should locally (on the laptop) run xauth
list, then paste the laptop:0 line onto the end of an xauth add on
the fast machine. Using startx will start whatever local window
manager you have installed, so you'll want to do something about that.
If you just start the server as X, without using xinit or startx,
xrdb etc. won't get run.
--
#define X(x,y) x##y
Peter Cordes ; e-mail: X(peter@llama.nslug. , ns.ca)
"The gods confound the man who first found out how to distinguish the hours!
Confound him, too, who in this place set up a sundial, to cut and hack
my day so wretchedly into small pieces!" -- Plautus, 200 BCE
Reply to: