I think I'm currently supposed to be out buying a TV at the moment. Or something else expensive. Instead I'm lying on the sofa listening to Whale and drinking tea. That's much better in my opinion, but it reminded me that I hadn't mentioned that I bought a projector. I had the loan of a projector for a while when I was in Belfast. It was a huge thing that made a lot of noise, but was pretty cool for watching films with. When I moved to the US I decided not to bother with a TV to start with - using my laptop did just fine for most things. Except films. They really benefit from a bigger screen. Especially if you want to watch them with someone else. So I started looking at pico projectors, because I wanted something small and cute that I could throw in a bag with my tiny laptop. At the time the best the pico projectors could do was 840x480, which I felt wasn't really that great. However back in January TI announced their DLP Pico HD chipset, offering a resolution 1280x800. I kept a look out for projectors using this to appear, and eventually, in July, Amazon claimed to have availability of the Vivtek Qumi. So I bought one. And I'm very happy with it. I'm not a heavy user, and there are some niggles, but it's small and does exactly what I want. In low light conditions it'll happily throw an image all the way across the room, which is more than it's rated at. There's a mini-HDMI connector on the back, so it's a doddle to plug it into my laptop using the supplied HDMI to mini-HDMI cable. The laptop auto-detects the device and extends the desktop appropriate, as you'd expect. It'll also do media playback itself - there's a USB host port and a micro SD slot on the back. This works ok, and the included remote means you can easily set the projector somewhere above your head and still be able to easily control it. Unfortunately the built in speakers are fairly useless. There's a 3.5mm socket for external speakers, but having to plug something else in detracts from the convenience factor of the built-in media player. Also my unit had the power switch installed upside down (the little red line indicating the power is on actually shows up when it's off), but that's the only complaint I've got about the build quality. There's a little neoprene case to store the thing in as well. So, er, yeah. I think I can continue to make do without a normal TV for a while longer and avoid the nightmare that I suspect are the shops on Black Friday.

Being tired of feeling embarrassed when noticing some warning in a buildd log only after having it uploaded and looking at the buildd logs of the other architectures, I've decided to write some little infrastructure to scan buildd logs for things that can be found in buildd logs. The result can be visited at https://buildd.debian.org/~brlink/. Note that it currently only has one real check (looking for E: Package builds NAME_all.deb when binary-indep target is not called.) yet and additionally two little warnings (dh_clean -k and dh_installmanpages deprecation output) which lintian could at catch just as well. The large size of the many logs to scan is a surprisingly small problem. (As some tests indicated it would only take a couple of minutes for a full scan, I couldn't help to run one full scan, only to learn afterwards that wb-team was doing the import of the new architectures at that time. Oops!) More surprising for me using small files to keep track of logs already scanned does not scale at all with the large number of source packages. File system overhead is gigantic and it makes the whole process needlessly IO bound. That problem was be easily solved using sqlite to track things done, though as buildd.debian.org doesn't have that installed yet, so no automatic updates yet. [Update: already installed, will be some semi-automatic days first, though anyway] The next thing to do is writing more checks, where I hope for some help from you: What kind of diagnostics do you know from buildd logs that you would like to be more prominently visible (hopefully soon on packages.qa.debian.org, wishlist item already filed)? Trivial target is everything that can be identified from regular expression applied to every line of the buildd log. For such cases the most complicated part is writing a short description of what this message means. (So if you sent me some suggestions, I'd be very happy to also get a short text suitable for that, together with the message to looks for and ideally some example package having that message in its buildd log). I'm also considering some more complicated tests. I'd really like to have something to test for packages being built multiple times to due Makefile errors and stuff like that.

It s general election time again in New Zealand this year, with the added twist of an additional referendum on whether to keep MMP as our electoral system. If you re not interested in New Zealand politics, then you should definitely skip the rest of this post. I ve never understood why some people consider their voting choices a matter of national security, so when via Andrew McMillan, I saw a good rationale for why you should share your opinion I found my excuse to write this post. Party Vote
I ll be voting for National. I m philosophically much closer to National than Labour, particularly on economic and personal responsibility issues, but even if I wasn t the thought of having Phil Goff as Prime Minister would be enough to put me off voting Labour. His early career seems strong, but lately it s been one misstep and half-truth after another, the remainder of the Labour caucus and their likely support partners don t offer much reassurance either. If I was left-leaning and the mess that Labour is in wasn t enough to push me over to National this year then I d vote Greens and hope they saw the light and decided to partner with National. Electorate Vote
I live in Dublin, but you stay registered in the last electorate where you resided, which for me is Tamaki. I have no idea who the candidates there are, so I ll just be voting for the National candidate for the reasons above. MMP Referendum
I have no real objections to MMP and I think it s done a good job of increasing representation in our parliament. I like that parties can bring in some star players without them having to spend time in an electorate. I don t like the tendency towards unstable coalitions that our past MMP results have sometimes provided. Of the alternatives, STV is the only one that I think should be seriously considered, FPP and it s close cousin SM don t give the proportionality of MMP and PV just seems like a simplified version of STV with limited other benefit. If you re going to do preferential voting, you might as well do it properly and use STV. So, I ll vote for a change to STV, not because I m convinced that MMP is wrong, but because I think it doesn t hurt for the country to spend a bit more time and energy confirming that we have the right electoral system. If the referendum succeeds and we get another referendum between MMP and something other than STV in 2014, I ll vote to keep MMP. If we have a vote between MMP and STV in 2014 I m not yet sure how I d vote. STV is arguably an excellent system, but I worry that it s too complex for most voters to understand. PS. Just found this handy list of 10 positive reasons to vote for National, if you re still undecided and need a further nudge. Kiwiblog: 10 positive reasons to vote National

