Assembling Juno: Installing and Results

With the first power-on, juno responded as hoped: the BIOS identified all the peripherals correctly, and then noted that no device contained any operating system to boot. I did a restart and went into the BIOS to change several settings (time, splash screen, boot order, etc.) and rebooted with a CD. Or rather, I tried to reboot with a CD. Even though I tried several bootable CDs, juno refused to even try to boot from them. It was as if juno would boot only from the first device and failed to check the others. Time to go into the BIOS again. But wait ... the system no longer responded to the DEL key. I couldn't get into the BIOS, even with several attempts! Eventually I had to switch a jumper to reset the motherboard to its factory default settings, and then, as if having enjoyed the attention, juno has never since failed to recognize a bootable device (including a USB memory stick) or to respond to the DEL key. I have changed most of the BIOS parameters again (one at a time), with no ill effect. Sometimes I think computers must go through a learning process when they first wake up or move to a new environment, and exhibit behaviors that disappear after a single baffling appearance.

The first job was to properly set up the SSD (solid state, or flash memory, drive). Including this part was one of the two less conservative items in juno's constitution. SSDs are relatively new, and early adopters (the last 18 months) have seen drives that slowed down over time, turned into expensive paperweights after applying a manufacturer's upgrade, and so forth. By now I hoped that the worst problems had been solved (or identified) by the truly early adopters. Because these devices, although blazingly fast compared to spinning platter hard drives, are very expensive, I stuck to a 40GB 'value' model by Intel (the writes are much slower than the reads, although still faster than a hard drive). I had to create a bootable CD from an image downloaded from the Intel website, in order to upgrade the device's firmware. Fortunately, this went without a hitch. Then I booted Ubuntu from a memory stick, and manually partitioned the SSD, not leaving that to the automated install. It gets very technical, but it's a good idea to align the partition with the SSD erase-size boundaries, and where possible, make file systems in those partitions with tweaks that also are driven by the erase block size. I hope that the next time I build a computer the SSD quirks will either be fixed, or compensated for by the operating system.

Then the Ubuntu install began. Here is the second of my two "leaps" -- I was installing 64-bit Ubuntu. Microprocessors began to have 32-bit capability in the mid-1980s, and 32-bit addresses meant that they, and programs that ran on them, could theoretically recognize up to 4 gigabytes of RAM. For the last several years processors have had 64-bit capability, although consumer machines typically continued to run with 32-bit operating systems and programs. However, with memory becoming cheaper and cheaper, and programs and data sets becoming larger and larger, 4 gigabytes of RAM could be a limitation. Also, for some tasks the 64-bit versions of the same program can be faster than the 32-bit. I decided to take the plunge and install the 64-bit version of Ubuntu with 4 GB of RAM in juno. For technical reasons that are historical -- PCs just grew that way from their origins in the 1970s -- a 32-bit operating sytem would actually be able to use no more than about 80% of that 4 GB.

The install went smoothly. (One does always need to tweak and individualize things.) I had been most apprehensive about Adobe Flash, because Adobe Flash for 64-bit Linux was available only as an 'alpha' to be downloaded from Adobe's web site. However, so far this has worked flawlessly, beyond my expectations. The other 64-bit issue was that there is no 64-bit version of Google Earth for Linux, at least not yet. Some have gotten the 32-bit version to run on a 64-bit system with some extensive workarounds, but for now I'm content to wait for a real 64-bit version.

At this point I noticed some oddities. The CPU temperature was 42°C, which I thought quite high for idle. Then I discovered that it was always 42°C, regardless of load or CPU speed -- the sensors were stuck. I gather this is a not-common but not-rare fault in some of the Intel processors of this generation. At least I was getting good temperature data from the combined controller and integrated graphics chip (nVidia MCP79), and from the 500 GB hard drive, so if things were getting hot I would have some warning.

The next oddity was that the BIOS showed my 1150rpm fans running thousands of RPMs faster than that:

Another sensor issue, fan quirk, or BIOS flaw, no doubt. It doesn't reduce the functionality of the system. I usually adjust the fan speeds several times at the beginning, to reach a balance between low-enough noise and good-enough cooling, and then leave them alone.

Through all this work the blue LEDs for the power button and the disk-activity indicator were bugging me. They were way too bright! So I put a little electrical tape over the disk activity light, blocking most of it, and put a disk of black construction paper in the center of the power button.

Here are a couple of images of at juno at work (taken with flash).

I should point out the small keyboard. It's a "Happy Hacking" keyboard for people, such as me, who don't use the numeric keypad, or have a small desk space, or prefer the traditional UNIX key locations for ESC, CONTROL, and the insidious CAPS LOCK.

Regarding the "faster" goal, I don't have any handy Linux benchmarks. Of course, with the SSD, booting now takes only 31 (plus or minus) seconds from power-on. Of that, 19 seconds are the motherboard waking up devices and taking inventory, and only 12 seconds to boot Linux and put up the login screen. Applications start a lot faster too. Let's just compare the specs. The prior computer, tbroma, had a CPU running at 2.13 GHz with a 667 MHz FSB (memory interface) and DDR2-667 memory. Juno runs at 2.93 GHz with a 1066 MHz FSB and DDR2-800 memory. It's gotta be faster!

What about the final goal, "cooler"? Well, tbroma would draw 42 watts when started up and logged in but not doing anything in particular, a state referred to as "idle". juno draws only 30 watts, measured by the same kill-a-watt meter. When running a CPU stress test program (from the Mersenne Prime search), tbroma, in the days when I could undervolt it, drew 77 watts. In the last year, when undervolting through Ubuntu finally became just too difficult, tbroma reverted to drawing 90 watts. juno sips 63 watts under that test.

And here's one of the best surprises. In tbroma's early days, I tried to get 'sleep' to work. Joan's iMac does 'sleep' very well; just hit a key or move the mouse, and in two or three seconds your desktop is back. I could never get tbroma to wake up properly from a sleep; it always thought it had been rebooted without a proper shutdown. Perhaps it was the motherboard, perhaps it was the operating system of three years ago, but I gave up on it. Guess what? Sleep on juno works, although it is not as slick as the iMac. I must press the power button, and eleven seconds later, after a few messages flash by on the screen, too fast to read, my desktop is back. (Complete with 'network disconnected' and 'network reconnected' notifications.) While asleep, juno draws only 5 watts! Heck, the power drain for just being plugged in while off is 4 watts. I've got juno set to automatically go to sleep after 30 minutes of no activity.

Can I repeat "faster, smaller, cooler" in two or three years? I think so. Smaller will be the biggest challenge, but it can be done, as with this system, which is about the same width and depth but shorter than juno. As infrequently as I use the CD/DVD drive, I could employ an external optical drive on those occasions where I needed one, which would free up space and reduce the cable count. As components get smaller and more capable, where's the limit?!