Older blog entries for ncm (starting at number 397)

I find it hard to argue with Avery in his rant against C++, besides minor quibbles. (In fact, you can append to a std::string without re-allocating. You can choose whether a std::map should quietly allocate a new cell for a previously unused key.) Still, much of what he writes is true. Yes, C++ code is often unavoidably unpleasant to look at. Yes, std::string is nobody's baby. Parts of the language are best forgotten (I'm looking at you, RTTI, and exception declarations, and export templates). We could say that's the price of power, but Java is just as ugly and not powerful at all. Haskell is pretty enough, and seems powerful until you try to use it for anything. The Gloriously Incompatible Successor to C++ could be even more powerful, and beautiful, but it's nowhere on the horizon. Until somebody makes one, well... there's more to life than pretty code. Powerful code, for example.

I upgraded my laptop kernel to Linux 2.6.34.1 to get the qcaux driver so it would talk to my Sanyo Katana LX phone, to offload pictures. When I plug it in, it shows up in dmesg, but nothing seems to know how to talk to it. I wonder what to try next. [Update: Dan Williams's blog has everything known. Yay Dan Williams. No picture downloads, but ModemManager can PPP through it, which is good for something, I guess.]

I just read And Another Thing, volume 6 of the Hitchhiker's Guide trilogy by Eoin Colfer, apparently under license by Adams's heirs. I'm tempted to say the best thing about it was the name of the Vogon ship, the Business End, out-Iain-M-Banksing Iain M. Banks himself.

I also read Strength in What Remains, by Tracy Kidder, The Wind-up Girl by Paolo Bacigalupi, Adventures of a Cat-whiskered Girl by Daniel Pinkwater (who I thought was dead and I'm overjoyed to find ain't), Complications: a surgeon's notes on an imperfect science by Atul Gawande, and Gunnerkrigg Court volumes 1 and 2 by Tom Siddell. All recommended.

I'm finally off Network Solutions. When they finally delivered the "authorization code" (first stalling for four days, for no reason) they offered a year's service for $16. Never, during 15 years as a regular customer, did they ever offer any $16 service short of a 7 year contract. Of course Gandi offers better every year, no strings attached (and even less for the despised ".biz", ".me", and ".co.uk" suffixes).

I'm a little late, but my Ada Lovelace Day choice for admired female hacker is Emilia Käsper, who coded implementations of AES-CTR and AES-GCM that run in under 10 cycles/byte, using SSE3 instructions, and defeat timing attacks besides. Each of 8 128-bit registers holds a bit from each byte in 128 bytes of plaintext: paper, slides. It isn't clear from the slides, but she shuffles the bits to their various registers using an SSSE3 instruction (and a "shuffle unit") that isn't in current AMD chips. Besides the speed, this is important because timing attacks on regular AES implementations are astonishingly easy.

A faster cipher would work on 128-byte blocks and just skip the bit shuffling. It wouldn't interoperate with anybody, but would be equally secure. If you went that route, I gather that one step of AES has turned out not to add any security, so you could skip that bit, too. You could call your cipher Skiphack. (Little historical joke there.)

My domain, cantrip.org, has been with Network Solutions ever since its inception. I've meant for years to move it, but just never got around to it until now. I chose Gandi.net for no better reason than that it's what Joey Hess uses. When you try to move your domain off of NS, they impose an arbitrary five-day delay, and offer you a 43% one-year discount (but still more than the competition) to stay. Of course each of these further steels my resolve to leave them.

I registered dingydangy.com with Gandi for my kids.

x86_64 AES assembly stinks, C blazes
In response to a problem at work where the new version of a program was running much slower than the released one, I looked at the performance of openssl doing AES on recent Intel x86_64. We had carefully ensured that SSL built using the hand-optimized x86_64 assembly version of the code. Imagine our surprise at finding that the C version runs twice as fast. I had tears from laughing.

How could this be? I interpreted it to mean that somebody at Intel made sure the compiler for x86 -> internal RISC (implemented in silicon) recognizes the instruction sequence generated by Gcc for AES, and pastes in its place a hand-coded sequence of internal operations. This means, in turn, that any new cipher that doesn't much resemble AES will be unfairly handicapped by running much more slowly on current Intel chips. It might mean that if Gcc were to improve its optimization to the point that the chip doesn't recognize the sequence it generates as AES, performance might drop by half or more. I wonder which chip version first got this optimization.

[Update: Or, it means that L1 cache alignment came out unlucky for the assembly code, in that particular build. Or something.]

They really should sell this thing as the "Friggin' Jetpack". No point in lowballing it, even though it is more like an adaptation of the Trek Aerospace "Solotrek" design than a proper jetpack.

Got a new camera, a Canon Powershot D10 that is supposed to work underwater. The manual says, "Playing back for a long time may cause feelings of discomfort." And regrets, for sure.

I have finally put my "socketpair for win32" (1, 2, 3) on github. That a bug turned up three years after initial posting suggests it is not, in fact, so trivial as I had originally said, and that perhaps, therefore, nothing in programming is. Or that nothing in interacting with an operating system is. Or anyway that nothing in interacting with a Microsoft operating system is. But probably the first is right.

Just shy of three years ago I posted a Free implementation of socketpair for Win32. Today I added a bugfix, connected with Windows System Error 10049 "Event ID 4226 TCP/IP has reached the security limit imposed on the number of concurrent TCP connect attempts."

For a couple of weeks, totem 2.28.5 on Debian has been crashing with SIGSEGV at startup with a message "Invalid column number 6 added to iter (remember to end your list of columns with a -1)". Traceback says this comes from a bad call to strlen, from somewhere under totem_action_set_mrl_with_warning. To fix it, I manually updated totem-common from 2.28.1-1 to 2.28.5-1.