You get a rigorous analysis of the science behind boiling eggs. I want one of those thermal circulators for Christmas.

Today, an episode of The Gadget Show aired in which they compared PC and Mac to put on their wall of fame . I was shocked that there was no mention of Linux at all in their rundown. Here is the email I just sent to them in response to the show:-

Date: Mon, 30 Nov 2009 22:16:28 +0000
From: Martin Meredith <mez AT debian DOT org>
To: gadget.show AT northonetv DOT com
Subject: PC vs Mac Yes, you mention windows But both PC s and Mac s have the ability to run a little thing called Linux Linux is the base of an operating system that s been around for years, often
making innovations BEFORE Windows or Mac are able to. It s an Operating system that s written by the people, for the people, which
shows in the fact that there are hundreds (if not thousands) of distributions
available to download and use for FREE!!!! A large motive behind the Linux movement is the fact that it s completely free.
Both in the sense of Free Speech, and in the sense of Free Beer. You don t have to pay for it, and you can do what you like with it. Compare the above to a Mac. With a mac, you re limited to the hardware you can use, you re limited in the functionality, etc etc. Comparing to Windows, you can see the benefit of the price. Constantly upgrading windows can cost a LOT of money. Ok, Linux does have it s flaws. Some hardware isn t supported correctly, and a lot of the software you ll find on the shelves of your local shop probably won t work with it. But, nowadays, with the advent of the iPhone, and to a lesser extent, Android based Mobile Phones, people are coming to expect easily available software. Enter the package Manager. Most distributions of Linux now offer an easy way to find and install applications, and some go a step further and give you an application that makes life even easier (See attached screenshot) Linux also has the benefit that, like the Mac, the fact that it s not Windows,
and something that 90%+ of people use, it s not a target for Viruses. Add that
to the fact that it has Least Privileged Access built in (Think Windows Vista
are you sure that you want to run this program as an admin? ), and has done
since the very beginning, and it makes it one of the most secure operating
systems you can find. Linux has come along in leaps and bounds in recent years, and is surely a
competitor for any operating system out there. While it may be unfamiliar,
with the advent of new technology, it s perfectly placed. This has been shown
by the fact that until Microsoft made a sly move to relicence Windows XP for
netbooks, it was hard to find a netbook with anything but a Linux based OS on it (and all those who tried out my eeePC 701 when it was new and shiny out of the box tended to prefer what was on that than Windows!)
Regards,
Martin Meredith Freelance Writer for Future Publishing
Debian Developer http://www.debian.org/
Ubuntu Developer http://www.ubuntu.com/
Deputy IT Manager for Mobile Fun Ltd. http://www.mobilefun.co.uk/

Now that I'm not letting the cat out of the bag (I bought these as gifts) I can write a review. The use case was pretty simple: I thought it'd be a cool Christmas present for our parents to give them something Internet-enabled that would give them regular updates on their grandchild (when he/she arrives). I was thinking a picture a day type of thing. So I hunted around for a WiFi-enabled digital picture frame, and found the iGala being sold pretty much exclusively by ThinkGeek. The reviews seemed pretty good. I know WiFi-capable frames have been around for a few years, but they always seemed to be pretty lacking in terms of WiFi functionality. Like they wouldn't do any security, or they'd only do WEP. This particular product claimed to do the whole gamut, including WPA2. The fact that it was a touch screen and ran Linux also made it appealing. So I ordered a couple of them for a few weeks before we headed to Australia, with the intention of making sure that they'd work. Here's the highlights. WPA2 didn't work (nor did WPA) Despite the software on the frames claiming to be able to talk WPA2, the frame would not associate with my Linksys WRTU54G-TM. I had to drop it all the way back to WEP to get it to connect. For me, this was the most disappointing failure. I bought the product specifically on the strength of its claim that it supported WPA2, and it just didn't work. It was also pretty impossible to debug the failure. I downloaded the latest firmware update, and that added additional settings for TKIP or AES when selecting WPA2, but neither option helped. The automatic updates are brain-dead Speaking of downloading firmware updates, the latest firmware that I downloaded and installed on the frames added automatic over-the-air firmware updates. Nice enough feature, except for the implementation. The frame tried to make an HTTP GET request for a non-existent file, every 6 seconds. So the frequency of checking alone is totally ridiculous, but couple with this the fact that it's making a GET request (this is what $DEITY invented the HEAD request for, people!) and the website has a "friendly" 404 Not Found page that weighs in at a little over 10 Kb. By my calculations, that's nearly 150 Mb of failed update checking traffic a day. Taking these frames to a backward country like Australia, where ISP users still have monthly quotas, gives the frame a pretty horrendous running cost in terms of traffic. Not to mention the outbound bandwidth requirements for the server hosting the updates. Crikey, the mind boggles. I'd have thought checking once a day and on power on would be perfectly sufficient. Transitions are unavoidable It may be just me, but I hate cheezy transitions. Digital picture frames tend to come with a myriad of them, but they all look cheap. It's impossible to tell the frame to just change the picture, it has to use at least one transition effect all the time. It defaults to randomly choosing from all the available ones. At least you can tone it down to just one. Automatic on/off time I liked that it was possible to configure operating times. No need to have the thing chewing power 24x7. It just seems to turn off the backlight outside of the programmed operating hours, so it's still doing the lame uber-frequent and bandwidth-intensive checking for updates even when it's "off". Photo check frequency is configurable Another nice feature was the ability to check for new photos at varying intervals. What I wanted for my parents was to just update once a day, so they'd get a new photo every day (assuming we put a new one in the Picasa web album that it's checking). This was very doable, and coupled with the automatic on/off time, means they should wake up to a new photo every day (that we change it). Built in photos are a bit too sticky There's 3 or 4 in-built photos as part of the firmware. If there's nothing accessible or available online, it'll cycle through these. Somewhat annoyingly, you need to have at least two photos in your online source for it to stop wanting to incorporate the stock photos in the mix. The workaround is to put the same photo in the online album twice, so you don't realise it's switching between two images. Lame, but it works... Touch screen UI was adequate Given the alternative user interface for digital picture frames is a little IR remote control and some dinky menus, the iGala was nice to configure. A full on-screen QWERTY keyboard pops up for entering WEP/WPA/WPA2 keys and configuring the Picasa/Flickr connections. Fairly responsive support The main near-showstopper for me was the lack of advertised WPA2 support. I emailed the Aequitech support folks quite a bit during my "evaluation" period. They got back to me fairly quickly most of the time and wanted to know exact details of my setup so they could reproduce it in the lab. They'd be well served having an actual ticketing system, instead of hiding behind an email address, as it made it hard to keep track of the multiple issues I was raising with them. It's written in Lua?! I have no familiarity with Lua, other than I know of its existence as a programming language. I'm curious as to what their motivation was for this language choice. All of the Lua code shipped in the complete firmware refresh ZIP files is bytecode. I have no idea if it's possible to decompile it. The CPU architecture would appear to be a Blackfin based on the few compiled binaries included in the full firmware. Easy to update Prior to the new update "functionality" I've already railed against, it was pretty easy to update. Download a ZIP file and a shell script, put them in the root directory of a USB key, and plug it into the frame and stand back. The updates don't seem to cryptographically verified (even the over-the-air ones), so I wonder if it's possible to break into the frame by way of a cleverly crafted "update". I have no idea what breaking into the frame would buy you. I don't know what sort of computing power they have. Conclusion I still think the iGala is a reasonable, if somewhat immature product. If the software is going to be actively worked on, and the support people continue to be responsive, then I think it's got good potential. For the price, I expected a more polished product, though. I received an email from their support people shortly after returning from Australia saying that they'd fixed the WPA2 problem. Unfortunately I had no intention of trying to remotely talk my parents through how to reconfigure their access point or the frame (interestingly WPA2 didn't work with their Linksys WAG54G2 either, so I'd love to know what WPA2 devices it was tested with), so it's 128-bit WEP until I next go to Australia.

