So here I am, enjoying a cold beer on a Friday afternoon with my Humppaball buddy, and suddenly, this crazy car that is bristling with cameras drives by, and now my pixelated face is all over the Interwebs! This is AN OUTRAGE!1! (for a second, I even considered putting a <blink> in there)

(I don’t really see why our privacy agencies are getting so upset about StreetView while people fritter away the actual private details of their lives on Facebook and are about to have their entire communications history stored in arbitrarily secure lockers at telecom companies.)

1980 flashback edition!

Der Kurier konstatiert in verfehltem Zynismus: “Bald wird uns nichts mehr verblüffen
können. Kein nationales Heiligtum bleibt verschont. Die Schlagzeile Sängerknaben zahlen
Schmiergelder an Lippizaner wird uns nicht mehr aufregen.”
— gingrich, oliver: Der Fall Rabelbauer. Der Mann mit dem Koffer. Seminararbeit, 2002

So, at least, things aren’t going down the drain, they have been solidly there for my entire life (and long before that). Btw, though all my examples seem to cluster in one party, there are plenty of examples from the rest of the political spectrum, I just can’t be arsed to waste more time digging through historical accounts I find deeply depressing just to provide a balanced view here.

Commentary is here.

Yay, data mining the US dating scene – the OKCupid blog! 7% of white females agree with “Interracial marriage is a bad idea”, while 54% agree with “I would strongly prefer to date someone with my own skin color/racial background”. “You know, racism is bad, but colored people? They’re just not that good.” (and ha, it’s even worse with non-whites, so maybe all the anti-racism conditioning at least has some effect).

I read David Foster Wallace’s famous Kenyon College commencement address again this week and was impressed. Part of me remains skeptical about taking life advice from somebody who obviously didn’t cope too well, but another part marvels at the number of times I felt compelled and moved by his reformulation of “things everybody knows”.

Because here’s something else that’s true. In the day-to-day trenches of adult life, there is actually no such thing as atheism. There is no such thing as not worshipping. Everybody worships. The only choice we get is what to worship. And an outstanding reason for choosing some sort of God or spiritual-type thing to worship — be it J.C. or Allah, be it Yahweh or the Wiccan mother-goddess or the Four Noble Truths or some infrangible set of ethical principles — is that pretty much anything else you worship will eat you alive. If you worship money and things — if they are where you tap real meaning in life — then you will never have enough. Never feel you have enough. It’s the truth. Worship your own body and beauty and sexual allure and you will always feel ugly, and when time and age start showing, you will die a million deaths before they finally plant you. On one level, we all know this stuff already — it’s been codified as myths, proverbs, clichés, bromides, epigrams, parables: the skeleton of every great story. The trick is keeping the truth up-front in daily consciousness. Worship power — you will feel weak and afraid, and you will need ever more power over others to keep the fear at bay. Worship your intellect, being seen as smart — you will end up feeling stupid, a fraud, always on the verge of being found out. And so on.

Sadly, this never seems to coincide with MY all-nighters:

Me, on Usenet, in 1998:

Hallo...
 
Nennt mich jetzt ruhig Verräter, aber weil ich leider in der Schule
gezwungen werde, CICS zu programmieren, wollte ich mal fragen ob da
vielleicht mal jemand die Sünde begangen hat, sowas auf Linux/Unix zu
portieren...
Weiss vielleicht jemand was, was mir weiterhelfen könnte? Netzsupport wäre
toll, aber ich wär auch mit einem Single User System zufrieden...
-- 
Thomas Themel
die_glacionauten@haidronic.edv.net
Rennsteinerstrasse 14a/1
A-9500 Villach
++434242210426 

The magic Internets just took a bit more than a decade to cough up the answer: zCobol. Can’t say I miss the days of EIBCALEN and DFHBMSCA, though.

I just wiped the dust off my monitor, using the supplied cleaning cloth. I even read the instructions and kept within the limits of spraying my cloth with water 4-6 times. When I sit down again, the monitor is off. I press the “Source” button a couple of times to cycle through the available inputs in hope to find either the laptop or the desktop, both connected to the monitor. No reaction. I press all the other buttons, nothing either. I disconnect and reconnect power. I check that the power cable hasn’t magically unplugged itself and the inputs are still firmly attached. I start looking for a power switch in all the usual and unusual places, but fail. Defeated, I turn to the laptop and download the monitor’s manual, only to find the obvious explanation:

There is a power “switch”, but it’s a touch sensitive area on the front side of the monitor (contrasted with all the other buttons, which are physical buttons hidden on the side of the monitor). It’s even marked with the universal “power” sign, but it’s quite easy to misread that as a label for the power LED that’s located a couple of millimeters below. But yeah, fine monitor. And it’s probably obvious to members of the iPhone generation.

So, my application doesn’t work. Somehow, a file I want to store stuff in always ends up empty. I dig through the code. I debug the code. I strace the code and look for other access to the file. It looks perfectly okay, I never touch the file again after a nice create/write/close without any errors. Standing by as the file is written, I see this:

