lowvolume

The lower-post-volume people behind the software in Debian. (List of feeds.)

As inauguration approaches, speculation has been heating up about Obama’s pick for the newly-created position of CTO. Most of the names floated — Eric Schmidt, Steve Ballmer, Jeff Bezos — just seem ridiculous (would you really leave being CEO of Google, Microsoft, or Amazon for a White House job?), but I’ve recently heard one name that’s gotten me excited: Princeton’s Ed Felten (blog).

Felten came to national prominence in 2000, when the music industry held a contest to see if anyone could break their “digital watermarking” technology. Felten and his team broke it and was about to publish a paper explaining how, when the recording industry threatened to sue him if he did.

Since then, he’s offered expert opinions on everything from Microsoft to voting machines and started the Center for Information Technology Policy at Princeton, which he directs, where he’s pushed for more government transparency. He has the incredibly rare combination of being an absolutely first-rate technologist while also being able to clearly explain all of the relevant policy implications. Like Science Advisor John Holdren, he’ll do a fantastic job representing the consensus of technical experts on every policy issue that comes his way.

Posted Wed, 07 Jan 2009 23:41:49 -0500 Tags: ?rss2email

Miguel de Icaza

Randy Edmonds pointed out in my previous post that FlashBang Studios's RaptorCopter is not the first or the only Unity3D/Mono-based game on the Apple AppStore.

I counted almost 40 apps on the AppStore based on Mono, from the thread here.

These are a few other games available today from the AppStore that are powered by Mono:

Downhill Bowling (5 stars), (screenshots and video).
Billiards.
SpacePig.
Age of Curling.
Dusktreaders.
X-Razer.
Tapball (video).
InvinciBall (video).
SlidePop.
FuguMaze.
Monkey Diving (video).
Ball-X (with the dash in the middle, or you wont find it).
FuguTilt.
Pizza Dash (you deliver pizzas in a car).
Debris (you do controlled demolitions).
Trash it!
Rotunda.
Asteroid Strike.
Crazy Snowboard (and 2.0).
Bubble Bang (video).
iStronaut Willy.
Bounce Pop.
Labyrinth 3D.
FuguBall.
SpaceRace (video).
iDrone.
Mars Explorer.

Word games:

Christmas spell.
Alpha Blocks: Brain Freeze.

Not really games, but cool hacks:

Moobox 3D, cute!
Widget Monkey.
Butterflies.
Dice 3D.
Night Divine.
Rainbow Day.
Zen of Snow and Zen of Snow 2.
Jingle Bells.
ArtiFISHal Life (3D Aquarium).
Leaves.
iFeathers.
Bobblehead Santa.

Posted Wed, 07 Jan 2009 16:31:00 -0500 Tags: ?gnome ?mono

Miguel de Icaza

Ben Laurie

Late last year the Google Security Team found a bug in OpenSSL that’s been there, well, forever. That is, nearly 10 years in OpenSSL and, I should think, for as long as SSLeay existed, too. This bug means that anyone can trivially fake DSA and ECDSA signatures, which is pretty damn serious. What’s even worse, numerous other packages copied (or independently invented) the same bug.

I’m not sure what to say about this, except to reiterate that it seems people just aren’t very good at writing or reviewing security-sensitive code. It seems to me that we need better static analysis tools to catch this kind of obvious error - and so I should bemoan, once more, that there’s really no-one working seriously on static analysis in the open source world, which is a great shame. I’ve even offered to pay real money to anyone (credible) that wants to work in this area, and still, nothing. The closed source tools aren’t that great, either - OpenSSL is using Coverity’s free-for-open-source service, and it gets a lot of false positives. And didn’t find this rather obvious (and, obviously staticly analysable) bug.

Oh, I should also say that we (that is, the OpenSSL Team) worked with oCERT for the first time on coordinating a response with other affected packages. It was a very easy and pleasant experience, I recommend them highly.

The Problems

The two obvious problems are

Putting cpumasks on the stack limits us to NR_CPUS around 128, and
The whack-a-mole attempts to fix the worst offenders is a losing game.

For better or worse, people want NR_CPUS 4096 in stock kernels today, and that number is only going to go up.

Unfortunately, our merge-surge development model makes whack-a-mole the obvious thing to do, but the results (creeping in largely unnoticed) have been between awkward and horrible. Here's some samples across that spectrum:

cpumask_t instead of struct cpumask. I gather that this is a relic from when cpus were represented by an unsigned long, even though now it's always a struct.
cpu_set/cpu_clear etc. are magic non-C creatures which modify their arguments through macro magic:
```
#define cpu_set(cpu, dst) __cpu_set((cpu), &(dst))
```

cpumask_of_cpu(cpu) looked like this:

#define cpumask_of_cpu(cpu)
(*({
        typeof(_unused_cpumask_arg_) m;
        if (sizeof(m) == sizeof(unsigned long)) {
                m.bits[0] = 1UL<<(cpu);
        } else {
                cpus_clear(m);
                cpu_set((cpu), m);
        }
        &m;
}))

Ignoring that this code has a silly optimization and could be better written, it's illegal since we hand the address of a going-out-of-scope local var. This is the code which got me looking at this mess to start with.

New "_nr" iterators and operators have been introducted to only go to up to nr_cpu_ids bits instead of all the way to NR_CPUS, and used where it seems necessary. (nr_cpu_ids is the actual cap of possible cpu numbers, calculated at boot).

Several macros contain implicit declarations in them, eg:

#define CPUMASK_ALLOC(m)        struct m _m, *m = &_m
...
#define node_to_cpumask_ptr(v, node)                                    \
                cpumask_t _##v = node_to_cpumask(node);                 \
                const cpumask_t *v = &_##v

#define node_to_cpumask_ptr_next(v, node)                               \
                          _##v = node_to_cpumask(node)

But eternal vigilance is required to ensure that someone doesn't add another cpumask to the stack, somewhere. This isn't going to happen.

The Goals

