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([EMAIL PROTECTED] , 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
