DebConf11 program, the FOSS way I'm going to DebConf11 and, once more, I'm thrilled at idea of living for about 2 weeks immersed in a very very very, very Debian-ic life. DebConf10, DebConf edition of last year, has been for me one of the most intense DebConfs ever, it would be hard to match it. But one of the nice things about DebConf, no matter the edition, is that it's very "open source" and do-ocratic in they way it is organized: everyone could contribute into making it even better than the previous edition. For one thing, there is no "event organizer" company behind DebConf. Rather, most of the hard work that goes into making a DebConf possible is done by the DebConf team, a volunteer team formed by a mixture of Debian contributors, local team members, and DebConf enthusiasts. But while they take care of most of the work and hence deserve the thanks of all DebConf attendees for that they do not account for all that makes a DebConf a great DebConf. For instance, having a great program is up to DebConf participants and the event proposals they submit: talks, BoF, panel discussions, film projections, contests, you name it. Today, in deadline frenzy mode (read on), I've submitted for review the following events for DebConf11:

• bits from the DPL, the traditional "state of the union"-like address
• Test Driven Development BoF, about DEP-8 and autopkgtest (co-authored with Tom Marble)
• sprint and money BoF, to review one year of the Debian sprint program and further discuss how we use donations to the Debian project
• Debian dErivatives eXchange BoF, about DEX and other initiatives to improve collaboration with Debian derivatives
• DebConf in Debian BoF: one year later the "DebConf vs Debian" BoF, what's the state of integration of DebConf in Debian? (spoiler: good!) how can we improve it further? (co-authored with Gunnar Wolf, Holger Levsen, and Moray Allan)
• DPL wannabe BoF: inspired by a discussion during this year DPL campaign, an attempt to explain what the "DPL job" is about and, who knows, collect "training" material for wannabe DPLs
• rolling BoF: let's summarize the monster thread about Debian rolling for those we lost half-way through and present the advancements of more recent and consensual proposals (this event is actually not by me: I've just prodded some of the rolling proponents on IRC and Raphael Hertzog has kindly agreed to submit and organize the BoF)

That's it from me, how about you?
Are you going to DebConf and willing to attend a conference with a great program? Great, then start submitting a great event yourself! Anything you are working on in Debian or you are excited about qualifies. And don't worry if you've never attended DebConf either, video archives from past DebConfs can give you more than a feeling of typical DebConf events. While the first deadline for events submission expires today, submissions will be open all the way to the end of the conference, but you should better hurry up as the early birds get the best scheduling slots (and missing the deadline, you'll miss the round of the review for the main program ... but you still have a few hours left :)). Good luck and see you in Banja Luka.

Date for end of sponsored registrations for this years DebConf11 in Banja Luka was set for May 8th, today that date has officially been extended to May 19th. Now to answer your question on why are you extending sponsored registrations 12 hours before it ends here s the answer. Registrations are going fine, we have more then 300 attendees who registered so far, it is due to change in our monetary resources as sponsorship level has changed from one to another, and we ve be granted to welcome more people. But it is also to give some possible attendees more time and information, as I ve got a feeling a lot of people from this region and elsewhere have been lacking some even general information, and thus I d like to bring everything closer to everybody. Before anything, heading to our website might be a good start as we have immense amount of information up there. Since government of Republika Srpska is our greatest and main financial sponsor, local team has made a document for them in which we tried to explain most basic and crucial things from what DebCamp and DebConf is over logistical/statistical data to what we have planned for Fun and Free time, so checking out that document might be a good idea as well DebConf11 Plan and Program. Since that might be too much for somebody as the documents stretches to some ~30 pages, I ll try to give answers to most common/asked questions. Registrations Who should register? In plain English, everybody. Only people that don t need to register are people who will attend Debian day, please see Plan and Program section 5.3 for more information on Debian Day. If you want to attend any of the DebConf lectures/presentations/whatever you should register. Registrations will play great deal in this years DebConf as if you register you ll get accreditation with your name on it and what you re allowed to do. Whether you have sponsored food/accommodation and thus allowed to eat for free or that you can sleep in certain hotel, or whether you re allowed to the pools for free; also as we re planning to have tight security in our Venue, in order for you to even enter Venue building you ll need to have accreditation on you. So, if you re planning to do anything with DebConf please do register. What is DebCamp/should I attend DebCamp? Please refer to Plan and Program document it s all said at the end of page 15. Sponsorship After registrations this is next thing that is brought up and that is most unclear to most of you. You re able to request travel, accommodation and food sponsorship, what each of those means is pretty self elaborate. But the real question here might be, who is eligible to request sponsorship? Again, everybody. What are is the criterion for getting sponsorship? There really isn t a written rule who gets the sponsorship and who doesn t but if you have ever been involved or contributed in any sort of way to Debian, or even have contributed or have been involved in any open source projects you re more then welcome to apply for sponsorship. Furthermore, due to the funds that we have been granted from Government of Republika Srpska, I even encourage you to ask sponsorship, don t be intimidated and just do it Professional/Corporate This is category for those who are sent by their companies, and whose participation/attendance is sponsored by the same. Professional covers the price of actual costs of their visit, while the corporate is double that price, which is for those who besides paying the actual costs also want to contribute money and help Debian. Organized transport and getting to Banja Luka Now, for those who are flying to Banja Luka I personally told you to come to via Zagreb. Why did I do this, if Banja Luka has its own airport? I told you this because Zagreb is much larger airport and thus has many budget companies, meaning cheaper flights. Once the registrations are closed, based on your arrival/departure dates we ll be able to statistically predict how many of you will be coming to Zagreb on each date and each time as we re planning to have organized transport. This means that we ll send buses/shuttles to pick people up in Zagreb. Of course to have this organized we ll need to set up arrival/departure pages with all the information that s need for us to have this organized. Now, for those who want to come directly to Banja Luka airport this might be bit pricer then going via Zagreb, but not by much. I personally value my time and I even fly from Zagreb to Sarajevo Phil for example booked his flight just this morning from London via Ljubljanja to Banja Luka and it wasn t that much more expensive then Zagreb. Also worth noting is that Banja Luka might be limited for some destinations, but I for a fact know that there are flights coming from Zurich, Ljubljanja, Belgrade and so on. Maybe someone from Banja Luka could follow up on this one with more information. Questions? With this post I hope I have brought some of these topics closer to you and that I made some things clearer. If you have any questions, please feel free to leave your comments or email whatever you re concerned about to our mailing list on: debconf11-localteam@lists.debconf.org Further reading:
Gunnar Wolf Posts explaining DebConf

This June, soon after my seventh anniversary with Canonical, I will finish my job as Ubuntu CTO at Canonical. You can read my official announcement on the Canonical blog. It s sometimes hard to believe that it s been that long since we first envisioned a Linux desktop for human beings . When I look at how far we ve come, at the difference we ve made to so many people, it s easy to see how the time passed so quickly. It s been an incredible experience for me to play a part in building Ubuntu and Canonical. Whether building a decentralized company of hundreds of people, to a global community project of tens of thousands of members, I m grateful for all of the learning opportunities along the way. It has been a privilege to work with so many brilliant, passionate and thoughtful people under such auspicious circumstances. There is much I will miss, and I have many memories to enjoy, from all-night global hacking sessions driving toward a ship date, to casual singing and playing music at our many face-to-face events Nonetheless, it is time for me to seek out new challenges and stretch myself in new ways. I ll be moving back to the US, closer to old friends and family, and starting a new job with a different type of company. I am leaving behind a capable and dedicated team at Canonical, who I am confident will achieve even greater things in the years to come. I will remain active in the free software community as a volunteer. I intend to continue to participate in Ubuntu, and to serve on the Technical Board. I will also be continuing my work with Debian and the DEX project. This year, I ve accepted advisory positions with the Ada Initiative and the Freedom Box Foundation, and will continue to support those organizations and their missions. I ll be in Budapest at the Ubuntu Developer Summit for the next week, and look forward to seeing my friends in Canonical and the Ubuntu community. I ll have more to say soon about what I ll be doing next professionally. Watch this space for updates!

Yay! As others have started posting in Planet Debian, I'll do my part: Yesterday I finished booking our flights, so if everything goes as planned, Reg and me will be arriving to Zagreb (Croatia) at 21:30, Monday July 18, to take part of the 12th Debian development conference, DebConf11, in Banja Luka, Bosnia & Herzegovina! Of course, reiterating this will never hurt: Do you want to support a global-scale, well-recognized, community-based Free Software project development? Be a sponsor for DebConf11!" Want some more DebConf11 banners and posters?

One important aspect of the mancoosi project is to build a model of the installation process in order to simulate packages upgrades before committing the changes on the machine. This work described here and here (and in upcoming publications) relays on the availability installation plan of the meta-installer (the exact order in which packages will be installed, configured and removed ) to run a simulation of maintainers scripts and check for potential problems accordingly to the model. Thanks to the help of Julian Andres Klode upstream and maintainer of the python-apt bindings it is now possible to extract the installation plan from apt-get without resorting to debug printout or other hacks. A forthcoming integration with mpm (Mancoosi-Package-Manager, our testbed meta-installer) will give us the possibility to hook the model checker to the meta-installer and to run it before every upgrade. The two important changes in the python-apt bindings that will make this possible are the new bindings to the class OrderList and the sub-classing of the class package manager. PackageManager . Regarding the latter, this is a small example (thanks again Julien !) that you can use to get the installation plan as computed by apt-get. In theory, this will also allow to experiment with different back-ends (like rpm - blah ! :) ) easily without the need to hack the c++ code. And this is the result on my machine :

