Wednesday, October 30, 2013

SQL Relay - 0.53 is out

SQL Relay 0.53 is now available!

This release contains several significant new features.

The most significant is the inclusion of a PHP PDO driver.  PDO is the most popular abstraction layer for PHP and SQL Relay has been without a driver for it for too long.  Give it a try:
It is new though, there could be bugs.  Report them to if you find any.

Also significant is support for Multiarch systems.  Debian and Ubuntu systems have supported Multiarch for a while now and packages weren't successfully detected on those systems.  They are now, even on non x86/x64 platforms.

The init scripts have been refactored as well.  After installed, SQL Relay should integrate properly with the init processes on most Linux and Unix systems and OS X.

The SQLite Statement API is now supported, both versions of it.  Platforms that can take advantage of it should perform a little better and use less memory.

A few bugs have been fixed too, including a long-standing issue where IPC and socket-related files were left lying around, owned by whoever last ran SQL Relay.  This caused problems if a different user tried to run it.  They are removed now and things work as expected.

The PHP Pear DB and Zope drivers have been removed too.  Packages aren't even available for them on most systems.  Zope is still well-used and I might resurrect the driver some day.  PHP Pear DB seems to have fallen so out of fashion that it's hard to even test it any more.

The sqlr-start program no longer attempts to start the sqlr-cachemanager.  Honestly, it's quirky that it ever did.  There are separate init scripts for them now as well.

What else..

Fixes for a few unlikely-to-be-encountered memory leaks and a few more obscure features.

Complete ChangeLog follows:
  • added support for sqlite statement api and native binds
  • fixed some leaks related to using sys::getHostName()
  • added multiarch detection
  • added PHP PDO driver
  • fixed a bind variable translation bug where output binds followed by := would not be detected
  • dropped zope support (for now)
  • dropped PHP Pear DB support
  • refactored init script - one script should work on all platforms now
  • updated init script installation - should work on virtually all unixes
  • added OS X launchd configuration
  • updated the sqlr-listener to clean up files related to ipc, sockets and marking whether the db is up or down on exit
  • sqlr-start no longer starts the cache manager
  • added a second init script for the cache manager
  • plugins are statically linked into libsqlrserver if the platform doesn't support shared libraries (or if --disable-shared is specified at configure time)
  • the perl API should build with old versions of perl (5.00X) on older platforms (redhat 4.2, 5.2, 6.2, etc.) now
  • updated postgresql bind docs
  • added dateyyyyddmm parameter
  • added yyyyddmm parameter to translatedates translation
  • added SQLR_MYSQL_DATE_YYYYDDMM envrionment variable to mysql drop-in library
  • added SQLR_ODBC_DATE_YYYYDDMM envrionment variable to odbc driver

Rudiments - 0.44 is out

For immediate release!

Rudiments 0.44

This release has lots of small fixes, optimizations and compatibility improvements.  There are no major changes but lots of refactoring and... fiddling around.

The most significant change is support for multiarch platforms like Ubuntu and Debian.  OpenSSL and PCRE should be detected properly on those platforms now.

Here's the complete ChangeLog for this release.
  • fixed inet_aton test to attempt link, not just compile
  • fixed vsnprintf test to work on arm linux
  • filedescriptor::printf now uses vdprintf, if available, if writes are not being buffered, and vasprintf, if available, if writes are being buffered
  • fixed a memory leak in filedescriptor::printf
  • added multiarch detection
  • applied Simon Martin's getenv-related patch to reset errno and allow getenv to return NULL - fixed a situation where an infinte loop could occur if getenv returned NULL and the most recent error from another system call was EINTR
  • added missing print() for const char *'s in linkedlistutils
  • tweaks for OSR505
  • a few xmlsax optimization fixes
  • renamed *Data methods to *Value in linkedlist and dictionary classes
  • removed print methods and unlikely-to-be-used static methods from *entry classes
  • refactored the static convenience methods of the *entry classes
  • refactored xattr code a little to make it smaller
  • removed static methods from filesystem class to make it smaller
  • removed some static methods from file class to make it smaller
  • removed the clientserverfactory class
  • slight refactoring of linkedlist and dictionary classes
  • various process class fixes for Windows

Sunday, October 27, 2013

Retrocomputing with SCO OpenServer 5.0.5


It seems like everybody hates SCO these days. But, there was a time... Way back, when they did good work, or at least work that enabled me to do good work. My understanding of SCO's history is a little fuzzy, but as I remember it, they spun off of Microsoft when Microsoft decided not to pursue Xenix. Either that or they bought Xenix from Microsoft. Something like that. Then they went on to develop a full fledged Unix for x86 and owned that market until Linux matured. In the mid-to-late 90's, Caldera began to challenge them with their Linux offering. SCO's technology lagged but they had a huge customer base. Eventually SCO proper got out of the OS business, changed their name to Tarantella and went on to continue development and support of their Tarantella platform. Caldera basically bought their customer base and ended up with their OS development business in the deal. Then leadership changed at Caldera. Caldera renamed themselves The SCO Group to capitalize on the name equity and began suing people left and right. That didn't go so well for them and I'm not exactly sure what happened next. They either renamed themselves Xinuos or Xinuos bought them, or something.

At any rate, before all of the politics, when I was a kid, my Dad used to run companies off of a PC, SCO Xenix (and later Unix), a Computone Intelliport (or later Intelliserver), and several dozen Wyse terminals. When I grew up, I wrote more software for those systems than I can even begin to remember.

Those were the days.

For a while, SCO Unix was pretty awesome too. When OpenServer came out in the early 90's, it had shared object libraries, a journaling filesystem, a Motif-based graphical desktop, graphical system administration tools, drivers written by the hardware vendors themselves and back-compatibility all the way to Xenix 286. Linux was still using coff binaries, libc4, ext2, athena widgets and you had to be really careful what hardware you tried to run it on. For a while, you could buy a single-user development version of OpenServer for like $100 too. I continued to use SCO, basically until the Linux distros started including ext3 and Gnome.

Between development versions and swag from old companies, my Dad and I ended up with several versions of SCO Unix and Xenix and software that ran on them. We used them for a while but for years now, the CD's and license keys have been sitting in boxes, collecting dust. He recently dug through all that though and came up with a copy of OpenServer 5.0.5, circa 1999.

5.0.4 and 5.0.5 were both very popular versions of OpenServer. Earlier versions were buggy and though later versions added DHCP and USB support, those features just weren't all that important on the server. Later versions suffered from competition with UnixWare, Solaris x86 and Linux too, and from general anti-SCO sentiment.