Eclectic paper: dh-ocaml In my day job as a researcher, I mostly publish papers along the lines of my main research interests (theorem proving, web technologies, formal methods applied to software engineering, ...). Some time though, I just come up to some eclectic idea, not strictly related to my job, that I feel like cooking up as a paper to be reviewed by some scientific venue. It happened some weeks ago with dh-ocaml, the package implementing the new dependency scheme for OCaml-related packages in Debian. It took us (as in Debian OCaml maintainers) several years to get it right and satisfactory for maintainers, users, release team, etc. The problem which dh-ocaml addresses is that, differently than C and other system-level languages, OCaml breaks ABI compatibility very often, due to the need of ensuring type safety across different libraries at link time. Other similar strongly typed languages, such as Haskell, behave similarly. This is at odds with the implicit assumption of forward-compatibility (unless otherwise "stated", e.g. with soname changes) that is relied upon by versioned dependencies in distributions like Debian. This discussion, the analysis of possible solutions, and the description of the solution we have actually implemented in dh-ocaml (called ABI approximation) turned out to be interesting for the French functional programming academic community: the paper on dh-ocaml has been accepted at forthcoming JFLA 2010. It is no rocket science , but people maintaining programs and libraries written in languages with concerns similar to OCaml's (e.g. Haskell, hello nomeata) might want to have a look.

Earlier this summer, I wrote a blog post on taking a principled position on software freedom where I argued that advocates of free/libre and open source software (FLOSS) should take a principled position because the pragmatic benefits associated with open source --- "better quality, higher reliability, more flexibility [and] lower cost" in OSI's words --- are simply not always present. More often than not, FLOSS projects fail. When they survive, they are often not as good as their proprietary competitors. Over the last year, I've been back at MIT taking classes, reading extensively, and otherwise learning how to act like a social scientist. My research goals, which I'm now beginning to focus on, are to help build a stronger understanding of the social dynamics in free software and free culture communities. With a slightly skeptical view toward my involvement with groups like the FSF and my work in the FLOSS community, at least one academic tried to suggest that taking a principled position in favor of software freedom might compromise the positivist social science research program in which I am engaged. "An advocate is too biased," they said. After many months of thinking seriously about this warning, I believe that this criticism can be addressed. After all, a principled position in favor of software freedom is a statement of how things should be, not a description of how they are. OSI will argue that open source leads to inherently better software. This statement, of course, is one that can be empirically tested and, in fact, there seems to be plenty of evidence that it is often wrong. On the other hand, the FSF's position that software should be free is ethical in nature. One can disagree with it, just like one can disagree with any other ethical position, but it can not be proved either right or wrong --- only convincing or unconvincing, logical or illogical in the context a certain set of other values that others might or might not share. Research has shown that the vast majority of FLOSS projects fizzle. A advocate who argues that FLOSS is inherently better is left trying to explain this fact and make excuses. As a result, OSI-style beliefs can certainly be a source of problematic bias in a social scientist. However, a person who believes that software should be free is welcome to recognize that it both fails and succeeds and to ask why. A principled idealist can argue in favor of behaviors that may be disruptive, difficult, or inefficient. Indeed, Stallman has never suggested that free software will be easier or better. Indeed, he routinely asks people to sacrifice their convenience for freedom. My goal, as a social scientist, is to understand why some FLOSS and free culture projects succeed and why many fail. I never take FLOSS's success for granted and, in fact, believe that proprietary software may often leads to better software in OSI's terms. Unlike an advocate who tows the OSI line, embracing evidence of the effectiveness of proprietary software is no way in conflict with my belief that software should be free. In fact, my desire to see software freedom grow becomes the driving force between trying to understand FLOSS's shortcomings! I am no more biased --- which is not to say completely unbiased --- than the person who both thinks that crime is wrong and who wants to study criminal behavior. In an analogous sense, starting out with the belief that all people are naturally law-abiding may be a problem in a way that beginning with the belief that people should be law-abiding is not. Starting from the fomer assumption, one has to explain away evidence to the contrary. Starting from the latter assumption, one can build an understanding of what drives people to obey or violate laws which, in turn, can help build a stronger society. To me, the question is not why FLOSS will succeed. Indeed, I believe its success is an empirical matter that remains very much up in the air. For me, the question is how it might. Embracing a principled position lets us face the facts and puts advocates and practitioners in a position to devise laws, social structures, and technologies to insure that it does.

