Greetings fellow Slackers!

To help me migrate fully to Slackware-KDE and avoid the frustrations of multi-booting, I plan to soon connect two computers with a cross-over cable.

I intend to install ICS/NAT, Samba, and NFS. Box 2 will provide my dial-up (ugh!) internet connection for both boxes. So far so good but as I possess only one decent monitor. I therefore want to install VNC and control Box 1 from Box 2. Additionally, I prefer to reduce desktop clutter with only one keyboard, mouse, and monitor.

Box 1 will be the VNC server (whether in Windows or Slackware) and Box 2 the VNC client. My initial challenge is I have no experience with VNC. Therefore I am concerned about performance with these two aging boxes.

Box 1:
400 MHz K6-III+
66 MHz FSB
40 GB hard drive
256 MB of RAM, not expandable
First generation 3D card, 4MB of RAM
1280 x 1024 resolution
100 Mb/s NIC
Multi-boot with Windows and Slackware 10.x-KDE

Box 2:
350 MHz PII-ECC (Deschutes---possible overclock candidate)
100 MHz FSB
40 GB hard drive
256 MB of RAM, expandable to 768 MB
First generation AGP card, 16 MB of SGRAM
1280 x 1024 resolution
100 Mb/s NIC
Slackware 10.x-KDE only

Monitor:
17" Samsung SyncMaster 712N (very pleased with this monitor)

1. How much RAM should I consider in Box 2 if I intend to VNC with Box 1? Is 256 MB sufficient or will more help? I probably will run Box 2 with 2 to 3 virtual desktops with one desktop dedicated to VNC.

2. Currently I have good video response and I'm content with my Slackware-KDE performance. But are my aging video cards sufficient to handle the additional requirements of VNC?

3. Will I be able to continue running Box 1 (VNC server) at 1280 x 1024 resolution? That's a lot of pixels to push. I run the video card in Box 1 with a 15-bit color plane. I deplore the idea of running at a lower resolution and additionally, 1280 x 1024 is the native resolution of my LCD monitor.

If I have calculated correctly, I'm thinking I should be okay at this resolution: 1280 x 1024 x 15 / 1,000,000 = 19.66 Mb (2.46 MB) per screen. At 100 Mb/sec = .197 second transfer time (ideal ). And that is without compression. Please let me know if I mucked this calculation.

4. Using VNC to control both boxes provides a "cool" factor, but would I be better off with a KVM switch? Long ago I used mechanical A/B switch boxes for monitors and printers, but I never have used a modern KVM. Thus, the zero experience factor again. Are KVMs worth the hassle or will my boxes handle VNC just fine?

TIA

I don't see why VNC wouldn't work on those boxes.

If you have some memory lying about then throw it in (make sure its the correct memory for your system).

KVM switches cost money. TightVNC is open source, so you may aswell try VNC before shelling out money on a switch.

I have run a tightVNC client over a broadband internet connection, the client had a S3 Trio3D/2x Graphics card with either 1Mb or 4Mb of memory on it, that could handle VNC fine.

