SSD swap
Juno was constructed with an Intel X25-V, a value-oriented 40 gigabyte SSD.
This device was large enough to hold the operating system (Linux) and applications, but all my user data was stored separately, on a regular spinning-platter hard drive. SSD drives were and are more expensive than regular hard drives, although now not so much as 3 years ago. Having the operating system and apps on the SSD made Juno fast to boot and fast to launch applications.
My choice to replace it was a Samsung 830, the 128 gigabyte version.
With this size, I could keep not only the operating system and applications on the SSD, but also all my user data except the extensive photograph folder, which remains on the hard drive. The Samsung device, being of a newer generation and not designed as a "value" item (not compromised to reduce cost) is, according to the specs, three times faster reading data and ten times faster writing data than the X25-V.
Fortunately, I also discovered while researching which SSD to purchase that SSDs using the new SandForce controller (interface between the SSD memory and the rest of the computer) did not play well with the I/O chip on my motherboard, the Nvidia MCP79. Many SSDs such as Intel, Corsair, and others now use the SandForce controller.
The MCP79 supports device speeds of 1.5 Gb/sec and 3.0 Gb/sec. (The newer SSDs also support 6.0 Gb/sec.) When the MCP79 negotiates the connection speed with a SandForce controller, they end up using the 1.5 Gb/sec setting instead of 3.0 Gb/sec! The Samsung SSDs use a Samsung controller and have no such problem. This, plus the excellent reviews of the 830, made the choice an easy one.
When I took the faceplate off Juno, it was clear that the dust filter needed to be cleaned again.
A dust vacuum wasn't sufficient; I ended up removing the filter and washing it.
Juno is constructed with the SSD installed in a drive bay underneath the optical (CD/DVD) drive. Thus, the first step was to remove the tray for the drive and disconnect the cables.
Here we see the Intel X25-V still in the drive bay.
Installing the Samsung was just a matter of removing the Intel (4 screws) and sliding in the Samsung, reinserting the 4 screws and reattaching the cables. By then the filter was dry, and I could reassemble Juno.
The upgraded system is certainly snappier than before. I'm pleased with it.
BIOS Upgrade
My motherboard, the Zotac gf9300-i-e, theoretically supported both methods of chatting with bulk storage devices such as hard drives and SSDs. The ATA specification is the much older of the two, and to support advanced features of newer hard drives and of SSDs there is the newer AHCI interface. However, when first building Juno, it became clear that the AHCI option didn't work. In fact, if I enabled AHCI in the motherboard's BIOS (embedded firmware), the computer would no longer see any of the attached devices: no hard drive, no SSD, no CD/DVD drive. Urk! I proceeded in ATA mode, which seemed to work well enough.
After swapping the SSDs I decided to try AHCI mode again. Same result, very disappointing. However, this time I stumbled across a Zotac forum posting mentioning a BIOS upgrade that had come out a few months after I assembled Juno, which solved this problem. There were some technical hurdles to overcome -- this motherboard, unlike some others, won't recognize a BIOS upgrade automatically if a USB stick is plugged in -- but eventually I applied the new BIOS, and voilá, AHCI mode was good!
Installing XUbuntu 12.10
I had ceased installing newer versions of Ubuntu, sticking with 10.10, because of the controversy over the new default user interface, Unity, and the changes in the GNOME desktop between version 2 and 3. I was happy with my GNOME 2.x desktop, and 10.10 was supported with updates and security patches for 18 months. Then those stopped. After two years on 10.10, Juno's software was showing its age and some new software packages would not install.
I had played around with some other packages on my ancient laptop, primarily LMDE (Linux Mint Debian Edition) with its Cinnamon and Mate desktops. But I wasn't completely pleased with Cinnamon or Mate, which were efforts to maintain a pre-Unity desktop environment. Finally I went with XUbuntu, which is an Ubuntu distribution that also installs a more traditional and lightweight desktop manager, xfce. I have a few quibbles with it, but xfce was my best fit.
Here are some miscellaneous points I noticed:
- The system will now wake up from sleep (suspend to RAM) when I press any key on the keyboard. Previously I had to push the power button. Hurrah!
- xfce can use either xfwm4, the standard xfce desktop compositor, or compiz, a fancier one. (Desktop compositors manage visual issues such as overlapping windows, partially transparent windows, wobbly windows, multiple workspaces, etc.) I finally decided that xfwm4 was more stable; occasionally windows would go black under compiz. I was willing to give up my wobbly windows for reliability.
- Some of the programs I use on a regular basis, such as the GIMP, an open-source Photoshop, were not installed by default. They can still be installed from the Ubuntu repositories, so it's not a large issue.
- LibreOffice, as distributed by Ubuntu, would crash on some of the spreadsheets I had created in the Ubuntu 10.10 environment. I filed a bug report, and it may be fixed in the next release. In the meantime, I installed OpenOffice, which worked just fine. Because of a file name conflict, I had to remove LibreOffice before I could install OpenOffice.
- The xfce desktop has, unfortunately, a mandatory snap-to-grid feature. That is, any icons/documents placed on the desktop are automatically lined up to use the center of one square of an invisible checkerboard dividing the desktop. I wish I could turn it off, as I could in GNOME 2.x. But I don't have very many desktop items anyway, so it's just an annoyance rather than an impedance to my workflow.
- The version of the C++ compiler supplied jumped forward two years as well. One of my programming projects would crash until I changed some global constructor usages that had worked OK with the older compiler.
- The audio/video command-line program ffmpeg is now deprecated, and a couple of the arguments have changed. The new version fails on some of my video projects where the old one did not -- arrgh! However, the program avconv, the immediate descendant of ffmpeg, did work. It leaves me wondering how or why the maintainers managed to break ffmpeg.
Going Forward
This is probably the end of the Juno upgrades. If it were inexpensive, I would increase the memory (RAM) from 4 GB to 8 GB, because sometimes when working on blog entries (many tabs open on the Web browser) and processing photos or videos Juno starts to swap (move some programs to disk to make room for other programs to run). This slows things down. However, this motherboard takes an obsolescent memory, DDR2-800, which is pricey when available. Perhaps next fall or winter I will build my next computer based on the upcoming Haswell generation of Intel CPUs, and I'll put 16 GB of memory in it. That would be enough RAM to allow me to experiment with virtual machines.