No measurable overhead for small CONFIG_NR_CPUS.
As little time and memory overhead for large CONFIG_NR_CPUS kernels booted on machined with small nr_cpu_ids.
APIs and conventions that reasonable hackers can follow who don't care about giant machines, without screwing up those machines.

The Solution

These days we avoid Big Bang changes where possible. So we need to introduce a parallel cpumask API and convert everything across, then get rid of the old one.

The first step is to introduce replacemenst for the cpus_* functions. The new ones start with cpumask_; making names longer is always a little painful, but it's now consistent. The few operators which started with cpumask_ already were converted in one swoop (they were rarely used). These new functions take (const) struct cpumask pointers, and may only operate on some number of bits (CONFIG_NR_CPUS if it's small, otherwise nr_cpu_ids). This replacement is fairly simple, but you have to watch for cases like this:
```
        for_each_cpu_mask(i, my_cpumask)
                ...
        if (i == NR_CPUS)
```
That final test should be "(i >= nr_cpu_ids)" to be safe now:
```
        for_each_cpu(i, &my_cpumask)
                ...
        if (i >= nr_cpu_ids)
```
The next step is to deprecate cpumask_t and NR_CPUS (CONFIG_NR_CPUS is now defined even for !SMP). These are minor annoyances but more importantly in a job this large and slow they mark where code needs to be inspected for conversion.
cpumask_var_t is introduced to replace cpumask_t definitions (except in function parameters and returns, that's always (const) struct cpumask *). This is just struct cpumask[1] for most people, and alloc_cpumask_var/free_cpumask_var do nothing. Otherwise, it's a pointer to a cpumask when CONFIG_CPUMASK_OFFSTACK=y.
alloc_cpumask_var currently allocates all CONFIG_NR_CPUS bits, and zeros any bits between nr_cpu_ids and NR_CPUS. This is because there are still some uses of the old cpu operators which could otherwise foul things up. It will be changed to do the minimal allocation as the transfer progresses.
New functions are added to avoid common needs for temporary cpumasks. The two most useful are for_each_cpu_and() (to iterate over the intersection of two cpumasks) and cpu_any_but() (to exclude one cpu from consideration).
Another new function added for similar reasons was work_on_cpu(). There was a growing idiom of temporarily setting the current thread's cpus_allowed to execute on a specific CPU. This not only requires a temporary cpumask, it is potentiall buggy since it races with userspace setting the cpumask on that thread.
to_cpumask() is provided to convert raw bitmaps to struct cpumask *. In some few cases, cpumask_var_t cannot serve because we can't allocate early enough or there's no good place (or I was too scared to try), and I wanted to get rid of all 'struct cpumask' declarations as we'll see in a moment.
Architectures which have no intention of setting CONFIG_CPUMASK_OFFSTACK need do very little. We should convert them eventually, but there's no real benefit other than cleanup and consistency.
I took the opportunity to centralize the cpu_online_map etc definitions, because we're obsoleting them anyway.
cpu_online_mask/cpu_possible_mask etc (the pointer versions of the cpu_online_map/cpu_possible_map they replace) are const. This means that the few cases where we really want to manipulate them, the new set_cpu_online()/set_cpu_possible() or init_cpu_online()/init_cpu_possible() should be used.
We will change 'struct cpumask' to be undefined for CONFIG_CPUMASK_OFFSTACK=y. This can only be done once all cpumask_t (ie. struct cpumask) declarations are removed, including globals and from structures. Most of these are a good idea anyway, but some are gratuitous. But this will instantly catch any attempt to use struct cpumask on the stack, or to copy it (the latter is dangerous since cpumask_var_t will not allocate the entire mask).

Conclusion

At this point, we will have code that doesn't suck, rules which can be enforced by the compiler, and the possibility of setting CONFIG_NR_CPUS to 16384 as the SGI guys really want.

Importantly, we are forced to audit all kinds of code. As always, some few were buggy, but more were unnecessarily ugly. With less review happening these days before code goes in, it's important that we strive to leave code we touch neater than when we found it.

Posted Tue, 06 Jan 2009 21:00:47 -0500 Tags: ?linux

Aaron Siego

I work with bugs.kde.org nearly every single day.

Most people who report bugs on it hardly ever visit it, and that's not a bad thing.

Some people who do end up there are frustrated due to some problem they ran into and so show up a little less than happy. Most are congenial, however, which is nice.

Unfortunately, there's still that familiarity gap. I have built up over the years a set of internal expectations around handling the bug system that I know are completely non-obvious to anyone who doesn't use bugs.kde.org often .. which is most of our reporters .. which leads to frustration. Everyone couple years I blog about this frustration. This one of those blogs.

Sometimes I honestly think a "bugs.kde.org driver's test" should be a prerequisite to using the system. It would go miles to improving the quality of the reports. In lieu of that, here are some quicky notes on handling bugs.kde.org:

Always include the version of KDE you are using. If you build from svn, then include the svn revision #. Otherwise, `kde4-config --version` is perfect.
If reporting a crash, provide a detailed description of what led to the crash. If reporting a functionality bug, describe the steps in detail needed to reproduce the problem. If you don't know, just describe as much as you can about what you or the machine was doing at the time. These descriptions help us replicate your experience which is critical to solving many reported problems.
If you are reporting a crash, always include a backtrace. If it has lots of "unknown symbols" in it, though, it's not likely to be very useful and your description of how to reproduce will be even more important. However, first consider reading this how-to on creating nice backtraces and get a realy good backtrace for the report.
Do not upload backtraces as attachments to reports! Instead paste them into a comment. This lets us easily search the database for similar backtraces. It's easy to search through comments in Bugzilla, not so much so through random attachments.
If the bug is rendering related, include what the graphics hardware and driver version is. It may not be relevant, but it often is and will save a "what's your graphics hardware?" roundtrip question.
If the bug has a visual manifestation (e.g. you can see the bug itself or symptoms of it somewhere on the screen) consider taking a screenshot of it and attaching it to the report. Screenshots are often very, very useful to understanding bug reports. Pictures and a thousand words and all that.
If you can't reproduce the bug after a while, let us know. That's useful information.
If we ask for more information, try and respond as soon as you can. Some bugs are easier to fix at certain times than others, for various reasons. Helping us by being attentive is much appreciated. If you can't get to it right away, or if you feel the answer you have isn't a good one (e.g. you tried what was requested, and nothing happened) still report back with either a "I'll get to it when I can" or "I tried it and got nothing useful back". At least this way we know you're still there.
Do not post to random bug reports unless your problem is the exact one in the original report. If you have a crash and your backtrace does not look identical at the top of it to the one in the report, do not add it to an existing report. If you have a similar sounding but not identical problem, do not add it to an existing report. File new reports. Bugzilla lets us merge reports, but it does not let us take a single comment and break it out into its own report. I wish it did, but it doesn't. Yes, this is a shortcoming in Bugzilla, but it's one we have to live with. This means that if you just pile in new bugs into old reports, we end up with reports that are completely unmanageable. Eventually, I just end up closing those kinds of ruined reports and make everyone file new ones.
Which leads to: one problem per report. Yes, Bugzilla is not the fastest tool to use and so it can be tempting to just pile in 2, 3, 5 or sometimes even more issues into the same report. Don't. It becomes very hard to track which issues are fixed and which aren't. Again, this is mostly due to shortcomings in Bugzilla, but it's the reality we deal with. File separate reports for separate issues; and yes, even if it's two different issues on the same topic.
Whenever you comment on a bug, the assignee(s) and the people on the CC list get an email with your comment in it ... even if the report is closed. So feel free to add comments to reports, someone somewhere will still get a notice of them.
Fixes will not appear immediately on your computer. You will need to wait until you update your installation to a version that contains that fix. Depending on when the fix is made and how you install KDE, this can even be many months time. This may sound like an obvious item, but many people seem rather surprised when I mark something as fixed with a commit to svn but the problem is still there on their computer.
Describe your problems thoroughly, but don't get too clever unless you've actually read the code. Way too often I get reports where the person has a pet theory about why something is happening and unfortunately the theory is dead wrong. At best it's just a waste of my time reading that part of the report, but more often it ends up confusing the report with some misinformation and worst case (which happens too often) the reporter gets so caught up in their idea of why the bug is happening that they end up describing that theoretical problem as opposed to what is actually happening. This risks confusing the bug triager, and often just means a long series of back and forth questions. If at all in doubt, just describe the problem as it manifests itself as thoroughly as possible. Leave the root-cause sleuthing to those with the code in front of them.
You don't have to suggest a solution. It is perfectly Ok to say "This doesn't work for me." and leave it at that. If there is a preferred way you'd like to see it happen, describe it in those terms: "I would prefer if ..". But as the reporter you don't have to come up with a solution.
I hate the term "wishlist" because it makes it sound like something you'd like to have but probably won't get. I far prefer the term "feature request" because that's what it really is, and "feature request" lacks all the implications of "wishlist". Some people get really annoyed when I mark their report as "wishlist" and in one sense I don't blame them; if you didn't know any better it might sound like your report has just been brushed off. That's not the case, however: if the request is for a new feature or new functionality, as opposed to fixing existing functionality, it's a feature request not a defect report.
Don't bother overstating the severity of your bug. It won't fool anyone. Seriously. =)
Don't bother linking to your favourite bug report from your blog, on web forums, on irc, etc hoping people will vote for it. When I see a bunch of people randomly showing up to vote on a report, I assume this is what has happened and ignore those votes. Such vote canvasing only distorts the statistical distribution of voting on bugs.kde.org and makes it impossible to distinguish between reports people actually, really want fixed and ones that someone has just done an effective job of campaigning for in online forums. In general, I put far more weight behind how many duplicates a report has than votes.
When it comes to feature requests, a judgment call is often required. That call belongs to the person(s) designing the software. If they decide against a feature, don't belabor the point by endlessly trying to convince them or getting angry with them. It doesn't help anything.
Saying thank-you even once makes up for 10 mistakes made elsewhere. It's really encouraging when a reporter is civil, cordial and says "thanks" when the fix goes in. Dealing with reports on bugzilla is, quite frankly, not the sexiest thing in the world to do, so anything that makes it go a little easier and nicer helps.

