BOUT three weeks ago I decided to go back to working with Fedora. This distribution served me well over the years, especially in distributed clusters. Fedora 14 looked very promising and it still is, but there are creases that are hard to undo and to hide. In order for matters to improve I will post a quick rant and hope that someone, somewhere will help address the issue that I’ve already reported (I also submit bug reports whenever that’s possible).

My main problem is package specific. The problem was first mentioned here. Thanks to a blog comment from Rahul I was made aware of fairly trustworthy repositories where packagers offer alternative packages. I soon found this newer build of Octave (needed to manually uninstall the existing one as it does not support updating existing packages). It is one of those unsigned packages, which require the user to jump through some hoops. The changelog looked promising because the latest entry mentioned exactly the bug that I was suffering from (many other people must be suffering from it too):

* Sun Feb 28 2010 Alex Lancaster <alexlan[AT]fedoraproject org> – 6:3.2.4-3
- Temporarily disable %check to enable build to complete and ensure upgrade path works. This works around a crash in the imread.m image test script, this may be the same problem as described by upstream here:

https://www-old.cae.wisc.edu/pipermail/octave-maintainers/2010-January/014891.html

So, here goes:

[root@blueberry roy]# yum remove octave
Loaded plugins: langpacks, presto, refresh-packagekit
Adding en_US to language list
Setting up Remove Process
Resolving Dependencies
--> Running transaction check
---> Package octave.i686 6:3.2.4-3.fc14 set to be erased
--> Processing Dependency: libcruft.so for package: pfstools-octave-1.8.1-1.fc14.2.i686
--> Processing Dependency: libcruft.so for package: octave-forge-20090607-17.fc14.i686
--> Processing Dependency: liboctave.so for package: octave-forge-20090607-17.fc14.i686
--> Processing Dependency: liboctave.so for package: pfstools-octave-1.8.1-1.fc14.2.i686
--> Processing Dependency: liboctave.so for package: plplot-octave-5.9.6-5.fc14.i686
--> Processing Dependency: liboctinterp.so for package: octave-forge-20090607-17.fc14.i686
--> Processing Dependency: liboctinterp.so for package: pfstools-octave-1.8.1-1.fc14.2.i686
--> Processing Dependency: liboctinterp.so for package: plplot-octave-5.9.6-5.fc14.i686
--> Processing Dependency: octave(api) = api-v37 for package: octave-forge-20090607-17.fc14.i686
--> Processing Dependency: octave(api) = api-v37 for package: plplot-octave-5.9.6-5.fc14.i686
--> Processing Dependency: octave >= 3.2.0 for package: qtoctave-0.9.1-2.fc14.i686
--> Processing Dependency: octave for package: plplot-octave-5.9.6-5.fc14.i686
--> Processing Dependency: octave = 6:3.2.4-3.fc14 for package: 6:octave-devel-3.2.4-3.fc14.i686
--> Running transaction check
---> Package octave-devel.i686 6:3.2.4-3.fc14 set to be erased
---> Package octave-forge.i686 0:20090607-17.fc14 set to be erased
---> Package pfstools-octave.i686 0:1.8.1-1.fc14.2 set to be erased
---> Package plplot-octave.i686 0:5.9.6-5.fc14 set to be erased
---> Package qtoctave.i686 0:0.9.1-2.fc14 set to be erased
--> Finished Dependency Resolution

Dependencies Resolved

=======================================================================================================
 Package                     Arch             Version                        Repository           Size
=======================================================================================================
Removing:
 octave                      i686             6:3.2.4-3.fc14                 @fedora              32 M
Removing for dependencies:
 octave-devel                i686             6:3.2.4-3.fc14                 @fedora             2.5 M
 octave-forge                i686             20090607-17.fc14               @fedora              39 M
 pfstools-octave             i686             1.8.1-1.fc14.2                 @fedora             254 k
 plplot-octave               i686             5.9.6-5.fc14                   @fedora             1.3 M
 qtoctave                    i686             0.9.1-2.fc14                   @fedora             2.9 M

