Takis blog

Creating DLLs using Visual C++ 8 on GNU/Linux with Wine

2008-04-28T01:05:00.018+02:00

Now and then people I work with ask me for a compiled library of some project for the Windows platform. As I dislike working on Windows, I use a MinGW crosscompiler on my GNU/Linux system to compile the code and thus am able to give them what they want.

Unfortunately, AFAIK the MinGW compiler can't generate debugging symbols compatible with Microsoft's compiler, meaning that although they can use the libraries I provide, they can't step through the code using Microsoft's debugger. Which is really annoying.

So, once in a while I figured it might be interesting to get the Visual C++ compiler working from within my GNU/Linux system. This way I would be able to compile everything with the Microsoft compiler and generate compatible debugging info. And as Microsoft has made the compiler free (as in beer not freedom), it's becoming more and more interesting.

I've tried this several times and in the end created a little script to make it easier to run the VC++ compiler. Afterwards I reported it to the Wine AppDB and although it seemed to work fine, I never really started using it, except for some experimentation.

Today, I was trying to figure out how to add support for the Intel C++ compiler to Eclipse/CDT, when I noticed that CDT plugins were already available in the Intel C++ compiler package... So, as I really wanted to play a bit with CDT, I figured I might as well have a look at how to integrate Microsoft's compiler in Eclipse/CDT.

The easiest way to have something workable is using the Eclipse/CDT GNU Make builder. And that's why I started creating a simple makefile which allows me to build Windows executables and libraries using GNU Make on my Ubuntu system. Eclipse/CDT already includes a VC++ output parser, so that part looks rather nicely integrated. The errors and warnings VC++ outputs, get parsed and added to a list of errors on which you can click, which will take you to the corresponding faulty line of code.

So, as I said, I had another go and created a little Makefile to make it a bit easier to create DLL's from GNU/Linux.

Basically, the only thing you need to do before this Makefile works, is install Microsoft Visual C++ Express on your Windows partition, and afterwards copy the followings directories into your Wine directory $HOME/.wine/drive_c/Program Files:

c:/Program Files/Microsoft Visual Studio 8/VC/include

c:/Program Files/Microsoft Visual Studio 8/VC/lib

c:/Program Files/Microsoft Visual Studio 8/VC/bin

c:/Program Files/Microsoft Platform SDK for Windows Server 2003 R2/Include

c:/Program Files/Microsoft Platform SDK for Windows Server 2003 R2/Lib

You can do this as follows:


mkdir -p $HOME/.wine/drive_c/Program\ Files/Microsoft\ Visual\ Studio\ 8/VC
mkdir -p $HOME/.wine/drive_c/Program\ Files/Microsoft\ Platform\ SDK\ for\ Windows\ Server\ 2003\ R2/

cp -r /mnt/windows/Program\ Files/Microsoft\ Visual\ Studio\ 8/VC/{include,bin,lib} $HOME/.wine/drive_c/Program\ Files/Microsoft\ Visual\ Studio\ 8/VC
cp -r /mnt/windows/Program\ Files/Microsoft\ Platform\ SDK\ for\ Windows\ Server\ 2003\ R2/{Include,Lib} $HOME/.wine/drive_c/Program\ Files/Microsoft\ Platform\ SDK\ for\ Windows\ Server\ 2003\ R2/

The makefile:


MSVC=c:/Program\ Files/Microsoft\ Visual\ Studio\ 8/VC/
MSSDK=c:/Program\ Files/Microsoft\ Platform\ SDK\ for\ Windows\ Server\ 2003\ R2/
INCLUDE=/I${MSVC}include /I${MSSDK}Include
LDFLAGS=/LIBPATH:${MSVC}lib /LIBPATH:${MSSDK}Lib
WINE=/opt/wine-dev/bin/wine
CXX=${WINE} ${MSVC}/bin/cl.exe

EXECUTABLE=main.exe

all: ${EXECUTABLE}

%.obj : %.cpp
 $(CXX) /c $(INCLUDE) $<

%.lib : %.obj
 ${CXX} $^ /link /DLL /out:${@:.lib=.dll} ${LDFLAGS}

%.exe : %.obj
 ${CXX} $^ /link ${LDFLAGS}

mylib.lib: mylib.obj

${EXECUTABLE}: main.obj mylib.lib

clean:
 -rm *.obj *.exe *.dll *.lib *.exp  

run:
 @${WINE} ${EXECUTABLE}

And, finally, there's a screenshot showing Eclipse 3.3.2 with CDT 4.0.3 and Visual C++ 8.0's compiler (version 14.0).

Updated: 2008/04/28 T 09:53.

Intro to GDB remote debugging

2008-01-16T18:14:00.001+01:00

A tiny introduction to remote debugging using GDB:

http://blip.tv/file/602952

Alexander Issaris

2007-12-14T17:47:00.000+01:00

This August I became a daddy for the first time. Here are some pics of our little boy...

Debugging the Linux kernel using Eclipse/CDT and Qemu

2007-12-14T15:23:00.005+01:00

A screencast demonstrating roughly the same thing is available at: http://blip.tv/file/586651
For iTunes users there's a videopodcast at: http://takis.blip.tv/rss/itunes/

Download the Linux kernel sourcecode from http://www.kernel.org/. For example, the current kernel version is 2.6.23, a direct link would be http://kernel.org/pub/linux/kernel/v2.6/linux-2.6.23.9.tar.bz2

Extract the Linux kernel sourcecode:


cd /usr/local/src
tar xvjf linux-2.6.23.9.tar.bz2

We will build the Linux kernel in a different directory:

mkdir -p /mnt/build/linux-2.6

Then copy the provided kernel configuration into this directory giving it a new name ".config". The following commands will then use this as a base-configuration to start from.

Next, we'll configure the kernel. Just keep pressing enter to use the default answers to all the questions that the kernel configuration program will ask you.


cd /usr/local/src/linux-2.6.23
make oldconfig O=/mnt/build/linux-2.6

Next, make the kernel a bit easier to debug:


make menuconfig O=/mnt/build/linux-2.6

And enable the following options: In the "Kernel hacking" menu enable both "Compile the kernel with debug info" and "Compile the kernel with frame pointers".

Now, we'll fire up Eclipse with the CDT plugin. You can download Eclipse with the CDT plugin from http://www.eclipse.org/downloads/. You'll need to download "Eclipse IDE for C/C++ Developers".

Get rid of the intro screen.

You'll get an empty workspace as shown in the screenshot. First disable automatic building, by using the "Window->Preferences" menu, selecting "General->Workspace" and deselecting "Build automatically". Eclipse will perform a time consuming indexing operation which you can disable by using the "Window->Preferences" menu, selecting "C/C++->Indexer" and switching from "Fast C/C++ Indexer" to "No Indexer".

Start a new project, by using File->New->Project...

Then select "C Project", "Makefile project", "Empty Project".

Now enter a project name and specify a specific directory for the project sourcecode. To do this, first uncheck the "Use default location" checkbox.

Finally click "Finish".

If you hadn't disabled indexing, Eclipse will now start indexing the Linux kernel sourcecode. This will take a long time.

You'll see a progressbar which might give you an indication on how long it might take to complete.

Eclipse finished indexing the kernel sourcecode. Now, we're ready to configure our debugger. Right-click on the project-name in the left pane (Project explorer) and select "Properties".

We want to modify the default build command and the location where the build files should go.

Uncheck "Use default build command" and enter make CC=gcc-3.4 O=/mnt/build/linux-2.6

Modify the build location by clicking the "File system..." button and browsing to /mnt/build/linux-2.6

Through the menu-bar select "Project->Build all" or press "Ctrl-b".

After some time the Linux kernel build will be completed and you see "bzImage is ready" appear in the Eclipse Console output.

Next, we'll run our kernel binary using the Qemu system emulator. The nice thing about Qemu is that besides the normal virtual HD, floppy and ISO image booting, it can also boot Linux kernels directly. And, Qemu provides a GDB-stub to which we can connect from our Eclipse debugger. The "-s" switch activates this GDB-stub. The "-S" switch makes sure Qemu doesn't start running before we're ready (it freezes the CPU at startup).