It's time to report again progress on phpMyAdmin translations. I will make it shorter this time :-). There has been great progress in translation progress. Japanese translation is near completing (only 55 messages are missing right now) thanks to Yuichiro who did tremendous work there. There is also ongoing effort for Sinhala translation lead by Madhura Jayaratne. Nevertheless the number of complete translations is still 14 (see my previous post for complete list). Besides translating phpMyAdmin itself, there was lot of work on translating documentation, so we now have complete documentation translated to Spanish and very good progress on Chinese one. As the final release of 3.4.0 is really close, anybody is welcome to translate missing bits. Any Norwegian, Polish or Finnish readers of this blog? I'm sure you can still make your translation complete! (Others are welcome as well of course.)

Filed under: English Phpmyadmin 0 comments Flattr this!

In my article "Last time I've used network-manager" I made a claim for which I've been criticized by some people, including Stefano, our current (and just re-elected) DPL. I said that a certain pattern, which showed up in a certain thread, were a prototype for discussions in the Debian surroundings.

Actually I have to commit, that this was a very generalizing statement, making my own point against the discussion point back directly at myself.
Because as Stefano said correctly there has been some progress in the Debian discussion cult.
Indeed, there are examples of threads, were discussions followed another scheme.
But to my own advocacy I have to say that such changes are like little plants (in the botanical sense). They take their time to grow and as long as they are so very new, they are very vulnerable to all small interruptions. Regardless of how tiny those interruptions may seem.

I've been following Debian discussions for 6 or 7 years. That scheme I was describing was that which had the most visibility of all Debian discussions. Almost every discussion which were important for a broader audience followed that scheme. It has a reason that Debian is famous for flamewars.
In a way its quiet similar to the network-manager perception, some people have. Negative impressions manifest themselves. Especially if they have years of time.
Positive impressions does not have a chance to manifest themselves as long as the progress is not visible enough to survive small interruptions.

I hope that I didn't cause to much damage with my comment, which got cited (context-less) on other sites. Hopefully the Debian discussion cult will improve further to a point where there is no difference between the examples of very good, constructive discussions we already have in some parts of the project and the project-wide decision-making-discussions which affect a broad audience and often led to flamewars.