The story behind it Recently, I decided to set up a subscription with a VoIP provider, Phonzo, here in Norway. On their webpage, Phonzo advertised a VoIP service which actually gave you the SIP information and allowed the user to connect their own equipment to this service. That s really cool , I thought. I can play with Asterisk on the PSTN now! . They also advertised an offer with rent of a Linksys SPA2102 included, at a very affordable rate. Now, I suspected that the box might be locked as I d heard they were with some providers so I searched all over their webpage for any hint that it might be. None was to be found and since they included the specific model designation of the adapter rather than mentioning a generic Analogue Telephone Adapter , I basically assumed it wouldn t be crippled. But when it did arrive (impeccable delivery time, and telephony worked out of the box, btw), I found to my dismay that the box was indeed locked. So I sent a polite email to customer service, saying basically that I know this is a matter mostly interesting to enthusiasts, but they ve advertised an SPA2102 , and what I have receieved is a crippled SPA2102 . They basically replied It says rent , so it belongs to us. I replied Renting does not exempt you from marketing laws; you ve sold me something else than what I paid for . I got the reply: We can t open it, it contains sensitive information and it s not crippled, it s optimized for Phonzo service[sic] (!). Yeah, that s really what they said. A few more emails back and forth, and nothing of value came forth. When I received a letter from customer service saying Stop your nonsense, we re providing you a service and the adapter is a part of it I realized I wasn t getting anywhere there. I ve sent an email to the address in the SSL certificate (who also seems to be one of the founders) hoping I d get in touch with someone of relevance, but I don t have great hopes. (There s a copy of the correspondance in Norwegian, if you re interested.) So over to my plan B. The Linksys SPA2102 has two interfaces for an administrator: The first is the HTTP interface bog-standard, with an admin password. The second is the Interactive Voice Response menu you know the kind, Press 1 for x, 2 for y, . Now, this menu has several different options, including one to enable HTTP access on the WAN port . By default, this option is set to False, and changing it requires an administrator password. But how do you enter an alphanumeric password on a DTMF dialpad? Aha the admin passnumber is derived from the admin password! The mapping is 1=1, [2ABCabc] = 2, [3DEFdef] = 3, , (everything else) = 0. This reduces the keyspace quite dramatically! So basically, what I ve done is kludged together a shell script which tries the different combinations and sounds them out using a software DTMF tone generator, with earphones serving as acoustic couplers. (For now, I ve skipped numbers containing a 1 . The number 1 only represents itself, and thus its value is quite low.) It then tries port 80 on its WAN IP every 100 attempts to see if a passnumber has succeeded. The shellscript is accessible here: http://simula.gunkies.org/~toresbe/dtmfbruteforce.bash. The phone adapter has two lines, but the second one is locked by Phonzo however, it is not possible to disable the IVR menu on this thing, so I have full use of the box while this is happening. (It nearly goes without saying that I ve spoofed the DNS so it connects to my Asterisk box. ) I m now averaging about one passkey per second. According to my calculations of each passkey representing the number of symbols per digit raised to the power of the number of digits, I am trying 16807 passwords per second and will be trying 117649 passwords per second when I get to six digits. I have a quite technical readership so please do correct me in the comments if I ve made an error in either the calculations or anywhere else. If there are any Phonzo users out there with an SPA2102, I would very much appreciate it if you contacted me brute force works a whole lot better when it s parallelized. I am currently at #302362. I have not yet been contacted by anyone in the same situation.

