We just released a sample chapter of the Debian Administrator s Handbook. It covers the APT family of tools: apt-get, aptitude, synaptic, update-manager, etc.

Click here to get your free sample chapter I m sure you will enjoy it. There are many interesting things to learn:

• How to customize the sources.list file
• The various APT repositories that Debian offers (Security Updates, Stable Updates, Proposed Updates, Backports, Experimental, etc.)
• How to select the best Debian mirror for you
• How to find old package versions
• How to install the same selection of packages on multiple computers
• How to install and remove a package on a single command-line
• How to reinstall packages and how to install a specific version of a package
• How to pass options to dpkg via APT
• How to configure a proxy for APT
• How to set priorities to various package sources (APT pinning)
• How to safely mix packages from several distributions on a single system
• How to use aptitude s text-mode graphical interface
• How to use the tracking of automatically installed packages to keep a clean system
• How APT checks the authenticity of packages that it downloads
• How to add supplementary GnuPG keys to APT s trusted keyring
• How to upgrade from one stable distribution to the next
• How to handles problems after an upgrade
• How to keep a system up-to-date
• How to automate upgrades
• How to find the package that you re looking for

If you liked this chapter, click here to contribute a few euros towards the liberation of the whole book. That way you ll get a copy of the ebook as soon as it s available. Thank you! I also invite you to share this sample chapter as widely as possible. We re only at 40% of the liberation fund and there s less than 2 weeks left. I hope this book extract will convince enough people that the book is going to be great, and that it really deserves to be liberated and bundled with Debian!

8 comments Liked this article? Click here. My blog is Flattr-enabled.

After recently reading a number of SSL/TLS-related articles, I decided to experiment and look for the ideal OpenSSL configuration for Apache (using mod_ssl since I haven't tried mod_gnutls yet) and nginx.

By "ideal" I mean that this configuration needs to be compatible with most user agents likely to interact with my website as well as being fast and secure.

Here is what I came up with for Apache:

SSLProtocol TLSv1
SSLHonorCipherOrder On
SSLCipherSuite RC4-SHA:HIGH:!kEDH

and for nginx:

ssl_protocols  TLSv1;
ssl_ciphers  RC4-SHA:HIGH:!kEDH;
ssl_prefer_server_ciphers   on;

Cipher and protocol selectionIn terms of choosing a cipher to use, this configuration does three things:

• disables all weak ciphers and protocols
• disables very slow ciphers that use ephemeral Diffie-Hellman exchanges
• gives priority to the RC4 cipher to minimize CPU usage and defend against the BEAST attack

Testing toolsThe main tool I used while testing various configurations was the SSL labs online tool. The CipherFox extension for Firefox was also quite useful to quickly identify the selected cipher.

Of course, you'll want to make sure that your configuration works in common browsers, but you should also test with tools like wget, curl and httping. Many of the online monitoring services are based on these.

Other considerationsTo increase the performance and security of your connections, you should ensure that the following features are enabled:

• SSL session caching with a session store shared between all of your web servers
• HSTS headers to let browsers know that they should always visit your site over HTTPS

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.

A few years ago, I ran into my friend Jay in the MIT Infinite Corridor. He was looking for volunteers to have their pictures taken and then added to the library of freely licensed and remixable media that would ship with every version of Scratch -- the graphical programming language built by Mitch Resnick's Lifelong Kindergarten group that is designed to let kids create animations and interactive games. Jay suggested I make some emotive faces and I posed for three images that made the final cut: But although I've spent quite a bit of time studying the Scratch community in the last few years as it is grown to include millions of participants and projects, I forgot about about Jay's photo shoot. A couple months ago, Acetarium resident Andres Lombana Bermudez pointed out that there was a mako tag on the Scratch website and that a whole bunch of users had been publishing projects using the pictures of me which, apparently, shipped in Scratch under my name. For example, in this project in which I dance in front of a enormous "MAKO" banner: That said, given the rather emotive nature of the pictures, I seem to usually end up being blown up shot, shrunk, set on fire by dragons, or meeting other similarly unfortunate ends. There's quite many more entertaining examples under the tag and many more elsewhere on the Scratch website although they are a little trickier to track down. Jonathan Zittrain likes to say that the best technologies are generative in the sense that they encourage their users to make things with them that the designer never forsaw or anticipated. I feel generative.

Hi all! My name is Alberto Garcia and this is my first (well, second) post in Planet Debian. So I ll introduce myself. I m a free software developer and enthusiast from Galicia, Spain. I studied computer science at the Corunha University, where I first heard about GNU/Linux and Debian. After leaving university I co-founded Igalia with a group of friends. We ve been working on lots of different things during all these years, but some projects we ve been particularly involved in include GNOME, Maemo/MeeGo and WebKit. Although I ve been using Debian for more than a decade now (my first -and still running!- installation was in 1997) and I m quite familiar with the distribution, it wasn t until a few years ago that I started maintaining packages officially. Apart from software, my other main hobby is music. When I m not using my computer you ll find me at some concert (preferably small bands: I hate long queues, crowded places and being far from the stage). It s no coincidence that my first Debian package was a Last.fm player ;) I don t have much more to add. I d like to thank Ana for adding me to the planet, and I m proud to be part of the Debian community!

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.