I use USAA for some of my finances. They specialize in remote banking (i've never been in a physical branch). Sadly, they can still be pretty clueless about how to use the web properly. My latest frustration with them was trying to use their Deposit@Home service, where you scan your checks and upload them. No problem, right? I've got a scanner and a web browser and i know how to use them both. Ha ha. Upon first connecting, i'm rejected, and i find the absurd System Requirements -- only Windows and Mac, and only certain versions of certain browsers. You also need Sun's Java plugin, apparently. Deliberately na ve, i call their helpdesk and ask them if they could just give me a link to let me upload my scanned checks. They tell me that they want 200dpi images, and then give an absurd runaround that includes references to the Gramm-Leach-Bliley Act as the reason they need to limit the system to Windows or Mac, and that security is the reason they need to control the scanner directly (apparently your browser can control your local scanner on Windows? yikes). But they let slip that Mac users don't have the scanner controlled directly, and can just upload images (apparently the federal law doesn't cover them or something). Preposterous silliness. The Workaround Of course, it turns out you can get it working on Debian GNU/Linux, mainly by telling them what they want to hear ("yes sir, i'm running Mac OS"), but you'll also have to run Sun's Java (non-free software) to do it, since their Java uploader fails with nasty errors when using icedtea6-plugin. I set up a dedicated system user for this goofiness, since i'm going to be running apparently untrustworthy applets on top of non-free software. I run a separate instance of iceweasel as that user; all configuration described is for that user's homedir. If you do this yourself, You'll need to decide if you want the same level of isolation for yourself. So i have the choice of installing sun-java6-plugin from non-free and having the plugin installed for all web browsers, or just doing a per-user install of java for my dedicated user (and avoiding the plugin for my normal user). I opted for the latter. As the dedicated user, I fetched the self-extracting variant from java.com, unpacked it, and added it to the iceweasel plugins:

chmod a+x ~/Download/jre-6u25-linux-i586.bin
mkdir -p ~/lib ~/.mozilla/plugins
cd ~/lib
~/Download/jre-6u25-linux-i586.bin
ln -s ~/lib/jre*/lib/*/libnpjp2.so ~/.mozilla/plugins/

Then i closed iceweasel and restarted it. In the relaunched iceweasel sesson, I told Iceweasel 4 to pretend that it was actually Firefox 3.6 on a Mac. I did this by going to about:config (checking the box that says i know what i'm doing), right-clicking, and choosing "new >> string". The new variable name is general.useragent.override and i found that setting it to the following (insane, false) value worked for me:

Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.9.2.3) Gecko/20060426 Firefox/3.5.18

Note that this configuration might make hotmail think that you are a mobile device. :P If you try to use this browser profile for anything other than visiting USAA, you might want to remove this setting, or install xul-ext-useragentswitcher to be able to set it more easily than using about:config. Once these changes were made, I was able to log into USAA, use the Deposit@Home service to upload my 200dpi grayscale scans. I guess they think i'm a Mac user now. The Followup After completing the upload, I wrote them this review (i doubt they'll post it):

The Deposit@Home service has great potential. Unfortunately, it currently appears to be overengineered and unnecessarily restrictive. The service requires two scans (front and back) of the deposited check, at 200dpi, in grayscale or black-and-white, in jpeg format, reasonably-cropped. The simplest way to do this would be to show some examples of good scans and bad scans, and provide two file upload forms. Once the user uploaded their images, the web site could run its own verification, and display them back for the user to confirm, optionally using a simple javascript-based image-cropper if any image seems wrong-sized. This would work fine with any reasonable browser on any OS. Instead, Deposit@Home requires the user to present a User-Agent header claiming to be from specific versions of Mac or Windows, running certain (older) versions of certain browsers, and requires the use of Sun's Java plugin. Entirely unnecessary system requirements to do a simple task. Disappointing. :(

Acknowledgements I found good background for this approach on the ubuntu forums. The Takeaway I continue to be frustrated and annoyed by organizations that haven't yet embraced the benefits of the open web. Clearly, USAA has spent a lot of money engineering what they think is a certain experience for their users. However, they didn't design with standard web browsers in mind, so they appear to have boxed themselves into a corner where they think they have to test and approve of the entire software stack running on the end-user's machine. This is not only foolish -- it's impossible. When you're designing a web-based application, just design it for the web. Keep it simple. If you want to offer some snazzy java-hooked-into-your-scanner insanity, i will only have a mild objection: it seems like a waste of time and engineering effort. My objection is much stronger if your snazzy/incompatible absurdity is the only way to use your service. A simple, web-based, browser-agnostic interface should be available to all your clients. Even more aggravating is the claim that they don't think they should engineer for everyone. I was told during the runaround that they would only support Linux if 4% of their users were using Linux (which they don't think is the case at the moment -- if you are a USAA customer, and you use something other than Mac and Windows, please tell them so). I tried to tell them that I wasn't asking for Linux support; i was asking for everyone support. If you just use generic engineering in the first place, there's no extra expense for special-casing other users. But they couldn't understand. And now, since i'll need to lie to them in my User Agent string every time i want to deposit a check online, those visits won't even show up in their logs to be counted. "Our web site deliberately disables itself for $foo users; we haven't written it for them; but that's OK, we don't have any $foo users anyway" is a nasty self-fulfilling prophecy. Why would you do that?

Curious about these shiny new things i keep hearing about, i set up a test desktop system using using systemd as the init system (yes, that means using systemd-sysv in place of sysvinit -- so i had to remove an essential package for this to work). A system-crippling bug was naturally the result of living on the bleeding edge, but fortunately it was resolved with a trivial patch. In all, i'm pretty happy with some of the things that systemd seems to get right. For example, native supervision of daemon processes, clean process states, elimination of initscript copy-paste-isms, and socket-based service initiation are all obvious, marked improvements over the existing sysvinit legacy cruft. But i'm a bit concerned about other parts. For example, all the above-mentioned features fit really well within a tightly-tuned, well-managed server. But systemd also appears to rely heavily on complex userland systems like dbus and policykit that would be much more at home on a typical desktop machine. I've never seen a well-managed server installation that warranted either policykit or dbus. Also, given the bug i ran into -- when PID 1 aborts due to a silly assertion, your system is well-and-truly horked. Shouldn't a lot more attention to detail be happening? I'd think that a "recover gracefully from failed assertions" approach would be the first thing to target for a would-be PID 1. I'm also concerned about the Linux-centricism of systemd. I understand that features like cgroups and reliance on the spiffiness of inotify are part of the appeal, but i also really don't want to see us stuck with only One Single Kernel as an option. The kFreeBSD folks (and the HURD folks) have done a lot of work to get us close to having some level of choice at this critical layer of infrastructure. It'd be good to see that possibility realized, to help us avoid the creeping monoculture. I worry that systemd's over-reliance on Linux-specific features is heading in the wrong direction. So my question is: why is this all being presented as a package deal? I'd be pretty happy if i could get just the "server-side" features without incurring the dbus/policykit/etc bloat. I already run servers with runit as pid 1 -- they're lean and quite nice, but runit doesn't have systemd's socket-based initiation (or the level of heavyweight backing that systemd seems to have picked up, for that matter). I understand that Lennart is resistant to UNIX's traditional "do one thing; do it well" philosophy. I can understand some of his reasoning, but i think he might be doing his work and his tools a disservice by taking it this far. Wouldn't systemd be better if it was clearer how to take advantage of parts of it without having to subscribe to the entire thing? Of course, i might be missing some nice ways that systemd can be effectively tuned and pared down. But i've read his blog posts about systemd and i haven't seen how to get some of the nice features without the parts i don't want. I'd love to be pointed to some explanations that show me how i'm wrong :)Tags: systemd

Since my latest announcement of the Lua workshop, I received a couple of emails asking why I discourage the use of Lua. Actually, I already wrote out many of the things I dislike about Lua. I won't come back on this technical issues here, but since Lua 5.2 is not yet released (it's still at alpha stage), they are still relevant nowadays. Stack based API is harder

The ease of integration of Lua into a C program is one of the point of Lua. They claim it's very easy to integrate Lua into your C application, because it does not use pointer, nor reference counting, nor anything that requires a minimum amount of skills to be used. It uses a virtual stack based approach. You push or pop things on a stack, and refers to them using a relative or absolute index. In order to people who never wrote Lua code to understand, here's a quick example on how this work. The L pointer is a Lua environment.

/* Create a table on the stack: index 1 */
lua_newtable(L);
/* Push a string on the stack: index 2 */
lua_pushstring(L, "hello");
/* Push a number on the stack: index 3 */
lua_pushnumber(L, 123);
/* Set newtable["hello"] = 123 */
lua_settable(L, -3);

