We've had sporadic Altus Metrum customer reports about RF susceptibility issues with their TeleMetrum installations. In almost every case, these problems have been completely resolved by either making sure the system battery has sufficient charge before launch, or through the application of standard engineering techniques such as twisting wire pairs to reduce differential coupling. However, even when every technique we could think of had been applied, once in a while someone still had issues. Around the time of LDRS this year, the incidence of such reports seemed to increase. One customer, in particular, had an installation in which he virtually always saw continuous resets of the board once his 54mm airframe was put on a launch rail, and several customers reported seeing board resets during ejection charge firing. Keith and I saw a board reset during main charge firing happen in person at NCR's Oktoberfest, and with a couple days available to work together after that launch, we decided it was time to figure out what was really going on. Here's what we've learned. In bench testing, it quickly became clear that the problem was the 3.3 volt power supply rail getting pulled down far enough to reset the CPU. This most frequently happened during ejection charge firing, when the input of the LDO regulator is pulled down by the near-short presented by the e-match when a pyro FET is turned on. To keep the 3.3 volt rail voltage up during firing, we include a 100uF bulk capacitor on the regulator's output. In all of our prior bench testing, we never saw the 3.3 volt rail droop significantly. Clearly something had changed... or maybe several things had changed? The first thing I wondered about was whether the new Kalman filtering code, which requires more compute cycles from the processor, might be consuming enough more power to pull the rail down faster during charge firing. After poking around at it, though, we have no data to suggest the new code makes a measurable difference in power consumption. The next thing we pondered was that at least some of the e-matches we and others are using in the hobby now come from the fireworks industry, where it is apparently considered a feature for the match to retain continuity after firing. This means the input of the LDO gets held down for longer than with the e-matches we used to use and Quest Q2G2 igniters that open when fired. But that still didn't make sense as the root cause, as we chose the FET firing time such that even with a dead short across the igniter terminals, the 3.3 volt rail wouldn't be pulled down far enough to cause trouble during firing. One of the big changes between v1.0 and v1.1 on TeleMetrum was that the newer boards incorporate a better reset circuit. This helps ensure the GPS chip always comes up running at power on, which was a problem at temperature extremes with older boards. However, a side-effect of this change is that a v1.1 board will reset any time the 3.3 volt rail drops below 3.15 volts, whereas older boards didn't trip until a much lower voltage. So the recent increase in reports might just be related to more v1.1 boards being placed in service? While experimenting on the bench, we observed that injecting RF energy into the input of the LDO regulator had the effect of pulling down the output voltage, presumably because the internal reference source accumulates charge and is fooled into thinking the output is too high. Since our designs all have the power switch contacts ahead of the LDO, the wires going out to the switch and back are effectively an antenna... as are, to a lesser extent, the wires going to the e-matches. There is some variability from part to part in just how badly the LDO reacts. But by attaching a tuned length of wire as an antenna to the LDO input and playing around, we were finally able to reproduce the problem reliably on a test board at my bench! On further analysis, we realized that the output of the USB battery charger chip and the input of the LDO both expect a 1uF bypass cap to ground. At some point, those looked redundant and we eliminated one of the two. Unfortunately, we weren't internalizing the fact that the switch leads were between the two caps, and the one we left was on the output of the charger and not at the input of the LDO. Placing a suitable bypass cap right at the input of the LDO turns out to have a truly dramatic effect on RF immunity! Once we realized that RF getting into the LDO input was the problem, Keith pointed out that we used to see "noise" in the accelerometer data on earlier boards that was caused by the 3.3 volt rail moving slightly during radio transmit, which we fixed with a hardware change on v1.1. We are now convinced that this was at least partly related to RF coupling to the LDO input, not just the change in power consumption on the LDO output. We didn't realize what was going on in earlier testing because we often didn't have ematches wired up, so RF coupling was minimal. But going back to flights logged with v1.0 boards that included deployment, and studying the magnitude of the "steps" in acceleration data observed when the transmitter was on, Keith was able to compute the amount the 3.3 volt rail must have sagged if the real acceleration wasn't changing... which in some cases was as much as 180mV! We think this proves that RFI could cause the LDO to drop its output voltage below the reset controller set point on v1.1 boards. Based on these observations, I'm making two hardware changes for the next version of TeleMetrum (version 1.2), and Keith is also making a software change. We have tested all of these changes on real boards both on the bench and in test flights, and the net effect is a major improvement in the RF immunity of TeleMetrum. The first hardware change is moving to a slightly lower trip voltage on the reset controller. Instead of 3.15, the new part trips at 3.00 volts nominal. This gives us more "headroom" to tolerate 3.3 volt rail droop during charge firing, and will allow the board to operate longer on a given battery charge. This change is not relevant for v1.0 and prior. The second hardware change is adding an appropriate bypass capacitor right at the LDO input. This requires a PCB update, but it's possible for me to update existing production boards by adding an 0402 cap right across the appropriate pins on the regulator chip. The software change prevents our altimeters from turning on the radio transmitter while an ejection charge is firing. Since the RF transmitter draws substantial additional power, this should help keep the 3.3 volt rail from drooping. This may not really matter, but it feels like the right thing to do. This change will be part of our next stable firmware release. We think most TeleMetrum customers need not worry about these updates. But if you have seen odd resets on the rail or during ejection charge firing in flight with a TeleMetrum v1.1, feel free to contact me about updating your existing board to include these improvements.

Back in the dark ages of the web, before the introduction of CSS 3, browsers could only display fonts available on the client system. Thanks to the introduction of @font-face and its now widespread support, this is over. Now, Web designers have access to a large selection of fonts and most users will be able to appreciate them. Typekit provides a subscription-based library of hosted, high-quality fonts to use on websites. I expose here my own, mostly uneducated¹ on the typographic side, look on this service.

Fonts embedding 101 There are several ways to embed fonts for the Web. Let s have a look at the most common ones.

Self-hosting and @font-face A first possibility is to host fonts yourself and provide a CSS file with the appropriate @font-face declarations. There are five important things to know:

1. There is no common format. You will need to host different versions of the same font to support most browsers.
2. Of course, Internet Explorer comes with its own quirks that you need to work around.
3. Most browsers enforce a same origin policy. You need to serve your fonts from the same domain as the requesting page. You can circumvent such a limitation by enabling cross-origin resource sharing: add an Access-Control-Allow-Origin header when serving fonts.
4. Fonts are unlikely to change. To leverage caching, configure an explicit expiration date far in the future. Something like 30 days.
5. There is no MIME types registered for fonts. Don t bother setting one, even if Google Chrome likes to complain about them in the console.

One great resource is Font Squirrel which provides kits with fonts and the appropriate CSS declarations. You choose your font family (or upload one of your own), the formats that you want to use (check them all) and you will get a ZIP archive with all fonts and a CSS file. You may want to tweak it a bit to enable automatic use of the bold variant when needed and to use a local copy if available. For example, if you choose Crimson, an oldstyle typeface, you may want to declare the bold version with font-weight: bold and add local names:

@font-face  
    font-family: 'Crimson';
    src: url('Crimson-Bold-webfont.eot');
    src: local('Crimson Bold'), local('Crimson Text Bold'),
         url('Crimson-Bold-webfont.eot?#iefix') format('embedded-opentype'),
         url('Crimson-Bold-webfont.woff') format('woff'),
         url('Crimson-Bold-webfont.ttf') format('truetype'),
         url('Crimson-Bold-webfont.svg#CrimsonBold') format('svg');
    font-weight: bold;
    font-style: normal;
 

Google Web Fonts For open-source fonts, you can also use Google Web Fonts instead of hosting the files yourself. Build a collection of fonts and choose the variants that you want to use for each of them. You will then be provided with a code snippet to paste in the <head> element of your page. For example, for Crimson:

<link href='http://fonts.googleapis.com/css?family=Crimson+Text:400,700,400italic'
      rel='stylesheet' type='text/css'>

Why choose this solution over self-hosting?

1. You don t use your own bandwith to serve fonts. This may be important if you pay for it.
2. Google uses its own CDN to serve fonts. If you don t use a CDN yourself, this can be a major performance improvement.
3. Caching is more efficient since many sites will use the same font.
4. It s easier to do it right.

Unless you are concerned about Google tracking your users², I think this is a better solution than self-hosting. Quick delivery of fonts is pretty important since content rendering can be delayed by them.

Paid services If you would like to use commercial fonts, like Adobe Minion Pro or Paratype Futura PT, a convenient option is to rent them. Typekit is service providing such an option. Pricing depends on volume and the number of fonts you want to have access to. There is a free plan and the first paid plan is US$24.99 per year. Other similar services exist. Feel free to compare. Once registered, the workflow is similar to Google Web Fonts. You choose your fonts, assemble them in a kit and publish it. Instead of directly providing a CSS file, Typekit provides some Javascript which will in turn download a CSS file containing all fonts in the appropriate format for the browser (on most browsers, fonts are inlined).