Because the CPU is "frozen" at startup, the Qemu window won't show anything useful yet.

Through the menubar, select "Run->Debug Configurations...". Double-click "C/C++ Local Application". Modify the "C/C++ Application" textentry to point to the actual Linux kernel, being /mnt/build/linux-2.6/vmlinux

Click on the "Debugger" tab, and in the "Debugger" listbox select the "gdbserver Debugger". Next, modify the "Stop on startup at:" to "start_kernel". Below this, you'll notice a frame named "Debugger Options"; click the "Connection" tab in this frame and modify the "Type" to "TCP" and the "Port number" to 1234. Continue by clicking the "Debug" button.

Eclipse might compile and link a bit, but will finally launch the debugger and ask if you want to switch to the debugging perspective. Say yes.

The next screenshot shows the debugging perspective. Just like with normal applications, you'll see that the line it is about the execute is highlighted.

In the Qemu window, you'll notice some output already. This is the output which happened in functions preceding the start_kernel() function.

...

By using "Run->Step over" or pressing the "F6" key, you can execute the kernel code line by line and examine what's happening.

If you want to see the assembly instructions which are being executed, you can add a view which displays this by selecting "Windows->Show View->Disassembly".

There's a register view too, as can be seen in the next screenshot. Registers who's contents has been altered by the previous execution step are highlighted in yellow.

You can add breakpoints, inspect variables, inspect memory and much more, but as you keep running the kernel you'll run in trouble as we did not specify a true harddisk image for Qemu. So, you'll get the following output in the Qemu window, because the Linux kernel could not find a root filesystem on our fake harddisk image "/dev/zero".

That's it. Hopefully the above is useful (and fun) for anyone :)

Last updated on 20080108.

Why GIT?

2006-10-05T22:06:00.000+02:00

For those of you who do not know what GIT is: GIT is a version control system similar to systems like CVS, Subversion or Bitkeeper.

In short, my four reasons for using GIT are:

Because it is distributed, it allows people to work on projects without having an account
It is really fast
All revisions of every file _are_ always locally available for you to inspect
Easy branching

Distributed

The one thing I adore most about GIT, is that it is a distributed system. Not by itself ofcourse, but this gives you incredible freedom (from a software developers perspective). To explain what is so great about this, I'll illustrate how development used to go with CVS and Subversion and similar systems.

Lets assume you are not a member of the project you want to work on. Then you'd have to check out their code from their software repository, make some changes and then -as you want to get it back and integrated- make a patch and send it to the projects mailinglist.
This doesn't sound that bad. Until you actually start working this way. The problem is that you do not have any versioning system for your own changes. You are working on a read-only repository and have no way to check in small changes.

So, what do some developers do (as I did)? They set up a local repository and import the external projects code. They have write access to that local repository, so they can start make changes while having their changes versioned.

The problem with this approach is that you will most likely want to keep synchronized with the official project sourcecode. So now and then you'd have to try and create a patch and solve lots of conflicts.

So, you'd say, okay, lets synchronise more often, so that the patches keep nice and small, and the conflicts would be easy to fix. Ofcourse, but the problem is that there is no automated way to do this, so it would involve a lot of work.

GIT makes this trivial. With GIT you'd make a clone of the projects repository. Within this clone you can do as you please, as it is your local repository. Now and then (very often) you just pull in the changes from the main project repository and you solve the conflicts that might occur.

How difficult is it to set such an environment up?

git-clone http://your.favorite/project.git

That's it.

Now, you enter the newly created project directory and start hacking and committing your new changes with:

git-commit -a

After a while you want to resynchronize with the main project repository, so you do a:

git-pull

GIT will get all the new code from the main repository, and will try to automatically merge it. If it fails, it will mark the code with the familiar ">>>" markers, as in both CVS and Subversion. After solving the conflicts, you commit again.

Or, you can keep one branch in your own repository identical to the main repository, and create a separate branch for your own development:

git branch mywork

git checkout mywork

Do whatever stuff you want to do in this branch and commits as much as you want to. Afterward you can pull from the main (called master) branch to your branch:

git pull . master

So, this command means that you want GIT to pull in the changes from the master branch into your current branch (being the one you were hacking in).

Speed
Another great benefit of GIT is that it's fast, really fast. I once did a comparison of GIT versus CVS, Subversion, TLA and Bazaar (and possibly others, can't recall). I used the Linux kernel source tree as contents for my revision control systems, and imported the 2.6.0 kernel. Then proceeded committing the 2.6.1 diff, 2.6.2, etc. After going up until 2.6.something, I then made a normalsized patch, and did a commit, GIT was blazingly fast while the other were unworkably slow. Recently Jo Vermeulen did a similar test and published the results on his blog. His tests focus on Bzr being comparable to GIT performancewise.

Full history at your fingertips
The entire sourcecode of the FFmpeg project, with every revision of every file included, fits into 9MiB using GIT. This means that you can have the entire development history of the project on your local harddrive. As it can be stored easily on your harddrive, it is very fast to access, as no calls need to use network connections at all.

Easy branching
Another nice thing about GIT is the ease with which one can create branches. And, in contrary with f.e. SVN and CVS, you feel comfortable to create branches _all the time_. Why? Because
you can delete them whenever you want, and no traces will remain. So, after the following commands, the repository will be the same as before the commands:

git-branch profile
git-branch h264
git-branch -D h264
git-branch -D profile

So, I typically create branches for whatever patch I am about to create. In fact, I actually just start working on something, and if it starts out being something worth keeping, I create a branch and commit the just created codechanges in that newly created branch.

Diffs between branches are easy too:
git diff profile..h264

Pulling in changes from a different branch into the current one:
git pull . somebugfix

Using GIT
If you want to use GIT, you'll better enjoy using the commandline, as the most powerful features are available through the commandline. There are some GUI's available too, mostly for inspecting codechanges.

There's a GUI included, called gitk:

Such as QGit:

And, for the Curses lovers, tig:

Update: As Uoti Urpala commented on the FFmpeg mailinglist, and as I should have mentioned above, the distributed nature of GIT isn't unique. There are a lot of other distributed revision control systems: Mercurial, Bazaar, Bitkeeper, SVK, TLA/Arch, darcs, ... In fact, I tested a few of those a long time ago, and noticed that performance was suboptimal for some (TLA/Arch and at the time Bazaar - but as I said that was a long time ago) and some seemed a bit immature, others were closed-source and commercial software. So, for me the choice was rather obvious. Recently, I have been told Bazaar has made excellent progress performancewise, so that might be an interesting candidate too. I never really tried Mercurial, although I did have the impression that it might have all the advantages GIT has...

Update2: Jo Vermeulen pointed me to this mail on the Cairo mailinglist where similar advantages concerning GIT are being illustrated.

DosBox on Nokia 770

2006-04-07T14:37:00.000+02:00

As I am experimenting with videoplayback on the Nokia 770, I had a look at both GTK+ and SDL for this purpose. After a quick hello-world style SDL application, I decided to get something cute running on the device.

I had a quick look at the Maemo Application Wishlist, and saw DosBox. This looked interesting to me, so I had a quick go at getting it up and running on the device. It compiled just fine in Scratchbox.

Several issues showed up. The first being related to SDL screen initialisation: you should always init SDL in 800x480 16 bits per pixel mode, fullscreen, with hardware accelerated SDL surfaces. Second issue was exactly the same as with Google LibJingle: it quickly ran out of memory and got killed by the kernel. Skimming through the sourcecode, followed by a quick hack fixed the first issue, while a swapfile fixed the second (16M swap appears to be enough).

Then as it seemed to work perfectly, I noticed that the virtual keyboard on the N770 was not accessible from within SDL, so I couldn't really do anything in my cute little DosBox :o) Anyways, likely it is possible to let DosBox start an app right from the commandline of an xterminal, and if the DOS application only requires a mouse, it could still be useful :)

Furthermore, DosBox seems to use the Alsa sequencer for MIDI support, that doesn't seem to work either, as there appears to be no sequencer. I haven't looked into this.

The binary is available here. The patch , horrible as it is -remember, it was a quick 2 min hack with grep and sed- is available here: Dosbox ugly N770 patch. It is truly a stupid patch, but as I'm distributing the binary, the GPL requires the availability of the code.