Probably not an exhaustive list, but there you go. Hopefully something in that list is useful to someone out there at some point in the future. =)

Posted Tue, 06 Jan 2009 14:53:00 -0500 Tags: ?kde

Aaron Siego

Earlier today Dirk sent a message to the release team and KDE core devel mailing lists noting that KDE 4.2 is now branched off of mainline and that the the first RC is being tagged. That means trunk is now what 4.3 will be.

As I've been reminded a few times already today myself, that means we need to backport bugfixes made to trunk that we want to appear in 4.2. The svnbackport script in kdesdk was updated today to backport to the new 4.2 branch and makes the process of backporting your last commit trivial.

The last few weeks leading up to a release are always exciting and nerve wracking for me. There are numerous details that always need to be worked out, though the project is getting better and not leaving things to the last minute. The promo team has been working on release materials since sometime in December, even. Hopefully that reduces the stress levels and burn out rates. =)

In a couple week's time it'll be full throttle on 4.3 ..

Posted Tue, 06 Jan 2009 14:47:00 -0500 Tags: ?kde

Ben Laurie

I’m pretty amused by this very successful appeal, which has put on buses all over England

Atheist bus advert

and I’m really impressed that they raised £135,000 (against a target of £5,500) to do it!

As an atheist humanist myself, I can only disagree with them in one respect: the use of the word “probably”. The website they’re reacting to, after all, doesn’t leave much room for doubt. They don’t say “You will probably be condemned to everlasting separation from God and then you might spend all eternity in torment in hell”, do they?

(via Boing Boing)

Where Do We Go From Here?

If you care about non-C++ languages and Plasma, come join us. We've already got a few Ruboids and Pythonistas hanging about on plasma-devel@kde.org and on #plasma writing Plasmoids, but we need more of you. JavaScripters with an itch to scratch should come join us, too. We need to kick the living crap out of these ScriptEngines and torture them in all sorts of ways, just as we have the C++ libplasma over the last year, and create cool things with them in the process. This way we can go from our first-cut ScriptEngines in 4.2 here to kick ass ones in 4.3.

