Fedora 9
To upgrade, I followed the excellent instructions at http://www.gagme.com/greg/linux/f9-tips.php. The key point is to use the ‘preupgrade’ package to sort everything out:

yum -y install preupgrade
preupgrade

This downloads new F9 versions of all the RPM packages you have on your system and then sets everything up so that when you re-boot your machine it will start F9.

It’s an excellent idea, and for me It Just Worked.

KDE 4
KDE version 4 is all rather new. Initially I had version 4.0 installed. The biggest drawback to this version was the absence of the Fuzzy Clock. However, I’m pleased to say that on my first ‘yum update’, my system was upgraded to KDE 4.1, complete with Fuzzy Clock. Whilst version 4.0 was looking a bit rough round the edges, 4.1 is a far more polished affair.

One of the new features (on System Settings, Desktop, General tab) is the ability to ‘Enable desktop effects’, which makes the whole machine much more Mac-like in the prettyness of the desktop. However, I noticed that with this turned on, even when nothing else was running, I was using about 50% of my CPU power just to run the desktop. So I turned that off

The other annoyance in KDE4 was the lack of launch buttons on the panel for my favourite applications. This was really getting on my nerves until I realised that the default ‘tab’ shown initially when clicking on the ‘K’ menu button is the Favourites tab. To add things to the Favourites tab just find the application in the labyrinth of menus on the ‘K’ menu, click it with the secondary mouse button and select ‘Add to Favourites’ from the context-sensitive menu. Now all your favourite applications are just 2 clicks away on the ‘K’ menu button.