Books

2006-03-31T13:25:00.000+02:00

Fiction
Angels and Demons - Dan Brown ***
Digital Fortress - Dan Brown **
The Da Vinci Code - Dan Brown ***
Deception Point - Dan Brown *
Big Fish - Daniel Wallace **
The Last Juror - John Grisham

History
Little Big Man - Thomas Berger **
Baudolino - Umberto Eco ***

Horror
At the Mountains of Madness - H.P. Lovecraft *
The Call of Cthulhu - H.P. Lovecraft *
The Lurking Fear - H.P. Lovecraft ***
The Outsider - H.P. Lovecraft ***
The Statement of Randolph Carter - H.P. Lovecraft
The Thing on the Doorstep - H.P. Lovecraft ***

Science fiction
Day of the Triffids - John Wyndham ***
Crime and Punishment - Fyodor Dostoyevsky ****

Non-fiction

History
The life of Greece - Will and Ariel Durant ****
Caesar and Christ - Will and Ariel Durant ****
The Age of Reason Begins - Will and Ariel Durant ***
The Age of Voltaire - Will and Ariel Durant ***
Rousseau and Revolution - Will and Ariel Durant ***

Other
Stupid White Men - Micheal Moore **
Dude, Where's My Country? - Michael Moore **
Adventures In A TV Nation - Michael Moore *

FOSDEM 2006

2006-02-26T15:26:00.000+01:00

I went to the Free and Open Source Developers European Meeting (FOSDEM) in Brussels this weekend. I attended some quite interesting presentations about Plan9, DTrace and Xen.

Some of these presentation were recorded, and the videos are available for free.

That's me on the picture :) It was taken by a former classmate of mine, Dag, with his Nokia mobile phone.

Printing huge posters

2006-02-19T23:16:00.000+01:00

I recently needed a huge poster of one of my own pictures. Luckily, on a GNU/Linux system, all the software you need for doing so, is already available and just works.

Here's the commands needed to convert a picture called "mypicture.jpg" to a big poster in a Postscript file called myposter.ps:


convert mypicture.jpg mypicture.ps
poster -mA4 -p4x4A4 mypicture.ps >myposter.ps

The parameter -mA4 selects the paper size you want to print the poster with. The parameter -p4x4A4 sets the poster size as being 16 A4 pages.

You can print using whatever printing application you like, be it lpr on the commandline or a graphical application such as Evince on GNOME systems (such as the Ubuntu Breezy system I am using).

Migrated my repositories

2006-02-06T17:23:00.000+01:00

I've recently migrated my repositories to a new hosting provider. The Breezy repository is available at http://issaris.be/breezy and my new Maemo repository
with packages for the Nokia 770 is available at http://issaris.be/maemo.

Nokia 770 OSGi

2006-01-30T14:24:00.000+01:00

Nokia770 running OSGi

These screenshots show a Nokia 770 with the Oscar OSGi implementation running on top of the JamVM Java virtual machine and GNU Classpath classlibraries.

Transcoding video for the K750i

2006-01-23T01:04:00.000+01:00

This works fine for me:
ffmpeg -i sourcevideo.avi -s qcif -b 256 -acodec aac -ab 128 -ac 2 targetvideo.mp4

ffmpeg -i sourcevideo.avi -s qcif -vcodec mpeg4 -acodec aac -r 20 -b 192 -ab 96 -ac 2 -ar 44100 targetvideo.mp4

Ubuntu Breezy bug

2006-01-19T11:07:00.000+01:00

When unmounting an external USB drive by clicking on the drive's icon and choosing "unmount volume",
the following error-message appears:

And, the strange thing is, the drive is apparantly unmounted, as there is no trace of it in either, mount or df's output.

Nokia 770

2006-01-18T19:05:00.000+01:00

I have been playing with the ultra-cool Nokia 770! :)

Here's a pic of my RTAI LiveCD website rendered with the browser on the device (Opera).

Puppy for mom

2006-01-18T18:34:00.000+01:00

We bought a cute little Cavalier King Charles Spaniel puppy for my mom:

Repository moved

2006-01-16T18:53:00.000+01:00

Due to unstability of the server that previously hosted my repository, I've moved my Ubuntu Breezy repository. The new line to add to your /etc/apt/sources.list would be:
deb http://alpha.uhasselt.be/takis.issaris/breezy/ ./

E17 screenshots

2006-01-13T19:39:00.000+01:00

Some screenshots of current Enlightenment 0.17's CVS code.

E17 starting...

Various apps available in the E17 CVS repository:

Entice, a image viewer using the E17 libs:

GIT CVS import Ubuntu Breezy package

2006-01-13T15:33:00.000+01:00

Added a cvsps 2.1 package to the repository as Ubuntu Breezy still ships with 2.0rc1. Version 2.1 is needed for GIT's CVS import functionality.

UM Linux HOWTO

2006-01-11T16:04:00.000+01:00

This is a short howto, explaining how to setup User Mode Linux for simple Linux kernel module development and experimentation. I'm using the current Linux kernel 2.6.15 version (actually, todays GIT tree :) )

I like to keep my filesystem structure nice and clean, which is why I tend to use multiple partitions and directories for separate things. I've got a /usr/local/src directory which contains the linux-2.6 subdirectory contains the Linux kernel sourcecode. All my builddirectories are stored in /mnt/build, and so the first thing to do is to create a new entry for the Linux 2.6 UML build:
mkdir /mnt/build/linux-2.6-um

Next, enter the Linux kernel sourcecode directory:
cd /usr/local/src/linux-2.6

We'll start from the default UML configuration file for the kernel:
cp arch/um/defconfig /mnt/build/linux-2.6-um/.config

Use the defaults from that default config file:
make oldconfig ARCH=um O=/mnt/build/linux-2.6-um/

In case there's anything you want to change in the configuration of the UML kernel, start
the configuration menu:
make menuconfig ARCH=um O=/mnt/build/linux-2.6-um/

Now, we're set to do the actual building of the kernel. This will take a while...
make ARCH=um O=/mnt/build/linux-2.6-uml/

We need a disk image for the UML kernel to use. So, we'll create one. There's many ways to do this, this is a rather simple one.

First create an empty file which will kind of represent a disk drive (or actually a partition on a diskdrive):
dd if=/dev/zero of=/usr/tmp/sarge.ext2 bs=1M count=500

Put a filesystem on this partition, ext2 is fine for such a simple development system:
mkfs.ext2 /usr/tmp/sarge.ext2

Mount the filesystem image using loopback:
mount /usr/tmp/sarge.ext2 /mnt/loop/ -o loop

