Older blog entries for ncm (starting at number 395)

21 Apr 2010 (updated 21 Apr 2010 at 04:39 UTC) »

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.

18 Mar 2010 (updated 7 Apr 2010 at 23:48 UTC) »
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.]

10 Mar 2010 (updated 10 Mar 2010 at 02:12 UTC) »

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.

10 Feb 2010 (updated 10 Feb 2010 at 20:36 UTC) »
redi, IlyaM: Ilya, your reaction to the C++ code you saw may (pace Jon) be right. There are heaps, mountains, planets of bad C++ code out there. Most of it probably comes from former (and current) Windows coders and Java coders. It's no harder to write good C++ code than good C code, but they seem disinclined to do it, or don't know how. C presents fewer temptations to bad coding than C++, but fewer tools to write powerful code. When you find a C++ library packed with virtual interfaces, "get" and "set" members, redundant constructors, and operator overloads, what you're seeing is probably just the product of procrastination.

A month ago I quit drinking (green) tea. Now my ADD is gone. I started twelve years ago because I was persuaded that it was "good for me". If you don't have ADD, dropping caffeine might not do you much good. If you do have ADD, have you tried that?

From an exchange on LWN:

... transforms your PHP source code into highly optimized C++ ... PHP->Scheme or PHP->Lisp ... would be seen as ... impossible to use in "real life" ... would be seen as very, very funny -- particularly by Lisp fans ... Roadsend PHP Compiler [is] doing (php -> scheme (bigloo) -> c)

Lisp comedy -- it writes itself.

386 older entries...

New Advogato Features

New HTML Parser: The long-awaited libxml2 based HTML parser code is live. It needs further work but already handles most markup better than the original parser.

Keep up with the latest Advogato features by reading the Advogato status blog.

If you're a C programmer with some spare time, take a look at the mod_virgule project page and help us with one of the tasks on the ToDo list!