Time to change my desktop theme ...

Just like out there.

Depending on network bandwidth, it may be preferrable to transfer data physically, for example in the form of a USB stick or the harddrive of a notebook. Since the transfer potentially exposes the data to the public, they should be encrypted. Personally, I use ecryptfs for the home partition of my netbook and encfs for sticks. Alas, mine is a lone voice in the wilderness: none of my colleagues and friends would even think about this subject. They'll never lose their stick!

Until they do. And then, of course, they come running and wailing and expect that I get it back for them right away or delete the data remotely immediately.

At least the last of this incidents raised the awareness for the need of appropriate measures when carrying sensitive data from A to B. After much discussion, the management finally came to the conclusion that USB safes would be the one and only solution.

At that time, I didn't know much about USB safes, other than that they are sticks with a built-in hardware encryption. Well, that, and their costliness: while a Kingston DataTraveler G3 with 8 GB can be obtained for €14, a Kingston DataTraveler Vault, again with 8 GB, has a price tag of €74.

For this price, I'd of course expect unquestionable und uncompromising security. Well, just a minute of further research led me to this page. The above mentioned 'Vault' is not affected, but that is of little consolation.

Back then, I didn't brood over the ways with which an unauthorized intruder could possibly gain access to these allegedly impenetrable devices. An article in c't 22/10 clarified that now, and surprised me with an archaic attack scenario which I would have not believed to be possible.

Entitled Panzerknacker, the article details the specific weaknesses of commercially available solutions: "Das wichtigste Angriffsszenario ist das Auslöten und Auslesen der Flash-Chips."

Wait a second...the most important attack is hardware related? But what about encryption?

"Verguß hin oder her: Physische Sicherungsmechanismen lassen sich letztlich irgendwie umgehen. Daher bleibt als letzte Bastion die Verschlüsselung."

The last one? Shouldn't encryption stand for itself? Well:

"Ich würde mir ein sorgfältig konstruiertes System nebst vollständigen Konstruktionsplänen und unabhängig geprüftem, offenem Quellcode [..] wünschen, doch solch ein Produkt kenne ich bislang nicht. Diesen Zustand erreicht man derzeit nur mit quelloffenen Software-Lösungen wie TrueCrypt in Kombination mit gewöhnlichen USB-Sticks. [...] In Sachen Komfort und Systemunabhängigkeit kann eine solche Lösung mit einem USB-Safe aber nicht mithalten." -- Peter Franck (Attingo, a data restoration specialist)

Wie komfortabel hätten wir's denn gerne? Soll der Stick das Passwort von den Lippen lesen und dazu einen Kaffee kredenzen? *kopfschüttel*

But wait: an open source solution in combination with an ordinary stick, that's just what I'm using. Hey! I've put the commands for mounting and unmounting the stick in scripts called 'ms' and 'us' for greater convenience. It's still very inconvenient, of course: you have to type the name of the script and the passphrase. Ah, why is life so hard?

Prague, you golden city! How much you have to offer!¹

No, one won't find streetlights like that in any other place. 😉

These photographs were taken by a friend during our three-day-and-night party in Prague on the occasion of his birthday. The ladies (yellow spot) reside close to the hotel we had booked, which in turn is located 20 m away from U Fleků.

¹ The museum of medievial torture instruments and the museum of sex machines, for example. And all varieties of pussy (or so we were told constantly). 😄

Software tends to get fatter with time. Just look at Firefox, which started as Phoenix with the self-proclaimed aim to fight the bloat of the Mozilla project. Look at it now: a fatter browser was never seen.

Others are not better. When upgrading my Mini to Maverick Meerkat, I've noticed that Chromium now takes 50 MB of my precious SSD space, just as much as Firefox does.

But what can we do? Light-weight alternatives—such as links—are limited in ability and performance, aren't they?

Are they?

uzbl git.20100403-3
    1652.8ms +/- 3.2%
