The new ncurses library that is currently sitting in the NEW queue will have a significant change that, if we ve done it right, should be an invisible change. If we ve got it wrong, then the BTS (and us) may be a little busy. What has happened is that the low-level terminfo library has been split out from the general ncurses library making a new package called libtinfo5. This also means that there only needs to be one libtinfo5 package because at this low level it doesn t care about wide characters, so there is no libtinfo5w (and that gets important later). libncurses is linked to libtinfo so from the point of view of using libncurses there should be no major change in how things are done. So, why bother? The way ncurses was built before causes a nice long conga line of trouble . There really are (was) two main ncurses library packages, libncurses5 and libncursesw5. The w meant it was for wide characters. So anything that uses ncurses needs to decide which one to link to or perhaps both. A problem came up with the readline library that needs to link to ncurses because programs that link to IT (such as python) want a wide library but other programs do not. One solution is to have two readline libraries, but then any other library would need to be compiled and built twice as well and so on and so on. readline didn t really want the full ncurses library, it only wants the terminfo part but there was (until now) no way of picking up that bit only. Once this new version of ncurses gets released then readline can link to libterminfo which is agnostic to wide and non-wide characters which means it is as well which them means everything else should, in theory work. If you are using ncurses for some low-level terminfo work only, you may want to have a look to see if you can link to libtinfo5 only which will mean depending on libtinfo5 and not libncurses5 or libncursesw5. I m just writing this up mainly and uploading the packages, the bulk of the work was done by Sven and Matthias as well as some help from our ever-helpful upstream Thomas.

There's loads of music on YouTube. However, when I want to listen to music, I'm not necessarily interested in slideshows. And yes, that's a euphemism. Luckily, extracting the video and audio from a youtube clip isn't very hard.

• First, download the clip. Yes, that's possible. This will get you a movie clip, by default in the highest quality format available for the particular clip you're trying to download.
• You want to know which codecs the clip is using. Mplayer to the rescue:

  wouter@carillon:~$ mplayer -frames 1 -v <file> 2>&1 grep -i 'stream.*audio'
  [lavf] stream 1: audio (vorbis), -aid 0
  

  meaning, this particular file has Vorbis audio.
• Next, extract the audio:

ffmpeg -i <file> -vn -acodec copy <output>.ogg

The critical bit is the '-vn' part, which tells ffmpeg not to encode the video to the output file. The 'mplayer' step isn't strictly required; but since youtube only uses lossy audio codecs, re-encoding the audio to a different codec will cost you audio quality. You may not want to do that; hence the mplayer step (to figure out which codec the source file is using), and the '-acodec copy' argument to ffmpeg's command line (which tells ffmpeg to not re-encode the audio, but just store the unmodified original audio stream in a different container file). Tadaa, music without video.

Keith and I released version 1.0.2 of AltOS, the open source firmware and software system associated with our Altus Metrum hobby rocket avionics systems. This release includes a fix for the defect in version 1.0.1 that prevented rebooting an altimeter from idle to pad mode over the radio link. This affects both TeleMetrum and TeleMini boards, and re-flashing the altimeter firmware is required to pick up this fix. We also restored the pre-1.0 mode selection behavior for TeleMetrum at power on. This is also an altimeter firmware change, but does not affect TeleMini.

Today, German politicians decided, that Germany be liable for up to 211 billion Euros for the debts of other EU countries. Or, put differently: the politicians put the money of the current and future generations on the line for a country that lived way above its capabilities for too many years. When the EU was founded, it was explicitly stated that no country needs ever be liable for any other. I understand that politics is hard, and letting Greece (and others) fall down might carry heavy, unforeseen consequences. Also, I understand that the Greek people are mostly innocent in all this and that the fault lies with their politicians and other corrupt entities in the nation. However, what s happening these days is beyond the comprehensible. If I were in a non-Germany EU country, I d rejoice and continue making debts. It is likely that this won t be the last time that our politicians cave in to pressure by other nations who have a lesser understanding of budgeting and saving. Since I am German, I can only shake my head, look to Berlin and ask myself whether this is the final straw that broke the camel s back. How the heck do the people over there ever want to regain the trust of their people? Politics has become the game of pleasing each other, who cares about the people? And the German politicians are (once again, remember credit default swaps?) at the forefront of this stupidity. To me, there is only one solution to Greece s debts: make sure that what happened can never happen again, and then cut the debts, or slice them in half. Let the banks carry the weight, for it was them who gave out the loans too liberally. And if this forces a bank or two to default, let it happen, for fuck s sake. The consequences might be dire, but they ll subside. And that s surely better than trying to pretend that we can keep juggling this heavily inflated financial system. Instead, the executives, elected to carry the trust of the people, are setting precedents for other countries to follow Greece, for it is likely that they wil be bailed out. By us. That is not the way to teach anyone the basics of economy: you can only spend as much as you earn, without exceptions. Debts will only come around to hurt you. I could puke. NP: Godspeed You Black Emperor!: F# A#

Besides FusionForge stuff, I also kept busy with other things.

