Saturday, April 19, 2014

Hurd 2013


Back in 2013, an updated version of Debian Hurd came out, aptly titled Hurd 2013. I downloaded the ISO but never got around to even trying to install it until yesterday.

While other GNU projects have basically driven the state of the art forward on a regular basis, the Hurd might get the award for the most slowly advancing project of all time. I'd put it right behind the Enlightenment window manager. It does keep moving forward though, inch by inch.

What is this Hurd you speak of? Basically it's GNU's take on the kernel. It's different from most kernels though because it implements a microkernel architecture.

What is this microkernel architecture you speak of? Well, I hope I explain this inoffensively accurately...

Most kernels are one big block of code, occupying a single address space. If an app wants to read a chunk of data from a file, it asks the kernel (via a system call) to read the chunk into a specified block of memory. Inside the kernel, the request trickles down through various subsystems and drivers. Something like: virtual file system subsystem -> ext3 driver -> virtual block device subsystem -> sata subsystem -> specific sata driver -> sata controller... To achieve this, each subsystem or driver makes a function call to the layer below it. Since all of this is done in the same address space, it's fast, but a bug in any one subsystem or driver could crash the entire system.

In a microkernel system, the microkernel is small and discrete. It manages virtual memory, schedules processes and provides a mechanism for proceses to talk to each other: Interprocess Communication (or IPC). That's all. Kernel components run as separate processes on top of a microkernel, each in their own address space, and communcate with each other and with user-space apps via IPC. If an app wants to read a chunk of data from a file, the request has to trickle down through an analogous set of subsystems and drivers, but rather than making function calls, the subsystems in the chain communicate via IPC. This involves a lot of copying and synchronization, and is potentially slower, but much more robust. Since everything runs in separate address spaces, it's much harder for a bug in one subsystem or driver to take down the entire system.

The Hurd isn't the only microkernel OS out there. Minix, QNX, Tru64 and OS X are all microkernel-based. There are many others too, but those come to mind immediately. Which architecture is superior? The jury is still out. There have been some famous debates on the subject, major vendors have gone both ways, but no clear winner has emerged.


At any rate, I'd played around with Debian Hurd 0.3 years ago but never got around to trying the current version until yesterday.

I installed it in VMware and ran into a few issues, but nothing I didn't eventually figure out how to work around.

Hurd 2013 - 1. install

I had to give the VM 512mb of ram for the installer to run at all.

The graphical installer only sort-of worked. It didn't display the "Go Back" and "Continue" buttons, and eventually hung extracting files. The text and pseudo-graphical installers worked fine though.

VMware usually puts the hard drive at IDE 0:0, but sometimes, randomly, puts it at IDE 1:1. I'm not sure why, but if it's not at 0:0, then the installer will eventually fail near the end, unable to find the CD. Making sure that the hard drive is at IDE 0:0 fixes this. Go figure.

The installer is also a little confusing because it sees the CD as just another hard drive, or at least presents it that way. When partitioning disks and installing the bootloader, it gives you the option of partitioning the CD or installing the bootloader on the CD. Not a problem, but it made me smile when I saw it.

There was also a problem near the end of the installation. It asks what additional software you want to install, but any attempt to install additional software fails. Accepting the default set of software works fine though.

So, after figuring all of that out...

Hurd 2013 - 2. first login


I was running the Hurd.

Post-Install Tweaks

During the boot process, /proc errors litter the screen. It turned out that the /etc/fstab had no entry for /proc, so I added one:

proc /proc procfs defaults 0 0

But there was still some issue. Attempts to mount /proc failed.

mount: cannot start translator /hurd/procfs: Translator died


Good example there though. A system with a monolithic kernel might have crashed entirely.

I did a bunch of research and digging around but I never got it working. /proc did work in 0.3 though, so I guess that's a regression.

On the plus side though, /etc/network/interfaces worked just like in other Debian releases, and I was able to use it to give the system a static IP. In 0.3 I'd had to set the IP address manually using fsysopts, but not in 2013.


I didn't have to tweak much else. I'd created a user for myself during installation, sudo was installed by default, and the ssh server just worked.

The Web

Wget was installed by default, but nothing else. I installed lynx, iceweasel and apache2 using apt-get, just like on any other Debian system.

Lynx worked. X-forwarding didn't, so I couldn't run iceweasel yet.

Apache was tricky to configure. The config files are spread out over a bunch of different directories. I guess it's the same on modern Debian Linux systems too but it was tricky to find everything.