So, like many people, I have received GNOME 3 in the latest upgrade on Debian testing, and switched away to Xfce very soon after. What's amazing (to me) about this whole experience, however, is how easy it is to switch desktop environments in Debian. Two years ago, I fled KDE in very similar circumstances. I have since used Openbox, LXDE, GNOME, Xfce, as well as a few more obscure window managers in short-lived experiments. All of this was easy to do and worked flawlessly. Most of my settings, my preferred programs, and startup applications were preserved, and if I didn't like it, I could switch back without a problem. (Ironically, the upgrades from KDE 3 to KDE 4 and from GNOME 2 to GNOME 3 lost far more settings than changes to other environments.) And of course you can mix and match applications from different environments, and these days this doesn't result in a visual crime. I don't know whom to thank for this, probably a combination of upstream developers, freedesktop.org guys, and Debian maintainers. Keep it up.

If you ever get an error message from the blktrace tool that looks like this:

BLKTRACESETUP(2) /dev/dm-0 failed: 2/No such file or directory
Thread 3 failed open /sys/kernel/debug/block/(null)/trace3: 2/No such file or directory
Thread 2 failed open /sys/kernel/debug/block/(null)/trace2: 2/No such file or directory
Thread 0 failed open /sys/kernel/debug/block/(null)/trace0: 2/No such file or directory
Thread 1 failed open /sys/kernel/debug/block/(null)/trace1: 2/No such file or directory
FAILED to start thread on CPU 0: 1/Operation not permitted
FAILED to start thread on CPU 1: 1/Operation not permitted
FAILED to start thread on CPU 2: 1/Operation not permitted
FAILED to start thread on CPU 3: 1/Operation not permitted

Don t be alarmed your disk hasn t suddenly disappeared out from underneath you. In fact, it means quite the opposite of what No such file or directory might imply. In fact, it means that there is already a blktrace of that particular block device in progress, and you ll need to kill that one off before you can start another one. Thank $DEITY for the kernel source code it was the only hope I had of diagnosing this particular nit before I went completely bananas and smashed my keyboard into small pieces.

The bug webinterface of the Ultimate Debian Database currently knows about the following release critical bugs:

In Total:	1869
Affecting Wheezy:	1211
Wheezy only:	155
Remaining to be fixed in Wheezy:	1056

Of these 1056 bugs, the following tags are set:

Pending in Wheezy:	54
Patched in Wheezy:	197
Duplicates in Wheezy:	48
Can be fixed in a security Update:	33
Contrib or non-free in Wheezy:	12
Claimed in Wheezy:	0
Delayed in Wheezy:	10
Otherwise fixed in Wheezy:	87

Ignoring all the above (multiple tags possible) 684 bugs need to be fixed by Debian Contributors to get Debian 7.0 Wheezy released. However, with the view of the Release Managers, 1105 need to be dealt with for the release to happen. Please see Interpreting the release critical bug statistics for an explanation of the different numbers.

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.

From time to time i want to answer on mails on Debian mailinglists that i am not subcribed to. To have proper reply-headers set, i usually copied the archive mbox from master.debian.org to my local machine. Now i found a much nicer way.

apt-get install fuse afuse sshfs
adduser zobel fuse
mkdir ~/fuse/
afuse -o mount_template="sshfs %r:/ %m" -o unmount_template="fusermount -u -z %m" -o timeout=60 ~/fuse
mutt -f /home/zobel/fuse/master.debian.org/home/debian/lists/debian-user/debian-user.201111