• A new electronic drumkit: I upgraded from a Roland TD-4K to the new TD-9KX2. Apart from the improvements of the sound module and the mesh-head pads, it has two goodies. First, an extra trigger input line. Which means I just had to plug a cymbal pad from my Guitar Hero drum controller (with a standard jack cable), so I get an extra pad. More cowbell! Second, it now has a MIDI-in port. Which means that I "just" have to write some code (probably using libcwiid) to get the signals from the GH controller to a convenient computer nearby, then turn them into MIDI signals and send them to the Roland kit. So that I get not one but six extra pads (actually, five and a pedal). Special effects, lasers, symphonic chords, cymbals of all sizes, steel drums and more cowbell!
• Big mistake: I borrowed a Zelda Twilight Princess game. I'm ashamed to admit that it ate my week-end, and it's likely to eat quite a bit of my time again in the near future, although I'll try to put it on a diet. Yeah, okay, I had sort of guessed that games had improved a lot since the days of Might & Magic, but wow, I didn't realise how much.
• Rapha l and I started the fundraising campaign for the translation of our Debian book to English. Pre-orders/pledges are collected on Ulule; we'll only get them if the threshold is met, but the counterpart is that we won't actually do the translation if the threshold isn't met: translation and proofreading and publication of a book take a tremendous amount of time, and that's going to be time spent away from our respective clients. Note that there's a second threshold, for the "liberation fund"; if that one is met, the result of the book will be released under a Free license (most probably a CC-BY-SA + GPL dual-license). There are a whole lot of options for contributing, with rewards according to the amount you choose: e-book, paperback book, updates to the e-book, dedication, and even a dinner with the authors (limited offer, while supplies last).

A summary of my FusionForge-ish activities this month:

• FusionForge 5.1 is now available in Debian testing ("wheezy"). 5.0 is still in Debian stable ("squeeze"), so support continues; nevertheless, the improvements are significant enough that I recommend new users to run the version from testing if possible. Note that you can install the packages from testing onto a system running stable, either by hand or with APT pinning (there are only a handful of packages you need to grab from testing to satisfy the dependencies).
• This was made possible by some bugfixing in the 5.1 branch of FusionForge. Nothing major in itself, but the accumulated fixes will probably be worth a 5.1.1 release soon.
• I didn't do much on the trunk apart from merging from 5.1, but others did: several new plugins appeared, notably as part of the Coclico project (which is approaching its end fast).
• Also, not yet pushed to trunk are two local branches I have: one is a plugin to integrate MoinMoinWiki (with permissions managed through the FusionForge roles), developed with a client of mine. The other will end up in reuniting the FusionForge database upgrade process across installation methods (the *.rpm packages and the source installation currently use a PHP script, the *.deb ones use a Perl script with transactions). It'll probably break many things when initially committed, so I'll keep it on a local branch until I feel it's mature enough.
• I updated the "sandbox virtual machine" image; it now uses Debian wheezy, and the testsuite now runs a more recent version of Selenium; more importantly, the testsuite now passes.

The following is a quick HOWTO for the brave Debian users who want to upgrade to GNOME 3. Assuming you have an up to date system running sid, and experimental listed in your APT sources, perform the following complicated steps to end up having a functional GNOME 3 desktop:

apt-get install -t experimental gnome

Thanks go to Joss for putting together new GNOME 3 meta-packages, and the rest of the Debian GNOME people for months of hard planning and packaging work, and painful testing transition handling. Before you ask, yeah, not all of GNOME 3.x is in unstable yet, but will soon be, as precedent transitions start clearing the way. And yeah, GNOME 3.2 will come just after the two remaining package sets enter testing. To compensate, you'll find that you have some GNOME leaf packages pending an upgrade to 3.2.0-1 while you read this.

I've never had a dog of my own since I grew up, but there have always been dogs in my life.

Calypso and Percy

Calypso was dropped off at Wortroot soon after I moved in, and was my borrowed dog for years. And she remained out there, spending a good decade with run of the woods, fields and streams, a good doggy life. She got old and feeble, spent winters by the fireplace, and finally it was too much for her. I'll miss her, the best dog I've known. Recently I've caught glimpses of a dog lurking in the distance here at the Hollow. When I noticed it was sleeping on the roof of the battery box, I realized it was probably one of the dogs that used to live here but were given away last year. Exchanged email with the likely owners, now in Sudan, and they tell me her name is Domino, and she must have run away home. So I've been putting out food for Domino this week, and yesterday she came close enough to be petted. Medium sized and white, her name is for a black mask extending from eyes to ears. Although currently skittish, she seems basically a good, calm dog.

This weekend we'll be having the 4th version of the Colombian Mini-Debconf. It will be held in the Otraparte Museum, in the city of Medellin. The cool thing this year is that we'll be having mostly Debian contributors than just users, with the kind participation of Anibal Monsalve, who is currently in the country.

There will be several 10-min lightening talks, followed by a key signing party and some actual work in packaging, and of course we'll be having some beers with Debian friends.

More info (in Spanish): http://wiki.debian.org/DebianColombia/MiniDebconf2011