Transaction Summary
=======================================================================================================
Remove        6 Package(s)

Installed size: 78 M
Is this ok [y/N]: y
Downloading Packages:
Running rpm_check_debug
Running Transaction Test
Transaction Test Succeeded
Running Transaction
  Erasing        : pfstools-octave-1.8.1-1.fc14.2.i686                                             1/6 
  Erasing        : qtoctave-0.9.1-2.fc14.i686                                                      2/6 
  Erasing        : octave-forge-20090607-17.fc14.i686                                              3/6 
  Erasing        : plplot-octave-5.9.6-5.fc14.i686                                                 4/6 
  Erasing        : 6:octave-devel-3.2.4-3.fc14.i686                                                5/6 
  Erasing        : 6:octave-3.2.4-3.fc14.i686                                                      6/6 

Removed:
  octave.i686 6:3.2.4-3.fc14                                                                           

Dependency Removed:
  octave-devel.i686 6:3.2.4-3.fc14                   octave-forge.i686 0:20090607-17.fc14             
  pfstools-octave.i686 0:1.8.1-1.fc14.2              plplot-octave.i686 0:5.9.6-5.fc14                
  qtoctave.i686 0:0.9.1-2.fc14                      

Complete!

This can be done from the GUI as well. But it’s not working. The bug still exists and prevails after the new package gets installed. To make matters worse, for some reason, yum just disallows installing unsigned packages. It does not even produce a warning with an opt-out/force option. It’s very stubborn, so I had to use the GUI. Then, running the program (the new build) showed that:

octave:4> imshow('Konqueror.jpg')
octave: magick/semaphore.c:525: LockSemaphoreInfo: Assertion `semaphore_info != (SemaphoreInfo *) ((void *)0)' failed.
panic: Aborted -- stopping myself...
Aborted (core dumped)
[root@blueberry roy]# qtoctave
[main()] Error loading the QT Translation file for locale 'en_US'.
[main()] Error loading the translation file for locale 'en_US'. Not found in /usr/share/qtoctave/lang 
[Main::Main] Building commands list.

[Main::Main] Commands list builded.
QWidget::setMinimumSize: (/QMdi::ControlLabel) Negative sizes (-1,-1) are not possible
[OctaveConnection::startOctave] Octave path: octave
[OctaveConnection::startOctave] Octave version: 3.2.4 (3.2.4)
[OctaveConnection::startOctave] Starting octave: "octave"  --eval "PS1('octave:\#>');PS2('octave:\#+>');addpath('/usr/share/qtoctave/scripts_octave/')"  --persist --no-history -i 
[OctaveConnection::startOctave] Octave running
klauncher(2168) kdemain: No DBUS session-bus found. Check if you have started the DBUS server. 
kdeinit4: Communication error with launcher. Exiting!
Segmentation fault (core dumped)

Oh, wonderful. Well, eventually I found a way to run qtoctave again. Checking the version/build names again:

[root@blueberry roy]# yum remove octave
Loaded plugins: langpacks, presto, refresh-packagekit
Adding en_US to language list
Setting up Remove Process
Resolving Dependencies
--> Running transaction check
---> Package octave.i686 6:3.2.4-3.el6 set to be erased
--> Processing Dependency: octave >= 3.2.0 for package: qtoctave-0.9.1-2.fc14.i686
--> Processing Dependency: octave = 6:3.2.4-3.el6 for package: 6:octave-devel-3.2.4-3.el6.i686
--> Running transaction check
---> Package octave-devel.i686 6:3.2.4-3.el6 set to be erased
---> Package qtoctave.i686 0:0.9.1-2.fc14 set to be erased
--> Finished Dependency Resolution

Dependencies Resolved

=======================================================================================================
 Package            Arch       Version              Repository                                    Size
=======================================================================================================
Removing:
 octave             i686       6:3.2.4-3.el6        @/2067.0.octave-3.2.4-3.el6.i686              32 M
Removing for dependencies:
 octave-devel       i686       6:3.2.4-3.el6        @/2220.0.octave-devel-3.2.4-3.el6.i686       2.5 M
 qtoctave           i686       0.9.1-2.fc14         @fedora                                      2.9 M

Transaction Summary
=======================================================================================================
Remove        3 Package(s)

Installed size: 37 M

Yes, even octave-3.2.4-3.el6.i686 has this same bug, so what gives? In Kubuntu 10.04 there is no such problem, not in the packaged version of Octave. Having to go through less official routes to unsigned packages is daunting enough for most people; finding out that it still does not work is even a lot worse. The problem here is not really Fedora but lack of coordination between octave and the magick folks. qtoctave handles this admirably well by restarting octave and not just letting the entire program crash. But still, having wasted several hours on this first looking for bugs in my code and then playing with packages rather than doing research (realising that my code was not the problem), I am left a bit bitter about my Fedora 14 experience. It is not as though I have been too lazy trying to resolve this and for the time being it seems like I will do more of my work on my Kubuntu box. It happens to have done packaging of Octave more successfully (at least that older version).

Update: not even stepping back to older versions of ImageMagic has worked and yum had the same limitations because the packages were unsigned.

[root@blueberry roy]# yum remove ImageMagick
Loaded plugins: langpacks, presto, refresh-packagekit
Adding en_US to language list
Setting up Remove Process
Resolving Dependencies
--> Running transaction check
---> Package ImageMagick.i686 0:6.6.4.1-14.fc14.1 set to be erased
--> Finished Dependency Resolution

Dependencies Resolved

=======================================================================================================
 Package                  Arch              Version                         Repository            Size
=======================================================================================================
Removing:
 ImageMagick              i686              6.6.4.1-14.fc14.1               @fedora              6.5 M

Transaction Summary
=======================================================================================================
Remove        1 Package(s)

Installed size: 6.5 M
Is this ok [y/N]: y
Downloading Packages:
Running rpm_check_debug
Running Transaction Test
Transaction Test Succeeded
Running Transaction
  Erasing        : ImageMagick-6.6.4.1-14.fc14.1.i686                                              1/1 

Removed:
  ImageMagick.i686 0:6.6.4.1-14.fc14.1                                                                 

Complete!

Then installing the older version via the GUI. Still the same issue.

[root@blueberry roy]# yum remove ImageMagick
Loaded plugins: langpacks, presto, refresh-packagekit
Adding en_US to language list
Setting up Remove Process
Resolving Dependencies
--> Running transaction check
---> Package ImageMagick.i686 0:6.6.0.2-8.fc14 set to be erased
--> Finished Dependency Resolution

Dependencies Resolved

=======================================================================================================
 Package          Arch      Version                Repository                                     Size
=======================================================================================================
Removing:
 ImageMagick      i686      6.6.0.2-8.fc14         @/2494.0.ImageMagick-6.6.0.2-8.fc14.i686      6.3 M

Transaction Summary
=======================================================================================================
Remove        1 Package(s)

Installed size: 6.3 M
Is this ok [y/N]: n
Exiting on user Command
Complete!
[root@blueberry roy]# octave
GNU Octave, version 3.2.4
Copyright (C) 2009 John W. Eaton and others.
This is free software; see the source code for copying conditions.
There is ABSOLUTELY NO WARRANTY; not even for MERCHANTABILITY or
FITNESS FOR A PARTICULAR PURPOSE.  For details, type `warranty'.

Octave was configured for "i386-redhat-linux-gnu".

Additional information about Octave is available at http://www.octave.org.

Please contribute if you find this software useful.
For more information, visit http://www.octave.org/help-wanted.html

