Technology Tales

Improving Font Display in Fedora 15

When I first started to poke around Fedora 15 after upgrading my Fedora machine, the definition of the font display was far from being acceptable to me. Thankfully, it was something that I could resolve, and I am writing these words with the letters forming them being shown in a way that was acceptable to me. The main thing that I did to achieve this was to add a file named 99-autohinter-only.conf in the folder /etc/fonts/conf.d. The file contains the following:

<?xml version="1.0"?>
<!DOCTYPE fontconfig SYSTEM "fonts.dtd">
<fontconfig>
<match target="font">
<edit name="autohint" mode="assign">
<bool>true</bool>
</edit>
</match>
</fontconfig>

Enabling autohinting improves font appearance in Fedora 15. The TrueType bytecode interpreter (BCI) was recently added to FreeType after its patent expired, but this actually decreased font quality on my system. I applied Kevin Kofler's autohinting fix and installed GNOME Tweak Tool, which lets you adjust autohinting settings. This combination solved my problems, particularly with letters like "k". Now, I am considering trying the same solution in openSUSE, which also has unsatisfactory font rendering, though I'll have to wait for GNOME Tweak Tool until they release a GNOME 3 version.

GNOME 3 in Fedora 15: A Case of Acclimatisation and Configuration

When I gave the beta version of the now finally released Fedora 15 a try, GNOME 3 left me thinking that it was even more dramatic and less desirable a change than Ubuntu's Unity desktop interface. In fact, I was left with serious questions about its actual usability, even for someone like me. It all felt as if everything was one click further away from me, and thoughts of what this could mean for anyone seriously afflicted by RSI started to surface in my mind, especially with big screens like my 24" Iiyama being commonplace these days. Another missing item was somewhere on the desktop interface for shutting down or restarting a PC; it seemed to be a case of first logging off and then shutting down from the login screen. This was yet another case of adding to the number of steps for doing something between GNOME 2 and GNOME 3 with its GNOME Shell.

After that less than positive experience with a Live CD, you'd be forgiven for thinking that I'd be giving the GNOME edition of Fedora 15 a wide berth, with the LXDE one being chosen in its place. Another alternative approach would have been to turn off GNOME Shell altogether by forcing the fallback mode to run all the time. The way to do this is start up the System Settings application and click on the System Info icon. Once in there, click on Graphics and turn on the Forced Fallback Mode option. With that done, closing down the application, logging off and then back on again will gain you an environment not dissimilar to the GNOME 2 of Fedora 14 and its forbears.

Even after considering the above easy way to get away from and maybe even avoid the world of GNOME Shell, I still decided to give it another go to see if I could make it work in a way that was less alien to me. After looking at the handy Quickstart guide, I ventured into the world of GNOME Shell extensions and very useful these have come to be too. The first of these that I added was the Alternate Status Menu, and I ran the following command to do so:

yum install gnome-shell-extensions-alternative-status-menu

The result was that the "me" menu gained the ever useful "Power Off..." entry that I was seeking once I refreshed the desktop by running the command r in the command entry box produced by the ALT + F2 keyboard combination. Next up was the Place Menu and the command used to add that is:

yum install gnome-shell-extensions-place-menu

Again, refreshing the desktop as described for the Alternate Status Menu added the new menu to the (top) panel. Not having an application dock on screen all the time was the next irritation that was obliterated, and it helps to get around the lack of a workspace switcher for now too. The GNOME Shell approach to virtual desktops is to have a dynamic number of workspaces, with there always being one more than what you are using. It's an interesting way of working that doesn't perturb more pragmatic users like me, but there are those accustomed to tying applications to particular workspaces aren't so impressed by the change. The other change to workspace handling is that keyboard shortcuts have changed to CTRL + ALT + [Up Arrow] and CTRL + ALT + [Down Arrow] from CTRL + ALT + [Left Arrow] and CTRL + ALT + [Right Arrow].