Dear lazyweb, I'm encountering a routing problem on one of my Linux machine, for which I haven't found a solution so far. I have a machine which has several network interfaces in different network (it's our monitoring system). So I have eth0 with 192.168.1.2 and eth1 with 10.0.0.2, and an dns entry pointing from myname to 192.168.1.2. Problems occur, if hosts in the 10.x.x.x network try to access the hosts. Accessing it via it's IP address in that network works, however if they try to access him via his other IP address 192.168.1.2 (e.g. because they resolve it via dns), it leads to some problems: The host send their packet to his IP address (which works), however when my machine sends the answer, it takes a shortcut, and sends them directly via eth1 and with 10.0.0.2 as source IP. This however gets filtered by a (stateful) firewall somewhere in between, as packet send to 192.168.1.2 are suddenly answered by 10.0.0.2. So far I found two solutions: Adjust the DNS to resolve to different IPs depending on the source of the request (ugly) or tell all firewalls to always let packet from my host pass, despite the changes source IP (also ugly, and probably quite some work). Is there anything else I can do? What I would really like, would be a way to tell my linux box to always respond with the IP it was talked to, even if there would be a shorter way to the origin according to the routing rable. So, if a host 10.0.0.42 contacts my host via the IP 192.168.1.2, the answer packet should come from 192.168.1.2 via eth0 instead of instead of having a source IP set to 10.0.0.2, it should be send via eth1. Is that somehow possible? Update: Wow, that was fast! The ink of my blog is still fresh, and I already got the answer! The solution to my problem is policy based routing. Thanks to weasel, Peter and Dale for their pointers! More information available at http://lartc.org/howto/lartc.rpdb.html, http://www.itbuzzer.net/corner/2007/09/how-to-implement-source-routing-with.asp or http://wiki.georgweiss.de/Linux/source_routing.

Our co-op has put in a bid to bring KohaCon to Edinburgh in 2012. Edinburgh is a great Free and Open Source Software (FOSS) conference city, with libraries of national and international importance, a huge choice of hotels, restaurants and entertainments and good international transport links. 2012 is also a great time for our co-op to host, because it ll be the International Year of Co-operatives and our co-op s tenth anniversary. So please, if you d like a library FOSS conference here next year, head over to KohaCon2012 voting straight away. I ll announce the result after the vote closes on Saturday 1st October.

Session reuse is one of the most important mechanism to improve SSL performance: by submitting an appropriate blob to the server, a client is able to trigger an abbreviated handshake, improving latency and computation time. There exists two distinct ways to achieve session reuse: session identifiers as described in RFC 5246 and session tickets as depicted in RFC 5077. A quick note: when I say SSL, unless I mention a version number, you should read TLS instead. Look at the article for TLS on Wikipedia for some background on this.

Theory of operation To establish a SSL connection, four messages need to be exchanged between client and server. With a latency of 50 ms, we have a 200 ms overhead to establish the connection (plus TCP handshake). Moreover, to share a common secret, both the client and the server needs to achieve some public-key cryptographic operations which are costly, computation-wise. To avoid a full SSL handshake each time a client request a resource, it is possible for the client to request an abbreviated handshake, saving a complete round-trip (100 ms) and avoiding the costliest part of the full SSL handshake. Two mechanisms can be used to accomplish an abbreviated handshake:

1. When the server sends the Server Hello message, it can include a session identifier. The client should store it and present it in the Client Hello message of the next session. If the server finds the corresponding session in its cache and accepts to resume the session, it will send back the same session identifier and will continue with the abbreviated SSL handshake. Otherwise, it will issue a new session identifier and switch to a full handshake. This mechanism is detailed in RFC 5246. It is the most common mechanism because it exists since earlier versions of SSL.
2. In the last exchange of a full SSL handshake, the server can include a New Session Ticket message (not represented in the handshake described in the picture) which will contain the complete session state (including the master secret negotiated between the client and the server and the cipher suite used). Therefore, this state is encrypted and integrity-protected by a key known only by the server. This opaque datum is known as a session ticket. The details lie in RFC 5077 which supersedes RFC 4507.

The ticket mechanism is a TLS extension. The client can advertise its support by sending an empty Session Ticket extension in the Client Hello message. The server will answer with an empty Session Ticket extension in its Server Hello message if it supports it. If one of them does not support this extension, they can fallback to the session identifier mechanism built into SSL. RFC 5077 identifies situations where tickets are desirable over session identifiers. The main improvement is to avoid to maintain a server-side session cache since the whole session state is remembered by the client, not the server. A session cache can be costly in term of memory and difficult to share between multiple hosts when requests are load-balanced across servers.

Browser support Session identifiers are part of SSL and are therefore supported since a long time by clients and servers. However, session tickets are an optional TLS extension and therefore, the support is not as widespread as for session identifiers. Support for tickets was added in OpenSSL 0.9.8f (October 2007). In GnuTLS, this is version 2.9.3 (August 2009). For NSS, the set of libraries behind most browsers, support of RFC 5077 is in version 3.12 (June 2008). Schannel, Microsoft implementation of TLS, does not currently supports tickets. To check if a browser supports session resume without and with tickets, I have written a web server listening to several ports with different configurations (session cache disabled or enabled, ticket support disabled or enabled). With the help of some Javascript, it is possible to interact with this server to determine what kind of session resume a browser support. It is difficult to get extensive results this way since you need to install a lot of browsers to get something valuable. Surprisingly, Android 2.3.4 browser (as shipped by Cyanogen Mod) does not support any session resume. Another way to check if a browser supports session resume is to use a sniffer and to spot Client Hello messages. If a client tries to resume a session, it will use an appropriate session identifier or send a ticket. A simple program parsing PCAP files allows to automate this task and get some interesting statistics. Here are random facts from more than 300 000 requests (38 000 clients) to a customer care service of an important French telco:

• 35% of requests exhibit support of tickets;
• 53.3% of requests ask to resume without tickets; 25.6% with tickets;
• 67.2% of requests exhibit support of SNI;
• 86.7% of requests use TLS 1.0; the remaining uses SSL 3.0; almost no TLS 1.1/1.2;
• in average, a client execute 8 SSL handshakes;
• ciphers supported by all clients are 3DES-SHA, RC4-MD5 and RC4-SHA.

With some log analysis to match each requests with the appropriate user agent, we can split the world in two parts: browsers supporting RFC 5077 (Chrome and Firefox) and browsers not supporting RFC 5077 (Internet Explorer, Opera 9.80, Safari for MacOS and iOS and Android browser).

Web server support There is no unique recipe to configure a web server to handle appropriately and efficiently session resume. Here are some generic directions :

• if the web server uses multiple processes, you need to configure a shared memory session cache; usually, tickets will work just fine in this setup;
• if you use local load-balancing, one easy way to avoid any problem is to use ensure that one IP is mapped to one server (either statically with hashing or dynamically with a stick table); if your load-balancer understands SSL, you can also use session identifier (and disable tickets¹) to build a stick table;
• if you don t want to apply the previous advice, you need to share the session cache between the servers with something like memcached and disable tickets;
• if you use global load-balancing (DNS based), there is no need to ensure that session resumption works across geographic pools since a user will usually stick to one pool.

Remember that only one client out of three supports TLS tickets. Therefore, you cannot rely on them to ensure proper session resume. You need a session cache.

Setting a session cache with Apache & nginx Apache features two different SSL engines. The first one is mod_ssl and uses OpenSSL as backend. It is possible to setup a shared session cache with SSLSessionCache but the memcached-enabled session cache is available only in the development branch. You can also get one by switching to mod_gnutls backend. The cache is enabled with GnuTLSCache. In this case, do not enable tickets because they cannot be shared. With nginx, you need to enable the shared session cache with ssl_session_cache. Currently, it lacks a memcached-enabled session cache but Matt Palmer has some patches to add it to the 0.8 branch. However, those patches can have a serious impact on nginx performance since retrieving a session from memcached is done synchronously (mostly because a limitation in OpenSSL design who does not allow to register asynchronous callbacks with SSL_CTX_sess_set_get_cb()). As a proof of concept, I have also added a similar feature to stud, the scalable TLS unwrapping daemon, a very efficient network proxy terminating SSL connections. The same limitation as for nginx applies: performances will suffer. Look at the pull request for more details.

Sharing tickets RFC 5077 tells tickets allow to load-balance requests across servers. However, to the best of my knowledge, there is currently no web server able to share tickets across a pool. Actually, when a server initializes its SSL stack, it will randomly generate some keys that will be used to protect and encrypt tickets. In OpenSSL, from ssl/ssl_lib.c:

    /* Setup RFC4507 ticket keys */
    if ((RAND_pseudo_bytes(ret->tlsext_tick_key_name, 16) <= 0)
              (RAND_bytes(ret->tlsext_tick_hmac_key, 16) <= 0)
              (RAND_bytes(ret->tlsext_tick_aes_key, 16) <= 0))
            ret->options  = SSL_OP_NO_TICKET;

Therefore, with a round-robin load-balanced pool of servers, tickets have to be disabled because servers would not accept tickets from neighbors. One way to solve this is to generate keys deterministically by hashing some common secret with the private key. I have implemented this approach for stud. Here is a simplified version (no error handling, no allocation) of the pull request for this feature:

    unsigned char keys[48];
    EVP_PKEY *pkey = grab_private_key();
    /* To get our key, we sign the seed with the private key */
    unsigned int siglen;
    unsigned char sign[LARGE_ENOUGH];
    EVP_MD_CTX mdctx;
    EVP_MD_CTX_init(&mdctx);
    EVP_SignInit(&mdctx, EVP_sha256());
    EVP_SignUpdate(&mdctx, some_secret, strlen(some_secret));
    EVP_SignFinal(&mdctx, sign, &siglen, pkey);
    /* And we keep only the first bytes. */
    memcpy(keys, sign, sizeof(keys));
    /* Tell OpenSSL to use those keys */
    SSL_CTX_set_tlsext_ticket_keys(ctx, keys, sizeof(keys));

Testing While tests can be done with just openssl s_client and openssl sess_id, testing all aspects can take a lot of time. For this purpose, I have written a client testing session resume with and without tickets. Here is a typical result: The program will try to establish five consecutive SSL connections for each IP without and with tickets. For each IP, the last four SSL connections should always reuse the first SSL session. Here, Twitter web servers seem properly configured: for each IP, session resume is successful. Their web servers do not support tickets or they may have disabled it because they share the session cache between servers inside the same pool.

---

1. RFC 5077 describes interactions between session identifiers and session tickets. When using tickets, the server should send back an empty session identifier. The client may present an empty session identifier or generate one. However, for all practical purposes, it seems that servers send back a non-empty session identifier and clients just stick to this identifier. Please, investigate if you want to use SSL session identifiers for load-balancing while keeping tickets enabled.

Hope a few of my readers got it from the title of this blog post. And maybe many others didn't. So let's talk about "Stop Making Sense". You're warned: nothing to do with free software...or running, this time. This is all about music. Music from the 80's. "Stop Making Sense" is indeed, in my opinion, one of the best achieved musical movie. It is simple: it features a gig by the Talking Heads, back in 1983, when this band was among the most innovative ones that ever appeared in the late 70's. And I finally managed to take time to actually buy the DVD and see it again as I didn't see it since 1985. For many people, Talking Heads is the incredible person that's David Byrne. That's certainly true for some parts (and this is what lead to their split in 1991), but the movie really gives credit to all members of the band, either the "regular" ones (Tina Weymouth, Chris Frantz, Jerry Harrison) or the tour musicians (Bernie Worrell, Alex Weir, Steven Scales, Lynn Mabry, Edna Holt). The construction of the movie is simple: it just starts with Byrne bringing a music box on an empty stage, with his acoustic guitar and playing an incredible tense "Psycho Killer" (there are so many different version of that mythical piece but this one is among the best). Then Tina joins for a not-so-often played "Heaven" and brings her so inimitable bass line (I count Tina among my very favourite bass player, immediately after Tony Levin). At the end of the piece, the crew quietly brings a full drum set, then Chris Frantz joins, smiling as ever, and the rhythm increases with "Thank you for sending me an angel". Then Jerry Harrison joins, to make the original Heads line-up for a really funky "Found a Job", where Jerry shows that he was THE Heads lead guitar (and Tina is still keeping the foundations so strong). Continuing the increasing tension, the rest of the musicians join for Slippery People, then Burning Down the House ("Who's got a match?"). All this culmminates in a crazy joggin on stage during "Life During Wartime" and Byrne performing incredible and stellar movements on stage. THis one surely makes the band entirely exhausted. How can they survive this? The few next songs are a little bit less stunning (oh, well, "Making Flippy Floppy" still features a dream bass line)...until a really special "Once in a Lifetime" that...has just to be seen (SAME AS IT EVER WAS), then a break where....the Tom Tom Club (namely Chris, Tina and the rest of the band) perform a giant "Genius of Love", so funky. All this is indeed meant for Byrne to prepare for his top appearance, in "Girlfriend is Better", in a giant suit, that makes his head over his long neck yet more...strange. This leads to a crazy "Take me to the River" which has always been the top of the Heads shows during the 80's and a tireless encore on "Crosseyed and Painless". The movie ends up and you nearly never had a breath. So, yes, if you think you enjoy the Heads music and have never seen that movie, just try doing it once. That's how music was in the 80's..and, doh, these folks were so good! By the way, all parts of the movie can be seen on YouTube in case you just want to see what *I* enjoy. Ah, and yes I share the love of the Heads with Danese "we never meet often enough" Cooper, by the way. We once made a promise ourselves to sing Psycho Killer in karaoke if we're happy (and drunk) enough to meet again before we're too old for this..:-).

* Life: As usual. * Debian: Lots of stuffs going on. We ve yet another MiniDebConf edition, this time at Mangalore. (Not really, it is at: NMAM Institute of Technology, Nitte) And, yes, we ve some nice international guests this time. (Ah, hello, bubulle!). I ve booked ticket etc. even I m heading there during Diwali time, I hope that it will be more fun than usual crackers + sweets etc this time! gwibber still sucks. * There is nothing apart from Life, Debian that needs update. Aye. Aye.

Continuing on my Hackweek project, I've polished GePeS a bit today. I started with better display of GPS coordinates and added some more GPS details to separate page. Adding images for moon phase was also part of the plan, though it force me to learn how to switch application to black theme, which looks much better with moon image. Rest of time was spent on cleaning up the code and adding preferences (for now only refresh rate). Updated screenshots: PS: Some numbers look weird (altitude and speed), though I'm pretty sure this is what phone reports me.

Filed under: English Meego Suse 4 comments Flattr this!

We just announced the launch of the fundraising campaign for the Debian Administrator s Handbook. We wanted to use this opportunity to let people contribute money both to our project but also to Debian itself. That s why we have setup a special link that you can use to participate. 15% of any donation made through this link (after VAT has been subtracted) will be given back to the Debian Project. Here s the link: http://debian-handbook.info/go/ulule-debian/ Feel free to use this link when promoting the project to your friends, so that even more money goes back to Debian. You can also embed a special widget on your website where any visitor that ends up becoming a supporter will also contribute 15% to the Debian project.

Help us spread the word about the project, and help raise money for Debian!

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

A bit more than a year elapsed since we announced our plans to translate our Debian book into English and to try to get it published under a license compatible with the Debian Free Software Guidelines. But we re now ready to go to the next step. Completing the translation of 450 pages book is a huge work, we estimate it s going to take roughly 3 full time months for both Roland and me. Since we re freelancers, we can take the required time provided that we have a minimum income during that period. That s where you come into play: we have setup a crowdfunding campaign on Ulule.com and we need your support to raise 15000 (this is the absolute minimum for us to be able to commit the required time). Even if a good and up-to-date book on Debian is a great perspective, we want to go further than that by adding the perspective of getting a DFSG-free Debian book. That s why we have transformed the crowfunding campaign in a liberation campaign. When you support the project, you can pledge money towards a liberation fund and if this fund reaches 25000 then the book will be published under the GPL-2+ and CC-BY-SA 3.0 licenses. On top of this, when you support this project you can select a reward that goes from a copy of the ebook to a dinner with the authors (only 10 places for the latter)! Among the other rewards, there s obviously a paperback version of the book, but also an individual one-hour mentoring session with me a nice way to get you hooked as a new Debian contributor (limited to 40 persons, don t miss the opportunity!). We also need your help to spread the news and get as many supporters as possible. Share the link with your friends, write an article on your blog, put a widget on your website, etc. Thank you very much!

Click here to go to the fundraising page and to learn more about this project.

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

There's something brewing, moving in Jalisco (a state in Mexico's West, where our second largest city, Guadalajara, is located). And it seems we have an opportunity to participate, hopefully to be taken into account for the future. Ten days ago, I was contacted by phone by the staff of UDG Noticias, for an interview on the Universidad de Guadalajara radio station. The topic? Electronic voting. If you are interested in what I said there, you can get the interview from my webpage. I held some e-mail contact with the interviewer, and during the past few days, he sent me some links to notes in the La Jornada de Jalisco newspaper, and asked for my opinion on them: On September 23, a fellow UNAM researcher, C sar Astudillo, claims the experience in three municipalities in Jalisco prove that e-voting is viable in the state, and today (September 26), third generation of an electronic booth is appearingly invulnerable. Of course, I don't agree with the arguments presented (and I'll reproduce the mails I sent to UDG Noticias about it before my second interview just below They are in Spanish, though). However, what I liked here is that it does feel like a dialogue. Their successive texts seem to answer to my questioning. So, even though I cannot yet claim this is a real dialogue (it would be much better to be able to sit down face to face and have a fluid conversation), it feels very nice to actually be listened to from the other side! My answer to the first note:

El tema de las urnas electr nicas sigue dando de qu hablar por ac en Jalisco... nosotros en Medios UDG hemos presentado distintas voces como la del Dr. Gabriel Corona Armenta, que est a favor del voto electr nico, del Dr. Luis Antonio Sobrado, magistrado presidente del tribunal supremo de elecciones de Costa Rica, quien nos habl sobre los 20 MDD que les cuesta implementar el sistema por lo que no lo han logrado hasta el momento, pudimos hablar hasta argentina con Federico Heinz y su rotunda oposici n al voto electr nico y por supuesto la entrevista que le realizamos a usted. Sin embargo este d a La Jornada Jalisco publica la siguiente nota http://www.lajornadajalisco.com.mx/2011/09/23/index.php?section=politica... nos gustar a saber cu l es su punto de vista al respecto, quedo a la espera de su respuesta

Hola, Pues... Bueno, s que el IFE hizo un desarrollo muy interesante y bien hecho hace un par de a os, dise ando desde cero las urnas que propon an emplear, pero no se instrumentaron fuera de pilotos (por cuesti n de costos, hasta donde entiendo). Se me hace triste y peligroso que el IEPC de Jalisco est proponiendo, teniendo ese antecedente, la compra de tecnolog a prefabricada, y confiando en lo que les ofrece un proveedor. Se me hace bastante iluso, directamente, lo que propone el t tulo: comicios en tres municipios prueban la viabilidad del voto electr nico en todo el estado . Pong moslo en estos t rminos: El que no se caiga una choza de l mina con estructura de madera demuestra que podemos construir rascacielos de l mina con estructura de madera? Ahora, un par de p rrafos que me llaman la atenci n de lo que publica esta nota de La Jornada:

la propuesta de realizar la elecci n en todo el estado con urnas electr nicas que desea llevar a cabo el Instituto Electoral y de Participaci n Ciudadana (IEPC) es viable, pues los comicios realizados en tres municipios son pruebas suficientes para demostrar que la urna es fiable

y algunos p rrafos m s adelante,

Cu ntas experiencias m s se necesitan para saber si es confiable, 20, 30, no lo s (...) Pero cuando se tiene un diagn stico real, efectivo y serio de cu ndo t cnicamente procede, se puede tomar la decisi n

Como lo menciono en mi art culo... No podemos confundir a la ausencia de evidencia con la evidencia de ausencia. Esto es, que en un despliegue menor no haya habido irregulares no significa que no pueda haberlas. Que haya pa ses que operan 100% con urnas electr nicas no significa que sea el camino a seguir. Hay algunas -y no pocas- experiencias de fallas en diversos sentidos de urnas electr nicas, y eso demuestra que no puede haber confianza en las implementaciones. Aunque el equipo nos saliera gratis (que no es el caso), hay que invertir recursos en su resguardo y mantenimiento. Aunque se generara un rastro impreso verificado por el votante (que s lo ha sido el caso en una peque a fracci n de las estacione de votaci n), nada asegura que los resultados reportados por el equipo sean siempre consistentes con la realidad. El potencial para mal uso que ofrecen es demasiado. Saludos,

