I recently ran into this bug (or maybe just „weird, undocumented behavior“) of mc(1) when setting it up on FreeBSD. Even after saving the „Verbose operation“ option in the „Configuration“ menu, it was always disabled after the next startup of mc. I could confirm that verbose=true got set in the $HOME/.config/mc/ini file (probably $HOME/.mc/ini on Linux), but was ignored (or reset) on startup.

Now, „Verbose operation“ makes all those nice progress bar windows pop up, and without it there’s no point in using mc! So what’s going on here? Apparently, mc checks your terminal’s reaction speed in terms of „baud“, like it’s 1997 and we’re running stuff on serial cables or something. If mc finds that your terminal is too slow, you don’t get any progress bars (awww), because your terminal apparently can’t handle it.

Now, under some circumstances, some terminals don’t report a proper baud speed – maybe because it’s not 1997, and we’re not running stuff on serial cables. In these cases, the function tty_baudrate() returns -1, which I guess should alert programs that the value is useless. But Midnight Commanders just asserts that this value is smaller than 9600 (duh!) and always sets verbose=FALSE; on startup, because your serial cable is too thin. Gotcha!

The bug has been known and ignored for 6 years (mc Trac ticket #2452), but I can confirm that the patch proposed in comment #15 does the trick. I’ve submitted it to the maintainer of the mc port in FreeBSD, and maybe you want to go and bug mc people to fix it or get your distro to incorporate the patch – because who on earth would want to to use Midnight Commander without those progress bars, am I right?!

If you have LUKS partitions on gpt-partitioned drives, you might have noticed that cryptsetup doesn’t handle PARTUUID=[…] entries in /etc/crypttab, even though it does understand the traditional UUID=[…]. There’s an Ubuntu bug for this (since 2010, because that’s how much Ubuntu cares about bug reports), and apparently Arch is patching cryptsetup to make it work.

But it turns out there’s an elegant workround for everyone, as inspired by this Debian mailing list post, where a user has /dev/disk/by-id/[…] entries in their /etc/crypttab. /dev/disk is just the most delightful symlink squaredance! If you don’t know about it yet, just ls -lR /dev/disk and prepare to be amazed 🙂

So, to make cryptsetup correctly parse the gpt partuuid of your drives, just use /dev/disk/by-partuuid/[…] symlinks in /etc/crypttab. Here’s an example of such a setup:

root                     UUID=00000000-[…]-444444444444 none luks
backup0 /dev/disk/by-partuuid/55555555-[…]-999999999999 none luks
backup1 /dev/disk/by-partuuid/aaaaaaaa-[…]-eeeeeeeeeeee none luks

Have fun!

The „Baker“ explosion, part of Operation Crossroads, a nuclear weapon test by the United States military at Bikini Atoll, Micronesia, on July 25th 1946. Source: Wikimedia Commons.

This photograph is probably one of the best known and most impressive when it comes to illustrating the scale and impact of a nuclear test—even if the explosion was a small one even by the standards of the 1960s. It shows the fifth-ever explosion of a nuclear bomb, about two years after the first-ever nuclear explosion in the Trinity test and one year after the attacks on Hiroshima and Nagasaki.

Prinz Eugen (1946)

Nagato (1942)

Saratoga (1941)

Military ships were placed in the vicinity of the two explosions of the test series in order to observe the effects of a nuclear explosion at close range. Most of the ships were derelicts from the Second World War that had ended only a year earlier. Among the most notable ships were the Japanese battleship Nagato, the German cruiser Prinz Eugen and the US aircraft carrier Saratoga. After the two test explosions, all three and several more ships eventually sank and were abandoned for being too radioactive to salvage.

Prinz Eugen’s propeller at Laboe Naval Memorial. Picture: Darkone on Wikimedia Commons, CC-BY-SA 2.5

One part from one of those ships, salvaged over 30 years after the nuclear tests, has been on display in northern Germany, close to where I live, since 1979. It is one of the three propellers of the Prinz Eugen. After first reading about it, I came back to the topic every now and again, mostly for being incredulous that this was a part that had actually been in the vicinity of the Crossroads nuclear explosions.

Given that it really does seem to be genuine, and neither a reproduction nor a part replaced before 1946, I went to visit the Laboe Naval Memorial. It is a curious memorial with an ambiguous character that is well reflective of the site’s history, conceived some ten years after the First World War, inaugurated by the Nazis and later rededicated to peaceful seas and the victims of all seafaring countries. In my opinion, however, the Memorial doesn’t do too convincing a job of renouncing the glorification and romanticization of murderous naval warfare and truly exhibiting an international and intercultural spirit.

Click to download PDF from the NPS

After seeing the propeller, I wanted to pick out the Prinz Eugen in photographs of the Crossroads nuclear tests. There seemed to be, however, no annotated photographs detailing the identities of more than one or two ships in the vicinity of the explosion. After some research, I came across and online edition of The Archeology of the Atomic Bomb: A Submerged Cultural Resources Assessment of the Sunken Fleet of Operation Crossroads at Bikini and Kwajalein Atoll Lagoons, published and hosted by the US National Park Service. Chapter Two: Operation Crossroads features annotated maps of the test site’s layout for both tests, and gives the names of many of the ships involved (mirrored here from a PDF edition hosted by the National Park Service). The famous view from the island towards the explosion, however, was photographed at an angle that makes it difficult to assess the relative positions of the ships and cross-reference them with the map. A perspective from above is much better suited for this, and there are high-quality photographs of the moment of the Baker explosion from different angles.

View from the East, the Prinz Eugen marked in red

View from the South, the Prinz Eugen marked in red

I referenced the map for the Baker test with aerial photographs of the explosion. I used the GIMP’s Perspective Tool to overlay photographs from two different angles with appropriately distorted versions of the map. I cross-referenced the positions of the ships in both photographs, cloud shapes, the incident angle of the sun and the lighting/shades of the ships to make what I believe is a good match between the map and both photographs. The following annotated pictures and lists give the names of those ships I have identified in the map-overlayed photographs with reasonable certainty.

The names and numbers are the same as in the above book. Beware that this is all just the result of an hour’s worth of Googling and an hour of playing with GIMP.  I could be completely wrong.

Original picture on Wikimedia Commons

Number Name
36 IX Prinz Eugen
47 DD Wllson
51 YOG-83
44 DD Trippe
29 DD Mayrant
11 ARDC-13
38 CA Salt Lake City
54 LCT-332
17 APA Briscoe
21 APA Catron
16 APA Bracken

Original picture on Wikimedia Commons

Number Name
38 CA Salt Lake City
31 BB New York
17 APA Briscoe
21 APA Catron
16 APA Bracken
34 BB Pennsylvania
40 SS Skate
23 BB Nevada
28 CVL Independence
22 APA Crittenden

P.S.: I’m very curious to know if anybody ever finds this interesting or even useful. Please do leave a comment if you have actually read and/or used this 😉

German freemail heavyweights and (several millions of users combined) are using deceptive techniques in order to manipulate Firefox and Chrome users into removing AdBlock and its variants. This message is displayed for people with the respective setup:

web_deThe yellow bar is part of the website (it even scrolls with the site). It says:

The security of your computer is compromised by a Firefox Add-On. [Restore Security]

Clicking the fake button or the „Further information“ link takes the user to a shady-looking website charmingly named (browser security dot info).

This site imitates the look of Chrome’s browser settings and uses a seemingly objective and caring tone, explaining how „content manipulating browser add-ons“ pose an enormous security risk. It also contains a surprisingly short list of allegedly „known malicious browser add-ons“:

plugins2Note how AdBlock and several variants of it are shown at the top of this list, described as „filters page contents“. Every user of AdBlock is aware that it filters contents—that’s its purpose. Still, this list is obviously supposed to cause insecurity and fear, especially since the same list contains obscure and dubious sounding add-ons. Many of them are described as „inserting external elements like advertising“. One, ironically, is accused of „creating false security alerts“.

Otherwise, the page purports to be a well-meaning security initiative. Only the legally-mandated and well-hidden Contacts page shows that 1&1 Mail & Media is behind it. The 1&1 DSL and hosting franchise is part of the German United Internet company, which in turn owns and A press release at praises it, but is not named as part of this „program“ anywhere on the site. However, in the ridiculously short „press comments“ section, and appear as two out of three sources (the third being a nasty tabloid’s computer spinoff magazine).

This practice is all the more more malicious, as it has taken years to establish that browsers show meaningful security notifications, and to get everyone’s parents to actually read and follow them.

Apparently, the Mozilla security team is looking at the situation, which I’m very grateful for.

Updated 2017-03-06: Now properly handles oldmail files to avoid multiple downloads of old mail when calling different sets.

Faced with a growing number of mailboxes to fetch messages from, I devised a little script to help me easily manage lots of accounts with getmail. It was inspired by this post from Charles Cazabon, the developer of getmail.

The advantage of this solution is that you need to create, name and manage getmail’s rcfiles for different mailboxes in one place only, without modfying other scripts, crontabs or whatever.

First off, this is the folder structure I created. It may remind you of the old /etc/rc.d/ folder structures that were common for system start scripts before we had upstart and all this modern whoop-de-do:

├── set-all
│   ├──
│   ├── rc.freemail
│   ├── rc.provider
│   ├── rc.uni
│   └──
├── set-often
│   ├── rc.provider -> ../set-all/rc.provider
│   ├── rc.uni -> ../set-all/rc.uni
│   └── -> ../set-all/
├── set-rare
│   ├── rc.freemail -> ../set-all/rc.freemail
│   └── -> ../set-all/
└── set-important
    ├── rc.uni -> ../set-all/rc.uni
    └── -> ../set-all/

.getmail/ -> .getmailsets/set-all/

All the getmail-typical rcfiles live in the .getmailsets/set-all/ folder, which is symlinked to .getmail/. This ensures that things will work like any normal getmail setup whenever you don’t use the sets.

Specific sets of rcfiles are defined by folders with a corresponding name and contain links to the actual rcfiles in the „all“ set.

This is the script that puts this structure to use. I call it checkmail:


RCSET=$1  # first argument names the set,
shift     # then gets deleted

for F in $RCPATH/set-$RCSET/rc.*; do
  RCARGS="$RCARGS --rcfile $(basename $F)"  # prepares --rcfile args

exec getmail $@ --getmaildir $RCPATH/set-all/ $RCARGS
                # make sure getmail always uses same oldmail-*
           # $@ holds all the (remaining) arguments to the script.

You use checkmail by calling it with the set name as the first argument, and any arguments you want to pass on to getmail, like in these examples:

$ checkmail all -q
$ checkmail important -v
$ checkmail rare -q -d

And these calls, of course, are what you want to place in your scripts, shortcuts and whatnot. You can then manage the set contents or rename the rcfiles in your .getmailsets without changing any of the scripts. How about, for example, a button on your desktop that runs:

$ ssh mailserver "checkmail important -v"

The script is also ideal, of course, for your crontabs. Here’s an example of my configuration:

*/5  0-3,9-23  * * * checkmail often -q
  0      8-23  * * * checkmail rare -q

Since $HOME/.getmail/ is symlinked to .getmailsets/set-all/, you can also call getmail for any single mailbox like your ordinarily would:

$ getmail -r
$ getmail -vr rc.uni

In my university’s research group, there’s a traditional weekly seminar known as „Kaffee und Technik“, where people will show each other tricks and methods they learned in the course of their research. Recently having taught myself a working knowledge of simple binary data storage and readout with Python, I compiled a little lecture on the subject.

Hoping that someone out there might also find this useful, I’m posting my slides here:

In case you’re wondering: The editor I am using is wxHexEditor. I found it to be a very good hex editor, with many more capabilities than most others out there. It is actively being developed and works equally well on Windows and Linux. It even compiled without any dependency hassle on an oldish system of mine.

So, if you’re looking for a good hex editor, try wxHexEditor. The project’s homepage is somewhat of a hassle to navigate around, but it’s definitely worth it.

A little over a year ago, serious problems were reported when using Arduino Uno and other Arduino boards for serial communication on Linux systems, most reports regarding various Ubuntu variants from versions 9.10 through 10.10, including 64bit versions. Since this problem has not popped up much recently, I suspect that newer boards don’t have this problem anymore. However, I recently had to deal with Arduino Uno boards bought circa in mid-2010, so I ran straight into these troubles. Read below for a detailed description of the symptoms.

A few weeks after the problem was reported, a firmware upgrade with a fix was published. An article was posted on describing the problem and how to fix it. In order to understand what the problem is and how it is fixed in principle, you should first read this article at describing the problem and their proposed fix.

The instructions posted on require you to solder a resistor to the back of your Arduino in order to flash the DFU bootloader. However, there is another way, as outlined in this forum thread at, describing how fix the problem without having to solder on their board. I cannot say whether this way is safer or not, so (as always) read everything carefully and proceed at your own risk!

On a calming note, the author of the Uno’s USB stack says in a forum post:

“it is impossible to break your board permanently if upgrading through the DFU bootloader”

On a frightening note, the wire-touching procedure described below is commented thusly:

“Be careful with the second wire as the capacitor is quite near a 5v track. You can try using a low-value resistor instead of a wire if you are worried about blowing up your board.”

Have you made up your mind about trying this? Okay, then let’s go:

Error messages and symptoms When plugging in the Arduino, it registers normally, as reported by dmesg:

[...] cdc_acm 3-1:1.0: ttyACM0: USB ACM device

However, when the Arduino is running a skech that uses even trivial serial communication, the TX LED hangs, and the Arduino IDE reacts very slowly to menu clicks (especially when trying to open the Tools menu). When trying to start the Serial Monitor, the IDE will hang for a moment and finally report errors like this:
Serial port '/dev/ttyACM0' not found. Did you select the right one
from the Tools > Serial Port menu?

I’m not 100% sure, but I think I also saw the following error message in this context:

avrdude: stk500_recv(): programmer is not responding

When the serial interface dies, dmesg will report this:

[...] tty_port_close_start: tty->count = 1 port count = 0.

If you want to upload a ‘safe’ sketch (i.e. one without serial communication), so as to make the board temporarily usable again, you have a few chances:

  1. Use a Windows machine to upload a new sketch.
  2. Reload the cdc_acm kernel module that creates the ttyACM* device nodes (or just reboot your machine) and reconnect, then use some timing and feeling to upload the sketch with the IDE shortly after the Arduino boots.
  3. Play around with the Reset button on the Arduino board and use some timing and feeling to upload a new sketch.

Of course, that’s no real solution. So let’s get to fixing the board.

Downloading the firmware and preparing to flash You will need a tool called dfu-programmer. This is available fromthe Ubuntu repositories, but reports say you should have at least version 0.5.1. If can only get an older version from a repository, you should at least be able to compile 0.5.1 if you have the lubusb-dev package.

Get the right firmware code for your board from this page by selecting the correct board version (‘Arduino-usbserial-uno.hex’ or ‘Arduino-usbserial-mega.hex’), then save the file linked from the “Raw” button at the top right of the code display.

Putting the Arduino board in DFU mode and flashing This requires two short (about 5 centimeters or 2 inches) pieces of wire and two steady hands. First, put both wires into the GND sockets as shown in the picture. Then connect the board with a USB cable, then first hold the upper wire to the contact as shown, while touching and releasing the lower wire the the left side of the indicated capacitor:
Update: Contrary to what is pictured here, it seems that at least for some Arduino Mega 2560, the second wire is not required. Try just connecting the first wire as shown, and if the Arduino enters dfu mode immediately (see below for how to tell), you’re good without needing to connect the second wire.

The LED labelled “L” may give two short blinks, unless the board is running a sketch that uses the “L” LED. Even though it may seem like the Arduino is just normally running its sketch, if you have executed the procedure correctly, the Arduino is now in DFU mode. You can verify this by examining the output of lsusb. Instead of reporting with ID 2341:0001 as usual, the Arduino will report with ID 03eb:2ff7 Atmel Corp. if it is in DFU mode. When you have made sure the board is in DFU mode, run:

  1. sudo dfu-programmer at90usb82 erase
    1. the RX LED will come on and stay on
  2. sudo dfu-programmer at90usb82 flash –debug 1 Arduino-usbserial-uno.hex
    1. use the correct filename that corresponds to your board’s firmware!
    2. dfu-programmer should output something like:
      4058 bytes used (49.54%)
    3. the TX LED will come on and stay on, so now RX and TX will be glowing
  3. sudo dfu-programmer at90usb82 reset
    1. All LEDs are now off.

Now, unplug the Arduino and wait a second. After this, everything should work smoothly, even serial-heavy sketches!

Good luck, have fun and don’t hesitate to post a comment if you have new/more precise information!