I actually kicked apache around for a while. I'd configured it correctly, as it turned out, but the server wouldn't start until after I installed the apache2-dev, libapr1-dev and php5-dev packages. Apparently one of them added some important file. Even then though, the server would run, but wouldn't run CGI's. I eventually rebooted for an unrelated reason and was surprised to find CGI's working after the reboot, with no changes to the apache configuration.


X Windows

In 0.3, I'd had a hell of a time getting X windows working. I eventually got twm running, but nothing else.

In Hurd 2013 it was easy to get XFCE running.

Hurd 2013 - 3. xfce

I just installed the xorg and xfce4 packages, created an .xinitrc file with:


And ran startx.

There is some security setting though, that prevents a non-root user from running X on the console. I'm not sure if Debian Linux has the same issue or not. I poked around a bit but never figured it out.

I didn't bother getting a graphical login working because I didn't plan on running X most of the time.

Xterm and the other basic XFCE components worked fine but my luck with other software wasn't as good.

X-forwarding hadn't worked over ssh. I'd hoped to be able to run iceweasel in the X session but unfortunately it failed to start there too.

apt-cache search turned up and libreoffice but it appeared that some of the necessary dependencies were unavailable.

I tried Gnome and KDE too but, as with the office packages, it appeared that some of their dependencies haven't been built yet, or at least haven't made it into the repository.


Well, who knows. I'll give it a few months and try again.


The development tools, languages and libraries that I needed were all available - gcc, make, cvs, vim, pcre, ssl, readline, perl, python, php, ruby, tcl, erlang, mysql, postgresql, sqlite, freetds, firebird, odbc and mdbtools. Yeah, there's no Oracle, Sybase or DB for Hurd, but that's kind of the point of SQL Relay. One of them at least.

Hurd 2013 - 4. sqlrsh

Oracle from Hurd!

One of the shortcomings of Hurd 0.3 was lack of support for SysV IPC - semaphores, shared memory and message queues. I'd hoped that Hurd 2013 had them, but I was out of luck there:

dmuse@hurd2013:~$ ipcs

kernel not configured for shared memory

kernel not configured for semaphores

kernel not configured for message queues

So, no SQL Relay server.

I looked around a bit for how to recompile the kernel. Maybe IPC is supported, just not enabled. I didn't get too far with that though.

Something to do later.


The most obvious improvements over 0.3 were support for /etc/network/interfaces and XFCE. Those are pretty big steps from a usability standpoint. I'm sure that a bunch of stuff was improved behind the scenes too, but those stood out.

It's unfortunate that /proc no longer worked, but hey, sometimes you've got to break a few eggs.

The only serious problem I ran into was general stability. My 0.3 VM sits idle most of the time. Every now and then I do an automated build on it, and it's always there waiting. 2013 doesn't seem so stable. I've had to restart the VM after leaving it idle for a few hours, several times, and sometimes it hangs at boot and has to be restarted again. It kind of feels like a filesystem problem, and a few times I've fsck'ed it and then fsck'ed it again, only to find more errors on the second pass. Hmmm. I see tune2fs, mkfs.ext3 and mkfs.ext4, maybe I can migrate the filesystem to ext3 or 4. It's not clear whether the kernel supports those filesystems or not though.

Fingers crossed.

Saturday, April 12, 2014

Retrocomputing with Personal Oracle7 and SQL Relay

I recently got SQL Relay running against Personal Oracle 7.2.2. I did it for fun, but it demonstrates a valuable feature of SQL Relay: Proxying - accessing databases from unsupported systems.

fedora 20 x64 - Oracle 7.2.2

Exercises like that often fall under the category of hobbyist retrocomputing but the reality is... old systems refuse to die.

Maybe you have an old app still lurking around, running against Oracle7 and you can't upgrade the DB for some reason. Your modern apps all run against Oracle 12c, but it would sure be great if they could pull data out of that old database. Unfortunately OCI stopped supporting Oracle7 about 10 years ago. You might even have an old copy of Oracle 8i lying around. If it wasn't so expensive, you'd have chucked it for all the good it does you today.

Relay to the rescue!

In my experiment, I accessed Oracle7 from Fedora 20 via an instance of SQL Relay running on Redhat 6.2 (not RHEL, but old, pre-Fedora Redhat 6.2) using OCI from Oracle 8.1.7. Of course, I wouldn't recommend using Redhat 6.2 in production, but you could run a still-supported operating system like Solaris 8 or 9 x86 in a VM and get the same result.