<script type="text/javascript"
        src="//use.typekit.com/tyt0atd.js"></script>
<script type="text/javascript">
  try Typekit.load(); catch(e) 
</script>

Typekit: the good parts So, why choose Typekit? First, there is the very large choice of fonts. The first paid plan comes with more than 500 fonts from about 80 foundries. There are about a hundred serif fonts and a couple hundred sans serif ones. Typekit provides a convenient interface to browse fonts. You can either search fonts by name or by characteristics. In the last case, you can filter on properties like the classification (serif, sans serif, decorative, etc.), weight, width, contrast, x-height, recommended use or language support. Once a font is selected and added to your kit, you can easily choose what variants you want. The kit total size is displayed. If you happen to meet any problem or have some questions, Typekit support is very responsive. I got clear and crisp answers in less than a few hours in the week-end.

and the bad ones Unfortunately, Typekit has also some shortcomings. One of the most commonly cited is that Javascript is mandatory. No Javascript, no fonts. If you want to display the appropriate fonts for users without Javascript, you should just not use Typekit.

Not free, nor free While Typekit offers some open-source fonts, most of them are not. Moreover, only a few of them are available in the free plan. While I would prefer to use open-source fonts, I don t consider this a strong requirement: if you are dissatisfied for some reason, switching back to open-source fonts (or another service) is fast and easy. I like serif fonts a lot and they get less attention from the FLOSS world: it is difficult to find one whose readability on screen is excellent. Droid Serif is a nice font but is a bit too black for me. Maybe Cardo would be a good match. You may disagree and in this case, Google Web Fonts or self-hosting seem the perfect match.

Difficulty to choose and test fonts While browsing fonts is easy and smooth, choosing and testing them is another matter. For example, Typekit is missing some interface to compare font rendering for whole paragraphs at a given size. It also misses a way to check how two fonts render together, one for headings and one for paragraphs. Here, Google Web Fonts is more versatile. Things become really difficult when you want to test your selected fonts for real. Except if you have invested into one of the expensive plans, you can only include a limited number of fonts in your kit. Each time you want to try another set of fonts, you need to modify your kit and wait for it to be distributed across Typekit network. You may have to wait five or ten minutes between each change! Another inconvenient thing is that once you publish your site, any change to the kit will affect the published version. Therefore, you need to use a second kit for development and play back and forth with those two kits. What would be convenient here is a special kit with all fonts from the library with restricted access to some IP to avoid abuse. This is something done by Fontdeck, a competitor.

Poor subset support Because you want to keep the font size small (about 30 kB for each variant), Typekit usually proposes two subsets: the default one contains only latin characters and the complete one with all glyphs. If some glyph is absent from the default subset, you need to use the complete one which is roughly two to four times the size of the default one. This is a bit huge for only one character. What would be nice is to have subsets for each language. In my case, I would take a French subset because I need the glyph which appears in French in words like c ur (heart or core) or il (eye). I don t want to select the complete subset just for this character. When a glyph is absent, the next font in the CSS stack is used. For example, if the selected font is FF Tisa Web Pro and the next font in the stack is Droid Serif, here is how the word c ur may be rendered. On the first line, FF Tisa Web Pro contains the appropriate glyph. On the second line, the glyph is absent and taken from Droid Serif. Since x-height and contrast are a bit different, the replaced glyph seems out of tone. At small sizes, the difference accounts for more than 10%. I have also added a third line where the ligature is built from o and e and the following style is applied to e :

.lf-ligature  
    margin-left: -0.172em;
    zoom: 1; /* Here to trigger hasLayout on IE7 */
 

As you can see, the result seems good. I have a piece of Javascript turning a ligature into the appropriate markup. It can be extended to handle more ligatures and could be adapted to handle other composed characters (like the ones in Anton n Dvo k ).

Defective caching Because a document can only be rendered after the fonts have been loaded³, it is pretty important to deliver fonts as fast as possible. Typekit uses Edgecast as a CDN and DynECT for DNS hosting. Two files are downloaded. Both of them are hosted on use.typekit.com. The first one is a script that will act as a loader. Based on the characteristics of your browser, it will choose how to download the requested fonts for best rendering. The second file is generally a big CSS file containing the fonts. Here are the headers returned for the first file:

HTTP/1.1 200 OK
Accept-Ranges: bytes
Cache-Control: max-age=300
Content-Encoding: gzip
Content-Type: text/javascript
Date: Tue, 08 Nov 2011 18:34:16 GMT
ETag: "388467610+gzip"
Expires: Tue, 08 Nov 2011 18:39:16 GMT
Last-Modified: Sat, 05 Nov 2011 09:31:57 GMT
Server: ECS (cdg/D624)
Vary: Accept-Encoding
X-Cache: HIT
Content-Length: 7440

First, notice that the content is served compressed. Good point. The next headers to look at are Cache-Control, Date, ETag and Expires: the server requests the content to be cached for 5 minutes. When the browser notices that its copy is out-of-date, it will issue a new request including a If-None-Match: 388467610+gzip header. Unless the kit has been modified, the server will answer with 304 Not Modified and no content. The copy of the browser will be valid for another 5 minutes. This means that after 5 minutes, at least 3 round-trips are needed to check if our fonts are up-to-date. Worse, sometimes, Typekit servers may be just slow. They can wait one second before answering, just to send a 304. Since the first file is a script embedded in <head>, the whole page is blocked until you get the answer. Here is an illustrative example with Chromium 14 where a page using Typekit is loaded while all static assets are in the navigator cache and things have gone wrong (which is pretty rare): Since fonts are needed, the rendering has been paused for 3.5 seconds until Typekit was fully loaded. If we look more closely, we may also notice we got a status 200 from the server instead of 304. Here is an excerpt of the browser request:

GET /tyt0atd.js HTTP/1.1
Host: use.typekit.com
Connection: keep-alive
Accept-Encoding: gzip,deflate,sdch
If-None-Match: "2200251225+gzip"
If-Modified-Since: Thu, 10 Nov 2011 11:38:11 GMT

And here is an excerpt of the answer headers:

HTTP/1.1 200 OK
Accept-Ranges: bytes
Cache-Control: max-age=300
Content-Type: text/javascript
Date: Fri, 11 Nov 2011 17:10:03 GMT
ETag: "2200251225"
Expires: Fri, 11 Nov 2011 17:15:03 GMT
Last-Modified: Thu, 10 Nov 2011 11:38:11 GMT
Server: EOS (lax001/54E5)
Content-Length: 25755

What happened? For some unknown reason, the server denied the access to the compressed version of the resource: there is no Content-Encoding: gzip while the browser did send Accept-Encoding: gzip. The tag provided by the browser (2200251225+gzip) came obviously from the compressed resource and therefore does not match. RFC 2616 requests If-Modified-Since header to be ignored if the tag does not match. Consequently, the server answers with 200 OK and resend the whole file. The same problem happened with the CSS file. Let me stress again how important the problem is: we had to download again the two files but we also downloaded the non-compressed version. Now, let s suppose that we did not run into this problem and the server answered with 304 Not Modified. The result is still not satisfactory: we would have waited 1.3 seconds to get both answers from the server. Keep in mind that most of the time, Typekit is pretty fast. Here is how I think this should have been done: each time you modify your font kit, you get a new URL to use (containing the version of the font kit for example). This resource and the associated fonts (whose URL is also versioned) are requested to be cached for several days. As a sidenote, this also enables to modify a kit for your development environment without modifying the kit for your production site. I suspect that Typekit did not go this way to track kit usage more accurately and enforce the appropriate pricing. Having multiple versions of the same kit would also allow us to use more fonts that we are paying for. UPDATED: Typekit support knows the problem and is working on it:

You ve identified a small bug in our CDN provider that we re working with them to fix. Hopefully I can give an explanation of what s happening. The CDN edge servers have a cache of recently served kits on them. Any request that is served from that cache will be correctly Gzipped and handle ETags. Unfortunately, if the content isn t already in cache and needs to be fetched from the master origin server then the request won t be gzipped correctly which has the side effect of breaking ETags. [ ] We are working to on getting this bug fixed, but any change to a globally distributed CDN will take some time. We re also working on having our content cached longer than 5 minutes whilst still allowing people to quickly update their site.

Conclusion I have mixed feelings about Typekit. While the difficulty to test fonts and the lack of language-related subsets are annoying, I have been able to work around them. However, the caching problem is more annoying. I am still considering going back to Google Web Fonts just because of this.

---

1. While I have a high interest in typography, have my own copy of The Elements of Typographic Style by Robert Bringhurst and have throughly read The Elements of Typographic Style Applied to the Web , I am still fairly novice on this matter.
2. Google serves fonts from a cookie-less domain. Technically, they could still do some kind of tracking but I believe they don t.
3. In fact, browsers have different strategies on how to render before fonts availability. Paul Irish wrote a comprehensive article on FOUT. One common strategy is to render a blank space until downloaded fonts are available. If this takes too much time, fallback fonts may be used.

