I am a Ubuntu Linux user. On my laptop and at work, I was running "Breezy Badger" (Ubuntu Linux 5.10) since last fall.

But one of the worst things about it was its inability to connect to WPA-encrypted Wifi access points. Eventually, I wrote a few shell scripts that made me able to connect to my AP at home, but it was far from being handy.

Now yesterday, I installed the new release, Dapper Drake on my laptop. The installation was straightforward, and by the way I liked it a lot that the installation CD is a live CD at the same time so that new users can "try before they buy".

When everything was installed, I realized that my wifi card was recognized and activated automatically, yet I was not able to connect to a WPA encrypted network. Instead it tried to connect to one of my neighbors unencrypted access points. Downgrading my connection to the demonstrably weak WEP encryption was not an option earlier, nor was it now.

Already being a little disappointed, I searched the Ubuntu forums and after a while, I came up with a thread about WPA access points with Ubuntu Dapper Drake.

In short: Nine seven steps to WPA encrypted Wifi with Ubuntu Dapper Drake:

1. sudo apt-get install wpasupplicant (might already be installed)
2. (You might have to do a sudo apt-get update in order to fetch the newest metadata for apt-get)
3. sudo apt-get install network-manager-gnome
4. sudo gedit /etc/network/interfaces -- Comment out everything but "lo" entries in that file
5. Create a file called /etc/default/wpasupplicant, add entry ENABLED=0
6. Reboot your system
7. Left-click the network manager icon in Gnome and select your wireless network
8. Follow the prompts for password, type, etc.
9. It will ask you to choose a password for your new "keyring".
10. Be happy ;)

Now everytime you boot up and log in, the network manager will connect you to your preferred WPA-encrypted network as desired.

There are only two caveats that I currently know of:

• The connection is only made once you log into Gnome. So if you plan to run this connection on a server or if you need a network connection before you get to the login prompt (i.e. during bootup), this method is not ideal for you.
• A current bug is that you are asked for your keyring password twice (?) everytime you log in. This can be annoying, but rumor has it, it is already fixed and an update will be released soon.

As you see, Dapper Drake made a big step towards the usability of Linux on laptops. Hope you give it a shot. It seems to be worth it.

Update: Removed two unnecessary steps. Thanks, Martin and Zakaria!

Read more…

Filled with deep sadness I have to realize that I can't watch the games of the soccer world cup 2006 in Germany live on TV.

Why? They are on, aren't they?

Ah, well, yes. But they are on around noonish, and at work, we don't have cable, so I am stuck with taping them and watching them later. Which is not even remotely as spicey as watching a game live.

However, I can probably be sure that I won't meet anyone all day who cares about the world cup, so at least nobody will spoil it for me ;) Back home in Germany, it wouldn't take any more than like 10 minutes until somebody cheered outside, telling you who won.

Especially when it was the German team who won.

By the way, if you are into betting on sports events but don't really want to spend money, try Stoccer. It is a market research project from my home university back in Germany and it works like a stock market for national team "stocks". They try to predict who'll win the world cup from analyzing what users "buy" what teams. Sounds like fun, I think I will join it!

Read more…

I found a Mac OS X hint yesterday mentioning how VideoLAN CLient (VLC) can save streaming videos into a file. Since today I wanted to record a radio show off the Internet, I gave it a shot for an audio stream too.

Here's what I got:

If you want to save a Quicktime (AAC/MP4) audio stream (maybe others, too? Leave a comment if you know!) to a file, start VLC from the command line (terminal window) like this:

/Applications/VLC.app/Contents/MacOS/VLC --rtsp-tcp rtsp://example.com/path/to/stream --sout '#standard{access=file,mux=mp4,url=/Users/Shared/VLCoutput.mp4}'