Copy an existing Linux distribution in this mounted filesystem image:
cp -var /usr/chroots/sarge/* /mnt/loop/

Move into the mounted filesystem and create the needed device nodes for UML:
cd /mnt/loop/dev
./MAKEDEV ubd

Next we'll install the kernel modules into the mounted filesystem:
cd /usr/local/src/linux-2.6
make modules_install O=/mnt/build/linux-2.6-uml ARCH=um INSTALL_MOD_PATH=/mnt/loop/

And finally, umount the filesystem image:
umount /mnt/loop/

Make a link named root_fs to your new partition image:
cd /usr/tmp
ln sarge.ext2 root_fs

Start the new UML kernel (and in this case, skip the default initscripts to get a real quick boot):
/mnt/build/linux-2.6-uml/linux init=/bin/bash

On the host system, create a directory for sharing files with the guest:
mkdir /tmp/forguest

In the guest system, mount this:
mount none /tmp -t hostfs -o /tmp/forguest

Now, any file appearing on the host system in /tmp/forguest, will also appear within the guest system in the /tmp directory.

Write whatever kernelmodule code (which doesn't actually access hardware since we're using UML)
you want in the /tmp/forguest directory.

Execute the following command once:
make -C /mnt/build/linux-2.6-uml/ modules ARCH=um

Build the module with the following command:
make -C /mnt/build/linux-2.6-uml/ SUBDIRS=$(pwd) modules ARCH=um

From the guest system, load the kernel module using:
insmod ./mymodule.ko

Remove it with:
rmmod mymodule

That's it! :)

Linux 2.6.15 released!

2006-01-03T17:01:00.000+01:00

Fifteen years after Linus Torvalds bought the machine which got Linux started, version 2.6.15 of his kernel has been released! :)

Added an Ubuntu Breezy image to my repository. Compiled for 686, with the default 686 ubuntu kernel configuration (thus most modules/drivers are available).

And, as I'm using an NVIDIA card here, I've added the NVIDIA kernel driver package too. It's not the current NVIDIA version, but the version included in Ubuntu Breezy (7667) recompiled for the above kernel.

Linux 2.6.15 Breezy kernel package
NVIDIA 7667 driver for the above 2.6.15 Breezy kernel

A quick glance at E17

2005-12-20T08:48:00.000+01:00

Those interested in having a look at E17 but not willing to actually start using it, can use the following command to see E17 in a nice little window:
Xnest -ac :1 | enlightenment -display :1

You need to have the xnest package installed or you can install the xserver-xephyr package and use:
Xephyr -ac :1 | enlightenment -display :1

Totally OT: Qemu 0.8.0 is available now! Lots of new features! :-)

MPlayer and accompanying browser plugin

2005-12-20T08:41:00.000+01:00

I've added MPlayer and Mplayerplug-in Debian packages to my Ubuntu Breezy repository. They are current snapshots of the CVS repositories. MPlayer can play nearly all audio and video files you can find, and the accompanying plugin makes those playable from within your browser.

apt-get install mplayerplugin

Libjingle and E17

2005-12-16T18:28:00.000+01:00

Google introduced a new project called Jingle earlier today. I just added Ubuntu Breezy packages of this new stuff to my repository.

Furthermore, I added E17 CVS packages. These should be built automatically using a cronjob.

All goodies available here:
deb http://lumumba.uhasselt.be/takis/breezy ./

More Debian packages

2005-12-07T16:09:00.000+01:00

I've added more packages to my Ubuntu Breezy repository. Besides snapshots of the standard GIT tools and Cogito, I've added qgit, JRTPLib, UIML.Net, Cassowary.Net, XMLRPC for C#, and the WxWidgets .Net bindings.

GIT world domination

2005-12-07T09:37:00.000+01:00

The Wine project has just started using GIT! This is the second large/huge project using Linus' Torvalds version control system.

What's incredibly neat is that they've put up the entire project history into the repository starting from 1993! Have a look over here at the webinterface.

The Wine people have put up a Wine GIT Wiki to get people started using GIT. For those interested in using GIT, Jeff Garzik's GIT HOWTO makes an interesting read.

In related GIT news: Artem Khodush wrote a webbased GIT browser.

GIT and Cogito snapshots

2005-12-05T10:50:00.000+01:00

I've made some GIT and Cogito snapshots available for Ubunty Breezy. The packages are created from a script invoked by cron, daily.

deb http://lumumba.uhasselt.be/takis/breezy ./

2005-11-09T23:55:00.000+01:00

The 28th of October me and my girlfriend went for a walk in the woods. There are lots of markings in the woods, of different colours representing different routes. The idea was to take a route which would be about 5km and we should complete it in an hour or so. So, we took the orange route, which was 5.5km. Three and a half hours later we finally got out of the forrest... :-) Some kids had apparantly moved some of the markings...

CVS to GIT and back

2005-11-08T14:46:00.000+01:00

The first step is to import a CVS tree into GIT:


mkdir foobar.git
cd foobar.git
git-cvsimport -p x -v -d :ext:takis@cvs.sourceforge.net:/cvsroot/someproject foobar

We will not make any modifications to the project in that directory, this directory is purely intended to be a GIT conversion of the CVS repository. Instead, we'll create a clone of that archive and do our hackery in there:


git clone -l foobar.git/ foobar-pi.git/

The "l" flag makes sure that git uses hard links instead of copying files, if possible.

Next, we'll make some modifications to the project and commit them using git-commit or cg-commit. As said earlier, we'll make those modifications in the foobar-pi.git directory:


cd foobar-pi.git
... do stuff ...
cg-commit

If new changes are committed in the CVS repository, we need to fetch those in our foobar.git repository, which is kind of a GIT mirror of the online CVS repository.


cd foobar.git
git-cvsimport -p x -v -d :ext:takis@cvs.sourceforge.net:/cvsroot/someproject foobar

Now, we'll pull in the CVS-commits to the clone directory.


cd foobar-pi.git
git pull

This results in a way to have a nice GIT repository of a project being hosted using CVS. Your GIT repository makes it easy to view changes in the project as you've got the full history locally on your system.

To prepare you modifications to be send as a patch, do the following:


git-format-patch origin..HEAD

This will give you a set of files, containing patches, which you can post to a mailinglist or maintainer.

If you've got write access to the CVS-repository, you probably want to commit these patches back into the CVS yourself. To do this, checkout the CVS repository somewhere on your filesystem:


export CVS_RSH=ssh
...

Get into the CVS working directory, and set the environment variable GIT_DIR to point to the .git directory within your git directory:


export GIT_DIR=/usr/local/src/foobar-pi.git/.git/

View the GIT-logs and select which commits you want to push into the CVS-repository:


git-log

Copy and paste the commit-identifier (being an SHA1-hash) and use it as a parameter to git-cvsexportcommit:


git-cvsexportcommit 4a20cbafdf25a141b31a8333284a332d1a4d6072
unset GIT_DIR

Do not forget to unset the GIT_DIR environment variable!

This will output:


$VAR1 = '4a20cbafdf25a141b31a8333284a332d1a4d6072';
...
Ready for you to commit, just run:

   cvs commit -F .msg Uiml/uiml.net.build

Repeat the command shown above:


cvs commit -F .msg Uiml/uiml.net.build

The patch which you wrote and committed in your clone GIT tree, is now committed back into the CVS repository.

Now, you can resync your GIT-CVS mirror tree:


cd foobar.git
git-cvsimport -p x -v -d :ext:takis@cvs.sourceforge.net:/cvsroot/someproject foobar

Now, your patches which you committed in the CVS repository, will be pulled back into the GIT-tree which acts as a mirror of the CVS-repository.

Now, you'll want to merge this back into your GIT-clone tree, which is where you do your actual work:


cd foobar-pi.git
git pull

Now, you've come full circle. You patches which were initially committed in foobar-pi.git, were committed to the CVS tree, and pulled back into the mirror GIT tree (foobar.git) and finally back into your clone/working GIT tree (foobar-pi.git). Ofcourse your patches were already in foobar-pi.git and GIT will notice this.

Oneway CVS to GIT

2005-11-08T14:31:00.000+01:00

The first step is to import a CVS tree into GIT:


mkdir foobar.git
cd foobar.git
git-cvsimport -p x -v -d :ext:takis@cvs.sourceforge.net:/cvsroot/someproject foobar


git clone -l foobar.git/ foobar-pi.git/


cd foobar-pi.git
... do stuff ...
cg-commit

If new changes are committed in the CVS repository, we need to fetch those in our foobar.git repository, which is kind of a GIT mirror of the online CVS repository.


cd foobar.git
git-cvsimport -p x -v -d :ext:takis@cvs.sourceforge.net:/cvsroot/someproject foobar

Now, we'll pull in the CVS-commits to the clone directory.


cd foobar-pi.git
git pull


git-format-patch origin..HEAD

This will give you a set of files, containing patches, which you can post to a mailinglist or maintainer.

Patch author tracking

2005-10-31T13:42:00.000+01:00

Some time after the SCO accusations that the Linux kernel would contain code owned by SCO, the Linux kernel people decided to setup a system for tracking the origin of patches. Unfortunately, this system isn't exactly faultproof. I've only submitted about 10 patches out of which three have been wrongly accredited. And because of GIT's use of hashes as identifiers, these mistakes do not get rectified.

Some time ago two patches of mine ended up in 2.6.11.5 stating someone else being the author. Now, I just noticed another patch of mine ended up somewhere in 2.6.x wrongly accrediting someone else.

The White Stripes in Brussels

2005-10-31T01:51:00.000+01:00

Saw The White Stripes in Brussels tonight! It was awesome! :)

Thales

2005-10-18T17:52:00.000+02:00

Thales
Originally uploaded by t4k1s.

Just got back from an interesting interview at Thales.

Google Maps

2005-10-14T17:12:00.000+02:00

My hometown on Google Maps

picorb IDL string

2005-10-13T13:59:00.000+02:00

picorb now supports the IDL string type.

picorb recursive structs

2005-10-13T02:55:00.000+02:00

Just finished adding recursive structs to picorb. For in, inout, out parameters and return types. For the moment I have only tested omniORB's interoperability with the new recursive structs code as I need to modify the testing code to do so. Next up will be the Java code, but that's for tomorrow.

What's next on my schedule are: adding support for sequences, user-defined exceptions, variable length types and arrays.

picorb floppy

2005-10-13T00:03:00.000+02:00

I've just created a bootable floppy of which 400K is used, which can be used to demonstrate picorb. GRUB by itself takes 152K on the FAT-formatted disk. eCos and the demo CORBA server implementation take 255K of which eCos takes about 240K. For now, I've taken a basic configuration of eCos, which I intend to strip down. The demo server implements a CORBA object supporting an interface containing 21 methods.

My ORB on PowerPC

2005-10-12T17:01:00.000+02:00

My tiny ORB is now also working on my MPC823E embedded board. I've named it "picorb".

CORBA for eCos

2005-10-11T13:51:00.000+02:00

I've just succeeded in getting my new tiny ORB running on eCos within the Qemu emulator! My testsuite of TAO, omniORB and J2SE ORB calls all succeed without a problem. Next up is testing on my PowerPC 823E embedded board to verify the correctness of the endianness related code.

eCos on Qemu

2005-10-11T01:28:00.000+02:00

Enabling some tracing output regarding DHCP, BOOTP and in general networking showed that no DHCP requests where being answered by the internal Qemu DHCP server. So, I disabled DHCP for now, and switched to a hardcoded network configuration. This seems to work, the network card gets nicely configured. My ORB runs and binds to the specified interface. But... through the slirp networking code, it doesn't seem to work. Switching to TUN/TAP hasn't given any positive results either.

eCos

2005-10-11T00:34:00.000+02:00

I've been playing with eCos lately. As I haven't got enough spare PCs -and because it allows me to work more efficiently- I'm using eCos on Qemu. The network card emulated by Qemu, is the widely support good old NE2000 (both ISA and PCI versions are emulated). Unfortunately, eCos doesn't support that network card, which in one way kinda surprised me, as it was a very widely supported card on desktop OSs. In fact, eCos just supports a few network cards on PC systems. Ofcourse, in another way, this isn't so surprising, x86 and it's related hardware aren't exactly the target of eCos.

Luckily, Antony T Curtis wrote a patch for Qemu to support another network card, the AMD PC-Net II. But, unfortunately, the latest release of eCos doesn't support that card either. Now, I've got three versions of eCos on my system: the latest release from the webpage, the Debian package and the latest CVS tree. After some playing around, I noticed that Qemu kept segfaulting when using the PC-Net card. Some googling turned up a few patches - which BTW have made it into the Xen repository (didn't know Xen was using Qemu) but haven't made it to the Qemu-patches page.

Now, the networkcard is nicely recognised by eCos, but the CVS branch of eCos has some other issues. Ofcourse, this is to be expected, it's the unstable CVS branch where developers push in their latest changes, but still it is kind of annoying. There hasn't been an eCos release in two years or so, so hopefully a new release will follow soon.

For the moment I'm stuck with some annoying issues: When booting Redboot, it just hangs for half a minute. The 2.0 release and also the Debian package with the same configuration on the same system, don't show this behavior. And after this, there's some problem with configuring the network card. I'm not sure whether the networkcard implementation in Qemu is to blame or the eCos driver. And I can't revert to the older eCos release to find out, as it doesn't support the card.
I'm pretty sure my code isn't to blame, as the official test mentioned in the eCos manual (ftp_test.c) doesn't work either. A mail to the eCos mailinglist could help.

Tiny CORBA implementation

2005-10-10T14:30:00.000+02:00

The 28th of September I started writing a new CORBA implementation. The major goal being minimal footprint while being GIOP compatible. The current footprint of a small Hello World style applications implementing one object containing 21 methods is 16024 bytes as an ELF Linux executable. The textsegment is 13008 bytes for the moment.

Currently, I have the base types working and structs, and I've tested interoperability with omniORB, TAO and Sun's Java ORB of the J2SE SDK. It works on both big-endian and little-endian systems.

I reused the omniORB IDL compiler frontend and implemented a new backend for my ORB, which reliefs me from the pain of writing skeletons manually, which I had to do the first days of the implementation.

I've started porting it to eCos but that isn't quiet working yet.

My diet

2005-09-01T23:56:00.000+02:00

My diet
Originally uploaded by t4k1s.

Im curious whether my current diet will indeed make me lose some weight ;-)

Filesystems

2005-04-12T19:58:00.000+02:00

I wanted to give GIT a go on the Linux kernel sourcetree, and decided to have a quick look at the performance of the various filesystems available for Linux today. I just tested the ones which were actually usable and drop-dead easy to setup: EXT2, EXT3, ReiserFS, SGI's XFS and IBM's JFS.

The only reason I'm posting this on my blog, is that I wanted to deleted the file I kept this info in and wanted to show it to a few friends who might find it interesting. So, I do not and is not a true benchmark. I just tested one thing, without isolating the to be tested process at all (I was running GNOME at the same time and various other apps). Again, it was just supposed to give me a quick and very rough idea about which filesystem would be fastest for doing lost of extracting of Linus kernel tarballs.

EXT2

pissaris@nyx:/extra/pissaris$ time tar xjf /home/shared/workshop/linux-2.6.7.tar.bz2
real 0m39.594s
user 0m35.705s
sys 0m2.498s

REISERFS

pissaris@nyx:/extra/pissaris$ time tar xjf /home/shared/workshop/linux-2.6.7.tar.bz2
real 0m48.444s
user 0m36.386s
sys 0m5.674s

XFS

pissaris@nyx:/extra/pissaris$ time tar xjf /home/shared/workshop/linux-2.6.7.tar.bz2
real 0m51.189s
user 0m36.353s
sys 0m3.387s

EXT3

pissaris@nyx:/extra/pissaris$ time tar xjf /home/shared/workshop/linux-2.6.7.tar.bz2
real 0m53.162s
user 0m36.205s
sys 0m2.965s

JFS
pissaris@nyx:/extra/pissaris$ time tar xjf /home/shared/workshop/linux-2.6.7.tar.bz2
real 1m20.934s
user 0m36.022s
sys 0m2.652s

DVD-Video authoring

2005-03-18T19:37:00.000+01:00

The fastest way I am aware of creating a DVD-Video from whatever moviefile you have lying around is using ffmpeg, dvdauthor and growisofs in the following way:


ffmpeg -i mymovie.avi -target pal-dvd - | dvdauthor -o dvd -
dvdauthor -o dvd -T
cd dvd
growisofs -dvd-compat -Z /dev/dvdrw -dvd-video .

Now, dvdauthor may complain about the aspect ratio, in which case you can explicitly set the aspect ratio using the "-aspect" parameter of ffmpeg.

Another one misunderstanding "NO WARRANTY"

2005-03-12T21:38:00.000+01:00

Here's another guy who doesn't seem to get it. Thom Holwerda posted on eXpert Zone:

OSS developers should learn to live with the fact that their software is no longer exclusively used by geeks and enthusiasts -- and if they cannot cope with this, then clearly state that your software is a hobby project

No, no, no. Most GNOME software -of which he's talking- uses the (L)GPL license. The GPL clearly states that there is *NO* warranty.

And furthermore, even if it was no hobby project and someone working in a company got the permission to release the developed software using the GPL license, then again, the users have no right to demand the implementation of the features they want. It's a gift. Accept it or ignore it.

OSNews' Eugenia on Gnome

2005-03-12T11:51:00.000+01:00

I was rather unpleasantly surprised by Eugenia's article on OSNews today.

"A feature will be implemented if and only if there is a developer who wants to implement it" (it was later mentioned in the discussion that this is if the developer actually has such a need himself for the feature).

Ofcourse! OSS is software by enthousiasts *for* enthousiasts. OSS developers are not a heap of programming slaves waiting to be commanded by demanding users.

I do not like or agree with the above statement, because I see software as simple tools. Only good tools can ultimately succeed. And I want Open Source to succeed.

The key to the success is more users contributing. Not complaining to developers to work harder for free.

For example, the No1 Gnome feature request, a menu editor that actually works properly, is still not realized after so many years.

So, what are you waiting for? During so many years, I'm pretty sure you could have implemented it yourself.

... users had to wait 6 months to get a checkbox on the preference panel ...

Oh please, it's a darn shame that none of them got to implement it themselves.

Open source devs generally only code whatever they personally need, and that's a huge difference from a commercial application where the "customer" is being asked repeatedly what features he/she needs in the application.

Sure. The customer pays, he gets his satisfaction, the programmer gets his by getting his wage. That's called a job. The other thing is called a hobby, which people do just for the fun of it. To please themselves. A hobby is not about pleasing others. It might please others, but that's not what makes it a hobby.

You may argue that in the second case you pay real money to get such support, but in my book, engineering is engineering. ... So, no matter if something is developed for OSS or for commercial reasons, the principle of engineering remains the same, because in both cases, the software is released out there to be consumed by [innocent] people.

NO. The software is written so satisfy the developers needs and as a free bonus he releases it. If someone might be able to use it, then it's a free gift. If they don't, well, then they are free to ignore it.

So in both cases, there is some responsibility on what the user would expect out of a given application and in the case of Gnome, there are a few millions of users that developers should take into account.

No, the OSS developer who is a hobbist programmer has _no_ responsibility.

Here's a nice quote from the GPL:


                           NO WARRANTY

  11. BECAUSE THE PROGRAM IS LICENSED FREE OF CHARGE, THERE IS NO WARRANTY
FOR THE PROGRAM, TO THE EXTENT PERMITTED BY APPLICABLE LAW.  EXCEPT WHEN
OTHERWISE STATED IN WRITING THE COPYRIGHT HOLDERS AND/OR OTHER PARTIES
PROVIDE THE PROGRAM "AS IS" WITHOUT WARRANTY OF ANY KIND, EITHER EXPRESSED
OR IMPLIED, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF
MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE.  THE ENTIRE RISK AS
TO THE QUALITY AND PERFORMANCE OF THE PROGRAM IS WITH YOU.  SHOULD THE
PROGRAM PROVE DEFECTIVE, YOU ASSUME THE COST OF ALL NECESSARY SERVICING,
REPAIR OR CORRECTION.

If these developers really don't want user feedback, they should close down their bugzilla, stop offering their software freely (only use it for their own needs), stop sending press releases out and stop asking for donations on their front page. It's as simple as that.

No, it's not as simple as that. There's users like the one quoted above, who nag and complain about OSS not being good enough, and there's users who are happy to be able to use and modify software for free. If you don't like OSS, you should stop visiting bugzilla, stop donating money and stop reading press releases. I happen to like all the aforementioned a lot.

If the "plain user" entity in the OSS world is such a taboo why the hell would I want to use OSS software?

You don't have to! Nobody is forcing you!

Just because the code is open?

Well, that's what defines OSS, doesn't it?

I don't personally have any real use for the source code (and most normal users don't either). I don't do C anymore (in the case of Gnome)

Well, if you don't like the software and are not prepared to enhance it, well, then that's pity. I suggest you go and find software that'll better fit your needs.

and I can't possibly pay $100-200 per hour to a consultant to add features for me.

If you can't spend $200 for getting a needed feature implemented, you certainly can't spend more on getting a WinPC full of software.

The point of OSS is that you _can_ add the feature yourself or ask someone to do it for you. If you can, good for you, if someone is kind enough to do it for you for free *be grateful*, otherwise pay someone.

Try getting your favorite feature into MS Visual Studio or any other closed source software package. Those companies will _truly_ ignore you. They might do market research to please to commonly asked features, but they certainly won't satisfy you specific needs.

All that "the source code is open, send me patches" it's all looney-baloney for the vast majority of users.

Please reread the "NO WARRANTY" section of the GPL.

You don't seem to get the nice thing about OSS, that is, if I write software to satisfy my needs, there might be other people who've got the same needs. And it will cost me little effort to just make it available. If they need different features, they can add them, and I can enjoy them as well.

However, I wouldn't mind at all paying about $30 per year to a big project like Gnome, but get assured that users aren't cut off from its development process (the current donation scheme does not take care of this).

They are *not* cut off. They are free to contribute. They are just not entitled to command any open source programmer and that seems rather reasonable to me.

They can only quickly describe what they need, and that's that.

Sure, I like to quickly describe what I need too, but apparantly the real world doesn't work like that. I like a Porche 911 for example. And, I don't like paying for it either, nor would I like building it myself. So, please you get me one. For free.

Normal users don't use bugzilla. Only power users & developers do. Besides, no one likes spending time to register.

Ah! So, you don't like devoting 5 minutes of your precious time to register at bugzilla, but you expect other people to devote many hourse of their *precious* time to implement your favorite software for free for you!

What I like to see, is some market research. Approach all kinds of users, put their gripes in line, make a note of their features they really need and evaluate them. Then, create a project plan and distribute the tasks that need to be done to your developers and make sure they deliver what they must deliver.

If you want to force people to work for free for you, that's called slavery.

People will say "that's not how OSS works", but as a user, I don't really care how OSS works.

Yes you do. You are imposing a working method on other people; telling them what to do. For free. For you.

I care about using software that's been properly developed taking users into account rather than purely developers' needs.

The features you need are not there, you are not intending to add them yourself. Okay. But you should not be annoyed that you can't force others to add them for you.

Be careful: I am not asking the OSS developers to implement every little thing that's asked out there, I am asking them to simply take users into account ...

Which does mean implementing every little thing that's asked out there.

I personally find it "deteriorating" for any user to use Open Source software made from such 'lone' developers and not by a company which specifically asks for feature requests or does market research. It would be like the user does not respect him/herself by using a tool that does not do all it could do or all things the user needs it to do

I think your statements show a lack of respect for the people out there who devote their free time to write software and then decide to give it away for free and release the full source code.

To me, software is a tool, nothing more. I am as practical as it goes when it comes to computers. I don't idolize them and I don't have a political ideology about software or hardware (and in fact, I personally take pity to anyone who does -- there's more important things in this world than to be political over bits and bytes).

But you do want a horde a programmers to work for free for you.

If something is open source, that's cool, it's a meta-feature that the closed source apps don't have, and I welcome it and I embrace it.

No you don't. You stated before that you don't care about the source code at all.

But when it comes to software written by hobbyists who don't want to implement anything apart from what they personally need, and systematically ignore their users

Again. They are hobbyists. They enjoy themselves writing software. Like you might enjoy taking a biketrip or whatever. They have every right to ignore their users. Just like you have the right to ignore my problems in my software while you are taking your biketrip.

(apart for their crashing bug reports, which is the only thing that they seem to need them for),

You should be grateful for that. They are trying to fix the problems *you* are having for free for you. Please try to send a bugreport to MS and see what response you'll get.

I refuse to use that software, because I respect myself and my choices.

Good for you. You surely seem to respect yourself. But you surely lack respect for the huge amount of work a huge amount of people made available for you for free.

While this might not be a huge problem for small time applications, it is a big problem when a project that's used by millions has the same attitude towards its users. It's disappointing, to say the least.

Yes. Your selfishness is disappointing.

Oh yes, I'm planning to build a house. I'll quickly describe how I want it, as I don't like to take time to explain clearly on how I want my house to be. But, once you've completed it, it should perfectly fit my needs, otherwise, I'll come to nag and complain about all the things you did wrong. And of course, I don't like paying for it. Oh, and as I'm not such a handy guy myself, I don't want to help out. So, you'll find me in Spain somewhere at the beach.

Update:
After reading Eugenia's article, I noticed this on her profile page:

... so if you have a problem with my spelling and grammar either:
a) do not come back (spare us and save your time too) b) send me a proofread version of the article in question.

This is truly hilarious. So, while she's saying that OSS developers should do everything to please the consumers of their software, she's saying to her readers -the consumers of her articles- that if they don't like her writings the should not read it or fix it themselves.

:-D

2.6.11-bk3

2005-03-08T09:01:00.000+01:00

A fix of mine for AMD8111e just made it into Linus Torvalds Bitkeeper tree as can be seen in the Linux 2.6.11-bk3 ChangeLog.

I've got to find a better way to keep track of which patches got into which trees. I have no idea for the moment which ones will need resending...

My dear pet

2005-03-07T20:51:00.000+01:00

poes
Originally uploaded by t4k1s.

Here's a picture of my dear pet. She didn't reach her first birthday.

Grave

2005-03-07T20:38:00.000+01:00

I've just finished burying my dear pet.

My pet

2005-03-07T09:28:00.000+01:00

During the night of Saterday on Sunday, while I was having a good time at dancecafe La Fete, my pet got hit by a car and died. It is my third pet dying in two years. This one was less then one year old <:-( It was on my way back home somewhere around 04:00 that I saw my pet lying just beside the street.

More patches!

2005-03-04T00:14:00.000+01:00

A few days ago I submitted four patches fixing bugs to the Linux kernel mailinglist. A few minutes (or was it hours?) later, the first two of them were confirmed to be needed and today Jeff Garzik pulled my patches in his BitKeeper kernel tree! Yay! :-)

And today the changelog of 2.6.11 appeared containing my previous patch. A pity they used my e-mail address instead of my name for reference... :-)

FOSDEM

2005-03-02T11:13:00.000+01:00

FOSDEM
Originally uploaded by t4k1s.

This weekend I attended FOSDEM with a few friends of mine. We ended up taking this group-picture with Linux kernel hacker Alan Cox!

Linux 2.6.11

2005-03-02T09:45:00.000+01:00

The 2.6.11 Linux kernel has just been released! 5662 files out of 15140 C files have been modified since 2.6.10... and my Prism54 fix was one of them! :-)

Here's the announcement.

Qemu accelerator kernel module

2005-02-22T14:25:00.000+01:00

Last week I tested the new -controversial- Qemu accelerator kernel module.

These are the results of the nbench2 benchmark:

Using the accelerator kernel module:
integer: 4.940
floating point: 9.813
memory: 5.994

Running the test on my machine without any emulator involved:
integer: 5.693
floating point: 11.083
memory: 7.137

Quiet impressive imho... of course -just as with VMware- as these "emulators" actually just execute the assembly code, they should approach native performance. It's a whole different story when IO-bound applications are benchmarked.

allyesconfig

2005-02-14T16:51:00.000+01:00

A nice 2.6.11-rc3-mm3 kernel configuration target in these cold winter days is 'allyesconfig'. As the name implies, it will answer yes to every kernelconfiguration question and therefore it will keep your CPU nice and hot.

For the less well-equipped people, there's the 'allnoconfig' which results in a nice and tidy 412K kernel image.

I've been playing with kexec lately and it seems to work really nice. Unfortunately, it hasn't been merged into Linus' kernel yet. I'm getting the necessary patches out of Andrew Morton's big kernel patch (2.6.10-mm3) and merging them with the ADEOS r9c3 patch for the 2.6.10 kernel. Having these patches combined would allow my LiveCD to switch various kernels without doing a full machine reboot.

Downset

2005-02-07T01:20:00.000+01:00

Today, I accidently noticed that Downset -a band I used to listen to 10 years ago- still existed and actually released CD's after their selftitled album. I was looking through Humo's (a local magazine) concertguide, and noticed that they were giving a concert in the cultural center called "Poorthuis" in a city called "Peer" , which is about a half hour drive from my place. So, I went to see 'em, and they played about an hour and a quarter. As I only know their first record, I noticed how hard it is to understand what their saying if you've never seen the lyrics to their songs before. Luckily, they did play a lot of old songs from their first record. More specifically, they played "Breed the killer", "Downset", "Ritual" and ended the show with "Anger".

TOOL lyrics

2005-02-02T16:48:00.000+01:00

As I keep relistening to old TOOL albums, and keep losing the links to the lyrics, I'll post 'em here, as a kind of bookmark :-)

http://toolshed.down.net/lyrics/

Elgoibar

2005-02-02T02:18:00.000+01:00

Last week the OCEAN project meeting took place in Elgoibar near San Sebastian and Bilbao. I took the opportunity to visit the Guggenheim museum and experience the local habits such as the delicious pintxos and the marvelous ciderhouse-style diner.

Pintxos are similar to Spanish tapas; they are small portions of food, composed of various components, such as fish, meat and vegetables. You eat them with a glass of wine while you're standing in a pub. After finishing your glass in about 10 minutes, you continue to the next pub, where the ritual reoccurs. The friday I arrived at San Sebastian, I had so many pintxos and accompanying glasses of wine, that I can't even recall how many and what I ate :-)

On monday evening, the evening after the first meeting, we went to a ciderhouse which was a apparantly a fairly typical place to have dinner at. The owner of the place would announce at regular intervals that he would open a new cidercase which was the signal for all people to go up and refill their glasses. The food was brought to the tables, where people could take a bit of the dish and eat it with bread. They served various types of fish, prepared in various ways and a truly huge steak.

Jon, one of my collegues explained me how to let the cider drop into the glass from about a meter from the tap but still the local girls insisted on correcting my technique :-)

The local people were all very friendly and there was a very warm and safe atmosphere all over.

This is definitely a place I'd like to visit again.

Kana

2005-01-10T23:24:00.000+01:00

Last Saturday I memorised the Hiragana characters. I'm able to recognise and read them all and their combinations. I started memorising the Katakana characters on Sunday, but since Sunday is family gathering day, I didn't have enough time to spend.

RTAI simplifications

2005-01-07T17:06:00.000+01:00

The RTAI developers are preparing to release a new version based on the magma branch. My first impressions are quiet good. They seem to have removed a lot of the unnecessary stuff, which makes the project appear somewhat less complicated.

The number of header and source files in the RTAI Kilauea tree determined with a simple find: 574. In the Vesuvio tree: 569. And finally in the new Magma tree: 325. Which shows that some serious cleanup has occurred.

DVD authoring

2004-12-18T13:18:00.000+01:00

Last week I was finally able to create a DVD-Video with ffmpeg which played on both my parents Sony DVD and my own Sony DVD player without any problems whatsoever. My previous tries ended with DVD which showed either horrible green artifacts or severe synchronisation problems. With last weeks CVS tree, it works fine.

So, the create a DVD-Video the output of ffmpeg can be fed directly to dvdauthor, no de-re-multiplexing of MPEG streams is necessary. And what's even better, on my Athlon XP 2000+ system, its encoding is faster then real-time; encoding to DVD-Video compliant MPEG-2 only took 75% of the running time of the video.

Java middleware performance

2004-09-21T11:13:00.000+02:00

Read an interesting paper on Java middleware performance which reaffirms my thoughts on this topic. Webservices are awfully slow, CORBA implementations vary wildly but all outperform the webservices. Fastest was the Orbacus ORB, second was RMI, slowest was SOAP, one but slowest was XML-RPC. The higher level abstractions such as CCM and EJB caused overhead. CCM on CORBA outperformered EJB on RMI. Seems that just as SOAP and XML-RPC, EJB implementations JBoss and JOnAS are awfully slow.

3D visualisation

2004-07-30T18:57:00.000+02:00

While discussing Blender animation on IRC, I was pointed to a Python 3D engine called Soya.

Poekie

2004-06-22T14:37:00.000+02:00

Just a few minutes ago my dad told me that my cat Poekie had been killed by a car. Here's a picture of Poekie.

some more pictures of Poekie

We had saved him twice before, but aparantly I couldn't save him this time :-(

We found him as a kitten and fed him and gave him a home. For years, everything went fine, until last summer when he got bitten by a rat. He almost died from the infection... We didn't notice that he had a wound, because his fur is so thick and he didn't complain much about it. Just the lack of appetite disturbed me.

Now, apparantly last night he crossed the street and got hit by a car.

Internet phone

2004-06-21T21:52:00.000+02:00

Today a colleague of mine pointed me to a Internet phone application called Skype. It gave it a try and it sounded remarkably pure and clear. They apparantly had just released their GNU/Linux version today.

Bochs

2004-06-17T14:47:00.000+02:00

Not all bugs are equal. Some are easily located by just looking at the code, some by watching the execution flow. Some bugs are really hard to locate and a debugger can help in tracing those.

When you're working on a project which involves modifying Linux kernel code, you'll have to be able to debug the Linux kernel. This is harder then debugging normal userspace applications. But luckily, the Linux community has provided some decent tools such as the various kernel debuggers and f.e. DProbes.

When you're programming RTAI, and you're bitten by an RTAI kernel bug, you're in big trouble. The Linux kernel debugging tools in general don't just work together with RTAI's ADEOS patch. So, there's no real tool to aid you. The best thing that might happen if something goes wrong is a kernel Oops, which you can try to trace and fix (See this Oops tracing howto).

Unfortunately, some bugs are really mean. They might cause a crash without an Oops or they might for example give you no backtrace at all.

One possibility for debugging such ugly beasts is a PC emulator such as Bochs. The Bochs PC-emulator has an integrated debugger. Unfortunately, Bochs is really slow. Some say, the emulation system runs about two hundred times slower then your real system.

Nevertheless, I tried to use it to debug RTAI/LXRT applications, but unfortunately, RTAI/LXRT applications don't run stable yet using Bochs.

CORBA porting adventures

2004-06-17T14:28:00.000+02:00

Because of issues with the TAO 1.3 OCI release, I started the port to 1.4.1 knowing that we would need that port anyway because of CIAO. The initial direct try from 1.3-OCI to 1.4.1-DOC was a failure,
too much had changed (9 versions) and apparantly I made a mistake somewhere...

The next try took a lot more work, because I ported to every successive version from 1.3-OCI to 1.4.1-DOC. So, from OCI's 1.3 release to the DOC group at Washinton University 1.3, to 1.3.1 DOC, and with every version in between to the final 1.3.x release of the DOC group 1.3.6-DOC. Then the porting continued to the major new DOC group release 1.4.0 and finally to 1.4.1-DOC.

Now, to be able to merge, I'll have to port it to the 1.4.2 CVSUP tree version. And ofcourse, test it extensively.

How to trace a kernel Oops

2004-06-17T14:20:00.000+02:00

Since a lot of the questions I answer keep returning to me, I thought I would be useful to set up a FAQ webpage. The first real entry explains how to trace a Linux kernel Oops.

Blending CORBA part 3

2004-05-05T19:00:00.000+02:00

This morning I had been testing the scalability of the Blender/CORBA Event Service connection thingy. Unfortunately, it didn't look good. I started to investigate the possible problems and changed the IDL to have lower overhead and better scalability.

Now, I have been playing around with about a dozen Blender objects moving around and rotating according to the coordinates specified by a CORBA server feeding events. So, it seems to work now. There still are some issues though.

I rendered this silly Blender-CORBA animation to a video.

Blending CORBA continued

2004-05-04T23:56:00.000+02:00

I finally managed to get a fluent Blender animation which received positional information using omniORB from a TAO CORBA server. It doesn't look impressive at all, since it just shows a simple cube moving around... but the possibilities are endless! :-)

If I make the code just a little bit more general, it should be possible to animate any Blender scene just by writing a CORBA Event Service supplier supplying various attributes for Blender objects.

Blending CORBA

2004-05-04T13:09:00.000+02:00

Last Sunday I experimented with using CORBA from within Blender's Python scripting environment. Yesterday, I extended these simple scripts to use the EventService to receive its updated data.

Unfortunately, there appear to be some problems with Blenders Python scripts. For example, even though a particular script ran successfully several times, then suddenly, Blender complained about syntax errors. There were no modifications between the runs and there was no syntax error :-(

TAO 1.3 problems on Linux 2.6

2004-04-29T19:58:00.000+02:00

So TAO 1.3 doesn't seem to work on Linux 2.6.

I'm being flooded with futex(0xbffff510, FUTEX_WAIT, 2, NULL) = -1 EAGAIN (Resource temporarily unavailable) messages from strace.

The problem seems to be resolved in TAO 1.4 but using 1.3 is easier since that's the version I'm also using on RTAI. To be able to run a CORBA application, I now have to keep compiling the IDL files with different versions of TAO, which is pretty annoying. So either I start testing the TAO 1.4 port I've been working on monday or I'll have to figure out what is causing the problems with Linux 2.6 and TAO 1.3. Using the old threading library doesn't seem to help. I should reboot using a 2.4 kernel to make sure I'm not hallucinating.

Threading issue

2004-04-29T19:53:00.000+02:00

The threading problems were caused by a change of the default stacksize. And yes, some basic functionality has not yet been implemented in NPTL.

NPTL issues

2004-03-05T17:07:00.000+01:00

Yesterday, when testing the new TAO/ACE release, I noticed several tests were
failing. I assumed the mistake was ACE's, and debugged it for hours.
Unfortunately, the bug wasn't in ACE, but in the new POSIX threading library for
GNU/Linux (NPTL). This was rather disappointing to me, since I had read nothing
but good about the new threading implementation. The problem occurred because on
thread creation, NPTL just ignores the thread attributes. So, selecting a
scheduler or priority on thread creation doesn't work at all.

Furthermore, I noticed, that the new threading library only allowed me to create
255 threads, while LinuxThreads allowed me to create 1532 concurrent threads.
This is even stranger, as I have read reports on using 100k concurrent threads
with this new threading implementation. Apparantly, somethings wrong here, but I
can't figure out what could be causing this.

And, when I was trying to report these issues to the NPTL developers, I couldn't
find their mailinglist. I could find people referring to it, but I couldn't find
the address :-) Now, for some reason it's called the phil-list... not quiet easy
to associate this with a new threading lib.

2004-01-12T01:33:00.000+01:00

gettimeofday_rt

I just ported the gettimeofday_rt I wrote for the previous release of RTAI to the newest RTAI 3.0. It works just fine for the ACE test! :-) Now, there are just some minor issues related to the prefered style of linking... Next up, is the porting of ACE's debug framework.

2004-01-11T22:11:00.000+01:00

One thing that's still missing from the RTAI Kilauea tree, is a decent gettimeofday function. I've added an implementation to the stable RTAI tree (Stromboli) earlier, so I'll just have to port that one to Kilauea. Without that patch, some ACE/TAO tests will definitely fail.

Other than that, the ACE debugging code has to be ported as soon as possible. Don't know if it's best to shove the data through a real-time FIFO or to just implement is using rt_printk.

2004-01-11T22:01:00.000+01:00

A few weeks ago, our TAO/ACE RTAI (Stromboli) port was starting to show some results. The CORBA benchmarking application I wrote about a year ago, worked on RTAI, both in soft and in hard realtime.

Last week, I started porting our TAO/ACE code to the new RTAI tree, called Kilauea. And about three hours ago, I ran all my (collocated) benchmarking code without any crashes! :-)

Furthermore, the official Collocation test included in TAO also works on RTAI 3.0 in hard realtime without any problems! Yay! :-)

I'm using the benchmarking results to create some charts which I'll post later on, to illustrate the achievable performance with TAO/RTAI.

2003-11-26T08:34:00.000+01:00

Last sunday I returned from St. Louis, MO where we worked on porting the TAO realtime CORBA ORB to RTAI. Pics are available here.

2003-10-13T23:43:00.000+02:00

Today I started with the implementation of an OMG specification called DAIS using Java. The DAIS spec is rather big, so it is by no means a complete implementation. By starting this, I was hoping to get a better idea of the problems that will be encountered when implementing DAIS.

When I started the implementation of the same CORBA object using C++, I noticed that the DAIS specification does not conform to the CORBA 3 IDL specification :-( The CORBA 3 keywords home and typeid are used as typenames in the DAIS specification.

One of those issues was already reported at the OMG website. I just filed a report for the other issue.

And in reporting that issue I noticed that my earlier biographer regarding the Lightweight Log Service, which I thought had been ignored, was being processed (Issue 5884)

2003-09-11T11:07:00.000+02:00

My first post!!!