We're willing, in fact desiring, to improve, modify and grow the ScriptEngines in response to usage. It's the best (some might say only) way, really. =)

I'll be announcing the documentation for the Basic JavaScript ScriptEngine when it's ready to go so you can all jump on it. The docs will come pre-4.2.0, so that you should be able to upgrade to KDE 4.2 and start hacking JavaScript with documentation in hand all in the same day without compiling any C++ on your own. Huzzah.

Posted Mon, 05 Jan 2009 20:53:00 -0500 Tags: ?kde

Damien Sandras

The first beta of Ekiga 3.1.0 is now available on GNOME FTP.

Please note that I started the development of Ekiga 9 years ago.

Here is the list of changes :

Added support for the G.722 audio codec: G.722 is a 16 kHz wideband audio codec advertised as HD Voice by the famous Polycom. It is a great boost in quality and interoperability.
Added support for the CELT ultral-low delay audio codec: CELT delivers high quality audio at 32 kHz or 48 kHz, allowing to transmit music in high quality, with low delay and low bitrate.
Added support for SIP dialog-info notifications: they allow displaying notifications of incoming calls in the roster. With software like kamailio or Asterisk, it allows being informed of incoming calls reaching your colleagues.
Largely improved LDAP support: the OpenLDAP guys contributed several patches to provide state-of-the-art LDAP support in the Ekiga address book. The new code even supports authentication.
Added support to disable STUN detection: some routers do not need it anymore as they implement NAT traversal for SIP.
Killed the gconf_test_age test: when GConf was released, Ekiga was among the first to adopt it. That annoying ‘gconf error’ was a relique of those early times.
More efficient memory handling using gmref_ptr.
Better handling of multiple network interfaces with dynamic addition and removal.
libgnome is not required anymore when using GTK+ 2.14.
Many code cleanups, new GObjects, …

The Ekiga developers team is also working on interesting new features that should be available after the 3.2 release :

XCAP support & Resource List support: It allows storing the contacts list on the Ekiga.net server.
GStreamer audio and video capture support.

Stay tuned for more news!

Thanks to all contributors and welcome to Eugen Dedu, our new release manager!

Posted Mon, 05 Jan 2009 16:44:48 -0500 Tags: ?ekiga

Josh Berkus

As of today, you have 2 weeks left to submit talk proposals to pgCon ...

Posted Mon, 05 Jan 2009 15:21:41 -0500 Tags: ?postgresql

Aaron Swartz

I grew up in Highland Park, Illinois, just down the street from where the telephone was invented. I now live in Cambridge, Massachusetts, just down the street from where it was stolen. Seth Shulman’s recent book The Telephone Gambit lays out the clearest case yet of how it all happened. Here’s the summary:

Alexander Graham Bell (or Aleck Bell, as he was then called) was the son of Alexander Melville Bell, the inventor of a system of phonic notation called Visible Speech. The elder Bell would use Aleck as an assistant in his demonstrations: After sending Aleck to wait in another room, Mr. Bell would ask the audience for a word or strange noise then write it in Visible Speech. Aleck would return and reproduce the sound from the writing alone. Voila.

As a child growing up like this, he played at inventing machines that could talk and telegraphs that could listen. But he found his career in tutoring the deaf — by teaching them to pronounce the phonemes of Visible Speech, he eventually succeeded in teaching them to talk and read lips.

One of his students was Mabel Hubbard, daughter of prominent Boston lawyer Gardiner Greene Hubbard. Son of a Massachusetts Supreme Court Justice, Hubbard established water and gas and trolley utilities for Cambridge, Mass. — some of the first in the nation. He also fervently lobbied Congress to replace Western Union’s monopoly on the telegraph with a new corporation, the US Postal Telegraph Company, that would contract with the government Post Office.

At the time, telegraph wires blanketed the skies of Boston, hanging in a dense web above the buildings. Many desperately wished for someone to develop a telegraph that could send multiple messages over the same wire, so that many wires could be replaced with just one. The theory was that if one could transmit the messages using different tones, they would “harmonize” instead of interfere, leading the idea to be called the “harmonic telegraph”. Naturally, Alexander Graham Bell turned his tinkering to this problem and persuaded Hubbard (as well as Thomas Sanders, another father of a Bell student) to finance his research in exchange for a share of any future US profits. Further complicating matters, Bell had fallen in love with his student, Mabel Hubbard. Mr. Hubbard made it clear he did not approve of such a marriage unless Bell made a profitable discovery.

But Bell was simply a hobbyist, the real research was being done by a man named Elisha Gray. Gray ran Western Electric, the leading supplier of technical expertise to telegraph monopoly Western Union. From his lab in Highland Park, Illinois, he and his assistants worked feverishly at new discoveries. Bell was well aware of this and considered himself to be in a race with Gray to invent the harmonic telegraph first.

In 1875, Bell made a breakthrough in his work on the harmonic telegraph. But he was a crafty fellow — his deal with Gardiner and Sanders was only about splitting US profits; it said nothing about profits overseas. British law at the time granted patents only to inventions not patented elsewhere first, so Bell drew up several copies of his harmonic telegraph patent and sent some to be filed in Britain first. The rest were sent to DC to be filed as soon as word got back from Britain.

On February 14, 1876, while the lawyers were waiting in DC to file Bell’s patent, Gray filed a patent of his own. Bell’s lawyers were close to the patent officers and had asked to be tipped off if Gray tried to file something, so they could file Bell’s patent first. When Gray’s patent was placed in the patent office’s inbox, Bell’s lawyers hand-delivered Bell’s patent to the examiner, so they could claim he’d received Bell’s first.

The patent examiner, Zenas Fisk Wilber, had fought in the civil war with Bell’s attorney, Marcellus Bailey. Wilber was an alcoholic and owed Bailey money (a serious Patent Office ethics violation). To pay his friend back, he showed him Gray’s application. Bailey was startled to find it wasn’t a patent on a harmonic telegraph at all — it was a patent for a telephone, capable of transmitting all the sounds of human speech and music. He called for Bell to come to DC at once.