You first push a table (in Lua, a table is almost equivalent to what you'd call a hash table in other language), then push the key, the value, and do the assignment operation. In the settable, we use -3 as index, meaning the "3rd item on the stack counting from top". We could also have written lua_settable(L, 1), since the table is also the first item on the stack from the bottom. So far, so good. Problems arise when you do more complicated stuff. My previous example is what you would typically find in a tutorial, but of course, real life is different, and usually more complex. If you cut the things in different parts, it can start to be more complicated. Let's take a look at the following:

/* Create a table on the stack: index 1 */
lua_newtable(L);
/* Push a string on the stack: index 2 */
lua_pushstring(L, "hello");
/* Push a number on the stack: index 3 */
lua_pushnumbe(L, mycomputingfunction());
/* Set newtable["hello"] = 123 */
lua_settable(L, -3);

Here, we do exactly the same thing, but we do not push 123 directly: we compute it. And here's the trick: if your computing function is also using the Lua stack, things can become very messy. As long as your computing function use the stack cleanly by pushing and poping all its item, and returning the stack in the same state it was before, you're safe. The problem is that in a complex program, you also write bugs. You do not chose to, but you do. And sometimes, you forget to pop one of the item you fetched from a table. Imagine that mycomputingfunction is:

int
mycomputingfunctiong(void)
 
  /* Just push the table we want to fetch
     the number from on the stack */
  pushatableonstack(L);
  lua_pushstring(L, "mykey");
  lua_gettable(L, -2);
  return lua_tonumber(L, -1);
 

This function works perfectly. It pushes a table, then a key ("mykey"), then fetches mytable["mykey"] and pops the key (lua_gettable does push value/pop key itself), and then returns the numeric value of the last item (the fetched one) of the stack. However, this function has a bug: it does not pop the table! This does not prevent the function to work. It does not raise a segmentation fault. It does not show any problem under gdb. It does not show any leak under Valgrind. It does now show any problem under any standard C debugging tool. But when you'll start using it, your program will start to do weird things, and you'll have to spend a huge amount of time debugging it manually, dumping the stack content at each step of your program to watch out what's wrong. Another bad thing, that can happen, is some code poping accidentally an item from the stack, or worst, from an empty stack. This does not raise any error on the Lua side, but will break your program in very unfunny way. Even if I've been very meticulous writing awesome, but we hit that problem regularly. The easiest workaround is to use lua_settop(L, 0) to reset the stack to 0 element. Doing this regularly (like after each program event or treatment) can remove left-over items and avoid the never ending stack grow you may experience if your left-over items continue to pile up. Did I tell you I dislike work-around? You could also use lua_call(), which would avoid such an error, but this would require a huge amount of indirection, and would make write more (useless) code. This kind of problem does not exists with pointer based API. If you screw things up, the problem will cause a segmentation fault or leak memory, or cause things you can (easily) debug with standard tools like gdb or Valgrind. No reference counting is a pain in the ass

Userdata objects are variable Lua size objects embedding a C struct you define. It's the equivalent of an object in object oriented language. Lua does not provide any reference counting for the userdata objects. That means you can push this objects on the stack, use them, but they cannot directly reference each others. If you have a "car" userdata and a "wheel" one, the car cannot hold directly a reference to the wheel. This is not possible because userdata are allocated and garbage collected by Lua, and there's no way to increase the reference counting yourself. So the common hack is to store the wheel into a table as a value, and store the table index as an integer into the car data structure. This obviously makes memory leaks tracking harder, add huge level of reference indirection in usage (still more code), and does not make the whole process less error prone (at least in my opinion). No paradigm makes you lose time

Lua is proud to come with no paradigm and to provide metatables. I already showed 3 years ago that it has big flaws. To me, this ain't no good. Lua is not functional, nor it is object oriented. Most people, including me, want one of this paradigm, or any else. Plain old imperative is not enough. So you'll start to build more, or to use something like LOOP, which implements an object model. You'll implement your paradigm. I say life is too short to (re)write a paradigm. In awesome we wanted to have an object oriented approach (this is kind of typical in such a graphical application context), so we tried to build one. To me, this started to be a show stopper when I realized that I've ended writing Python object model into Lua while developing awesome (which aims to be a window manager, not a language). This is one of the reason I stopped hacking on Lua things. I liked Python object model and wanted to have it in Lua, and spending time rewriting Python is just not worth it. I probably should have chose Python, not Lua. YMMV. Embedding may not be a good choice

This is not Lua related, but I want to mention it. Googling for "embedding vs extending" will probably tell you more about why you should double check that you really need to embed Lua rather than to extend it. Being small is not an excuse

One common argument to choose Lua is that it has a small footprint. Yeah, that's true, but that's useless. Bummer! When I program, I don't have any resource usage pressure. People who have such pressure are either paranoids or playing in the world of embedded computers. This is also a no more existing conception since quad core processors equiped phones are coming into the market. I'm rather confident that what we used to call embedded devices are just dead and are now plain computers. But as usual, YMMV. So start to forget about it, run in your underpants and yelling "yay we killed that shit!", and then use real computers stuff. :-) Even if benchmarks show how Lua is damn fast, remember what a benchmark proves: that you can do useless things very fast. Too few extension modules