Tomorrow (25th November) evening, I will be giving a short talk about PostgreSQL at the monthly Munich Open-Source-Treffen event.

The meetings start around 6PM and are always in Cafe Netzwerk in Luisenstr. 11, a nice and cosy hangout and hackerspace for young Munich students near Hauptbahnhof.

Could you not trust this man?Max and Fraser are very interested in this year's election. I guess political awareness starts at the first election after you turn 10, or so. They're both very curious about how mum and dad are voting, and while their mother will not tell (though we all have our suspicions :-) I don't see any reason not to discuss my political leanings with them.I've been what is commonly termed a 'floating' voter for most of my voting life. I imagine the politicians themselves might term people like me 'floaters', with an eye to the scatalogical implications. After all, their livelihoods are on the line!So, after reading this blog post I thought I might as well also share my personal voting plans with the world.

While working on SAT-Britney, I made heavy use of the IntSet data type provided by the basic Haskell library containers . Since memory consumption was a problem, I looked at its implementation, which is a binary tree, and wondered whether this could be improved for dense sets by using a machine sized word as a bit map to represent a continuous part of the integers, so I started to implement it. The effect on my program was not as strong as I had hoped for, but nevertheless, the code made its way back into containers after a thorough review and a considerable amount of further improvements by Milan Straka. I m getting sucked deeper and deeper into the Haskell community... (which means that the Haskell community does not suck, of course.)
Flattr this post

Yesterday evening I updated my server to remove MySQL:

steve:~# dpkg --purge mysql-client-5.1 \
                      mysql-common     \
                      mysql-server-5.1 \
                      mysql-server-core-5.1 \
                      python-mysqldb        \
                      libdbd-mysql-perl     \
                      libdatetime-format-mysql-perl

Until last month I had two database in use, one each for a pair of web-applications. As of now one is using redis - which I'm already using for my image hosting - and the other application is using SQLite. Until recently I had a high opinion of SQLite, although that has now been downgraded a little, it is still a thoroughly excellent piece of software. I was just surprised at little things it was missing, to the extent I had to rewrite my applications SQL. Still one less service is a good thing, and the migration wasn't so painful.. In more productive news I recently acquired a nice external flash - the Yongnuo YN-460 II is (very) cheap and cheerful, it can be fired remotely with my triggers so I've had a lot of fun with opportunistically taking pictures and experimenting with lighting. Most of the results are NSFW, but there are some other examples lurking around including the first time I managed to successfully capture a falling water-drop. (Not the best picture, not the most explicit effect, but fun regardless. I both can and will do better next time!)

Somebody recently asked me to write about "camera stuff under linux" and happily I declined. Why decline? Because there are so many good tools, applications, and utilities. (I use local tools for organisation and duplicate detection, rawtherapee for RAW conversion and GIMP for touchups). Having many available options is fantastic though, and something hard to appreciate for "newcomers" to Linux. (Yeah I waited 90 seconds - if I remembered to add -nojava - for Netscape Navigator to start, under X10, with 8Mb of RAM. Happier days are here. Sure DRM is bad, secure boot .. an open question, but damn we have it good compared to almost any previous point in time!)

ObQuote: "Yeah, obviously it is only a tactical party. I'm only having a party to eventually get sex." - Peep Show