You're on a small island in the middle of a vast ocean. There's nothing but dirt, stone and grass on the your island, which is part of a tiny archipelago. One of the nearby islands features a dark cave, with what looks like a coal seam near the entrance. You can glimps two small trees on another island nearby. All around your little clutch of islands is what appears to be vast, unending ocean in all directions. It's midday and you need to make yourself safe for the night. You can use the wood from the trees to craft a pickaxe. With this, you can fetch some coal from the seam. With the coal, you can create some torches, to see in the dark. You might have enough wood left over to make a door, if you're lucky. Or perhaps you should save it to craft a boat, or a sword. Groans from something unknown emanate worryingly closely from the darkness of the cave. You're lucky: one of your two trees has dropped a sapling. You eagerly plant it. In a few days time, you might be able to harvest some more wood. You've been granted a temporary reprieve, but the law of diminishing returns means at some point, and soon, you'll run out of wood. Swimming is time-consuming. By the time you have assembled a meagre supply of wood and coal, it's almost sunset. You nervously dig a burrow in the mud of your original island, light it with a torch and block the entrance back up. Night passes slowly as you listen to things crawling around in the darkness outside. I first learned about Minecraft from this blog post by Mike Watson last year. Mike did a great job of demonstrating the narrative power of the game and his post left a lasting impression on me. Every now and then I dip in to Minecraft to see what's new since the last time I played it. In the last few months version 1.8 was released and so I started a new map to check it out. I ended up with a corker of a randomly-generated map. Inspired by Mike's post, I thought I'd write a bit about it. In a follow-up post I will provide the map itself.

During summer, I somehow managed to collect huge backlog on Gammu. This consisted on few hundredths of emails to reply, bug reports, not reviewed records in phone database and so on. Today I can finally say this is mostly over and I should be able to react more quickly. Though this does not change anything on previous statements about limiting my involvement there. Processing emails went quite smoothly, luckily some of them resolved themselves or others have helped on mailing list. With bug reports it is more troublesome, because there are topic which I don't want to touch and thus looking for volunteers to work on that. Maintaining Gammu packages in Ubuntu PPA so that users would be able to install latest version easily is one of such tasks, which are waiting for somebody. Anyway I feel much better without those unread emails and I hope not to collect so huge pile of them again :-).

Filed under: English Gammu 0 comments Flattr this!

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. :)

You should probably ignore this post. I'm just venting. I'll be better after a nice cup of tea. Things that are causing me to fume about the fact Gnome Shell just hit Debian/Testing:

• Spacefun came back. Even on GDM3. Just fucking die already.
• I had to reboot to get bluetooth working again.
• /desktop/gnome/shell/windows/workspaces_only_on_primary set by default? SRSLY?
• It failed to carry over my previous monitor settings.
• I'm pretty sure I don't have a latent desire for a machine running OS X, whatever the GNOME devs might think.
• How many mouse clicks to get to the list of applications?
• Er, why have you changed my default apps? (Why is clicking a link in a terminal opening Epiphany rather than a new tab in Iceweasel?)