[root@somewhere somewhere]# while true; do ls -l --time-style=full foo; sleep .5; done
ls: foo: No such file or directory
-rw-r--r--  1 nfsnobody nfsnobody 0 2009-07-24 13:54:36.117293000 +0200 foo
-rw-r--r--  1 nfsnobody nfsnobody 65 2009-07-24 13:54:39.544909000 +0200 foo
-rw-r--r--  1 nfsnobody nfsnobody 65 2009-07-24 13:54:39.544909000 +0200 foo
-rw-r--r--  1 nfsnobody nfsnobody 65 2009-07-24 13:54:39.544909000 +0200 foo
-rw-r--r--  1 nfsnobody nfsnobody 65 2009-07-24 13:54:39.544909000 +0200 foo
-rw-r--r--  1 nfsnobody nfsnobody 65 2009-07-24 13:54:39.544909000 +0200 foo
-rw-r--r--  1 nfsnobody nfsnobody 65 2009-07-24 13:54:39.544909000 +0200 foo
-rw-r--r--  1 nfsnobody nfsnobody 0 2009-07-24 13:54:39.544909000 +0200 foo
-rw-r--r--  1 nfsnobody nfsnobody 0 2009-07-24 13:54:39.544909000 +0200 foo
-rw-r--r--  1 nfsnobody nfsnobody 0 2009-07-24 13:54:39.544909000 +0200 foo

Since this happens even when I kill my application while the file is still in its non-empty state, I start getting suspicious about the underlying filesystem (as you’ve probably noticed by now, NFS). Now, look at this:

[root@somewhere somewhere]# echo "0123456789012345678901234567890123456789012345678901234567891234" > aFile
[root@somewhere somewhere]# cat aFile
[root@somewhere somewhere]# ls -l aFile
-rw-r--r--  1 nfsnobody nfsnobody  0 Jul 24 11:27 aFile

But…

[root@somewhere somewhere]# echo "012345678901234567890123456789012345678901234567890123456789123" > aFile
[root@somewhere somewhere]# ls -l aFile
-rw-r--r--  1 nfsnobody nfsnobody 64 Jul 24 11:27 aFile
[root@somewhere somewhere]# cat aFile
012345678901234567890123456789012345678901234567890123456789123
[root@somewhere somewhere]# ls -l aFile
-rw-r--r--  1 nfsnobody nfsnobody 64 Jul 24 11:27 aFile

Heh. So writing a file of 64 bytes or less works, while anything larger gets reset to zero sooner or later. Of course, that begs the question of what happens when appending to a 64 byte file…

[root@somewhere somewhere]# echo "012345678901234567890123456789012345678901234567890123456789123" > aFile
[root@somewhere somewhere]# cat aFile
012345678901234567890123456789012345678901234567890123456789123
[root@somewhere somewhere]# echo "X" >> aFile
[root@somehwere somewhere]# cat aFile
012345678901234567890123456789012345678901234567890123456789123

Lovely, isn’t it? At this point, I want to investigate this thing a bit more exhaustively and try to write a shell script in that fateful directory. When I’m done, it has of course grown over the magical 64 byte boundary, and vim warns me that

"test.sh" E667: Fsync failed
WARNING: Original file may be lost or damaged
don't quit the editor until the file is successfully written!

An error at last. So I start googling around for failed fsyncs on NFS, and it turns out that they like to crop up when the NFS developers break the kernel code. However, when I strace my vim to find the error, it finally dawns on me what the actual problem is:

fsync(4)                                = -1 EDQUOT (Disk quota exceeded)

Ah yes, quotas.

[root@somewhere somewhere]# quota nfsnobody
Disk quotas for user nfsnobody (uid 65534):
     Filesystem  blocks   quota   limit   grace   files   quota   limit   grace
nfshome0:/vol/vol1/nfshome0
                2150400* 2048000 2150400             736  102400  122880

Sure enough, this weird behaviour turns up when the user is over its quota. Also, interestingly, the ability to even write the long files in the first place seems to be limited to bash – for example:

[root@somewhere somewhere]# dd if=/dev/zero of=foo bs=65 count=1
1+0 records in
1+0 records out
dd: closing output file `foo': Disk quota exceeded

And sure enough, an strace of this dd shows that it gets an error on close:

close(1)                                = -1 EDQUOT (Disk quota exceeded)

Amazingly, bash’s echo somehow seems to bypass this check, since the appropriate section of its strace reads:

open("foo", O_WRONLY|O_CREAT|O_TRUNC|O_LARGEFILE, 0666) = 3
fcntl64(1, F_GETFD)                     = 0
fcntl64(1, F_DUPFD, 10)                 = 10
fcntl64(1, F_GETFD)                     = 0
fcntl64(10, F_SETFD, FD_CLOEXEC)        = 0
dup2(3, 1)                              = 1
close(3)                                = 0
fstat64(1, {st_mode=S_IFREG|0644, st_size=0, ...}) = 0
mmap2(NULL, 32768, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0xb7ddb000
write(1, "01234567890123456789012345678901"..., 66) = 66
dup2(10, 1)                             = 1
fcntl64(10, F_GETFD)                    = 0x1 (flags FD_CLOEXEC)
close(10)                               = 0

Huh? I can’t seem to make sense of this. But anyway, I’ll go pester the NFS admins to increase nfsnobody’s quota a bit now and alter my code to check all the fstreams’ failbits again after closing them, then hope that my application doesn’t use whatever magic bash uses to bypass the error. You’re welcome to earn major geek points in the comments by explaining this to me.

M-x phases-of-moon

Of course with optional prefix argument for specifying year and month. Ha, TextPad losers – can your text editor help you find out that your first full moon was three days after your birth?