This is both a release announcement for the next installment of The MirBSD Korn Shell, mksh R40b, and a follow-up to Sune s article about small tools of various degrees of usefulness. I hope I don t need to say too much about the first part; mksh(1) is packaged in a gazillion of operating environments (dear Planet readers, that of course includes Debian, which occasionally gets a development snapshot; I ll wait uploading R40c until that two month fixed gcc bug will finally find its way into the packages for armel and armhf. Ah, we re getting Arch Linux (after years) to include mksh now. (Probably because they couldn t stand the teasing that Arch Hurd included it one day after having been told about its existence, wondering why it built without needing patches on Hurd ) MSYS is a supposedly supported target now, people are working on WinAPI and DJGPP in their spare time, and Cygwin and Debian packagers have deprecated pdksh in favour of mksh (thanks!). So, everything looking well on that front. I ve started a collection of shell snippets some time ago, where most of those small things of mine ends up. Even stuff I write at work we re an Open Source company and can generally publish under (currently) AGPLv3 or (if extending existing code) that code s licence. I chose git as SCM in that FusionForge instance so that people would hopefully use it and contribute to it without fear, as it s hosted on my current money source s servers. (Can just clone it.) Feel free to register and ask for membership, to extend it (only if your shell-fu is up to the task, KNOPPIX-style scripts would be a bad style(9) example as the primary goal of the project is to give good examples to people who learn shell coding by looking at other peoples code). Maybe you like my editor, too? At OpenRheinRuhr, the Atari people sure liked it as it uses WordStar like key combinations, standardised across a lot of platforms and vendors (DR DOS Editor, Turbo Pascal, Borland C++ for Windows, ) ObPromise: a posting to raise the level of ferrophility on the Planet aggregators this wlog reaches (got pix)

It s been one year since the first People behind Debian interview. For this special occasion, I wanted a special guest and I m happy that our Debian Project Leader (DPL) Stefano Zacchiroli accepted my invitation. He has a difficult role in the community, but he s doing a really great job of it. He s a great mediator in difficult situations, but he s also opinionated and can push a discussion towards a conclusion. Read on to learn how he became a Debian developer and later DPL, what he s excited about in the next Debian release, and much more. Raphael: Who are you? Stefano: I m Stefano Zacchiroli, but I prefer to be called Zack, both on the Internet and in real life. I m 32, Italian, emigrated to France about 4 years ago. I live in Paris, and I find it to be one of the most gorgeous and exciting cities in the world. As my day job I m a Computer Science researcher and teacher at University Paris Diderot and IRILL. In my copious free time I contribute to Debian, and I m firmly convinced that doing so is an effective way to help the cause of Free Software. Besides, I find it to be a lot of fun! Raphael: How did you start contributing to Debian? Stefano: Flash back to 1999, when I was a 2nd year student in Computer Science at the University of Bologna. Back then in Italy it was uncommon for young geeks to get exposed to Free Software: Internet was way less pervasive than today and most computer magazines didn t pay much attention to GNU/Linux. Luckily for me, the professor in charge of the student lab was a Free Software enthusiast and all students machines there were running Debian. Not only that, but there was also a student program that allowed volunteers to become sysadmins after having shown their skills and convinced the director they were trustworthy. Becoming one of those volunteer Debian admins quickly became one of my top objectives for the year, and that is were I ve learned using Debian. The year after that, I got in touch with a research group that was to become the happy bunch of hackers with whom I would have done both my master and PhD theses. They were designing a new proof assistant. Most of the development was in OCaml and happened on Debian. OCaml was available in Debian, but many of the libraries we needed were not. So I approached the Debian OCaml Team offering to help. Before I realize what was going on I was (co-)maintainer of tens of OCaml-related packages. At some point I got told I think you should apply as a Debian Developer . So I did and in a couple of months I went through the New Member (NM) process, that was back then in its infancy. I still remember my happiness while reading the account created mail, the day after my 22nd birthday. I know the NM process went through some bad publicity in the past, but I m happy to see that nowadays the process can be as swift as it has been for me 10 years ago. Raphael: It s your second year as Debian Project Leader (DPL). Are you feeling more productive in the role? Do you fear to burn out? Stefano: I m feeling way more productive, no doubts. The task of the Debian Project Leader is not necessarily difficult, but it is a complex and scarcely documented one. It is also profoundly different from any other task that Debian people usually work on, so that experience doesn t help much in getting started. Before becoming effective as DPL one needs to get to know many people and mechanisms he is not familiar with. More importantly, one needs to set up a personal work-flow that allows to keep up with day-to-day DPL tasks (which are aplenty) as well as with urgencies (that tend to pop-up in the leader@debian.org INBOX at the least convenient time). Finally, one also needs to do proper traffic shaping and always retain enough motivation bandwidth to keep the Project informed about what is going on in DPL-land. Finding the right balance among all these ingredients can take some time. Once one is past it, everything goes way more smoothly. The above is why I m constantly encouraging people interested in running for DPL in the future to reach out to me and work on some tasks of the current DPL s TODO list. I swear it is not just a cheap attempt at slavery!. It is rather an attempt at DPL mentoring that could be beneficial: both to give future candidates more awareness of the task, and to reduce the potential downtime when handing over from one DPL to the next. Regarding burn out, I don t feel prone to its risk these days. If I look back, I can say that my contributions as DPL have been pretty constant in volume over time; my enthusiasm for the task, if anything, is on the rise. The effectiveness of my contributions as DPL are, on the other hand, not mine to judge. Raphael: If you had to single out two achievements where you were involved as DPL, what would they be? Stefano: I d go for the following two, in no particular order:

• Dialogue with derivatives. When I became DPL ~1.5 years ago the situation on that front was pretty dire. In the specific case of Ubuntu, by far the most successful and customized of all Debian derivatives, I remember being scared of raising the topic of collaboration with them on mailing lists. More generally, we had no specific initiatives to foster technical collaboration with and among derivatives. A huge potential of (forwarded) contributions to Debian was being wasted. Today things look much better, as I ve documented in recent talks at DebConf11 and UDS-P. The amount of forwarded patches we receive from downstream is at its maximum and many people who apply to become Debian Developers come from derivatives. Conflict situations still exist, for good reasons that we still have to either fix or figure out entirely. But I m positive we re on the right track.

  The amount of forwarded patches we receive from downstream is at its maximum

  This is by far not an achievement of mine alone. In particular, many of the activity of the Derivatives Front Desk have been organized by other enthusiastic volunteers. But I ve done my part, especially in breaking the ice and in proposing a vision of Free Software distribution where all distros play a role and are welcome to join the game, as long as they give back and give credit to their respective upstreams.
• Process membership. I m proud of having promoted the general resolution (GR) that has clarified (and advertised to the world) that Debian welcomes all kind of contributions, and that they all equally matter to become proper members of the Project. I notice only now while writing this that the GR title, traditionally chosen by the secretary, was Debian Project Members . That choice harmonically closes the circle with the recent renaming of the NM process to New Member process. Today, we have several project members (AKA Debian Developers ) that are active citizen of Debian with voting rights, even though they take care of tasks other than packaging. Anyone can become a Debian citizen, as long as they are ready to abide by Debian s values, have a track record of verifiable contributions to Debian, and are committed to keep them coming in the future.

  We have several project members that [ ] take care of tasks other than packaging.

  Once gain, this is by far not an achievement of mine alone, very little project-wide achievements are. DAM has helped a lot and support from the project as a whole has been immense.

OK, let me cheat and add a third one I m also proud of having been able to report to the Project my whereabouts as DPL, thoroughly and periodically, since the very beginning is first term. People annoyed by my reporting logorrhea now have all my sympathies. Raphael: Among the possible new features of Debian Wheezy, which one gets you excited most? Stefano: It s multi-arch, no doubt. Even though it is not a directly user visible change, it s a very far reaching one. It is also one of those changes that make me feel that moment of truth of coders, when you realize you are finally doing the right thing and ditching piles of ugly hacks.

It s multi-arch [ ] you realize you are finally doing the right thing and ditching piles of ugly hacks.

Raphael: If you were not DPL and could spend all your time on Debian, what project would you do? Stefano: I would sit down and do software development for Debian. It s impressive how many important and beneficial changes for Debian could be delivered by specific software improvements in various parts of our infrastructure. We tend to attract many packagers, but not so many people willing to maintain Debian infrastructure softwares like dak, britney, debbugs, the PTS, etc. Their maintenance burden then falls on the shoulders of the respective teams which are generally very busy with other important tasks. As a project, we seem to be more appealing to packagers than to software developers. That is a pity given the amount of exciting coding tasks that are everywhere in Debian. Part of the reason we are not appealing to developers is that we are not particularly good at collecting coding tasks in a place where interested developers could easily pick them up. It also takes quite a bit of inside knowledge to spot infrastructure bugs and understand how to fix them. I long for some spare hacking time to check if I m still good enough of a coder to hunt down longstanding bugs in our infrastructure, which have ended up being my pet peeves. I d also love to dive again into RCBW. It s less committing than package maintenance, more diverse and challenging, and also an immensely useful activity to get Debian releases done. Raphael: Martin Michlmayr is worried that there is so few paid opportunities around Debian. Do you agree with his sentiment, and if yes do you have ideas on how to improve this situation? Stefano: The idealistic me wishes Debian to be a community made only of volunteers that devote their free time to the Project. Oh, and that me also wishes Debian to be competitive with similar projects, no matter how many full-time employees others have! That is coherent with a view of society where everyone has a day job, but also engages in volunteering activities ensuring that public interest is pursued by people motivated by interests other than profit. But I do realize that for Free Software to succeed companies, employees, and salaries should all have a role. I admire projects that strike a good balance between volunteer and paid work. The Linux kernel is emblematic in that respect: many developers are paid by companies that have a commercial or strategic interest in Linux. Nevertheless volunteers contributions are aplenty and the Linux community gives a convincing impression that choices are driven by the community itself (or by its benevolent dictator) without money-driven impositions.

I do realize that for Free Software to succeed companies, employees, and salaries should all have a role.

Such an ecosystem does not exist around Debian. We do have a partner program that allows for it to happen, but we have very few partners with an interest in doing distribution development work. Like Martin, I m worried by this state of affairs, because it de facto means we lag behind in terms of available people power. In a community of volunteers, that might frustrate people and that is not good. To improve over the status quo the first step is to federate together small and medium companies that have a strategic interest in Debian and listen to their needs. I m already in touch with representatives of such companies that, in many cases, already employ Debian Developers to do some distribution work in Debian. We will be soon sending out a call to reach out to more such companies, but since we are discussing this, why waiting? If some of our readers here are representative of such companies, I encourage them to get in touch with me about this. Raphael: You know that the fundraising campaign for the Debian Administrator s Handbook is on good track but the liberation of the book is not yet assured. What do you think of this project? Stefano: I m happy about the project, to the point that I ve accepted writing a testimonial for it . I m sad about the scarce availability of up to date and high quality (DFSG-)Free books about Debian and I welcome any initiative that might help closing that gap.

I m sad about the scarce availability of up to date and high quality (DFSG-)Free books about Debian.

Free Culture is a great offspring of Free Software and I m convinced we need to stand up against double standards in the two camps. Letting aside software-specific licensing details, the basic freedoms to be defended are the same. They are those freedoms that ensure that a reader is in full control of his book, pretty much as they ensure that a computer user is in full control of the software that runs on it. I m therefore proud that Debian has long resolved that the Debian Free Software Guidelines (DFSG) apply not only to software but also to books and other pieces of documentation. But the status quo implies that not only we have very few up to date, high quality books about Debian. It also implies that, at present, we have no such book that we can distribute in the Debian archive, showing off the Free Software (and Free Culture!) values we stand for.
Crowdfunding is considered to be a good mate for Free Culture, where the services model that applies to Free Software is more difficult to exploit. I so wish any luck to yours and Roland s initiative. A different matter is whether Debian, as a project, should endorse the initiative and actively campaign for it. As you know, I think it should not. While we do advertise general project donations, we don t do mission-specific fundraising campaign for Debian itself. Coherently with that, I don t think we should relay crowdfunding campaigns for 3rd parties, even when the result would be beneficial to Debian. Raphael: Is there someone in Debian that you admire for their contributions? Stefano: There are two classes of people that I particularly admire in Debian:

• Those with an uncanny ability to guide discussions towards constructive conclusions. We are lucky to have many in Debian and I admire all of them. Having to single out one I d name Russ Allbery, in honor of whom I hereby propose the periodic Russ Allbery s Distinguished Flametamer Award .
• People stepping up for responsibility roles, especially when the responsibility put them in tough spots. Release teams, ftp-masters, DSA, DAM, as well as past and present members of teams with similarly hot seats have all my admiration.

---

Thank you to Zack for the time spent answering my questions. I hope you enjoyed reading his answers as I did.

Subscribe to my newsletter to get my monthly summary of the Debian/Ubuntu news and to not miss further interviews. You can also follow along on Identi.ca, Google+, Twitter and Facebook .

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

A few months ago, Adobe announced a slew of vulnerabilities in its Flash Player, which is a critical component of Adobe AIR:

Adobe recommends users of Adobe AIR 2.6.19140 and earlier versions for Windows, Macintosh and Linux update to Adobe AIR 2.7.0.1948. [...] June 14, 2011 - Bulletin updated with information on Adobe AIR

However, looking at Adobe's instructions for installing AIR on "Linux" systems, we see that it is impossible for people running a free desktop OS to follow Adobe's own recommendations:

Beginning June 14 2011, Adobe AIR is no longer supported for desktop Linux distributions. Users can install and run AIR 2.6 and earlier applications but can't install or update to AIR 2.7. The last version to support desktop Linux distributions is AIR 2.6.

So on the exact same day, Adobe said "we recommend you upgrade, as the version you are using is vulnerable" and "we offer you no way to upgrade". I'm left with the conclusion that Adobe's aggregate corporate message is "users of desktops based on free software should immediately uninstall AIR and stop using it". If Adobe's software was free, and they had a community around it, they could turn over support to the community if they found it too burdensome. Instead, once again, users of proprietary tools on free systems get screwed by the proprietary vendor. And they wonder why we tend to be less likely to install their tools? Application developers should avoid targeting AIR as a platform if they want to reach everyone.Tags: adobe, proprietary software, security

This announcement was provided by Martin Erik Werner. I m reproducing it for Planet Ubuntu. The Debian/Ubuntu Games Team is organizing another meeting. If you re into developing and/or packaging of games, or just generally curious about games in Debian/Ubuntu, you should join! It will be held next Saturday, the 26th of November, in the #debian-games channel on irc.debian.org (also know as irc.oftc.net) at 10:00 UTC. More information is available on the wiki page Games/Meetings/2011-11-26. The agenda starts off with the usual round of introductions, so if you re new to the Team, say hi! Then we ll be going through the action items from the last meeting, including work on the Debian Games LiveCD, and what s up with the /usr/games/ path anyways? Next we ll be moving onto how the Games Team is faring in terms of members: are new recruits finding it comfortable, should we advertise more? Next up it s the squeeky penguin: Wheezy is somewhere in the not-completely-distant future, how does that affect the Games Team, should we be scuffling to get specific tasks done? Then onto the recurring question of Sponsoring, and how to improve it, should we be utilising DebExpo more? What about our favourite PET? Lastly, PlayDeb is doing some really neat stuff, would it make sense for our team to push some changes to PlayDeb? Would it make sense for PlayDeb to push changes to Debian Games? Hopes are for a good discussion, and a merry time, hope to see you all there! Related posts:

1. Debious A dubious Debian packaging GUI
2. One week with Debian
3. A list of some commercial GNU/Linux games

---

No comments
Siegfried-Angel Gevatter Pujals, 2011. Permalink License Post tags: Debian, games, packaging

Many of us out there writes small tools to just solve a simple task that you need. Here, I will present a tool I needed last night. I have a small job doing a wordpress site for some people, and I needed a image with the site title in a font matching some specific criteria (like a double story lowercase A and a small serif on lowercase L, while in general being a Sans Serif type). So what I needed was a application that let me write a word or a phrase, and see it written with all available fonts on the system. So, it took a little more than a effective hour and 120 lines of code to come up with this: Click to see image And if anyone cares, I have pushed the sources to git.kde.org. I m sure many of you also have various such small apps. Let s see them. That s also you Eike and your svgtoy app :) Another thing I learned from this app is that the ukij fonts targetted the Uyghyr language actually is very interesting also for western europeans.