Bell did, and examiner Wilber showed him Gray’s patent as well, taking time to explain how it worked. Bell thanked him and returned that afternoon with $100 for his trouble. Bell then quickly scribbled an addition to his patent in the margin, adding that it should also cover “transmitting vocal or other sounds telegraphically” (this addition does not appear in any of the other copies).

Contravening much standard practice at the time, Bell’s (modified) patent was quickly granted, while Gray’s was denied. It was issued the same day Bell returned home from DC, March 7, 1876. The following day, Bell drew in his lab notebook a copy of the diagram he had seen in Elisha Gray’s patent:

Diagram showing the similarity between Gray's patent and Bell's notebook

It took Bell several days of tinkering, but soon he was able to replicate Gray’s device. On March 10, he made that now-famous call: “Watson — come here — I want to see you.” Both Bell and his assistant Watson recorded the event that night in their notebooks.

But Bell didn’t want to simply duplicate Gray’s work; he wanted to invent a telephone of his own. He spent many months trying to develop a telephone that worked on a different principle, but never succeeded in getting it to clearly transmit audible speech. Bell was always extraordinarily reluctant to demonstrate his telephone, for fear that Gray would learn it was a simple copy. Mabel had to trick him into attending the Centennial Exposition, where he was supposed to demonstrate his work to a group of engineers, including Elisha Gray. On one occasion, Bell’s telephone patent was set to be annulled unless Bell would swear under oath that the invention was truly his. Bell fled the country, testifying only at the last minute after desperate pleading from Mabel.

The legal conniving a success, Bell and Mabel were soon married. Feeling guilty, Bell gave all but ten of his shares in the Bell Telephone Company to her and swore to never work in telephony again. The company was operated by Gardiner and others while Bell went back to working with the deaf. He always said he was more proud of his work for the deaf than of the telephone.

It took Gray a long time to realize that Bell’s patent was a fraud. For one thing, he was still focused on the harmonic telegraph; his customers at Western Union couldn’t imagine running telephone wires to every house and thus couldn’t see how talking over wires was particularly useful. For another, it took years for the story to leak out, through numerous court battles and Congressional hearings. Zenas Fisk Wilber’s affidavit confessing to what he’d done did not appear until 1886, a decade later. Bell’s notebooks, making clear the blatant copy, were not made public until the 1990s.

Bell’s biographers have gone to heroic lengths to explain away all the evidence. Refusing credit for the telephone just showed Bell’s humility; not being involved in the corporation showed his dedication to pure research. The fact that both patents were filed on the same day is a grand historic coincidence — or perhaps Gray stole the idea from Bell.

As a result, Gray is forgotten and Bell is remembered as one of history’s great inventors — not as he should be: a hobbyist and a fraud, forced by love into stealing one of the greatest inventions of all time.

Now playing: Regina Spector - “On The Radio”

Posted Mon, 05 Jan 2009 13:22:49 -0500 Tags: ?rss2email

Josh Berkus

First off, before I get started on some more guidelines for writing maintainable queries, Regina and Leo already wrote about Part I ...

Posted Mon, 05 Jan 2009 09:05:00 -0500 Tags: ?postgresql

Ben Laurie

I cooked a snack this afternoon, crab and sweetcorn soup, a classic dish which I always cook from the fantastic book “Chinese Cookery” by Ken Hom. As we ate it my older son, who is home from university for a few weeks, complained yet again that you can’t get the book anymore. So, I decided to have a look to see if I could find a secondhand copy. To my amazement it is in print again, as of a few days ago, and you can get it for about a tenner from Amazon!

Of all Ken Hom’s books this is my favourite - great food with simple recipes that actually work, and can be achieved without too many specialist ingredients or tools. My own copy is in three pieces it has been used so much.

Share This

Posted Sun, 04 Jan 2009 13:39:55 -0500 Tags: ?openssl

Aaron Siego

Perusing through the Plasmasphere as 4.2 looms seeing what needs attention, I had my gaze drawn towards the JavaScript ScriptEngine by Chani. The everything-and-the-kitchen-sink JavaScript API is still in playground, so that won't be there until 4.3, but the basic API was there in kdebase and it generally worked. For certain values of worked. There was much left to be desired.

We've added a number of things to it to get it into shape and feature complete in time for 4.2 so people can actually start using it. It's pretty rewarding to see how fast and general painless working with QtScript can be.

Perhaps just as important, I've also begun documenting the API. Miracle of miracles, documentation!

The Simple JavaScript API will be shipped as "unstable" in 4.2, meaning that I may make changes to it in 4.3. This will allow those of us who care about these things to work with people who would like to use such things and round off the corners between now and 4.3. This is much like how we didn't provide binary compatibility guarantees for libplasma until KDE 4.2. At least with things like JavaScript, it's a lot more flexible. =)

