Plus, I’m Finally Remembering To Use Capital Letters With My Subject Titles Again!

For those not in the know, or haven’t been paying attention around here, I’m not a big fan of using Windows on a personal basis.  I have no problems recommending it in corporate environments or for friends; I just don’t like having to stare at it on my own machines after working on it 40+ hours a week.  So, a couple of years ago, I threw in an Ubuntu CD and never looked back.

Never, that is, until Hardy Heron, the latest version.  Suddenly, I was tripped in “Evolution of an Ubuntu User” mode, and I wanted out.  Unfortunately, most of the problems I was experiencing dealt with products that other distributions were starting to include, so, at least as far as Linux was concerned, I was feeling a little stuck.  Some of the problems I had included:

• Copy/Paste didn’t work on the Terminal Server Client.  Guess what?  It’s a known bug.
• If I closed my laptop and opened the lid while the power was on, the screen would remain blank.  Guess what?  It’s also a known bug.
• VMWare won’t install due to an incompatible kernel version.  Great. Thank goodness Linus can change the API between kernel 2.6.19 and 2.6.24.  I’d hate to think that a product with incremental minor version numbers actually has, y’know, a stable API. Hell, let’s change function names on the fly!  It’ll be fun!

This state of affairs continued for the better part of three months.  I was getting frustrated, tired, and just generally sick of it.  I was even flirting with trying a BSD… heck, I still might.  At least their upgrade process is almost sane, in that they actually have a semi-stable kernel API, among other things.  Besides, the more I read the Linux Hater’s Blog, the more I agree with it - there some profoundly stupid things going on with Linux, and most of that is by design.

The good news, though, is that I did find some fixes to two out of my three problems:

1. I fixed Copy/Paste by turning off Compiz.  I didn’t like the eye candy anyways.  Of course, why Ubuntu felt it was necessary to turn on, by default, something that is at version 0.5.2, I don’t know.  But, it stopped mucking about with my X server, which meant that rdesktop had access to my clipboad again.  Huzzah!

   (For those of you keeping track at home, you can turn off Compiz by going to System->Preferences->Appearance->Visual Effects->None.  Then, restart; it’ll turn off the effects but Compiz still kind of runs in the background unless you restart your computer.)

2. Sadly, Compiz was not the cause of my laptop’s malfeasance whenever I closed it.  So, I looked around and discovered that Ubuntu’s hardware manager was giving me old Nvidia drivers (169.something).  Maybe that has something to do with it?  With a little searching, I discovered EnvyNG, which allows me to install Nvidia drivers in a halfway sane manner (i.e. without having to recompile the stupid thing whenever Ubuntu decides my kernel needs to be updated - this happens frequently).  It updated my drivers, I restarted… and now I have my laptop back!  It closes!  It opens!  I’m happy!  Even CTRL-ALT-F1 through F6 work!  Happy days!

Of course, VMWare still doesn’t work, which means I can’t even manage VMWare machines with my laptop unless I start learning about remoting into applications via X.  That said, anything with instructions like these should probably be shunned without prejudice…

Our computer is known to the outside as light, and we’re in domain uni.verse. If we’re running a normal X server, the display is known as light.uni.verse:0. We want to run the drawing program xfig on a remote computer, called dark.matt.er, and display its output here on light.

Suppose you have already telnetted into the remote computer, dark.matt.er.

If you have csh running on the remote computer:

dark% setenv DISPLAY light.uni.verse:0
dark% xfig &

or alternatively:

dark% xfig -display light.uni.verse:0 &

If you have sh running on the remote computer:

dark$ DISPLAY=light.uni.verse:0
dark$ export DISPLAY
dark$ xfig &

or, alternatively:

dark$ DISPLAY=light.uni.verse:0 xfig &

or, of course, also:

dark$ xfig -display light.uni.verse:0 &

It seems that some versions of telnet automatically transport the DISPLAY variable to the remote host. If you have one of those, you’re lucky, and you don’t have to set it by hand. If not, most versions of telnet do transport the TERM environment variable; with some judicious hacking it is possible to piggyback the DISPLAY variable on to the TERM variable.

You have got to be kidding me.  Ugh.  Of course, that writeup was written in 2001, so things have certainly improved since then (NOTE:  Don’t think about what Citrix was doing with Windows 2000, nor that Microsoft had a working Terminal Server implementation by then!).  I’ll have to look at that later.

Oh, and, no, VNC is not a solution.  Stop that.

Trackback URI | Comments RSS