And to September 26th:

Disculpe que lo molestemos otra vez, pero este d a fue publicada otra nota m s sobre el tema de las Urnas electr nicas en Jalisco donde se asegura que la urna es invulnerable. http://www.lajornadajalisco.com.mx/2011/09/26/index.php?section=politica... nos podr a conceder unos minutos para hablar con usted, como la vez pasada, v a telef nica sobre el caso espec fico de Jalisco, en referencia a estas notas publicadas recientemente? si es posible podr a llamarle este d a a las 2 pm? Quedo a la espera de su respuesta agradeci ndole su ayuda, apreciamos mucho esta colaboraci n que est haciendo con nosotros

Hola, ( ) Respecto a esta nota: Nuevamente, ausencia de evidencia no es evidencia de ausencia. Se le permite a un peque o segmento de personas jugar con una m quina. Significa eso que fue una prueba completa, exhaustiva? No, s lo que ante un jugueteo casual no pudieron encontrar fallos obvios y graves. Un verdadero proceso que brindara confianza consistir a en (como lo hicieron en Brasil - Y resultaron vulnerables) convocar a la comunidad de expertos en seguridad en c mputo a hacer las pruebas que juzguen necesarias teniendo un nivel razonable de acceso al equipo. Adem s, la seguridad va m s all de modificar los resultados guardados. Un par de ejemplos que se me ocurren sin darle muchas vueltas:

• Qu pasa si meto un chicle a la ranura lectora de tarjeta magn tica?
• Qu pasa si golpeo alguna de las teclas lo suficiente para hacerla un poquito menos sensible sin destruirla por completo? (o, ya entrados en gastos, si la destruyo)

La negaci n de servicio es otro tipo de ataque con el cual tenemos que estar familiarizados. No s lo es posible modificar el sentido de la votaci n, sino que es muy f cil impedir que la poblaci n ejerza su derecho. Qu har an en este caso? Bueno, podr an caer de vuelta a votaci n sobre papel - Sobre hojas de un block, probablemente firmadas por cada uno de los funcionarios, por ejemplo. Pero si un atacante bloque la lectura de la tarjeta magn tica, que es necesaria para que el presidente de casilla la marque como cerrada, despoj de su voto a los usuarios. S , se tienen los votos impresos (que, francamente, me da mucho gusto ver que esta urna los maneja de esta manera). El conteo es posible, aunque un poco m s inc modo que en una votaci n tradicional (porque hay que revisar cu les son los que est n marcados como invalidados - no me queda muy claro c mo es el escenario del elector que vot por una opci n, se imprimi otra, y el resultado fue corregido y marcado como tal)... Pero es posible. Sin embargo, y para cerrar con esta respuesta: Si hacemos una corrida de prueba, en circunstancias controladas, obviamente no se notar n los much simos fallos que una urna electr nica puede introducir cuando los "chicos malos" son sus programadores. Podemos estar seguro que este marcador Atlas-Chivas-Cruz Azul tenga el mismo ndice de fiabilidad como una elecci n de candidatos reales, uno de los cuales puede haberle pagado a la empresa desarrolladora para manipular la elecci n? Y a n si el proceso fuera perfecto, indican aqu que est n _intentando_ licitar estas urnas (y nuevamente, si lo que menciona esta nota es cierto, son de las mejores urnas disponibles, y han atendido a muchos de los se alamientos - Qu bueno!)... Para qu ? Qu nos van a dar estas urnas, qu va a ganar la sociedad? Mayor rapidez? Despreciable - Media hora de ganancia. A cambio de cu nto dinero? Mayor confiabilidad? Me queda claro que no, siendo que no s lo somos cuatro trasnochados los que ponemos su sistema en duda, sino que sus mismos proponentes apuntan a la duda generalizada. La frase con la que cierra la nota se me hace digna para colgar un ep logo: "en ese futuro quiz no tan distante la corrupci n tambi n ocurre y sta se debe siempre al factor humano". Y el factor humano sigue ah . Las urnas electr nicas son programadas por personas, por personas falibles. Sin importar del lado que est n, recordar n la pol mica cuando se hizo p blico que la agregaci n de votos en el 2006 fue supervisada por la empresa Hildebrando, propiedad del cu ado del entonces candidato a la presidencia Felipe Calder n. Qu evita que caigamos en un escenario similar, pero ampliamente distribu do? Y aqu hay que referirnos a la sentencia de la Suprema Corte de Alemania: En dicho pa s, las votaciones electr nicas fueron declaradas anticonstitucionales porque s lo un grupo de especialistas podr an auditarlas. Una caja llena de papeles con la evidencia clara del sentido del voto de cada participante puede ser comprendida por cualquier ciudadano. El c digo que controla a las urnas electr nicas, s lo por un peque o porcentaje de la poblaci n.