Now, if you want to schedule the whole thing, a cron job will do the job. The tool at would be certainly more correct (since you don't want to schedule it as a recurrent task), but the at daemon is disabled on OS X by default.

So, do a crontab -e and put in two lines like this (yes, put the whole VLC stuff into one line as mentioned above):

0 15 12 5 * /Applications/VLC.app/Contents/MacOS/VLC --rtsp-tcp rtsp://example.com/path/to/stream --sout '#standard{access=file,mux=mp4,url=/Users/Shared/VLCoutput.mp4}' 30 15 12 5 * killall -QUIT VLC

The first line starts VLC as mentioned above. 0 15 12 5 means: Start at 3 p.m. (= 0 15), on May 12 (= 12 5). The asterisks in each of the lines just mean that you don't care about the weekday. <!--more--> The second command, accordingly, stops recording at 3:30 p.m. by killing the VLC process. Two notes on that:

First, keep in mind to sind the QUIT signal rather than TERM (which would be the default), otherwise VLC won't correctly finish writing the file and probably render it unusable.

Second, killall is the mass murderer of the kill() commands. It will kill all running instances of VLC, not just the one recording your stream. So, don't wonder if the movie you happen to be watching stops playing at the scheduled time.

Save it and you are all set: Your stream will be recorded at the right time. You will find your stream in the Users/Shared/ folder, as specified in the VLC command line.

Eventually, when everything is done, you do a crontab -e again, and remove the two lines so that it won't start recording again, a year from now ;)

Have fun listening!

Read more…

Too bad my NSLU2 apparently does not have a battery inside...:

# ntpdate time.oregonstate.edu Looking for host time.oregonstate.edu and service ntp host found : time.oregonstate.edu 8 May 21:08:00 ntpdate[4084]: step time server 128.193.10.15 offset 1145070824.207699 sec

Read more…

To keep track of my numerous bookmarks on the Internet, I use the popular bookmarking service del.icio.us, along with a handy Firefox extension.

Well, when you accidentally hit the "tag" button on a newly opened tab in Firefox, this is what happens:

You are bookmarking the unbelievably useful website about:blank.

Due to the ginormous amount of information stored on that web page, I decided to keep the bookmark as a valuable resource for my daily Internet research (after all, it is the "home" page in my web browser and thus the first page I ever see when opening Firefox). ... And so did 2362 other people who were as stupidsmart as me to bookmark about:blank ;)

Update: ... and counting...: There are already 2374 people besides me, now :)

Read more…

Today I was connecting a second USB harddrive to my NSLU2.

What you get is a few interesting effects, among them device IDs (/dev/sda, sdb...) changing depending on the order in which you attach the drives. Plus, I added a USB hub, which makes the device names change anyway.

The solution for the crazily jumping dev nodes is the udev system, which is part of Linux for quite a while now, but I never really had a need to play with it yet. But the howto is pretty nice and easy to apply.

Still, a few notes:

• The SYSFS{whatever} rules support wildcards, so that you don't have to write the whole descriptor if you don't want to. For example, "Max*" instead of "Maxtor 6" works totally fine. -- That's especially useful since SYSFS{model} descriptors often seem to be filled up with a couple of spaces at the end.
• Some (all?) USB hard drives in fact don't consider themselves to be USB devices. So in this case defining BUS=="usb" will not result in any device links to be created at all. I had to define BUS=="scsi" instead. You should look at the udevinfo output as suggested in the "writing udev rules" howto, it will tell you exactly what setup is necessary for your device/drive configuration.

That's how my two new rules look like (each in one line only): BUS=="scsi", KERNEL=="sd", SYSFS{vendor}=="Maxtor", SYSFS{model}=="L250R0", NAME="%k", SYMLINK="usbhd/maxtor250%n" BUS=="scsi", KERNEL=="sd", SYSFS{vendor}=="Maxtor", SYSFS{model}=="Y080P0", NAME="%k", SYMLINK="usbhd/maxtor80%n"

If you have any questions, let me know.

If not, have fun :)

Read more…

The harddrive manufacturer Hitachi offers something new on its website:

Noises that indicate hard drive failure in WAV format.

Be warned, it's not for the faint of heart. Now that's what I call a nightmarish soundtrack - hopefully nobody sues them because of the emotional pain when hearing harddrives crash ;)

(via (German) zeitwissen blog)

Read more…

Developing software that has been in use for quite a while (like the Maintain network management software I am currently working on), you frequently run into tiny little problems that are somehow the heritage of ancient times. Sometimes, they are easy to use, in other cases they start as small issues and turn into butt-biting monsters ever so quickly.

One of these is MySQL's PASSWORD() hashing function. What was meant to be a good idea - having the RDBMS handle the passwords with its built-in hash - turned out to be a bad one: MySQL's password hash changes virtually with every release (okay I am exaggerating), making your hashes unusable, so your customers stay locked out of your software.