This is it. We know the faces of people who will count in Europe during the 2009-2014 period. And we can count on them to make the EU weigh even less than it did until now. Jos Manuel Dur o Barroso, president of the European Commission. For 5 years, this ultra-liberal brought in his fanatic views of the free market, leading to unprecedented removals of regulations and legislations that could prevent large corporations to extort money from citizens. He holds a non-negligible responsibility on the (still unsolved) bank crisis of 2007. Yet, citizens voted en masse earlier this year for the EPP all across Europe, leading to his renewal. You get the commission you deserve. Herman Van Rompuy, president of the European Council. This is no secret that this transparent non-leader was the choice of Sarkozy after Tony Blair turned out to be an unsustainable choice. Yet, none of the 26 other members of the Council dared to raise a single finger against this choice. Sarkozy has completely lost his credit in France, but that doesn t prevent this council of cowards from trusting him, apparently. It s not as if there weren t good candidates, like Jean-Claude Juncker or Vaira V e-Freiberga. But having a competent, Europe-friendly president who actually knows his files and speaks many languages would have cast shadows on those who don t (see below). Catherine Ashton, foreign ministry of the EU. If there was any worse possible choice, I don t know which. This was the only position supposed to be affected to a socialist. And since the Labour party is still member of the PASD, despite their insane liberal economic policy and their full-scale paranoia leading to unprecedented freedom hunting in the UK, the position was given to someone from this party. And among them, they chose a person with a reputation of sloppiness and incompetence, who doesn t speak correctly a single foreign language. It is probable that, just like Van Rompuy s going to be Sarkozy s puppet, she s going to be the UK Foreign Office s servant. And we continentals all love the Foreign Office s policy, which is often in complete opposition to what the rest of Europe feels like. Jerzy Buzek, president of the European Parliament. You don t know him? Neither do I. A weak parliament goes with a weak parliament president. This way, the European Council has its hands free for behind-the-curtains arrangements, rather than letting the citizens representatives take action. Martin Schultz, president of the PASD group at the European Parliament. In order to ensure his place as president of the Parliament for the second half of the period, he betrayed his own people, and accepted any rotten compromise the EPP would propose for the key positions. Socialists have never been so weak in Brussels, and the total absence of leadership has something to do with it. Makes you proud to be European, heh? And of course you already know the real faces of Europe for the next years. Sarkozy, Merkel, Berlusconi, Brown. The main leaders from Western Europe, with their rotten governments who swore to slay any of the remaining personal freedoms in each of their countries. What a great image for EU in the world. What a great example to set. But again, you get the leaders you deserve. That s the whole point of democracy.

I ve just read an interesting post at Making Light about seat-belts [1]. In Australia seat-belt use is mandatory, you can be fined for failing to wear one and the police (who help clean up the mess when someone dies on the road) are apparently quite aggressive about enforcement. Even aside from the legal requirement the use of seat-belts is fairly ingrained in Australian culture, people tend to use them even when they won t get caught. One of the things I like to do in my spare time is to take unused computer gear from IT companies (which they regard as rubbish) and give it to home users for recreational and educational use. Due to that and my work for some smaller IT companies I ve helped many people load computer gear into their private cars and observed that most people will not take adequate care unless I coerce them. A CRT monitor tends to be large and heavy, you wouldn t want to get hit in the back of the head with one at 60Km/h. With some combinations of monitor and car you can fit a monitor in the front passenger foot-well, but usually the only place a monitor will fit is the back seat. The correct thing to do is to use the seat-belt to strap the monitor in place. It s most likely that the monitor stand (the only part that allows a seat-belt to be attached) would snap off in the event of a serious crash but this would at least slow the monitor down. Also don t put the monitor directly behind your seat if you can avoid it, put it behind the passenger seat. In a collision monitor might be able to push through your seat and cause you a back injury. Between 1992 and 2006 there were 78,000 acute computer-related injuries treated in US hospital emergency rooms [2]. The number of injuries caused by monitors peaked at 37% of the total in 2003 this was largely due to monitors falling on people. Even without the speed of a car a monitor can be a dangerous projectile. Hard drives have a lot of potential to cause damage, they are dense, hard, and the corners often aren t rounded. Storing them above the back seat behind the driver s head (as a friend once tried to do) is a really bad idea. Mythbusters showed that a box of tissues isn t going to kill you in a crash, but a hard drive is much more dangerous. The typical car glove box can store a few drives. If you need to transport a box full then the front passenger foot well is a reasonable place. If your car rolls then that would suck, but it seems that people usually die when they roll their car anyway so just try not to do that. A serious server (EG 2RU or bigger rack-mount) typically weighs 30Kg or more and is solidly constructed. The size and mass of such a machine makes it extremely difficult to safely store inside a car. The ideal place is the boot, but if that isn t an option then behind the passenger seat is the next best option. One final issue that I ve been wondering about is the safest option for laptops that are in use in a moving car. A 3Kg Thinkpad would have to hurt if it hit you in the back of the head at 60Km/h. The child-seat attachments are solid anchor points that can be used for other things. I wonder if a laptop security cable could be attached to one of the child seat points. According to an exhibit at a science museum I can throw a tennis ball at 115Km/h, so I presume that laptop security cables are designed not to break when someone swings the laptop at that speed. Therefore if a car was driving at a legal speed in Australia before crashing then a laptop security cable should be able to stop the laptop. Preventing the cable from injuring the passenger on the way would be the difficult part.

• [1] http://nielsenhayden.com/makinglight/archives/008845.html


• [2] http://www.tgdaily.com/content/view/42768/135/

I m back from Dallas, where I was invited at the Ubuntu Developer Summit for Lucid. I spent a great week there ; the event was extremely well organized (by organizing them every 6 months, you are probably able to gather a lot of experience!). Of course, after all I had heard about people hugging each other all the time in the Ubuntu community, I was a bit worried, especially with the flu spreading! But there are lots of fantastic people around Ubuntu, and it was a very nice opportunity to be able to meet them all. Since it was my first UDS (I was at FOSSCAMP in Prague a few years ago, but didn t stay for UDS back then), I was not really sure of what to expect. I was very pleasantly surprised. UDS vs Debconf UDS is very different from Debconf. In Debconf, we do three different kind of things:

• we hack, mostly on our own, in the hacklabs
• during talks, we report on what we have done recently
• during some talks or BOFs, we discuss future (possible) changes

In UDS, the main focus is on the third point: most of the sessions are about discussing what will be implemented for the next release. All of the relevant developers are in the same room to discuss possible problems, and the outcome of each session is usually a detailed plan, with a list of action items. It s a very nice way to ensure that changes are well thought, and allows making large-scale changes in Ubuntu very easily (you don t spend weeks arguing about them on mailing lists). Of course, it s probably also helped by the fact that there s a company behind Ubuntu, with a set of large teams (kernel, foundations, desktop, etc), which helps transfering trust (not everybody feel like they have to participate in each discussion, even when they affect the whole distribution: the team in charge is trusted by the rest of the project). On the other hand (yeah, let s be negative for a while) it doesn t really help spreading information between Ubuntu developers: it s often a bit difficult to get the global view of what is happening inside Ubuntu, especially since lots of things are discussed on IRC. Collaboration between Debian and Ubuntu During the week, I mainly was interested on collaboration between Debian and Ubuntu. There s a strong focus on doing the right thing wrt Debian (and also other upstreams). Then, of course, Ubuntu also has an agenda, which sometimes requires moving very fast on some things, or making compromises between technical purity and pragmatism. But the willingness to have common foundations between Debian Squeeze and Ubuntu Lucid will surely benefit both distros. Quality Assurance On the QA front, I am planning to do archive rebuilds for Ubuntu as well (fixing FTBFS is an easy way to start contributing to Ubuntu or Debian, and having those bugs fixed in Lucid would benefit Debian as well, by having patches already prepared). I also had a session with the QA team, where I gave an overview of what we are doing in the Debian QA group, to discuss opportunities for collaboration. The Ubuntu QA team focuses more on testing (with automated or manual testing) and bug triaging than archive quality that part is left to the MOTUs and the release managers. (About MOTUs, I liked how what they do was described as long-tail maintenance, landscape gardening or terraforming. That gives a good idea of what it s about). Ultimate Debian Database On the Ultimate Debian Database front, I did a plenary talk to try to demonstrate how UDD could be useful to Ubuntu as well, and, with Jorge Castro, we examined some metrics of Ubuntu s giving back to Debian. I also talked with the Launchpad team to try to resolve my long standing pretty please provide an export of Ubuntu bugs, so I can easily import them in UDD! issue. Ubuntu and ARM ARM netbooks and smartbooks (mix between netbooks and smartphones) are coming, and Ubuntu is clearly very well positioned to play an important role on that market. There was a whole track about ARM support, with lots of changes that will be done for Lucid. Let s all hope that Ubuntu-powered ARM netbooks win that market, so we don t reproduce the failures of the non-ARM netbooks. Distributed Development James Westby has been working on a set of tools to be able to work on Ubuntu packaging using bzr. The point is not to store the canonical source for Ubuntu packages in bzr (well, at least it s not the plan yet), but to provide a set of branches to make it easier to merge or cherry-pick from Debian. The resulting workflow looks extremely nice, with lots of syntaxic sugar. And even better, he assured me that his code is portable to Git ;)
Using his work, merging Ubuntu-specific changes in a new version of a Debian package basically means pulling from lp:ubuntu/foopkg, merging from lp:debian/sid/foopkg, and you are done!
As a bonus, we (Debian) would get bzr branches with the history of packages (kind of bzr-powered snapshots.debian.org).
James project is not completely ready yet, but should be very soon. It s already basically usable, apparently. Conclusion Ubuntu has clearly gone a very long way since 2004. Everything looks very well organized and polished, and gives the impression of a big machine that nothing can stop. With Cloud Computing and now ARM netbooks, Ubuntu has proven to be able to adapt to the current trends and attract a lot of visibility. It is great news for Free Software, but also proposes an interesting challenge to Debian: of course, it s nice that a Debian-based distro is in that position, but will Debian manage to stay relevant, or are we just going to be the technically-pure distro without many users that serves as a package supermarket for Ubuntu?

Just wanted to share comments on some movies I've watched recently.

• The hurt locker: about the days of a bomb disposal team in the war of Iraq; well done, entertaining, and it didn't trigger my oh-again-the-yanks-saving-the-day response.
• Gran Torino: cannot say much about this one, I loved each minute of it. Clint Eastwood is getting better every day; must see.
• The union: the business behind getting high: a documentary on cannabis, nice but not that interesting.
• Bienvenue chez les Ch'tis: a simple French comedy, nothing deep here. Nevertheless, I found the characters lovable, and now I'd like to visit Nord-pas-de-Calais.
• La m me: another French film, which I really enjoyed. Marion Cotillard is really impressive in her rendition of Edith Piaf.
• Death proof: ah, Tarantino, can't help enjoying, even though there was not much plot here.
• Les poupees russes: more French cinema. The sequel of "L'auberge espagnole" which wasn't that great is quite dull. The director doesn't get tired of trying to show off all these fancy edition effects, and instead of being clever, it looks silly.
• Der Untergang: disturbing, well done, enjoyed.
• Cidade de Deus: quite a surprise this one; dynamic, thrilling, great edition. Based on a real story, but goriest than Tarantino.
• Blade runner: I got a high quality copy, which was enough of an excuse to watch and enjoy it once again. A beautiful film in every sense.
• This is England: didn't know anything about This is England, and surprised me to see a film that touches on the war of the Malvinas (Falklands) from an English perspective, although that is not central to the plot. It revolves around a boy who joins a gang of skinheads, which was another surprise, as I didn't even know that the non-racist skinheads existed.
• Zack and Miri make a porno: funny, edgy, but they had to ruin everything with romance, bleargh.
• Happy together ( ): I think I liked it, but I'll need to see it again with readable subtitles!
• School of rock: I think I will never enjoy north-American comedies...