However, I am not a skilled JavaScript developer. I don't work with JavaScript day in, day out and so I'm not familiar with which idioms would make the most sense to those who do. For instance, today I run into this simple question: Is it more "natural feeling" in JavaScript to have onFormFactorChanged or formFactorChanged? I know that the former is used in web page APIs (onClick, onLoad, etc.) and that the latter is a bit more C++ (though even there we do it slightly differently, which a constraintsEvent method that gets a set of or'd flags). Right now I'm going with the onFormFactionChanged style, but that's purely a naive gut-feeling-and-a-little-knowledge-of-JavaScriptbased choice.

So if you are someone who works with JavaScript a lot, please find me on irc.freenode.net in #plasma and let's talk. I have questions, you probably have answers. My timezone is GMT-7, so keep that in consideration if you try and track me down.

Also, we'll be looking for people who would like to do simple to medium complexity Plasmoids in JavaScript once 4.2.0 is out. You'll be our guinea pigs and if you do your work alongside us in #plasma you'll have the chance to help improve the Basic JavaScript API and even test the Advanced version when it becomes available.

Posted Sun, 04 Jan 2009 00:35:00 -0500 Tags: ?kde

Harald Welte

So today I arrived in South Korea, after a one day stop-over in Taipei (following a flight connecting in Abu Dhabi). I've arrived at about 6pm local time and had a 90minute bus ride to the hotel in Yongtong-gong. So besides check-in and a quick stop at the convenience store, I didn't yet do much.

Some first impressions, in no particular order:

Heating like crazy. This first occurred to me in the airport, but became more of an issue in the bus. I was actually sweating with my long-sleeved shirt, without any jacket. The hotel has a default temperature of 28 degrees Celsius, not only in the lobby but in every room. you can adjust it, but as soon as you leave the room, it resets to 28. So the setting is not very useful, considering that a floor based heating has a very high latency, since the entire floor tiles are heated up and dissipate heat even hours after adjusting the temperature.
The hotel clerk asked me in the elevator what kind of power plug my laptop had, and if I needed any kind of adaptor. Furthermore, he actually showed me the LAN cable and indicated "IP address automatic"
After a first try, that automatic IP address is actually a public IPv4 address. Wasn't there something about IP addresses running out in Asia? Weird, but definitely very welcome! Traceroute indicates all intermediate routers in Korea don't have any reverse lookup. Even more weird
The hotel room has flat screen plasma TV and a PC (running Windows, so I just disconnected the screen and run it in multi-head. Interestingly, the VGA and audio inputs of the plasma TV are connected with the PC at the desk, so you can play back video from the Internet or DVD's on your plasma TV. That's way better than crappy pay-TV in western countries
Samsung is apparently so big, that they have a dedicated bus stopping at this hotel, taking people to the company twice every morning. A sign in every hotel room indicates this fact
I totally love the sound of the language. To me, it actually sounds even better than Japanese.

So I remain thrilled what happens next. Not sure how much time I will have during the week, depends how busy it is at work.

Posted Sat, 03 Jan 2009 20:00:00 -0500 Tags: ?iptables ?linux

Aaron Swartz

Previously: 2007 Review of Books, Books I recommend Without Reservation: 2006

I read exactly 100 books this year. I mistakenly told someone over the summer that I read a hundred books a year (I only read 70 last year, although 120 the year before that) and as the new year approached I felt duty-bound to make that true. (This led to spending a lot of New Year’s Eve in a corner reading, as this list may suggest.)

Here are the books (in chronological order), with occasional short comments. Books I’m happy to have read are linked. Books I recommend are in bold.

Quantum Theory: A Very Short Introduction. Seemed decent for the format.
Gecan, Going Public
The Activist’s Handbook. Could be better written, but probably the best of its type. I’ve definitely thought back to this one a lot this year.
Poundstone, How Would You Move Mount Fuji?
Poundstone, Labyrinths of Reason
Lodge, Changing Places.

Typical campus novel fun, but with some great People’s Park stories.
Elster, Political Psychology. Short Elster essay collection. Probably for Elster fans only.
Lords of Poverty (skipped parts)
On Being Nonprofit. Completely unmemorable.
How to Do Things with Words. Important in its time, but mostly overtaken by Searle’s later work.
The Revolution Will Not Be Televised
Campaign Finance Reform and the Future of the Democratic Party
The Visible Hand.

Tough sledding, but important points. Read my summary.
Thaler, The Winner’s Curse
Poundstone, Fortune’s Formula

Fantastic fun. Math, mafiosi, movies.
Freeman, Rawls (parts)
MacKenzie, An Engine Not a Camera.

I recommend starting with his LRB stuff.
Fitch, Solidarity for Sale. For leftists who really love unions. You need to know the flaws to make them better.
Maisel, From Obscurity to Oblivion: Running in the Congressional Primary. Not a lot of books on the inside of campaigns, but this is one of the few.
Segaran, Programming Collective Intelligence. Terrible title, but a good book on how to do data mining.
Willis, Learning to Labor. Not as great as the excerpts I’d read had led me to think.
The Brain: A Very Short Introduction
Peck, Hatchet Jobs. Fun stuff.
Sloan, My Years with General Motors (skipped second half). I read this to understand how modern management was invented. It did not help.
Hoopes, False Prophets

A wonderful series of profiles of the most prominent management theorists going back to slavery and Taylor. The book’s editorial line is a bit marred by the inability of the author (a B-School prof and manager) to reconcile his belief that management power is unjust and that it is necessary. But solid history and good takedowns of some important figures.
Dani Rodrik, Has Globalization Gone Too Far? (lent by Henry Farrell). A good book, but not for general readers.
A Random Walk Down Wall Street. Mixed feelings.
Wilson, To The Finland Station.

Really, really good. Edmund Wilson was the incredible writer you’d expect and this is his masterpiece.
Maurer, The Big Con: The Story of the Confidence Man

Luc Sante’s intro alone is worth the price of the book, but the rest of the book is fantastic as well. Everyone should know about con men. (The BBC’s Hustle is obviously a television adaptation of the book.)
A Choice Not an Echo: The Inside Story of How American Presidents Are Chosen. Still crazy after all these years, although the whole anti-backroom thing is interesting. I read it to see what you could airdrop on college kids.
Khurana, Searching for a Corporate Savior

Really, truly great.
Is That a Politician in Your Pocket? (skimmed)
Debunking Economics. Quite good, although not perfect.
Men and Women of the Corporation.
Carlson, Executive Behavior. Worthless
Elster, Explaining Social Behavior

Magical, magisterial masterpiece. (my review; more on Elster)
Piven, Challenging Authority. Kind of thin; I glazed over portions.
Rosen, The World Split Open
Mary Douglas, How Institutions Think. Terrible.
From the Folks Who Brought You the Weekend
Nuts and Bolts for the Social Sciences
Brook, The Trap
Gessen, All the Sad Young Literary Men
Khurana, From Higher Aims to Hired Hands
Glymour, The Mind’s Arrows
Pearl, Causality. I wish everyone understood this.
Elster, Strong Feelings
Gelman et. al., Red State, Blue State, Rich State, Poor State (sent by Andrew Gelman). Lots of great empirical work, but little theory or story to back it up.
Lodge, Nice Work

Typical campus novel fun, but with deeper thoughts about business and finance.
Armstrong and Moulitsas, Crashing the Gate
Menand, American Studies
Galbraith, The Predator State

My summary.
Watchmen

Brilliant. Wanted to see it before the movie came out.
Tilly, Big Structures, Large Processes, Huge Comparisons
Mann, Sources of Social Power, Vol. 1

Tough reading, but really fascinating stuff.
Frank, The Wrecking Crew. Lots of good dirt, but not exactly the most rigorous theoretical argument.
Perry, Spectrum. Perry is great — the autoinvestigatorial last chapter alone is worth it.
Bearman et. al., Doormen. I read this because I now have a doorman and am uncomfortable about it. This helped.
Teles, Rise of the Conservative Legal Movement. Good stuff, although narrow.
DFW, McCain’s Promise. Brilliant, naturally. I’d read Up, Simba! before, of course, but I read this out loud to a friend and it was just a joy to do.
Ken Silverstein, Turkmeniscam.

Great fun. Not just a great story of investigative journalism, but lots of interesting and important background as well. I’m a huge Silverstein fan.
DFW, Everything and More.

This book is an interesting, but, I think, ultimately unsuccessful experiment. DFW tries to teach math by channelling his favorite math teacher — writing in the style of an excitable lecturer, completely with verbal tics and backtracking (which, in printed form, becomes kind of a running gag).

It’s certainly not a bad book by any means, but I don’t think it’s really a successful model for how books can teach math.
Wodehouse, Psmith in the City. Hilarious. Psmith is a delight. I want to hear him acted but the recent BBC version is dreadful.
Clark, Organizing Our Marvellous Neighbours (skimmed parts)
How Wikipedia Works (skimmed parts)
Latour and Woolgar, Laboratory Life. Delightful. I apologize humbly and abjectly for ever criticizing the strong programme of science. Sokal and Bricmont led me badly astray on that one.
DFW, Consider the Lobster

DFW’s suicide hit me very hard. I ended up coping by reading every piece of nonfiction he’d ever published. He was a brilliant, tortured man and I see so much of myself in him. His nonfiction was fantastic and I will consider my life a success if I can do half of what he did.

If you want to get started, I recommend (best work first):
1. Federer as Religious Experience [B/W PDF]
2. “David Lynch Keeps His Head”, in A Supposedly Fun Thing I’ll Never Do Again (there’s a severely abbreviated version printed in Premiere; read the real thing instead)
3. “A Supposedly Fun Thing I’ll Never Do Again”, in A Supposedly Fun Thing I’ll Never Do Again (the Harper’s version [PDF] preserves most of the good stuff but is shorter)
Krugman, Peddling Prosperity

Probably Krugman’s best book, it provides a throughly enjoyable and enlightening intellectual overview of the economics of the 1980s and 1990s. The delicious takedown of supplysiders is worth the book alone, but the rest is great too.
Tough, Whatever It Takes. A great read; a bit overly credulous — doesn’t address Keynesian critics of intervention or betray much skepticism about tests. (my review)
Wolfe, Radical Chic and Mau-Mauing the Flak Catchers. Great fun.
The Homework Myth. Sometimes it seems like Kohn just gets narrower and narrower (via email, he disputes this).
Savage Mules. A good antidote for faith in the Democratic Party. (dsquared’s review)
Beam, Great Idea at the Time. A fun historical take down of the Great Books. Probably more fun if you know what the Great Books are.
A Brief History of Neoliberalism. Borderline unreadable. Why did everyone rave about this book?
Love at Goon Park.

The first section is a (confessed!) retread of Becoming Attached, one of my very favorite books (a 2006 highlight). But after that it gets much better and the interplay of animal and human stories is a lot of fun. I’ve been reading it to the five-year-old, who loves animal stories of all sorts, and she just laps it up. (I skip the incredibly dark parts, of course.)
Newsweek, Secrets of the 2008 Campaign (full text online). For campaign junkies only.
Perlstein, Tested.

Very good. (my review)
Keynes, Economic Consequences of the Peace (full text online).

Wow, Keynes knows how to write. The first section is a must-read for any diplomat. Chapters 4 and 5 (which unfortunately are the bulk of the book) are only worth skipping or skimming for modern readers.
Kaufman, Synecdoche, New York (scripts). What a movie! There were a lot of script reviews that said things along the lines of “I don’t know if movies can capture a script this complex.” Reading the script now, you see the exact opposite is the case. The script is a pale imitation of the film, missing most of what made the film magical. Which just underscores what a great movie it was.
Bowles and Gintis, Schooling in Capitalist America.

Not the easiest read, but brilliant. One of the very very few books I want to read again (in this case, because I am sure I didn’t get it all the first time). The definitive Marxist take on education.
Smile When You’re Lying

Tons of fun. I hate traveling and have never cracked a travel book, but this angry and profane insider’s evisceration of the industry was still a complete joy. Read Ezra’s review — with a comment from the author!.
DFW, A Supposedly Fun Thing I’ll Never Do Again.

Brilliant. Just brilliant.
Keynes, Essays in Persuasion.
Douthat, Privilege (lent by Rick Perlstein).

What is wrong with Ross Douthat? This book is eminently mockable, but I have to say I could see writing most of it myself. Which is weird, since Douthat is a staunch conservative and I’m a crazy-far-leftist. Is Douthat a double-agent? Or is he really this confused about what conservatism is about? I wrote this summary for Rick:
- Prologue: Harvard is actually an education in the ruling class. [Ross didn’t like Harvard so much.]
- 1: Diversity policies ensure all sorts of ethnicities get accepted but they all come from the upper class. [Big black homeless guy starts living in Ross’s dorm.]
- 2: The real ruling class gets tapped for private clubs where they get connected to wealthy alumni and rape attractive coeds. [Ross gets invited to apply at various clubs and rejected.]
- 3: Students are aggressive social climbers, calibrating who they talk to and what activities they join to maximize their resume. [Ross’s friend’s friend gets arrested for embezzling.]
- 4: Persuaded that the market is God and academia is a sideshow, professors give students easy grades to help them get good jobs and be rich (thus proving the professors’ worth). Courses are poorly taught and maddeningly specific — its very difficult to get a solid general education. [Ross doesn’t like his classes and gets mediocre grades.]
- 5: Random drunken hookups are so common that the only way to get any kind of commitment is to fall into a college marriage (of which, I must say, there is a beautiful description pp. 145-147). [Ross falls head-over-heels for a totally agonizing tease, only to have her give it up months later to a preppy sailing kid who gets her drunk.]
- 6: Most harvard students arrive virgins and have a hards time getting any while they’re there, out of awkwardness and fear of threatening their spot in the overclass. [Ross can’t even get laid at an all-girls school.]
- 7: The student body is primarily New Democrat, with a smattering of vocal leftist protestors. [Ross supports the living wage movement. [ed. note: wtf?]]
- 8: Harvard students spend summers at elite internships acclimating to their future careers. [Ross goes sailing with William F. Buckley!]
- 9: 9/11 sucked. [Ross laps up the patriotic spirit and the Summers presidency.]
- …and then a tearfelt ending.
Sorry, did I end up mocking it a little?
Gore, Sammy’s Hill. Yes, I have a weakness for chick lit.
What Motivates Bureaucrats? A genuine investigation (as opposed to the typical social science arms-length thinking) into how Reagan affected the civil service. In short, our civil service is the opposite of what you see on Yes, Minister — they were practically falling over themselves to kneecap their own agency in response to the President. Kind of sad, but hopefully this means that Obama will also have wide lattitude.
DFW and Mark Costello, Signifying Rappers.

A great book, although surprisingly the best parts are written by Costello. A dense intermixed weave of music, history, race, law, fantasia, and brilliant writing.
The Telephone Gambit. Decently researched, mixed in with self-indulgent (and just plain bad) autobiography about writing the book. I wrote up a summary of the story which I’ll be publishing soon and you should probably just read that instead. But everybody should agree that Bell stole the telephone from Gray after this book.
Krugman, The Age of Diminished Expectations (1st ed). Bleh. Krugman’s first book, back before he knew how to write.
Bartels, Unequal Democracy. I’m also going to publish a summary of this.
Beam, Gracefully Insane. Like all good residents of Cambridge, being institutionalized in McLean has long been a dream. After enjoying Beam’s other book (Great Idea at the Time) this seemed right up my alley, but it was nowhere near as good.
Gore, Sammy’s House. The Gore books were bothering me because I could never figure out who Wye and RG were supposed to be — all the other characters mapped pretty obviously onto current politicians, but the candidates were a mystery. I’d somehow forgotten my first instinct: RG is AG, which means that you have to think back two decades or so. Once you realize that, everything falls into place.
Wodehouse, Mike: A Public School Story. The first Psmith story. Cricket, cricket, cricket, cricket. Sigh.
Ice Cream Man. Good fun for Tosci’s fans.
Kuttner, Obama’s Challenge
V for Vendetta. Moore’s whole story about how the movie softened the fascism and anarchism seems completely bogus. That said, the movie did change some fantastic parts, including V’s televised speech and the brilliantly convoluted Hamlet-esque ending. Also, the movie’s whole virus attack subplot was stupid. On the other hand, the movie added some great stuff too. So see both, I guess.
Krugman, Pop Internationalism. The essays Krugman wrote before Peddling Prosperity, meaning it discusses the same stuff but much more disjointed and poorly edited. I was hoping it’d explain the mystery of his animus towards Laura D’A, but no such luck.
First-Time Manager. A much better book than I expected, but enough tin-ear corporate silliness that I can’t thoroughly recommend it.
Searle, The Campus War (full text online).

Actually, a really good book on the campus uprisings of the 1960s. First, there’s some terrific first-hand reporting from Searle’s experience at Berkeley (in which he participated in all three sides: the uprising, the faculty response, and the administration counterattack!). Second, there’s some good secondhand summarizing about the experience at other campuses. Third, there’s some good analysis about why campus uprisings happen and what they mean. Fourth, there are some interesting proposals for reforming the university. (I, too, want to get rid of the trustee system.) Makes me wish Searle did more non-philosophy books!
Haggis-on-Whey, Animals of the Ocean (In Particular, the Giant Squid). Not as good as the original (now in its third edition!).

Happy new year!

Posted Sat, 03 Jan 2009 16:00:59 -0500 Tags: ?rss2email

Ulrich Drepper

Fedora 10 comes with filesystem capability support. Unfortunately it is not used by default in the packages which can take advantage of it. I think the excuse is that there people who build their own kernels and disable it. That's nonsense since there are many other options we rely on and which can be compiled out.

Anyway, you can do the following by hand. Unfortunately you have to do it every time the program is updated again.

sudo chmod u-s /bin/ping
sudo /usr/sbin/setcap cap_net_raw=ep /bin/ping
sudo chmod u-s /bin/ping6
sudo /usr/sbin/setcap cap_net_raw=ep /bin/ping6

Voilà, ping and ping6 are no SUID binaries anymore. Note that ls still signals (at least when you're using --color) that there is something special with the file, namely, there are filesystem attributes.

These are two easy cases. Other SUID programs need some research to see whether they can use filesystem capabilities as well and which capabilities they need.

Posted Fri, 02 Jan 2009 19:21:44 -0500 Tags: ?glibc

Robert Love

This New Year's Eve, while you drink and dine and dance, as sapping as this roller coaster of a year has been, never take for granted what you have and who you are.

I'm luckier than most.

The Big Picture, The Globe's beautiful photography blog, features an amazingly well composed photo tour of Israel and Hamas's deterioration after six months of relative but illusive calm.

Even they are luckier than some.

Posted Wed, 31 Dec 2008 14:00:00 -0500 Tags: ?linux