Technology Tales

A look at Slackware 13.0

Some curiosity has come upon me and I have been giving a few Linux distros a spin in VirtualBox virtual machines. One was Slackware, which reminds me of a fellow university student using it in the mid/late 1990's. Since then, my exploration took me into Red Hat, SuSE, Mandrake and eventually to Ubuntu, Debian and Fedora. Since all of that bypassed Slackware, it was to give the thing a look.

While the current version is 13.1, it was 13.0 that I had to hand, so I had a go with that. In many ways, the installation was a flashback to the 1990's and I can see it looking intimidating to many computer users with its now old-fashioned installation GUI. If you can see through that, though, the reality is that it isn't too difficult to install.

After all, the DVD was bootable. However, it did leave you at a command prompt and I can see that throwing many. The next step is to use cfdisk to create partitions (at least two are needed, swap and normal). Once that is done, it is time to issue the command setup and things look more graphical again. I picked the item for setting the locale of the keyboard and everything followed from there, but there is a help option too for those who need it. If you have installed Linux before, you'll recognise a lot of what you see. It'll finish off the set-up of disk partitions for you and supports ext4 too; it's best not to let antique impressions fool you. For most of the time, I stuck with the defaults and left it to perform a full installation with KDE as the desktop environment. If there is any real criticism, it is the absence of an overall progress bar to see where it is with package installation.

Once the installation was complete, it was time to restart the virtual machine, and I found myself left at the command prompt. Only the root user was set up during installation, so I needed to add a normal user too. Issuing startx was enough to get me into KDE (along with included alternatives like XFCE, there is a community build using GNOME too) for that, but I wanted to have that loading automatically. To fix that, you need to edit /etc/inittab to change the default run level from 3 to 4 (hint: look for a line with id:3:initdefault: in it near the top of the file and change that; the file is well commented so you can find your way around it easily without having to look for specific esoteric test strings).

After all this, I ended up with a usable Slackware 130.0 installation. Login screens have a pleasing dark theme by default, while the desktop is very blue. There may be no OpenOffice but KOffice is there in its place and Seamonkey is an unusual inclusion along with Firefox. Though it looks as if it'll take a little more time to get to know Slackware, it looks good so far; I may even go about getting 13.1 to see how things might have changed and report my impressions accordingly. Some will complain about the rough edges that I describe here but remarks about using Slackware to learn about Linux persist. Maybe, Linux distributions are like camera film; some are right for you and some aren't. Personally, I wouldn't thrust Slackware upon a new Linux user if they have to install it themselves, but it's not at all bad for that.

If all else fails...

Two problems have come my way that were resolved by removing configuration files and going again. Both affected Linux installations that I have. The Ubuntu installation on my main PC is working well, but I ran into trouble starting up NetBeans 6.8. No GUI would ever appear but taking away the .netbeans folder from my home area allowed a fresh start with the IDE starting up as it should. To date, not all the various projects that I have are restored, but that can be done as I go along. Plugins for PHP development needing reinstatement, but that was another easy thing to achieve; just go to Tools > Plugins on the menus and work with the dialogue box that appears to download and install the needful.

The inspiration for taking the configuration folder from the home area came from needing to address a misadventure with a Debian VM. Perhaps foolishly, I went using gconf-editor on there and messed up the appearance of the terminal window with whatever change I made. Getting rid of the .gconf folder restored order with its recreation by the system. Next time, remembering what changes have been made and reversing them might be the best course of action...

Upgrading to Fedora 13

After having a spin of Fedora's latest in a VirtualBox virtual machine on my main home PC, I decided to upgrade my Fedora box. First, I needed to battle imperfect Internet speeds to get an ISO image that I could burn to a DVD. Once that was in place, I rebooted the Fedora machine using the DVD and chose the upgrade option to avoid bringing a major upheaval upon myself. You need the full DVD for this because only a full installation is available from Live ISO images and CD's.