Tags: Planet Lugfi, Planet Debian

The difficulty with living on the Joey sleep schedule as the year wanes is finding enough daylight to have a satisfying day. The plan was to hike in the mountains, but my inbox said otherwise. Ugly new debhelper bugs. Looking at the hard one, I felt as if someone from 30 years ago was trying to take my day away. Why does make(1) not provide a way to discover which targets exist in a makefile? My hack to workaround that historical oversight was breaking, and make was nearly fork-bombing the system in the process. This seemed likely to eat my weekend -- I was very glad to find a quick, ugly workaround. By then it was 2:00. I'd not get to the mountain pass til after 3:00, which was pushing it. Almost stayed home, but it was such a nice sunny day, perfect weather. So I headed out. Spent half an hour along the way talking with an old woman about a well (long story), but reached the Roan with nearly two hours of daylight. And it was sublime. I realized I'd never stayed up there for sunset, so I hunkered down on a rock, finished checking my email (left over from the earlier hurry), and then spent half an hour chatting on the phone with my dad, as the sun inched down a finger at a time. When it went behind the other peak, and mist crept up the valleys below, it got cold and I hurried down. Reached the car in deep dusk, and coasted down the mountian while listening to a BBS nostalgia piece on the radio. On the way home, pulled in at the Ridgewood BBQ, and am sitting on the porch in the cold with about 50 other people, waiting for a seat (hopefully before it closes), and blogging. I accomplished everything I wanted to today, including getting something significant done, hiking, and spending quiet time on top of the world. Though only just, and feeling I was running late the whole time. Nice thing about the Joey schedule though, is I will have seven more hours of quiet time before sleep.

I can't simply put up any longer with all the shit thrown on the face being unable to do punish such bad behavior. There are just so many other things that increase my anger (like, for example, "WTH is python2.6 still not in unstable?!") that I don't need another one.

For sure, I don't advocate or encourage anyone to join the MIA team, and I'm speaking with a lot of experience... There is a proposal, from zack, to restructure how MIA works (another bright example of collaboration...): when will it be implemented? nobody knows. will it help? I don't think so (much).

My work (MIA work in general) was almost invisible, like invisible were all the harsh and aggressive replies I got. The nice part is that those replies came from people with the worst situation. Something like:

• me: "this package has no uploads since 2005", reply: "this package has no upstream release since 1983" - 1. probably is to remove? 2. what about all the bugs filed against the *Debian* package? 3. what about the gazillion of lintian errors and warnings on that package? 4. MIA doesn't contact about only 1 package (so maybe there's something more?)...
• me: "one of your packages has 4 RC bugs", reply: "it's team maintainer!!" - yeah, so let's pretend that since it's team-maintained 'someone else' (that's never you) will work on it.
  

and several other non-sense replies doesn't leave anything but a huge frustration in you.

And when you got really pissed off, and want to see some sort of reaction on such bad and unmotivated attacks and ask the "People with Powers", what do you got? "sorry, we can't do anything to help you, it's your problem". Something should be done to protect people from fuckheads, make them behave, or else kick them out of the project as far away as we can. But what we got is nothing (and nothing seems to be changing on this side).

Well, now it's not my problem anymore, it's someone else: in perfect Debian-style.

Russell Coker advocates putting -e on the shebang line of shell scripts. I disagree. From my experience this is extremely unhelpful to people who may be debugging your shell scripts in the future. Consider this, you've added -e to the shebang of a script, and some poor schmuck down the track is trying to debug why it spontaneously exits. What's the most obvious way to do this? Run the script with sh -x or bash -x. What happens when you do this? The shebang is completely ignored, and the script is directly run by the shell interpreter. If the person doing the debugging doesn't happen to transpose all of the shell options on the shebang line to the manual shell interpreter invocation, you're going to get different behaviour. So I advocate an explicit set -e on the second line of shell scripts instead. As much as making shell scripts set -e is a good practice, it drives me absolutely batty having to deal with scripts that spontaneously exit as soon as something they run exits non-zero. Particularly when you've chained a bunch of shell scripts together, or have one sourcing a bunch of script fragments from a directory. For this reason, I prefer to write in Bash and use an exit handler, to make it very obvious when a shell script has abended due to set -e.

For about a month or so Squid v3.1 is now in experimental ready to use and ready for getting tested by a wider community base. So I installed it by changing my sources.lists deb-src line to experimental instead of unstable, apt-get update, apt-get build-dep squid3 and apt-get -b source squid3. Compilation went fine and flawlessly on unstable. On stable/lenny you'll need to install squid-langpack as well from unstable.
After installing the resulting *.deb files, there was no need to change or update the configuration for squid3: if a request/domain lookup results in an IPv6 address, squid3 will use it and gives precedence over the IPv4 address. If there's no IPv6 address for that requested domain, nothing changes from the old behaviour. So, when a page is requested by an IPv4 client, squid3 will contact the site via the IPv6 address if possible and deliver the page to the client via IPv4. This is the same (and naturally expected) behavior as in polipo, another IPv4/IPv6 capable proxy. Polipo is a small proxy with less functionality than squid3, but it has some issues from time to time that needs a restart of its service. Additionally I would prefer just one proxy running on my system. So, now I'm able to just use squid3 for all of my proxy tasks again.

Using a IPv4/IPv6 capable proxy is by the way a good method to increase IPv6 visibility, especially when you fear the (amazing small) workload to deploy IPv6 in your own network.

Getting python2.6 as the default ASAP is currently the #1 priority for the Python modules team. I also consider it very important and tried to help with it, but it is starting to get depressing. The plan is to fix all packages in unstable to be compatible with python2.6 first. This would be easy if there hadn t been a very badly planned change in the installation paths that came together. Because of it, quite a number of packages have to be fixed. Two months ago, I filed a lot of bugs in that order. I missed a number of issues, but overall, almost all packages have been fixed, thanks to Kumar Appaiah, Bastian Venthur and everyone else who sent patches and NMUs. One of the biggest issues, though, comes from python-central. Since it doesn t handle some of the new paths that were introduced (which is somehow ironic, since the python-central maintainer, Matthias Klose, is also the python maintainer who did this change), a large number of packages FTBFS when built against python2.6. In Ubuntu, it turned out to be a giant mess, most packages using python-central needing changes, and we wanted to avoid that. This is why Piotr O arowski sent a NMU for python-central that fixes these issues for good. Guess what happened? Matthias Klose uploaded a new version that does not include the python2.6 fixes, completely discarding the work that has been done. And of course, making the upload of python2.6 to unstable, which was ready to be done in a few days, impossible. I think it s fine if Ubuntu maintainers don t have the time to handle their packages in Debian. But it is clearly not acceptable to hold back development in Debian, nor to treat it as a garbage dumpster where you can send all the crappy software solutions that were badly designed in Ubuntu to duplicate them in Debian. This is what Matthias has been doing for several years. For how long are we going to tolerate such behavior? For how long will we leave such a critical package in the hands of a single person with no interest in Debian?

Under UNIX, it is possible to get into a position where your shell's working directory is pointing to an inode that no longer exists, but a "newer" directory with the same name exists. The easiest way of reproducing this scenario is as follows: However, as concrete example, imagine you are debugging something deep inside a generated code tree if you ran make clean and then make again from another shell, your debugging shell would be left pointing to an inode that does not exist (as it was removed by make clean), yet the make call would have made an identically named directory in its place. Shells behave rather unintuitively in this situation; ls will (correctly) return no results, but attempting to do anything useful results in curious error messages. I use the following zsh precmd hook to transparently fix this for me: The cost of the stat calls seem justified by the convenience and are in any case insignificant compared to the other things I am doing in my precmd. If you are using zmodload zsh/stat, then replace stat -c %i with stat +inode. (My previous experience with zsh tricks is that the functionality invariably exists already in some obscurely named builtin. Here's hoping.)