Debian's libvirt in unstable finally passes the Technology Compatibility Kit (libvirt-tck) for qemu:///system:

Files=59, Tests=1579, 315 wallclock secs ( 0.77 usr  1.02 sys + 31.40 cusr 10.14 csys = 43.33 CPU)
Result: PASS

We're running libvirt's internal test suite since 0.9.0 but this doesn't launch any real virtual machines to check things like suspend, resume, snapshotting, migration and it doesn't create storage pools and volumes or networks. This means a lot of testing was done manually with each release. libvirt-tck provides a framework to perform these kinds of integration testing between libvirt and it's drivers, comes with hundreds of testcases already and it's easy to set up since it's available in experimental:

apt-get install -t experimental libvirt-tck

Edit /etc/libvirt-tck/default.cfg if you don't want to use the default connection URI. Then just run libvirt-tck:

libvirt-tck

Since this is supposed to stress libvirtd and the hypervisor and since it creates and deletes storage pools, networks and virtual machines it's recommended to run this on a dedicated system to make sure the tests don't blow away any precious config. If a test fails one can debug that single test using:

LIBVIRT_TCK_CONFIG=/etc/libvirt-tck/default.cfg prove --verbose /usr/share/libvirt-tck/tests/hooks/051-daemon-hook.t

This already revealed errors in our package like a missing parted build dependency breaking the creation of disk based storage pools, bugs in libvirt, crashes in QEMU and minor errors in the test suite itself. We're currently cheating a bit since the tests for hooks and nwfilter are currently disabled due to license problems with the used Perl modules. libvirt-tck can easily be integrated into Jenkins since it can now use libtap-formatter-junit-perl to generate JUnit XML. To do so simply configure a free-style software project to execute these commands:

rm -f libvirt-tck.xml
sudo libvirt-tck --timer --format junit --force > libvirt-tck.xml

allow Jenkins to run libvirt-tck as root

jenkins ALL=(ALL) NOPASSWD: /usr/bin/libvirt-tck --timer --format junit --force

and configure it to publish a JUnit test result report. Currently I'm only running the tests for qemu:///system so any help running and debugging this for LXC, VirtualBox or XEN is very welcome. Many thanks go to Salvatore Bonaccorso for packaging the missing Perl modules needed by libvirt-tck.

See also parts 1, 2, 3, and 4. This is the biggest highlight of our trip to Greece for me. I enjoy having the chance to meet people, visit for awhile, and make new friends and that certainly happened in Greece. In one of the shops we happened to step into, I noticed a radio behind the counter. That s not unusual itself; radios often catch my eye these days. But this radio was tuned to 21.070, an amateur radio frequency. So I asked the shop owner if he happened to be a ham. And indeed he was. He was Lakis (SV5KKU), and Terah and I had a great time visiting with him. Terah took some photos of us, and then we made our purchases and headed out. I had brought my HT (handheld radio, weighs a few ounces and is powered by batteries) with me, and Lakis told me about the repeaters in the area. I had known about some of that since I had emailed Panos of the amatuer radio club in Rhodes before leaving home (I found his name via Google). A couple of days later, on Tuesday, we found ourselves back in Lindos. It was mid-afternoon, so the shops were quiet. After a late lunch, I thought it would be nice to drop in on Lakis one more time, since we were scheduled to fly back the following morning. I m not sure how long we stayed it must have been at least an hour and enjoyed the fresh orange juice he prepared. After we got back to our hotel Tuesday, I learned that our flights on Wednesday were canceled due to a nationwide air traffic controller strike in Greece. After 3 hours on the phone with Delta (more on that experience later), we got rescheduled to fly back Friday. On Wednesday morning, I remembered that the Rhodes amateur radio club meets every Wednesday evening, and now I would be able to go! I knew how to contact Lakis by email and on the radio, and he kindly offered to pick me up and take me there. So that evening, I got a tour of his impressive mountaintop installation, and then it was on to the club the Radio Amateur Association of the Dodecanese (SZ5RDS). There I met Panos, whom I had emailed earlier (and I think surprised him a bit). It was a friendly group, and they translated into English for me every so often so I knew what was being discussed. When I was about to leave, they gave me this: The translation, partly from my memory and partly with the help of Google Translate, is:

Radio Amateur Association of the Dodecanese, SZ5RDS Our friend and radio colleague KR0L JOHN GOERZEN, who visited the island, has our recognition as an HONORARY CLUB MEMBER. PRESIDENT KAVALAKIS PANAGIOTIS SV5AZK (Panos) SECRETARY PAPADIMITRIOU CHRISTOS SV5DDT RHODES Oct. 5, 2011

(I hope that any Greeks reading this will send me corrections.) I truly appreciated that gesture and meeting all the people in the club. On the way back to the hotel, Lakis and I stopped by a restaurant, which I believe had the best souvlaki I ve ever tasted thanks! We brought some back for Terah. She had chosen to stay at the hotel that evening and had a small hotel meal earlier, but enjoyed the souvlaki and pita. Terah had explained to the ma tre d that I wasn t along that evening because I had gone to an amateur radio club meeting. Judging by the surprised reaction, this was probably the first time they had heard that particular comment! Experiences like this make travel fun and worthwhile. Thank you very much, Lakis and everyone in the club I hope to have a chance to visit again.

Today I was removing KDE from my laptop, when I realized that kde-window-manager would not go away (even when it was automatically installed) since it provides x-window-manager, which is needed by gdm. I manually removed it, but that got me thinking that maybe I had other packages that were in this situation. So I picked aptitude and tried to build some search-fu. Here is the resulting query:

aptitude search '?for x:

 ?x:installed

 ?x:automatic

 ?x:provides(?virtual ?reverse-depends(?installed))

 ?not(?x:reverse-depends(?installed(?depends(?=x))))'

Now, lets go over the query. The first part ?for x: allows us to refer to the package currently being matched. See the documentation for details. We'll see later why we need this. Basically we are saying: give me all packages x that match the following pattern. The second and third parts are trivial: we only want automatically installed packages.
The fourth part, ?x:provides(?virtual ?reverse-depends(?installed)) was easy: find all packages that provide a virtual package that is depended upon by some other installed package.
The fifth and final part, ?not(?x:reverse-depends(?installed(?depends(?=x)))) is why we needed the bound variable x. We want to filter out (hence the ?not) the packages that have some reverse dependency that depends directly on the package x. That way, in my case, metacity won't show up since gnome-core directly depends on it and is installed.

Unfortunately, this query doesn't grok alternative dependencies. For example, if gnome-core depended on metacity x-window-manager then this query wouldn't show metacity, since it is depended upon by a package. If someone can make this query understand that so that it only eliminates packages directly depended upon with no alternatives dependencies, please let me know!Tags: aptitude, cleaning, tip, tips

This blog post isn t only directed to ThinkPad owners as most notebook Linux users with Intel Core Duo 1/2 and i3/i5/i7 processors have been affected by this bug if not all. And yes, this problem is present on latest Debian Unstable and Ubuntu 11.10. Prelude I m owner of Thinkpad X300, great machine except the fact that just recently I replaced its 3rd cooling fan! Yea, I do a lot of compiling and it s on all the time, but still this kind of things shouldn t happen. I first linked this problem to the fact that Thinkpad fan on Linux (as of 2.6.22) always works at what s its basically maximum RPM, thus the reason there are numerous fan control scripts. My favorite one is Thinkfan, but controlling fan doesn t really help if you have a overheating problem. For matter of a fact it working on its maximum speed might only help, with its own toll. As of kernel 2.6.38 up until 3.1 (still present) there has been a problem of power regression but besides this I had slight problem with overheating. Regarding overheating in beginning I tried reporting bugs, tried different Thinkfan configurations, blamed proprietary software such as Adobe Flash for spiking up CPU temperature, however this problem was somewhat solved. After numerous battery calibrations and as these didn t work in the end for battery life getting poorer with each day, I just blamed the factor that notebook was getting pretty old (~3 years). Then the consumer woke up inside of me and I thought it was time to get new notebook. I laid my eyes upon ThinkPad X1 thing of beauty except one mayor drawback, its price. I did some reading on X1 and interesting enough, X300 comes with Core Duo 2 L7100 but overheating + power regression was still present even on latest Intel Core I* series. Reading this killed the consumer and woke up the hacker side. Solution Initial workaround to the problems of power regression is to add pcie_aspm=force besides existing GRUB boot arguments, this did help to some point but what really helped in both cases was also adding i915.i915_enable_rc6=1 or at least I thought so since this line only applies to Sandy Bridge (i3/i5/i7) and latter. In the end my /etc/default/grub looks like:

GRUB_CMDLINE_LINUX_DEFAULT="quiet splash pcie_aspm=force i915.i915_enable_rc6=1"

and make sure you run update-grub after making these changes. Besides the arguments I used there are other ones you can use and for more info please head to Tweaks To Extend The Battery Life Of Intel Linux Notebooks . Results I ended up with such simple tweak are more then satisfactory as I got some ~45 extra minutes of battery life besides the fact that it lowered temperature by some ~10 C. Guess this also gives me extra time until I get a chance to lay my hands on X1 P.S: After I posted this some argued that this is a workaround rather then a fix and folks at [Phoronix] just posted what they call a proper solution to this problem. Also please note although Sandy Bridge users that enable this might sometimes get a video corruption bug, i915_enable_rc6 is still supposed to get enabled by default in 3.2. So logical conclusion you can come up with is unless you re troubled by this problem, you might not want to use this work around/fix at this point. And hope it ll be fixed in future releases of your favorite Linux distribution.

I recently started getting mails from no-reply@joindiaspora.com. Usually, a mail from no-reply@whatever is enough to make me believe that the admins of said whatever are clueless regarding what e-mail means and how should it work. And in this case, it really amazes me If I get an invite to Diaspora*, right, I should not pester a hypothetical sysadmin@joindiaspora.com to get me off his list, but I should be able to reply to the person mailing me Maybe requesting extra details on what he is inviting me to, or allowing me to tell him why I'm not interested. But yes, Diaspora* has fallen to the ease of requiring me to join their network to be able to communicate back with the "friend" who invited me. Some of the (three?) readers of this site might not be familiar with the Diaspora* project. It is a free reimplementation (as far as I know) of something similar to Facebook Free not only in the sense that it runs free software, but also because it is federated Your data will not belong to a specific company (that is, you are not the value object they sell and make money with), but you can choose and switch (or become) the provider for your information. A very interesting proposal, socially and technically. I find that a gross violation of netiquette. I should be able to reply to the mail - Even if in this case it were to (and sorry As you are spreading my name/mail, you will excuse me if I spread your name ;-) ) fernando.estrada.invite1501335@joindiaspora.com. Such an (fictional FWIW) address would allow for mail to reach back the submitter by the same medium it was sent, without allowing open spamming into the network. Now, what prompted me to write this mail (just before adding no-reply@joindiaspora.com to my blacklist) is the message I got (in an ugly HTML-only mail which erroneously promised to be text/plain, sigh...) is that Fernando sent me as the inviting message, So, at least are you going to give Diaspora a chance? The answer is: No.. But not because of being a fundamentalist. Right, I am among what many people qualify as Free Software zealots, but many of my choices (as this one is) is in no way related to the software's freeness. I use non-free Web services, as much as many of you do. Yes, I tend to use them less, rather than more (as the tendency goes). But the main reason I don't use Twitter is the same reason I don't use Identi.ca, its free counterpart And the reason I'm not interested in Facebook is the same reason I will not join Diaspora* Because I lack time for yet another stream of activity, of information, of things to do and think about. Yes, even if I care about you and I want to follow what's going on in your life: The best way to do it is to sit over a cup of coffee, or have some dinner, or to meet once a year in the most amazing conference ever. Or we can be part of distributed projects together, and we will really interact lots. Or you can write a blog! I do follow the blogs of many of my friends (plus several planets), even if they have fallen out of fashion A blog post pulls me to read it as it is a unit of information, not too much depending on context (a problem when I read somebody's Twitter/Identica lines: You have to hunt a lot of conversations to understand what's going on), gives a true dump of (at least one aspect of) your state of (mind life work), and is a referenceable unit I can forward to other people, or quote if needed. So, yes, I might look old-fashioned, clinging to the tools of the last-decade for my Social Web presence. I will never be a Social Media Expert. I accept it But please, don't think it is a Stallmanesque posture from me. It is just that of a person who can lose too much time, and needs to get some work done in the meantime. (oh, of course: Blog posts also don't have to make much sense or be logically complete. But at least they allow me to post a full argument!)

Since there have been a few blog posts about GNOME 3 already, I m sure you don t mind me adding one. I m one of those who don t do any work, just lurk around and wait for stuff to be fixed or working in the first place. I also don t like compiling GNOME myself. I barely touched the already packaged stuff in the repository of our Debian GNOME packaging team. But I run unstable plus stuff from experimental. I ll thus have a bit of a different experience with GNOME 3 than current testing users who at least in parts don t seem to like what they re getting. That being said I love it. No, I don t mind running network manager on my systems, I even have it on my netbook (Atom processor). I used wicd for a long time because network manager really got nothing done back in the days (half a year ago or what :)). Nowadays, since version 0.9, it works fine for me. No fiddling around with config files, perfect integration in the desktop, and LAN and WLAN Just Work [tm]. No, I don t like if some weird dependencies dictate what tools to use. I usually used pidgin for messaging, for instance. Now I m using empathy, simply because it s best integrated in GNOME. And no, I won t switch from mutt to evolution. :-P And there are more such cases. Also, these weird accessibility tools that are stuck in the gnome-shell top panel , I don t need them. Still there. (There s an extension to remove it, by the way.) Also, I must say, GNOME 3.2 is a lot better than 3.0 already. And I think 3.4 might do the final trick for me. Fact is, with GNOME 3 I have a much cleaner desktop, there is more room for windows (which is nice on a netbook display), there are web apps which I already use a lot, and it has a professional, not too playful look (i.e. a few effects, clear and consistent theming, no bubbling windows). And the new notification stuff is just awesome, especially with the empathy integration. Oh, and too many mouse click to access an application? 1) Put your most used apps in the favorites bar (or whatever it is called); it s just one click then. 2) Press your meta-key (that way our name for the windows key, or was that the ESC key? Whatever, press your windows key), type in the first two or three letters of your application, and hit enter; you don t need a mouse at all. There. It had to be said. :)

Oh, boy. Where do I start I postulate that there exists something called the "UI Singularity". Those who spend too much time considering the optimal way to interact with computing devices eventually pass through this singularity and can no longer effectively communicate with those of us on the other side. At least that's one way to explain what seems to be happening to free-software desktop environments. From the outside, it would appear this happened to KDE with KDE 4, and now, unfortunately, it has happened to GNOME, with GNOME 3. I've had GNOME 3.0 running on my Debian laptop for a few months, which I have used casually. At work, we installed Fedora 15 (GNOME 3.0) on our 69-seat Linux lab over the summer, which I have used on occasion to achieve specific things. I haven't dared upgrade my main work machine yet. So, it could be argued that I haven't spent enough time immersed in the GNOME 3 experience to really judge it fairly. On the face of it, I wish 3 was an iterative development from 2, and didn't throw so many babies out with the bathwater. My casual use of it so far has not endeared it to me at all. In the interests of being fair, rather than deliver my opinion of GNOME 3 as it currently stands, I've decided to try and use it in anger for a while to truly see whether I can "get it". Now that we're past the start of term, I am attempting to use a lab-configured Fedora 15 machine as my main work environment. I'll run with this for a while, and then try a Fedora 16 instance (I need to consider whether we should move to F16 for the second semester anyway) to see what improvements GNOME 3.2 brings.

Ugh, in the last year and a half I've only posted once. With the move to Ireland, starting a new job, and then using too much Google+, I forgot about this blog thing. So, to start with something easy, I'll tell you about some films I watched recently. This weekend I had a marathon of films, after sometime without watching any, I watched two at home and two at my favourite cinema in Dublin: the IFI, which I recommend to anyone living here. First, on Friday, I watched Brazil, the 1985 classic from Terry Gilliam. It was a long overdue obligation to watch it, and some discussions with a friend about cinema made me finally do it. It was an amazing film. Among the many memorable scenes, and cinephile winks, I liked the one copying the famous Odessa steps sequence. The problems related to its US release reminded me a bit of the problems with the edition of Touch of evil, although in the case of Brazil, what the big studio did to the film was to butcher it. On Saturday I continued on the Gilliam streak and re-watched 12 Monkeys, which I had forgotten completely. Another great film, with a clearly bigger budget, it does not rely on the money but in the plot, art, and acting to be memorable. Also, I love the main theme, a tune from Astor Piazzolla called "Suite Punta del Este". Just after finishing the film, I read that some people from the local Couch Surfing group were meeting at the IFI to see one of the many features of the Polish film festival that took place this weekend. So I went and saw A short film about killing, a powerful and shocking movie about the death penalty. Considered by many to be one of the most horrifying depictions of a killing (two, in fact), it didn't shock me as much as some other films had done, maybe it was because of the cinema overdose... Anyway, it was another must-see. IMDB asserts that the Polish government suspended the death penalty in Poland for five years after the release of this film, but I could not find sources to confirm this. This morning I woke up pretty early, which is completely uncommon for me on a Sunday. So I decided to use the tickets offered by the IFI for a pre-screening that I had assumed I would not use, since I had to be in the cinema at 11! This time it was an Irish documentary about Bernadette Devlin, called Bernadette: Notes on a political journey. It was really interesting, even if I had never heard about this important figure of Ulster politics in the sixties. Sadly, because of my ignorance on the topic (and some northern accents that I have trouble understanding), I missed many parts of the film. In any case, it has increased my appetite to know more about the Troubles, which had started when I visited the Republican neighbourhood of Belfast, specially Falls road. Tags: Life, Planet Debian

