In a project, I need two "blobs" compressed; the first one is the usual mix of ARM code, Thumb code and data, the second is a piece of firmware to be uploaded into an FPGA. Both of these show obvious signs of redundancy (the ARM condition code "always" appears quite often, and FPGA blobs have a lot of zeros). So I thought that it might be an interesting idea to use the extra knowledge we have to build a better compressor. The easy answer, of course, would be zlib and a static table that emphasizes on the typical distribution of ARM code, however that is still quite suboptimal, for example we know that the heightened probability for the "always" condition code is only given in the condition code field, so we have to look at words, which is not very zlib-ish. Also, the redundancy goes further. Except for very few exceptions, registers are a lot more likely to be used as source operands if they had been a destination operand since the last unconditional jump that was not a forward branch. That much intelligence comes at the price of making the decompressor pretty complex, though, which I'd like to avoid. One of the main reasons for actually thinking about this stuff is that zlib's inflate code is too big for the 16kB space I have, and compiling it in Thumb mode leads to an ICE. So complex decompression code is pretty much a non-option. Almost the same thing goes for the FPGA data. The gzipped data is still more than 50% of the uncompressed size, so I believe there is room for improvement here as well. Being able to use the same decompressor is a bonus, of course, but as long as the decompressor itself compresses well, a minor issue.

So K. called me a brat, and rightly so. Now I could go on about the bizarre dysfunctional ways A. and M. keep trying to drag me into their extramarital insanity, but that would be overuse of initials. I could tell you about Fatslaps and his plans to splatter Harry with onions, but Harry is whimpering just about the right amount. I'm talking about Harry, not Harry. I could do a Marxist literary criticism of The Garbage Pail Kids Movie, but something disturbing happened to me, indirectly leading me to have a flashback. It was another century, though not more than a couple miles away. As with all progress , some things are better now, and some things are worse. Maybe that's just how I see it. It's stereotypically geriatric to reminisce about the past, accentuating the positive, but it's stereotypically me to only comment on the negative. So in the interest of stalling, here comes a m lange of the two. Value judgments are left as an exercise for the reader, assuming the prostitute/lover question isn't still getting top billing. Warren Zevon was still alive. Nouvelle Vague hadn't released any albums yet. I only knew one person who spoke Brazilian Portuguese. I hadn't seen Rent yet. I used to eat a lot more Colombian food. I refused to eat tomatoes. Actually, I ate quite a few things then that I don't now, and quite a few things now that I didn't then. I don't remember what I ate that night, but it wasn't Kraft dinner ; I'm sure of that. I know because I went to see a free concert as performed by the Barenaked Ladies. The concert was free because they were almost completely unknown. I was introduced to them a while before, by a dirty, dirty slut who squealed with delight because the lyrics featured words such as erection . It took me years of recovery to be able to appreciate that song. Years. If she hadn't, I would have found out about them through Minna Bromberg because she does a cover. One of the people I was with shouted out to Steven Page, calling him by the wrong name. If being a starstruck poseur weren't enough cause, I think the error would have made me implode from embarrassment. He took it on the chin. I know this Canadian who keeps telling the same tired old story that the Barenaked Ladies is the only Canadian band to ever become famous outside of Canada. He uses this dubious claim to segue into his bit about how The Tragically Hip is really popular in Canada, but unknown everywhere else. I tell him that I've heard of The Tragically Hip. He doesn't believe me. I try telling him that I've never heard of Moxy Fr vous or Rush, at which point he breaks down and admits that everyone has heard of Rush. Then we repeat the conversation a month later. So BNL did get all famous and mainstream and STUFF. That night, they urged everyone in the audience to promote them so they could GET PAID and sell out to The Man. I must confess not comprehending their earnestness and the gravity of the situation. I also never expected them to be played on Z100. Boycott ClearChannel. They're sellouts now, but they weren't then, and a good time was had by all. At the time, If I Had $1000000 might've been their most popular song. AS SUCH, the more rabid fans in the audience had brought boxes and boxes of macaroni & cheese, as well as a stuffed monkey or two. These items were flung at the stage, at appropriate times, frightening the band. I don't believe that anyone threw a green dress. Now, Canadians are funny people. They like to flap their heads and do medleys and covers and rap gratuitously in the middle of concerts. Well, Rush doesn't, but Moxy Fr vous and BNL do, and that's enough for me to make a sweeping generalization, because Rush can be disqualified purely on the mullet factor. You probably don't know this, but If I Had $1000000 is a song which gets a lot of variation and perhaps improv. For example, the owner of the remains will vary, and they'll vamp the introduction with the lyrics of some other song. You can hear it on the Rock Spectacle album, where they lead in with Grade 9. That night they did Prince's Raspberry Beret. We swooned. We swooned.

While evaluating Gallery, I noticed that my test web server generates wrong links inside the web application. After getting some help on the Gallery Forum, I was told that this was because my setup was miscreating REQUEST_URI to contain the entire URI, consisting of scheme, host name and path, while Gallery expects that variable to be only the path portion of the URI. Since REQUEST_URI is fine when I ask the web server running the application directly from the host in question, while accessing it from my local machine through an ssh tunnel (since the application web server is not going to be publicly visible on the Internet) yields the full URI in REQUEST_URI Unfortunately, neither is the PHP Documentation especially verbose (it just says that REQUEST_URI is “The URI which was given in order to access this page; for instance, ‘/index.html’.”) nor is the apache documentation formally defining REQUEST_URI (the closest to a definition being the documentation for mod_setenvif, which says that REQUEST_URI is “generally the portion of the URL following the scheme and host portion without the query string”). Did I miss a more formal documentation of apache/PHP’s behavior? Pointers appreciated. While I was writing this blog entry, which was a lot more angry in its first version, the Gallery guys finally acknowledged that apache and PHP are not sufficiently specifying REQUEST_URI and that I have delivered a valid example where there is a host part in REQUEST_URI. They’re going to work around this. Good news, thanks!