This evening I investigated #555941 in libxml-filter-xslt-perl, and was able to downgrade it to "important". I'm working on a proper fix, but it's not RC any more. (Gunnar, I don't mean to make you feel bad! I've been inactive for a while myself - I'm just making up for lost time.) And now for conversation via blog! Clint, I'm inclined to agree about ego, fiefdoms and so on. But I'm unconvinced that personal relationships themselves are harmful. Actually, I was thinking more about "professional relationships" - I don't care much whether mentors take their mentees to an art gallery, provided they work with them over a period of time, and therefore get to know the quality of their packaging. (I was a bit careless in my phrasing last night.) Having said that, let's do that as well! Indeed, building relationships so that we don't flame each other to a crisp the rest of the year is the very reason we hold DebConf, right? (Apart from the beer. And the holiday.) I reckon the mentoring system would be more effective if we started thinking along these lines, and this in turn would help address the wider problem of resources within various parts of Debian. Maybe not directly, but it could free up other people to work on the complicated stuff. We could probably turn debian-mentors into a sort of "team" in its own right. (Apologies if someone's suddenly made debian-mentors active again behind my back.) And if I ever get approved by DAM (ahem), I intend to propose a deal to the debian-mentors list that each upload of an updated package will cost them one RC bug NMUdiff, and uploads of new packages will cost two. ;)