this week showed an interesting mixture of RC bug fixes: applying patches from others, writing one on my one, adjusting build dependencies, & also closing some bugs that did not occur anymore during the last Grid'5000 run & are also unreproducible locally (thanks to Lucas for the hint).

• #625412 tuxpuck: "tuxpuck: ftbfs with gcc-4.6 -Werror"
  false positive of the -Werror mass bug filing, close the bug
• #634283 src:qsstv: "qsstv: FTBFS Please Build-Depends on libjpeg-dev, not libjpeg62-dev"
  do as the bug report requests, upload to DELAYED/2
• #634426 src:mssh: "mssh: FTBFS: mssh-terminal.c:49:5: error: 'vte_terminal_fork_command' is deprecated (declared at /usr/include/vte-0.0/vte/vtedeprecated.h:82) [-Werror=deprecated-declarations]"
  apply patch from Ubuntu / Michael Vogt, upload to DELAYED/2
• #634532 src:pyabiword: "pyabiword: FTBFS: libtool: link: /usr/lib/libfreetype.la' is not a valid libtool archive"
  builds successfully locally and at Grid'5000, close the bug
• #634539 src:rss-glx: "rss-glx: FTBFS: libtool: link: cannot find the library /usr/lib/libfreetype.la' or unhandled argument /usr/lib/libfreetype.la'"
  builds successfully locally and at Grid'5000, close the bug
• #634542 src:morla: "morla: FTBFS: libtool: link: /usr/lib/libcurl.la' is not a valid libtool archive"
  builds successfully locally and on the buildds, close the bug
• #634545 src:pdl: "pdl: FTBFS: build-dependency not installable: libhdf4-alt-dev"
  builds successfully locally and at Grid'5000, close the bug
• #634547 src:kdevelop-php: "kdevelop-php: FTBFS: /build/kdevelop-php-T0YRXE/kdevelop-php-1.2.2/obj-x86_64-linux-gnu/parser/phpparser.h:7:20: fatal error: phpast.h: No such file or directory"
  builds successfully locally and at Grid'5000, close the bug
• #634557 src:slcfitsio: "slcfitsio: FTBFS: configure: error: unable to find the cfitsio library and header file fitsio.h"
  adjust to multiarched build dependencies, upload to DELAYED/2
• #634562 src:wv: "wv: FTBFS: libtool: link: /usr/lib/libfreetype.la' is not a valid libtool archive"
  builds successfully locally and at Grid'5000, close the bug
• #634578 src:arpon: "arpon: FTBFS: Libpthread not found!"
  add patch from Ubuntu / Steve Langasek, Andreas Moog, Daniel T Chen, upload to DELAYED/2
• #634592 src:libshout: "libshout: FTBFS: devlibs error: There is no package matching [libc6-dev] and noone provides it, please report bug to d-shlibs maintainer"
  builds successfully locally and at Grid'5000, close the bug
• #634606 src:gcolor2: "gcolor2: FTBFS: *** libtool.m4 and ltmain.sh have a version mismatch! ***"
  add patch from Ubuntu / Colin Watson, upload to DELAYED/2
• #634637 src:tuxpuck: "tuxpuck: Please Build-Depends on libjpeg-dev, not libjpeg62-dev"
  do as the bug report requests, upload to DELAYED/2
• #634647 src:xloadimage: "xloadimage: Please Build-Depends on libjpeg-dev, not libjpeg62-dev"
  do as the bug report requests, upload to DELAYED/2
• #643442 src:morla: "morla: FTBFS: about.c:258:3: error: format not a string literal and no format arguments [-Werror=format-security]"
  add a patch which adds format arguments to g_snprintf(), upload to DELAYED/2

I must admit that I ve never been a big fan of the dash as /bin/sh change. I have three main problems with the switch: POSIX compliance as an argument Complying to standards is a really good thing. But when everybody is ignoring the standard because they want the comfort of newer features, maybe it s a sign that the standard should be updated to include those newer features. Most of the bashims used everywhere in scripts were signifiant improvements, like the ability to write:
cp short1/path1,short2/path2 /very/long/common/path/to/a/file
instead of:
cp short1/path1/very/long/common/path/to/a/file short2/path2/very/long/common/path/to/a/file The option to improve bash was not fully explored We started with the premise that bash is bloated, slow, and cannot be improved. Maybe you can help me with that, but I could only find a few simplistic benchmarks comparing dash and bash, and I could not find any analysis of why bash is slow, and why it cannot be improved.
One of the obvious problems is that bash is also an interactive shell, and is linked to ncurses and terminfo, which increases the startup time. But have we investigated the possibility to have a /bin/bash-non-interactive binary that would not be linked to ncurses? The change was brought to users While it is OK for Debian (or Ubuntu, in that case, since that change was done in Ubuntu first) to force its developers to use POSIX-compliant scripts, the switch could have been made only to Debian-created scripts (by switching them from a /bin/sh shebang to a /bin/dash shebang, for example). I have trouble justifying that this change was forced on users as well. Next: linker changes and we are doing it again. A set of linker changes (see also the Ubuntu page) was already done in Ubuntu, and is very likely to be done in Debian as well. This switch requires deep changes in some buildsystems (it requires ordering of libraries and forbids indirect dependencies), and is rather painful (it was reverted before the Ubuntu 11.04 release because it was not possible to fix all the packages during the natty release cycle, but is done in the 11.10 release). Of course, there are justifications for this change. But I m not sure that it s worth all the trouble created for users.

I recently wanted to buy some MP3 files from Amazon (a whole album in my case, but you can also just buy single MP3 files if you want). Digital music downloads from Amazon are often much cheaper than buying the physical CD (from Amazon), and you can also instantly get the stuff within seconds, without having to wait for the physical CD to be shipped to your place. The good thing about Amazon's MP3 downloads is that the files are not infested with any DRM-crap (if that were the case I wouldn't spend a single penny on such useless junk, of course). This allows you to burn the MP3 files on CDs and/or play them on any device you like (MP3 player of choice, laptop, hifi-system, car, e-book reader with MP3 playback support, etc. etc). Granted, you can not re-sell the digital files on eBay later, this is the one little drawback you have when compared to physical CDs, but I guess most people can usually live with that. Also, it would be great if Amazon would provide Ogg Vorbis files instead (or in addition to) MP3 files, of course. Anyway, in order to download the MP3 files you buy from Amazon, they suggest to install the Amazon MP3 Downloader, which (surprisingly) is even available in a Mac and Linux version (only 32-bit though), but is (unsurprisingly) closed-source. This is no-go, of course, but luckily there is an alternative. The clamz tool (GPL, version 3 or later) allows you to easily download single Amazon MP3 files, or whole albums. First, you need to login to your Amazon account and then visit a certain Amazon page (which sets a special "congratulations, the Amazon MP3 Downloader has been successfully installed" cookie in your browser). See the clamz website for the respective URL for your country. For Germany, use this URL. The clamz installation is easy enough on Debian:

  $ apt-get install clamz

IMPORTANT: It seems you need at least version 0.5 for recent Amazon files as they apparently changed something, see #647043. Current Debian unstable as of today already has 0.5, though. After that is done, the rest is easy: In Amazon, click on "Buy MP3" or "Buy MP3 album", which will download a special AmazonMP3-1234567890.amz file. You can then let clamz download all the MP3s by typing:

  $ clamz AmazonMP3-1234567890.amz

Wait a few minutes, and you'll have a bunch of non-DRM MP3 files in your current directory. Easy. See the manpage for a bunch of options which let you configure clamz to your preferences.

