The Rants, Raves, Gripes, and Prophecies of Paul R. Potts
Contents by Category
Contents by Date
This past weekend I attempted to make a little headway in some of the technical setup for the hobby and learning projects I've been discussing.
First, I brought my PC up to Fedora Core 3. This turned out to be much more painful than necessary; Firefox kept downloading an ISO for the first installation CD that was incomplete: it would silently fail, leaving an incomplete image file. The rest were fine. Strange. I didn't find out until booting it and doing the CD verification. The mirrors were running very slowly, and it took me multiple tries to get a clean ISO. So that was an enormous waste of time.
Despite all that, when I finally got the FC3 installer down, the upgrade proceeded fine. The exception was the patches. There is always an enormous backlog of patches, even for a recent distro; the patch process kept failing, with a variety of baffling error messages about missing RPMs that failed to tell me what went wrong. I finally had to apply the patches in batches (heh), rebooting after each batch; this worked. My 5 gig root and home partitions are strangely full; I need to clean out some build directories. I probably should have made my partitions larger. At some point I might start over on a second drive configured without dual-boot. Which brings me to...
One of the first steps was to make it so that I can keep my PC in Linux all the time, without booting back and forth to Windows 2000 just to run Word, Visio, or Functional Developer. After reading a rave review of the QEMU emulator in the British magazine Linux User, I decided to try it out. I was disappointed. It yields a segfault on startup consistently on FC3. Some other users are reporting the same problem on the forums. One guy with source tried to diagnose the problem with GDB. I don't really know how to use GDB off-hand. He had no luck working out a root cause and patch, so I figured that it was going to be a very time-consuming proposition, and not part of my core goals; I decided to try a different solution for now.
So, Bochs, another emulator mentioned in Linux User. This is ugly. It fails to have sensible default behavior, and uses an ugly configuration file. I got failures loading the VGA ROM image, for no reason I could ascertain. It would work with the demo Linux image, but the default config specifies a PC with 2 megabytes of RAM; that tells you how old it is. The user interface did not look promising, either, so I decided to move on.
I finally settled on downloading a 30-day trial of VMWare. For the most part, this just worked; it has quite slick virtual device drivers. I don't have a floppy drive, and it demands one each time I start the virtual machine. I'm not sure how to disable this; maybe in the virtual machine BIOS? I had a little bit of difficulty getting the VM to talk to my CD-RW drive, but a "legacy mode" checkbox makes it work.
It is not certified to work with Fedora Core 3, and Windows 2000 was unusable in full-screen mode due to drawing problems, but I loved the ability to set a wide variety of display sizes for the virtual video driver, and so could pick one that fit nicely on my 1600x1200 desktop. My biggest difficulties were in setting up a new partition in the uninitialized space on my hard drive to host the PC's disk image. I tried using the version of GNU parted that was on the Red Hat installation and rescue CD: it crashes, and fdisk was missing in action. If you run the installer, you can't get back to the Disk Druid partition editor without doing a complete reinstall. Trying will result in an unintentionally trashed GRUB boot (I use the NT bootloader to choose to load the Linux bootsector as a file; if it doesn't work, instead of the "LI" that happens with a failed LILO boot, you get a screen that says "GRUB" and nothing else. This failure seems to indicate that I need to replace the bootsector file with a new one extracted from the Linux boot volume. Fortunately, this fixed it.
I'm not sure of the name of the text-based, menu-driven partition editing tool I used before, but I don't think partedit was it. I got the latest stable source and built it successfully, although it gave me grief when my shell apparently could not find it. It finally started working, again for no apparent reason, and I was able to tell it that I wanted an ext3 partition and file system. No dice: it tells you that this feature doesn't work. (Then why is it one of the available options?) You have to specify ext2, and then use mkfs or something like that to write the file system, which can be ext3. Sigh. There's also a really ugly bit of user-interface design: you have to specify the partition point using a floating-point number of gigabytes. You specify a number, and it gets rounded, presumably, to the appropriate sector, which is displayed as a different floating-point number. You have to assume it is starting at the next available sector. Accidentally specifying a value that overlaps an existing partition produces a really ugly series of math errors, but then gets set to a legitimate value anyway. It's just bad. Sectors, bytes, etc., on a hard disk have precise integer values, not floating-point numbers of gigabytes; kilobytes, megabytes, and gigabytes are not really base-10 concepts anyway, so what does this even mean? I've no idea, but it is really the wrong way to display these values to the user.
Strangely, my Fedora Core 3 installation still imposes a 2 gigabyte limit on files. That isn't normally a problem, but building a virtual machine's hard disk image involves making a large file. It is not clear to me how to work around this; I tried setting some environment variables, but it didn't help. It is just baffling to me that this is still an issue; I guess that whatever hack-workaround-on-top-of-a-hack-workaround that fixes this limitation in the BIOS or IDE standard or whatever is still not part of the standard build. It seems that in 2005 it ought to be possible to set up a PC which, by default, doesn't have these strange arbitrary limitations (along with the cylinder restriction on the boot sector), but sadly, this hasn't yet happened.
It's also worth mentioning that the aphorism "Linux is free only if your time isn't worth anything" is still true, at least to some extent. I'm considering making the money-for-time tradeoff to buy VMWare, because it mostly Just Worked, where two open-source emulators didn't, and Wine doesn't.
Anyway. You can imagine the number of hours of my free time the above setup took. Without much free time left, I began to embark on attempting to get the jetty Java web server and sisc Scheme tools working.
I ran out of time, but the results were not encouraging. Ant would not compile either of them from source; apparently there is no JDK of any stripe standard in Fedora Core 3; there also seems to be no yum install option for said JDK. It comes with a GNU Java with a different name, and the standard Java is a script that acts as some kind of proxy mechanism. I've been away from Java for a few years, so I don't quite know what is going on with Java on Linux. I naively expected things to be more polished and plug-and-play than they were a few years ago.
There is fortunately a Sun JRE and JDK available as an RPM; I installed this successfully, but am now bogged down in config files. I apparently need to do something to configure the proxy scripts to use the Java that I want it to use, and wound up in a maze of twisty little man pages, all alike.
Anyway, there it stands. I'll see what I can do the next time I have a large chunk of free time. I've obviously been spoiled by the MacOS? X developer tools; everything pretty much just works. I'm also wondering if I made a mistake attempting to rely on Fedora, instead of another distribution like Debian. That's something guess I'll consider later; meanwhile, if I can get by with this configuration, I'll have to decide whether to pay for VMWare.
I'm getting Programmer's Paradise spam offering me special deals on VMWare. I'm quite confident I did not opt in to get junk e-mail when requesting the trial license key. This alone might just piss me off enough to refuse to do business with the VMWare folks -- I get so much junk mail already -- but if I go that route, I'll at least tell them why. Maybe QEMU will get a patch that makes it work with FC3.
While I'm at it, I should mention the source of some strange difficulty I was having building Gwydion Dylan. First, version 2.3.11 of d2c did not handle configuration on Fedora properly. This was because of a regular expression attempting to identify the CPU type, and failing to match. It's just another example of just how ad hoc all that autoconf stuff is. Debugging it is not easy, or at least if it is, I don't know how to do it. You've got to read code and insert print statements, and I'm not sure there's a better way. As a sort of 1.5 problem, apparently FC3 comes with an updated version of the autotools, which yields an endless series of warnings about deprecated quoting, so for some time I thought that this might be the problem. It generates warnings and errors about other programs, not just yours. Really, really ugly. I bought the book on the GNU autotools at one point and tried to get to know them; such a mess of m4, shell scripts, Perl, sed, and other mess does not seem worth becoming expert in unless absolutely necessary, like libtool.
The second problem was a weird error where apparently d2c could not find the GC library version 6. I don't know why it was attempting to load version 6; there isn't one. The real problem was apparently that I mis-installed a binary tarball starting at /usr/local instead of root (/). That was user error, but why this would result in the error I was getting is completely baffling; even if the buried binary d2c was being executed, or a buried library, none of them should have had a reference to a GC version 6. I only found the answer by accident, after days of full Mindy bootstraps and quite a bit of discussion on the #dylan IRC channel, installing a separate binary tarball for the GC library, etc. I try to be as careful as I can, but it is certainly easy to make a mistake like this, when your installation tool is as unhelpful as "tar."
I also made an attempt to see if I could make it easier to add content to my weblog. I tried to write a Ruby program that would talk to my IMAP mail server, read incoming messages sent to a specific account, get out the text, and deposit them in the weblog file tree.
Talking to the server and stepping through the "envelopes" (header information) was extremely simple. Extracting the actual text content seems impossible. There aren't any examples I could find. After a few hours spent reading a cascading series of Internet RFCs I concluded that the IMAP Ruby library is not exactly helpful with this; it seems like there ought to be some kind of basic, standard method to extract the plain text of the message. If there is, it isn't basic or simple, and the text part isn't visible in the data structures the library returns; there must be some kind of nested set of requests to get it from subsidiary return values, but I couldn't figure it out in a reasonable amount of time. So, so much for that quick hack. I'm not giving up entirely, which appears simpler, so maybe I'll try using POP. Or perhaps the right thing to do is to try to hook up a Ruby script to a procmail filter, although that seems like it could have security implications, although I'm not an expert in that area.
So, there it is: lots more to do; some progress on the infrastructure I want, but not a good start on any of the projects in particular. My approach is to work a bit on each one and see where I can get leverage, and repeat the next time I have some free time.