Mine the Harvest

I’ve been waiting 27 years to see this:

joshua@jaguarpf-login2:~> date
Thu Mar 10 16:04:31 EST 2011
joshua@jaguarpf-login2:~>

Translated from Old High Geek (derived from early proto Unix) that output is similar in magnitude to the fabled Enochian Emerald Tablets of Hermes Trismegistus. But to explain how cool this was for me, a bit of a narrative is needed, but there won’t be much computer speek or techno mumbo jumbo in this post.

In 1983, when I was 12 years old, the movie War Games came out. Of course, I was already deeply in love with computers and had spent endless hours already using my 8 Mhz, 8-bit Atari 400 with 24K as well as my Vic 20 with 3K. Naturally, being a geek, I knew about Cray Supercomputers. (The word was pronounced with a slight pause and inflection when uttered, if indeed the ineffable need be put in human words.) The anecdotal relationship in War Game’s between professor Falken (John wood) and the real life Seymour Cray was  also common geek lore – cannon in fact. Cray was THE supercomputing company – the gold standard of computing.

My love for Cray systems continued unabated from that time, and I would always keep an eye on what the company, and there computers, were doing. Of course, the story of the visisituedes of the company and its founder are near legendary. But like a favorite sports team or rock band I was always a loyal fan – even though I had never once used a Cray system. Neither did I own any platinum, or anti-matter, but one need not have something to know its worth.

More years past until in October of 1996, while driving to work, I heard the news of the unexpected death of Seymour Cray. Wow, that sucked. The father of supercomputing was killed in a car crash, apparently by a drunk driver. I thought about it for days, with the surreal feeling you get when a hero figure is made so painfully mortal, and who’s life need not have been ended. It was just one of those days you will always remember.

Over the years computers kept changing. The age of the custom “big iron” vector supercomputers waned, replaced by commodity hardware running thousands of CPUs and powered by a little OS called Linux. Now, if there was one thing I liked equally as much as Cray’s, it would have to be Linux.

One thing lead to another, and I was recently offered a position at Oak Ridge, the home of Jaguar – a Cray XT5  system with over 220,000 cores running at 2.3 PF (2.3 quadrillion calculations a second).  Jaguar, my favorite computer in the World, running my favorite OS, on a Cray platform, was what lead me to the Lab and I’ve been quite happy with my position there.

So, while that output might seem like any other login, or some boring computer output, for me it had a bit more emerald tablet like glow to it.

Today is another one of those days I’ll remember.

Thanks Seymour.

Recently I was getting errors when trying to rip mp3 files on my Suse 11.3 box, though it seems this issue affects various distributions using KDE. The solution in my case turned out to be quite simple.

Original error when using K3B or audiocd://

Could not read some_song.mp3: encoding failed
WARNING: libsndfile may ignore -r and perform fseek's on the input.
Compile without libsndfile if this is a problem.

I downloaded and compiled the latest version of lame from Sourceforge – which is the same version as the one I had from Packman – 3.98.4. The version I compiled, specifying no additional options, allows ripping of mp3 files no problem.

Running ldd on the packman (Suse repo) binary, and the one I compiled, show that the pm one is indeed compiled with libsndfile:
Callandor:~ # ldd /usr/bin/lame*
/usr/bin/lame:
linux-vdso.so.1 => (0x00007fff563ff000)
libncurses.so.5 => /lib64/libncurses.so.5 (0x00007fc9202d2000)
libm.so.6 => /lib64/libm.so.6 (0x00007fc92007b000)
libc.so.6 => /lib64/libc.so.6 (0x00007fc91fd1b000)
libdl.so.2 => /lib64/libdl.so.2 (0x00007fc91fb17000)
/lib64/ld-linux-x86-64.so.2 (0x00007fc920527000)
.
/usr/bin/lame-pm:
linux-vdso.so.1 => (0x00007fff9cfff000)
libmp3lame.so.0 => /usr/lib64/libmp3lame.so.0 (0x00007f84c6fc3000)
libncurses.so.5 => /lib64/libncurses.so.5 (0x00007f84c6d6e000)
libsndfile.so.1 => /usr/lib64/libsndfile.so.1 (0x00007f84c6b07000)
libm.so.6 => /lib64/libm.so.6 (0x00007f84c68b0000)
libc.so.6 => /lib64/libc.so.6 (0x00007f84c6550000)
libdl.so.2 => /lib64/libdl.so.2 (0x00007f84c634c000)
libFLAC.so.8 => /usr/lib64/libFLAC.so.8 (0x00007f84c60fc000)
libvorbisenc.so.2 => /usr/lib64/libvorbisenc.so.2 (0x00007f84c5d21000)
/lib64/ld-linux-x86-64.so.2 (0x00007f84c723f000)
libogg.so.0 => /usr/lib64/libogg.so.0 (0x00007f84c5b1a000)
libvorbis.so.0 => /usr/lib64/libvorbis.so.0 (0x00007f84c58ed000)