Coming soon after the upstream procps 3.3.0 being released, the debian packages have been uploaded tonight. The Debian packages have had the added benefit of being a day late by having a tiny 2 line patch to stop pgrep from crashing. One regression that is on purpose, watch is currently not 8-bit clean again until I can sort out how to get the linking right with the new build process. Testing Systems The embarrassing problem with pgrep did start a discussion about testing, especially regression testing. I ve recently started using unit testing in my python programs and love the level of assurance those tests give me that I haven t broken anything (to a degree anyhow). I d really like to be able to type make test and have each of the programs run through a series of tests. The problem with packages like procps (psmisc too) is that you really need to test the entire program, not just a stub, and that the program needs access to a know level of /proc. The only thing I have seen that is even remotely what is needed is the bunch of scripts that coreutils uses which creates dummy files and directories to operate the commands on. I expect we could do something similar with some scripts that create a known process but if anyone has a better idea about how to test a command line program let me know.

At work we have heaps of servers. I believe the total count is around 1000 at the moment. To be able to get help from the vendors when something go wrong, we want to keep the firmware on the servers up to date. If the firmware isn't the latest and greatest, the vendors typically refuse to start debugging any problems until the firmware is upgraded. So before every reboot, we want to upgrade the firmware, and we would really like everyone handling servers at the university to do this themselves when they plan to reboot a machine. For that to happen we at the unix server admin group need to provide the tools to do so. To make firmware upgrading easier, I am working on a script to fetch and install the latest firmware for the servers we got. Most of our hardware are from Dell and HP, so I have focused on these servers so far. This blog post is about the Dell part. On the Dell FTP site I was lucky enough to find an XML file with firmware information for all 11th generation servers, listing which firmware should be used on a given model and where on the FTP site I can find it. Using a simple perl XML parser I can then download the shell scripts Dell provides to do firmware upgrades from within Linux and reboot when all the firmware is primed and ready to be activated on the first reboot. This is the Dell related fragment of the perl code I am working on. Are there anyone working on similar tools for firmware upgrading all servers at a site? Please get in touch and lets share resources.