To add that application dock, I issued the command below and refreshed the desktop to get it showing. Though it stops application windows becoming fully maximised on the screen, that's not a problem with my widescreen monitor. In fact, it even helps to switch between workspaces using the keyboard because that doesn't seem to work when you have fully maximised windows.

yum install gnome-shell-extensions-dock

After adding the application dock, I stopped adding extensions though there are more available, such as Alternate Tab Behaviour (restores the ALT-TAB behaviour of GNOME 2), Auto-Move Windows, Drive Menu, Native Window Placement, Theme Selector and Window Navigator. Here are the YUM commands for each of these in turn:

yum install gnome-shell-extensions-alternate-tab
yum install gnome-shell-extensions-auto-move-windows
yum install gnome-shell-extensions-drive-menu
yum install gnome-shell-extensions-native-window-placement
yum install gnome-shell-extensions-theme-selector
yum install gnome-shell-extensions-user-theme
yum install gnome-shell-extensions-windowsNavigator

One hope that I will retain is that more of these extensions will appear over time, but Ranjith Siji seems to have a good round up of what is available. Other than these, I also have added the DCONF Editor and GNOME Tweaks Tool, with the latter restoring buttons for minimising and maximising windows to their title bars for me. As ever, yum was called to add them using the following commands:

yum install dconf-editor
yum install gnome-tweaks-tool

There are other things that can be done with these, but I haven't explored them yet. All yum commands were run as root, and the ones that I used certainly have helped me to make myself at home in what once was a very unfamiliar desktop environment for me. In fact, I am beginning to like what has been done with GNOME 3 though I have doubts as to how attractive it would be to a user coming to Linux from the world of Windows. While everything is solidly crafted, the fact that I needed to make some customisations of my own raises questions about how suitable the default GNOME set-up in Fedora is for a new user, though Fedora probably isn't intended for that user group anyway. Things get more interesting when you consider distros favouring new and less technical users, both of whom need to be served anyway.

Ubuntu has gone its own way with Unity and, having spent time with GNOME 3, I can see why they might have done that. Unity does put a lot more near at hand on the desktop than is the case with GNOME 3 where you find yourself going to the Activities window a lot, either by using your mouse or by keystrokes like the "super" (or Windows) key or ALT-F1. Even so, there are common touches like searching for an application like you would search for a web page in Firefox. In retrospect, it is a pity to see the divergence when something from both camps might have helped for a better user experience. Nevertheless, I am reaching the conclusion that the Unity approach feels like a compromise and that GNOME feels that little bit more polished. Saying that, an extra extension or two to put more items nearer to hand in GNOME Shell would be desirable. If I hadn't found a haven like Linux Mint where big interface changes are avoided, maybe going with the new GNOME desktop mightn't have been a bad thing to do after all.

On upgrading from Fedora 13 to Fedora 14

My Fedora box recently got upgraded to the latest version of the distribution (14) and I stuck to a method that I have used successfully before and one that isn't that common with variants of Linux either. What I did was to go to the Fedora website and download a full DVD image, burn it to a disk and boot from that. Then, I chose the upgrade option from the menus and all went smoothly with only commonplace options needing selection from the menus and no data got lost either. Apparently, this way of going about things is only offered by the DVD option because the equivalent Live CD versions only do full installations.

However, there was another option that I fancied trying, but was stymied by messages about a troublesome Dropbox repository. As I later discovered, that would have been easily sorted, only for my opting for a tried and tested method instead. This was a pity because only two commands would have needed to be issued when logged in as root, and it would have been good to have had a go with them:

yum update yum
yum --releasever=14 update --skip-broken

These may have done what I habitually do with Ubuntu upgrades but trying them out either will have to await the release of the next version or my getting around to setting up a Fedora virtual machine to see what happens. The latter course of action might be sensible anyway to see if all works without any problems before doing it for a real PC installation.

Ridding Fedora of Unwanted Software Repositories

