Ubuntu 5.10 on the Ultra 20 (or, why I prefer Java's client compiler over the server compiler)

Flush with success from running the Ubuntu 5.10 live CD on my Ultra 20, I tried the real thing.

Installation was similar to the live CD. It took about 20 minutes, and a few more questions were asked. The expected "which time zone?" question was one, and there was one difficult question about how I'd like to format my disk. More on that later.

In contrast to Solaris, I was asked for a hostname, the name of a user, and a password for that user. There was no need for a root password because you're supposed to use sudo(1), another thing that Solaris gets wrong. (Logging in as root is so 1970s. It seems to me analogous with the mistake dynamic languages like Ruby make in forcing you to pay for stuff even when it's the last thing you need. In Ruby's case, you get no static checking in return for dynamism you hardly ever need and could easily ask for. In Solaris' case, you get all the dangers of being logged in as root in return for not having to explicitly annotate each command with "sudo". Not good trade-offs.)

Ubuntu doesn't include an SSH server, nor any development tools. Mac OS makes the former a check box item (the server's installed, but not activated by default) in a handy dialog that covers all network services. I wasted some time looking for the equivalent check box before asking Google and finding out that I needed apt-get(1).

So, here's the list of packages I need to do anything (the lack of each of these is a reason why I've no time for Win32):

# For remote use:
sudo apt-get -y install openssh-server
# For editing:
sudo apt-get -y install exuberant-ctags iamerican
# For general development:
sudo apt-get -y install build-essential make ruby ri g++
# For version control:
sudo apt-get -y install bzr cvs subversion
# For C/POSIX man pages:
sudo apt-get -y install manpages-dev glibc-doc
# For X11 development:
sudo apt-get -y install x-dev libx11-dev
# For building yacc parsers:
sudo apt-get -y install bison
# For building Python programs that have C extensions:
sudo apt-get -y install python-dev

Given those, I could scp(1) my .bash_profile, .bashrc, .inputrc, and .ssh/ over, and get on with downloading Sun's JDK.

That was where things started to go weird. At work, where I use the stuff I write at home, it takes 4s to build one of my projects on Debian/Intel. With Solaris/Opteron on the Ultra 20 at home, the same build took 2s. With Ubuntu/Opteron, it took 8s. I didn't know how modern Linux and Solaris compared, but I expected them to be about the same, so this was Linux performing four times slower than I'd expected.

Not good.

Unfortunately for me in diagnosing the problem, there were a lot of variables. Three different OSes, three different kernels, three different file systems. Three different versions of GNU make, and three different versions of Sun's JDK. GNU make was easily eliminated by writing the output of make -n to a file and examining and running that. I installed Sun's 1.5.0_06 (instead of the 1.5.0_05 I'd been using) at work, with no change. So it wasn't like there was a major javac(1) performance regression (I'd already worked out that was where all the time was going). I didn't have much to lose, so I re-installed Ubuntu without LVM. No change.

Then I noticed that I was running the server compiler. There is no client compiler for amd64. And we all know that the cost of the server compiler is the increased start-up time. Passing -J-server to javac(1) on my work Debian/Intel box confirmed the theory that I probably didn't want the server compiler for this job.

Out of interest, then, I installed the x86 JVM. And got my build time back down where it should be.

At this point, I'd love to know what I was running on Solaris. Had I accidentally managed to install the x86 JVM instead of the amd64 one? We'll never know, because I had to reformat to install Ubuntu. Google doesn't seem to think there's a client compiler for Solaris/amd64, or that the Solaris/amd64 server compiler is ridiculously faster than the Linux/amd64 server compiler.

I wondered if there was any reason why I'd want to use an amd64 JVM build, given that I don't run any enormous J2EE webturds. One of my Terminator co-conspirators pointed out that, yes, there is: JNI libraries. Your JNI library needs to match your JVM, and that might be awkward to ensure without the "appropriate" 64-bit JVM for your architecture.

For the record, I think Solaris was a shade faster for my usual builds, but not to the extent that I'd be prepared to put up with the pain of its userland, or the lack anything even remotely approaching apt-get(1). Blastwave just isn't in the same league. Not in terms of range of packages, not in terms of how well what few packages there are work (the Ruby package had a dependency on a library it didn't contain, and after the last time I updated the Firefox package, it would hang on start-up), and perhaps most importantly, it's not the One True Way on Solaris; it's Yet Another Way That Doesn't Quite Solve The Problem.

The "software update" system on Ubuntu, which seems to be the Synaptic front-end to apt-get(1) is pretty good. I'd read about it on the web before, and had tried it on my Debian box at work, and been completely underwhelmed. When I ran it, it seemed to be a GUI equivalent of dselect(1), one of the worst programs of all time, both in idea and execution. I didn't see the point and never ran it again. On Ubuntu, it's set to run itself and announce updates like Mac OS' Software Update. That's the main thing I haven't liked about using apt-get(1) for everything in the past: it doesn't have a push side. Synaptic provides one, and it's pretty good. It's a little more complicated than Apple's effort, but then it tries to provide support for extra sources of packages, and that's one thing Apple don't do which I think annoys most third-party developers. (Even if you can understand why Apple might not want to sanction third-party packages in such a way, Synaptic does seem to keep the distinction between Ubuntu and external packages reasonably clear.)

Overall, I'm happy enough with Ubuntu that I'm not about to reformat for the third time in three days.

(As for NTP, it turns out to not be the real thing. If you choose the "Time and Date" administration option, there's a check box a with Mac OS. Unlike Mac OS, checking the box brings up a poorly-worded dialog mumbling something about you needing to "install and activate NTP support in the system to enable synchronization of your local time server with internet time servers". My local what? Anyway, click the button and it will do it for you, but will inexplicably fail to check the check box you first clicked on. Clicking on the check box again brings up the same "NTP support is not installed" dialog, and clicking "Install NTP support" for a second time does nothing but close the dialog. Re-start the "Time and Date Settings" program, and you can check the check box. Strangely, that leaves you with no servers selected, and there's no advice about how many upstream servers to synchronize with. So, no, this isn't a patch on Mac OS. But Solaris can consider itself knocked to the ground and urinated upon while all the other OSes stand around laughing.)