#!/usr/bin/perl
use strict;
use warnings;
use File::Temp qw(tempdir);
BEGIN  
    # Install needed RHEL packages if missing
    my %rhelmodules = (
        'XML::Simple' => 'perl-XML-Simple',
        );
    for my $module (keys %rhelmodules)  
        eval "use $module;";
        if ($@)  
            my $pkg = $rhelmodules $module ;
            system("yum install -y $pkg");
            eval "use $module;";
         
     
 
my $errorsto = 'pere@hungry.com';
upgrade_dell();
exit 0;
sub run_firmware_script  
    my ($opts, $script) = @_;
    unless ($script)  
        print STDERR "fail: missing script name\n";
        exit 1
     
    print STDERR "Running $script\n\n";
    if (0 == system("sh $script $opts"))   # FIXME correct exit code handling
        print STDERR "success: firmware script ran succcessfully\n";
      else  
        print STDERR "fail: firmware script returned error\n";
     
 
sub run_firmware_scripts  
    my ($opts, @dirs) = @_;
    # Run firmware packages
    for my $dir (@dirs)  
        print STDERR "info: Running scripts in $dir\n";
        opendir(my $dh, $dir) or die "Unable to open directory $dir: $!";
        while (my $s = readdir $dh)  
            next if $s =~ m/^\.\.?/;
            run_firmware_script($opts, "$dir/$s");
         
        closedir $dh;
     
 