Input from other users on the Suse foum shows that this issue is a bit hit and miss. For some, lame linked against libsndfile seems to work okay. For myself and others on various bug reports, not so much. Building lame is very easy though, and should you be experiencing this issue it might be something to try.

The JCE editor has some nice features, including allowing you to insert php and Javascript into an article. There are however several things which may stop this from working. And judging for the huge number of forum posts on this, it seems that getting this to work is very problematic. Here is what I did to allow the use of Javascript in articles:

• Install the JCE editor plugin
• I recommend uninstalling, or at least disabling, any other PHP / Javascipt editor plugins (Jumi, Sourcerer, etc.) If these are active they tend to compete with each other. Simplify.
• Use the JCE configuration manager to grant permissions to the needed groups
• Configure JCE – set cleanup HTML to no
• In JCE group configuration settings: Allow PHP and Javascript
• This post was the hinge-pin of my issue. Ensure that the default content filter in Joomla is not set to clean content tags! By default in Joomla 1.5.8 even content added by Superadmin is cleaned.

1. Navigate to Content → Article Manager.
2. Press the Parameters icon in the toolbar to show the Articles – Global Configuration screen.
3. Scroll down to Filtering Options, highlight all Filter groups except Super Administrator, and select Filter type of Blacklist (Default)

• If content filtering as noted above is active, you may be able to insert, and even preview, code – but when you apply or save the code will be stripped.

Additional things you may need to do:

• Use the show / hide button in the editor to ensure your code is being inserted correctly. You might even need to follow a process of: click show/hide editor > hide > insert js> click apply> click show/hide > show > save

• If html tags are being added when you save, or other weird issue are occurring, try replacing the editor_plugin.js with a patched version from here and clear browser cache.
• Disable any other content / editor plugins that may be interfering to isolate the problem.

Additional info can be found at the JCE forums.

Another source of information on integrating Javascript and CSS can be found here

Recently I decided to revive my interest in playing the guitar. I took a few lessons back around 1988, but didn’t stick with it. Over the years  my desire to pick it up again has cropped up here and there, but either I was too busy with life and college, or my guitar was in another state, or whatnot. However, I was recently reunited with my guitar, but not my old amp. I decided to see how I might use my Linux box to allow my to play through it, and perhaps have some effects processing as well. I quickly discovered the rich extent of audio tools available for Linux, and even for the guitar specifically. I hit a gold mine.

I quickly found several USB sound cards with 1/4″ jack inputs, which were well supported under Linux, were readily available – and at a modest price. I ordered a Behringer UCG 102 off Amazon for all of $29.

Behringer UCG 102

I also discovered Rakarrack, an full featured guitar effects processing suite for Linux.  I had no issues getting Rakarrack installed, and anxiously awaited the arrival of the new sound card. If you play the guitar, you really have to check out Rakarrack – it is amazing.

Rakarrack - Sound Like a God

When the Behringer arrived I was shocked to discover the EnergyXT2 recording software it came with nativity supported Linux. Displayed right on the CD sleeve was a an nice capital “L” and advertised Linux support:

Yep - it runs on Linux.

This, of course, I would have to try – simply as a matter of principle. I soon discovered however several issues with this software, and my solutions to them are below.

NOTE: I should say however that the Behringer Guitar to USB interface worked flawlessly, and in short order I had connected my guitar, fired up the Jack audio server, launched Rakarrack and was playing. The effects provided by Rakarrack include: distortion, chorus, reverb, flanger, digital delay and many others. Wow – this is like having an array of effects pedals for free, and they sound great.  And it should be mentioned as well that the open source Ardour recording software worked without requiring anything beyond finding and installing the RPM. So . . . why even bother with getting EnergyXT2 to work? Well, because it’s there. I loved the idea of getting Linux software with a product I bought, and by God I intended to see it work.