---

The promised fix is in gallery2 svn, I have applied the patch to my local version, and the application is fine now. Thanks!

While trying to introduce Linux at the SOS Hermann Gmeiner International College in Tema, Ghana, I encounted a very strange problem. Here are the results, I spare you the list of things I tried to find out:The BIOS on the Gateway PCs they use here, with the id bf86510A.15A.0066.P13, will freeze when it encounters a disk with a linux created partition table. It will do so before even deciding what to boot, so you can't boot from CD then. It does not matter if the orignal MBR is on it, or the one created by Window's fixmbr, or lilo -M, or install-mbr, or grub. Changing the partition table using Windows XP (diskpart in the recovery console) will make the BIOS boot nicely. This only happens with the hard model drive that came with the PCs, after replacing it with a different model any partition table is ok.The only way to keep working with the hard drive is to power the computer without the hard drive attached, wait until it is done detecting it (for example wait until the BIOS complais about the lack of harddrives), then plug it in while the computer is running. Of course, the hardware is not meant to be used this way, and it might destroy everything, so don't try this at home (unless you have to). For me it was the only way, since when I know boot from a CD (Windows Installation Disk, Knoppix, FAI-Installation CD, anything that does not rely on BIOS information regarding the hard disks), the hard drive can be used just fine...So how did I get Linux on it in the end? One can say I tricked the BIOS: I made the automatic Linux installation add another, unused and small partition at the end. After the installation is done and I can't boot regulary any more, I use the mentioned power trick to boot the Recovery Console of a Windows XP installation CD, to delete the unused partition with diskpart. This makes Windows write the table, and thus make the BIOS happy. Unfortunately, this kills grub, so I have to boot any Linux boot CD, chroot into my installed system and run grub-install...If anyone has encountered similar problems before and maybe found a nicer solution, which maybe could bring me back the "A" in "Fully Automatic Installation", or at least frees me from the need to make IDE hot-pluggable, I'd be grateful.

Few weeks ago, I began working with Paul Wise (pabs) with Synfig Studio packages, an excellent software to make animations.
I have tested it just one and a half hour with no previous experience and reading the tutorial I ended this animation.

There is a complete gallery with a lot of examples.

At the moment we are only four developers working on it, and extra developers working on it should be welcome!

One of the interesting topics that came up during this last summer at various conferences -- dare I call it the Summer of Wiki? -- was the idea that experienced wiki community members need to share our cultural values and community-building experience with new wiki sites and developers. Christoph Sauer coined a term for this effort: Wiki Ohana, based on the Hawaiian concept of wp:ohana, or extended family. I was glad to see that the tireless Mark Dilley has started a new wiki at http://wikiohana.net/ to organize the Ohana effort. I plan on taking some time to work on this site; I think it's going to be crucial for riding the publicity wave that wiki is on right now. tags: wiki ohana mark dilley

Wikitorial triumphant Last summer, the Los Angeles Times tried an extremely interesting experiment in creating a wikitorial, or wiki-based editorial. The experiment was a notorious disaster: due to excessive abuse and fighting, the Times cancelled the experiment before publishing the results. The entire experience stained wiki's reputation for an entire year. Fast forward to 2006: oh, how times have changed. Ryan Singel of W I R E D magazine put up a 1000-word article about wikis on a wiki at SocialText. He invited the general public to edit the article. The result, which is a reasonably cohesive article on wikis, was published in wired under the title Veni, Vidi, Wiki. It's not the best article in the entire world on wiki, but it's not half bad. Some people have been down on the project -- mostly wiki businesses who felt they didn't get prominent enough coverage -- but I think that the bar was set so low by the LA Times that it's hard not to call getting to publication a success. Looking back, what were the possible factors that made the WIRED article work when the LA Times one didn't?

• Point of view. The LA Times article was an editorial, while the WIRED article was ostensibly a news story. Editorials are intrinsically opinion-oriented. Wiki can work for expressing personal opinions, but it's not easy, and the result usually isn't a very good read. It's much better as a means for expressing agreed-upon consensus information.
• Topic. The LA Times decided to use the extremely divisive issue of the war in Iraq as the subject of its editorial. How they expected to have a collaborative editing success with this topic is hard to understand. By concentrating on the wiki method itself, on the other hand, the WIRED article covered a much cooler topic that lent itself better to dispassionate discussion and consensus.
• Shared goals. The Times tried to reach out to a mass-market audience that was extremely passionate and divided on the topic at hand. The discussion of the Iraq war had already largely degenerated to name-calling and demonization at that point; the people who were participating had more to gain from keeping the other side from getting a say than from getting their own opinion across. For the WIRED article, the audience was experienced wiki community members -- people who know and understand the technology and culture. They had a shared goal with WIRED and with each other -- to spread the word about wiki in a way that's easy to understand. Although Angela Beesley's point and Mike Cannon-Brookes's article correctly note that the increasing commercial interest in wikis did bring some baggage along, I think there was some common ground that participants could reach.
• Organizational commitment. This, I think, was the key success factor. The LA Times posted their wikitorial as an experiment -- they dipped their toe in the water and pulled back as soon as the going got tough. As far as I know, they had no community management or leadership, and no seasoned wiki community members participating. On the other hand, Ryan Singel's article was hosted on SocialText, and SocialText has made a good business out of teaching companies and organizations the Wiki Way. They've got some of the best wiki minds around on their payroll, and it shows in their ability to manage a wiki project.

Although I think that these experiments are interesting, I don't think they make a very good measurement of whether wiki can work. Obviously, we have thousands of examples that wiki works (see WikiIndex if you need more convincing). I think that people's engagement with a wiki is proportional to their belief in the importance of their own work. If wikis are relegated to a tiny part of a Web site or publication, participants pick up on this de-emphasis and don't put much effort into the project; it's a self-fulfilling prophecy. I think that to be healthy, a wiki needs to be a major part of its parent project, if not the whole thing. That's why, I guess, WikiNews is going to continue to be more relevant and important than one-off wiki article stunts. tags: wiki wikitorial W I R E D latimes ryan singel socialtext