Retrocomputing with Personal Oracle 7.2.2


The first version of Oracle that I ever used was version 7.3.4 for SCO OpenServer 5.0.0. I think. Something like that. It had an odd installer that required the screen resolution to be set to 256 colors. Only 256 colors. No more, no less. It also assumed you were using NIS and getting the installation to run without it required copying the entire CD onto the hard drive, tweaking the install script, and then running it from there, rather than from the CD. This was back in the late 90's, when a 1.6G hard drive was huge and you could easily run out of space during the installation because of having had to copy the CD onto the local drive.

Good times.

I've long wanted to relive those days, so I've had an eBay search going for Oracle for a while now. It usually turns up modernish versions, but a month or two ago a seller popped up with a still-shrink-wrapped copy of Personal Oracle 7.2.2.

windows 95 - 3. Personal Oracle 7.2.2

Ha! I'd forgotten about the existence of Personal Oracle.

Back before they gave the DB away for development and non-commercial use, Oracle sold Personal Oracle 7. It was inexpensive, ran on Windows 95, and only allowed a single connection. I guess it was a useful development tool for a lot of people, but back then we ran Unix on the servers and everybody had a Mac on their desk. If we had 3 Windows installations in the whole office, it would have been a lot, so we didn't pay it much attention.

Still though, seeing it on eBay widened my eyes. It was Oracle7, and you rarely run into any kind of Oracle7. I tend to avoid still-shrink-wrapped stuff because some die hard collector might appreciate it more than I do, but...


Finding a Compatible OS

The first hurdle was finding something it would run on. The box said Windows 95 and didn't mention anything else.

I'd recently gotten Windows 3.1 off of eBay, a copy of NT 4.0 came with Visual Studio 5 that I bought ages ago, I inherited a copy of Win2k when a company I used to work for went out of business, and there's a Windows 98 upgrade CD in my folk's basement, but I was all out of Windows 95.

Windows 3.1 is 16 bit. No chance there.

I tried it with my NT and Win2k VM's, but no luck. It doggedly refused to install. I didn't even try Windows 98 because I'd have needed a copy of Windows 95 just to install it.

Windows 95 is a little sketchy. There are probably a hundred listings for it on eBay but about 95% of those are just the disk that came with some old computer and marked "for distribution with a new pc" (or something like that) and I'm not 100% sure of the legalities involved in buying one of those. It seemed like the remaining 5% were all upgrades too, so I waited. And waited. And waited... And eventually did some research. Turns out Microsoft only sold upgrades. Ha! No use waiting any longer.


Getting it to install in VMware was a little tricky. The VM configuration was straightforward but the CD predates bootable CD's and it didn't come with a boot floppy. I couldn't just start the install and insert a Win 3.1 disk to prove I owned one. I had to run the install CD from an already-fully installed version of Windows 3.1.

More good times. But I got it going.

windows 95 - 1. installed

Sort of. Windows 95 predates VESA. I ended up with a 16 color, 640x480 desktop and all of my attempts to install VMware-tools or other third-party SVGA drivers failed.

The CPU was slammed at 100% too. Apparently Windows 95 didn't idle the CPU. There are free utilities for DOS and Win 3.1 to take care of that, but the only one available for Windows 95 cost money and did a bunch of other stuff related to overclocking.

Oh well. Maybe I'll buy it later.

Windows 95's default network configuration is odd by today's standards too. I removed IPX/SPX and NetBEUI and installed TCP/IP. I gave it a static IP and played around with telnet, ftp and a couple of browsers. Netscape 6.0 installed and ran just fine. So did IE 5.5. Aside from the 16 colors, they were both even semi-usable.

windows 95 - 2. ie5.5

I'd have preferred better resolution, and for some reason the daylight-savings-time handler kept resetting the date to sometime in 1988 every time I'd reboot, but things worked well enough to do what I really wanted to do.

Oracle Installation

Installing Oracle on Linux or Unix is a ten-thousand step process. Well, not literally, but it can be a lot of work. Installing on Windows is a breeze.

You just click stuff, answer some intuitive questions, and voila...

windows 95 - 4. oracle install

Nothing too it.

Poking Around

I remember various versions of Oracle 8 up and filling my start menu with tons of software. Personal Oracle 7 is much more spartan.

On the server side, you get:

  • Start Database
  • Stop Database
  • Backup Manager
  • Recovery Manager
  • Personal Oracle7 Navigator a few docs.