Do you need to do this too? Well, that’s up to you. You can certainly use Ardour to record with, and it works extremely well. But if you want to try out EnergyXT, and use it with Jack, and with MIDI, and especially if you are running 64-bit – then read on.

If all you want is a basic working EnergyXT2 without Jack support, that should not be too difficult:

0) First – you need to download the latest version of EnergyXT2 for the website. The version which was shipped has a bug which caused it to fail returning:

X Error of failed request: BadImplementation (server does not implement operation)
Major opcode of failed request: 139 (MIT-SHM)
Minor opcode of failed request: 5 (X_ShmCreatePixmap)
Serial number of failed request: 382
Current serial number in output stream: 384
X Error of failed request: BadDrawable (invalid Pixmap or Window parameter)
Major opcode of failed request: 55 (X_CreateGC)
Resource id in failed request: 0x2a000a4
Serial number of failed request: 383
Current serial number in output stream: 384

This is easily solved by downloading the updated version. You might want to grab the manual too.

At this point it should start and work correctly, but you will not have Jack support. For that you need to continue with the next steps. This assumes some familiarity with compiling things, obtaining required libraries, and some basic debugging – it is not really difficult, but if you have not compiled things much it may be a learning experience.

1) The version of libaam.so provided with the software has several limitations, the most significant of which is that it does not support the Jack audio server.  Now – there are two routes to take here:

A) Download the source for libaam.so from the EnergyXT libaam site and compile using the instruction there, or:

B) Download and compile the source for from the libaam Jack Sourceforge project. This is most certainly the better route to take as it supports more MIDI channels and also can build a QT Interface to configure it to work with Jack. Simply download, untar and continue with the steps below.  Note this contains its own readme and make file, and QT interface, unlike the basic version for the EnergyXT site.

2) Next, I was building this on a 64-bit OpenSuse 11.3 system. The fact of building this on a 64-bit platform introduces a number of additional factors which have to be addressed. If you were to build this on a 32-bit platform, it would be easier.  If using a 64-bit environment (perhaps like Studio64) the first thing you need to do is ensure you have the 32-bit versions of the libraries you will need, AS WELL AS 32-bit versions of gcc, glibc, etc. These are going to be called different things depending on your distro, but you are looking for things like:

libasound2-devel
libjack-devel-1.9.5-2.8.i586 (get 32-bit version from webpin)
alsa-plugins-jack qjackctl
libqt4-devel-4.6.3-2.1.1.i586
alsa-devel-1.0.23-2.12.x86_64
glibc-32bit-2.11.2-3.3.1.x86_64
gcc45-32bit-4.5.0_20100604-1.12.x86_64
gcc-c++-32bit-4.5-4.2.x86_64

And maybe . . .

libSDL_mixer-1_2-0-32bit
libSDL_mixer-1_2-0

Should you receive any build errors complaining about libs you know you have, may need to make some symlinks for several of the libraries, such as:

sudo ln -s /usr/lib/libasound.so.2.0.0 /usr/lib/libasound.so
sudo ln -s /usr/lib/libjack.so.0.1.0 /usr/lib/libjack.so
sudo ln -s /lib/libgcc_s.so.1 /lib/libgcc_s.so

Getting all the 32-bit libraries you need may take a few tries – each time you compile you may be presented with some new library needed – but you should be able to work through them and fortunately there are a limited number required.

If you do not have 32-bit gcc, you may get messages similar to:

paracelsus@Callandor:~/energyXT/libaam-0.0.2> g++ -m32 -shared -lasound -ljack jack.cpp -o libaam.so
/usr/lib64/gcc/x86_64-suse-linux/4.3/../../../../x86_64-suse-linux/bin/ld:
i386:x86-64 architecture of input file `/usr/lib64/gcc/x86_64-suse-linux/4.3/crtbeginS.o’ is incompatible with i386 output

This is simply due to missing the proper gcc and g++ 32-bit packages – oops. (While I had the necessary 32-bit libs for qt and Jack, I  inadvertently had not installed 32-bit gcc and g++ libs, so it indeed was missing the 32-bit version of crtbeginS.o, just like it says.

2) This then allowed libaam.so to build, and you should be able to use the library at this point. You most likely want the configuration interface too, but building xt2-config failed with a missing qmake-qt4, though it was installed. That was corrected with a symlink:

ln -s /usr/lib/qt4/bin/qmake /usr/bin/qmake-qt4

3) The next problem building xt2-config was with it expecting a 32-bit build environment – Note that -m32 is specified in the Makefile for libaam, but NOT in the config/Makefile for xt2-config, thus:

g++ -c -m32 -pipe -g -Wall -W -D_REENTRANT -DQT_GUI_LIB -DQT_CORE_LIB -DQT_SHARED -I/usr/share/qt4/mkspecs/linux-g++ -I. -I/usr/include/QtCore -I/usr/include/QtGui -I/usr/include -I. -I. -o moc_configw.o moc_configw.cpp
g++  -o xt2-config main.o configw.o moc_configw.o    -L/usr/lib -lQtGui -L/usr/lib -L/usr/X11R6/lib -lQtCore -lpthread
/usr/lib64/gcc/x86_64-suse-linux/4.3/../../../../x86_64-suse-linux/bin/ld: skipping incompatible /usr/lib/libQtGui.so when searching for -lQtGui
/usr/lib64/gcc/x86_64-suse-linux/4.3/../../../../x86_64-suse-linux/bin/ld: skipping incompatible /usr/lib/libQtGui.so when searching for -lQtGui
/usr/lib64/gcc/x86_64-suse-linux/4.3/../../../../x86_64-suse-linux/bin/ld: skipping incompatible /usr/lib/libQtGui.so when searching for -lQtGui
/usr/lib64/gcc/x86_64-suse-linux/4.3/../../../../x86_64-suse-linux/bin/ld: cannot find -lQtGui

Now, I can see that g++ is not being called with -m32 when it links the three compiled files main.o configw.o moc_configw.o To get this to build correctly I modified the Makefile in config/Makefile (which is called from the Makefile in the build root), and added:

#CFLAGS        = -pipe -g -Wall -W -D_REENTRANT $(DEFINES)
CFLAGS        =  -m32 -march=i386 -pipe -g -Wall -W -D_REENTRANT $(DEFINES)
#CXXFLAGS      = -pipe -g -Wall -W -D_REENTRANT $(DEFINES)
CXXFLAGS      =  -m32 -march=i386 -pipe -g -Wall -W -D_REENTRANT $(DEFINES)

And . . .

####### Build rules

all: Makefile $(TARGET)

$(TARGET): ui_config.h $(OBJECTS)
        $(LINK) $(LFLAGS) $(CXXFLAGS) -o $(TARGET) $(OBJECTS) $(OBJCOMP) $(LIBS)

The result is a working libaam.so you can copy to your energyXT folder (backup and replace the existing) which supports Jack, and a working xt2-config (move it from config/ to /usr/bin)

xt2-config for Jack Audio

Of course on a 32-bit OS EnergXT2 should just run out of the box (as long as you have downloaded an updated copy) but you still would not have Jack support (which is really the way to go), or the QT config interface, and as more users move to 64-bit and RT kernels for audio applications, this may come in handy.

Today the above PHP bug was pointed out to me, and in looking into it further I discovered a few interesting things, which I’ve decided to list here.  While this bug is serious, a bit of research quickly showed it requires a rather specific combination of PHP version, OS architecture and CPU architecture and feature set, as well as PHP build options.

1) This is completely dependent on an x87 FPU design flaw, wherein 80-bit FP arithmetic is used.

2) Newer processors (x86-64)  with  SSE2 are IEEE-754 compliant, and use 64-bit FP.  So, even if you are running an affected version of PHP (5.3.x or 5.2.x) on a 32-bit OS, if you have an X86-64 CPU you may not in fact be affected (depending on how php was built). Test and see by running a simple test such as:

[user@host ~]$ cat phptest.php
<?php $d = 2.2250738585072011e-308; echo $d + 0; echo “\n”; ?>
[user@host ~]$ php phptest.php
2.2250738585072E-308

3) One work around, if you are affected, is to simple have php.ini preload a simple  script to detect to handle requests containing the problematic value, as described here.

4) Alternatively, if you wish to compile your own PHP, adding -mfpmath=sse (or -ffloat-store) to your CFLAGS will also resolve this issue.

While at first this bug may cause a sense that great effort will be needed on a sys admins part to update PHP on many servers, investigation and testing may show that little needs to be done. Of course, new packages for PHP 5.3 will soon be available with will correct the issue as well, but the above may assist you in assessing what actions may need to be taken in the interim.