Dad, will you and mom stay up all night decorating the house for me?

That was Jacob s question to me at bedtime the evening before his fifth birthday. Jacob had already had his birthday party a few weeks ago. When scheduling means that parties happen that far away from the boys real birthdays, they get a smaller celebration with just Terah and me where we open their presents from us. A low-key thing, so we weren t planning to decorate the house. I said, Well, I don t think we ll be doing all that since you already had your birthday party. And the look of eager anticipation on his face turned to a very sad and disappointed look, and made me feel really bad. Uhoh. So while Jacob was sleeping, I mentioned it to Terah. We decided we should improvise something simple, so she found some old streamers and we taped them up, running them through several rooms in the house and across his door. It took a few minutes using supplies we already had, but the joy the next morning was priceless. Oh dad, you said you wouldn t stay up all night, BUT YOU DID! Oh I am SO HAPPY! YAY YAY YAY! And he ran through the house to discover what else was set up. Then he ran to find Oliver and gave him a tour of everything. Then we sat down to open his presents. Here he is, holding a present from Terah and me: That s a copy of The Lorax. My friend Jonathan had brought a copy along during our road trip in Mexico, and Jacob was really excited about it. And didn t really want to give it up, because You can only get The Lorax in Mexico. He (and Oliver) really enjoyed all his presents he also got a train book from us (which he said, Oh, yay, it s the book they have at preschool! ), and a game and some other presents from the distant relatives. But the highlight was something of an impulse buy. I was at the RadioShack in Derby a place I ve written about before, It is what a RadioShack should (and used to) be. It has a large amateur radio section, sells all sorts of coax by the foot, and provides astonishingly good post-sale service. Well, I was there with a radio question, and Mark (the owner) who is an excellent salesman in a positive way pointed me to a display of snap kits. I noticed their Electronics 101 Snap-Kit (a rebranded Snap Circuits Jr. SC-100). A ham in Pennsylvania had suggested them to me once, and as Jacob s birthday was coming up, I gave it some thought. The kit said ages 8 and up. I asked Mark what he thought about a boy just turning 5. He said, Well, probably not normally. But knowing you, if you re there to work on them with him, I think he d enjoy it. But I wouldn t have him work on it by himself. I agreed and we bought it. I pondered how to explain the concept of this thing to Jacob. Eventually I decided I would call it a toy-building kit. He understood that. Jacob and I spent hours together working with it. He would flip through the book, either picking circuits that looked interesting or telling me what kind of circuit he wanted to build. Then I would tell him what to put where, and he d snap them together and play with them. He only played with each finished product a few minutes before he was ready to try another. Once I got him very excited with my offer to show him how to hook up two switches in parallel for the fan he built (and later introduced the parallel vs. series concept by hooking them up in series instead.) Here we are working on it together. Jacob repeatedly called Terah over to look at the things he built. He was very excited that he assembled it himself. Eventually, Oliver (age 2) came over wanting to help. So he sat on my lap, and handed parts to Jacob, then Jacob put them on the grid. Oliver really enjoyed being involved in this way, even though I had to keep him from doing things like ripping the capacitor off its mount. We tend to be modest in terms of the number of things we give the boys and their cost, reasoning that we, like many, already have too many toys in our house, and that greater cost doesn t necessarily equate with a better experience for the boys. I particularly look for things with lasting value and unique experiences for them, and I think we succeeded this year. But I realized quickly that the greatest value of this kit wasn t electronics. It was having a great way for me to spend a lot of time doing things with the boys which all of us enjoyed. Those hours building things together were as much a present for me as for Jacob, I m quite sure. Jacob s real party was a few weeks ago at the Great Plains Transportation Museum in Wichita. They let people rent a historic caboose to use for a birthday party for children. So we did that for Jacob this year. That was a huge hit for the boys. Jacob got to help his grandpa make some pie (instead of cake) for the party. He enjoyed eating it, of course. He enjoyed opening his presents high up on the observation chair in the caboose. And the boys got to play on all the other equipment in the museum. Jacob enjoyed playing tour guide for family since most of them hadn t been there. He also enjoyed watching freight trains pass on the other side of the fence from the museum preferably while sitting in one of the museum s engines. Oliver certainly didn t get left out. Train-watching is serious business, after all. Jacob has long talked about going to the train museum and the airplane museum (Kansas Aviation Museum) on the same day, so one of his birthday surprises was that we went to the airplane museum after his party. His favorite item there is a retired FedEx 727. Here he is walking down the rear of the plane. And, of course, they played captain and co-pilot in several different planes.