It's about time that Rapha l is interviewed in the "People behind Debian" series he initiated on his blog. Indeed, when he interviews people, Rapha l asks about other people they could suggest for next interviews. So, during mine, I suggested him to be a next "victim". As he couldn't interview himself, I volunteered for this. As you'll see below, Rapha l (who's a friend of mine as I'm a friend of his) likes to speak and that shows in the length of his answers :-) but you always know more about Debian when reading his blog posts, books, mails, etc. I personnally think that he is among the best promoters of the project for years and it was a pleasure for me to conduct this interview. My questions are in bold, the rest is by Rapha l. Who are you? Hi, Rapha l Hertzog, I'm a 32 years old French Debian developer who is married and who has a 2-year old son. I'm running my own company (Freexian) since 2005, I started it 3 years after the end of my computer science studies. I'm also a very proud author of the Cahier de l'Admin Debian, a French book about Debian. You often wrote about your attempts to make your living partly, if not completely, out of your Debian work. Can you describe the way you're trying to do this? My first try has been with Freexian. I always advertised this company as being specialized in Debian GNU/Linux. While Freexian is successful enough to provide me a decent income, I'm not really satisfied with the result because very few of my contracts are about improving Debian. I use Debian daily for the benefit of my customers, writing new customer specific (embedded) software, deploying a service on Debian servers, etc. But except for the occasional bugfix, all this work does not improve Debian (the only exception has been the dpkg multiarch implementation work sponsored by Linaro). The positive side is that I don't need to fill my entire schedule to earn enough money to live. So I'm regularly taking some days off work to be able to contribute to Debian. This is a freedom that I enjoy... My French book has also been a bestseller and depending on the years the royalties represented between 1 and 2 months of supplementary time that I can spend on Debian (that is between 2000 and 4000 EUR of income). Now since last year, I decided to actively work towards my goal of making a living out of my Debian work. I want to build on what has been most successful for me up to now, that is my book. My strategy has been to build an audience around my blog: with a direct contact with my readers I have the opportunity to sell e-books, and without any intermediary taking the biggest part of the price, I don't need a very large audience to be successful. I have also been experiencing micro-donations with Flattr, people who are enjoying my articles on my blog can use it to give a few cents for each article they find useful. With a large enough userbase, this could fund free documentation and would avoid the need for commercial e-books but we're not there currently and I don't know if it will ever reach the critical mass. Last but not least, I'm soliciting donations for my Debian work on the sidebar of my blog, and I have the chance to a have a few (regular) donators. You're a proud father since last year. How do you manage your commitment to the project with your family life? There are few things that I put above Debian in my life, but my family certainly is. I try to handle most of my Debian duties during work hours so that I can spend time with my family on evenings and during week-ends but in truth I never really disconnect from Debian. It happens quite often that I say to my wife I'll come in a few minutes, let me finish this and then I end up responding to a Debian mail, or an IRC query and take 30 minutes instead of the 5 expected ones. I try hard to avoid this but it's difficult. Luckily for me, my wife is very supportive of my Debian involvement and knows me well... By the way my wife is using Debian on her computer, and my son has already played with DoudouLinux (a Debian derivative!). Have you already been accused of self-promotion in your writings? If that would ever happen, what would you answer to that? Yes, more than once. I am proud of what I do for Debian, I enjoy sharing the result of my work. Because of this, some people believe that I'm selfish and egocentric. And this has somewhat increased since I have been soliciting donations: for me it's important to be transparent towards donators so that they see what I really do for Debian. But some people have the feeling that I'm getting undeserved attention and that I bring everything towards my own person. On the other side, as an author, I'm a public figure who is definitely seeking some attention... I don't have any miraculous answer, we are a large and diverse community, it's next to impossible to please everybody. I listen to all the concerns that people bring forward, I take them into account as much as possible, in particular when I believe they are reasonable/well justified, or when they come from people that I highly respect. But sometimes I have to plainly ignore them too... in particular when they are trying to impose their own political view on a topic that's not directly related to the only value that we all share: the social contract. Contributing to Debian is a challenge, we all have to make efforts to put aside our differences and to concentrate on the work that brings us closer to the best free software operating system ever built. You recently launched a campaign to free out the soon-to-be-published "Debian Administrator Handbook", an English version of your well-known book about Debian in French. Can you tell us more about this project? My French book has been very successful at helping people to get started with Debian, and like I already explained, it was also effective to fund a part of my Debian work. So I wanted to make it available world-wide by publishing an English translation of it. I tried to find an English-speaking editor willing to take on the challenge but I found none interested. Not put off by a setback, Roland (my co-author) and I decided to negotiate with our French editor Eyrolles to recuperate the necessary rights to translate the book into English. Handling everything ourselves represents a lot of work, but it also means that we have the freedom required to decide of the license of the resulting book. We would love to see it under a license compatible with the Debian Free Software Guidelines. But at the same time we firmly believe that we deserve a reasonable monetary compensation for the work on the book, so we conditioned its liberation to a predefined amount of money (25 K ) in what we call the "liberation fund". And since we wanted to be sure that we would have the required means to complete the translation, we used a crowfunding platform to seek support of people interested by the book. With such a platform you're only debited if the minimal requested amount is reached. Anyone can participate, pre-order the book and/or put some money in the liberation fund. As of today, we already reached the minimal funding goal (15 K ) so the book translation will happen. But the liberation target has not yet been reached so we don't know yet if the book will be free from the start... you can follow the progress right on the fundraising page or on the website dedicated to the book. PS: If you want to contribute to this project and also make a donation to Debian at the same time, you should check out this page. You're one of the main developers of dpkg, a critical tool for Debian systems. Can you tell us more about the current development challenges it is facing? What will be the new dpkg features for wheezy? The current challenges are not really technical. dpkg is a relatively mature piece of software and it will continue to work for the foreseeable future without needing much maintenance work. The real challenge is trying to setup a healthy developement community around it so that we can keep tackling new interesting problems (there are many listed in the roadmap and in the 225 wishlist bugs). There is a real problem of leadership and communication in the current team. We used to be three, and we're only two nowadays. Guillem is the legitimate leader since he's involved in dpkg's developement since early 2006 while I joined only in late 2007. But in the last 4 years, we did not manage to recruit anyone else on the team. Some persons tried to contribute significant new features (like Sean Finney with a rework of the way we handle configuration files) but they gave up frustrated after a while because we did not manage to review their work (and discuss the design) in any reasonable timeframe. Another famous case is Ian Jackson with his trigger work. His work got merged, but so late that in the mean time he blew up while trying to hijack the maintenance of dpkg. For a long time I was concentrating my work on the Perl part of dpkg (aka dpkg-dev mainly), so I did not feel qualified to review and merge work related to the C part and I was just a worried observator of this situation. I tried to improve it by setting up some basic review infrastructure, it should have brought some lisibility to the status of each change left to be reviewed... but it has not been used and it changed nothing. Over the years, I became much more interested in the C part. My first big contribution in C has been the rewrite of update-alternatives (from Perl to C). I made other small changes in between, but at the start of this year I had this great opportunity to work on the multiarch implementation (FYI, multiarch is the possibility to mix packages from several architectures on a single system). This really forced me to jump into the C codebase and learn a lot about how dpkg is implemented. Thanks to this I have been able to tackle other small projects (like the improved triggers). This would be all great if my multiarch work was already merged, but it's not. It's a large work, I do not mind waiting a bit in particular since Guillem is a highly skilled C programmer. His sharp analysis of new designs are invaluable, when he reviews code he always finds something to improve. I learnt a lot just by reviewing the code he wrote over the years. That said I have been waiting since April without almost no updates from him. With the release team asking us to hurry up, the situation is getting somewhat strained as I really want to see multiarch in Wheezy and I do not really want to short-circuit Guillem. Hum, I may have drifted a bit from your original question... what great new features can people expect? Well multiarch is supposed to be the big new feature, apart from that there aren't many things that matter to the end users. But there are already quite a few changes that are of interest to package maintainers (like hardened build flags, source package improvements, improved triggers, ). What's the biggest problem of Debian? Manicheism and a tendency to quickly polarize the discussions. In reality, there are very few situations where everything is all good or all bad. Ever since I have read The 7 Habits of Highly Effective People I try hard to put into practice the habits of interdependence . Instead of having only my point of view in mind, I try to understand the motivations from the other party ( Seek First to Understand, Then to be Understood ) in order to be able to put forward solutions acceptable to both parties ( Think Win-Win ). I highly recommend this book to anyone. And I invite everybody to at least try to follow those simple advices. Is there someone in Debian you admire for their contributions? There are many and I can't give an exhaustive list... here are some that I would like to highlight (in no particular order):

• Niels Thykier for the work he puts into Lintian, and his recent work on a britney test-suite (the software that creates testing out of unstable);
• Joachim Breitner for his britney reimplementation using a SAT solver;
• Adam D. Barrat for his work on britney2;
• All the release team members who take care of an endless stream of transitions;
• Christoph Berg for his continuous work over the years on various QA infrastructure (DDPO, Mole, );
• Enrico Zini for the way he helped reform the New Member process without any big disruption;
• Russ Allbery for his Debian Policy work and for being a model in terms of how we should interact on Debian mailing lists;
• Stefano Zacchiroli for being the most active leader that I have ever seen, and for the way he tries to steer important discussions to a constructive conclusion.
• etc.

Most of those people are working on improving Debian's infrastructure so that we can all be more effective and do an even better work. This kind of work is not always very visible but it's crucial to Debian's future. Thank you to Rapha l for the time spent answering my questions. I hope you enjoyed reading his answers as I did. And, anyway, it was fun to just play the game "the other way".