This is not directly Lua's fault, but there's too few extension modules for Lua. The community is quite small compared to other big languages' ones. So think twice

before you choose Lua (or any other language). My recommendations these days would be not to embed, but to extend. If you really have no choice and need to embed a language into your application, GNU Guile is probably worth considering, because it's a Scheme and therefore a functional language :-), and because it can provides also different languages. Including Lua.

I d like to extend a warm welcome to our new batch of students selected for the 2011 Debian Google Summer of Code! They should soon be posting on Debian Planet and you re welcome to come talk to them on #debian-soc on irc.debian.org Further details will be posted in the coming days to our wiki: http://wiki.debian.org/gsoc Automated Multi-Arch Cross-Building and Bootstrapping aka autocrossbuild , by Gustavo Prado Alkmim, mentored by Wookey
Enable easy and automated setup of cross-platform automated build systems and bootstrapping for QA in the Multi-Arch era. This involves the creation of multi-stage bootstrap build sequencing tools and a reliable automated multi-arch cross-builder. APT/Dpkg Transaction Ordering for Safety and Performance aka aptordering , by Chris Baines, mentored by Michael Vogt
The ordering code in libapt is responsible for ordering the unpacking/configuration of debs so as to ensure dependencies are satisfied etc. Currently it organizes the ordering into big batches. This project further implements an ordering satisfying more constrains such as minimal amounts of dpkg invocations , minimal amount of broken packages at any point . DebDelta APT Native Integration aka debdelta , by Ishan Jayawardena, mentored by Michael Vogt
Improve user experience of APT and its front-ends by speeding up the upgrade process. This provides a better framework for unified handling of debdelta and future APT improvements such as parallelism. Support for stable and security ugprades as well as multiple APT related libraries is expected. Dpkg Declarative Diversions aka declarativediversions , by Sam Dunne, mentored by Steve Langasek
The dpkg-divert command should be replaced with a new control file with a declarative syntax which Dpkg will parse and process directly as part of the package unpack and removal phases, eliminating the problems resulting from non-atomic handling of diversions. Backend Tools and Infrastructure for DEX aka dextools , by Nathan Handler, mentored by Matt Zimmerman
EX is a new program designed to help improve Debian and its derivatives by merging in changes made downstream and encouraging discussions between the various projects. As this is a new project, most of the infrastructure does not exist (or is rather hackish and incomplete). This project will create the necessary backend tools and infrastructure so that all Debian derivatives can easily make use of the DEX project. Jigsaw Modularized Java in Debian aka jigsaw , by Guillaume Mazoyer, mentored by Tom Marble
The Java Development Kit (JDK) is a big monolithic software tool: many of its features are only useful in limited areas (GUI toolkits are useless for a web server). This project will bring the Jigsaw modular JDK to Debian, helping performance (start-up, size, etc) but also the dependency resolution (to match Debian packaging). Some work exists upstream does not fit with Debian. This project will package the current development version of Jigsaw, update Debian Java Policy, and create the necessary packaging tools for software depending on it. Python Multi-Build for Python Extensions Packaging aka pythonmultibuild , by Mesutcan Kurt, mentored by Piotr O arowski
This project creates a tool to build Python extensions for all Python versions supported by Debian at the time. The project should detect the upstream build system and testing frameworks and use them. It will be interfaced with CDBS and the dh sequencer, replacing their Python snippets. Debian Teams Activity Metrics aka teammetrics , by Sukhbir Singh, mentored by Andreas Tille
This project will gauge the performance of teams in Debian by measuring metrics such as: postings on relevant mailing lists, package upload records from the Ultimate Debian Database and commit statistics from project repositories The information gathered will help in evaluating team performance by measuring how people in a team are working together. An interface to access this information easily will also be developed. Compute Clusters Integration for Debian Development and Building aka computeclusters , by Rudy Godoy, mentored by Steffen M ller
The project s main goal is to enable developers to easily use compute clusters (Eucalyptus, OpenStack ) as environments for arch-specific development by providing a set of tools they can use to setup and run an extended platform for their development, testing and building tasks. Good luck to everyone!