The first challenge with any of these older OS'es is finding an emulator that will actually boot them. Fortunately SCO OSR 5 is semi-supported by VMware. For a while, it was even one of the OS'es you could select from the OS list during installation.

I used an 8g disk and 128m of RAM, which I believe were the defaults and selected Other from the OS list.

The CD wasn't bootable though. Instead I had to mount it, find the boot disk image at images/boot/install.img and copy it out. The bootloader loaded fine but there is a trick to getting it the installer to actually run. I'm not sure where I found the trick, but I had it in some notes from the last OSR 5.0.5 install I did, umpteen years ago. Basically it needs a contiguous block of at least 32M of RAM, probably to load a ramdisk into.

The magic bootstring:

defbootstr mem=1m-64m

That actually allocates 63m of contiguous RAM. I might have gotten away with a 1m-33m parameter but 1m-64m was in my notes, so I used that.

OSR 5.0.5 - 1 boot

Apparently (according to my old notes), 8g drives are supported by default but if you want to use a drive larger than 8g then you have to add a biosgeom=(cylinders,heads,sectors) flag as well. cylinders=(#ofgig*1024*1024/63/255*2)-5. So, for a 30g disk, (30*1024*1024/63/255*2)-5=3911. You'd use:

defbootstr mem=1m-64m biosgeom=(3911,255,63)

Ha, I actually remember having to upgrade the bios in many of my old computers to support disks larger than 8g.

Anyway, after supplying the proper boot string, the installer started up.

I always thought the installer was attractive, as text-based installers go anyway.

It is a little quirky. You use arrows to move around, enter to accept an options and space to change an option. The cdrom drive isn't auto-detected, you have to specify whether it's on the primary or secondary bus and whether it's the master or slave. The "System name" prompt wants the host name. You can mostly accept the defaults.

One thing I always did though is turn off Bad Tracking, otherwise the installer will scan the drive and look for bad sectors. This takes eons and isn't necessary. Another quirk in the installer though... After turning Bad Tracking off, the installer still reports that its still on. It's not. There's just a bug in the installer.

OpenServer 5.0.5 doesn't support DHCP so you have to give it an IP address. It does support the emulated PCNet card though.

For video and graphics, use VESA SVGA (the default).

Oddly, the mouse is not configured by default and must be set to "Low Resolution Keyboard Mouse".

After all that, and otherwise accepting defaults, the installer will run unattended.

OSR 5.0.5 - 2 install

And when it's done, after a reboot, you get a fairly attractive graphical login.

OSR 5.0.5 - 3 first login

At one of the companies I used to work for, we named our servers after scientists. We'd swap that SCO logo for a photo of them and set the background to something appropriate as well. It was loads of fun.

Logging in revealed the Motif-based desktop.

OSR 5.0.5 - 4 desktop

State of the art for when it was released in 1995. Actually, I that's when I first saw it, in OpenServer 5.0.0. SCO released their OpenDesktop product back in 1990. It's possible that it came with the same desktop. I'm not sure.

A Post-Install Tweaks

Post-installation, as usual, I had to tweak a few things.

First, I created a user for myself with:

useradd -m

Next, I disabled the graphical login and I wouldn't be needing it in the future.

scologin stop scologin disable

Then I finished the network setup. The installer prompts for an IP address, netmask, hostname and domain name but fails to prompt for a gateway and DNS information.

Setting up DNS is straightforward. Create /etc/resolv.conf with something like:

domain nameserver

Adding a gateway is less straightforward. I remember from setting up 5.0.2 (Internet FastStart) that there is some file, somewhere in the system, that if you put the IP address of the gateway in it, it will automatically be set at boot. It's not in an intuitive place though and I had an impossible time finding it. For all I know, it only worked on 5.0.2. What we always did was edit /etc/tcp and look for a line like:

/etc/route add 0 > /dev/null 2>&1

Then add a line after it like:

/etc/route add default > /dev/null 2>&1

So that's what I did. After a reboot, I had networking.

I also fixed the man page system.

A little digressive background on the OpenServer man page system...

In OpenServer, man pages are actually served by a small http server called scohttpd. In theory, this is a really cool idea.

First, you can read the man pages by pointing a browser at port 457 and drilling down. However, if you want to crash a modern browser, go ahead and try that. The man pages are compressed with the "compress" format (which predates gzip) and apparently modern browsers think they can handle that and then die trying.

Second, you could install all the man pages on a "man server" and point the other systems at it using the MANPORT and MANSERVER environment variables rather than having to install man pages on every system in the network. In the late 90's this would have saved an appreciable amount of disk space. SCO software packages are even structured to make this possible. SCO never promoted doing this though, for some reason, and sadly, the feature went largely unused.

The man system has a bug though. The scohttpd server runs early in the boot process and some time later in the boot process, the socket files that it uses get deleted.

A quick fix is to edit /etc/rc and append:

/etc/scohttp stop /etc/scohttp start

...and reboot.

OSR 5.0.5 - 5 text login

Woohoo! Text login and working man pages.

Next, I installed the SCO OpenServer Development System and SCO Optimizing C Compiler from the distribution CD.

SCO's package manager is an interactive program called "custom". As in, to "customize" your system.

It, along with the rest of the system-administration tools, is written in TCL and, depending on whether you're running in a graphical environment or not, displays a graphical or text-based UI. The UI's look very similar and function identically. I was always impresssed with that technology.

To install the dev tools, I ran custom and selected Software->Install New->From osr505 (the name of my system)->CD-ROM Drive 0. I unselected Microsoft Client Software, selected SCO OpenServer Development System and SCO Optimizing C Compiler and selected Install.

If I may digress again...

Another very cool feature of OpenServer is the "From osr505" option that I mentioned above. CD-ROM drives in the late 90's were still really, really slow. If you had a software package installed on another system in the network, instead of installing from a CD on the local machine, you could tell custom to install it from another machine, across the network. The packages were structured to keep the original copy of config files too, so if you did a network install from another machine, you wouldn't get a modified version of the config files. With fast internet, apt-get, yum and friends, this approach is obsolete these days, but in the 90's, it was awesome.

Every OpenServer release was followed up with a bunch of patches and ultimately a release supplement roll up. Sometimes there were several consecutive Release Supplements. Patches and Release Supplements are all listed at and available directly at I installed RS505A, which patched the OS and the Development System.

SCO packages are quirky. They are typically distrbuted as a tar or cpio file containing a set of files named VOL.000.000, VOL.001.000, VOL.002.000, etc. which are themselves, cpio files containing the software. To install them, you must extract the file, tell custom to install "Media Images" and point it at the directory containing the VOL files. I think there is a non-interactive way to use custom, but I never figured it out. I don't think there's any way to get it to dig into a tar or cpio file though. So, package installation has always been a manually intensive process.

I didn't at this point, but if you attempt an OpenServer installation, I recommend installing the oss646b supplement as well, to save yourself lots of headaches later. Ironically, it's missing from the list of supplements, but it's absolutely critical if you want to use gcc rather than the native C compiler. It's available at

Remote Access

Telnet and ftp are the only built-in way to access an OSR 5.0.5 machine but ssh is available via "Skunkware".

Over the years, SCO downloaded, patched, compiled and made installable packages for a bunch of open source software. They called this project Skunkware, an allusion to Lockheed Skunkworks, I guess. These packages are available at and they put out "Skunkware" CD's too. Apparently they'd been doing this since the Xenix days, but I'm not sure how they distributed the software back then.

Skunkware packages for OSR5 in particular are available at The openssh package is among them.

Actually, I had to install zlib, prngd and openssh. I also had to tweak /etc/init.d/RMTMPFILES and add:

rm -f /usr/local/var/prngd/prngd.lock

Otherwise prngd would leave a lock file lying around and wouldn't restart after a reboot.

I tried to get X11 forwarding working. In /usr/local/etc/sshd_config, I uncommented and set:

X11Forwarding yes

I eventually discovered that the path to xauth was hardcoded into the program too, at /usr/X11R6/bin, which doesn't exist on OSR5 as OSR5's X Windows is based on X11R5, not X11R6.

I made the appropriate directories and added a symlink:

mkdir /usr/X11R6
mkdir /usr/X11R6/bin
cd /usr/X11R6/bin
ln -s /opt/K/SCO/XServer/5.2.2a/usr/bin/X11/xauth xauth

Unfortunately, X11 forwarding still failed with "X11 connection rejected because of wrong authentication." I still haven't figured it out. It's possible that xauth from X11R5 just isn't compatible with modern X. X11R6 is available for OSR5. Maybe I'll try that some day.

What's up with that crazy path to xauth?

Another fairly innovative thing that SCO did with the OpenServer series is install literally everything under /opt and /var/opt and create symlinks from the files there into /bin, /lib, /usr/bin, /usr/lib, /etc and so forth.

Internally, their package manager would just extract a new package into /opt and /var/opt and run the "fixmog" program to update the links.

Patch management was easy for the installer too. The patch was installed under /opt and /var/opt and making the patch available just involved updating the links. Rolling the patch back was simple too. Remove the patch, update the links.

The real power of this approach though, SCO never promoted. You could install software on one machine, NFS-export the directories for that package under /opt and /var/opt, mount them on another machine and run fixmog on that machine. The software was then immediately available on the other machine without having to fiddle with PATH's or LD_LIBRARY_PATH's. We did this a lot. It was quirky though, in that the packages showed in custom as having been installed locally, and if you didn't know they were NFS-distributed and deleted one, it would delete it from the app server. Maybe I can see why SCO never promoted NFS-exporting their software.

The whole links-everywhere thing seemed like a good idea, but it turned out to be confusing as hell. The output of "ls -l" had a gazillion symlinks to long paths and looked terribly cluttered. Just running "l" appended a @ to the filename if it was a link, which was also confusing. I think there were issues with scripts that ran ls -l or l as well. In the end, the dpkg/rpm approach was superior.

But I digress...

With OpenSSH installed, I could ssh into the VM. Yay, no more working on the console.

I could also scp and sftp.


Sadly, OSR505 comes with compress/uncompress but doesn't come with gzip, bzip2, zip or unzip and its tar program lacks the ability to uncompress on the fly. Fortunately GNU tar and the rest of those programs are available via Skunkware as well.


OSR505 comes with Netscape Communicator 4.05 which had a laughably difficult time rendering anything. I was able to install lynx and wget from Skunkware. Maybe someday I'll work on getting a semi-modern graphical browser working.

On the server side, 5.0.5 comes with the Netscape FastTrack Server. I bet you didn't even know Netscape made a web server. They did. I used it for years and years.

If you run a "ps -efa | grep http" on a running OSR505 system, it will reveal a confusing array of web servers, actually:

root 544 1 0 Oct-18 ? 00:00:00 /var/scohttp/scohttpd -d /var/scohttp
nouser 467 466 0 Oct-18 ? 00:00:00 /usr/internet/etc/ncsa_httpd -d /usr/internet/admin
root 411 1 0 Oct-18 ? 00:00:00 /usr/internet/ns_httpd/admserv/ns-admin -d /usr/internet/ns_httpd/admserv
root 413 411 0 Oct-18 ? 00:00:00 /usr/internet/ns_httpd/admserv/ns-admin -d /usr/internet/ns_httpd/admserv
root 415 413 0 Oct-18 ? 00:00:00 /usr/internet/ns_httpd/admserv/ns-admin -d /usr/internet/ns_httpd/admserv
nouser 420 1 0 Oct-18 ? 00:00:00 ./ns-httpd -d /usr/internet/ns_httpd/httpd-80/config
root 466 1 0 Oct-18 ? 00:00:00 /usr/internet/etc/ncsa_httpd -d /usr/internet/admin
nouser 421 420 0 Oct-18 ? 00:00:00 ./ns-httpd -d /usr/internet/ns_httpd/httpd-80/config

What the heck?

The ns-httpd processes are the Netscape FastTrack server - the web-server proper. The scohttpd server is for serving man pages. The ns-admin servers run a web-based configuration interface for the Netscape FastTrack server. The ncsa_httpd process runs a web-based configuration interface for configuring networking and other things on the local system (very quirky). If you enable secure httpd on the FastTrack server, a second set of FastTrack servers will start up and a second set of servers will start up for administering it. Gazillions of web servers on an OSR5 system. They used them for everything.

I aimed a browser at the various servers to verify that they were working but I didn't play with them other than that. Maybe later.


Yes. This is what I'm always really up to.

The native compiler had a hilariously difficult time making sense of my software. Maybe one day I'll tweak it to work with the native toolchain, but I figured I'd have an easier time with gcc.

In retrospect, it might have been easier to modify my software.

Several different versions of gcc are available via Skunkware and one via a "GNU Tools Supplement" available at None of them worked. This seemed strange because I know confidently that I used gcc for years on various OSR 5.0.X platforms.

It took hours and hours of installing, uninstalling, patching and rolling back to figure out how to get everything working but here's a summary of the challenges and solutions:

  • The linker ld, as shipped by default and updated by RS505A doesn't support -static or -R options but libtool insists that it does.
    • The -static issue expresses itself with lots of "relocations remaining" errors at link time.
    • Actually ld does support -R but it means something totally different than libtool thinks it does, it's not the rpath.
  • oss499a adds -static support (or somehow works around it) but occasionally "relocations remaining" errors persist.
  • oss646b fixes all of these issues but causes the Skunkware gcc's to error out at link time with a _fini error.
  • The gcc from gnutools fixes the _fini error.
  • So, you have to use oss646b and gcc from gnutools, there's no other reliable option.

I didn't install all of gnutools, only GCC. Some of the other packages are duplicates (or newer versions of) tools I'd already installed and some of them require a different package called gwxlibs. In fact, during intallation it warns about:

Some of the selected software depends on other software that is not currently installed on your system.

...but it's safe to ignore the warning if you're just installing gcc.

I also installed perl, python, php4, pth (a portable pthreads package required by python), readline, bash, cvs and gmake from Skunkware. I'd swear that Java 1.1.3 was once available for OSR5 too, and there are even allusions to this on the SCO site but I can't find it anywhere anymore.

I tried installing openssl and postgresql from Skunkware but as it turns out, openssl only provides static libraries and postgresql requires the FSU-pthreads package which causes relocation errors at runtime.

I could probably build openssl from source and maybe postgresql too, against pth, but I'll save that for another day.

After all that, and a few tweaks to my code, I was eventually able to build and install everything. The SQL Relay installation was a little anticlimactic because I didn't have any database software installed to run the server against, but the client ran fine.

$ uname -a
SCO_SV osr505 3.2 5.0.5 i386
$ sqlrsh -host fedora19 -port 9000 -user test -password test
SQLRShell - Version 0.53
Connected to: fedora19:9000 as test

type help; for help.

0> select banner from sys.v_$version;
Oracle Database 12c Enterprise Edition Release - 64bit Production
PL/SQL Release - Production
CORE Production
TNS for Linux: Version - Production
NLSRTL Version - Production
Rows Returned : 5
Fields Returned : 5
System time : 10000


Ironically I originally developed the precursor to SQL Relay on an SCO OpenServer system to run against Oracle 7. These days I don't have a copy of Oracle 7 and even if I did, I long removed support for it. OpenServer has been relegated to client-only status.

Oh well, times change.


Aside from the quirks I mentioned above, I ran into a slew of other oddities while fiddling with OSR505. Some can be attributed to its age, others to SCO's commitment to back-compatibility. Others, I'm just not sure about.

  • At boot there are options for entering single-user mode and setting the date/time. There are timeouts for both prompts. However, hitting enter at the initial boot prompt disables the timeouts and makes it sit on the prompt to enter single-user mode forever.
  • On the command line, hit delete instead of ctrl-C.
  • Home directories are created under /usr.
  • Root's home directory is /.
  • There is no "which" command.
  • PATH is set in /etc/default/login for console logins but ssh appears to hardcode its own PATH before running .profile.
  • /usr/bin/X11 isn't in the PATH by default.
  • ./ is in the PATH.
  • The shell doesn't know about ~.
  • The package manager automatically selects the first package. So, if you want to uninstall something, you have to make sure to unselect the first package or it will get uninstalled too.

And, the quirk that confounds automated remote scripting over ssh:

The .profile runs a tset command that guesses your terminal type and then prompts you for whether it was correct or not. This makes ssh'ing remote commands a pain because you have to hit return manually to accept the terminal type. Without this command, the TERM type appears to generally get set correctly. Just comment it out in the .profile:

#eval `tset -m scoansi:${TERM:-scoansi} -m :\?${TERM:-scoansi} -r -s -Q`


I had a lot of fun installing OSR505 and it was a nice walk down memory lane, but I haven't yet gotten to do everything I wanted to.

It would be cool to:

Get the webserver working and serving CGI's.

Find Java and get my java code working with it.

Get xauth working, maybe by installing X11R6.

Get postgresql working, maybe by building from source.

Get my software to compile with the native toolchain and optimizing compiler.

SCO supported IPX/SPX and NetBEUI, had an Advanced File and Print Server that predated SAMBA and had a Volution Messaging server that was compatible with older versions of Exchange Server. I think all of that is on the install CD. It'd be neat to get all of that working.

Earlier versions of OSR5 came with Wabi and Merge. Wabi means Windows ABI and was an environment similar to Wine that allowed you to run Windows 3.1 apps on SCO. It even came with a graphical desktop similar to 3.1. It was dog slow in the 90's but might run OK now if I can find it. Merge was the predecessor to Win4Lin. Basically Win4Lin was a port of Merge to Linux. The Merge that came with OSR only supported Windows 3.1 though, I think. It'd be cool to locate that software and play with it.

My Dad has floppies for Microsoft Basic for Xenix, Microsoft Word for Xenix, Foxplus and maybe even Foxpro for Unix. It'd be fun to intall those and play around with them. We wrote so much code in Basic and Fox, you can't begin to imagine.

Get Oracle 7 working again. We once had the installation CD's for 7.4.3 and 7.4.4. I might be able to dig them up.

Ahhh, some day... Some day.

Saturday, October 19, 2013

NetBSD - 6.1.2 x86

NetBSD 6.1.2 apparently came out sometime recently when I wasn't looking. I have probably a half dozen NetBSD installations running in various emulators, but my primary NetBSD development environment is x86. I'll get around to upgrading the others in due time, but the x86 VM can't wait. It can't!


As with most OS'es these days, you can either download a DVD image with everything on it and install from that, or you can do a netinstall over FTP or HTTP or something. I usually go with the netinstall unless I'm installing some really old version that's hard to find, and I went with the netinstall in this case too.

I downloaded the boot iso from:, aimed VMware at it and began the installation.

VMware always wants to know what kind of OS you're using but never gives you a NetBSD option. Other -> FreeBSD has always seemed close enough and I went with it again this time. I wonder exactly what the difference between that and Other -> Other would be though. I know you get IDE disks with FreeBSD and it defaults to 20g rather than 8g but there's probably something else too. Maybe I'll look into that some day.

Other settings... 8G disk, bridged Network Adapter, 800 x 600 display, 256M of RAM. I also removed the Floppy, USB and Sound Card.

NetBSD runs in a lot of emulators so I've probably done more NetBSD installations than anything else. The installation process always seems pretty straightforward to me. Just follow the prompts.

I selected Full Installation, Use Entire Disk, Use Existing Partition Sizes and installed from FTP. I also declined IPv6 autoconfiguration.

Pretty soon, I was in business.

I've always liked how the installer shows you the full ftp session output.

NetBSD 6.1.2 i386 - 1 install

The downloads are getting quicker every year. I'm always surprised how quickly an entire distro comes down.

As of 6.1, I think, but maybe 6.0, after the sets are installed there's a menu that lets you configure the network, timezone, root password, etc. You can bypass all of it if you like but I usually go down the list, configuring each thing.

It's important to "Enable installation of binary packages" and "Enable sshd" but I chose not to enable ntpd, ntbdate or mdnsd.

I also got a little concerned when pkgsrc stalled out at the end but it eventually finished so I guess everything is OK there.

When the installation is over the installer drops you back at the main menu.



NetBSD 6.1.2 i386 - 2 first login

Post-Install Tweaks

I don't usually like poking around as root, so the first thing I do with a new system, unless I was able to do it during the installation, is create a user for myself.

NetBSD has the standard useradd/userdel commands.

useradd -m -G wheel dmuse passwd dmuse

The -m creates a home directory and the -G wheel adds the user to the wheel group, making it possible to su. On linux and some other platforms those options aren't necessary but it I believe it is on all of the BSD's. useradd doesn't prompt for a password so that's important to run afterward.

The next thing I usually do is make it possible to sudo without a password. Unfortunately sudo isn't installed by default but fortunately, NetBSD supports pkgin, and by virtue of selecting the "Enable installation of binary packages" option during the installation, I can install sudo easily.

pkgin install sudo

pkgin is great. It's similar to apt-get and yum. You can list available packages, search for packages, install them over the internet (with dependency resolution) etc.

It even has a feature that I'm not sure how to do (or if you can) with apt-get and yum. If you manually install a package and it drags in dependent packages, but then you uninstall the main package, the dependent packages are orphaned. It would be great to uninstall them as well but who keeps track of all the dependent packages that got installed along with the one you meant to install? Pkgin does. Those packages are marked auto-removable, as nothing else depends on them. You can run "pkgin autoremove" and it will remove all auto-removable (orphaned) packages. Awesome.

There is a significant quirk though. It appears that if you install a meta-package (ie. a package that doesn't install anything, only has dependencies that cause other packages to be installed) then the dependencies themselves get marked as having been installed directly and can't be removed automatically. This is particularly frustrating when you install something large like the Gnome desktop and then attempting to remove it, expecting autoremove to do most of the work for you.

But I digress.

I was in the middle of configuring sudo...

NetBSD puts its packages in /usr/pkg so the sudoers file is in /usr/pkg/etc. I appended to it:


All right, no more logging in as root.

I enabled sshd during installation. xauth was installed as well. X11 Forwarding wasn't enabled by default though, so I enabled it by editing /etc/ssh/sshd_config and setting:

X11Forwarding yes

then restarting ssh

/etc/rc.d/ssh restart

After that I copied my entire .ssh directory from another VM and was able to ssh into the NetBSD VM without a password.

All right, no more logging in on the console.

ssh, scp, sftp and ftp all appeared to be present. tar, gzip, bzip2 and unzip appeared to be present as well. zip was conspicuously absent but quickly installed:

sudo pkgin install zip


On the client side, I like to have firefox, lynx and wget available and apache on the server side. None were installed but all were available. "pkgin search firefox" and "pkgin search apache" revealed several options for each but it looked like "firefox" and "apache" would install the latest version.

sudo pkgin install firefox lynx wget apache

The apache config file appeared to be /usr/pkg/etc/httpd/httpd.conf with DocumentRoot /usr/pkg/share/httpd/htdocs.

I enabled cgi's.

LoadModule cgid_module lib/httpd/
AddHandler cgi-script .cgi
Options Indexes FollowSymLinks ExecCGI
DirectoryIndex index.html index.cgi

Apache for NetBSD comes with an example init script but it's not installed by default. I installed it...

sudo cp /usr/pkg/share/examples/rc.d/apache /etc/rc.d

...and enabled it by adding the appropriate line to /etc/rc.conf


Then started apache. Would my test program work?


echo "Content-type: text/plain"


Excellent. Moving on.

Graphical Desktop

What kind of graphical desktop could I get working? A few pkgin searches revealed Gnome 2 and 3, KDE 3 and 4 and XFCE 4 but no obvious metapackage stood out for any of them.

After a little digging on the web I found the pkgsrc meta-packages list for 6.1.2 at It looks like "gnome-platform" will get me Gnome 2, "kde" will get me KDE 3 and "xfce4" will get me XFCE 4.

Well, as it turns out, gnome-platform doesn't get you all of Gnome 2. To get it, you have to manually install tons of individual packages and it's difficult to figure out which. Worse, if you get started and want to bail, pkgin autoremove doesn't work help because gnome-platform is a meta-package.

XFCE 4 looked like a better choice...

sudo pkgin install xfce4

The list of dependencies looked more realistic.

I created my .xinitrc...


... switched back to the console and ran ...



NetBSD 6.1.2 i386 - 3 xfce

I love their little mouse logo.

All right, what about a graphical login? XFCE doesn't have its own and they recommend using gdm, lightdm, slim or lxdm. Of that list, pkgin only knows aboug gdm. Maybe plain old xdm would work. It was already installed.

I created an .xsession file with:




to /etc/rc.conf and rebooted.

Well, it wasn't pretty, but it worked:

NetBSD 6.1.2 i386 - 4 xdm

And logging in got me an XFCE session too.

What about the web browser...

I clicked on "Web Browser" and it ran "Nightly" but "Nightly" looked a lot like Firefox. I checked the Preferred Applications settings in XFCE and they were set to use Firefox as the web browser. Indeed, running firefox from the command line in a terminal ran "Nightly" as well. Does "Nightly" mean "nightly build of Firefox"?

At any rate, I aimed it at my trails site and it worked as expected. The fonts were a little big, but zooming out by 1 took care of that.

NetBSD 6.1.2 i386 - 5 browser


Were there any productivity apps available? It appeared so. pkgin could see LibreOffice 3 and 4, OpenOffice 3.1, KOffice, fengoffice and various other packages.

sudo pkgin install libreoffice4-bin

LibreOffice had some interesting dependencies like suse_base, suse_x11, suse_libtiff, etc. NetBSD supports binary emulation. Maybe LibreOffice was just a linux app with the necessary support packages.

pkg_info -L suse_base sure made it look like it was. Everything was stored under /usr/pkg/emul/linux. Interesting.

I had to run it from the command line using "soffice" and it complained about a non-existent java vm and threw a bunch of dbus/gconf errros but in the end, it worked:

NetBSD 6.1.2 i386 - 6 libreoffice

Impressive sir!

AbiWord and GNUmeric were also available and appeared to be native NetBSD apps.

sudo pkgin install abiword abiword-plugins gnumeric

They integrated better too, showing up in the XFCE menu after installation and appearing as the default .doc handler for Firefox (or Nightly).

NetBSD 6.1.2 i386 - 7 abiword


All right, enough of that. I'm ulimately setting up this VM to test my software on.

Some packages that I needed appeared to already be installed: gcc/g++, pcre, openssl, apr, perl, sqlite, cvs

But even more needed to be:

sudo pkgin install readline php ruby tcl erlang openjdk7 mysql-client postgresql92-client unixodbc freetds gmake vim-gtk2

I copied my .cvsrc and .vimrc from another VM and some build scripts too, checked out my source code and ran the main build script.

Everything built.

To test it I had to add /usr/local/firstworks/bin to my PATH and /usr/local/firstworks/lib to my LD_LIBRARY_PATH. The BSD's in general are difficult to set system-wide paths on because the .profile scripts override anything you set in /etc/profile so I just added them to my .profile instead of setting them system-wide.

After that, I could run the sqlrelay server against the different databases that I was able to build support for. sqlrsh could connect just fine to the instance on my linux host connected to oracle.

NetBSD 6.1.2 i386 - 8 sqlrsh

Everything appeared to work as expected.

Clean Up

I don't need X Windows for most of what I do so I disabled xdm in /etc/rc.conf


and rebooted. During the reboot I reduced the VM's memory configuration to 128M. That's always been plenty in the past.


I did run into some interesting quirks.

Shell aliases need to go in a particular location in ~/.shrc rather than in ~/.profile directly or it causes all kinds of problems. I don't remember that from 6.1.1 but maybe it was an issue in that release too.

XFCE itself doesn't appear to read ~/.profile and its terminals don't either. On top of that, the shell doesn't understand ". .profile" or "source .profile". To get my PATH settings, I had to run a terminal, then run bash and manually source my .profile. I'm sure there's some way to fix that but it was very confusing.

There's also a swap partition issue. No swap partition was created by the default installation options but the system was configured to save core (in case of a kernel panic) to the nonexistent swap partition. /etc/rc.d/swap2 complains that there isn't one too. It's possible to add a swap file by running:

dd if=/dev/zero of=/swap bs=1m count=256
chmod 600 /swap
swapctl -a -p 1 /swap

and adding to /etc/fstab:

/swap none swap sw,priority=1 0 0

but the kernel can't dump to that so it's only a half fix. Very strange. I'll have to keep that in mind for next time.

Wednesday, October 16, 2013

The Horizon...

Looking ahead...

I like to look ahead.  It's so exciting!  Sometimes at least.  Hopefully this look ahead will be exciting to you.

Coming soon to SQL Relay...
  • PHP PDO Support
  • SQLite Statement API Support
  • Multiarch Support
The next release will include all three.  Exciting?  Maybe.  I guess that depends on your interests.

I've been meaning to implement these things for long time and just now getting around to doing it.


The PDO support will probably have the greatest impact.  PDO is the most popular PHP database abstraction layer these days and SQL Relay has long lacked support for it.  It's funny, for as popular as it is, it is a little quirky.  There's no obvious way to bind a floating point number, for example.  It looks like you just can't do it.  It doesn't appear to differentiate between Clobs and Blobs either.  They're both just LOB's.  That's actually giving me problems right now.  And it doesn't appear to support out-variables.  It supports in-binds and in/out-binds but not just plain out-binds.  SQL Relay supports in-binds and out-binds but not in/out-binds, so I guess I can't be too particular about another API's lack of support for something, but it's odd.  I'm currently mapping SQL Relay's out-binds to PDO's in/out's.  I hope that works out.

SQLite Statement API

This is an under-the hood change that won't likely have any noticeable effect, other than maybe subtle performance or memory-usage.  SQLite has long had a statement-oriented API and supported bind-variables natively, but SQL Relay has always used the older API and faked bind variables by rewriting the query.

No longer!

The SQLite Statement API is now supported.  Actually both versions of the statement API are supported.  There appears to have been an initial effort and then a follow-up where _v2 was appended to some of the functions and error handling was improved.  Both statement API's are now supported, as is the old sqlite3 API and the even older sqlite API.  So, it shouldn't matter what version of SQLite you're using, they're all supported.

From the outside, there are only two noticeable differences.

The statement API exposes column types, so column types will now be visible and not just "UNKNOWN".

Also, the statement API provides methods for fetching one row at a time, while the older API's either required you to register a callback to handle a row or returned the entire result set at once.  I opted to use the return-the-entire-result-set method and as a result, knew how many rows there were in the result set.  When using the statement API though, the total number of rows in the result set is unknown until they've all been fetched.  So, going forward, if you use setResultSetBufferSize() on the client-side, rowCount() will be unknown.

It's possible that performance will be improved using the statement API but I haven't run any tests to see.  It's likely that memory usage will be better on the server-side, as the sqlr-connection daemon doesn't buffer the entire result set any more.  Depending on the size of the result set, this could improve performance too.  Again, I haven't run any tests to see.

Multiarch Support

Debian and Ubuntu have recently embraced Multiarch.  It's a great idea but it creates headaches for configure scripts.

What is Multiarch?

Some architectures support multiple binary formats.  For example, an x86_64 CPU can run code compiled for x86_64 or x86.  An ARM chip with hardware floating point support can run ARM binaries that depend on hardware floating point support, or soft-float binaries.  Many ARM chips can run thumb code as well.  A MIPS64 chip can run 32 or 64-bit MIPS binaries.  Similar for SPARC64.

In the past, support for multiple architectures on the same system has been shoehorned in by creating /lib and /lib64 directories and putting 32-bit libs in /lib and 64-bit libs in /lib64.  BTW, this also created its share of headaches for my configure scripts, but happened so long ago that I'd forgotten entirely about it.

Multiarch aims to support more than just 32 vs. 64 bit variants.  On a Multiarch system, under /lib and /usr/lib, there are directories like i386-linux-gnu, amd64-linux-gnu, mipsel-linux-gnu and arm-linux-gnueabihf with architecture-specific libraries in them.  An amd64 machine might have both amd64-linux-gnu and i386-linux-gnu directories, enabling it to run 32 and 64-bit binaries.

This presented a challenge.  The configure script has to look in the appropriate subdirectory but the arch command doesn't help.  For example, arch might return i586 or armv7l rather than i386 or arm.  And how should we know to look in arm-linux-gnueabihf?  Where does that gnueabihf come from?  This plagued me until I discovered that on newer multiarch systems,  gcc -print-multiarch will return the multiarch tuple.  Woohoo!

So, now the configure scripts look in the appropriate directory.  If you use gcc -m32 on an x86_64 system, it should look in the i386-linux-gnu subdirectory.  If you use gcc -m64 (or leave out the -m option), it'll look in the x86_64-linux-gnu or amd64-linux-gnu subdirectory, as appropriate.

What does this mean for the user?  Basically on modern Debian and Ubuntu releases, The configure script will "just work" and correctly detect everything installed on the system rather than requiring painful manual intervention.

That's half of the challenge.  The other half is installing my libraries in the right places.  For now, I'm just still installing them in the lib directory.  Currently, the --libdir option to the configure script can be used to install them in the appropriate multiarch subdirectory.  I'll have to see what the debian package build scripts are doing.  They might just be using --libdir and I may not have to do anything.

So, that's what's on the horizon.

There will, of course, be a few bug fixes, and it's possible that the ODBC driver might have some improvements too, but I wouldn't hold my breath.

Sunday, October 6, 2013

FreeBSD - 9.2 x86

Upgrade time!

FreeBSD 9.2 just came out and last night I felt compelled to upgrade.  Compelled!

Would my software still compile and run?  Did they fix the issue I had in 9.1 where pkg_add -r didn't work for large enough files.  Who knows!?  I would find out.

The netinstall image was available, as they usually are, from I downloaded it forthwith, aimed my VMware Workstation at it and let the adventure begin.

"Select a Guest Operating System" it said. "Other -> FreeBSD"  seemed like a logical choice.  I also changed the 20g hard drive image to 8g (which was enough with 9.1) but accepted the default 256M of memory.  Later, the disk turned out to be IDE.  I wonder if I'd get better performance out of SCSI.  Some day I'll test that, but not today.  I didn't need a Floppy, USB or Sound Card so I removed the emulated versions of those, switched my Network Adapter to Bridged (and to replicate physical network connection state) and set the Maximum resolution of any one monitor  to 800 x 600.



FreeBSD-9.2 - 1. boot screen
Interesting. I don't remember a multi-color bootloader in 9.1. Maybe there was one though and I just don't remember it. I like it.

On the "Distribution Select" screen, games was already checked but I checked doc, ports and src too to get a more complete installation.

I'm using static IP's on my network so I opted out of DHCP autoconfiguration but noticed something quirky when attempting to enter my IP, netmask and gateway.  Hitting return after entering a value in a field takes you to the next screen rather than the next field and hitting tab takes you down to the OK/Cancel buttons rather than the next field too.  I had to use arrows to navigate between the fields.  Unusual.

Ok.  Static IP, no IPV6, let's go.

I selected Guided partitioning and used the Entire Disk.  The default partitioning looked good - a small boot partition and the rest was swap and root.

Pretty soon the installer was downloading sets.  The download was surprisingly fast.  I went to get a glass of soda and the Overall Progress was already at 15% when I came back.

FreeBSD-9.2 - 2. downloading
That said, for whatever reason, set extraction seemed to take a while.  Another reason to test that emulated SCSI drive some time, I guess.

Eventually everything was installed.  On the System Configuration screen, sshd was already checked and I didn't enable moused (mouse on console), ntpd or powerd.

I did create a user and was surprised at how many options there were.  Most OS'es prompt for the login name, full name and password, maybe additional groups.  FreeBSD asks a whole page of questions, all relevant questions, but man... a lot of questions.

A minute or two later I rebooted and got my first login prompt.

FreeBSD-9.2 - 3. first login
Post-Install Tweaks

I logged in and checked to see what was running.  Not much, actually, which was nice.  I usually have to stop a ton of unused processes, but not this time.  Sendmail was running, but after poking around a bit I learned that it was configured for local delivery only.

There was an odd adjkerntz process running but after looking at the man page it seemed wise to leave it running.

I'd created a user for myself but quickly realized that I'd forgotten to add myself to the wheel group.  Oops.  Maybe I should have paid more attention on that long page of options when I created the user to begin with.

I usually install sudo almost immediately after installation.  FreeBSD still doesn't appear to have an equivalent to yum search or apt-cache search but I figured I could probably guess the package name.

pkg_add -r sudo

Yep, not too hard.  The sudoers file was in /usr/local/etc though, not /etc.  I guess this makes sense as the rest of sudo was installed under /usr/local but it took me a minute to find it.  sudoers is in a different place, I never remember that about FreeBSD.

sshd was running already but I installed xauth so X-forwarding would work.

pkg_add -r xauth

I copied my .ssh directory from another machine and was instantly able to ssh into the VM from elsewhere.  No more working on the console.


What kind of web software do we have.  Nothing came in the base install, it seemed, so I installed firefox, lynx and wget.

sudo pkg_add -r firefox lynx wget

firefox pulled in a lot of x-windows stuff (which I expected) but unexpectedly pulled in perl and python too.

On the server side, I installed apache.  Or at least I tried to.  pkg_add of apache, apache2 and httpd all failed.  What's it called again on FreeBSD?  No good way to find out (that I know of) other than ftp'ing in and looking around.

cd cd pub/ports/i386/packages-9.2-release/Latest
dir *apache*

There appeared to be apache22 and apache24 options.

sudo pkg_add -r apache24

The install script gave me this helpful message too:

To run apache www server from startup, add apache24_enable="yes"
in your /etc/rc.conf. Extra options can be found in startup script.

Thanks for that.  I added the enable line, but how do you actually start apache again?  There was no /etc/rc.d/apache*.  "grep -r apache /etc" was unrevealing

Finallly, "pkg_info -L apache24-2.4.6" revealed an init script in /usr/local/etc/rc.d/apache24.  Got it.  Should have remembered that.

The config file was in /usr/local/etc/apache24/conf/httpd.conf.  The DocumentRoot was set to /usr/local/www/apache24/data.

I enable cgi's...

LoadModule cgi_module libexec/apache24/
AddHandler cgi-script .cgi
Options Indexes FollowSymLinks ExecCGI
DirectoryIndex index.html index.cgi

...and started the server

/usr/local/etc/rc.d/apache24 start

I wondered if that would get started at boot time or not.  Does the init process look in /usr/local/etc/rc.d?  I'd find out later.

Do cgi's work?  Sometimes they don't but this time they did.  My little test program worked fine with lynx:

echo "Content-type: text/plain"


What kind of productivity tools were available?  I'd have to ftp in again to find out.  Looks like LibreOffice is available.  Excellent.

sudo pkg_add -r libreoffice

In 9.1, downloading a large package would sometimes cause pkg_add to stall out.  Not this time though.  It took a while but everything was successfully downloaded and installed.

I guess I jumped the gun a bit with that LibreOffice install though.  To actually run LibreOffice, it's generally helpful to have X running first.

Graphical Desktop

What desktops are available?  I had to ftp in again to find out but I was pleasantly surprised.  Gnome 2, KDE, XFCE 4, LXDE and E17 all appeared to be available.  Gnome 3 was missing but it requires hardware acceleration and I'd have installed Mate instead anyway.

Let's try Gnome 2.

sudo pkg_add -r xorg gnome2

This took forever.  I was reading a book while waiting and after several chapters, I just gave up and let it run all night.  The next morning it was installed though and I tried it out.

There were a few things that I didn't remember from my last FreeBSD install but I did remember that X on FreeBSD requires hald and dbus.  They were installed with xorg but not enabled so I added lines to /etc/rc.conf to enable them:


X also requires /proc so I added a line for it to /etc/fstab...

proc /proc procfs rw 0 0

... and then I started everything up.

sudo mount /proc
sudo /usr/local/etc/rc.d/hald start
sudo /usr/local/etc/rc.d/dbus start

To just run gnome from the command line you have to make sure there are no .startxrc or .xsession files in your home directory, create an .xinitrc with:


and run:


I switched back to the console and tried it.  It almost worked.  I got a beautiful desktop but the mouse didn't work.  After some poking around it appeared that hald wasn't running.  Ah, who knows, just reboot.

Upon reboot, hald, dbus and apache all 3 came up.  I guess the init process does look in /usr/local/etc/rc.d.

I tried startx again and the mouse worked fine.  The first terminal I opened died immediately but the next one opened fine.  I've never been able to reproduce that and had no other problems at all.  I have no idea what caused it.

I fired up Firefox and pointed it at my trails site.

FreeBSD-9.2 - 4. firefox
It seemed slow to start but ran well once loaded.

LibreOffice writer seem slow to start as well.

FreeBSD-9.2 - 5. libreoffice

Neither guest nor host were paging.  I thought fs caching might improve things and Firefox did seem to start more quickly the next time but LibreOffice still didn't.  The System Monitor said I was only using about 36m of ram (out of 256) but now using 131m of swap.  Hmm.  Something's going on.  No time to fiddle with that though.

VMware tools.  Could I get them working?

I clicked "Install VMware Tools" in VMware and (as expected) nothing happened.  I had to manually mount cd  but that took a little digging to figure out.  I'm sort-of used to mount attempting to detect the filesystem type and also sort-of-used to the filesystem type being iso9660, but it doesn't and it wasn't.  No problem though, I figured it out:

sudo mount -t cd9660 /dev/cd0 /mnt

Installation was a little tricky though.  It started off easy.

tar xfz /mnt/vmware-freebsd-tools.tar.gz
sudo vmware-tools-distrib/

I accepted the defaults.  At the very end it errored out.  Apparently I needed to install compat6x-i386.  No problem.

sudo pkg_add -r compat6x-i386

I re-ran installer and re-accepted defaults.  This time it got further but I got some semi-confusing messages at the end: "No X install found" "Unable to start services for VMware Tools"

Maybe a reboot would help.

Kind-of.  The messages said to run /usr/local/bin/

I did and it still gave errors regarding memory manager and blocking file system but it appeared to recognize X.  I ran startx and, hey! the cursor automatically moved in and out and I could resize the screen.  Woohoo!  I'll call that success for now

To get a graphical login I append some lines to /etc/rc.conf:


And I'm sure there's some way to start GDM from the console but I just rebooted again.  Upon reboot I got the expected graphical login manager.

FreeBSD-9.2 - 6. gdm

Logging in took a while.  Everything seemed generally sluggish but once it was loaded it was very usable.

It's fun to get the graphical desktop working but in truth, I prefer to run my VM's in text mode.  I usually just ssh into them to test software and there's no need to consume the extra memory.  So I disabled the graphical login...


...and booted back into text mode.


Development is what I'm really up to with these VM's.  I make sure my software compiles and runs on them.  The more platforms and compilers you expose your code to, the more likely it is to compile and run on platforms you don't have access to.  Or something like that.

g++, perl, python and ruby appeared to have been installed already, as were pcre, openssl, apr, curl, libexif, and librsvg2.  For some reason, proj was even installed.  I didn't realize anyone but me ever used it but apparently so.

I did need to install a few languages, database API's and tools so I ftp'ed in to the ftp site again and discovered the names of the packages I needed to install.

sudo pkg_add -r gmake vim php55 tcl86 erlang openjdk7 readline unixODBC mysql56-client postgresql92-client freetds freetds-devel sqlite3 mdbtools p5-Image-ExifTool gdal

freetds-devel is the oddball.  Why a separate devel package?  That's standard on Linux for sure, but not on any of the BSD's.  Odd.

In 9.1 pkg_add had stalled out on erlang and openjdk7 and I had to manually download and install them, but it worked this time.  Woohoo!

I copied over my .cvsrc, and .vimrc files from another VM, tweaked my .profile a little and...  ahh, come on:

E25: GUI cannot be used: Not enabled at compile time

Really?  gvim was compiled without support for the GUI?  I guess so.

I checked out and built all of my code.  No surprises, everything compiled and installed just fine.

Updating the system-wide PATH is always difficult on FreeBSD because the user-specific .profile overrides it entirely so rather than updating /etc/profile, I added /usr/local/firstworks/bin to the PATH and /usr/local/firstworks/lib to the LD_LIBRARY_PATH in my .profile.

sqlrsh worked as expected.

FreeBSD-9.2 - 7. sqlrelay

(I fired up the GUI one last time to get that screen shot)

Running sqlrelay against mysql, postgresql, sqlite, etc. all worked as expected and my test programs worked against it.  All right.  I'll, of course, do more testing later but for now it looks like FreeBSD 9.2 is supported.

Clean Up

Since I'm not running a graphical environment, I disabled hald and dbus in /etc/rc.conf...


...and rebooted.  During the reboot I tuned VMware down to 128M of RAM too.



Or at least almost none.  There were a few quirks but I have yet to install an OS that didn't have any.  Besides, I'm not here to critique the OS, just to explore it and support it if I can.