I regularly run VNC over my home network when working on different boxes. Since my laptop has next to no power (specs: http://www.kaear.co.uk/projectdisp.asp?ID=25) and openoffice is pretty slow, I VNC to the main PC to use openoffice. To date, I've not found any network or system limitations (I use two 10/100 wired lans, with an 802.11g bridge) when using VNC. I even have the server installed on my girlfriends PC (a windows box), so I can check her box from whereever I'm sitting!

I wouldn't recommend it for high framerate games, the refresh just isn't fast enough, but I can see no reason why it wouldn't work.

I have a few points to make about VNC and KVM switches. First off, let's cover the KVM side:

* Platform independant. Because they're hardware and require (to the best of my knowledge) no drivers, that are totally platform independant. Anything that uses PS/2 sockets for control and VGA sockets for graphics will work with these things, including embedded devices, SGI workstations, Macs ... the whole lot.
* Direct control. Again, because it's hardware, you're not seeing a packeted, low refresh version of what's on the other screen - you're seeing *the* screen. This means it's exactly the same as plugging the monitor straight in.
* Cost. It's expensive (or more expensive than *free*). If you were running some obscure boxes, or server applications that you didn't want VNC server running on, then it's a must. But it doesn't sound like you're sitting in a farm, so the needs are different.

VNC (windows):

I first came accross VNC when I was working as an IT tech before university, and it was only when i started getting enough PCs to network together that I realised the value of it, at the time I was working on purely windows and the two (Windows / *nix) are subtly different, so I'll address them one at a time.

* The server can be set to run as a service, so it'll be available on boot. However, this will mean if booting fails, or if you use safe mode - it won't work.
* When you connect to the server, you're presented with the same screen as whoever is sitting at the box is seeing - good for troubleshooting.

VNC (linux):

The major difference is in the way the server works. Typically using TightVNC or RealVNC, you'll be presented with a blank screen, much like you logged in yourself. The significance? The session you're viewing is not the same session that whoever is sitting at the box is seeing - useless for troubleshooting, but good for a pseudo-thin client / compressed remote X set up.

* The server can run at startup, not a problem, but configure it carefully - because I have found that it likes to shut itself down when you disconnect.
* The client is pretty much the same as the windows variety, which is nice.
* You *can* view that first session by using a special VNC server (I use this one on a media box downstairs on the telly! http://www.karlrunge.com/x11vnc/) and that functions pretty much like the windows service one does - again, nice for consistency.
* Starting any kind of VNC server at startup is interesting and for me, meant editting the GDM startup script. I use auto-login in run level 4 for the telly-box, so I couldn't say if it's easier for a standard setup.

To go back to your original query: "I am concerned about performance with these two aging boxes."

I can't foresee any problems whatsoever with the performance of VNC - but be aware that you will be running multiple X sessions if you use the usual VNC server, you won't be connecting to the first session, and that will cause loading on your Linux box.

I think I've probably covered most of what you ask in more detail than you need at this stage, but, let's look at your questions and just wrap up:

More RAM is always a good thing. What do you mean by virtual desktops? In KDE, do you mean the little desktop switcher thing? Or do you mean running KDE on VT7, VT8 and VT9?

VNC runs via the network and essential takes lots of screenshots of your running desktop and posts them to the client - your video card on the server won't get used at all. On the client side, it's just 2D work, and you'll be fine with that.

Your network (assuming 10/100) will be more than man enough to deal with this. Other than LAN gaming, it's what networks were made for! \o/

VNC you can get, try and use for free. If it doesn't satisfy your requirements and/or you have some money to burn, then try a KVM. I would say that VNC will probably do exactly what you want, and more =D

Let us know how you get on with the setup and your opinions on the final running system!

Take it easy,
- Piete.

VNC is mostly pointless for linux. Considering being able to use the CLI remotely, as well as run X windows remotely.

Obviously the one usefull thing would be for helping users work on they're own desktop, but I don't got users running linux

The point is that X is extremely inefficient over the Intenet because most X applications use many request/response roundtrips, which wastes a lot of time waiting for responses. VNC and NX offer significant speed improvements (NX is up to 70 times faster than X) since they use compression and eliminate most roundtrips.

Thanks for the response folks. I was optimistic based upon my simple calculation above that I should have no problems, but without VNC experience I was unsure. I'm not into 3D or action games, or videos and those concerns simply do not exist for me. Of course, software compression reduces the information chunk size that must be transmitted so all things considered I expect the transfer times to be faster than what I calculated above.

My primary transitional need to is to be able to use Word 97 until I can migrate many of those templates and macros to OpenOffice Writer. I've been through that kind of project twice before and the task is hardly insignificant. I've experimented a lot with running Word 97 on WINE, but there are too many nuances for me and I'd rather use Word natively.

One caveat with this VNC idea struck me today, however. During the early transition period when I am still dependent upon Windows and Word for my production work there might be times when I need that box running without the second box through which VNC normally would provide my access. Or, because my second box will be somewhat experimental in the early stages of this migration, I might fubar the box and need old faithful to get online. Thus, in that case a KVM might be the better way to go although I certainly like the "cool" factor of using VNC to connect both boxes. Therefore I probably will go with both options. An inexpensive KVM always lets me into either box without physically rerouting cables.

Based upon my gut feeling and the recommendations above, I'll look for some inexpensive RAM to bump the second box to more than 256 MB.

Yes, I'm referring to the KDE virtual desktops, not individual login sessions (as they are called in /KDE).

I intend to maintain a journal of this entire project. When or where I'll post that journal remains to be seen!

Of course, KnightHawk has something of a valid point: you don't have to use a desktop to be able to administer your PC - that's a Windowism - you can just as easily ssh into any of your linux boxes from linux or windows (take a look at the PuTTy project) and work from a command line. Especially if all your doing is using it as a firewall (it's a nice application of linux, actually), a filestore, an HTTP/FTP server, and so on.

VNC doesn't quite work like that. You'll find that each VNC server starts up it's own "login session", effectively, since it'll be running KDE on the virtual terminals (VT7, VT8, etc). You'll see what I mean when you start playing with it =)

Only being able to use one monitor while messing with it all is a bit of a drawback, I agree. You may be better sorting out a migration plan and just migrating than messing around with little steps (it depends how critical this kind of thing is, I suppose). Alternatively, you may be able to get away with putting the boxes physically close together during a migration period, and if it all goes horribly wrong - just move the cables over =)

Take care,
- Piete.

PS: Tried a generic blog site for journalling? It's pretty compelling to get the network sorted quickly with that kind of pressure

You can also set it to remove the native display

I thought I'd post a follow-up to this somewhat old thread. As can be surmised from my posts here, I've been quite busy with a lot of things getting my two-box network running. Samba kicked my butt, but I'll share that story at my web site (in progress and hope to post soon). Regardless, yesterday I decided to finally give VNC a whirl now that so many other aspects of this project were under the carpet.

In my NT4 box I installed TightVNC 1.29. This guy understands installations. A simple zip file. No system files, no registry bullsh-t.

I ran the TightVNC server and added a password.

With my KVM I toggled to my Slack 10.2 box using KDE 3.4.3. I ran the KRDC Remote Desktop Connection Tool (K-Menu->Internet->Remote Desktop Connection). I added the box name for my NT4 session and selected OK. And just like that I was controlling my NT4 box. Total time invested by me: about 2 minutes. If only everything could be so easy to install. My hat's off to the TightVNC and KDE developers!

Some questions I haven't yet found answers:

1. The mouse pointer sometimes has a small square or the text-mode "I-beam" at the tip. How do I stop this?

2. The KRDC tool bar remains fixed at the top of the screen. Mildly distracting. Is there a way to embed the KRDC toolbar into the Kicker Task Bar?

3. I'm hoping this is obvious and I simply am missing the info somewhere, but how do I configure KRDC, or TightVNC to function password-less, or embed the password somewhere like Samba does with the credentials file option?

4. Screen response time is not the greatest. After some preliminary tests with file transfer speeds, I suspect I need to tweak NT4 and not Slack. Using Samba, from the command line I copied the 10.2 CD-2 ISO image from my Slack box to my NT4 box. The ifconfig command showed a clean transfer with no errors or collisions. Using the time command I calculated 4.67 MBps (37.35 Mbps) transfer speed. Seems slow for two 100Mbps full duplex cards. Any thoughts on what I might be able to tweak to improve network speed?

As always thanks again.

3) I don't know about Remote Desktop Connection, but using vncviewer you can specify a password file to be read from a file generated using vncpasswd, that can be used to authentificate. See vncviewer's man page.

Okay. I have only tried the KDE RDC. I have not installed the TightVNC viewer. I'll add that to my to-do list and see if I like the differences.