Monzool’s Personal Publishing

THE SERIAL PORT on my Fedora 15 install, mysteriously refused to be accessed. I discovered that when inserting a USB-to-Serial device, GNU screen would refuse to access the created device /dev/ttyUSB0.

» screen /dev/ttyUSB0 115200
[screen is terminating]

Since I could use screen for serial access as root, and because the newly installed Fedora did have some hiccups in adding my user (the /home/monzool directory already existed from a previous Ubuntu install), I first checked group permissions, but they seemed fine for this situation.

» ll /dev/ttyUSB0
crw-rw----. 1 root dialout 188,  0 Jun  6 08:27 /dev/ttyUSB0
 
» groups
monzool tty wheel uucp dialout tcpdump screen vboxusers

Screen didn’t offer much indication of the problem, but using strace I could see that some of the last things checked for permissions where /var/run/screen. I then removed that directory and recreated the directory setup by starting screen with sudo.

» ll /var/run/screen
drwxrwxr-x. 4 root    root    80 Jun  6 08:27 screen
» rm -rf /var/run/screen
» sudo screen /dev/ttyUSB0
» ll /var/run/screen
drwxrwxr-x. 4 root    screen    80 Jun  6 08:47 screen

This helped nothing! :-(

I then tried minicom, which was more informative about the problem

» minicom
minicom: cannot open /dev/ttyUSB0: Device or resource busy

This would mean that something else had hijacked the port. A quick check confirmed that something called gpsd was using the port.

»  lsof /dev/ttyUSB0
COMMAND PID   USER   FD   TYPE DEVICE SIZE/OFF  NODE NAME
gpsd    883 nobody    8u   CHR  188,0      0t0 11408 /dev/ttyUSB0
»  ps ax | grep gpsd
  883 ?        S<s    0:00 gpsd -n -F /var/run/gpsd.sock

Now gpsd is for handling GPS devices, but it made no sense to trigger this daemon for a simple USB-to-Serial adapter.

Knowing what was causing the hazzle, I found this bug rapport https://bugzilla.redhat.com/show_bug.cgi?id=663124. In it, it is proposed to set USBAUTO=no in /etc/sysconfig/gpsd.

» echo "USBAUTO=no" >> /etc/sysconfig/gpsd

And sure enough, this fixed the problem. The USB-to-Serial adapter could now be accessed by any serial terminal.

I’VE BOUGHT A copy of the game Sacred Gold in an edition that is ported to Linux. This would be very exiting… if it didn’t segfault every time I start it :-(

$ sacred
sacred 1.0.1, built for i386        
Segmentation Fault: I dont believe in dragons! oh...
 
This is a BUG, please report it to http://support.linuxgamepublishing.com
Stack dump:                                                             
{                                                                       
        [0xb8024400]                                                    
        /usr/lib/gtk-2.0/modules/libcanberra-gtk-module.so [0xb68299a6] 
        /usr/lib/gtk-2.0/modules/libcanberra-gtk-module.so(gtk_module_init+0x5d) [0xb6829a5d]
        /usr/local/games/sacred/lib/lib1/libgtk-1.2.so.0(gtk_init_check+0x3f3) [0xb7700443] 
        sacred [0x860422e]                                                                  
        sacred [0x8620770]                                                                  
        sacred [0x860839b]                                                                  
        sacred [0x809ab90]
        /lib/i686/cmov/libc.so.6(__libc_start_main+0xe5) [0xb71557a5]
 
        sacred(gtk_widget_grab_focus+0x31) [0x8053849]
}

The game publisher Linux Game Publishing has provided a test tool that evaluates if your system should be able to execute the game…

# testtool
Testing installation... OK, installed at /usr/local/games/testtool
Base system Test
----------------
Testing architecture of system... 32 bits
Testing system CPU... 1242MHz
Testing CPU flags... MMX SSE SSE2 SSE3
Testing system memory... 2025MB
 
Graphics Test
-------------
Looking for OpenGL library
Accepting /usr/lib/libGL.so.1
X Error of failed request:  BadMatch (invalid parameter attributes)
  Major opcode of failed request:  155 (GLX)
  Minor opcode of failed request:  5 (X_GLXMakeCurrent)
  Serial number of failed request:  26
  Current serial number in output stream:  26

So It appeared that I had some trouble with the proprietary Nvidia driver. I ran glxinfo and indeed it gave an error.

$ glxinfo | grep -i error
Error: glXCreateContext failed

On the world wide web I found some hints about adding the following lines to xorg.conf.

Section "Files"
    ModulePath      "/usr/lib/xorg/modules/extensions"
    ModulePath      "/usr/lib/xorg/modules/drivers"   
    ModulePath      "/usr/lib/xorg/modules"           
EndSection

That didn’t help. :-(

Grepping the logs however revealed some useful information

$grep -i glx /var/log/*
/var/log/Xorg.0.log:(II) "glx" will be loaded. This was enabled by default and also specified in the config file.
/var/log/Xorg.0.log:(II) LoadModule: "glx"
/var/log/Xorg.0.log:(II) Loading /usr/lib/xorg/modules/extensions//libglx.so
/var/log/Xorg.0.log:(II) Module glx: vendor="X.Org Foundation"
/var/log/Xorg.0.log:(==) AIGLX enabled
/var/log/Xorg.0.log:(II) Loading extension GLX
...
/var/log/Xorg.0.log:(EE) NVIDIA(0): Failed to initialize the GLX module; please check in your X
/var/log/Xorg.0.log:(EE) NVIDIA(0):     log file that the GLX module has been loaded in your X
/var/log/Xorg.0.log:(EE) NVIDIA(0):     server, and that the module is the NVIDIA GLX module.  If
/var/log/Xorg.0.log:(==) NVIDIA(0): Enabling 32-bit ARGB GLX visuals.

It was clear that the Nvidia driver failed to intitalize the GLX module, but before that, it can be seen that another GLX module was actually loaded Module glx: vendor="X.Org Foundation". This was a big hint.

Looking into earlier investigated directories I could see that I had two different versions of the glx library files installed?

/usr/lib/xorg/modules/extensions# ll
-rwxr-xr-x 1 root root 1269220 2009-07-25 13:10 libglx.so.173.14.20
-rw-r--r-- 1 root root  337008 2009-09-28 07:32 libglx.so

It seemed strange that I had two so differently sized versions of libglx laying around, and also that the Nvidia version appeared not to be the default file.
Searching for the libglx file revealed that only the fglrx-driver and the Nvidia drivers supplied that file.

$ apt-file search libglx.so
fglrx-driver: /usr/lib/xorg/modules/extensions/libglx.so
nvidia-glx: /usr/lib/xorg/modules/extensions/libglx.so
nvidia-glx: /usr/lib/xorg/modules/extensions/libglx.so.185.18.36
nvidia-glx-legacy-173xx: /usr/lib/xorg/modules/extensions/libglx.so
nvidia-glx-legacy-173xx: /usr/lib/xorg/modules/extensions/libglx.so.173.14.20
nvidia-glx-legacy-71xx: /usr/lib/xorg/modules/extensions/libglx.so
nvidia-glx-legacy-71xx: /usr/lib/xorg/modules/extensions/libglx.so.71.86.07
nvidia-glx-legacy-96xx: /usr/lib/xorg/modules/extensions/libglx.so
nvidia-glx-legacy-96xx: /usr/lib/xorg/modules/extensions/libglx.so.96.43.13
xserver-xorg-core: /usr/lib/xorg/modules/extensions/libglx.so
xserver-xorg-core-dbg: /usr/lib/debug/usr/lib/xorg/modules/extensions/libglx.so

Although the only glx package that was installed on the system was libgl1-mesa-glx.

$ aptitude apts glx
p   fglrx-glx
i A libgl1-mesa-glx

Looking at libgl1-mesa-glx showed that that package installed a OpenGL library file

$dpkg -L libgl1-mesa-glx
/.
/usr
/usr/share
/usr/share/doc
/usr/share/doc/libgl1-mesa-glx
/usr/share/doc/libgl1-mesa-glx/copyright
/usr/share/doc/libgl1-mesa-glx/changelog.Debian.gz
/usr/share/lintian
/usr/share/lintian/overrides
/usr/share/lintian/overrides/libgl1-mesa-glx
/usr/lib
/usr/lib/libGL.so.1.2
/usr/lib/libGL.so.1

Strangely also here a Nvida version of the library existed in /usr/lib

-rwxr-xr-x 1 root root   667528 2009-07-25 13:10 libGL.so.173.14.20

This seemed like the Nvidia installer have had collisions with other already installed packages and had failed to resolve the situation properly. Unfortunately the installer had warned nothing about this situation. What I did then was to remove the existing libraries and make a symlink to the Nvidia libraries for libglx and libGL.

/usr/lib/xorg/modules/extensions# ll libglx*
lrwxrwxrwx 1 root root      19 2009-10-01 22:22 libglx.so -> libglx.so.173.14.20
-rwxr-xr-x 1 root root 1269220 2009-07-25 13:10 libglx.so.173.14.20

/usr/lib# ll libGL*
lrwxrwxrwx 1 root root       18 2009-09-13 13:40 libGL.so.1 -> libGL.so.173.14.20
lrwxrwxrwx 1 root root       18 2009-10-01 22:52 libGL.so.1.2 -> libGL.so.173.14.20
-rwxr-xr-x 1 root root   667528 2009-07-25 13:10 libGL.so.173.14.20

And then… glxinfo ran with no errors.

The log also changed for the better

$grep -i glx /var/log/*
/var/log/Xorg.0.log:(II) "glx" will be loaded. This was enabled by default and also specified in the config file.
/var/log/Xorg.0.log:(II) LoadModule: "glx"
/var/log/Xorg.0.log:(II) Loading /usr/lib/xorg/modules/extensions//libglx.so
/var/log/Xorg.0.log:(II) Module glx: vendor="NVIDIA Corporation"
/var/log/Xorg.0.log:(II) NVIDIA GLX Module  173.14.20  Thu Jun 25 19:49:59 PDT 2009
/var/log/Xorg.0.log:(II) Loading extension GLX
/var/log/Xorg.0.log:(II) NVIDIA(0): Support for GLX with the Damage and Composite X extensions is
/var/log/Xorg.0.log:(==) NVIDIA(0): Enabling 32-bit ARGB GLX visuals.
/var/log/Xorg.0.log:(II) Loading extension NV-GLX
/var/log/Xorg.0.log:(II) Initializing extension GLX

Unfortunately Sacred still segfaults big time :-(

THE MENU IN GVim suddenly disappeared?! I did not provoke this by making changes in any .vimrc, .gvimrc or in any files in the .vim directory. The menu was just gone after a boot when GVim auto-loaded the documents open before the reboot. The system is Kubuntu 8.04 and vim-gnome.

I googled for a solution and eventually found an answer at Nabble (thanks goes to mmarko). It appears that something (?) changed the Gnome setup for GVim in the file ~/gnome2/vim.


No menu:

[Placement]
Dock=Toolbar\\0,0,0,0\\Menubar\\0,0,0,0

With menu:

[Placement]
Dock=Toolbar\\0,1,0,0\\Menubar\\0,0,0,0

MICROSOFT WORD 2007 was in todays pool of software upgrades at work. Our previous edition of Word was the 2003 edition, and I must say that the UI and MMI has been changed to a whole new concept. It looks fine and all. And its actually pretty easy to navigate the new “Ribbon”, but the direct keyboard shortcuts are not visible in the (non-existing) menu’s anymore – so I forget them.

Complementary to the normal direct shortcuts, Microsoft has introduced a feature known from e.g. both the Opera and Konquerer browsers. When pressing the Alt key, every menu, group and function gets assigned one or more keys which activates the item… wait. That sounds familiar…

Skimming though Microsoft’s Word 2007 navigation tutorial a funny quote emerges: “In other words, you need to get out of text entry mode and into command mode.”

That sounds like something taken right out of the Vi/Vim manual – lol.

LIBERATED AT LAST. No more torment and self-punishment of using Mac OS X. I finally caved and wiped the Apple operating system from my Macbook and installed Debian and KDE 4. Sweet.

For a long time I’ve been reluctant to wipe the Mac OS X. I wouldn’t just give up on Mac OS X that easy. If so many people finds it that great, why did I keep hitting shortcoming after shortcoming and stupidity after stupidity?

If I should list what I like about the Mac OS X, I could list three things: Front-row is a pretty good media center. Mac OS X boots really fast. I like the zebra wallpaper – I kept that.

As for reasons that I don’t like the Mac OS X experience I could list a few. For example: Finder sux bad and is slow as molasses and stupid. The terminal is broken. I hate when CD’s won’t eject. Its frustrating that wireless cannot reconnect after standby. Hate those stupid obscure keyboard shortcuts. Feel back at Window 2000 with software updates that requires rebooting. I loathe those giant updates to iTunes which I rarely used. The multi-workspace concept in Spaces, its borked. The hibernation support is lousy at best. Hate that stupid inefficient application task switcher. And not by fault of Apple, I’m unhappy with the endless row of bad Total Commander/Krusader clones. I’m also irritated on an almost endless row of broken macports and broken fink ports.

It actually required two attempts to get the Macbook up and running. On the first attempt I followed the directions from the Debian Macbook Wiki, which preach that Lilo must be install for a later replacement by Grub. After installing Grub it was no longer possible to boot. On the second attempt I installed Debian like normal, and chose Grub as boot manager. Then it worked. Actually in a few other occasions I got into troubles when following the guides. It seems that the Debian Macbook Wiki is somewhat outdated on certain areas, as some special “jumping though loops” measures are no longer required, but would rather get you into trouble. Installing the 915resolutions package for example, crashed my X, but was in fact not necessary to get the prober resolution anyways. However it provides many valuable informations and links, and generally ease the installation considerable.

HAVING GROWN UP using Norton Commander for DOS, Total Commander on Windows and Midnight Commander and Krusader on Linux, its hard, if not impossible, to do work without a proper Norton Commander clone. This is true, especially on Mac OS. The standard file tools in Mac OS X are useless compared to the mentioned tools. For Mac OS X a range of native alternatives exists like Disk Order, XFolders, Fork Lift and muCommander. None of them are really good though. They all have their own weirdness’ and shortcomings, and generally none comes near the functionality and speed of used offered by Krusader or Total Commander.

I’ve used Midnight commander on Mac OS X, but I prefer Krusader, and thankfully its pretty easy to get Krusader up and running on Mac OS X thanks to the Fink project. If not having installed Fink already, do so by performing the following steps after downloading the source distribution (a binary installer is provided for Mac OS X Tiger).

$ tar xvf fink-0.28.1.tar
$ cd fink-0.28.1
$ ./bootstrap
$ /sw/bin/pathsetup.sh
$ source ./init.sh
$ fink selfupdate

Fink is now installed, configured, updated and ready for use. Installing Krusader and the required dependencies takes only a single command.

$ sudo fink install krusader

Wait for compilation to complete (may take a while). If everything goes well, Krusader should be able to be started from the terminal window.

$ krusader &

Running Krusader I discovered that the Meta/Alt key was not possible to use. This is unfortunate as many keyboard shortcuts in Krusader uses that key. Fixing this requires two setup modifications. In the X11 preferences I deselected all options under the tab ‘input’. This makes sure that X11 won’t override any personal settings made on the keyboard setup. Alas this is exactly what is required for the Meta/Alt key to work. Terminate the X11 session and edit the file ~/.Xmodmap (create it if not existing). Add the following keyboard mappings.

clear Mod1
keycode 66 = Meta_L
add Mod1 = Meta_L
keycode 69 = Mode_switch
add Mod1 = Mode_switch

Now Krusader can be used with working keyboard shortcuts :-) (note that my MacBook has a Danish keyboard, so the above mappings may possible be different if using another keyboard layout).

YAST MAY BE a powerful tool, but sometimes Suse and OpenSuse still manage to screw up their configuration so not even Yast can rectified the situation. We use Suse and OpenSuse at work, and twice I’ve experienced that the network configuration cannot recover from a netcard being changed. During boot an error message “eth0 renamed to eth2″ would show, followed by another error message (after a looong timeout) “no configuration found for eth2″ and afterwards DHCP would fail. After booting I would have to run ifup-dhcp eth2 to get network up and running.

Okay. The situation is amendable and requires only two setup modifications (hacks). First an easy edit in the udev network rules, to fix that the one and only netcard was being named eth2 and not eth0.

The netcard MAC-addresses and names are associated in the udev network persistent name rule-file. /etc/udev/rules.d/30-net_persistent_names.rules

SUBSYSTEM=="net", ACTION=="add", SYSFS{address}=="00:0c:29:14:e6:1b", IMPORT="/lib/udev/rename_netiface %k eth0"
SUBSYSTEM=="net", ACTION=="add", SYSFS{address}=="00:0c:29:e9:d1:b6", IMPORT="/lib/udev/rename_netiface %k eth1"
SUBSYSTEM=="net", ACTION=="add", SYSFS{address}=="00:0c:29:32:11:fd", IMPORT="/lib/udev/rename_netiface %k eth2"

This file contained some mappings not belonging to any netcards in my current system. Ensuring that the MAC-address mached the eth2 entry, I renamed the entry and deleted the other two.

SUBSYSTEM=="net", ACTION=="add", SYSFS{address}=="00:0c:29:32:11:fd", IMPORT="/lib/udev/rename_netiface %k eth0"

If booting after this modification, the first error message would vanish and, as remapping now is no longer enforced, the second would now be “no configuration found for eth0“.

The missing configuration can be fixed in Yast by creating a new ethernet device called ifcfg-eth0, or as I did, by just soft-linking the existing network configuration to that name.

# ln -s /etc/sysconfig/network/ifcfg-eth-bus-pci-0000\\:02\\:00.0
/etc/sysconfig/network/ifcfg-eth0

Yehaa. Network errors be gone, and automatic DHCP now working :-).

I’ve experienced this problem on Suse 10.0 on a fresh install where I changed a VMware virtual netcard from the computers build-in netcard to a secondary USB netcard. At that time I didn’t want to spend to much time on it and just reinstalled. We’d just upgraded to OpenSuse 10.2 and I was handed a copy of a colleagues VMware image. As his netcard did not have the same properties as mine (i.e. MAC-address) I was hurled into the same problems once again.

GUI PROGRAMMING IS not something I’ve done in quite a while. At work I do embedded programming and that’s mainly also what I’ve been doing for my own personal projects. Except for some small utility applications I really haven’t done large GUI projects since MFC 6.0 was cool (if such a time ever was) ]:->.

An absolute requirement is that the end result must be multi platform capable (Linux, BSD, Mac OS X and Windows). Plenty of frameworks and toolkits exists that fulfill that requirement, but I find that the Kde/Qt constallation is the most exiting and complete toolkit(s) around – especially given the multi platform perspective introduced by Kde 4. Although Kde 4 is not quite stable yet, I think the choice is wise in a longterm perspective.

I primarily do C/C++ programming (and a bit of Lua scripting), but I really would like to extend my horizon (or more precise raise above n00b level) in other programming languages like C# and Python. Given that I have much to learn about Kde, GUI’s and what else is hot in the desktop programming world, the option of C# is not a mandatory requirement. I could settle on a C++ and Python solution.

Mixing two complete different kinds of languages (static and dynamic) requires either good binding layers or Mono. The Kde Project provides a large suite of binders in the KdeBindings package. The README contains a concise description of the project contents:

This package contains:
* working:
  * korundum: KDE bindings for ruby
  * qtruby: Qt bindings for Ruby
  * smoke: Language independent library for Qt and KDE bindings. Used by QtRuby
    and PerlQt.
  * kalyptus: a header parser and bindings generator for Qt/KDE. Used for
    Smoke, Java, C# and KSVG bindings generation at present.
  * ruby/krossruby and python/krosspython which are plugins for the kdelibs/kross
    scripting framework to provide scripting with python+ruby to applications.
  * PyKDE: KDE bindings for python, requires PyQt from riverbankcomputing.co.uk
  * Qyoto: Qt bindings for C#
  * Kimono: KDE bindings for C#

The Mono project seems to be somewhat controversial. A lot of writing has being going on lately on Mono vs. Novell/Microsoft vs. freedom. Anders Hejlsberg and his team have created both clever and interesting stuff in the .NET architecture like C#, DTS (Common Type System) and CLR (Common Language Specification), but I can’t appreciate embracing other closed proprietary technologies from the .NET portfolio, when other alternatives exist in the FOSS community. I think Robert Devi summed it up nice in the Osnews.com comments (the personal rantings of Robert on Mono speed/memory, Amarok etc. I don’t agree on).

As far as I can tell, the above observations give me the following constructs:

1. C++ + Kross + PyQt + PyKde(*1).
2. Mono + C# + limited managed C++ + Qyoto/Kimono + IronPython.

*1: PyKde is not released for Kde 4 at present time.

Its a difficult decision whether to choose the one or the other construct. Because I have already done much C++ coding (and shot a foot off more that once) and not much C# coding, I lean mostly towards the Mono solution. Unfortunately this could potentially force me to use MonoDevelop. Tried it eight months ago and tried it again yesterday; it’s still the single most unstable piece of software I ever used :-(. Hope its not the case that it only works on OpenSuse or Suse. That would not be freedom. Anyways, selecting C# would mean that the money I spent on the book Professional C#, 3rd Edition won’t go to waste.

THE HEXDUMP MAN page, I find, is not the best written example of an applications manual. I recently had a task of finding the addresses of filename encounters generated when a bunch of files were written to an uncompressed jffs2 partition. Normally I’ve been sticking to the simple hexdump -C <device> use, but grepping filenames from the output is not applyible because of the line breakings.

$ hexdump -C /dev/mtd0  | grep count
00092df0  63 6f 75 6e 74 31 32 2e  64 61 74 ff 19 85 e0 02  |count12.dat.....|
000bfe80  00 00 0e 0b 08 63 6f 75  6e 74 31 33 2e 64 61 74  |.....count13.dat|
000c7f10  63 6f 75 6e 74 30 39 2e  64 61 74 ff 19 85 e0 02  |count09.dat.....|
000f9a80  ff 40 62 1d f9 72 7e e3  63 6f 75 6e 74 31 31 2e  |.@b..r~.count11.|
000ffb90  63 6f 75 6e 74 30 39 2e  64 61 74 e0 02 00 00 00  |count09.dat.....|
000ffd80  0a 00 00 00 0b 0b 08 63  6f 75 6e 74 31 30 2e 64  |.......count10.d|
00115e20  bd 6e 58 e6 63 6f 75 6e  74 30 37 2e 64 61 74 ff  |.nX.count07.dat.|
0012ebe0  63 6f 75 6e 74 30 38 2e  64 61 74 ff 19 85 e0 02  |count08.dat.....|
0013fcc0  00 08 0b 08 63 6f 75 6e  74 30 37 2e 64 61 74 e0  |....count07.dat.|
0013feb0  01 00 00 00 08 00 00 00  09 0b 08 63 6f 75 6e 74  |...........count|
0014af40  fa ce 22 36 63 6f 75 6e  74 30 34 2e 64 61 74 ff  |.."6count04.dat.|
00163d00  63 6f 75 6e 74 30 35 2e  64 61 74 ff 19 85 e0 02  |count05.dat.....|
0017fbc0  00 00 00 05 0b 08 63 6f  75 6e 74 30 34 2e 64 61  |......count04.da|
0017ffb0  00 07 0b 08 63 6f 75 6e  74 30 36 2e 64 61 74 e0  |....count06.dat.|
00180070  16 b6 2c e3 32 2e ad 46  63 6f 75 6e 74 30 31 2e  |..,.2..Fcount01.|
00198e30  75 8e d7 96 63 6f 75 6e  74 30 32 2e 64 61 74 ff  |u...count02.dat.|
001b1bf0  63 6f 75 6e 74 30 33 2e  64 61 74 ff 19 85 e0 02  |count03.dat.....|
001bfb00  0b 08 63 6f 75 6e 74 30  31 2e 64 61 74 e0 02 00  |..count01.dat...|
001bfcf0  00 00 02 00 00 00 03 0b  08 63 6f 75 6e 74 30 32  |.........count02|
001bfef0  63 6f 75 6e 74 30 33 2e  64 61 74 e0 02 00 00 00  |count03.dat.....|

Wanting to hexdump to produce an output more suitable for searching, I read the hexdump man page where it is evident that hexdump provides flexible output formatting.

     -e format_string
             Specify a format string to be used for displaying data.

The short description is elaborated in a later section

   Formats
     A format string contains any number of format units, separated by white-
     space.  A format unit contains up to three items: an iteration count, a
     byte count, and a format.

Okay, three parameters of which two of them are optional. Regarding the non-optional format specifier, it must be double quoted.

     The format is required and must be surrounded by double quote (" ")
     marks. It is interpreted as a fprintf-style format string (see
     fprintf(3)) ...

Okay. Not so hard. I know fprintf syntax. So what configuration am I optionally skipping? The first parameter is iteration count.

     The iteration count is an optional positive integer, which defaults to
     one.  Each format is applied iteration count times.

So, what does the iteration count actually do? Repeat the same printout x number of times? That of course would be a daft thing to do. Not being a native English speaker, I reassured that iteration did not have any dualistic meaning unknown to me. Dictionary.com defines

Hmm, still not exactly clear on what iteration does. I’d better experiment to figure it out. Next optional parameter defines a byte count.

     The byte count is an optional positive integer.  If specified it defines
     the number of bytes to be interpreted by each iteration of the format.

Huh? Byte count of what again? Does this relate to the amount of "%c"‘s and what-not I put in the mandatory part?. Experimentations will tell. The final details on the optional parameters are how to apply them.

     If an iteration count and/or a byte count is specified, a single slash
     must be placed after the iteration count and/or before the byte count to
     disambiguate them.

That would be iterations or iterations/byte_count told in many words forming an obscure sentence?

Well, feeling armed for some basic hexdump formatting, I proceeded to do some experimentations.

$ hexdump -e "0x%08x" /dev/mtd0
hexdump: bad format {0x%08x}

What?! I took another look at the examples provided by the man page.

     Display the input in perusal format:

           "%06.6_ao "  12/1 "%3_u "
           "\\t\\t" "%_p "
           "\\n"

Hmm, and I write all three lines how? Or is it three examples? Tried the top line from the example. It worked, although of course not giving me the output format desired. Cos of the nature of the input data, the generated output actually didn’t make much sense, but now a little wiser I continued experimenting.

$ hexdump -e 8/1 "0x%08x" /dev/mtd0
hexdump: bad format {8/1}

Hmm, perhaps a double qouting is required before the “optional” parameters?.

-sh-2.05b# hexdump -e "" 8/1 "0x%08x" /dev/mtd0
Segmentation fault

WTF!? Near having a fury induced head explosion I resolved to Google. Seems that I’m not the only one having a hard time decoding the ‘-e’ description (even though the kind poster states that reading the man page is understanding hexdump). The apparent proper syntax is:

$ hexdump -e ' [iterations]/[byte_count] "[format string]" '

This was not the exact syntax mentioned in the man page, but I tried.

$ hexdump -e '6/1 "0x%08x, "' -e '"\\n"' /dev/mtd0

Hurraa, it worked. Having this figured out, the only thing left was to find out what the exact functionality of the iteration and byte_count parameters were? I wasn’t fully enlightened by the output, so a few more tests should reveal the purpose of them both.

$ hexdump -e '6/1 "0x%08x, "' -e '"\\n"' /dev/mtd0
0x000000ff, 0x000000ff, 0x000000ff, 0x000000ff, 0x000000ff, 0x000000ff,
0x000000ff, 0x000000ff, 0x000000ff, 0x000000ff, 0x000000ff, 0x000000ff,

Hmm, six columns…

$ hexdump -e '4/1 "0x%08x, "' -e '"\\n"' /dev/mtd0
0x000000ff, 0x000000ff, 0x000000ff, 0x000000ff,
0x000000ff, 0x000000ff, 0x000000ff, 0x000000ff,
0x000000ff, 0x000000ff, 0x000000ff, 0x000000ff,
0x000000ff, 0x000000ff, 0x000000ff, 0x000000ff,

Aha, so… iterations equals columns. Still not figured out the byte_count parameter though.

$ hexdump -e '6/2 "0x%08x, "' -e '"\\n"' /dev/mtd0
0x0000ffff, 0x0000ffff, 0x0000ffff, 0x0000ffff, 0x0000ffff, 0x0000ffff,
0x0000ffff, 0x0000ffff, 0x0000ffff, 0x0000ffff, 0x0000ffff, 0x0000ffff,

Perhaps the partial empty (erased) flash section was not the best example to learn from, so I created a file repeating the numbers 00 to 09.

$ hexdump -e '6/1 "0x%08x, "' -e '"\\n"' count.hex
0x00000000, 0x00000001, 0x00000002, 0x00000003, 0x00000004, 0x00000005,
0x00000006, 0x00000007, 0x00000008, 0x00000009, 0x00000000, 0x00000001,
0x00000002, 0x00000003, 0x00000004, 0x00000005, 0x00000006, 0x00000007,
0x00000008, 0x00000009, 0x00000000, 0x00000001, 0x00000002, 0x00000003,

$ hexdump -e '6/2 "0x%08x, "' -e '"\\n"' count.hex
0x00000100, 0x00000302, 0x00000504, 0x00000706, 0x00000908, 0x00000100,
0x00000302, 0x00000504, 0x00000706, 0x00000908, 0x00000100, 0x00000302,
0x00000504, 0x00000706, 0x00000908, 0x00000100, 0x00000302, 0x00000504,
0x00000706, 0x00000908, 0x00000100, 0x00000302, 0x00000504, 0x00000706,

Aha, guess that(?) would fit the byte count description…

Having finally decoded the man page I set on to find a proper output. After some unsuccessful attempts, I googled for a hint to a solution. Eventually I found some indications that, to get the desired formatting, I should utilize some of the non-fprintf formatting options provided by hexdump. More man page decoding? No fucking way! Enough of this shit!

Having wasted precious work time, I abandoned hexdump and put together a little Lua script that would do the hex dumping and format the output to fit my requirements.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59

#!lua
--[[  Hex dump utility
      usage:   lua xdex.lua pattern file
 
      example: lua xdex.lua "count%d%d.dat" file.dat
--]]
 
local debug = false
 
-- http://lua-users.org/wiki/LuaPrintf
printf = function(s,...)
           return io.write( s:format(...) )
         end -- function
 
local f = assert(io.open(arg[2], "rb"))
local data = f:read("*all")
 
--
-- Locate offsets of all pattern matching items
--
local offset_begin, offset_end = 0, 0
local items = {}
local index = 1
 
repeat
  offset_begin, offset_end = string.find( data, arg[1], offset_begin+1 )
  if offset_begin == nil then
    break
  end
  items[index] = { offset_begin, offset_end }
  index = index+1
  if debug then printf("%08xh - %08xh\n", offset_begin, offset_end) end
until ( offset_begin == nil )
items[index] = { nil, nil } -- Terminate
 
--
--    Hexdump alike printing of results
--    (Inspired from test/xd.lua in lua5.1 distribution)
index = 1
local offset = 0
while true do
  local s = string.sub( data, offset+1, offset+16 )
  if s == nil or items[index][1] == nil then
    return
  end
 
  if (offset+16) >= items[index][1] then
    io.write( string.format("%08x  ", offset) )
    string.gsub( s,"(.)",
        function (c) io.write( string.format("%02x ",string.byte(c)) ) end )
    io.write( string.rep(" ", 3*(16-string.len(s))) )
    io.write( " ", string.gsub(s,"%c","."), "\n" )
 
    if (offset+16) >= items[index][2] then
      index = index+1
    end
  end
  offset=offset+16
end

The output from the above script correctly finds 26 encounters of the input pattern, where the original grepping on the hexdump output would only discover 20 encounters.

$ xdex.lua "count%d%d*[.]dat" /dev/mtd0
00092df0  63 6f 75 6e 74 31 32 2e 64 61 74 ff 19 85 e0 02  count12.datÿ.à.
000abba0  0b 08 00 00 03 f0 42 2c 83 b2 2d 83 63 6f 75 6e  .....ðB,²-coun
000abbb0  74 31 33 2e 64 61 74 ff 19 85 e0 02 00 00 10 44  t13.datÿ.à....D
000bfc80  00 00 00 01 00 00 00 0c 00 00 00 0d 0b 08 63 6f  ..............co
000bfc90  75 6e 74 31 32 2e 64 61 74 e0 02 00 00 00 0d 00  unt12.datà......
000bfe80  00 00 0e 0b 08 63 6f 75 6e 74 31 33 2e 64 61 74  .....count13.dat
000c7f10  63 6f 75 6e 74 30 39 2e 64 61 74 ff 19 85 e0 02  count09.datÿ.à.
000e0cc0  0b 08 00 00 61 f7 3b 03 c4 12 57 53 63 6f 75 6e  ....a÷;.Ä.WScoun
000e0cd0  74 31 30 2e 64 61 74 ff 19 85 e0 02 00 00 10 44  t10.datÿ.à....D
000f9a80  ff 40 62 1d f9 72 7e e3 63 6f 75 6e 74 31 31 2e  ÿ@b.ùr~ãcount11.
000f9a90  64 61 74 ff 19 85 e0 02 00 00 10 44 ee 2d 30 6f  datÿ.à....Dî-0o
000ffb90  63 6f 75 6e 74 30 39 2e 64 61 74 e0 02 00 00 00  count09.datà....
000ffd80  0a 00 00 00 0b 0b 08 63 6f 75 6e 74 31 30 2e 64  .......count10.d
000ffd90  61 74 e0 02 00 00 00 0b 00 00 00 02 00 02 0c d8  atà............Ø
000fff70  00 00 00 01 00 00 00 0b 00 00 00 0c 0b 08 63 6f  ..............co
000fff80  75 6e 74 31 31 2e 64 61 74 e0 02 00 00 00 0c 00  unt11.datà......
00115e20  bd 6e 58 e6 63 6f 75 6e 74 30 37 2e 64 61 74 ff  ½nXæcount07.datÿ
0012ebe0  63 6f 75 6e 74 30 38 2e 64 61 74 ff 19 85 e0 02  count08.datÿ.à.
0013fcc0  00 08 0b 08 63 6f 75 6e 74 30 37 2e 64 61 74 e0  ....count07.datà
0013feb0  01 00 00 00 08 00 00 00 09 0b 08 63 6f 75 6e 74  ...........count
0013fec0  30 38 2e 64 61 74 e0 02 00 00 00 09 00 00 00 02  08.datà.........
0014af40  fa ce 22 36 63 6f 75 6e 74 30 34 2e 64 61 74 ff  úÎ"6count04.datÿ
00163d00  63 6f 75 6e 74 30 35 2e 64 61 74 ff 19 85 e0 02  count05.datÿ.à.
0017cab0  0b 08 00 00 b7 fd 21 e2 80 0e 71 56 63 6f 75 6e  ....·ý!â.qVcoun
0017cac0  74 30 36 2e 64 61 74 ff 19 85 e0 02 00 00 10 44  t06.datÿ.à....D
0017fbc0  00 00 00 05 0b 08 63 6f 75 6e 74 30 34 2e 64 61  ......count04.da
0017fbd0  74 e0 02 00 00 00 05 00 00 00 02 00 00 af 50 00  tà...........¯P.
0017fdb0  00 00 01 00 00 00 05 00 00 00 06 0b 08 63 6f 75  .............cou
0017fdc0  6e 74 30 35 2e 64 61 74 e0 02 00 00 00 06 00 00  nt05.datà.......
0017ffb0  00 07 0b 08 63 6f 75 6e 74 30 36 2e 64 61 74 e0  ....count06.datà
00180070  16 b6 2c e3 32 2e ad 46 63 6f 75 6e 74 30 31 2e  .¶,ã2.­Fcount01.
00180080  64 61 74 ff 19 85 e0 02 00 00 10 44 ee 2d 30 6f  datÿ.à....Dî-0o
00198e30  75 8e d7 96 63 6f 75 6e 74 30 32 2e 64 61 74 ff  u×count02.datÿ
001b1bf0  63 6f 75 6e 74 30 33 2e 64 61 74 ff 19 85 e0 02  count03.datÿ.à.
001bfb00  0b 08 63 6f 75 6e 74 30 31 2e 64 61 74 e0 02 00  ..count01.datà..
001bfcf0  00 00 02 00 00 00 03 0b 08 63 6f 75 6e 74 30 32  .........count02
001bfd00  2e 64 61 74 e0 02 00 00 00 03 00 00 00 02 00 01  .datà...........
001bfef0  63 6f 75 6e 74 30 33 2e 64 61 74 e0 02 00 00 00  count03.datà....

Thank you Lua, thou truly are a light in the darkness.

KDE ON VMWARE appears to be a combination of instability.

At work I’ve been running Kde on two VMware Workstation installations, one Suse 10.0 and a Debian unstable. The experience is the same for both installs where the VMware session crashes at least on time a day, but more often as much as three times a day. At work we are four colleagues that are working in a VMware environment and we are all have problems with VMware sessions suddenly crashing. No particular pattern of work seems to provoke the crashes, but experiments show that it is only the Kde + VMware constellation that causes problems. A colleague found that replacing Kde with another window manager makes all the instability issues go away. Hence we have all abandoned Kde for other window managers.

I’m a long time Kde fan and on my personal Debian unstable install, Kde has run for years and it never crashes. Could be interesting to know what Kde is doing that makes VMware spill its guts.

For replacement window manager a couple of colleagues installed Enlightenment, another installed IceWM and I installed Xfce4.4. Xfce4 actually really impresses me. Not only does it look spectacular, but also it’s so much more responsive compared to Kde. Of course I cannot work without my trusted Kde applications and tools, but luckely Xfce4 provides optional Kde and Gnome integrations. The really big bonus of Xfce4 is the awesome keyboard nagivation abilities. Xfce4 provides global shortcuts for easy window resizing, moving, maximizing, minimizing etc. Nice :-)