sub download  
    my $url = shift;
    print STDERR "info: Downloading $url\n";
    system("wget --quiet \"$url\"");
 
sub upgrade_dell  
    my @dirs;
    my $product =  dmidecode -s system-product-name ;
    chomp $product;
    if ($product =~ m/PowerEdge/)  
        # on RHEL, these pacakges are needed by the firwmare upgrade scripts
        system('yum install -y compat-libstdc++-33.i686 libstdc++.i686 libxml2.i686 procmail');
        my $tmpdir = tempdir(
            CLEANUP => 1
            );
        chdir($tmpdir);
        fetch_dell_fw('catalog/Catalog.xml.gz');
        system('gunzip Catalog.xml.gz');
        my @paths = fetch_dell_fw_list('Catalog.xml');
        # -q is quiet, disabling interactivity and reducing console output
        my $fwopts = "-q";
        if (@paths)  
            for my $url (@paths)  
                fetch_dell_fw($url);
             
            run_firmware_scripts($fwopts, $tmpdir);
          else  
            print STDERR "error: Unsupported Dell model '$product'.\n";
            print STDERR "error: Please report to $errorsto.\n";
         
        chdir('/');
      else  
        print STDERR "error: Unsupported Dell model '$product'.\n";
        print STDERR "error: Please report to $errorsto.\n";
     
 