Like other Linux distributions, Fedora has the software repository scheme of things for software installation and updating. However, it could do with having the ability to remove unwanted repositories through a GUI, only it doesn't. What you need to do instead is switch to root in a terminal using the command su - and enter your root user password before navigating to /etc/yum.repos.d/ to delete the troublesome [file name].repo file. Recently, I needed to do this after upgrading to Fedora 14 or yum wouldn't work from the command line, which is the way that I tend to update Fedora (yum -y update is the command that I use because it automatically does all installations unattended until it is finished doing what's needed). The offending repository, or "Software Source" as these things are called in the GUI, belonged to Dropbox and even disabling it didn't make yum operate from the command like it should, so it had to go. Maybe Dropbox hasn't caught up with the latest release of Fedora, but that can be resolved another day.

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.

Relocating the Apache web server document root directory in Fedora 12

So as not to deface anything that is available online on the web, I have a tendency to set up an offline Apache server on a home PC to do any tinkering away from the eyes of the unsuspecting public. Though Ubuntu is my mainstay for home computing, I do have a PC with Fedora installed, and I have been trying to get an Apache instance to start automatically on there unsuccessfully for a few months. While I can start it by running the following command as root, I'd rather not have more manual steps than is necessary.

httpd -k start

The command used by the system when it starts is different and, even when manually run as root, it failed with messages saying that it couldn't find the directory while the web server files are stored. Here it is:

service httpd start

The default document root location on any Linux distribution that I have seen is /var/www and all is very well with this, but it isn't a safe place to leave things if ever a re-installation is needed. Having needed to wipe /var after having it on a separate disk or partition for the sake of one installation, it doesn't look so persistent to me. In contrast, you can safeguard /home by having it on another disk or in a dedicated partition, which means that it can be retained even when you change the distro that you're using. Thus, I have got into the habit of having the root of the web server document root folder in my home area, and that is where I have been seeing the problem.

Because of the access message, I tried using chmod and chgrp, but to no avail. The remedy has to do with reassigning the security contexts used by SELinux. In Fedora, Apache will not work with the context user_home_t that is usually associated with home directories, but needs httpd_sys_content_t instead. To find out what contexts are associated with particular folders, issue the following command:

ls -Z

The final solution was to create a user account whose home directory hosts the root of the web server file system, called www in my case. Then, I executed the following command as root to get things going:

chcon -R -h -t httpd_sys_content_t /home/www

It appears that even the root of the home directory has to have an appropriate security context (/home has home_root_t so that might do the needful too). Without that, nothing will work, even if all is well at the next level down. The switches for chcon command translate as follows:

-R : recursive; applies changes to all files and folders within a directory.

-h : changes apply only to symbolic links and not to where they refer in the file system.

-t : alters context type.

It took a while for all of this stuff about SELinux security contexts to percolate through to the point where I was able to solve the problem. A spot of further inspiration was needed too and even guided my search for the information that I needed. It's well worth trying Linux Home Networking if you need further details. Though there are references to an earlier release of Fedora, the content still applies to later versions of Fedora to the current release, if my experience is typical.

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.

An early peek at Ubuntu 9.10

Even if the twice a year release means that changes to Ubuntu are evolutionary rather than revolutionary, that isn't to imply that curiosity doesn't get the better of me from time to time. The result is that an early alpha version (3 at the time of writing) of the Linux distro has found a home in a VirtualBox VM on my main system. The most noticeable change so far is the inclusion of GNOME 2.27.5 with its Fedora-esque log-in screen and the movement of the shutdown and log-off paraphernalia to the System menu, which is where you find it in Debian or Fedora. On the account settings menu, there lives a link to an equivalent of the Windows Control Panel called Control Centre; the menu item is named System Preferences. For the record, I have seen it in Fedora 11 too, so it does look as if Ubuntu's GNOME implementation is looking more like a brown equivalent of Fedora. Whether this stays like this is anyone's guess, but a new messaging arrangement is coming into being, too.

Otherwise, there appears to be no real drama on the surface, with Firefox staying at 3.0.x for now and OpenOffice moving to 3.1. Personally speaking, I'd be very surprised to see Firefox 3.5.x being left out, though I did run into a spot of bother with the Preferences dialogue crashing it on Windows XP. Under the bonnet, the kernel is at release 2.6.31 and things seem reasonably stable at this stage. Saying that, there is a crash report icon that appears every session, but that has no effect apart from the visual side of things. VirtualBox Guest Additions work as they should, better than they in Windows guests if my experience provides any sort of benchmark (the display does odd things unless you keep jogging the graphics memory up and down). All in all, things appear usable if undramatic at this stage, and there are a few months to go before the final release anyway.

Adding msttcorefonts to Fedora

Once you have enabled the appropriate software repository, you can install the msttcorefonts (Microsoft TrueType core fonts like Arial, Times Roman, Verdana, Georgia, etc.) package on Debian and Ubuntu. With Fedora, it surprisingly isn't so straightforward. There is a recipe using the command line that worked for me, and I'm not going to repeat it here, so I'll leave you to go where I found it. In fact, it forms part of a wider unofficial Fedora FAQ that may be of more interest to you than solving this.

Update for Fedora 12 (2009-11-24):

You also need chkfontpath so the following needs doing before the final part of the command sequence, changing the filename as appropriate for your situation:

yum install xfs
rpm -ivh http://dl.atrpms.net/all/chkfontpath-1.10.1-2.fc12.i686.rpm

Whither Fedora?

There is a reason why things have got a little quieter on this blog: my main inspiration for many posts that make their way on here, Ubuntu, is just working away without much complaint. Since BBC iPlayer isn't working so well for me at the moment, I need to have a look at my setup. Otherwise, everything is continuing quietly. In some respects, that's no bad thing and allows me to spend my time doing other things like engaging in hill walking, photography and other such things. While I suppose that the calm is also a reflection of the fact that Ubuntu has matured, there is a sense that some changes may be on the horizon. For one thing, there are the opinions of a certain Mark Shuttleworth, though the competition is progressing too.

That latter point brings me to Linux Format's recently published verdict that Fedora has overtaken Ubuntu. I do have a machine with Fedora that performs what I ask of it without any trouble. However, I have never been on it trying all the sorts of things that I ask of Ubuntu, so my impressions are not in-depth ones. Going deeper into the subject mightn't be such a bad use of a few hours. What I am not planning to do is convert my main Ubuntu machine to Fedora. I moved from Windows because of constant upheavals and I have no intention to bring those upon me without good reason, something that's just not there at the moment.

Speaking of upheavals, one thought that is entering my mind is that of upgrading that main machine. Since its last rebuild was over three years ago, computer technology has moved on a bit since then, with dual and quad-core CPU's from Intel and AMD coming into the fray. Of course, the cost of all of this needs to be considered too, which is never more true than in these troubled economic times. If you asked me about the prospect of a system upgrade a few weeks ago, I would have ruled it out of hand.

What has got me wondering is my continued used of virtualisation and the resources that it needs. Mad notions like running more than one VM at once will put any CPU or memory through their paces. Another attractive idea would be getting a new and bigger screen, particularly with what you can get for around £100 these days. However, my 17" Iiyama is doing well enough to consign this one to the wish list for now. None of the changes that I have described are imminent, even if I have noticed how fast I am filling disks up with digital images to make an expansion of hard disk capacity a higher priority.

If I ever get to do a full system rebuild with a new CPU, memory and motherboard (I am not so sure about graphics since I am no gamer), the idea of moving into the world of 64-bit computing comes about. Since the maximum amount of memory usable by 32-bit software is 4 GB, 64-bit software is a must if I decide to go beyond this limit. That all sounds very fine, aside from the possibility of problems arising with support for legacy hardware. It sounds like another bridge to be assessed before its crossing, even if two upheavals can be made into one.

Besides system breakages, the sort of hardware and software changes over which I have been musing here are optional and can be done in my own time. That's probably just as well in a downturn like we are experiencing now. Being careful with money becomes more important at times like these, which means that it's fortunate that free software not only offers freedom of choice and usage but also a way to leave the closed commercial software acquisition treadmill with all of its cost implications, leaving money for much more important things.