Hyperscope I'm psyched to see that Hyperscope has achieved its 1.0 milestone. Hyperscope is the extension of wp:Doug Engelbart's ideas about hypertext and human intelligence augmentation into the technologies of today's World Wide Web. Eugene Eric Kim has been working hard on the project and gave a great demo of the tool at Wikisym in August. Congratulations to EEK and the entire Hyperscope team! tags: hyperscope hypertext doug engelbart eek

The security incident on alioth resulted in some rather bad press. Much of which isn't very accurate (the server was not cracked, certain applications installed by users were abused, but no privilege escalation happened) and not fair (this is not a "dumb" web server, but a server to be used by "third party users" to run web applications on). It's also worth noticing, that everybodys favorite Joerg Schilling commented [de] (read: flamed) on these articles in his best troll manner. In fact, he's known to be a frequent troll on heise, often posting "corrected" versions of articles related to Solaris or Linux. If you've read his posts there and his mails you just can't take him seriously. Don't feed the troll, and just ignore anything you hear from him. Including any cdrecord stuff, please switch to cdrkit/wodim! To avoid this type of problems I see the following choices:

• Disallow users to install their custom PHP scripts
• Require users to send their web applications through a security review process and installation by the admins
• Write and run some security scanner on these applications, that will detect known vulnerable versions of installed applications (but that means someone needs to write lots of detection code, and update it with every related security announcement...)
• Modify PHP to be harder to attack (i.e. remove functionality, that will potentially break stuff we want to have)
• Use SELinux to jail the webapps a bit more. E.g. SELinux could have prevented the attackers from setting up their IRC proxy.

As you can see, the first option is the easiest, but it's contrary to the idea of alioth - being allowed to run custom web apps. Face it: a webserver serving only static pages is much easier to keep secure than one where users are allowed to install custom applications. And a project of Debians size needs to offer a web server where developers can run custom CGI. The other options mean much more work; especially the SELinux option would increase security a lot, even with PHP, but it means someone will have to spend a lot more time on administrating the system, and especially helping users when their web app doesn't work right because of SELinux security restrictions. For further increases in security PHP would need to be patched with some SELinux support: it shouldn't be allowed to include() or execute files written by the web server and not uploaded via ssh. For this, PHP needs to understand security contexts. One thing we should go for, however, is to provide more common services on alioth. For example wikis. Maybe we could setup a shared MoinMoin instance for all projects on alioth that want to have a wiki. And maybe offer "security supported" installations of other common webapps as well (e.g. forums, trac). Attacks usually exploit widely used applications such as wikis or forums. And even when 90% of the users on alioth upgrade their software on time, there are still 10% vulnerable. And maybe we can setup a box for the custom applications that actually is SELinux enabled in one or two years, when enough people are familiar with it and on how to write and maintain an appropriate policy.

