EDORA 14 was a bit of a mixed bag, but it was definitely an improvement compared to previous versions. I’ve used it since it was released (and blogged quite a lot about it). At the moment I use an older version:

bash-4.0$ uname -a
Linux [XXXXX] 2.6.30.10-105.2.23.fc11.i686.PAE #1 SMP
Thu Feb 11 07:05:37 UTC 2010 i686 i686 i386 GNU/Linux

Not to worry, it’s up to date and it runs the latest KDE. The general impression has been positive, having worked on this operating system for the past week or so (still awaiting my Ethernet’s return, so working from a lab, not via SSH). A few remarks about the weak spots:

• X (org/server) blows up under particular circumstances where a newer version of X might be expected. If an attempt is made to invoke it from a remote host (SSH with X forwarding), the whole of Fedora blows up and the session must be restarted. If run locally, the same type of X issue simply raises a hardware-based exception and produces a major warning, then gives the option to gracefully shut down the affected program. It’s not good, but it’s definitely better than the former scenario, which is reproducible by the way.
• Dual-screen handling is fantastic. It is still a plug-and-play experience, even with Fedora 11 in place.
• There are far too many visual artefacts and drawing bugs (direct rendering is lacking). Again, this may just be the fault of old X and nothing whatsoever to do with the drivers of this GPU (Fedora seems to favour free drivers).

Aside from X rants, this platform is fantastic for development. Everything has worked well so far, except Firefox with occasional crashes (occurring at least once a day).

Is Fedora ready to become the most widespread GNU/Linux desktop? Probably not yet. But for development? Sure, why not? Fedora 14 is more mature, but that too has some wrinkles which I covered here before.

By the way, the screenshot at the top (click to zoom) shows the application I’ve been developing recently. More details will be published shortly as blogging distracts from persistent coding, and vice versa.

oday I set up my alternative machine in a way which enables me to get the best of GNOME and KDE. It was set up in a way that I never tried before. Back in 2001 or thereabouts I would have gnome-panel imported into my desktop session (from another computer) and I repeated this type of practice locally around 2005-2007 when I wanted my KDE desktop to also have gnome-panel and therefore allow easy access to GNOME-side administration tools or applications. Today I tried something different altogether by installing KDE alongside GNOME and then running plasma-desktop in GNOME, which obviously imported panels and the background utilities, including 2 folderview plasmoids that import directories over SSH (the remote server on which I run workloads).

The bottom line is, there need not be a strict choice between GNOME and KDE. Both are compatible with one another and can run alongside one another in the very same session. In this case, it’s a dual-head machine with free graphics drivers and I might post some screenshots soon. This helps debunk the myth of incompatible desktop environments.

ODAY I moved on to my next research project, which I will mention very briefly in the next post. As part of this move I’ve also made some distro changes. The servers are running Ubuntu, so for the sake of consistency I wanted to explore the latest and greatest of Ubuntu and its flavours/derivatives. I gave a go to 3 and spent some time working from them (not long enough an experience as yet).

Will it be 10 out of 10 for the 10.10 releases? What about Mint 10 (codename “Julia”)? I decided to try today, hopefully seeing how it all compares to Fedora 14, which I have used since it was released around the end of October. The change is motivated by needs of consistency; I also like to try different distributions and see what they are all about over time, for the sake of comparison. I might stop using Fedora for a while. It is still installed on a PC, but I moved all my important work files out of there, which means they’ll go out of sync over time.

A report about use will be posted at a later date (this is not a review but a post with quick impressions). The important points are that today I tried Linux Mint (very latest version, which is GNOME based) and latest Ubuntu+Kubuntu shortly afterwards. Linux Mint has this nice new feature (to me at least) that has it start the installation while the user enters installation options such as user details, location, etc. The menus and graphics (including icons and window decorators) are stunning. Setting up dual-head in Ubuntu without proprietary drivers was easy, in Kubuntu it’s still not as easy (getting twinview). Overall, since both share the very same base (even same packages for the most part, except those which are preinstalled), comparison in this case ought to rely on what’s above the hood, mostly user experience.

ORKING with bare metal for the purpose of maximal hardware utilisation and performance is not the same as working with typical computer programs. Developing software for research is also different from software development for end users, where the software is treated as a product. Different scenarios require different methodologies and different levels of polish, and thus have different specifications and priorities. In research, brute force becomes essential to the success of one group or another.

I often find myself working on servers or clusters (only GNU/Linux), in which case it is useful to manage up to 50 computers, for example, remotely, at the same time. With full GUI sessions it can be a disorienting task, but that too can be achieved and I wrote about it roughly 6 years ago in this blog (back when I was a Ph.D. student).

