Friday, December 30, 2005

How I Spent My Christmas Vacation

Well, we went to Christmas Eve service, called Mom and lil'bro, opened presents under the tree, had friends over, oh, I see, this is supposed to be how I spent Christmas with my computer.

That's right, Dave. What have we been doing?

Well, since I've been home most of this week I've had plenty of chances to hack around on the computer. Most of this has been looking for new games I can play on a Linux box, like Penguin Planet Racer, né Tux Racer. I've also mined Tech Blogs for scripts, and even set up my own online software repository, which currently has one (count 'em - 1) script.

But mainly, I went looking for games and other add-ons.

So yesterday I did a Google™ search on "Linux Games" and was led to John Murray's Homepage. Not the John Murray from my hometown, this one's Aussie. His page has a collection of Linux links. One was a proprietary pinball game that I couldn't get to work. But another was a link to a bunch of fancy new screen savers, all of which run under xscreensaver.

If you don't know about xscreensaver, you haven't been running Linux very long. It's a screen saver program, as you might expect, which starts up when your keyboard and/or mouse have been idle for a preset amount of time. It then starts up, putting up weird images on your screen. Unlike most screen savers in the Windows world, however, xscreensaver can do different things at different times. Currently, my copy has 250 programs. When I'm off the computer for a bit, one of them, chosen randomly, starts up. I can, of course, edit the list of allowed programs (using what's called xscreensaver-demo for some reason). And, also of course, I can change the time xscreensaver waits before it starts, how long it displays a given screensaver, and when (or if) it locks up my keyboard so that outsiders can't see my account without my password.

But wait, there's more! Other people have added screensavers for xscreensaver. And that's what today's post is about.

Warning!! Long, geeky post follows!! You have been warned!!

As I said, I found a page of neat screensavers. Now this is a SourceForge project, so it's easy to go there and get the source, right? But then you have to download Source, Textures, and Sounds, either separately or all together, and then figure out how to put them together. Complicated. Better to let someone else do the work. So let's follow Murray's suggestion and search RPMfind for rss_glx packages. There aren't any for Fedora Core, but there are several for Mandriva. Let's try that, first downloading the latest binary RPM, rss_glx-0.7.6-1mdk.i586.rpm.

Try a standard install:

$ sudo rpm -ivh rss_glx-0.7.6-1mdk.i586.rpm
Password: xxxxxxxxxx
error: Failed dependencies:
        libMagick-5.5.7.so.0 is needed by rss_glx-0.7.6-1mdk.i586
        libopenal.so.0 is needed by rss_glx-0.7.6-1mdk.i586

Not terribly unexpected, this is a Fedora machine, after all. It's a bit worrisome that my yum repositories don't seem to know about libMagick and libopenal, but maybe in Fedora they're given different package names.

So go back to RPMfind and download the equivalent source RPM, rss_glx-0.7.6-1mdk.src.rpm. Move it into the ~/rpmbuild/SRPMS directory, and try to install it there:

$ sudo rpmbuild --rebuild rss_glx-0.7.6-1mdk.src.rpm 
Password:xxxxxxxxxx
error: Failed build dependencies:
        libMesaGLU1-devel is needed by rss_glx-0.7.6-1mdk.i386
        libopenal-devel is needed by rss_glx-0.7.6-1mdk.i386
        libMesaglut-devel is needed by rss_glx-0.7.6-1mdk.i386
        libMagick-devel >= 5.5.7 is needed by rss_glx-0.7.6-1mdk.i386

OK, lots of stuff missing. And no good idea as to where to find it. The only reference I find to Mesa or GLU under Fedora is as part of the xorg-x11 distribution, which makes sense, actually. But it would appear that Mandriva and Fedora use different package names, and I don't want to deal with that right now.

What to do? I still don't want to go back to the source, if I can avoid it, as I might not get everything installed the right way. But wait! I have the source code right here, in the src.rpm package. Let's yank it out.

The easiest way to do this is to use fedora-extract, a little script which will pull apart any archive file:

$ fedora-extract rss_glx-0.7.6-1mdk.src.rpm 
rss_glx-0.7.6-1mdk/rss-glx_0.7.6.tar.bz2
rss_glx-0.7.6-1mdk/rss_glx.spec
$ cd rss_glx-0.7.6-1mdk
$ ls -l
total 4892
-rw-r--r--  1 local local 4978215 Aug 29  2003 rss-glx_0.7.6.tar.bz2
-rw-r--r--  1 local local    6346 Aug 29  2003 rss_glx.spec

At this point we could, I suppose, look through the spec file and see what we're supposed to be doing. Mostly it just sets up some default directories, though. So let's just yank out the source and do it ourselves.

$ tar xjf rss-glx_0.7.6.tar.bz2
$ ls -l
total 4900
drwxr-xr-x  8 local local    4096 Aug 28  2003 rss-glx_0.7.6
-rw-r--r--  1 local local 4978215 Aug 29  2003 rss-glx_0.7.6.tar.bz2
-rw-r--r--  1 local local    6346 Aug 29  2003 rss_glx.spec
$ cd rss-glx_0.7.6
$ ls
aclocal.m4   configure.in  Makefile.am    other_src            stamp-h.in
AUTHORS      COPYING       Makefile.in    README               utils
autogen.sh   depcomp       missing        README.xscreensaver
ChangeLog    include       mkinstalldirs  reallyslick
config.h.in  INSTALL       NEWS           src
configure    install-sh    oglc_src       stamp-h

Good, there's a configure file. Examining it says that it defaults to /usr/local for storage, and that's good enough.

$ ./configure
[Lots of lines deleted -- no errors on my system]

It does, however, give the messages

checking AL/al.h usability... no
checking AL/al.h presence... no
checking for AL/al.h... no
Hrm, maybe AL/al.h is in /usr/local/include
checking AL/al.h usability... no
checking AL/al.h presence... no
checking for AL/al.h... no

Which I'm guessing have something to do with the missing libopenal library. I see that Murray had the same problem. A quick search shows that OpenAL is a portable library for 3D spatialized audio. OK, I don't really want audio in my screensaver, thank you very much. Let's just leave this out.

OK, now compile the stuff:

$ make
[Takes a while, no error messages I can see.]

Then we use the handy checkinstall program to create an RPM file:

$ sudo /usr/local/sbin/checkinstall
Password:  xyzzyxyzzy2

checkinstall 1.6.0, Copyright 2002 Felipe Eduardo Sanchez Diaz Duran
           This software is released under the GNU GPL.


The package documentation directory ./doc-pak does not exist. 
Should I create a default set of package docs?  [y]: y

Preparing package documentation...OK

Please choose the packaging method you want to use.
Slackware [S], RPM [R] or Debian [D]? R

Please write a description for the package.
End your description with an empty line or EOF.
>> This is a collection of OpenGL screensavers for xscreensaver. They
require a hardware-accellerated GLX implementation.
You need to add them manually to your ~/.xscreensaver file as described
in README.xscreensaver
http://rss-glx.sourceforge.net/

[I then edited to fields so that finally things look like this:]
This package will be built according to these values: 

1 -  Summary: [ This is a collection of OpenGL screensavers for xscreensaver. They ]
2 -  Name:    [ rss ]
3 -  Version: [ glx_0.7.6 ]
4 -  Release: [ 1 ]
5 -  License: [ GPL ]
6 -  Group:   [ Applications/System ]
7 -  Architecture: [ i386 ]
8 -  Source location: [ rss-glx_0.7.6 ]
9 -  Alternate source location: [ http://rss-glx.sourceforge.net/ ]
10 - Requires: [ xscreensaver-base ]
11 - Provides: [ rss ]

Enter a number to change any of them or press ENTER to continue:
[Lots of output]
**********************************************************************

 Done. The new package has been saved to

 /home/local/rpmbuild/RPMS/i386/rss-glx_0.7.6-1.i386.rpm
 You can install it in your system anytime using: 

      rpm -i rss-glx_0.7.6-1.i386.rpm

**********************************************************************

$ cd /home/local/rpmbuild/RPMS/i386
$ sudo rpm -ivh rss-glx_0.7.6-1.i386.rpm
Preparing...                ########################################### [100%]
   1:rss                    ########################################### [100%]

Now, however, we need to look at the file /usr/doc/rss-glx_0.7.6/README.xscreensaver, which tells you to run /usr/local/bin/rss-glx_install.pl, which will update your personal xscreensaver installation. A properly constructed RPM file would do this automatically, but this isn't a properly constructed RPM, so there. Once the script is run, you can play around with xscreensaver-demo to see which of the new programs works on your computer. Like Murray, I couldn't get Skyrocket to work, but I'm not going to worry about that now. I can probably fix it by installing libopenal, but, as I said, I don't really need a noisy screen saver. I just unchecked the box that tells xscreensaver to run Skyrocket. The rest of the new screensavers work.

OK, that's a long, geeky post, but I wanted to document all of the steps in a software install, just this once. Next time I'll just refer you back here, OK?

Note added in proof: While I was posting all this, I'd left xscreensaver-demo running, positioned on the Skyrocket program. After I posted the original message, I remembered demo was still running. When I went to click it off, I saw that Skyrocket was, in fact, working. Without sound, of course. So I've put it back into the rotation for xscreensaver.

Tuesday, December 27, 2005

Homegrown Software

Techn0manc3r has a nice little fortuneteller script that pops up a fortune onto your X11 desktop. The script uses Tcl/Tk, in particular the wish program, which Fedora supplies in the Tk RPM package.

He also has a Wallpaper Setter for changing backgrounds. This inspired me to post one I've written, setbg, a small Perl script that allows you to randomly change the wallpaper at random times. I wrote up a general software page for this, hopefully I'll add some more stuff in the future.

Saturday, December 24, 2005

After All That Work

After installing Tux Racer from an old src.rpm, I ran yum update to check the status of my other RPMs. (In particular, I wanted to see if Firefox 1.5 had moved from the Fedora Core development tree. It hadn't.) I was then told that yum was going to replace Tux Racer with Penguin Planet Racer. This is a newer Open Source version of Tux. Apparently the original Tux went from Open Source to commercial, so this is what's left behind. It's pretty much the same game, of course.

For those playing along with yum, make sure you have the Fedora Extras repository enabled, then do

yum install ppracer

wish someone would have told me that.

Keep Your Feathers Oiled
    and Your Beak Down

Rather than work this Christmas Eve Morn, I decided to get Tux Racer running on the Windows machine. If you've never seen it, Tux is a penguin who loves to slide down slippery slopes collecting herring on the way. You get points for quick runs and the number of fish you grab. You can race down various slopes, compete for different "Cups," and download other courses, and design your own course. There's even a Windows version available, as well as one for the Mac, which I've yet to try. You can get them through links on the Tux Racer download page.

Tux used to be available on with the Fedora Core 3 distribution, but it was dropped from FC4 for reasons of space, I guess. The "recommended" way of getting Tux to run under Linux is to install from source. I tried that, using the usual tar -xvf; ./configure ; make ; make install procedure, but that failed at the ./configure stage with the message

configure: error: Your copy of glx.h is out of date. You can get a more recent copy from the latest Mesa distribution (http://mesa3d.sourceforge.net).

I tried to Google for a solution, but didn't find anything that would help much, except for digging out a copy of /usr/include/GL/glx.h from another Mesa distribution and trying that. That seemed rather too much work for a Saturday morning, especially on Christmas Eve.

Then I remembered that Tux Racer was in the Fedora Core 3 distribution. A quick search of rpm.pbone.net found several locations for tuxracer-0.61-28.src.rpm, the Fedora Core 3 source RPM for Tux. Hopefully this would have whatever fixes were needed to get Tux to race under FC4.

From then on we follow the standard method for building RPM files from source RPMs.

  1. cp tuxracer-0.61-28.src.rpm $HOME/rpmbuild/SRPMS
  2. $ cd $HOME/rpmbuild/SRPMS
  3. $ sudo rpmbuild --rebuild tuxracer-0.61-28.src.rpm
  4. Wait a bit. There are lots of warning messages, but nothing stops. (You may have to install some other packages to get to this point, but they are all in the FC4 distribution, I think.)
  5. $ cd ../RPMS/i386/
  6. $ sudo rpm -ivh tuxracer-0.61-28.i386.rpm
  7. $ rehash
  8. $ tuxracer

And now you should be gliding down the mountain.

Wednesday, December 21, 2005

It Happens Every Christmas

Your friends, real, virtual, and imaginary, fill your email with heartfelt thoughts, cute cards, and amazing animations, all celebrating the holiday.

This isn't one of those:

A BK Holiday

Sunday, December 18, 2005

      This Week's Sign That The
          Apocalypse Is Upon Us
(And I Really Mean It This Time)

"Festive" gold and silver garnish.

Yes, you eat it.

Saturday, December 17, 2005

Delete Windows?
(Yes/No/[HELL YES!])

I'm going to do something I've never done before, and probably never do again: recommend a book I have no intention of reading, much less buying.

The book is Just Say No to Microsoft: How to Ditch Microsoft and Why It's Not as Hard as You Think, by Tony Bove, "Writer, producer, market-messaging consultant, musician, and book author." (His words, and his link to Amazon. The man is nothing if not commercial.)

I'm recommending the book because of a Washington Post webchat, Bove's page Get Off Microsoft, and his Get Off Microsoft Blog, now listed in the sidebar. All have useful information on ways to do things with a computer that don't involve bowing in the general direction of Redmond. There's a lot on Linux alternatives, but just as much on Macs, and he's not adverse to recommending Open Source or other non-MS software on Windows machines.

So why won't I read it? Well, if it showed up under the Christmas tree (Kids: this is not a hint) I'd read it, but I know most of the stuff in the book, so I don't need to buy it for myself. My bosses are Mac-centric and Linux friendly, so I don't need to convince them.

I guess it would be a good stocking stuffer for friends using Windows, except the only friends that would appreciate it are fellow geeks, and geeks who use Windows aren't really geeks.

So I'll just recommend it to the 50+ per cent of you that read this blog and still, for whatever reason, use Windows.

There's an alternative!

Thursday, December 15, 2005

Making FVWM an Option

A correspondent (we now have correspondents, aka people who write us) sent us a link to FVWM Crystal, a set of tweaks and addons to enhance the FVWM Window Manager.

I'm not going to be using it soon, it looks rather bulky, and one of the reasons for using FVWM was the fact that it is relatively lightweight when compared to Gnome and KDE. (The other reason was the large virtual desktop, mine is 9 times larger than the screen, and I can pan anywhere on it with the mouse.) However, Correspondent also mentioned that FVWM-Crystal contained a file which made FVWM show up on the GDM (and KDM, presumably) window manager login screen.

This has been an irritant. In a default Fedora Core 4 setup, when you turn on the computer there's a splash screen which has a box for your username and password. Down at the lower left there's an entry called, I think Session. The options inside Session are, by default, Gnome, KDE, Last Session, and Default.

If you install FVWM from source, as I've done (or use a home-rolled RPM file) it doesn't show up on the login screen. To get FVWM to launch when you log in you need to create a .xsession file in your home directory which contains the line

/usr/bin/fvwm

if that's the location of your FVWM executable. This is the "default" option on the Session menu.

That's not too hard for me to figure out, but suppose I want some other user of this machine to have a chance to learn the glories of FVWM? The easiest way to do that is to give them the ability to launch FVWM from the Session menu. That's where the hint from FVWM-Crystal comes in.

The Gnome (GDM) and KDE (KDM) window managers look in the directory /usr/share/xsessions to see what window managers are available. I found the files gnome.desktop and kde.desktop there. Obviously I need to install a fvwm.desktop file. But what goes in it?

FVWM-Crystal comes with a fvwm.desktop file. It's not totally appropriate for my setup, but it provided enough hints to let me construct a version for myself. Mine looks like this:

[Desktop Entry]
Encoding=UTF-8
Type=XSession
Name=FVWM
Comment=F(eeble) Virtual Window Manager:  Lightweight, Fast
Exec=fvwm
Terminal=False
TryExec=fvwm
Type=Application

[Window Manager]
SessionManaged=true

I'm not sure if all of that is necessary or not.

Save this file as /usr/share/xsessions/fvwm.desktop, make it executable ($ chmod 755 /usr/share/xsessions/fvwm.desktop), log out of your Xsession, and look at the Session option on the login screen. FVWM should be available as an option.

Wednesday, December 14, 2005

Cleaning Up the File Installation Mess

Who knew Christmas shopping would be useful?

The other morning I played hooky from work to go Christmas shopping. Don't worry, I took annual leave.

I took a break from my arduous task by getting a coffee at the local Borders. Before I got that, though, I looked around for something to read and found the Jan/06 issue of Linux Journal. I intended to put it back when I left, but it was so useful that I decided to shell out the $5.25 to buy it.

Which brings us to the current topic, an article by Marcel Gangé on cleaning up your $HOME (or other) directory after you've installed a program from a tarball.

So what's the problem? If you're new to Linux, you may have only installed programs from RPM or Debian .deb files, then you might not have encountered a tarball. Heck, if you use yum or apt-get you might never have seen an .rpm or .deb file at all, even though they are there.

Simply put, a tarball is collection of files that will install a program for you on your system. Unfortunately, usually the files are the source code for the program, plus some "hints" (a file called configure and another called makefile, or maybe Imakefile) on how the files are to be compiled. The tarball is a compressed archive file, usually with a name like fineprogram.tar.gz or fineprogram.tgz, the "gz" indicating that everything is compressed with the gzip program.

Now installing from source is a chancy proposition — my current success rate is maybe 90%, but some programs just won't install on my system, probably because I'm missing some key libraries (that's why we have yum and apt-get, to handle these dependencies).

For now, though, let's assume that you've got the program compiled, and even installed (more about that later). You delete the source code directory as a bunch of junk you'll never need again, and run the program happily.

Until one day, you find that the program doesn't really do exactly what you want it to do, and you decide to delete it from your system and replace it by a newer program.

A small problem: The program may have left traces of itself in /usr/bin, /usr/lib, /etc, /usr/share, and maybe /opt, just out of a general sense of perversity. Where are all those files?

Well, if the program was nicely written, you could go back to your source directory and run "make uninstall". This looks for a set of commands in the makefile which remove all of the installed program components.

Unfortunately, you deleted the makefile along with the rest of the source, remember?

Oops.

Now, this post won't tell you how to clean up that mess, but it will tell you one way of preventing the mess from happening.

The secret is a program which Gangé's article talks about extensively: CheckInstall. Basically, the program (available as a tarball, RPM, Slackware, or DEB file) keeps track of where all of the files a tarball installs are, and makes it easy to delete them if you want to. It does this by creating a RPM, DEB, or Slackware Binary file. You install this just like you would a binary file you get from your distributer, and you can delete it the same way.

How does it work? I'm just going to discuss how it works under Fedora, so I'll create an RPM file. I think it works pretty much the same way for Debian and Slackware files, but that's for you to test out.

For an explicit example, let's assume that I want to install the FVWM window manager from source.

That last link should get you a file called fvwm-2.4.19.tar.gz, a tarball with the FVWM source code. Compiling this code is actually fairly easy. You just open up an terminal window, and execute the following commands:

$ tar tvzf fvwm-2.4.19.tar.gz
$ cd fvwm-2.4.19
$ ./configure
$ make
$ sudo make install
$ cd ..
$ rm -fr fvwm-2.4.19

What's all that do? Let's go through it line by line:

  1. $ tar tvzf fvwm-2.4.19.tar.gz uncompresses the tarball. This creates a directory named fvwm-2.4.19 and puts all the files you need into it.
  2. $ cd fvwm-2.4.19 goes into that directory.
  3. $ ./configure runs a program which searches your machine and decides if you have all the libraries you need to compile and run fvwm. If you do, it will create a makefile which has the locations of all the files you need to run the program, plus appropriate compiler flags.
  4. $ make executes the makefile. Typically this will take minutes to hours, as all the components of your system are compiled. If it's successful, then
  5. $ sudo make install will put all of the program bits where they belong. You need the sudo if you want to install the program in /usr or /usr/local, or someplace else that's owned by the superuser.
  6. $ cd .. returns you to the directory above fvwm-2.4.19.
  7. $ rm -fr fvwm-2.4.19 deletes the source code.

What does CheckInstall do? It gets rid of the "make install" step. Basically, you run the following commands:

$ tar tvzf fvwm-2.4.19.tar.gz
$ cd fvwm-2.4.19
$ ./configure
$ make
$ sudo "/usr/local/sbin/checkinstall"
$ sudo rpm -i /usr/src/redhat/RPMS/i386/fvwm-2.4.19-1.i386.rpm
$ cd ..
$ rm -fr fvwm-2.4.19

The process is pretty self-explanatory. You can give the default answers to all of the questions, tell the code to create an RPM file, and it will tell you that it has created an RPM file in the location /usr/src/redhat/RPMS/i386/fvwm-2.4.19-1.i386.rpm or wherever. The exact name and location depends on the installation. (All these "su" and "sudo"s will require the appropriate passwords, by the way.)

So what's the big deal? The RPM file installation process knows where all the files belonging to fvwm-2.4.19 went on install. Thus, if you later decide you don't want to use FVWM as your window manager,

sudo rpm -e fvwm removes the program from your system, along with all of the auxiliary files it installed.

Now, a word of warning: this is not a real RPM file. "Real" RPM files have dependency information in them. What's that? Well, say that FVWM depends upon a library called "libfoo". If for some reason I remove the "libfoo" RPM from the system, a "real" RPM installation would tell me that this is going to break FVWM. However, here the RPM isn't connected to "libfoo" so far as your RPM system knows, so it won't warn you. Also, you probably can't pass this RPM off to a friend with any hope of him getting it to run on his system: he's better off trying to compile the code himself.

However, it does make file installation and cleanup a lot neater, and so is extremely usefull.

And well worth the $5.25 for the magazine.

Saturday, December 10, 2005

In Case of My Untimely Demise

You've met our cats ( here, too).

The white one has it in for me. If I shuffle off of this mortal coil under suspicious circumstances, he did it.

Follow:

We've had these cats since before we moved to the current house. In the old house, they were well behaved. That is, they never got in anyone's way as we walked around the house.

The old house was a large Levitt Cape Cod with a finished second floor. To go from upstairs to downstairs you went from a bedroom or the bathroom into a small alcove, and then proceeded down the stairs. The walls of the alcove were close-in, so you could always catch yourself if you tripped at the top of the steps. A cat in front of you had just better get out of the way.

Our new house is a "raised ranch," with the stairs out in the middle of the living room. If you trip, there's little to stop you except for a banister which is possibly made out of something resembling wood. The cat immediately saw his chance.

When I head down the steps, the white one likes to follow — well, not exactly follow. He starts from behind me, true, but he then runs in front of me. Very close in front of me, so that I have to stop. The more I'm carrying, the finer he cuts it — for laundry he gets within a foot, if I'm holding a computer he gets within six inches or so.

Today, I was heading down the stairs. As I came off the landing, I instinctively stopped, one foot in midair, waiting for the cat to come by.

He wasn't there. I almost lost my balance and crashed through the front door at the bottom of the stairs.

He's trying to kill me.

Sunday, December 04, 2005

An Explanation for the
Whole Frakin' Universe

   


Click on the picture to advance to the next frame.

Or click here for the full screen version.

Saturday, December 03, 2005

Another Unpatched IE Flaw

If. for some reason, you are one of the 30% of the people reading this blog who still use Internet Explorer, you might want to look at this: Microsoft Issues Warning About Unpatched IE Flaw. No, it's not deja vu all over again, it's another bug:

The company said users browsing the Web with IE could infect their computers with a Trojan horse if they visit certain Web sites that are known to be exploiting the flaw, though it didn't specify what those sites are.

Why do I, a semi-known Linux user and closet Mac freak, keep telling you about Windows and IE bugs? Because they affect non-Windows users as well (read the comment by the weasel), and this, from The Register:

Consider an analogy on the size of modern malicious code: if Windows XP were the size of the Empire State Building, then the little barking Beagle virus - the size of a small dog - can come in through the front door, lift its leg, deliver its payload, and somehow cause the entire building to come crumbling down. Or, Beagle can simply hold the door open automatically, so that a large cement truck can drive in and deliver its mystery payload to the base of the operating system as required.

Oh, and if you are an IE user looking for an alternative, Firefox version 1.5 is out.