UPDATE: Neither KDE 4.0 nor KDE 4.1 can cope with dual screen display systems! I’ve seen comments that imply dual screen configurations are very rare and so fixing the problems is not a priority. Boo : -( See my comments below for details.

Units will convert quantities expressed in one unit in to another unit. Here’s an example:


$ units
2439 units, 71 prefixes, 33 nonlinear units

You have: 12 miles
You want: kilometres
* 19.312128
/ 0.051780933
You have:


So, 12 miles is equivalent to 19.312128 kilometres. OK, that was an easy one to warm up with. Units knows about all kinds of arcane measures and can happily convert between them all. Here’s an example from the man page:


$ units
2439 units, 71 prefixes, 33 nonlinear units

You have: furlongs per fortnight
You want: m/s
* 0.00016630952
/ 6012.8848
You have:


I actually needed to use units to find out my weight in kilos:

$ units
2439 units, 71 prefixes, 33 nonlinear units

You have: 20 stone + 1 lb
You want: kilos
conformability error
127.45946 kg
1000
You have:


My goodness, that’s a large number!

Units should be available in most versions of Unix and Linux - just get a terminal session (telnet or ssh for example) and type in ‘units’. As usual, read the manual page by typing ‘man units’.

The main reason I use KDE rather than Gnome or another system is the Fuzzy Clock. The clock in the lower right hand corner of my screen uses real English to tell the time. So, for example, 11:22 would appear as ‘Twenty past eleven’. The fuzziness is adjustable, but the minimum setting changes the time every 5 minutes, which is more than good enough for most things. This means that the clock will say ‘Twenty past eleven’ until it changes to ‘Twenty five past eleven’.

Recent versions of KDE also include a nifty utility called ‘kbluelock’. When you enable kbluelock, it scans for Bluetooth devices nearby. Select your phone from the list shown, and if your phone ever goes out of range, kbluelock will enable the screen saver, automatically locking the screen. Effectively your phone is being used as a ‘presence detector’ - it indicates if you are at your computer.

This reminds me of the Active Badge system, although that used infra-red technology rather than Bluetooth wireless. I like the idea of using my phone to indicate where I am (within limits

In practice, what happens is that when Thunderbird starts, not much happens until I get a popup dialog box telling me that a script on this page is taking a long time to finish. Even if I try and cancel the script, nothing responds until I manually kill off Thunderbird completely.

Which is a shame.

So, Dr Jan’s Tip From The Top for today is…

You can start Thunderbird with all addons disabled by using the command line:

thunderbird -safe-mode


Once Thunderbird has started it’s then a simple matter to use the Addons screen to disable or uninstall the offending addon.

It seems that the problem for me was the Provider for Google Calendar addon. The Lightning calendar is excellent, and getting better at a good rate too. Unfortunately, without the Google Calendar synchronisation it’s not much use to me at the moment.

I’ll probably try again when a new version is released

I hate Macs. I have always hated Macs. I hate people who use Macs. I even hate people who don’t use Macs but sometimes wish they did. Macs are glorified Fisher-Price activity centres for adults; computers for scaredy cats too nervous to learn how proper computers work; computers for people who earnestly believe in feng shui.

Just don’t look under the hood - there’s a big, hairy, scary Unix system driving it all. With just a small effort you can get a bash shell. Phew

Cron is normally implemented as a daemon, ‘crond’, which is started automatically when the machine is booted. The cron daemon spends most of its life asleep, but once a minute it wakes up and checks if there are any jobs which need to be started at the current time. If there are, they are started and left to run. Any output from these programs will be captured and sent by email to the user that started the job, unless the output (and the error output) is explicitly redirected on the command line in the crontab file.

You may not have permission to use cron on your system, in which case you will need to (or ask your system administrator to) add your details to /etc/cron.allow and make sure they don’t appear in /etc/cron.deny.

Each user can set up their own personal crontab file, which specifies the schedule and the commands to run.

The crontab file is a plain text file with 6 whitespace delimited fields per line. The first 5 fields specify when to run the commands (which form the sixth field).

Here’s a sample line which removes old temporary files as mentioned in the example above:

0 0 * * * /usr/local/bin/find /tmp -depth -mtime +7 -exec /usr/local/bin/remove {} \;

This is what the numbers at the front of a crontab file mean:

Use a star (*) to indicate all possible values.

So, the example above is executed at 0:00 (midnight) every day.

As you can see, the scheduling scheme is very flexible, allowing everything from once every minute (* * * * *) to once a year (10:00 on the third of January would be represented as 00 10 3 1 *) and almost everything in between.

An important point to bear in mind when using cron is the environment which is used to run the jobs. Cron uses ’sh’, the Bourne shell to run the commands you specify. There is only a minimal PATH statement set up, which is why in the example above the full path name is specified for the find and remove commands.

It can be a good idea to prefix your cron commands with ‘. .profile’ to execute your .profile and set up all your default settings. One thing to be aware of here is that most interactive logins use either ksh (the Korn shell) or bash (the Bourne Again SHell), and there may be commands in your .profile which work fine in ksh or bash but which fail in sh.

The classic example is setting up environment variables. For example,

export PATH=$PATH:$HOME/bin

is valid syntax in ksh and bash, but not in sh. You need to export the variable as a separate step:

PATH=$PATH:$HOME/bin
export PATH

The crontab command is used to configure cron jobs.

Do a ‘man crontab’ for more details

Do be careful when using the crontab command, because if you mistype the switches they can be interpreted as a non-existent filename which will effectively remove your existing crontab.

Anyone familiar with the early days of Unix will recognise the authors as key members of the Bell Labs team that created and nurtured Unix through its early years. Brian Kernighan is rightly famous as the co-author, with Dennis Ritchie, of The C Programming Language (a similarly concise tome).

This book is slim by computer book standards, but it manages to cover a huge amount of ground. The copyright date is 1984. Don’t let that put you off, it’s still an enormously useful and very relevant book.

When I first read this book I had already been using the Xenix flavour of Unix for several years, so I wasn’t exactly a newbie.

OK, enough waffle. This is a FANTASTIC book! Reading through it for the first time, suddenly everything clicked into place and it all made a lot more sense.

The strength of this book is that it explains the philosophy of Unix, the approach and the grand design behind it all. Once you have that everything becomes much more obvious and it’s easy to see how everything fits together.

The key parts of the Unix philosophy are

• write programs to do one thing and only one thing well
• use plain text to store information in a human-readable format
• don’t use headers or footers - every line should be real data
• use pipes and redirection to combine programs to achieve your goals

The book starts with information about getting access to your Unix system and progresses logically through the file system, pipes, filters, shell programming and on to C programming. The C chapters start with using standard I/O and end up with using lex and yacc to write a programming language of similar complexity to BASIC.

Computing in 1984 meant using a VDU or, if you were not that fortunate, a hard-copy terminal to access the central computer. Home computers of the period were things like the Apple II (mainly in America I assume), and the British Broadcasting Corporation Microcomputer (in the UK).

I was attending Middlesex Polytechnic and using a DECSystem10 mainframe, so VDUs and teletype printers were familiar items. The description of powering up a terminal or using a dial-up connection seems rather quaint now, but at the time a 600 baud connection was fast.

After this first (somewhat amusing) section the text becomes much more relevant as it moves on to cover software rather than hardware

There is a fairly in-depth review of the Unix filesystem, including a discussion of i-nodes.

The pipes and filters section gives an excellent grounding in the subject and illustrates the Unix philosophy perfectly.

The book covers all the essential command line tools in a concise and informative way. If you follow the examples in the text you will end up with a bunch of useful utilities which just make your life easier. I still refer to the sections on ‘awk’ and ’sed’ quite regularly.

Anyone from a programming background will find this book an excellent introduction to Unix. The extra bonus is that if you follow it through to the end, you’ll have covered some sophisticated language building tools and become proficient with the C language. There is also a chapter about using nroff for document preparation. The entire book was written on a Unix system, and nroff and troff were used to process the text into a format suitable for a typesetter. The proud boast at the front of the book is that all the code within it is automatically taken from working programs.

The best guide to any technical book is the quality of its index, and this is easily one of the best indices I’ve encountered.

All in all, this book was a revelation to me.

If you would like to buy your own copy of this book, and I’d heartily recommend that you do, I encourage you to click on the Amazon link below. This is my first experiment in earning some dosh with my blog - given that no-one reads it, the chances of anyone buying the book and me getting a commission seem extremely remote to me

Unfortunately most of these data were in small files - the largest probably a megabyte or so.

I ran some speed tests. We had gigabit ethernet connecting the 2 boxes on a little used LAN.

I wrote a small script to start 6 copy processes in parallel and another to periodically measure how much disk space had been used on the target machine.

I found that 6 simultaneous scp commands ran at about 15Mb/s (Megabytes per second). scp has the overhead of encrypting the data stream before it is transferred, so I tried plain old rcp as well. That gave me worse results than scp.

Thinking that the large number of small files was slowing things down I tried using tar to batch up the files. I wrote a tiny script to pipe the output of the tar command across to the target machine directly in to a receiving tar process which unbundled the files.

The tar approach almost doubled the rate of transfer to about 30Mb/s.

Here are the tar commands. Note that you’ll need to enable r-commands by creating .rhosts files in the home directories of each machine (remove these after they copy is complete - they are notorious security problems). Note also that, as usual, HP-UX is awkward - whereas the rest of the world uses ‘rsh’ for the remote-shell command, HP-UX uses ‘remsh’. ‘rsh’ is some kind of restricted shell in HP parlance.

box1> cd source_directory; tar cf - . | remsh box2 "cd target_directory; tar xf - "

The first tar command creates a file called ‘-’, which is a special token meaning ’standard output’ in this case. The archive created contains all the files in the current directory (.) plus all subdirectories (tar is recursive by default). This archive file is piped into the remsh command which sends it to the box2 machine. On box 2 I first change to the proper receiving directory, then I extract from ‘-’, or ’standard input’ the incoming files.

I had 6 of these tar commands running simultaneously to ensure the network link was saturated with data, although I suspect that disk access may have been the limiting factor.

You can use the GNU version of ‘find’ to discover where the link loops are. This information is from a bug report here.

Note that this doesn’t work if you have version 4.2.19 of find. You can check the version with rpm, assuming you are using an rpm-based Linux distribution (RedHat anything, CentOS, etc.).

‘rpm -q findutils’ should show the current version.

find . -follow

find: Symbolic link 'some/path/or/another' is
part of a loop in the directory hierarchy;
we have already visited the directory to which it points.

Once you have found the location of the loop you can manually fix things

Don’t think that because you’re more technical/brighter/don’t really care about the existing data that you’ll be OK.

If you don’t have a back up Murphy’s Law dictates that something disastrous will happen and you’ll lose everything.

If you do have a backup, by the same logic you’ll be fine. Think of it as an insurance policy