Since all was graphical easiness, I got back into Fedora again without a hitch. Along with other bits and pieces, MySQL, PHP and Apache are working as before. If there was any glitch, it was with NetBeans 6.8 because the upgrade from the previous version didn't seem as complete as hoped. However, it was nothing that an update of the open source variant of Java and NetBeans itself couldn't resolve. There may have been untidy poking around before the solution was found, but all has been well since then.

Solving an upgrade hitch en route to Ubuntu 10.04

After waiting until after a weekend in the Isle of Man, I got to upgrade my main home PC to Ubuntu 10.04. Before the weekend away, I had been updating a 10.04 installation on an old spare PC and that worked fine, so the prospects were good for a similar changeover on the main box. That may have been so, but breaking a computer hardly is the perfect complement to a getaway.

To keep the level of disruption to a minimum, I opted for an in-situ upgrade. The download was left to complete in its own good time, and I returned to attend to installation messages asking me if I wished to retain old logs files for the likes of Apache. When the system asked for reboot at the end of the sequence of package downloading, installation and removal, I was ready to leave it do the needful.

However, I met with a hitch when the machine restarted: it couldn't find the root drive. Live CD's were pressed into service to shed light on what had happened. First up was an old disc for 9.10 before one for 10.04 Beta 1 was used. That identified a difference between the two that was to prove to be the cause of what I was seeing. 10.04 uses /dev/hd*# (/dev/hda1 is an example) nomenclature for everything, including software RAID arrays ("fakeraid"). 9.10 used the /dev/mapper/sil_**************# convention for two of my drives, and I get the impression that the names differ according to the chipset that is used.

During the upgrade process, the one thing that was missed was the changeover from /dev/mapper/sil_**************# to /dev/hd*# in the appropriate places in /boot/grub/menu.lst; look for the lines starting with the word kernel. When I did what the operating system forgot, I was greeted by a screen telling of the progress of checks on one of the system's disks. While that process took a while, a login screen followed, and I had my desktop much as before. The only other thing that I had to do was run gconf-editor from the terminal to send the title bar buttons to the right, where I am accustomed to having them. Since then, I have been working away as before.

Some may decry the lack of change (ImageMagick and UFRaw could do with working together much faster, though) but I'm not complaining; the rough of 9.10 drilled that into me. Nevertheless, I am left wondering how many are getting tripped up by what I encountered, even if it means that Palimpsest (what Ubuntu calls Disk Utility) looks much tidier than it did. Could the same thing be affecting /etc/fstab too? The reason that I don't know the answer to that question is that I changed all hard disk drive references to UUID a while ago, but it's another place to look if the GRUB change isn't fixing things for you. If my memory isn't failing me, I seem to remember seeing /dev/mapper/sil_**************# drive names in there too.

Moving application title bar buttons on GNOME desktops

A recent look at how Ubuntu 10.04 development is getting on confronted me with an interface situation to which I am not accustomed: title bar buttons at the left. The usual combination of buttons for maximisation, minimisation and closure were there in their usual order but at the left of the window. While this is the where you find them on OS X, I prefer the Windows convention and placed them to the right again.