Yesterday, I helped a friend install an Edimax wifi USB stick. I've been using wireless networking lots for a year or two without much trouble, even testing experimental drivers sometimes, so I thought this would be straightforward. How wrong was I? First complication: the target machine is running the latest Windows, but still needed a driver CD-ROM loading. The instructions were quite clear that this must be done before plugging in the stick. What it doesn't tell you is that the stick has to be plugged in at a specific point during installation - cue mad unpacking. Second complication: the autorun program on the driver CD tries to do DNS lookups. Why on Earth? This is part of installing a network device. There is no working connection to the network, else we would probably not be installing this... Third complication: the questions in the install wizard are nonsense. For example: "Do you want to optimize for performance or for wifi operation?" Erm, I'd like it to operate as a wifi device with good performance please. The installation manual didn't explain what the questions meant, but did at least give recommended answers. Final complication: the driver utility has at least two ways of setting which wireless network to use (as well as the target AP, there's a BT Home Hub and some other BT kit somewhere nearby, according to their ESSIDs, although the USB stick only saw the Home Hub). One of them works. One doesn't, with the same settings. The only obvious way to find that out is trial-and-error. There's no useful error message when it fails - just no working network connection. Yes, lots of Linux stuff is harder to install than it needs to be, but at least its questions mostly make sense and most things give proper error output that helps to debug it. Windows is still in the dark ages on these two. I guess it's the lack of peer review: I didn't see any way to send a bug report to the dodgy driver designers. By the way, the Edimax stick works pretty well (although their web site is terrible). I think I'd recommend it, particularly if you're not using the Windows drivers... It says on the box it works on Debian and it looks good on linux-wless, but I've not tested that.

Today, as it was widely anticipated, the Superior Tribunal of the Judicial Power of the Federation (TEPJF) declared Felipe Calder n, of the currently right-wing governing PAN party, elected as president for the 2006-2012 period.
My regular readers will know that my political views are against his party's, and that I completely oppose him - Of course, being consequent, in June I started, together with some friends, FeCal.org.mx, a site destined to show the incongruencies and incoherences in the official version - and that evolved to a site I am quite fond of, having good and deep analysis of the political situation. Of course, it is time now to redesign and think forward for this site, now that FeCal is no longer a candidate - but lets leave it aside for now.
Today, we are mourning. We are not mourning an electoral loss - Wherever there is democracy, there are losers, and it might be right that we lost this time. Furthermore, in political systems such as ours, it is practically guaranteed that the majority of the citizens will lose (this means, it is terribly hard for any candidate to get over 50% of the votes - If Calder n wins with almost 35% of the votes, or if L pez Obrador wins by a similar amount, we will anyway have 65% of losers). But what we are mourning goes far beyond that: We lost faith in our electoral institutions, which we were so proud of a couple of years ago. They proved not to be serious, not to be adequate for a hard decision. Why am I saying this? Lets analyze a bit.
First of all, the Federal Electoral Institute (IFE)'s main function is to organize the federal elections, and to make sure they are run with neutrality. Since the early months of the formal competition (as the campaigns themselves started way too early and we Mexicans are sick of the eternal electoral climate), the IFE has not acted in time to stop a dirty campaign, made not only by the PAN party but by the nation's President himself and by groups that, being privately owned, are said to be outside the reach of the IFE's regulatory spectrum. The IFE's general council should have been built with representants of all of the main political forces, but only PRI and PAN (which means, center-right and right wing) were represented.
Secondly, over the last six years, President Fox seems to have made constant efforts not only to prove us all he is a complete fool and inept as a statesman (examples abound, there is no rush to prove Vicente Fox just cannot be trusted to run a country), but that his fight for democracy was nothing but a race for personal power. He took every oportunity he could to promote his party - while the Mexican law requires him to remain neutral during the electoral period. There are many proven examples of irregularities and corruption inside his cabinet (most notably those carried out by Josefina V zquez Mota, who was in charge of all of the federal programs to fight poverty, and was the coordinator of Calderon's campaign) leading to inject resources into the campaign. Yes, this should have been stopped by IFE as soon as they were detected - But it was not. And, thank you Mr. Fox, by doing this you severely undermined the respect there should be for the Presidential figure.
Now, IFE's role ends shortly after the elections. After that, it is TEPJF's role to qualify the elections - To ratify they complied to the required equity, legality and certainty. Many of us had more trust in TEPJF than in IFE, mainly because of the series of personal and group connections that came up between IFE and the power groups. Most of us were quite vocal on the voto por voto, casilla por casilla front - Demanding from TEPJF to request to recount all of the votes. Having only 0.58% distance between the top candidates, with lots of statistical anomalities, with tons of reports of illegal tampering of the ballots, having a wide recount would surely make many among us believe and accept the results - Of course, the PAN repeated ad nauseam that the ballots had been counted and we should not go again over the same excercise, quoting all kinds of arguments that came from a too narrow interpretation of the law. And, in the end, too narrow was the response of TEPJF - Only 9% of the booths were reinspected, and not all of them were recounted. In fact, one week ago, they decided to discard over 300 appeals (this means, 300 requests for trial on a specific booth or on a whole district), without yet disclosing which appeals were they, on what basis were they discarded, what geographical areas did they impact, or anything. They nullified about 235,000 votes - And this number is quite scary, as it practically matches the official difference between the two lead candidates (244,000 votes before this partial recount, 233,000 after it). We can now state for certain that the difference between the candidates is smaller than the error margin.
Today, with a very important portion of the country in doubt on whether their decision was legal and correct, TEPJF ratified Felipe Calder n as the elected president. This would be good news. I would like to accept Felipe as my president - Sadly, I cannot, just because all of the TEPJF's principles were violated:

• Equity: The process didn't progress with equity. Illegal publicity was repeated over and over. Just as one example, the Presidency has had the equivalent of 24h a day of ads in the national electronic media for over six months - And IFE acknowledged it was used in a way that promoted the vote for their candidate. The final message was very subtly changed, many people were left unsatisfied, and... That was it.
  Andr s Manuel L pez Obrador was often protrayed as a puppet of Fidel Castro and Hugo Ch vez, and there are still people who believe he was setting to create a communist regime in Mexico. Of course, this was also a direct result of what is now known as the hatred campaign that the ruling party and an important group of industrials pushed. So, no, we had no equity.
• Legality: Most of this posting has dealt with the ilegalities of the process, they are really not in short supply. The sad and alarming thing is that it was the TEPJF itself which commited the last and most important illegal acts.
• Certainty: In a strongly contested electoral scenario, I perceive this to be the sole most important principle. How many votes were cast for each of the top candidates? We have repeatedly stated that the difference between them is below the statistical error margin for a process where a million people counted the votes. And after last week's results where nearly 240,000 votes were discarded, the difference is objectively and undoubtely smaller than the error margin. Even if no fraud was made, people make mistakes, and it is too na ve to assume not even one out of each 200 votes was incorrectly accounted. And even if no fraud was done, not allowing the society to ensure the results of the process really match the reality is by itself a fraud. We will now probably never know if Felipe Calder n cheated, the same as we still don't know who won in 1988 and by how much. Then, official records say that Carlos Salinas had over 50% of the votes, Cuauht moc C rdenas almost 30% and Manuel Clouthier close to 20% - But both C rdenas and Clouthier were sure they had won. And while C rdenas (founder of the PRD, which now supports L pez Obrador) called off the civic resistence to start creating a strong political movement for future, PAN's Clouthier did exactly what his party criticizes L pez Obrador for. In fact, our president Vicente Fox was the Agriculture Secretary in Clouthier's parallel government. Only that Clouthier had a misterious accident some months later and died - giving way to the dark period of PRI-PAN concertacesiones led by Diego Fern ndez de Ceballos.

So... In short, what comes now? We are exhausted by this long process. As too many people, I just cannot accept the imposition of yet another fraudulent president. I had the hopes that Mexico had changed in the last 18 years - But it has not. We are still in a strong presidentialist regime, and we still don't have hopes of getting a democratic government. If we do have a democraticly elected president, perfect, I will accept it. Of course, criticizing and keeping a close eye on his government, as I don't think the social and economic principles they push, but accepting. But there are too many signs of a fraud, there are too many stinky bits in the decision. The stinkiest of them all, the refusal of their opportunity to shut us up. Is it better to have millions of angry citizens closing important streets and giving Mexico a bad name by writing about our trip back to the stone age than to allow for a legal recount? Is it too much asking giving some certainty to our elections? Is there any doubt we will keep fighting this imposition?

Yesterday, I posted an 18-line solution to Lars' language problem. One problem with it was that it was not very memory-efficient (or time-efficient, for that matter). In other words, it was optimized for elegance.

Here is a 22-line solution that is much more memory-efficient and works well with his "huge" test case. Note to Planet readers: Planet seems to corrupt code examples at times; click on the original story to see the correct code.

import System.Environment
import Data.List
import Data.Char
import qualified Data.Map as Map
custwords = filter (/= "") . lines . map (conv . toLower)
    where iswordchar x = isAlphaNum x && isAscii x
          conv x = if iswordchar x then x else '\n'
wordfreq inp = Map.toList $ foldl' updmap (Map.empty::Map.Map String Int) inp
    where updmap nm word = case Map.lookup word nm of
                             Nothing -> Map.insert word 1 nm
                             Just x -> (Map.insert word $! x + 1) nm
freqsort (w1, c1) (w2, c2) = if c1 == c2
                                 then compare w1 w2
                                 else compare c2 c1
showit (word, count) = show count ++ " " ++ word
main = do args - getArgs
          interact $ unlines . map showit . take (read . head $ args) .
                     sortBy freqsort . wordfreq . custwords

The main change from the previous example to this one is using a Map to keep track of the frequency of each word.

Provides a minor bug fix for AllegroCL's lowercase lisp reader, mlisp. Also, special thanks to Christophe Rhodes, frequent contributor to SBCL's MOP, for his excellent suggestion in response to a question for improving CLSQL's MOP internals: CLSQL object definitions use custom slot types. For example, a CLSQL slot may have :type (varchar 10) specified which gets translated to a lisp type of (or null string). Rather than parsing and then re-storing the type atrribute of a slot in compute-effective-slot-definiton, Christophe suggested performing the type parsing in initialize-instance :around of the CLSQL direct-slot-definition object. Then, the real type attribute is stored in the both the direct and effective slot definition from the beginning.This is more AMOP complaint since AMOP doesn't specify that one may change the type attribute of a slot. This is clearly seen since CLSQL no longer needs to modify OpenMCL's ccl:type-predicate slot attribute after the type was changed in compute-effective-slot-definition.

We spent the extended weekend in New York City, visiting many friends. Particularly noteworthy was our dinner with my Cousin (Dr.) Matt at Gobo, “Food for the Five Senses.” (The website, by the way, is a fairly effective combination of Flash where helpful and HTML where Flash is unnecessary.) Gobo served quite possibly the best vegan food I’ve ever had. I might even say the best vegetarian food I’ve ever had. (Since I’m a vegetarian, I guess that might just make it the “best” food.) Our dinner included:

• scallion pancakes with homemade mango salsa
• crispy spinach & soy cheese wontons
• salt & pepper king oyster mushrooms
• natural seitan medallion in sizzling spicy citrus sauce
• spinach pistachio roll with jade mushrooms
• beet salad with toasted walnuts

Too bad Boston has nothing comparable. Every time I travel to New York I wonder why Boston can’t borrow at least some of the best ideas — for example, a functional mass transit system. Some other highlights — click on any image for a full-size version: Esther watching the traffic go by
Buildings
A Fountain
The view from my cousin’s rooftop

For a long time I've enjoyed reading books by David Brin. Not only does he have some good sci-fi ideas and a good writing style, but he's also a cool guy when you meet him at a signing. One of the core concepts in a number of his books is the idea of uplift, whereby advanced races use a combination of breeding programs and genetic manipulation to raise animals to a similar level to humans in terms of intelligence and ability to use tools.

I believe that it's a necessary step in the development of the human species to encounter other species as equals. It seems obvious that a person who was raised in isolation would not be able to reach their full potential (there are many examples of children being abandoned and living with animals, the results are not positive). It also seems obvious to me that a species that is raised in isolation without interacting with other equal species will also be unable to reach their full potential. I believe that the human race needs to meet with another species of an equal level as the next stage in the development of our civilization.

Given the lack of success of SETI programs it seems that uplifting a species such as dogs, monkeys, or dolphins is likely to give better results in this regard than trying to contact non-human intelligent creatures.

Dogs might be a good first choice for uplift because they are well domesticated, this means that you are permitted to own them in residential areas without a license and there are good veterinary services for them. A possible way of starting an uplift program would be for people around the world to buy dogs of some particular breeds and then measure them by some objective scales. There are intelligence tests for animals that could be applied to dogs, the ones that get the best scores would be permitted to breed. Also we would want to breed them for communication ability (the ability to talk) and dexterity (evolve their toes into fingers). The statistics of the dogs and their lineage (don't want in-bred dogs) could be stored in a database and the breeding program could be done in an open-source manner over the net.

Most domesticated dogs are in-bred to some degree so we would want to cross-breed them to some extent. Poodles are reasonably intelligent and live for a long time so may be good for a start to this program, also blue-heelers, terriers, and labradors are reasonably smart and could be included.

Debian has always defined itself as "the universal operating system", which to me means that, given two options A and B, each with their own advantages and disadvantages, we will incorporate them both, because there are people for whom A is better, and people for whom B is better. This is one of Debian's greatest strengths, and this is what makes it the "universal" distribution. Now there has been discussion lately about whether Debian needs some sort of central authority to pull the project into a certain direction. The thing is, while everyone seems to agree that we lack direction, we cannot disagree more on which direction it would be if we had one. At present, we have a number of groups pulling in different directions:

The "release" group

Debian's primary goal is/should be to make stable releases. In the time between releases, people should run the release candidate and iron out bugs, so we can release faster; new features are to be added only right after a release.

The "usability" group

Debian does not have any use if we do not support every user. As the admin users can already help themselves, we should focus more on the average user and make the system more simple to use and administer. Integration is a must, as is closed-source firmware.

The "hacker" group

Debian's purpose is essentially to give us a distribution we can use for ourselves, where all the tools that exist are there.

The "freedom" group

Debian is supposed to be only free software so I don't accidentally come into a situation where I'm in breach of a license.

The "large installations" group

It should be as easy as possible to deploy Debian to a set of boxes and remotely administer them. It should be easy to install the software the users need and to customize it for our organization. Users are not supposed to administer machines, and non-free software and drivers need to be clearly marked and easily avoidable so as to not put us at legal risk.

The "supermarket" group

Debian is a repository of packages that makes our lives easier when we build either a system or a distribution, but we don't really care whether stuff is integrated already, because in order to feel comfortable with it, we need to redo it anyway.

The "small but beautiful" group

The system should be as modular as possible, allowing me to leave stuff out that I don't need. I don't mind installing stuff later on.

There are others, and I have represented each only with their most extreme positions. These groups are not usually disjunct, and in some places, some groups share goals. But, for example the "usability" group and the "small but beautiful" group will always disagree on what should be in a base installation. All of this is not new. What is new is that people are asking for a strong leader to strike down the unbelievers rather than discussing stuff on the mailing lists. This is generally a thing I wouldn't like to see happen in Debian, because anyone you pull into the discussion is either uninformed (so not qualified to answer) or already has an opinion (which will most likely conflict with either party's opinion). By forcing a decision, you essentially give one party the right to dismiss arguments with "we've already had this, it has been decided" and do not solve the problem at all, because the other party is still unhappy. You might want to argue that a committee evens things out a bit as more groups are represented there. That is true to a certain extent, however you'd have to have a way to determine who gets to be on the committee, and to do so in a manner that noone is left out (even if there are new groups forming all of the time) and without giving any group too much power. We might just include everybody, which brings us to status quo, except that everyone got a job title now and people might feel more inclined to decide things by majority vote (because that is what committees do after debating, right) instead of based on actual merit. Scott writes that implementing the same thing he just did in Ubuntu would have taken him ages to do in Debian because there are so many more people to coordinate in Debian. I have to disagree here, the number of people to coordinate is probably the same if not higher, except that the Ubuntu model seems to be that every core team member has commit access and is supposed to read up on the changelog when touching a package, making the coordination more implicit. I happily give out Ubuntu CDs, which do have non-free drivers, firmware and documentation, to users. Telling them that they cannot use that driver or have a manual because it's not free will not help anyone, and it is unlikely that they will be taken to court over it. This is all fine and dandy considering Ubuntu's target audience. However, Debian has a much larger target audience, including Ubuntu itself. If Debian were to interpret licenses less strict for some perceived benefit for the users (cdrecord springs to mind here), then all derivers, including Ubuntu, would have to carefully cross-check all of the licenses for possible violations. Thus, I oppose GFDL documentation in Debian main, because when we say "our priorities are our users and free software", that includes all of our users, not just end users. So, what I ask of you people reading this via Planet Debian is the following: Ask your "opponent" whether he'd be interested in finding a common solution that fits both use cases. Present it as a technical challenge. Accept that the outcome of such an endeavour might be that the other person is right. Accept that not everyone shares your views and/or priorities. It is hard to accept for me that a lot of people still think that svn is superior to git, or emacs is superior to vi. So if you have a different opinion on some matter, keep in mind that the other person may be looking at things from a different angle, where his choice is the only "logical" choice. Oh, and that goes for both of you. To conclude: Debian's strength is its lack of a clear direction. If we were to decide that the end users are what matters, we'd become another Ubuntu, which would be quite unnecessary because we already have one, and they are pretty good at being Ubuntu. If we decided only releases mattered, we'd probably release more often, but right after a release, unstable would be really broken (the elders might remember how it was before the "testing" distribution was introduced). In the same way, the release team takes care to include your pet project in the release if at all possible. Every package that is added delays the release because they have to wait for autobuilders and make sure that everything is internally consistent. So, they are already respecting your goals. Are you going to respect theirs, and join the release effort even if all your machines run unstable? So in my opinion it is a good thing that we did not decide on a direction, because there is no right one. We'd always leave some people behind if we had to make a choice. What needs to change is our attitude that software is to be used in one particular way, because the people actually using it would disagree. After all, free software is (also) about being able to do things your own way, and Debian as a whole should be supportive of that.

The "Debian board" has been discussed a lot recently. I'm not so convinced it will improve matters that much. I don't think Debian is lacking a central authority to keep the vision. Most people have some overall vision; these visions might disagree on some points, but a board is bound to have the same disagreements. What is taking the fun out for me is not that some technical matters don't work out the way I want them too, but usually it's lack of manpower in certain files of particular interest to me. For example SELinux has been rather frustrating for me, since I felt like fighting alone on a lost position. Often applications would change faster than the policy could be updated etc. And trying to support sarge made that even more so. Sometimes bugs were fixed upstream, but the packages in Debian weren't updated yet, etc. When I was maintaining galeon back then, the must frustrating things were that on one hand, you had lots of people complaining about galeon 2 being different from galeon 1 (and not accepting that galeon 1 was dead upstream, I preferred galeon 2 and so obviously packaged galeon 2) - and on the other hand that there were tons of open bug reports noone even had time to verify. Working on such a package can be very frustrating. I've been keeping out of flamewars and such for quite some time, so I'm not so much bothered by that. I've blogged about that before. But I don't see where a "board" or "steering commitee" would come in helpful. Especially not in comparison to DPL-named release managers etc. IMHO it would be helpful to bring more people in. Our process of becoming a DD is very demotivating, and actually we could use more people - especially - for things like bug verification. Contributing to Debian can be demotivating for several reasons:

• Packages where the maintainer doesn't respond
• Packages the maintainer doesn't really care about
• Packages where you don't understand the packaging, because it's too different from what most packages use (i.e. please use debhelper and maybe CDBS for your packages, don't build your own 20k makefile buildsystem)
• Often not easy to create proper patches
• Roundtrip times of bugtracking etc.

Stuff I've been enjoing:

• "Thank you"s at the end of bug reports
• Occassional teasing by helix for complaining too much in my blog
• Real life meetings of debian-MUC
• Team-maintained packages

What I'd love to see on the long run is some kind of central package repoistory. Many other distributions use some kind of huge version control system for managing all their packages. Maybe we could have something like this with two "default" branches. With very little effort you can get write access to the "public" branch, and only full developers can pull patches over to the "authorative" branch. Packages should be built from that branch, and use some uniform way for this (e.g. debian/patches/ directories!) But people with more experience in team maintainance, e.g. the Gnome team, can hopefully comment more on this.

Following Sesse's example, I decided to start bugfixing one RC bug per day, so, this is the result of my first three days at bugfixing:

• #377652, by fixing the source code to look for rgb.txt in the correct location.
• #377365, by finding out that the bug was not present anymore.
• #377608, by updating to the new usage of libavformat-dev. Actually, both Sesse and I fixed the same RC bug at the same time. :-\

It's quite rewarding to think that if you fix 1 bug a day, from today till November, 30th, you can fix about 140 bugs. With a couple of us doing this, we could tackle not only the RC-bugs but also the important ones (but we have to coordinate, so that we don't overlap again).

I have published the slides to my DebConf 5 presentation, WTFM: Write the Fine Manual. An example manpage (PostScript output) and script for finding executables on your system that are missing manpages are also available.

On 21 August, Don Armstrong, a Debian developer, accepted my offer to serve as my delegate in handling trademark issues vis-à-vis the DCCA. As an employee of a DCCA member company, I found it wise to avoid the perception of a conflict of interest. I should stress that any such perception would merely have been conjectural, however; at no point have I been asked by anyone to put my thumb on the scales, as it were, and deal with the DCCA or any of its member organizations in a preferential way. It is widely understood within the Debian Project that our existing trademark policy, originally formulated in 1998, is too vague, and has not scaled well to suit Debian's much greater degree of success and market penetration (on its own, and in the form of derivatives) seven years later. However, grappling with the issue has proven challenging for Debian's membership. I believe this is mainly because the Free Software hackers that comprise our organization have tended to self-educate to a far greater extent on copyright law, and even patent law, than they have on trademark law. Recently (within the past year or so), Debian gained access via its U.S.-affiliated charitable organization, Software in the Public Interest, Inc. to a pro bono legal counsel who understands the Free Software culture. Debian's difficulty with trademark management is not unique — we have been on the other side of this problem when dealing with the Firefox and AbiWord trademarks, since we customize the codebases of these software projects in our GNU/Linux distribution, but ship them with their names (and logos) intact. It so happens in these cases that the originators of the software (who hold the trademarks) approve of our modifications. One of the essential pillars of software freedom, however, is the user's right to make modifications that the authors or rights-holders in the software may not agree with. Free Software hackers can feel, with some justification, that it is misleading to uphold the freedom of a work on the one hand (by using a copyright license such as the GNU GPL), and take it away with the other (by asserting a trademark on some essential aspect of the work, such as its name). It is true that a work can be renamed, or descriptive text changed, to identify itself as distinct from an "official" version of the work, but this in turn, it is feared, can damage perceptions of the work through at least two mechanisms. Firstly, disclaimers about unofficial status may be unnerving to users who aren't schooled in the vagaries of trademark law, in which — at least in the United States — you are expected to aggressively defend your mark lest you lose a future infringement case you bring against a well-heeled defendant. Users may mistake strident proclamations of unofficial, unendorsed status in a piece of software as a warning that it is unsuitable for use, or has known severe flaws. Secondly, aggressive use of trademarks, or even just the tension observed above between giving with a copyright license and taking away with a trademark license, may lead some distributors to rename a work, obscuring its origins to the casual user. This can happen pre-emptively, before a distributor even knows whether the modifications they have made (or think they might make in the future) have met with any objection from the trademark holders in that work. The "freedom to fork" (i.e., make a derived version unendorsed by the original author) is an essential part of Free Software, and while Free Software hackers' sense of community generally leads them to eschew forking in favor of compromise and consensus, occasionally a fork ends up growing the userbase or improving the overall quality of the Free Software landscape. A hacker may fear that brash trademark assertions by an author constitute mere lip service towards the freedom to modify the work without changing its name, and may be tempted to fork it, leaving the trademark encumbrance behind. Even among those who do not guard their software freedoms quite so jealously, the fear can exist that a simple difference of opinion over some technical programming detail, such as choice of sorting algorithm or graphical toolkit, will escalate to the point where the trademark license on the work (implicit or otherwise) is withdrawn. This is the inverse of the previous situation — instead of a modifier choosing to fork a work, the original author of a work (or, at any rate, the holder of the trademark associated with it), can force the modifier to fork. The dilemma this imposes upon the people creating the modified versions — revert your existing change or be legally compelled to make an additional one — can rub people the wrong way. When forking occurs, for whatever reason, and even in the relatively benign case of "rebranding" to remove legally protected marks, the threat exists that the competitive strength of the corresponding software will be diluted. Imagine if each of four major GNU/Linux distributors rebranded their version of Mozilla Firefox, calling it instead things like "Lizardfox", "Hatfox", "Swirlfox", and "Hearstfox". How many users would deduce that the web browsers in question were all "really" Mozilla Firefox, each one with a fig leaf placed delicately over it so that the legally-minded types at the Mozilla Foundation and the distributors could wink at each other? Even the somewhat savvy GNU/Linux user may be more confused than one might expect, given that other names used for Mozilla's suite of applications include Sunbird and Thunderbird, yet there is an independent Free Software project called Firebird, which was established prior to the Mozilla Foundation's adoption of its product naming scheme. "What's in a name?", you may ask. They're important because they are simple labels we can use to refer to Free Software success stories. There's a lot of Free Software to talk about; the phenomenon of copyleft does much to ensure a competitive culture. It's difficult to achieve an unnatural monopoly in this environment, because anyone who steers a software project in a direction the users don't want to go has to cope with the prospect of seeing a group of those users organize their own community based around a derived version that does what they want. The hypothetical hydra-headed Firefox situation described above, however, is an example of false competition, because the distributors were compelled to distinguish their Web browsers for legal, rather than technical, reasons. In actuality, Mozilla Firefox is a good example of what's right about Free Software, not just because of its licensing but because a web browser is a familiar concept to nearly every computer user today. Free Software's early successes were more esoteric — GNU Make, the GNU Compiler Collection, the GNU C Library, GNU Emacs, and even the Linux kernel are not pieces of software that the general user can easily conceptualize. It is beneficial — to say nothing of convenient — to refer to the leading freely-licensed web browser as "Mozilla Firefox" rather than "a suite of mostly-compatible, similarly-named Web browsers shipped by the various GNU/Linux distributors". Those who seek to foment confusion and FUD about Free Software would doubtless capitalize on such a situation. These issues are challenging but not insuperable. A coherent policy will enable the community to establish a set of common practices, whereas now there are few conventions in the trademark arena. Ultimately, it is my hope that Debian will be able to promulgate a trademark policy that not only satisfies our needs, but serves as a model for others. To establish a successful policy, I suspect we need to build one up from basic concepts, and formulate explicit answers to fundamental questions.

• Why even have a trademark? Let's understand what protections the law affords and determine which, if any, are applicable to our endeavors. In the U.S., trademarks are managed by the federal government (rather than the states), and regulated by Title 15, Chapter 22 of the United States Code. International treaties result in trademark law being roughly similar across most jurisdictions in the developed nations, but there could exist important differences that we should learn about.
• What level of Debian involvement should be necessary for an "outside" organization to use our mark without a fuss from us? Should there be any situations where people essentially have an automatic trademark license, or should we use trademark law as an instrument to encourage (or compel) anyone trading in our name to contact us? We need to consider small-scale garage-based redistributors who simply move physical copies of our official ISO images as well as commercial derivative distributions.
• Is it feasible to apply the copyleft concept to trademarks? That is, is there some way we can turn the restrictive aspects of trademark law into a kind of compact that upholds the freedoms of a sharing community, while penalizing the activities of those who would prey upon that community?

Originally published 2005-09-14.
Updated 2005-10-15 to add licensing in comments.

Courtesy of FindLaw Legal News: WASHINGTON-President George W. Bush said Wednesday that Harriet Miers' religious beliefs figured into her nomination to the Supreme Court as a top-ranking Democrat warned against any "wink and a nod" campaign for confirmation. "People are interested to know why I picked Harriet Miers," Bush told reporters at the White House. "They want to know Harriet Miers' background. They want to know as much as they possibly can before they form opinions. And part of Harriet Miers' life is her religion." Courtesy of the United States Constitution, Article VI: ...all executive and judicial Officers, both of the United States and of the several States, shall be bound by Oath or Affirmation, to support this Constitution; but no religious Test shall ever be required as a Qualification to any Office or public Trust under the United States. Oh, well, just so long as it's a criterion, not a test. I mean, it's only essential, not a qualification or something, right?

Since I got back from the Oldenburg Linux Developers' conference, I've had my attention on our security infrastructure. Despite only being there for one and a half days thanks to a badly delayed trans-Atlantic flight, I found the conversations and collaborative spirit heartening. The bad news is that what I had planned for a writeup got rendered obsolete soon after I returned to the United States. Things have been changing rapidly, but mostly for the better. We've got three machines in the DNS rotation for security.debian.org now, which is superior to the one we had before (you can use the command dig security.debian.org to inspect the DNS record). My thanks go to our security and system administration teams for recovering from the recent overload problem provoked by an xfree86 package security update. Being somewhat familiar with that package, I can understand how its large size combined with Debian's ever-growing userbase starved the security host of bandwidth. Secondly, while I was in Oldenburg, Joey Schulze gave me a lot of insight into what a challenge one particular package is — the thing sucks up at least half of his time, dwarfing all other stable security update efforts. You've probably guessed that this package is the Linux kernel. Due in part to its success, and in part due to OS kernels being inherently attractive exploitation targets, the Linux kernel is getting a significant amount of scrutiny from a security perspective. Taking Red Hat Enterprise Linux as an example, we can see two advisories in the past two weeks: one on 28 September and one on 5 October. The one on 28 September addressed eighteen (18) different vulnerabilities as catalogued by MITRE's CVE project, and the one on 5 October — that's one week later — addressed fourteen (14) vulnerabilities, of which eight (8) were distinct from the previous advisory. (There was some overlap because the earlier advisory was for Red Hat's Linux 2.4.x kernel series, and the latter was for the 2.6.x series.) Those Debian developers who have ever handled a security vulnerability in one of their own packages can likely imagine the labor burden this is. Then reflect that Debian ships and supports a lot more Linux kernel trees than Red Hat does — this only magnifies the problem. The good news is that a team of developers focused on stable kernel security updates has been established. One of its members said to me today that he has seen a "very positive increase in kernel-related security activity". It is too soon to declare this problem resolved, but I perceive no lack of talent or dedication on the part of our developers. I am there to assist them in resolving the organizational and workflow issues so that our users can see the fruits of their energy directly. Similarly, I'm interested to see how the security.debian.org round-robin arrangement holds up after a reasonable period of real-world loads, particularly since I expect kernel package updates to sock the machines about as badly as an X Window System update. These issues are not over and done with, so an announcement declaring these problems vanquished would be premature. At the same time, the developers and users at large need to know whether or not people have their attention on them. I am wary of leaders or managers who declare issues resolved too soon, or proclaim optimism that later turns out to be unfounded, and have sought to avoid this vice. I apologize if I have tacked too far in the opposite direction. I perceive progress in this area. Let me know what you think, what you need to see, and by what metrics you measure progress and accomplishment on the security front. You can reach me at leader@debian.org (the address is already blitzed with so much spam there seems little sense in obfuscating it). (After getting some feedback on this entry, it's my intention to post it with any applicable revisions to the debian-devel-announce mailing list; please take this opportunity to "patch" this "beta", if you're so inclined.)