Chromium 8.0.551.0 (62128)
    1834.8ms +/- 2.0%
Firefox 3.6.10
    4163.6ms +/- 1.4%

root@mini:/home/cobra# wajig size | grep chromium
chromium-codecs-ffmpeg                  1,180
chromium-browser-inspector              3,940
chromium-browser                    49,252
root@mini:/home/cobra# wajig size | grep uzbl
uzbl                            656

root@mini:/home/cobra# wajig remove
chromium-codecs-ffmpeg
chromium-browser-inspector
chromium-browser

Adblocker? Privoxy:

vi ~/.config/uzbl/config
set proxy_url = http://127.0.0.1:8118

I also like

@cbind  gc<Scroogle:> = uri https://ssl.scroogle.org/cgi-bin/nbbwssl.cgi?Gw=%s&n=2
@cbind  gx<IxQuick;> = uri https://ixquick.com/do/metasearch.pl?query=%s&cat=web&pl=chrome&language=english

in ~/.config/uzbl/config.

I love this browser...its just perfect for the Mini 😊 And vi aficionadas have a new home. 😉

A friend of mine from Cincinatti was impressed by the date printed on a Staropramen bottle he'd seen on his visit to Prague. 'Woohoo, 19th century!' He didn't quite understand my sudden hysterical laugher following this enthusiastic statement. Here's some of the beer I recommend these days to prove my point. 😄

Pity it's already so cold. Otherwise you could call both of the above just a modern fashion in view of a Weihenstephan Hefeweizen. 😉

Back in the days where data were transported on disks capable of holding a mere 360 kB, file compression was a vital technology and widely used. In the age of terabyte harddisks, file compression appears somewhat outdated, even obsolete, since storage space is cheap and available in abundance. Even more important, most modern file formats utilize compression (both lossy and lossless) anyway. Pictures, for example, are stored as png or jpeg, documents as pdf or odt (which is nothing but a zipped xml container), music as mp3, and movies as mpeg4. Very little is gained when trying to compress these files once more, so why bother at all?

Well, I can only speak for myself. I use LaTeX for publications and presentations, so all my texts are also stored as such: plain text. Graphics are included as pure ASCII encoded encapsulated post scripts, and thus as plain text. Data are plain text anyway, Mathematica scripts are, and shell or Python scripts also. All of my important files are plain ASCII. Now, plain text can be compressed very efficiently, and since I usually synchronize my computers via the net, I welcome small sizes since the bandwidth I'm commanding is far from infinite.

Size, however, is only one aspect: the compression and decompression time should not exceed the saving in time obtained when transmitting the compressed file. Otherwise, the undisputed champion of text compression, paq8, would win single-handedly. 😉

For a comparison, I've selected a realistic example: the project folder of this paper, which is roughly 200 MB in size (precisely 215336960 bytes). This folder contains all files needed in the course of the project, including many whose size cannot be reduced significantly by further compression (such as figures in pdf format). I've archived the folder using 'tar -a -cvf test.tar paper/' since several of the file compressors do not archive themselves.

The following table displays all relevant data: the name of the contender in the first, the size of the compressed tar archive in the second, and the compression and decompression time in the third and fourth column, respectively. I've used the default setting unless otherwise noted. The first numbers in the latter columns stem from my dual core desktop system (e6600, 2.4 GHz, 8 GB RAM), the second ones in brakets from a 24 core workstation (opteron 8431, 2.4 GHz, 64 GB RAM). Draw your own conclusions (but note that only pigz and pbzip are fully parallelized).

Ok, ok: I use nanozip. And yes, nanozip is also available for Windows, even with a GUI. 😉

Maximum compression reference (noncompetetive):

¹ with -m0=BZIP2 -mmt
² with -cdP -t6
³ with -t7z -m0=lzma -mx=9 -mfb=64 -ms=on -md=32m (upon popular request 😉 )