sub fetch_dell_fw  
    my $path = shift;
    my $url = "ftp://ftp.us.dell.com/$path";
    download($url);
 
# Using ftp://ftp.us.dell.com/catalog/Catalog.xml.gz, figure out which
# firmware packages to download from Dell.  Only work for Linux
# machines and 11th generation Dell servers.
sub fetch_dell_fw_list  
    my $filename = shift;
    my $product =  dmidecode -s system-product-name ;
    chomp $product;
    my ($mybrand, $mymodel) = split(/\s+/, $product);
    print STDERR "Finding firmware bundles for $mybrand $mymodel\n";
    my $xml = XMLin($filename);
    my @paths;
    for my $bundle (@ $xml-> SoftwareBundle )  
        my $brand = $bundle-> TargetSystems -> Brand -> Display -> content ;
        my $model = $bundle-> TargetSystems -> Brand -> Model -> Display -> content ;
        my $oscode;
        if ("ARRAY" eq ref $bundle-> TargetOSes -> OperatingSystem )  
            $oscode = $bundle-> TargetOSes -> OperatingSystem [0]-> osCode ;
          else  
            $oscode = $bundle-> TargetOSes -> OperatingSystem -> osCode ;
         
        if ($mybrand eq $brand && $mymodel eq $model && "LIN" eq $oscode)
         
            @paths = map   $_-> path    @ $bundle-> Contents -> Package ;
         
     
    for my $component (@ $xml-> SoftwareComponent )  
        my $componenttype = $component-> ComponentType -> value ;
        # Drop application packages, only firmware and BIOS
        next if 'APAC' eq $componenttype;
        my $cpath = $component-> path ;
        for my $path (@paths)  
            if ($cpath =~ m%/$path$%)  
                push(@paths, $cpath);
             
         
     
    return @paths;
 

The code is only tested on RedHat Enterprise Linux, but I suspect it could work on other platforms with some tweaking. Anyone know a index like Catalog.xml is available from HP for HP servers? At the moment I maintain a similar list manually and it is quickly getting outdated.

I want to blog frequently but usually don't seem to find the time for it. I'm not above tying myself to the mast if it means blogging more. Iron Blogger is a blogging and drinking club based on this premise. The rules are pretty simple:

• Blog at least once a week.
• If you fail to do so, pay $5 into a common pool.
• When the pool is big enough, the group uses it to pay for drinks and snacks at a meet-up for all the participants.

Nelson Elhage ran the original Iron Blogger for about a year before the effort ran out of steam. I've started a new instance with a couple people from the previous group and a bunch of folks from Berkman, MIT, and beyond. If you live in Boston and want to join, there are still a couple of spots available. I'm going to cap the current group, at least temporarily, at about 30 people because I think that's the maximum we'll fit into a local pub. Look over the site and send me an email if you're interested. If you don't live in Boston but want to organize your own Iron Blogger, you can use the software in Nelson's git repository (or my branch) to automate nearly the whole process of tracking posts, generating reports, and updating the ledger of debts.

The Debian/Ubuntu games team is organizing another meeting, if you're into developing and/or packaging of games, or just generally curious about games in Debian/Ubuntu, you should join! It will be held next Saturday, on the 26th of November, in the #debian-games channel on irc.debian.org (also know as irc.oftc.net). More information is available on the meeting wiki page. The agenda starts off with the usual round of introductions, so if you're new to the team, say hi! Then we'll be going through the action items from the last meeting, including work on the Debian Games LiveCD, and what's up with the /usr/games/ path anyways? Next we'll be moving onto how the games team is faring in terms of members: are new recruits finding it comfortable, should we advertise more? Next up it's the squeeky penguin: Wheezy is somewhere in the not-completely-distant future, how does that affect the games team, should we be scuffling to get specific tasks done? Then onto the recurring question of sponsoring, and how to improve it, should we be utilising DebExpo more? What about our favourite PET? Lastly, PlayDeb is doing some really neat stuff, would it make sense for our team to push some changes to PlayDeb? Would it make sense for PlayDeb to push changes to Debian Games? Hopes are for a good discussion, and a merry time, hope to see you all there! (This text provided by Martin Erik Werner)

Hello Most SDL packages are outdated, people are complaining in the BTS, and the team is mostly inactive. That s bad news for my project. What can I do ? Well, it s Debian project, I just have to step up. Thanks to Sam Hocevar, I m now admin on Debian Alioth SDL packaging project. I d like to revive the team. (Note that I don t have the bandwidth to be the team all by myself). Here are the first steps I plan (mostly inspired by the way Debian-perl team is working):