Terah and I recently decided that each of us could use a day off of not having to do work or supervise boys. Yesterday I had the day off work so that was mine. I took my Kindle, along with its Gutenberg copy of War and Peace, which yes, I m reading for fun. I slept in a bit, then got breakfast and sat down at Botanica, the Wichita Gardens with the Kindle for awhile. That was a nice way to spend the morning. Today was Terah s day off. Initially I thought of taking the boys to The Cosmosphere, one of the world s premier space museums, or to the Kansas Aviation Museum. But then I realized that the Midland Railway, a historic excursion line in Baldwin City, KS, was having their first train trip of the year. And it s the Easter special: you take the train a few miles out of town, get off, the kids do an Easter egg hunt, then also get to get their picture taken with the Easter bunny. Kid paradise, right? What could be better? So this is how my alarm came to be set for 5:15 on a Saturday morning. Oliver woke up early, but I had to get Jacob up. He was groggy, trying to cover his face and ears, and annoyed at me for trying to wake him up. Until I said, Jacob, it s time to get ready for the car trip to the train ride. Can you go get dressed for the day? Silence. Then about 5 seconds later, he jumped up, said, OK dad, I will do it, and he did. We drove our 2.5 hours. I had set out a non-dirty breakfast in the car for them the night before, so they munched while we drove. Then had to wait in a huge line for our tickets. An hour later we had them got the last 3 tickets for the first departure of the day, 10AM and ran to get on the train before it left. Jacob and Oliver both got very quiet. Sometimes Jacob especially does that when he s very excited about things. He doesn t always look it right then, but I knew I d be hearing about it later. He had his face almost pressed to the window the whole way. Oh, and yes, he dressed himself and I didn t check to make sure he had the correct shirt, or that it wasn t on inside-out, until it was too late. Oops. We rode in an ex-CP car built in 1936. One of the cars on the train was built in the 1890s quite some neat equipment. Anyhow, next came the hunt. There were two large lawns covered in eggs, separated by age group. Jacob and Oliver were in the younger group, but still only got a few eggs (there were lots of other parents, uhm, helping their kids by picking up eggs the kids were too slow to get and putting them in baskets ) But they were thrilled with the experience so that s what counts. They moved the locomotive to the other end of the train for the trip back using an adjacent track. Lots of the kids watched them couple it back on. Jacob and Oliver were particularly interested nothing could have distracted them from watching that train though they didn t particularly like the noise of the horn. On the way back, someone in an Easter bunny suit was on the train for pictures. I took the boys there. They usually refuse to sit on laps of Santa and such, so I didn t figure much success. They actually agreed to do it. And despite their expressions in this photo, Jacob later told me over and over how much fun it was to be with the Easter bunny. After we got back, we headed for the car. Jacob insisted on carrying his own Easter bag, and predictably wound up carrying it upside down for awhile. So his bag had some grass in it from picking the candy back up. Oliver discovered some rocks by a ditch and had fun throwing them in to make a splash, so we paused for that for awhile. By this point it was about noon. So at this point, what does a dad who has managed to keep two active boys in line for an hour, help them with an egg hunt and giant rabbit, and keep them from falling into the ditch they re throwing rocks into, do? Say that it s time to eat lunch and then head for home so we can be there in time for supper? Or go for MORE ADVENTURE? I said, Jacob, how would you like to eat lunch inside a big train station in Kansas City? Pause for a couple of seconds to think. YEAH! I have never had lunch in a train station before! Let s go! Shall we go NOW? So I gave them the leftover breakfast to eat during the hour drive on towards the beautiful Kansas City Union Station. It s one of the few grand American train stations that survives intact, and is just stunning. Jacob and Oliver both fell asleep on the way there. We parked, walked inside, and Jacob just froze. Dad WOW! That ceiling is SO HIGH! I can t even reach it! He then raised his hand as high as it would go and said, See dad, it is so high I can t touch it! (Most ceilings are, but this one is indeed much, much taller than most.) We ate lunch in the second level of a restaurant right in the Grand Hall, which Jacob really enjoyed. Here s Jacob, annoyed that I pulled out the camera again: Then we went exploring for an hour. Jacob talked about his adventure . We went up the elevators and checked out the balconies. Then we found the Model Railroad Experience. And oh my. The boys were visibly the most excited they had been all day. Oliver just froze at the spot he walked through the door, not caring to move and see the rest of the exhibit because he was so fascinated by what he already saw. There was a huge layout in the middle of the room, and smaller ones in adjacent rooms. We finally made our way there, and Oliver just ran round and round one of them, following a train, excitedly yelling There it is! There it is! There it is! Here s a photo from the big layout: Jacob cried when it was time to go, but I had promised them some dessert before we left, so after a bite of ice cream we were on our way. On the way home, every 15 minutes or so, Jacob would make a remark like this: Dad, the train ride was SO fun! or Dad, I really liked Kansas City Union Station! and so forth, naming every highlight of the day for him several times over: the Easter bunny, the egg hunt, train ride, and everything about Union Station. On the way home, we stopped at our favorite restaurant in Emporia: BobbyD s Merchant St. BBQ. This is always a hit for everyone in the family. A down-home place that has excellent food, is not far off our path, and never seems to have a wait. Yum.

So how much wind energy can we realistically use? A paper (Earth System Dynamics, DOI: 10.5194/esd-2-1-2011) by Miller,Gans and Kleidon (MGK10) has generated a lot of controversy courtesy of a New Scientist review (See Climate Progress for a good rebuttal). They argue that the effective limit we can safely extract without (bad) climatic consequences is around 18--68 TW (we currently use 0.2 TW of wind power). This paper is a follow-on to Kleidons work on the thermodynamics of the climate, where he points out that the free energy is the important measure of what energy can be generated by renewables. The free energy of the atmosphere is on the scale of hundreds of TW, he argues, much less than the heat energy of ~10^5 TW that comes from the sun. He argues that not enough attention is paid to the free energy budget, and argues that from MEP theory that free energy flows through different geophysical processes are more important than people currently think: such energy and momentum flows then lead to faster depletion of gradients than people currently use in their models. Frequently we use "diffusive-like" approximations to stuff we can't explicitly handle,such as convection and eddies below the resolution of our computer models. That the free energy budget, and small-scale processes need more detailed study (such as the transfer of momentum and energy from wind to water), I agree. But paradoxically, MGK10's estimates based on diffusive processes are what gets it into trouble. The critiques (e.g. Jacobsen and Archer) seem to concentrate on the estimates for diffusive and other energy losses (eg. wake fields) and climatic consequences are very loose, and out by factors of 50-100. They also ignore the fact that using wind as a substitute for more destructive energy sources produces a net gain, climate-wise. Based on these numbers, the real limits on wind power are more limited by where we can realistically place turbines, and the use and availability of rare earth metals in turbine magnets (MW sized turbines use over a ton of neodynium each in magnets!) One of the focuses of research at ICHEC and Met Eireann is wind for wind power: this becomes increasingly important for Ireland as we have more energy production by wind. I've been recently involved in a European project Weather Intelligence for Renewable Energies on investigating weather and climate forecasting needs of wind energy. In our weather models, we are getting to finer and finer resolutions (down to 2-5 km operationally, but working on 1 km in research), but as yet do not take account of wind energy changes. Modelling the wake turbulence, etc. and other effects of turbines is a 'fluid dynamics' problem done by the wind turbine manufacturers, mostly, in order to lay out turbines in a farm efficiently; this is done on the timescale of metres and seconds, while on the other end of the spectrum work is done in climate research on the changes in potential winds to see if wind energy will change in a few decades. But little is done on 'weather' scales of kilometres, minutes and hours: it turns out there are wind patterns that we don't predict in our models (vortices, etc.; especially for offshore turbines) that affect wind energy production, but would be very useful for wind farm and electrical grid operators to know about. So we should think about adapting our weather models for these. Either way, it looks like more detailed work on the interactions between atmospheric dynamics and wind farms would be a good thing. Incidentally, whatever about the alarmist nature of the article, kudos to New Scientist for their linking to papers: they quoted the names of the journals (Earth System Dynamics,Philosophical Transactions of the Royal Society), but where the article was not yet published (or behind a paywall), linked to the Arxiv.org version. More could do this. Tags climate, energy, thermodynamics, science, wind, renewables