Report bugs to  (but first, please read
http://www.octave.org/bugs.html to learn how to write a helpful report).

For information about changes from previous versions, type `news'.

octave:1> imshow('in')
octave: magick/semaphore.c:525: LockSemaphoreInfo: Assertion `semaphore_info != (SemaphoreInfo *) ((void *)0)' failed.
panic: Aborted -- stopping myself...
Aborted (core dumped)

I’m giving up. Maybe I just need to go to far older versions for compatibility, but I tried the oldest ones built for Fedora 14.

‘ve been an Octave user on several machines and everything worked perfectly well until Fedora 14, which has a newer version of the software and thus a serious conflict of incompatible libraries. For many image loaders the following type of error is shown just before Octave crashes:

octave: magick/semaphore.c:525: LockSemaphoreInfo: Assertion `semaphore_info !=
 (SemaphoreInfo *) ((void *)0)' failed.
panic: Aborted -- stopping myself...

Do not waste time trying to find a bug in the code of an Octave program. It is a known issue that GraphicsMagick and Octave are having this year.

Somebody posted debugging information and John W. Eaton responded with a link to this thread from January. The best solution is probably to escape to previous versions for the time being.

T HAS been a while since I last did a comprehensive survey of DICOM-related software and since I am ditching MATLAB (in the quest for Free software-only research) I decided to review or at least check out what’s available at the end of 2010. Other people may find this handy.

DICOM is notorious for being the standard that’s not quite the standard and is actually somewhat proprietary and controlled by one entity. As someone pointed out the other day, DICOM is considered “extensible”, which implies that the usual type of format ‘bastardisation’ will always occur. It’s just an inconsistent data format as someone warned, so some software would cough at it and sometimes manage to salvage some data. According to Wikipedia, some tagging of the image/s is accompanied by data fields like:

Let us say that we are more interested in the raw image data and not so much in the metadata. If that’s the case, batch conversion to a more manageable format is worthwhile. Here is the command-line converter that I use (some are for Windows only and they are proprietary) and some other options can be found on the Web through directories. There are also good software resources on scientific data formats and there is radiology CEU information regarding PACS and DICOM viewers. There is actually far more choice out there than there was a few years ago. For GNU/Linux and Free software proponents there is no lack or deficiency, either.

HIS POST is part of a series that I do about my incursions moving from MATLAB to Octave, which has so far been a pleasant experience. QtOctave looks better and is easier to install than MATLAB (on GNU/Linux with KDE at least). For those who experienced being a customer/user of MATLAB, it can really be a pain in the butt, licence-wise. The parent company, MathWorks, can be very aggressive when it comes to licensing (it pays the BSA after all), so people are kept tied to particular IP addresses and must renew something to remove artificial limitations. Moreover, the toolboxes that MATLAB sells separately are a case of artificial scarcity and they can be expensive. Octave resolves much of this by centralising a lot of software as shown in the screenshots above (also separating free/libre from proprietary). Rather than waste time with paperwork and bank transactions, any QtOctave user can simply and quickly click away to receive anything s/he desires. It’s truly like a candy store.

Why ever go through the trouble presented by MATLAB, Maple, Mathematica, or IDL? Some people may need these for collaboration and consistency (as in monoculture), but it is better to start without any proprietary software dependency.

I will report on more aspects of this comparison as I go along. At the moment I’m exploring the GPLv3-licensed BioSig project, which allows me to deal with DICOM datasets of the heart (images acquired just recently — ones that I picked up at the hospital yesterday). Speaking of which, I’ve learned that some scanning machines that traditionally used Windows are now moving to GNU/Linux. How exciting times are coming…

N A KDE (Qt) desktop like mine, despite MATLAB putting a lot of effort into improving the GUI on the GNU/Linux side^* (even adding a Microsoft Windows-esque “Start” button at the bottom left), QtOctave integrates more nicely with the desktop. Thanks to all those who suggested some other tools including R, Sage, Scilab, QtOctave, graphviz and so on as I make my way into the world of Free software-only research (valuable pointers in the comments too).

All the code I’ve ever produced is Free software, but whenever I worked with MATLAB only the underlying framework was proprietary. This created a sort of trap, wherein my free/libre code depended on code which was not. In the near future I hope to produce code, blog items, upload of all code I write (including code sample for explanatory purposes), screecasts, etc. I may even commit code upstream if it’s polished enough for general-purpose use. I will continue to share dents and images on a regular basis too. In the mean time, for comparative purposes, I will also use my academic licence of MATLAB. I was once ranked first in the world for my code contributions to MATLAB, but although my code was all free software it helped MATLAB (BSA sponsor and thus a contributor to an attack on the software industry) just sell more copies of proprietary software. I am not a disgruntled prominent user of MALTAB but someone who is trying to show the way out of MATLAB mostly for idealogical reasons. If everything works as I hope, I will soon be 100% free of proprietary software.
___
^* It was far, far uglier a few years back.

It was interesting to find out why Ian had left to join Sun.

ERE are some thought about things I’ve observed in the past week.

Linux and Free Software FUD on the Rise in 2008

The attacks on OSS and Linux have ballooned since the new year began (LANCOR, Jeff Gould, McAfee and the ilk). I decided to just concentrate on squashing FUD and attacks. Please E-mail me (roy at schestowitz dot com) if you see something I have not covered somewhere on the Web. It’s something which must be addressed.

Be aware that Intel systematically spread FUD and sabotaged the OLPC project from the very start. The press never covered this properly. WSJ said that Intel staff also spread FUD in Peru. They were saying OLPC adapters should not work (a lie). Folks are encouraged to embargo Intel not only for this, but for its kickbacks as well. For two years, Intel has behaved like an appalling abusive monopoly, but the press did not cover the issues at hand. It looked the other way instead. When it comes to OLPC, Intel spread FUD. tried to gag Nick Negroponte with a ‘deal’ and also ‘competed’ by selling Classmate at a loss. Those who want to know the real story should start here.

Open Source in the United Kingdom

BECTA is responsible for the procurement of software in Britain’s educational sector, but its seems like a lost case based on what I’ve read. Such dinosaurs are dependent on the existence of software with acquisition costs attached. There are other issues however, including the danger of rocking the status quo boat.

Procurement is a matter of gut feeling or relationships. Pressuring those responsible by exposing them might be the most effective way to combat this habit. It seems to have worked out with the BBC, which gradually surrenders to pressure to stop its Windows-only affairs. One can find Mark Taylor’s piece in Groklaw (and Highfield’s hurried response to it). This shows how putting one’s job in jeopardy (for possible corruption) can lead to results.

GPL Lawsuits FUD

Some recent headline suggested the GPL is attacking, rather than being attacked (dishonoured). That was a fortnight ago. There is a lot of FUD at the moment in general. As pointed out above, McAfee brings back its 2006 FUD and attacks the GPL again.

Of course, McAfee relies on insecure systems to sell its products. It was caught spreading Linux FUD back in 2006 when it accused Linux of security problems. Fortunately, as a Linux user, I don’t even need to avoid McAfee products. McAfee are irrelevant to me. That’s why they are so afraid (defensive).

Where is the Old Open Source and What Did You Do to the Real One?

As the meaning of “open source” got so diluted and the business models of some new adopters assimilated to that of proprietary software, it become more apparent that Free software (as in GPL and its derivatives) was the way to go. That’s why GNU/Linux is so far ahead of open source in the enterprise when it comes to adoption.

In short, open source is something else whose value was radically warped. We have to ask ourselves if OSI-approved ‘open source’ means what it used to mean. If not, we’re killing the term and harm everyone who is honest, e.g. Digium, Red Hat, even MySQL. People ought to return to the term “Free software” and just emphasize that it’s about freedom. ‘Open source’ should have been more stubborn and selective. Have I lost hope in ‘open source’ because of the charts? No, that was months ago when I saw the thing devolving and called it quits.

Remember never to mix the penetration rates of open source with Free software such as GNU/Linux.