To provide some sort of legacy support, in former versions of Maintain the OLD_PASSWORD() alternative was used to authenticate, followed by a re-hashing of the password with the new PASSWORD() hash.

Still, it's only a matter of months until MySQL decides to change its hashes once again, leading to even more legacy code and less transparency in the authentication codebase. Plus, if people don't want to use MySQL at all, they have a big problem: Most other DB engines don't offer a PASSWORD() function.

Therefore the hash was changed to SHA1, leading to yet another special case in the password validation methods.

Anyway, in the upcoming Maintain 3, old passwords will only be supported through a legacy authentication module designed to re-hash the passwords to SHA1, hopefully one and for all times extinguishing issues with changing hashes in the database backend.

The moral: There is a reason for MySQL to discourage use of PASSWORD() in applications. Believe me. They are right.

Read more…

Currently, I have to work a lot with ant for class, and generally, I like it.

The XML format used to describe the build tasks is pretty straightforward, makes sense most of the time and is even pretty extensible, so that things like JUnit testing are as easy as the ABC. Well -- they should be.

When using ant with Eclipse, everything worked fine. But then, when I checked out the project on the command line and confidently ran an "ant test", I was presented with the following error message, which through its length alone has such a beauty that I should truly consider printing it out and put it on my wall to admire it daily.

BUILD FAILED /blah.../build.xml:51: Could not create task or type of type: junit. Ant could not find the task or a class this task relies upon. This is common and has a number of causes; the usual solutions are to read the manual pages then download and install needed JAR files, or fix the build file: - You have misspelt 'junit'. Fix: check your spelling. - The task needs an external JAR file to execute and this is not found at the right place in the classpath. Fix: check the documentation for dependencies. Fix: declare the task. - The task is an Ant optional task and the JAR file and/or libraries implementing the functionality were not found at the time you yourself built your installation of Ant from the Ant sources. Fix: Look in the ANT_HOME/lib for the 'ant-' JAR corresponding to the task and make sure it contains more than merely a META-INF/MANIFEST.MF. If all it contains is the manifest, then rebuild Ant with the needed libraries present in ${ant.home}/lib/optional/ , or alternatively, download a pre-built release version from apache.org - The build file was written for a later version of Ant Fix: upgrade to at least the latest release version of Ant - The task is not an Ant core or optional task and needs to be declared using <taskdef>. - You are attempting to use a task defined using <presetdef> or <macrodef> but have spelt wrong or not defined it at the point of use Remember that for JAR files to be visible to Ant tasks implemented in ANT_HOME/lib, the files must be in the same directory or on the classpath Please neither file bug reports on this problem, nor email the Ant mailing lists, until all of these causes have been explored, as this is not an Ant bug.

This is not an ant bug? Oh yes it is. "ant-junit.jar" is now shipped by default with ant and still, ant claims not to know about that task?

And anyway - why couldn't the developer who took the time to write such a cryptic error message use his effort instead to fix the bug?!

Unbelievable enough - however, since others did a much better job on ranting about ant's worst error message ever, I'm going to stop now and provide a solution for that problem instead (since ant developers obviously didn't feel alike):

Go to $ANT_HOME/lib and make a symbolic link to your JUnit's junit.jar file. The directories differ for most operating systems, but the system is the same: Ant apparently does not find JUnit in its classpath, resulting in the error message above. When JUnit is linked to Ant's library dir however, it can find JUnit and will call the unit tests as expected.

(Now it took me like 4 lines to describe a fix for the problem. Why such an easy fix is not part of the ant error message will probably remain a secret forever.)

I hope I helped some of you guys who have the same problem. Keep having fun programming!

Read more…

One thing reminding us constantly that OSX is almost as crappy as Redmond OS is the Spinning Beachball of Death.

Since I revently gave my Mac Mini a decent amount of RAM to waste for useless eyecandy, I don't meet the little spinning fellow as often anymore.

However, the installation of the Eclipse IDE the last week brought a nice, new beachball appearance: When I use spotlight to start the program (as I usually do, because it's so much faster than clicking through the menu structure), it will kill the system tray in the upper right corner of the screen.

The time stops counting and when I move the cursor over it, I see the cursor turn into the beloved beachball again! :)

I did not find any information about it on the net besides an old forum post in the google cache... But the solution seems to be, not to start Eclipse with spotlight but to actually click on it in the Applications folder or the dock.

Works for me, now.

Is that crazy or what?

Read more…