On the client side, you get:

  • SQL Plus
  • SQL Net Easy Configuration a few docs.

This is all from way before Oracle got interested in Java, so the Navigator is a native Win32 app.

windows 95 - 5. oracle navigator

It's fairly rudimentary too. You can create, list and destroy database objects, but you can't run queries.

Running queries requires SQL Plus.

I'd used the "local connection" object in the Navigator to access the DB, but SQL Plus requires a username, password and SID and I wasn't sure what SID corresponded to "local connection". The SQL Net configurator revealed a tcp-loopback SID though, so I used that, plus the standard scott/tiger credentials, and before long I was looking at the familiar example database.

windows 95 - 6. sqlplus

Ha ha!

system/manager worked too and the system tables were familiar.

Remote Access

Ok, so I could access the DB via the "local connection" and via the tcp-loopback SID. I presumed that the local connection was happening through some kind of IPC and that the tcp-loopback connection was happening through a TCP listener. Was the TCP listener accessible from the outside?

Well, I could telnet to port 1521 from another machine, so maybe it was.

It's a-whole-nother story or two, but I have various old versions of Oracle running on various old versions of Redhat linux, from before the Fedora project. I added this SID...

orcl =
(ADDRESS = (PROTOCOL= TCP)(Host= 1521))
(CONNECT_DATA = (SID = orcl))
) tnsnames.ora on a couple of them, and gave sqlplus a try.

No problem from Oracle 8.0.5 on Redhat 5.2:

[dmuse@redhat52 admin]$ sqlplus system/manager@orcl

SQL*Plus: Release - Production on Fri Apr 11 23:52:32 2014

(c) Copyright 1998 Oracle Corporation. All rights reserved.

Connected to:
Personal Oracle7 Release - Production
With the distributed and replication options
PL/SQL Release - Production


And it worked equally well from Oracle 8.1.7 on Redhat 6.2.

But Oracle 9 on Redhat 9 wasn't as happy.

[dmuse@redhat9 dmuse]$ sqlplus scott/tiger@orcl
SQL*Plus: Release - Production on Fri Apr 11 23:56:36 2014

Copyright (c) 1982, 2002, Oracle Corporation. All rights reserved.

ORA-24439: Connections to Oracle7 server are no longer supported

And, true to the licensing scheme described in the docs that came with the media, only one concurrent connection is supported. Second attempts fail with:

ORA-12500: TNS:listener failed to start a dedicated server process

Limitations notwithstanding, I was able to create a tablespace and schema for a test user:

CREATE TABLESPACE testtablespace
DATAFILE 'C:\oracle\testtablespace01.dbf'

CREATE TABLESPACE testtablespacetemp
DATAFILE 'C:\oracle\testtablespacetemp01.dbf'

CREATE USER testuser IDENTIFIED BY testpassword
TEMPORARY TABLESPACE testtablespacetemp;



The only trouble that I had was that I usually use the NOLOGGING option with CREATE TABLESPACE, and it wasn't supported.

It seems like Oracle7 did support that option though, so maybe that's specific to Personal Oracle 7. No idea.

SQL Relay

Hooking up SQL Relay to the DB was easy. I configured it to only start 1 connection, used the testuser/testpassword credentials to log into Oracle, and used the orcl SID that I'd defined earlier.

I could only do this on my Redhat 6.2/Oracle 8.1.7 and Redhat 5.2/Oracle 8.0.5 VM's though, as newer versions of Oracle refused to connect to the DB.

Still, I was able to access the DB from Fedora 20 x64 through the relays running on those old VM's.

fedora 20 x64 - Oracle 7.2.2

And with a few tweaks, my standard Oracle test script for SQL Relay ran.

success success
success success success
success success
success success success success success success success success success success success success
success success success success success success success success success success success success
success success success success success success success success success success success success

The few tweaks I did make had to do with the limitations of Oracle7. Specifically:

  • The default date format is DD-MON-YY with a 2-digit year.
  • VARCHAR2's have a maximum size of 2000 bytes.
  • Multiple connections aren't supported.
  • Output bind cursors either don't work, or work very differently. The PL/SQL that I used for Oracle 8+ was rejected.

SQL Relay appears to work with Oracle7. Personal Oracle 7 has some limitations, but none that make it painful to play with. Windows 95 is a little quirky, but I suspect that if I look around I'll find solutions.

All-in-all, a fun experiment. Well worth the effort involved.