Older blog entries for ncm (starting at number 406)

12 Sep 2010 (updated 12 Sep 2010 at 06:22 UTC) »

Today was the day to remember the United States has announced itself cowards before all the world. Will we ever regain our pride? Not until the last torturing murderer protected by the Pentagon is in chains.

10 Sep 2010 (updated 10 Sep 2010 at 03:26 UTC) »

Who says sociology doesn't have anything useful to offer? This paper, L-worlds: The curious preference for low quality and its norms, by Diego Gambetta and Gloria Origgi, explains so much about so much that the world will never look the same. It explains why offering good free software to people used to expensive bad software just irritates them. It explains why well-reasoned discussion isn't welcome in blog comments. It explains Safeway supermarkets, American cars, and television.

I'm still trying to get this Dell E6510 with integratedIntel Arrandale graphics working. Lately it's been overheating, although I don't know whether to blame linux or Dell. During a long kernel build, it hovers around 101C (spiking over 105, with emergency shutdown) in an X terminal, but around only 75 C without X. Starting a compile jumps the temperature by 18K in a couple of seconds, and stopping drops it by 20K in about the same time.

More mysteriously, the Synaptics touchpad doesn't show up as anything but a PS/2 mouse, so edge scrolling etc. doesn't work. Lots of workarounds are offered all over the web, but none of them help.

To everyone upset about Oracle going on a Java litigation rampage, I have only one thing to say: you had plenty of warning. So, I just laugh. Next, let's see what happens with Mono.

Incidentally, the Ekiga web page, uproariously, recommends installing OSS 4 in order to get it working. Um, no thanks. I won't be installing BeOS either.

8 Aug 2010 (updated 8 Aug 2010 at 07:12 UTC) »

Got the intel "Centrino Advanced-N" 6200 wifi working on this Dell. That meant downloading a "firmware" archive, iwlwifi-6000-ucode-, from Intel's site, and dumping iwlwifi-6000-4.ucode into /lib/firmware. ("apt-get install firmware iwlwifi" might do the job, but that has version 9.193.) I also had to run "rfkill unblock all", and make sure the rfkill switch was off. ("rfkill list" helped.) Astonishingly, somebody actually thought it would be a good idea for the wifi connectivity light on the keyboard to flicker whenever net activity happens, i.e. all the damn time. To fix it, I had to create a file /etc/modprobe.d/iwlcore.conf containing "options iwlcore led_code=1". Now it's just on, steady, when wlan0 is up. Seems like a good default to add to module-init-tools.

I tried setting up pulse-audio on another (intel HDA) box. The process was distressingly similar to the last time, two years ago, e.g. manually editing /etc/asound.conf. Results seem a little more successful than last time, but I made the mistake of trying to use Ekiga to test it. Ekiga appears to be too buggy, still, for the results to mean anything.

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">
        <edit name="autohint" mode="assign">
        <edit name="antialias" mode="assign">
        <edit name="hinting" mode="assign">
        <edit name="hintstyle" mode="assign">
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:
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, and maybe even, 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 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.]

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