I update my testing boxes (work + home laptops) almost every day. It rarely breaks, and certainly when it does I accept that's what I get for doing rolling upgrades. I can't remember the last time I did an upgrade that actually made me angry. Also I suspect this thing is going to have a complete fit on my binary nVidia/hacked up DisplayLink configuration at work (the DisplayLink side refuses to do 3D for starters). Perhaps better not to upgrade there until I have a sufficient block of free time. Maybe it's time to go back to evilwm. I only stopped because I wanted a dock for wifi/bluetooth etc applets on my laptop that didn't get hidden when I fullscreened things. Implementing _NET_WM_STRUT might make that doable... (I'm sure some of this is just dealing with the change but it's a bit bloody difficult to deal with a complete change in user interface that hasn't even managed to carry across settings from the old one.)

The bug webinterface of the Ultimate Debian Database currently knows about the following release critical bugs:

In Total:	1893
Affecting Wheezy:	1250
Wheezy only:	180
Remaining to be fixed in Wheezy:	1070

Of these 1070 bugs, the following tags are set:

Pending in Wheezy:	47
Patched in Wheezy:	190
Duplicates in Wheezy:	51
Can be fixed in a security Update:	33
Contrib or non-free in Wheezy:	10
Claimed in Wheezy:	0
Delayed in Wheezy:	3
Otherwise fixed in Wheezy:	87

Ignoring all the above (multiple tags possible) 709 bugs need to be fixed by Debian Contributors to get Debian 7.0 Wheezy released. However, with the view of the Release Managers, 1144 need to be dealt with for the release to happen. Please see Interpreting the release critical bug statistics for an explanation of the different numbers.

So a few days ago, there was this:

21:24 < wouter> hum.
21:24 < wouter> Anyone know of a tool to manage scanned documents?
21:25 < wouter> the idea being that I can tell this tool "here's a bunch of newly-scanned documents", and it will upload them to a server
21:25 < wouter> and it should allow me to easily find a specific file later on
21:25 < wouter> and I'd also like version control there
21:26 < wouter> and I do _not_ want to download the entire repository of scanned documents on my laptop (that's why I have a server)
21:26 < wouter> and perhaps I'd also like a pony to go with that.
21:29 < wouter> oh, yes, and I do _not_ want a webbrowser as the primary interface (that might be okay to look things up, but not to store stuff)

The answer, as it turned out, was git-annex: a tool to manage files with git, without checking them into git. What, I hear you say? Yes, that sounds a little weird, doesn't it? Perhaps it's easiest to explain with a little example.

$ git annex add 2011-11-07-belgacom.pdf
$ ls -l 2011-11-07-belgacom.pdf
lrwxrwxrwx 1 wouter wouter 191 nov  7 14:46 2011-11-07-belgacom.pdf ->
../.git/annex/objects/xx/3F/SHA256-s1537334--c44e1a057e247bfe7c196ac146c8a0ca32096c0b10df6c18fd3f1c2e99ecddbf/SHA256-s1537334--c44e1a057e247bfe7c196ac146c8a0ca32096c0b10df6c18fd3f1c2e99ecddbf

The file is now known to git-annex, and I can have it do all kinds of useful things with it now:

$ git annex drop 2011-11-07-belgacom.pdf
drop 2011-11-07-belgacom.pdf (unsafe)
  Could only verify the existence of 0 out of 1 necessary copies
  No other repository is known to contain the file.
  (Use --force to override this check, or adjust annex.numcopies.)
failed
git-annex: drop: 1 failed

Oops, we hadn't copied it to anywhere else yet. We don't want to lose our data!

$ git annex move --to server 2011-11-07-belgacom.pdf
move 2011-11-07-belgacom.pdf (checking server...) (to server...)
SHA256-s1537334--c44e1a057e247bfe7c196ac146c8a0ca32096c0b10df6c18fd3f1c2e99ecddbf
     1537334 100%    9.22MB/s    0:00:00 (xfer#1, to-check=0/1)
sent 30 bytes  received 1537668 bytes  1025132.00 bytes/sec
total size is 1537334  speedup is 1.00
ok
$

What just happened? git-annex copied the file to a git remote called "server", and then dropped it from my local copy. It's no longer here! The symlink in my local directory is now a dead link; I can not open it anymore. But, no worries! If we ever need it again, it's just a single command away.

$ git annex get 2011-11-07-belgacom.pdf
get 2011-11-07-belgacom.pdf (from server...) 
SHA256-s1537334--c44e1a057e247bfe7c196ac146c8a0ca32096c0b10df6c18fd3f1c2e99ecddbf
     1537334 100%    9.58MB/s    0:00:00 (xfer#1, to-check=0/1)
sent 30 bytes  received 1537668 bytes  3075396.00 bytes/sec
total size is 1537334  speedup is 1.00
ok

This allows me to save space on my local laptop while not having to care where the files are -- they're just there. And it gets more awesome if you know that git-annex can store multiple copies of each file (so you have automatic distributed backups, as with regular git), where you can enforce the minimum number of copies. Also, git-annex supports multiple backends -- you can store your data in Amazon S3, or on an encrypted USB drive, or whatever, and have git-annex manage it transparently for you. I said this already on IRC, but: Joey, I owe you beer.

It s seeming increasingly likely that reports regarding the future of Banshee, Tomboy, and the rest of the Mono stack in the default Ubuntu desktop install are accurate. Ubuntu 12.04 will likely be the first Ubuntu release since 5.10 not to ship with any Mono apps in the default install ending a run of 12 releases over 6 years. The decision seems to have come about during the default apps session at the Ubuntu Developer Summit just ended in Orlando, Florida. Prior to heavy vandalism, the only reasons cited for the change in the UDS session log are Banshee not well maintained and porting music store to GTK3 is blocked on banshee ported to GTK3 . Other reasons mentioned but not in the session logs are complaints that it doesn t work on ARM. I m using a lot of conjecture in this first paragraph because the news about the decision appeared on the blogosphere before anywhere else. The first many Banshee or Tomboy developers read about it was reading a flurry of activity on the Tweetosphere from the anti-Mono activists declaring victory. So first, a word on the cited reasoning. Banshee works fine on ARM, since Mono works fine on ARM. Xamarin, the company behind most upstream Mono work, earns their income almost entirely from ARM versions of Mono, running on the varied ARM implementations found in smartphones. Every major Banshee release is personally tested on my Genesi EfikaMX, an ARM system with a Freescale i.mx51 processor. I ve also demonstrated Banshee running in an Ubuntu chroot on my HP Touchpad, an ARM-based tablet. What is known is that Banshee has some problems running on Texas Instruments OMAP4 processors the target ARM platform for Canonical s ARM work. None of the Banshee upstream developers, Mono upstream developers, or Mono Ubuntu team has ever been able to reproduce the cited problems, since problems specific to an exact ARM chip are impossible to reproduce without the requisite hardware and none of us owns an ARM system matching Canonical s target. That Banshee is still a GTK+2 app is true. A port to GTK+3 is almost complete, but blocking on a single technical bug deep within GTK# s guts, which could be fixed by someone with sufficient knowledge of GTK+ semantics. Nobody with the required GTK+ knowledge has stepped forward with a fix at this point in time. As for the final point, that Banshee is not well maintained, this seems like a directed personal insult against the active and responsive Banshee maintainer, Chow Loong Jin, and upstream bug triager David Nielsen, in addition to the immeasurable hours contributed free of charge for the benefit of Ubuntu users by various other members of related Mono app and library teams, including myself. I need to stress at this point that my annoyance with this decision has nothing to do with the actual app changes. Keeping Tomboy and gbrainy, at a cost of about 25 meg of unsquashed disk space, is a hard argument to make compared with those two plus Banshee for 40 meg. Dropping gbrainy and Tomboy, and switching to Rhythmbox, will save about 30 meg of unsquashed space, all told.I m unconvinced that Rhythmbox is a technically superior app to Banshee several features which were gained by the first app swap will be lost again but that s another long tedious argument to be had. No, what has me deeply angered is the shambolic way the changes were made and announced. Significant accommodations were made by Banshee upstream in order to make life easier for Canonical to integrate Banshee into their OS. For one thing, that s why the Ubuntu One Music Store support is a core Banshee feature, not part of the third-party community extensions package. If Banshee was being considered for replacement due to unresolved technical issues, then perhaps it would have been polite to, I don t know, inform upstream that it was on the cards? Or, if Canonical felt that problems specific to their own itches required scratching, then is it completely beyond the realm of possibility to imagine they might have spent developer resources on bug fixing their OS and sending those fixes upstream? Or even and call me crazy providing access for upstream to specialized hardware such as a $174 Pandaboard to empower upstream to isolate and fix unreproducible bugs specific to Canonical s target hardware? And here s where it gets more astonishing for me Canonical paid money to ship one of the community-based packagers responsible for the stack, Iain Lane, to Orlando for UDS, and didn t think it was worth bothering to perhaps inform him hey, the stuff you work on is in danger of being axed from the default install, maybe you should go to this session . So I m not cross that the stuff I work on has been removed from the default install. I intend to continue working on it as I have for the last 4 years, through my work in Debian. No, why I m cross that I heard about it from fucking Boycott Novell. Regardless of your opinions regarding Banshee or its stack, if you read the above and don t see it as an abysmal failure of community engagement by a company whose community manager wrote a book on the damn topic, then there s something seriously wrong with your understanding of how community labour should be seen as a resource. Maybe someone at Canonical should try reading Jono s book. It s not a first-time offence, and this mail from a PiTiVi developer regarding changes in 11.10 makes for useful further reading. [edit] There is some worthwhile discussion going on on the ubuntu-desktop mailing list covering the technical issues surrounding the decision, I would suggest it s a good place for ongoing technical discussion.