To achieve that end, I ran gconf-editor from the command line using my usual user account (not sudo; that doesn't seem to work) and made my way to apps -> metacity -> general. Once there, I sought out the button_layout property and moved the colon in the value from the left to the right. In other words, I started with this:

maximize,minimize,close:

and changed it to this (note the position of the colon in the actual string):

:maximize,minimize,close

If you ever find yourself wanting to change things from the Windows convention to the Apple one, just reverse what I did. As an aside, you also can swap the button order too if you like. After all, it's just a text field that you can edit, and the screen immediately refreshes when you hit the Return key after completing the edit.

As a more general observation, if Ubuntu 10.04 does come out using the OS X convention for title bar button placement, I could see others like wanting it changed back and that's why I am sharing it here. Surprising users in this way, especially after the 9.10 release's attracting some adverse comments, would not be all that advisable. The issue may be easy to address, but that's small comfort when you release how easily users are discouraged.

Nevertheless, 10.04 is an LTS release and what I have seen so far looks polished; there may be no splash screen at boot and shutdown time for what I am running (I am sticking with acquiring upgrades every so often instead of periodic re-installation from a new disk image) but that's a minor matter.

For the sake of not turning over the apple cart, I may have left off VirtualBox Additions, and things look steady enough so far. In fact, I am writing these words using Firefox 3.6 on there. Accompanying that is OpenOffice 3.2, but things do not look so different apart from these, a reassuring observation. While there may be an emphasis on purple in the colour scheme at the time of writing, that could change yet. 9.10's course had plenty of that, so I am willing to be patient. After all, there's more than a month to go yet, before the final cut is available for general use.

Command Line Software Management

One of the nice things about a Debian-based Linux distribution is that it is easy to pull a piece of software onto your system from a repository using either apt-get or aptitude. While some may prefer a GUI, but I find that the command line offers a certain extra transparency that stops the "what's it doing?" type of question. That's never to say that the GUI-based approach hasn't a place, and I only go using it when seeking out a piece of software without knowing its aptitude-ready name. Interestingly, there are signs that Canonical may be playing with the idea of making Ubuntu's Software Centre a full application management tool with updates and upgrades getting added to the current searching, installation and removal facilities. That well may be, but it's going to take a lot of effort to get me away from the command line altogether.

Fedora and openSUSE have their software management commands too in the shape of yum and zypper, respectively. The recent flurry of new operating system releases has had me experimenting with both of those distros on a real test machine. As might be expected, the usual battery of installation, removal and update activities are well served, and I have been playing with software searching using yum too.

One thing that has yet to mature is in-situ distribution upgrading, à la Ubuntu. In principle, it is possible, but I got a black screen when I tried moving from openSUSE 11.1 to 11.2 within VirtualBox using instructions on the openSUSE website. Not wanting to wait, I reached for a Live CD instead, and that worked a treat on both virtual and real machines.

Being in an experimental turn of mind, I attempted the same to get from Fedora 11 to the beta release of its version 12. A spot of repository trouble got me using a Live CD in its place. You can perform an in-situ upgrade from a full Fedora DVD, but the only option is system replacement when you have a Live CD.

Once installation is out of the way, YAST can be ignored in favour of zypper and yum is good enough that Fedora's GUI-using alternative can be ignored. It's nice to see good transparent ideas taking hold elsewhere and may make migration between distros much easier too.

You always can install things yourself...

With Linux distributions offering you everything on a plate, there is a temptation to stick with what they offer rather than taking things into your own hands. For example, Debian's infrequent stable releases and the fact that they don't seem to change software versions throughout the lifetime of such a release means that things such as browser versions are fixed for the purposes of stability; Lenny has stuck with Firefox 3.06 and called it IceWeasel for some unknown reason. However, I soon got to grab a tarball for 3.5 and popped its contents into /opt where the self-contained package worked without a hitch. The same modus operandi was used to add Eclipse PDT and that applied to Ubuntu too until buttons stopped working, forcing a jumping of ship to NetBeans.

Of course, you could make a mess when veering away from what is in a distribution, but that should be good enough reason not to get carried away with software additions. With the availability of DEB packages for things like Adobe Reader, RealPlayer, VirtualBox, Google Chrome and Opera, keeping things clean isn't so hard. While your mileage may vary when it comes to how well things work out for you, I have only ever had the occasional problem anyway.

What reminded me of this was a recent irritation with the OpenOffice package included in Ubuntu 9.10 whereby spell checking wasn't working. While there were thoughts about in situ fixes like additional dictionary installations, I ended up plumping for what could be called the lazy option: grabbing a tarball full of DEB packages from the OpenOffice website and extracting its contents into /tmp and, once the URE package was in place, installing from there using the command:

dpkg -i o*

To get application shortcuts added to the main menu, it was a matter of diving into the appropriate subfolder and installing from the GNOME desktop extension package. Of course, Ubuntu's OpenOffice variant was removed as part of all this but, if you wanted to live a little more dangerously, the external installation goes into /opt which means that there shouldn't be too much of a conflict anyway. In any case, the DIY route got me the spell checking in OpenOffice Writer that I needed, so all was well and another Ubuntu rough edge eradicated from my life, for now anyway.

So you just need a web browser?

When Google announced that it was working on an operating system, it was bound to result in a frisson of excitement. However, a peek at the preview edition that has been doing the rounds confirms that Chrome OS is a very different beast from those operating systems to which we are accustomed. The first thing that you notice is that it only starts up the Chrome web browser. In this, it is like a Windows terminal server session that opens just one application. Of course, in Google's case, that one piece of software is the gateway to its usual collection of productivity software like Gmail, Calendar, Docs & Spreadsheets and more. Then, there are offerings from others too, with Microsoft just beginning to come into the fray to join Adobe and many more. As far as I can tell, all files are stored remotely, so I reckon that adding the possibility of local storage and management of those local files would be a useful enhancement.

With Chrome OS, Google's general strategy starts to make sense. First create a raft of web applications, follow them up with a browser and then knock up an operating system. It just goes to show that Google Labs doesn't simply churn out stuff for fun, but that there is a serious point to their endeavours. In fact, you could say that they sucked us in to a point along the way. Speaking for myself, I may not entrust all of my files to storage in the cloud, yet I am perfectly happy to entrust all of my personal email activity to Gmail. It's the widespread availability and platform independence that has done it for me. For others spread between one place and another, the attractions of Google's other web apps cannot be understated. Maybe, that's why they are not the only players in the field either.

With the rise of mobile computing, that kine of portability is the opportunity that Google is trying to use to its advantage. For example, mobile phones are being used for things now that would have been unthinkable a few years back. Then, there's the netbook revolution started by Asus with its Eee PC. All of this is creating an ever internet connected bunch of people, so having devices that connect straight to the web like they would with Chrome OS has to be a smart move. Some may decry the idea that Chrome OS will be available on a device only basis, but I suppose they have to make money from this too; search can only pay for so much, and they have experience with Android too.

There have been some who wondered about Google's activities killing off Linux and giving Windows a good run for its money; Chrome OS seems to be a very different animal to either of these. It looks as if it is a tool for those on the move, an appliance, rather than the pure multipurpose tools that operating systems usually are. If there is a symbol of what an operating system usually means for me, it's the ability to start with a bare desktop and decide what to do next. Transparency is another plus point, with the Linux command line having that in spades. For those who view PC's purely as means to get things done, such interests are peripheral, and it is for these that the likes of Chrome OS has been created. In other words, the Linux community need to keep an eye on what Google is doing but should not take fright because there are other things that Linux always will have as unique selling points. Even though the same sort of thing applies to Windows too, Microsoft's near stranglehold on the enterprise market will take a lot of loosening, perhaps keeping Chrome OS in the consumer arena. Counterpoints to that include the use GMail for enterprise email by some companies and the increasing footprint of web-based applications, even bespoke ones, in business computing. In fact, it's the latter that can be blamed for any tardiness in Internet Explorer development. In summary, Chrome OS is a new type of thing rather than a replacement for what's already there. We may find that co-existence is how things turn out, but what it means for Linux in the netbook market is another matter. Only time will tell on that one.

When buttons stop working...

One of the things that stopped working as it should after my recent Ubuntu 9.10 upgrade was the Eclipse PDT installation that I had in place. Editing files went a bit haywire and creating projects had me pushing buttons with nothing happening. Whether this was a Java or GNOME issue, I don't know, but I found it happening too on openSUSE 11.2 (there should be more on that distro in a later entry). That was enough to get me looking again at NetBeans.

In both openSUSE (NB version 6.5) and Ubuntu (NB version 6.7.1), I plucked the default offering of NetBeans from the respective software repositories and added the PHP plugin in both cases. Unlike when I last gave the platform a go, things seemed to go smoothly, and it looks to have replaced Eclipse for PHP development duties. While project scanning may take a little while, it's far from annoying, a departure from my earlier dalliance with using NetBeans as a PHP editor was stymied by performance that was so sluggish as to make the thing a pain to use. Up to now, NetBeans' footprint when it comes to its use of PC power never was light, so I am wondering if dual-core and quad-core CPU's help along with a copious supply of RAM. Only time will tell if these initial positive impressions stay the course; for now, I'll be keeping an open mind.

Rough?

Was it because Canonical and friends kept Ubuntu in such a decent state from 8.04 through to 9.04 that things went a little quiet in the blogosphere on the subject of the well-known Linux distribution? If so, 9.10 might be proving more of a talking point, and you have to wonder if this is such a good thing with the appearance of Windows 7 on the scene. Looking on the bright side, 10.04 will be an LTS release, so there is some chance that any rough edges that are on display now could be resolved by next April. Even so, it might have been better not to see anything so obvious at all.

In truth, Ubuntu always has had its gaps, and I have seen a few of their ilk over the last two years. Of these, a few have triggered postings on here. In fact, issues with accessing the BBC iPlayer still bring a goodly number of folk to this website. That may just be a matter of grabbing RealPlayer, now helpfully available as a DEB package, from the requisite place on the web and ensuring that Ubuntu-Restricted-Extras is in place too, but you have to know that in the first place.

Even so, unexpected behaviours like Palimpsest seeing every partition on a disk as a different drive and SIL Raid mappings being seen for hard drives that used to live on the main home PC that bit the dust earlier this year; it only happens on one of the machines that I have running Ubuntu so it may be hardware thing and newly added hard drive uses none of the SIL mapping either.

Perhaps more seriously (is it something that a new user should be encountering?), a misfiring variant of Brasero had me moving to K3b. Then, UFRaw was sluggish in batch mode, yet that's nothing that having a Debian VM won't overcome. Rough edges like these do get you asking if 9.10 was ready for the big time, while making you reluctant to recommend it to mainstream users like my brother.

The counterpoint to the above is that 9.10 includes a host of under the bonnet changes like the introduction of Ext4 hard drive formatting, Xsplash to allow the faster system loading to occur unseen and GNOME 2.28. To someone looking in from outside like me, that looks like a lot of work and might explain the ingress of the annoyances that I have seen. Add to that the fact that we are between Debian releases, so things like the optimised packaging of ImageMagick or UFRaw may not be so high up the list of the things to do, especially with the more general speed optimisations that were put in place for 9.10.

With 10.04 set to be an LTS release, I'd be hoping that consolidation is the order of the day over the next five or six months, but it seems to be the inclusion of new features and other such progress that get magazine reviewers giving higher ratings (Linux Format has given it a mark of 9 out of 10). With the mooted inclusion of GNOME 3 and its dramatically different interface in 10.10, they should get their fill of that. However, I'd like to see some restraint for the take of a smooth transition from the familiar GNOME 2.x to the new. If GNOME 3 stays very like its alpha builds, then the question of how users will take to it arises. Of course, there's still some time before we see GNOME 3 and, having seen how the Ubuntu developers transformed GNOME 2.28, I wouldn't be surprised if the impact of any change could be dulled.

In summary, my few weeks with Ubuntu 9.10 as my main OS have thrown up no major roadblocks that would cause me to look at moving elsewhere; Fedora would be tempting if that situation were to arise. The irritations that I have seen are more like signs of a lack of polish and remain peripheral to day-to-day working if you discount CD/DVD burning. To be honest, there always have been some element of roughness on Ubuntu, but has the lack of sizeable change spoilt us? Whatever about how things feel afterwards, significant changes can mean new problems to resolve and inspire blog posts describing any solutions, so it's not all bad. If that's what Canonical wants to see, they might get it, and the year ahead looks as if it will be an interesting one after a recent quieter period.