Working from the command line at a desktop is perfectly acceptable if brains and not candy count, so platforms like Mac OS X are irrelevant. To do coding on the server I currently use vi as the editor in one terminal and the MATLAB session in another. On the desktop I would use QtOctave, as covered before (also in some screencasts). Unfortunate issues that had me revisit MATLAB (which in any case would be inevitable as means of ensuring compatibility with colleagues) led me back to the old days of developing over SSH (using KIO slaves and the likes of that). Quick access to the file can be gained using abbreviated wrappers such as:

./Main/Programs/Scripts/SSH/42
/opt/matlab/bin/matlab -nodesktop -nosplash -r "addpath(genpath('/home/S00/schestr0/'))"

where 42 is a script numbered after the machine number and the latter command initialises the command line. /home/S00/schestr0/ is using NFS and it can be reached from any computer at the department at the same time (multiple machines can write to the filesystem at the same time, too). If the files are edited locally, they can be passed across to the server using a simple command that transfers them in encrypted form.

scp /home/roy/Main/IT/Programs/get_dicom_heart/* -r
schestr0@eng041.cs.man.ac.uk:/home/S00/schestr0/get_dicom_heart/

Occasional local backups (usually nightly because it is resources-intensive over USB2) are achieved as follows:

mkdir /media/disk/Home/`date +%Y-%m-%d`

tar -cf - /home/roy|split -b 1000m - /media/disk/Home/`date +%Y-%m-%d`/Home-`date +%Y-%m-%d`.tar.

To decipher this, try:

man tar
man split

For example in:

tar -cf - /media/SEA_DISK/Home/|split -b 1000m - Baine-`date +%Y-%m-%d`

the backup is split into chunks of 1 gigabyte and the files are named by the date

To reassemble the above (resorting from backups):

cat *|tar -xf - 

No command line interface should be intimidating. Many powerful computer tasks are managed from it because the command line makes streamlining simpler and scripting jobs is a lot easier. My programs are written in a way that enables assigning many parameters like paths and wildcards, which lets the programs run for many hours and automatically produce output like images, videos, and text for inspection later. Research in computer vision or computer graphics requires heavy computation and for compelling experiments, the larger the sample sets, the more convincing the results. Use of computer resources therefore becomes the difference between failure and success and those who fail to master it can easily perish against the competition. Another valuable skill is knowing how to reuse code (legally of course) and this is where free/libre software orientation helps a lot. Publication in Open Access (OA) and availability of one’s own work — including code — can help gain more citations, which is the currency by which many publications are being judged.

ESTERDAY I encountered my first major setback in Octave for Kubuntu. It was a bug, not a missing feature. It involved an outside library again. I tried installing a newer version of gnuplot (installing the latest one by compiling the source code), but this did not resolve the issue. All in all, over an hour was spent on it, first assuming that I was coding wrongly and later realising that the issue was upstream (there are many more threads like this and they dominate the discussion on the matter). Applying the patch manually would only be a short-term solution as it was already submitted for inclusion in future releases, so for the time being, where this function is needed, I will reluctantly be testing the code under MATLAB (for which I have an academic licence that everyone gets whether they want to or not). It was rather depressing to use MATLAB for a few hours yesterday. Compatibility will be assured again when the little issue (fixable with just a line or a few) is addressed also in the binaries offered by GNU/Linux distributions. Apart from that I’m having Fedora-Octave-ImageMagick compatibility issues [1, 2], which help not at all.

My overall experience with Octave is pleasant and it remains by far the primary choice for image analysis. But for others who insist on using MATLAB I must ensure cross-compatibility, thus the following (under Fedora):

The image shows the interface which now precedes the tracking phase. Points can be placed by the user with text guidance in the console. The interfaces were also improved to separate between rectangular, circular, and manual placements.

Here is an example image without the interface.

ITHOUT preparing any notes I’ve embarked on the task of making this first Octave tutorial, which hopefully helps show how to install it on a Debian- or Red Hat-based system.

Please bear in mind that this was done on the spot without rehearsals and future tutorials will hopefully be more organised.

HEN Fedora 14 was released there was a lot of excitement about it, more so than when previous releases of this leading GNU/Linux distribution came out. This was justified. After almost 8 weeks with Fedora 14 the only major issue I have had with it is conflicting packages, which would not really be Fedora’s fault. For the most part, when it comes to the experience on the KDE (4.5.x) desktop, everything is great. Some reviewers of Fedora 14 have been harsh and said that it would mostly suit advanced users; I’ve not yet found something which would justify a need for advanced skills though. Maybe once a week or so a technical issue may arise that requires technical understanding, but it’s never something critical.

All in all, having used Fedora 14 since it was released I can happily recommend it.