Today didn t exactly go as planned. Terah woke up feeling sick, and by mid-morning was really wanting a nap. Not that that is likely to happen with a 3-year-old and a 4-month-old in the house. I needed to visit the WSU bookstore sometime anyhow, so I suggested I d take Jacob to Wichita for awhile. Jacob had been talking of seeing the trains again for awhile, so he chose these overalls for the day: He wanted me to sing Home On The Range several times as we drove. We stopped at WSU first, and he enjoyed running down the wide sidewalks and trying to hide behind bushes. Then it was on to lunch at HuHot Mongolian Grill. Jacob chose his own ingredients (with some help from me). He chose fish, which noodles he wanted, and of course had some baby corn and carrots. He got a full bowl of ingredients, and of course his favorite part was watching them grill it. He polished off most of his plate, too. He had been talking about ice cream all day. In fact, mention Wichita to Jacob, and he ll almost immediately say, Shall we get some ice cream? I wonder who he gets that from Terah usually takes him to Cold Stone Creamery, but we didn t have enough time to go there. So we went to The Old Mill Tasy Shop, something of along-time local legend in downtown Wichita. Jacob enjoyed noticing that the old brick wall had holes in it while they scooped out his chocolate ice cream and my strawberry sundae. He was too busy devouring his ice cream to notice it came in a metal bowl until I pointed it out to him. Then it was off to the Great Plains Transportation Museum. It was a quiet afternoon in November; not the packed crowd like the last time we were there. He went for the old Santa Fe diesel passenger locomotive first (which he insists is a freight train ). Of course you get to go inside almost everything, and he enjoyed going inside that one, sitting on the engineer s chair, and playing with handles and knobs. We went in several of the cabooses, and he noticed the train potty in one. It s the old open to the ground type, and if you look down inside it, you see the rocks that are underneath the caboose. Jacob thought it was very interesting that the train potty has rocks in it. The museum is right next to some active freight tracks, and Jacob was very much hoping that there d be a freight train going past. He wasn t disappointed; we saw two, plus an airplane and a helicopter. A successful visit, I d say. <object classid="clsid:D27CDB6E-AE6D-11cf-96B8-444553540000" data="http://www.flickr.com/apps/video/stewart.swf?v=71377" height="267" type="application/x-shockwave-flash" width="400"><param name="flashvars" value="intl_lang=en-us&amp;photo_secret=8517185815&amp;photo_id=4104904370"><param name="movie" value="http://www.flickr.com/apps/video/stewart.swf?v=71377"><param name="bgcolor" value="#000000"><param name="allowFullScreen" value="true"><embed allowfullscreen="true" bgcolor="#000000" flashvars="intl_lang=en-us&amp;photo_secret=8517185815&amp;photo_id=4104904370" height="267" src="http://www.flickr.com/apps/video/stewart.swf?v=71377" type="application/x-shockwave-flash" width="400"></embed></object> So I didn t really get done anything I had planned to today, but in spite of being behind on stuff, it s a better day than I had planned. I really enjoy going off and doing things with Jacob. While we were eating lunch, I asked him if he had fun at the bookstore. Yeah! I have fun EVERYWHERE! What a fun perspective, huh?

I've spent chunks of the last couple of days fighting a problem that's existed for about 25 years. The 8086 was a 16-bit processor with a 20-bit address space, limiting the maximum physical address that could be accessed to 1MB. However, quirks of the segmented memory system meant that addresses greater than 1MB could be constructed - these would wrap around to the bottom of memory. Because loading the segment registers was a time consuming operation, some programmers used this behaviour as a performance optimisation.

The 80286 introduced 24 bit address space. Unfortunately, this meant that the addresses that previously wrapped to the bottom of memory now pointed at real addresses - not ideal if you were expecting the old behaviour. IBM fixed this by tying the 21st address line (A20 - they're zero indexed) through an and gate, with the default behaviour being to keep it tied at 0 and thus maintaining the old wraparound behaviour. Applications that wanted to access the full address space needed to enable the A20 logic gate. IBM didn't want to add any extra hardware to their system if they could avoid it, so tied the other side of the and gate to a spare pin on the keyboard controller. By writing a couple of bytes to the keyboard controller, your PC-AT stopped pretending to be an XT and gave you access to all of the insanely expensive RAM it had stuffed in it. Hurray!

PCs have been emulating this behaviour since the AT was first cloned. Of course, this being the PC industry, many have got it wrong. There's a set of approaches for controlling the A20 gate that may work, varying in terms of performance and desirability. Most hardware will give the desired result (ie, I have no desire to run DOS executables from 1982, make my A20 work damnit) using any of the various methods of A20 enabling. Some hardware doesn't. The most common method used in bootloaders (where we still have access to system BIOS services) is to call int 15h with an ax of 0x2401, which asks the BIOS to enable A20 for us. This isn't implemented on all hardware, but we should get a failure back that lets us go and bang on the keyboard controller in an attempt to get it to pay attention[1].

Enter the Kohjinsha SC3.

I picked this up second hand in Japan. It's a ridiculously cute little tablet, only slightly larger than hardware that's comfortably in the MID range. It booted a Fedora liveCD perfectly, though having GMA500 graphics meant that what appeared wasn't terribly attractive. Installation proceeded happily enough, followed by a reboot and... nothing. Grub loaded the kernel and initrd, jumped to the kernel and everything hung.

So, for the past couple of days, I was stepping through the kernel setup code, trying to work out where and why it was hanging. I'd got it narrowed down to the region where the kernel tried to free the memory used by the initramfs, but the failure hopped around depending on my kernel build. Something was clearly very wrong. The strangest thing about this was that if I booted the liveCD boot menu and selected "Boot from local drive", everything worked perfectly. isolinux was clearly doing something that grub wasn't, but there's rather a lot of code to step through there.

Things became a lot easier once I found that the OpenSuse version of grub worked. Their grub has a rather smaller set of patches than ours, and only a few looked even plausibly relevant. It only took ten minutes or so to figure out that it was one that altered the A20 code. Things became much clearer then.

The main functional difference between the Suse A20 implementation and the upstream one[2] is that the Suse one explicitly tests whether the A20 enabling worked by putting values at two different addresses that would be the same if A20 is disabled. By comparing them, we know whether A20 is working properly or not. If not it can then fall back to other mechanisms. The Fedora code trusted the BIOS's claim that the int 15 call had worked. The Kohjinsha's BIOS lied, A20 remained disabled, grub copied the kernel and initramfs to chunks of address space that contained lies rather than RAM and everything fell over horribly.

Thankfully, not a difficult fix once the problem was identified. But seriously, people. How hard can it be not to screw this up?

(For an excrutiatingly detailed analysis of how hard it can be not to screw this up, see here)

[1] the Intel Macs don't implement the int 15 approach, but return a failure. They also don't have a legacy keyboard controller, so attempting to hit that resulted in grub falling over. The magic IO port approach works. Another example of how the Intel Macs aren't really PCs...

[2] grub2 implements the more paranoid check