• create a SDL-team page on debian wiki (done)
• setup a SDL packaging git repo so that team members can collaborate more easily on packaging (on-going)
• call for volunteers to help. (this message is the first step)
• review and upload packages from team members

Now, there are some ground rules I wish to push forward:

• any team member can work on any package maintained by the team.
• just tell us on this list about any work you are doing (to avoid duplication)
• send a mail on this list if you need a package to be reviewed for upload.
• you can use SDL subversion repository to work on a package
• you can also use SDL git repo to work on a package (please discuss with us for the migration steps)
• once a package is migrated to git, it cannot go back to subversion.

If you don t agree with the above points, now is the time to say it. Feel free to join by:

1. Creating an account on Alioth
2. request to join sdl-team
3. Last but not least, send a short introduction mail to pkg-sdl-maintainers AT lists.alioth.debian.org so we can know each other.

See you soon

Yesterday I wrote about an alleged attack on the Windows 8 secure boot implementation. As I later clarified, it turns out that the story was, to put it charitably, entirely wrong. The attack is a boot kit targeted towards BIOS-based boots. It lives in the MBR. It'll never be executed on any UEFI systems, let alone secure boot ones. In fact, this is precisely the kind of attack that secure boot is intended to protect against. So, context.

The MBR contains code that's executed by the BIOS at boot time. This code is unverifiable - it's permitted to have arbitrary functionality. There's only 440 bytes, but that's enough to jump to somewhere else and read code from elsewhere. There's no way for the BIOS to know that this code is malicious. And one thing this code can obviously do is load the normal boot code and modify it to behave differently. Any self-validation code in the loader can be patched out at this point. The modified loader will then load the kernel, and potentially also modify it. At this point, you've lost. Any attempts to validate the code can be redirected to the original code and so everything will look fine, up until the point where the user runs a specific application and suddenly your kernel is sending all your keystrokes over UDP to someone in Nigeria.

These attacks exist now. They're in the wild. In a normal UEFI world you'd do the same thing by just replacing the UEFI bootloader. But with secure boot you'll be able to validate that the bootloader is appropriately signed and if someone's modified it you'll drop into some remediation mode that recovers your files, from install media if necessary.

Obviously, this protection is based on all the components of secure boot (ie, everything that runs before ExitBootServices() is called) being perfect. As I said, if any of them accept untrusted input and misinterpret it in such a way that they can be tricked into running arbitrary code, you'll still have problems. But when discussing the pros and cons of secure boot, it's important to make sure that we're talking about reality rather than making provably false assertions.

comments

Censoring the Frozen Planet The Guardian reports on Discovery's decision not to screen the climate change episode in the US is an injustice to the startling beauty on show during the series. #censorship, #climatechange

Starting with Fedora 16 we're installing using GPT disklabels by default, even on BIOS-based systems. This is worth noting because most BIOSes have absolutely no idea what GPT is, which you'd think would create some problems. And, unsurprisingly, it does. Shock. But let's have an overview.

GPT, or GUID Partition Table, is part of the UEFI specification. It defines a partition table format that allows up to 128 partitions per disk, with 64 bit start and end values allowing partitions up to 9.4ZB (assuming 512 byte blocks). This is great, because the existing MBR partitioning format only allows up to 2.2TB when using 512 byte blocks. But most BIOSes (and most older operating systems) don't understand GPT, so plugging in a GPT-partitioned disk would result in the system believing that the drive was uninitialised. This is avoided by specifying a protective MBR. This is a valid MBR partition table with a single partition covering the entire disk (or the first 2.2TB of the disk if it's larger than that) and the partition type set to 0xee ("GPT Protective"). GPT-unaware BIOSes and operating systems will see a partition they don't understand and simply ignore it.

But how do we boot a GPT-labelled disk with a protective MBR on a system that doesn't understand GPT? The key here is that BIOS is pretty dumb. Typically a BIOS will see a disk and just attempt to execute the code in the first sector. This MBR code knows how to do the rest of the boot, including parsing the partition table if necessary. The BIOS doesn't need to care at all.

Of course, some BIOSes choose to care. We've seen a small number of machines that, when exposed to a GPT disk, refuse to boot because they parse the MBR partition map and don't like what they see. This is typically accompanied by a message along the lines of "No operating system found". What we've found is that they're looking for a partition marked with the bootable flag, and if no partitions are marked bootable they assume that there's no OS. This is in contrast to the traditional use of the flag, which is merely a hint to the MBR as to which partition boot code it should execute.

So, should we set that flag? The UEFI specification specifically forbids it - table 15 states that the BootIndicator byte must be set to 0. Once again we're left in an unfortunate position where the specification and reality collide in an awkward way.

If this happens to you after a Fedora 16 install, you have two choices. The first is to reinstall with the "nogpt" boot argument. The installer will then set up a traditional MBR partition table. The second is to boot off a live CD and run fdisk against the boot disk. It'll give a bunch of scary warnings. Ignore them. Hit "a", then "1", then "w" to write it to disk. Things ought to work then. We'll figure out something better for F17.

comments