Yesterday, I've visited my favorite Indian restaraunt and asked for an 'Indian' rated Chicken Vindaloo. I've been in India several times and know the real deal. It was close, and I don't know anybody who'd eat this Vindaloo without breaking into a sweat. 😉

Yet, when I want to have the raw deal, I don't turn to Indians, nor to Mexicans, but instead to 四川菜 (Szechuan). A favorite breakfast for kids there is 'Chili Noodle', and if they say Chili, they mean it.

Today I'm in the mood to top the Indians, so I'm cutting a Habanero for use of the remains of a great, but altogether too mild soy-beans based chili. My personal limit: I've tried two Habeneros per dish, but found to my great disappointment that the resulting melange was a tad too hard for me.

But one does the job just fine. 😄

After posting the above, I've seen the fortune of Mark Twain: "The difference between a Miracle and a Fact is exactly the difference between a mermaid and a seal."

Well said. And: "The difference between a Mermaid and a Seal is exactly the difference between a dish with one and two habaneros."

A lot in life is about choice. Or you could say, choice is what life is all about. Since we're all independent minds in charge of ourselves (aren't we), the choice is ours. We chose our profession and our partner. We chose the city we live in, the apartment we rent, the car we drive, and the food we eat. We chose the color of the carpet in our bedroom as well as the reading providing the intellectual stimulus required for our morning sessions.

You didn't believe a word of what I just said, right? Good! 'Cause I don't believe it myself. The first thing I see every morning is this black Ferrari 599 GTO in the traffic jam at Tiergartenstraße. At first the guy in there didn't like my mocking greeting when I passed him on my blue Muddy Fox, but now he grudgingly returns it every time. I understand his bad mood, since I'd sure hate to see bicyclists passing with ease as I stand there in my third of a million Euro investment. You think he's chosen to stand there? No, he's forced by social conventions and social ties.

As soon as I arrive in the office, I get another excellent example of the failure to chose rationally. One? Well, dozens. Imagine lots of people with a PhD in physics, and all of them with the task to present their latest ideas to an international audience. And what do they use for that? Powerpoint (or OpenOffice Impress, which is just as bad).

Why's that a bad idea? Millions of presentations are given by Powerpoint everyday, after all. Well, it's not really the presentation itself, but rather the questions following it. It happens after every talk: a question refering to the plot on slide ... "hmmmm, I can't remember. The one with the nice plot showing this and that, you know?" The speaker then walks back his slides, one by one, through all silly transitional effects, from slide 31 to slide 5 which takes about 2 min. And so on for the majority of questions asked. 😞

With the time wasted by this utter nonsense, one could easily organize another conference.

But what alternative do we have? Well, an excellent one if the presentation is in pdf format (the natural format for a beamer class presentation). The python script impress!ve (aka keyjnote) does away with this and other inconveniences.

Simply press the tab key to see a full-screen overview of all slides. Press 'Enter' for a spotlight which has both more visibility and more weight than the Parkinsonian spot of the trembling laser pointer. Use the left mouse button to highlight entire regions of the slide, while the rest is shaded such as to not distract attention. Press 't' to look how much time has evolved since your talk has started. Etc., etc. ... Of course, you may also write scripts to extend the functionality, like jumping to certain slides once pressing their number.

Impress!ve uses OpenGL hardware acceleration for the display of transitional effects. If you don't like them, or don't have the hardware, swith them off with the command line parameter '-t None'. My Mini, for example, is too slow to display smooth transitional effects except for one (CrossFade). All others are sort of ... stuttering. The shading, in contrast, is done smoothly and effortless. 😉

A colleague of mine wrote a few lines of code which simulate a longitudinal x-ray scan of a periodic heterostructure in the kinematical approximation. Gaussian fluctuations in the vertical position of the layers are explicitely included. Since MadMax doesn't offer this possibility, I got very interested in this little simulation.

Here's the Fortran code:

program kinemat
implicit none
integer Nat1,Nat2,Nperiods,i,j,n,Nbuffer
integer, parameter :: Np=50000
real pi,a,q,eps,t1,t2,t,a1,a2,sigma,R,Tbuffer
complex Ffilm,Fbuffer,FonePeriod,Fperiodic
complex, parameter :: Im=(0.,1.)
pi=4.*atan(1.)
a=0.2593 ! spacing [nm]
Nat1=3./a ; Nat2=14./a ; Nbuffer=500./a
Nperiods=4
eps=0.02
sigma=0.
a1=(1.+eps)*a ; a2=a
t1=Nat1*a1 ; t2=Nat2*a2 ; t=t1+t2 ; Tbuffer=Nbuffer*a2
open (10,file='kinemat.dat')
do i=1,Np
    q=2.*pi/a + 3.*(-1.+2.*i/Np)
    R=exp(- (q-2.*pi/a)**2*sigma**2/2.)
    FonePeriod=( (exp(Im*q*t1)-1)/(exp(Im*q*a1)-1) + &
   (exp(Im*q*t2)-1)/(exp(Im*q*a2)-1)*exp(Im*q*t1) )
    Fperiodic=(exp(Im*q*t*Nperiods)-1)/(exp(Im*q*t)-1)
    Ffilm=exp(Im*q*Tbuffer)*Fperiodic*FonePeriod*R
    Fbuffer=(exp(Im*q*Tbuffer)*R-1.)/(exp(Im*q*a2)-1.)
    write (10,*) q,log(abs(Ffilm+Fbuffer)**2)
enddo
end program kinemat

For such a small task, Fortran is perhaps not the ideal choice, and I thus decided to "port" the code to Python. What I initially didn't understand was the "clumsy" way to define the thicknesses. If t2 = nat2*a2, and nat2 = 14/a with a = a2, then t2 = 14. Right?

Right. But what happens when you apply the same to t1 and nat1? I thought it'd be basically the same, but what I didn't see and understand (blind as a mole, dumb as a pole) is that nat1 and nat2 are defined as integers in the above code. Fortran then automatically rounds these numbers ... and that's essential! Look at the following expression, which is the basic element of the equations above:

$\Large{ \frac{e^{inq} - 1}{e^{iq} - 1}}$

With an integer $n$ and at $q = 2 \pi$, this expression is indeterminate. This single value is simply ignored by all implementations, be it in Fortran, Python, or Mathematica. However, if n is not an integer, the ultimate mathematical sin is commited: divison by 0. OMG! 😄

Just enter the following lines into an ipython console and see for yourself:

q = arange(-2.5*pi,2.5*pi,0.0001)
int=(exp(1j*10*q)-1)/(exp(1j*q)-1)
plot(q,int)

Nice and well behaving. In contrast:

int=(exp(1j*10.371*q)-1)/(exp(1j*q)-1)

Horrible *shudder*

Here's the final python code:

It is, by the way, only natural to have an integer n, since crystals grow in discrete atomic layers, and not in arbitrarily small increments. Being a physicist, I should have seen that right away. What a shame.

Ahhhh, WTF. 😄

PS: Oh ja, the performance. With Fortran, you change the parameters, save, compile, and excute the program. Then you gnuplot the result. With Python, you change the parameters, save, and excute the program which plots the results. Well, what do you think?

I'm working on a manuscript with a two-column setup (as essentially all manuscripts for respectable journals). I want several of the figures to span the entire width of the page. Easy: \begin{figure*}...\end[figure*}. Great, it goes to the top of the page. Then the next figure should go to the bottom of the page, right?

Wrong. The fucking figure goes to the end of the manuscript. *AaaHaaHaarghx!*

It took me a while to realize that this behavior is actually the one you expect by design. Jesus.

\usepackage{stfloats} takes care of this mess in the most uncelebrated way. 😉