I have noticed some problems with how Debian is using the popularity-contest data.

• popcon units are unknown Using the popcon score of a package to measure its use is like using the bleeple score of a trip to measure its distance. Both scores have no sensible units attached, though they may be loosely derived from a unit value. Is a trip with a bleeple score of 99 a long trip? Is a package with a popcon score of 99 a rarely used package? The only way to resolve this ambiguity at all is to compare ratios of values, so the problimatic units cancel out. A flight from NYC to AMS with a bleepie score of 99 is 50 times as bleepie as my drive home, which scores 2. So, any statement like "low popcon score" is basically so lacking in context as to be meaningless. Such statements are deprecated, and should be ignored.
• not all popcon scores are comparable The above example is intentionally bad. Plane flights and car trips are not very comparable when you don't know what units (time / CO2 / distance / number of people sharing a confined space / security theater points) are being used. Similarly, comparing a high popcon package like gnome-terminal with a relatively low popcon package like udhcpc is very deceptive. The former is installed by default in the desktop task, but plenty of desktop users would not miss it. The latter is installed only on embedded systems, which can exist in absurd numbers, and none of which will tend to report to popcon. So, any attempt to compare popcon scores should include a rationalle about why the two scores are comparable. For example, gnome-terminal and rxvt are somewhat comparable since they are both terminal emulators. But, only the vote scores, not the inst scores should be compared, since gnome-terminal is installed by default. dhcp3-client and udhcpc are not comparable despite being similar packages.
• popcon scores do not measure long tail effects A strength of Debian is that not only commonly used, but also uncommon and niche software is packaged. Popcon does not measure the benefit of some little used peice of software being there, packaged and ready to use when a user needs it. For six years I kept satutils in Debian, despite it probably having no users. It has a very specific use case, to control a motorized internet satellite dish typically installed on an RV. I did that because it was essentially no work (the package was approximatly bug free, and required no changes since 2007), and because of the possible payoff if someone needed this thing and there it was, in Debian. The value of Debian in that occasion would spike to a value that, while not directly comparable with a popcon score, would be pretty epic, for that one user, as they pushed arrow keys to move a satellite dish around. (It also had the best WITHOUT WARRANTY statement I've had the pleasure to write: "If you break your dish off your vechicle using this software, you get to keep both pieces.") Every removal of a package for "low popcon score" runs the risk of silently degrading this overall value of Debian.
• who wants to be popular? Part of the problem is that popcon has been around long enough that the connotations of its name, "popularity contest" have been dulled by repetition (and abbreviation). Popularity contests are not pleasant things. They rarely reach the best result. They embody the tyranny of the majority. The name was originally, to the best of my knowledge, chosen exactly to imply all these failings, to say that hey, popularity-contest is deeply flawed, but is better than nothing for this one specific use case (ordering packages to place on CD sets). We no longer think of popcon with these caveats. That is a regression in your brain. Fix it. By removing packages that appear unpopular, we run the risk of Debian becoming bland and homogenous.

The last weeks I spend quite a lot of time hacking on a Python library for the AR.Drone. The AR.Drone is a nice toy for nerds. You connect to it via WIFI and soon you ll realize that it has 4 ports open. Reading the specs you ll find, that on one port it listens for AT-Commands with which you can remote control the drone, on the other two ports it waits for an incoming package which will trigger the drone to send the navdata (speed, angles, battery status, etc) and the video stream. Heck, you can even telnet into the drone Unfortunately it comes without a proper software to control the drone, only an iPhone app (w/o iPhone of course). But given the documentation, it should be easy to write your own. While getting the beast to fly was relatively easy, decoding the almost -jpg-video-stream was not. Almost-jpg, since the images the drone sends are more or less jpg with a small difference which makes it impossible to decode them using standard multi-media libraries. Anyways, the format is documented and implementing a decoder was not that hard. The tricky part was to get the framerates from unacceptable 0.5 FPS to 12-22 FPS the whole decoder is written in Python. I m cheating a bit by using psyco, but the code in arvideo.py is heavily optimized to minimize calculations and to please psyco. In the code is also a small demo app which uses Pygame to display the video stream and allows to control the AR.Drone with the keyboard. It should be ready-to-use as soon as you are connected to the drone via WIFI. The git repository is here, the license is MIT. Suggestions and patches are welcome. Here is a video of the drone flying through the office.

Generally speaking it is a really bad idea to hold passwords in cleartext. I am actually amazed people still do this! The standard way of holding passwords that has been around for years is to encrypt or hash the password and store the result, called a ciphertext. There have been many ways of hashing the password, starting off with plain old crypt with no salt (a random pair of characters) then crypt with salt through to MD5 and SHA. The thing is, each one of these hashing techniques results in a ciphertext in a different length. Now with most languages, this doesn t matter because you know what hash you are using; its simply the name of the function or some flag you set. PHP is different, because all of these methods use the one function called crypt which is a little confusing because it is more than plain old crypt. Around the PHP version 5.3 the developers started putting in the more complex hash algorithms which is good, but the ciphertext has been growing. A lot of applications store this hashed password in a database and the decision needs to be made; how big should this field be? For a long while, 50 characters would be enough and this is what programs like jffnms use. Unfortunately the SHA-512 algorithm needs 98 characters so what you get is half a hash stored. When the user enters their password, the program compares the full hash from that password to the half hash in the database and it always fails. I ve adjusted JFFNMS to use 200 character long fields which is fine for now. The problem is who knows what the future will bring?

Related articles

• France to require cleartext password storage (boingboing.net)
• Are You Sure SHA-1+Salt Is Enough For Passwords? (it.slashdot.org)
• What All This MD5 Hash Stuff Actually Means [Technology Explained] (makeuseof.com)
• Serious Security Flaw in Amazon.com Passwords (techie-buzz.com)

Went to loadays, where I did a talk on "Single sign-on with Kerberos and LDAP". Or, at least, that was the intention when I found out that there was going to be a tutorial on LDAP the next day, I decided to focus my talk mostly on kerberos, only lightly touching LDAP. As it turned out, that was a great decision I could easily fill a whole hour on Kerberos, anyway, and though doing a kerberos setup without doing ldap too is fairly silly, doing it properly would have required more time than was assigned to me. Instead, I managed to talk the audience through most of the important theory about kerberos (things like "what is a principal", "what is a ticket", etc), and did a live demo in which I configured a kerberos realm on a virtual machine, and then used SSH to connect passwordless to that machine from a second virtual machine on the same virtual network. While I would've loved to make it even better by throwing in a kerberized HTTP configuration, I couldn't do much more than just mention the fact that it can be done as is the case for sasl-enabled protocols (imap, ldap, smtp, etc) and some other things. The talk seems to have been a success with the audience, too; the room itself was full, nobody actually left (which usually is a good sign in and of itself), and I got only positive feedback from the people who were there; one person even went so far as to say that he considerd it the best talk he'd seen thus far, today. Which I think is pretty high praise, considering how my talk was in the penultimate time slot. All in all, a good day.

Jacob really enjoys his pajamas. By this point, he can mostly get himself ready for bed. He still wants help brushing his teeth but that s about it. His favorite pajamas are his rocket ship pajamas , which also cover his feet and have a white pad underneath the feet. That s his favorite part. They have rockets all over them, and he sometimes will run out of a room and inform me with delight, I m all rocket ships! Oliver has really started to form up words. We can pick out words like lettuce, truck, book, look, and dad John . He also has a way of saying there it is , most particularly when looking at trains. Jacob still loves trains. In church, he will take his markers, connect them end to end, and have a marker train that will keep him entertained for quite a long while. He will slide it back and forth on the pew, and eventually it will slide in a tunnel (behind my back). This actually started with hymnbook trains get a few books in a row, and it s a train. Anything can be a train to Jacob. Driving down the road, we might see what he calls tree trains, which are just trees in a row. Last Sunday, the Kansas Mennonite Men s Chorus had its first concert of the season. I sing with this group, which has nearly 300 men in it. It s a lot of fun to be a part of that group, and the music is wonderful. Jacob and Oliver were there on Sunday, and both started to take more of an interest in the music that before. Jacob particularly loved the song Dry Bones, which had a number of odd percussion instruments in it. He was laughing at spots, and wanted to hear me sing it for the next several days. He even wanted Terah to read the program from the concert to him before his nap one day. Oliver enjoyed it too, and kept saying dad John (his word for me) whenever there was a soloist. I didn t sing a solo, but apparently to 1-year-old eyes, 300 guys all dressed alike all look like dad. Jacob and I recently have been reading Winnie the Pooh stories at his bedtime. Not the Disney books, but the original A. A. Milne stories. We read a few pages every night, and have made it to page 214 by now. Jacob loves it. And he s becoming increasingly interested in reading things. Sometimes we ve been unsure if he s reading something or just had it memorized. Last night, I got out the book, and we were on a page he had never seen or heard before. He pointed to a word, and said, It says Roo there! And indeed it did. Then he added, It says said Roo. . Yep. And then he read me the whole sentence:

I love jumping, said Roo.

I believe that s the first time I ve been certain Jacob has read me an entire sentence without having memorized any of it beforehand. And he won t be old enough to start Kindergarten for another year and a half. We then read the story, and when I came to the sentence Jacob had read to me, he interrupted, saying, No, dad, I will read that one! And he did.

Recently, I've had the pleasure of having to write many short documents in LaTex (short as in 1 to 6 pages). I haven't written a lot in LaTex since my school time, so this was a very nice flashback to those times. However, since then PDF is the new "standard" format, not PostScript, so I had to do a bit of adjustement. The biggest change is that pdflatex doesn't "like" EPS files for images, so what to do? As usual, the road to enlightenment has many turns First, reading docs, I said simple, create a PNG file, scaled at high resolution, then include it scaled down so that it kind of loses the ugly scaled-bitmap feel. But that's not a nice solution: it is still bitmap, just looks like aliased. So I wanted another solution and threw gnuplot's set terminal png and fig2dev's -L png out the door. Next was, of course, embedding PDFs, since pdflatex supports that. However, gnuplot's pdfcairo output is not as nice as I wanted. It works, but only kind of. Issues with font consistency and scaling, etc. Then I remembered the nice pslatex output from xfig, and learned that there's a pdftex output. And that gnuplot also can generate .fig output. So I went and redid my Makefiles and gnuplot command files and everything, and suddenly all looked almost right. There are still a few issues:

• if you select an invalid font in gnuplot (set terminal fig font "foo"), it will simply ignore that font, without any warning
• while you can tell it to set the "special" fig flag on the emmitted text (set terminal fig textspecial) , you can't give gnuplot a LaTex font name, since it only has definitions for the normal PostScript fonts; this can be worked around via giving it a PostScript font that has the same index as the desired LaTex font
• the font size specified in gnuplot is not really influencing the actual fonts used in LaTex
• as xfig doesn't know the actual font rendering box as computed by LaTex, you lose the (simple, but good) WYSIWYG features, and need to go back and forth between the created PDF and xfig to change the actual layout
• if you use a \resizebox around the inclusion of the pdf_t file, the fonts are scaled too, which is plain wrong

So while this setup has some drawbacks, it works well enough. I was happy to simply have a well defined workflow. But then I wanted to do a simple graph (of a 3-wire sorting network), and I realised that positioning all of that using xfig will be painful. I kept stumbling upon pgf and tikz during my previous investigations, and I said I should check it out. Wow. tikz and pgfplot. While you lose a bit on the graphing capabilities, you also gain a lot. Basically one can replace both xfig (instead of hand-drawn diagrams you can actually write them in code, programatically, no more guessing) and gnuplot (so that you have consistent fonts/scaling). I was so amazed at this excellent combination that I've converted for all my new docs to this. And now I have the problem that I keep wanting to write LaTex code in ikiwiki PS: Yes, I've been busy lately, so busy that my Debian work has mostly been suspended. Should be back in about a month or so.