Older blog entries for ncm (starting at number 402)

5 Aug 2010 (updated 5 Aug 2010 at 07:14 UTC) »

The Inconsolata typeface looks incomparably better in Emacs with "slight" hinting, but other faces, particularly Linux Libertine O, which I use everywhere that I don't want a monospace face, really needs hinting. What to do? I added


    <match target="font">
        <test compare="eq" name="family">
           <string>Inconsolata</string>
           </test>
        <edit name="autohint" mode="assign">
            <bool>false</bool></edit>
        <edit name="antialias" mode="assign">
            <bool>true</bool></edit>
        <edit name="hinting" mode="assign">
            <bool>true</bool></edit>
        <edit name="hintstyle" mode="assign">
            <const>hintslight</const></edit>
    </match>
to my /etc/fonts/local.conf, and then set Gnome's hinting back to "full", and then cycled Emacs through a font change so it would pick up the new setting. That worked for Emacs, but not for gnome-terminal. Apparently Gnome programs make gnome-appearance-properties settings override fontconfig settings. There's a bug filed about that over at Canonical, not that anything's been done about it:
https://bugs.launchpad.net/ubuntu/+source/fontconfig/+bug/161058
You may recognize from there where I got the code above.

At least Emacs and my Linux Libertine text look good. I have given up and switched to Deja Vu Mono for my terminals.

5 Aug 2010 (updated 5 Aug 2010 at 03:46 UTC) »

A watershed day: I've been using the 6x13 ("fixed") typeface in Emacs, as in xterm, since 1988, and have just switched to Inconsolata 9. (Thanks, Raph!) The final obstruction fell when I discovered that Inconsolata looks phenomenally better with "slight" hinting (set using gnome-appearance-properties). Inconsolata is a little bit less dense vertically -- I fit 82 lines on this screen, where 6x13 fit 88 -- but the width is almost identical. The alternatives to Inconsolata, like Vera Sans Mono and Liberation Mono, waste far too much space to be usable.

Speaking of typefaces, Linux Libertine is so overwhelmingly better looking than everything else, I'm astonished it's not been adopted as the default face on all distros. ("apt-get install ttf-linux-libertine") I have jimmied my fontconfig to substitute it for every face used in every web page, serif or not. If you can tolerate sans-serif text fonts, Biolinum is equally well done.

Xorg on a Dell Latitude E6510 with Arrandale video, using i915 kernel drm, still doesn't work right, but with released Linux 2.6.35 it's better than it was. I have a few patches that, e.g., make it come back after it blanks the screen for inactivity. To unblank it after suspend/resume, I still have to plug and unplug an external monitor. Thanks to Jesse, Chris, and Dave for hammering away at this. There's a fair chance that 2.6.35.2, and maybe even 2.6.32.18, will work well enough to be usable by normal people. Maybe released Squeeze will even work out of the box on it, instead of panicking.

29 Jul 2010 (updated 30 Jul 2010 at 02:08 UTC) »

I just installed a Debian GNU/Linux Squeeze snapshot on a Dell e6510 with an intel i5-520M and integrated intel graphic adapter. The experience took me back to the early '90s. The installer tried to put Grub2 in the MBR and failed. It tried Grub 1 and that failed too. It put in LILO, successfully. Then, putting in Grub 2 worked. Starting X locked up the machine, hard. It turns out that the i915 driver in current released kernels is busted. Booting with i915.modeset=0 keeps it from locking up, but leaves a black screen; setting the driver to "vesa" lets it start up to a desktop. The 2.6.35-rc6 kernel on experimental has a fix for i915, but apt won't install it. Building that kernel from sources worked, with full-screen stellarium running about 23 frames/s (vs. 0.3 without). I haven't tried the intel 6200 wireless yet.

This E6510 is prone to announcing that the CPU fan has failed, during startup and setup intervals, but allows you to continue. Suspend works, but resume doesn't; after resume, you can ssh in, but the screen stays black, even in text consoles. Looks like I'll be sticking with VESA for X. Again. In text consoles, it buzzes when it's supposed to beep, and you can't turn it off by any means I have discovered. (Blacklisting the pcspkr driver doesn't do it.)

22 Jul 2010 (updated 22 Jul 2010 at 08:02 UTC) »

Avery Pennarun enlarged on his previous posting I criticized as wrong in almost every detail, yet not far wrong in its conclusion. This time he does much better, but in identifying what he considers essential in a language to replace C++, he mostly identifies features of C++0xA, the new ISO C++ standard. In other words, the closest possible practical approximation to his ideal replacement for present C++ is ... C++. One howler, though, is his remark that any replacement for C must be "as fast as C". This is a common mistake among slow-language promoters, which sets a low bar; it really needs to be substantially faster than C -- as, indeed, C++ is. Another howler is that he doesn't seem to know about Algol 68 and its notion of pointers.

I've come to realize that in every sense that matters, "high level language" always really means "slow language". Once you trade off speed, there's no excuse for not being utterly superb in every other way. Every imperfection and quirk becomes absolutely indefensible. Yet, every slow language I know of is riddled with weird quirks from top to bottom.

(Following up from redi about Avery's anti-C++ rant and my earlier response...) On re-examination, I find Avery is wrong in practically every detail, most probably because he started out and still lives in the world before there was a Standard C++.

Redi already noted that the Return Value Optimization (RVO) doesn't depend on inlining, and that Avery's example doesn't depend on the RVO anyway. I will add that RVO is implemented in every extant compiler, so you should think of it as a regular language feature.

Avery complains vaguely about C++ exceptions, but C++ is the only language where exceptions actually work. That's because C++ is the only language that has real destructors. Other languages need a "finally" construct, which obliterates most of the potential benefit of exceptions.

Everything Avery complains about in std::string is a feature; i.e. it has 99 problems, but Avery's ain't them. If you find yourself making a string class, you're wasting somebody's time. If your function would be just as happy with a const char*, then make it take a const char*. I don't make my own string types; I use either std::string or char*, and one or the other always does the job.

Avery's complaints about function pointers are just weird. In most places where you would have used a function pointer in C, you want a virtual function in C++. That's close to the only place where virtual functions are actually useful (which makes it criminally idiotic that virtual functions are the default in Java, but I digress). Most people don't find it immediately obvious how virtual functions fill in for function pointers without looking at actual examples. Now that you know, though, you can look for yourself.

So, if in all of Avery's examples he's wrong, where is he right? He's right that C++ code cannot be made as pretty as code in a slow language, and that it's a mistake to try. C++ code is always going to look kind of clunky. The knack is to know which kinds of clunkiness are essential, and which are your fault because you didn't think clearly about what you are doing. If you find yourself overloading operator[] or fooling around with exotic function pointers, it's probably the latter. Coding good C++ is a lot like chess; ask yourself, "does this line help solve an actual problem?" If not, it's likely to be procrastination, or over-engineering, or wankage. It's not to C++'s credit that you have to ask yourself that, but no language deserves the blame for your own dilatory impulses.

What sucks most is that there is no useful and pretty language as powerful as C++, and none being worked on, so those of us doing hard things will depend on C++ indefinitely. Other, slow languages will come and go and be used for easy problems, as Bram's Law predicts.

20 Jul 2010 (updated 20 Jul 2010 at 07:13 UTC) »

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.]

24 Jun 2010 (updated 24 Jun 2010 at 08:31 UTC) »

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.

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.]

393 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!