ERROR: WOUTER+TIMHOTEL@GREP.BE is not a valid email address True, because I entered it in lowercase.

1. Email address local parts (the bit before the @) are case sensitive. That means you can't just convert it to all caps and assume it will arrive.
2. local parts can be composed out of any character from the following list:
• alphanumeric characters (a-z, A-Z, 0-9), and
• !#$%&'*+-/=?^_ ~.

This means that if you're trying to validate an email address by adding a regular expression that does more than check whether there's not exactly one @ in the address, you're almost always wrong. Next time you try to tell me my mail address is invalid, go read the RFC first. Morons.

If you value your privacy, you might want to use a search engine like Ixquick which tries to protect your privacy. But if you value your privacy you probably have NoScript installed and have it hide <noscript> elements, as many pages hide tracking methods for users with deactivated JS in such tags. That makes every result page (but the first) inaccessible, because Ixquick has its non-JS navigation in noscript tags too. Now you could either activate JavaScript for Ixquick or work around this problem. Thanks to Greasemonkey and a little script I wrote, working around this issue is really easy. At this point, there is only this one script on dev.carbon-project.org, but in case I write another one, it'll end up there too. ;-)

I have been a long-time user of the Galeon web browser, which, while powerful for its time, is getting a bit long in the teeth and has been abandoned for a long time. As a result I need to find something new. As Galeon uses the Mozilla engine I figure switching to Iceweasel/Firefox will be the least amount of pain since they share similar formats for lots of the user configuration and data (with the exception of history). Switching to Firefox also gives me access to a lot of configurability and a vast sea of extensions all written in RDF, JavaScript and zoooool (ahem, XUL). Another plus was that I was already using Firebug for the occasional web development project. Looking at the Mozilla addons site is like entering someone's shed. There will be the few beautiful unfinished projects still being worked on, one polished finished scuplture gathering dust but still admirable, things with power plugs from a bygone era, some things that have a coin slot on them, some cryptic machines with no visible screws or manuals, some spiders and their cobwebs and a few rats and mice chewing through things. A place where you can find some excellent, well documented, useful and Free Software extensions alongside lots of crud. Luckily for me the good stuff that I wanted to use was already in Debian or the friendly Debian Mozilla extension maintainers team was willing to package them for me. In my quest for freedom from Galeon I first noticed that there is no up button in Iceweasel. Bummer, I use that a lot so I went searching for extensions. I soon found one extension, but it hadn't kept up with the ever-changing Mozilla APIs so it fell by the wayside. Thanks to the leavers of breadcrumbs I picked up the trail to a new shiny and working extension. Lo-and-behold I found Uppity, which was all about going up and as it turns out, much better at that than Galeon. Thanks to MozExt team, thats solved, next! The next glaring problem was the lack of Galeon-style smart bookmarks. Before you ask, yes, Firefox smart keyword bookmarks are not the same thing. This was rediculously hard to search for due to the wording used by both projects being same same but different. Some folks switched to Epiphany to get the extra search boxes on their toolbars. Like this guy I was not interested in that, mainly due to the addons I would be missing out on. I tried a few different tacks, even searching for a way to have multiple search boxes in the Firefox toolbars. I soon gave up on finding an extension that would do this like Galeon does so I figured its time to roll up the sleeves and learn some zzzoooool. I already know a little bit about JavaScript and CSS so... First slap a dash of a tutorial about adding toolbar buttons, add a slither of adding extensions without installing them, stare down some Mozilla reference manuals, thrown in a pinch of favicons, give up on a wild goose chase or two, add a big fat blob of zoooool and sautee in fugly hacks. Soon enough you will have something hardcoded that works like Galeon smart bookmarks but looks even better. I may eventually turn this into a proper and functionally equivalent extension for Galeon-stlye smart bookmarks but for now it will remain a useful hack. If you want to get your hands dirty with zzzoooooool and try this out after modifying it to use your personal search URLs, please feel free to contact me. For now the only remaining issue I can see is that the forward/back buttons in Iceweasel don't have the explict menu buttons. This is a minor issue for me so now it is time for me to figure out how to migrate my data and config¹ before permanently switching away from Galeon. Wish me luck! 1. Of course the data and config are fugly, but that is a something for another, much broader and more complicated hack

See also parts 1, 2, and 3. I am a person that enjoys food that s different from what s at home, and Rhodes didn t disappoint. Terah and I used to live close to an excellent Greek restaurant in Indianapolis, so we were already familiar in some way with the food. But there isn t any Greek restaurant at all in the Wichita area, so we missed it. Our favorite restaurant on Rhodes was Kalypso of Lindos. Everything there was just excellent, starting with the saganaki, one of my favorite Greek appetizers. I had yogurt with honey there for dessert both times we visited, a surprisingly tasty desert. Like many restaurants in Lindos, Kalypso had the option of eating on the rooftop, or at ground level. We ate on the roof, which had a nice view of the Lindos Acropolis. Being outdoors, there were sometimes cats around. This kitten enjoyed playing games with my shoestrings for awhile. Kalypso is at a 17th century captain s house. Here s a view of it from the rooftop: We, of course, had the chance to eat at quite a few different places during our visit, and I d go on way too long if I mentioned them all. Terah particularly enjoyed the gelaterie.gr ice cream shop in the square in Rhodes. We liked our lunch at Maria s Taverna in Lindos and enjoyed chatting with the staff there. I recently talked about shopping in Mexico, and perhaps learned a thing or two from that. I won t say we never buy them, but in general we don t buy souvenirs like t-shirts, plastic things made in China, etc. We prefer to buy local. Those items tend to be higher quality, more interesting, and we like to support the local economy. We also don t have lots of room for things, so we try to choose carefully. So it was something of a surprise to Terah, and perhaps even to me, when I suggested we go shopping one day. Terah typically enjoys shopping a lot more than I do. Anyhow, off we went to Lindos. One of the first things that had caught our eye in Lindos was the shop selling glass. But it wasn t just any glass; it appeared to be made with some sort of layered process, and has a distinctly three-dimensional feel to it. As you move around, it looks like the background shifts. We wound up with this item, which was made in Athens: By the time we visited Lindos specifically for shopping, we had a good feel for when the busy times of day were, so we could avoid them. It gave us the opportunity to visit with people and when they weren t busy, many shopkeepers liked to chat. I enjoy hearing people s stories and we heard several. One ceramics shop the Musa Shop -caught Terah s eye. They had such incredible and beautiful pieces outside that we just had to go in. We wound up with two pieces from there, both in shades of blue: Both remind me of the Aegean Sea and the deep blue sky of Rhodes. And then, as we were walking along, I pointed inside a shop and said to Terah, Hey, those look different. We went in, and eventually wound up buying these: The appearance, and even feel, of them is unlike anything I d seen. Quite interesting. And seeing those particular items in the Lakis Place shop led to making some new friends I ll write about it in the next post.

My son is being encouraged to lie. It's a fairly regular occurrence around here, and I'm sure you've seen it yourself. It's that checkbox on the website you're visiting where you say "Yes, I am over X years of age".

Some days ago, a hacker group, THC, released a denial of service tool for SSL web servers. As stated in its description, the problem is not really new: a complete SSL handshake implies costly cryptographic computations. There are two different aspects in the presented attack:

• The computation cost of an handshake is more important on the server side than on the client side. The advisory explains that a server will require 15 times the processing power of a client. This means a single average workstation could challenge a multi-core high-end server.
• The use of SSL renegotiation allows to trigger hundreds of handshakes in the same TCP connection. Even a client behind a DSL connection can therefore bomb a server with a lot of renegotiation requests.

Mitigation techniques There is no definitive solution to this attack but there exists some workarounds. Since the DoS tool from THC relies heavily on renegotiation, the most obvious one is to disable this mechanism on the server side but we will explore other possibilities.

Disabling SSL renegotiation Tackling the second problem seems easy: just disable SSL renegotiation. It is hardly needed: a server can trigger a renegotiation to ask a client to present a certificate but a client usually does not have any reason to trigger one. Because of a past vulnerability in SSL renegotiation, recent version of Apache and nginx just forbid it, even when the non-vulnerable version is available. openssl s_client can be used to test if SSL renegotiation is really disabled. Sending R on an empty line trigger renegotiation. Here is an example where renegotiation is disabled (despite being advertised as supported):

$ openssl s_client -connect www.luffy.cx:443 -tls1
[...]
New, TLSv1/SSLv3, Cipher is DHE-RSA-AES256-SHA
Server public key is 2048 bit
Secure Renegotiation IS supported
Compression: zlib compression
Expansion: zlib compression
[...]
R
RENEGOTIATING
140675659794088:error:1409E0E5:SSL routines:SSL3_WRITE_BYTES:ssl handshake failure:s3_pkt.c:591:

Disabling renegotation is not trivial with OpenSSL. As an example, I have pushed a patch to disable renegotiation in stud, the scalable TLS unwrapping daemon.

Rate limiting SSL handshakes Disabling SSL renegotiation on the client side is not always possible. For example, your web server may be too old to propose such an option. Since those renegotiations should not happen often, a workaround is to limit them. When the flaw was first advertised, F5 Networks provided a way to configure such a limitation with an iRule on their load-balancers. We can do something similar with just Netfilter. We can spot most TCP packets triggering such a renegotiation by looking for encrypted TLS handshake record. They may happen in a regular handshake but in this case, they usually are not at the beginning of the TCP payload. There is no field saying if a TLS record is encrypted or not (TLS is stateful for this purpose). Therefore, we have to use some heuristics. If the handshake type is unknown, we assume that this is an encrypted record. Moreover, renegotiation requests are usually encapsulated in a TCP packet flagged with push .

# Access to TCP payload (if not fragmented)
payload="0 >> 22 & 0x3C @ 12 >> 26 & 0x3C @"
iptables -A LIMIT_RENEGOCIATION \
    -p tcp --dport 443 \
    --tcp-flags SYN,FIN,RST,PSH PSH \
    -m u32 \
    --u32 "$payload 0 >> 8 = 0x160300:0x160303 && $payload 2 & 0xFF = 3:10,17:19,21:255" \
    -m hashlimit \
    --hashlimit-above 5/minute --hashlimit-burst 3 \
    --hashlimit-mode srcip --hashlimit-name ssl-reneg \
    -j DROP

The use of u32 match is a bit difficult to read. The manual page gives some insightful examples. $payload allows to seek for the TCP payload. It only works if there is no fragmentation. Then, we check if we have a handshake (0x16) and if we recognise TLS version (0x0300, 0x0301, 0x0302 or 0x0303). At least, we check if the handshake type is not a known value. There is a risk of false positives but since we use hashlimit, we should be safe. This is not a bullet proof solution: TCP fragmentation would allow an attacker to evade detection. Another equivalent solution would be to use CONNMARK to record the fact the initial handshake has been done and forbid any subsequent handshakes. If you happen to disable SSL renegociation, you can still use some Netfilter rule to limit the number of SSL handshakes by limiting the number of TCP connections from one IP:

iptables -A LIMIT_SSL \
    -p tcp --dport 443 \
    --syn -m state --state NEW \
    -m hashlimit \
    --hashlimit-above 120/minute --hashlimit-burst 20 \
    --hashlimit-mode srcip --hashlimit-name ssl-conn \
    -j DROP

Your servers will still be vulnerable to a large botnet but if there is only a handful of source IP, this rule will work just fine¹. I have made all those solutions available in a single file.

Increasing server-side power processing SSL can easily be scaled up and out. Since SSL performance increases linearly with the number of cores, scaling up can be done by throwing in more CPU or more cores per CPU. Adding expensive SSL accelerators would also do the trick. Scaling out is also relatively easy but you should care about SSL session resume.

Putting more work on the client side In their presentation of the denial of service tool, THC explains:

Establishing a secure SSL connection requires 15 more processing power on the server than on the client.

I don t know where this figure comes from. To check it, I built a small tool to measure CPU time of a client and a server doing 1000 handshakes with various parameters (cipher suites and key sizes). The results are summarized on the following plot: For example, with 2048bit RSA certificates and a cipher suite like AES256-SHA, the server needs 6 times more CPU power than the client. However, if we use DHE-RSA-AES256-SHA instead, the server needs 34% less CPU power. The most efficient cipher suite from the server point of view seems to be something like DHE-DSS-AES256-SHA where the server needs half the power of the client. However, you can t really uses those shiny cipher suites:

1. Some browsers do not support them: they are limited to RSA cipher suites².
2. Using them will increase your regular load a lot. Your servers may collapse with just legitimate traffic.
3. They are expensive for some mobile clients: they need more memory, more processing power and will drain battery faster.

Let s dig a bit more on why the server needs more computational power in the case of RSA. Here is a SSL handshake when using a cipher suite like AES256-SHA: When sending the Client Key Exchange message, the client will encrypt TLS version and 46 random bytes with the public key of the certificate sent by the server in its Certificate message. The server will have to decrypt this message with her private key. Those are the two most expensive operations in the handshake. Encryption and decryption are done with RSA (because of the selected cipher suite). To understand why decryption is more expensive than encryption, let me explain how RSA works. First, the server needs a public and a private key. Here are the main steps to generate them:

1. Pick two random distinct prime numbers p and q , each roughly the same size.
2. Compute n=pq . It is the modulus.
3. Compute \varphi(n)=(p-1)(q-1) .
4. Choose an integer e such that 1<e<\varphi(n) and \gcd(\varphi(n),e) = 1 (i.e. e and \varphi(n) are coprime). It is the public exponent.
5. Compute d=e^ -1 \mod\varphi(n) . It is the private key exponent.

The public key is (n,e) while the private key is (n,d) . A message to be encrypted is first turned into an integer m<n (with some appropriate padding). It is then encrypted to a ciphered message c with the public key and should only be decrypted with the private key:

• c=m^e\mod n (encryption)
• m=c^d\mod n (decryption)

So, why is decryption more expensive? In fact, the key pair is not really generated like I said above. Usually, e is a small fixed prime number with a lot of 0, like 17 (0x11) or 65537 (0x10001) and p and q are choosen such that \varphi(n) is coprime with e . This allows encryption to be fast using exponentiation by squaring. On the other hand, its inverse d is a big number with no special property and therefore, exponentiation is more costly and slow. Instead of computing d from e , it is possible to choose d and compute e . We could choose d to be small and coprime with \varphi(n) and then compute e=d^ -1 \mod\varphi(n) and get blazingly fast decryption. Unfortunately, there are two problems with this:

• Most SSL implementation expects e to be a 32bit integer.
• If d is too small (less than one-quarter as many bits as the modulus n ), it can be computed efficiently from the public key.

Therefore, we cannot use a small private exponent. The best we can do is to choose the public exponent to be e =4294967291 (the biggest prime 32bit number and it contains only one 0). However, there is no change as you can see on our comparative plot. To summarize, no real solution here. You need to allow RSA cipher suites and there is no way to improve the computational ratio between the server and the client with such a cipher suite.

Things get worse Shortly after the release the denial of service tool, Eric Rescorla³ published a good analysis on the impact of such a tool. He asks himself about the efficiency to use renegotiation for such an attack:

What you should be asking at this point is whether a computational DoS attack based on renegotiation is any better for the attacker than a computational DoS attack based on multiple connections. The way we measure this is by the ratio of the work the attacker has to do to the work that the server has to do. I ve never seen any actual measurements here (and the THC guys don t present any), but some back of the envelope calculations suggest that the difference is small. If I want to mount the old, multiple connection attack, I need to incur the following costs:

1. Do the TCP handshake (3 packets)
2. Send the SSL/TLS ClientHello (1 packet). This can be a canned message.
3. Send the SSL/TLS ClientKeyExchange, ChangeCipherSpec, Finished messages (1 packet). These can also be canned.

Note that I don t need to parse any SSL/TLS messages from the server, and I don t need to do any cryptography. I m just going to send the server junk anyway, so I can (for instance) send the same bogus ClientKeyExchange and Finished every time. The server can t find out that they are bogus until it s done the expensive part. So, roughly speaking, this attack consists of sending a bunch of canned packets in order to force the server to do one RSA decryption.

I have written a quick proof of concept of such a tool. To avoid any abuse, it will only work if the server supports NULL-MD5 cipher suite. No sane server in the wild will support such a cipher. You need to configure your web server to support it before using this tool. While Eric explains that there is no need to parse any SSL/TLS messages, I have found that if the key exchange message is sent before the server send the answer, the connection will be aborted. Therefore, I quickly parse the server s answer to check if I can continue. Eric also says a bogus key exchange message can be sent since the server will have to decrypt it before discovering it is bogus. I have choosen to build a valid key exchange message during the first handshake (using the certificate presented by the server) and replay it on subsequent handshakes because I think the server may dismiss the message before the computation is complete (for example, if the size does not match the size of the certificate). With such a tool and 2048bit RSA certificate, a server is using 100 times more processing power than the client. Unfortunately, this means that most solutions, except rate limiting, exposed on this page may just be ineffective.

---

1. However, since this rule relies on source IP to identify the attacker, the risk of false positive is real. You can slow down legitimate proxies, networks NATed behind a single IP, mobile users sharing an IP address or people behind a CGN.
2. Cipher suites supported by all browsers are RC4-MD5, RC4-SHA and 3DES-SHA. Support for DHE-DSS-AES256-SHA requires TLS 1.2 (not supported by any browser).
3. Eric is one of the author of several RFC related to TLS. He knows his stuff.