In my spare time, I currently work on a Norwegian docbook version of the 2004 book Free Culture by Lawrence Lessig, to get a Norwegian text explaining the problems with the copyright law I can give to my parents and others that are reluctant to read an English book. It is a marvellous set of examples on how the ever expanding copyright regulations hurt culture and society. When the translation is done, I hope to find funding to print and ship a copy to all the members of the Norwegian parliament, before they sit down to debate the latest revisions to the Norwegian copyright law. This summer I called for volunteers to help me, and I have been able to secure the valuable contribution from at least one other Norwegian. Two days ago, we finally broke the 50% mark. Then more than 50% of the number of strings to translate (normally paragraphs, but also titles and index entries are also counted). All parts from the beginning up to and including chapter four is translated. So is chapters six, seven and the conclusion. I created a graph to show the progress: The number of strings to translate increase as I insert the index entries into the docbook. They were missing with the docbook version I initially started with. There are still quite a few index entries missing, but everyone starting with A, B, O, Z and Y are done. I currently focus on completing the index entries, to get a complete english version of the docbook source. There is still need for translators and people with docbook knowledge, to be able to get a good looking book (I still struggle with dblatex, xmlto and docbook-xsl) as well as to do the draft translation and proof reading. And I would like the figures to be redrawn as SVGs to make it easy to translate them. Any SVG master around? I am sure there are some legal terms that are unfamiliar to me. If you want to help, please get in touch, and check out the project files currently available from github. If you are curious what the translated book currently look like, the updated PDF and EPUB are published on github. The HTML version is published as well, but github hand it out with MIME type text/plain, confusing browsers, so I saw no point in linking to that version.

A few days ago, I blogged about visualizing CRAN dependency ranks which turned out to be a somewhat popular post. David Smith followed-up at the REvo blog suggesting to exclude packages already shipping with R (which is indicated by their 'Recommended' priority). Good idea! So here is an updated version, where we limit the display to the top twenty packages counted by reverse 'Depends:', and excluding those already shipping with R such as MASS, lattice, survival, Matrix, or nlme. The mvtnorm package is still out by a wide margin, but we can note that (cough, cough) our Rcpp package for seamless R and C++ is now tied for second with the coda package for MCMC analysis. Also of note is the fact that CRAN keeps growing relentlessly and moved from 3969 packages to 3981 packages in the space of these few days... Lastly, I have been asked about the code and/or data behind this. It is really pretty simply as the main data.frame can be had from CRAN (where I also found the initial few lines to load it). After that, one only needs a little bit of subsetting as shown below. I look forward to seeing other people riff on this data set.

#!/usr/bin/r
##
## Initial db downloand from http://developer.r-project.org/CRAN/Scripts/depends.R and adapted
require("tools")
## this function is essentially the same as R Core's from the URL
## http://developer.r-project.org/CRAN/Scripts/depends.R
getDB <- function()  
    contrib.url(getOption("repos")["CRAN"], "source") # trigger chooseCRANmirror() if required
    description <- sprintf("%s/web/packages/packages.rds", getOption("repos")["CRAN"])
    con <- if(substring(description, 1L, 7L) == "file://")  
        file(description, "rb")
      else  
        url(description, "rb")
     
    on.exit(close(con))
    db <- readRDS(gzcon(con))
    rownames(db) <- db[,"Package"]
    db
 
db <- getDB()
## count packages
getCounts <- function(db, col)  
    foo <- sapply(db[,col],
                  function(s)   if (is.na(s)) NA else length(strsplit(s, ",")[[1]])   )
 
## build a data.frame with the number of entries for reverse depends, reverse imports,
## reverse linkingto and reverse suggests; also keep Recommended status
ddall <- data.frame(pkg=db[,1],
                    RDepends=getCounts(db, "Reverse depends"),
                    RImports=getCounts(db, "Reverse imports"),
                    RLinkingTo=getCounts(db, "Reverse linking to"),
                    RSuggests=getCounts(db, "Reverse suggests"),
                    Recommended=db[,"Priority"]=="recommended"
                    )
## Subset to non-Recommended packages as in David Smith's follow-up post
dd <- subset(ddall, is.na(ddall[,"Recommended"])   ddall[,"Recommended"] != TRUE)
labeltxt <- paste("Analysis as of", format(Sys.Date(), "%d %b %Y"),
                  "covering", nrow(db), "total CRAN packages")
cutOff <- 20
doPNG <- TRUE
if (doPNG) png("/tmp/CRAN_ReverseDepends.png", width=600, heigh=600)
z <- dd[head(order(dd[,2], decreasing=TRUE), cutOff),c(1,2)]
dotchart(z[,2], labels=z[,1], cex=1, pch=19,
         main="CRAN Packages sorted by Reverse Depends:",
         sub=paste("Limited to top", cutOff, "packages, excluding 'Recommended' ones shipped with R"),
         xlab=labeltxt)
if (doPNG) dev.off()
if (doPNG) png("/tmp/CRAN_ReverseImports.png", width=600, heigh=600)
z <- dd[head(order(dd[,3], decreasing=TRUE), cutOff),c(1,3)]
dotchart(z[,2], labels=z[,1], cex=1, pch=19,
         main="CRAN Packages sorted by Reverse Imports:",
         sub=paste("Limited to top", cutOff, "packages, excluding 'Recommended' ones shipped with R"),
         xlab=labeltxt)
if (doPNG) dev.off()
# no cutOff but rather a na.omit
if (doPNG) png("/tmp/CRAN_ReverseLinkingTo.png", width=600, heigh=600)
z <- na.omit(dd[head(order(dd[,4], decreasing=TRUE), 30),c(1,4)])
dotchart(z[,2], labels=z[,1], pch=19,
         main="CRAN Packages sorted by Reverse LinkingTo:",
         xlab=labeltxt)
if (doPNG) dev.off()

At the beginning of this year, I blogged about a Mexican security-minded hacker conference scaring away its female audience by advertising in a sexist way. I don't know if it is the need to be l33t or kewl, to show off that hackers are really socially inept, or what... but this seems to carry on. I know many are familiar with the red/yellow card project (and followup) by kdotcdot. I am (rightfully? naively?) proud that at DebConf we have achieved a clean conference environment, without such problems... Yes, I know that, during the last ~year at DebConf11 we discussed an anti-harassment policy (look at the thread, it was quite interesting!), came up with standards of respect And Debian as a whole voted on a GR that ratifies a diversity statement. The fact that we had those very positive discussions, documents and events shows we needed to have them. But, again, this shows that being a hacker does not necessarily mean being a jerk. And I'm very proud to be part of this community. I recently stumbled across a very nice, insightful post by Valerie Aurora on The Ada Initiative: Supporting women in open technology and culture DEFCON: Why conference harassment matters. Take a good read at it. I hope it helps shape other hacker groups in a less-aggressive, more welcoming way. Oh! And before closing: Be sure to at least skim through both Valerie Aurora's and kdotcdot's comments. LOTS of insight in them.

I ve been meaning to post this picture for a while. A few months ago I was at a local pottery/ceramics shop with my family. They were all decorating things and either my wife or one of my children suggested I do one too. Art it not my thing. I thought about it and finally an idea I ll make a Debian coffee mug. I used the browser on my phone to go to debian.org and then I blew the logo up to the full size of the screen and traced it onto paper. I used that as a template to paint it onto the largest coffee mug I could find. Here s the result. I hope you enjoy the picture (note the actual coffee stain for authenticity).

After some rants about the status of different Qt-based serial port libs, I'm happy to announce that today QExtSerialPort was accepted in Debian experimental (this last link may give a 404 for some time, that's ok).

A great effort was done upstream to put the source in a suitable state for being included in Debian. Thank you all guys!

I packaged a beta version, so I uploaded it to experimental.

In case you are wondering why packaging a lib with (yet) no apps depending on it, the answer is quite simple: there are lots of people already using it in it's home projects (me included). Now those projects have the chance to get into Debian too :-)

As a side note, there is also another nice implementation called QtSerialPort. I have also tested it and works pretty fine too. It aims to become part of Qt as an add-on someday.

You can use a PBO solver to clean up your system from unneeded automatically installed packages. First of all, you convert the system state to PB, and add an optimization function telling it to remove as many automatically installed packages as possible. Then you run this thing through a solver (such as clasp, which seems the fastest solver for PBO instances in the Debian archive) and convert its output to human-readable package names. Code is provided at http://anonscm.debian.org/gitweb/?p=users/jak/cleanup.git, under the MPL 2.0. You need to have python-apt and clasp installed to use it. There is potential minisat+ support, but it s currently a bit broken. To use, run python program_builder.py, and it will tell you which packages are no longer needed on your system. It ignores Suggests, if you want those in, you have to hack the code and replace Recommends by Recommends , Suggests . You can also turn of such dependencies by setting Program.hard_softdeps to False.
Filed under: APT2, Debian, Python

There's been a few links to this story of someone buying a system that turned out to have UEFI firmware and also turned out not to boot. Given all the press, it's unsurprising that people would assume that problems they have with UEFI booting are related to Secure Boot, but it's very unlikely that this is the actual problem here. First, nobody's shipping an appropriately signed operating system yet. A hardware vendor that enabled secure boot out of the box would be selling a machine that wouldn't boot any OS you could buy. That's a poor way to make money. Second, the system booted a Fedora 17 CD. Fedora 17 isn't signed, so if the firmware booted it then the firmware isn't enforcing Secure Boot. Third, it didn't boot the installed OS. That's really at the point of it sounding like a hardware problem - selling systems that don't run the OS you sold them with is a guaranteed way of getting enough support calls that you wouldn't make any money on them, ever.

To be fair, Linux compatibility with UEFI systems is still not as good as it is with BIOS systems. Fedora 18 will be using a new UEFI boot process and so far in our testing it's been significantly more reliable than Fedora 17. There's still some remaining issues that we're aware of and working on, but right now it's hugely more likely that failures to boot Fedora 17 on UEFI systems are down to our bugs rather than Secure Boot.

comments

Happy 19th birthday, Debian! The Debian project is 19 years old now. Following Francesca's invitation (and Rapha l's lead, and using Leandro's image, collaboratively as it always happens here), I will tell a bit of my memories: How I got to Debian. I am a Debian user since ~2000, and a Debian Developer since April 2003. But, just as Rapha l's, my history must go somewhat further back in time. In 1992, I got my first 1200bps modem, and almost immediately became an avid BBS user (what's that? Javier Matuk talks [in Spanish] about BBSes in his newspaper column back in 1994). By mid 1993 I started operating my own BBS, CatarSYS. One of the key points that defined CatarSYS is that my focus was large-scale communication. I started connecting to several BBS networks, allowing messages to be relayed to distant people, mainly in the USA and Spain, and getting some feeds that could be seen as the poor man's Usenet. At some point during the year I kept CatarSYS going, I got connected through a strange set of gateways to pure gold: A UUCP feed! This means, during some months, I operated the first (free, hobbyist) service that offered its users a free Internet mail address in Mexico. Yes, it was completely different to what we are used to today. I tried to connect to my provider at least three times a week, but this meant less than one week turnover time for messages sent to people anywhere in the world! But, back to Debian: Via this UUCP feed, I also got some real Usenet newsgroups Including several on the comp.os category. I remember reading about Linux back then, and learning some commands, but didn't really get hooked into it. I was in Israel from July 1994 to June 1995, doing completely non-computer-related tasks. Came back in 1995, and due to my father being an academic, got dialup internet access at home. WOW, *real* Internet! It didn't take me long to start downloading Linux information and floppy images. One failed after another. But before the end of the year, I found in a bookshop a book (that included a CD-ROM) called "Build your own web server with Linux". WOW again Remember this was still 1995! I bought it, and shortly afterwards, I had a Slackware system (Linux kernel 1.0.9) running. That meant many sleepless nights full of joy and frustration (as getting hardware to work was cloe to impossible). By 1996, I got (within one week) my two first real jobs: A systems administrator at a small ISP and a highschool teacher. At the ISP, I got a spare computer to play with Linux, as of course the Big Server was running with Windows NT 3.51. Poor little machine... By then I was already a part of the Mexican Linux User Group. This group had just printed a batch of Linux CDs RedHat 4.0. This was the first release that really made me happy and allowed me to do good work. Together with a friend I took to work with us, Juan Pablo Romero, we installed over a weekend a full replacement for our buggy NT machine, in much cheaper hardware. Of course, Linux was nowhere near corporate-recognition, and our project remained a project, not touching the Windows machine. Anyway... Several years passed, and I was happy with my RedHat choice. I won't mention the milestones and job changes, as it would get boring and leave the point completely aside. By the year 2000, I was quite more involved with the LUG, as well as with the computer security group in DGSCA-UNAM. I became also an OpenBSD user, and had got so hooked up in free software that I felt the need to collaborate: To be a little part of one of those Big Projects that had given me so much. But which one? I have never been much of a programmer Yes, I can solve my everyday needs and have fun with it, and sometimes a bit beyond that. I enjoy programming. But all of my projects have begun little and stayed little. I wanted to join OpenBSD, as it was a community I really believed in, but given my skillset (and given a flame-prone, aggressive developer community), I lost motivation to do so. By 2000, I had also lost faith in RedHat. I don't have the exact dates, so I might be some months off But after RedHat's IPO, I felt a sharp change. Version 7.0 was really demotivating It tried to offer a polished desktop experience, but was really buggy, unstable, and full of bad decisions. In Mexico, Pepe Neif had taken up the job of making a derivative distribution of RedHat (called LinuxPPP), pressing hundreds of CDs and making a teaching program I was part of several times. Talking with Pepe (who continued to release based on RedHat 6), he told me he was interested in switching over to become a Debian-based distribution, but the job of migrating his installed base made the project stall LinuxPPP reached only version 6.4. But I installed Debian in early 2000, and loved it. I started getting familiar with its social philosophy and foundation documents at the same time I started migrating my servers from RedHat to Debian This must have been by Spring 2000, as I installed Potato while it was frozen but not yet stable. By January 2002 I applied for NM. My process took a long time, as my AM got MIA when he had already approved me (but before sending the AM report), so basically I had to go through AM twice And by April 16, 2003, I got accepted as a DD. Contrary to what is acceptable today, I requested the full process to be done before starting to maintain any packages, as I didn't want to bother people with package sponsorship requests, so my whole process was done evaluating packages I would eventually upload. Since becoming a DD, my main involvement in the project has been in packaging groups (I was a pkg-perl founder and member for many years, and am currently working in the pkg-ruby-extras group). But, as I said, my main strength is not programming So my main involvement in Debian has been more social than technical: I have been a DebConf organizer since 2005, a very interesting, stressing, rewarding and (for some months) time-demanding role, and since 2009 I am part of the keyring maintainence team, which is much easier workload, although carries important ramifications. So, after 19 years of Debian, and after nine years of me being part of it, Debian is clearly my strongest link to the Free Software community, a project I have grown to love and whose way of being I share and enjoy studying and explaining. And it is a technically excellent product, and a great place to start and keep learning both about how every aspect and layer of an operating system works, and how human-to-human interaction works in such a diverse, almost impossible environment happens. Congratulations, Debian!

Attachment	Size
debian-19_500.png	149.81 KB

The biggest objection that most people have to UEFI Secure Boot as embodied in the Windows 8 certification requirements is the position of Microsoft as the root of trust. But we can go further than that - putting any third party in a position of trust means that there's the risk that your machine will end up trusting code that you don't want it to trust. Can we avoid that?

It turns out that the answer is yes, although perhaps a little more complicated than ideal. The Windows 8 certification requirements insist that (on x86, at least) the key databases be completely modifiable. That means you can delete all the keys provided by your manufacturer, including Microsoft's. However, as far as the spec is concerned, a system without keys is in what's called "Setup Mode", and in this state it'll boot anything - even if it doesn't have a signature.

So, we need to populate the key database. This isn't terribly difficult. James Bottomley has a suite of tools here, including support for generating keys and building an EFI binary that will enrol them into the key databases. So, now you have a bunch of keys and the public half of them is in your platform firmware. What next?

If you've got a system with plug-in graphics hardware, what happens next is that your system no longer has any graphics. The firmware-level drivers for any plug-in hardware also need to be signed, and won't run otherwise. That means no graphics in the firmware. If you're netbooting off a plug-in network card, or booting off a plug-in storage controller, you're going to have similar problems. This is the most awkward part of the entire process. The drivers are all signed with a Microsoft key, so you can't just enrol that without trusting everything else Microsoft have signed. There is a way around this, though. The typical way to use Secure Boot is to provide a list of trusted keys, but you can also provide trusted hashes. Doing this involves reading the device ROM, generating a SHA256 hash of it and then putting that hash in the key database.

This is, obviously, not very practical to do by hand. We intend to provide support for this in Fedora by providing a tool that gets run while the system is in setup mode, reads the ROMs, hashes them and enrols the hashes. We'll probably integrate that into the general key installation tool to make it a one-step procedure. The only remaining problem is that swapping your hardware or updating the firmware will take it back to a broken state, and sadly there's no good answer for that at the moment.

Once you've got a full set of enrolled keys and the hashes of any option ROMs, the only thing to do is to sign your bootloader and kernel. Peter Jones has written a tool to do that, and it's available here. It uses nss and so has support for using any signing hardware that nss supports, which means you can put your private key on a smartcard and sign things using that.

At that point, assuming your machine implements the spec properly everything that it boots will be code that you've explicitly trusted. But how do you know that your firmware is following the spec and hasn't been backdoored? That's tricky. There's a complete open implementation of UEFI here, but it doesn't include the platform setup code that you'd need to run it on any x86 hardware. In theory it'd be possible to run it on top of Coreboot, but right now that's not implemented. There is a complete port to the Beagleboard hardware, and there's instructions for using it here. The remaining issue is that you need a mechanism for securing access to the system flash, since if you can make arbitrary writes to it an attacker can just modify the key store. On x86 this is managed by the flash controller being switched into a mode where all writes have to be carried out from System Management Mode, and the code that runs there verifies that writes are correctly authenticated. I've no idea how you'd implement that on ARM.

There's still some work to be done in order to permit users to verify the entire stack, but Secure Boot does make it possible for the user to have much greater control over what their system runs. The freedom to make decisions about not only what your computer will run but also what it won't is an important one, and we're doing what we can to make sure that users have that freedom.

comments

We were nearly 20 people from the Shanghai Linux User Group this evening, at JA cafe (near JinAn temple), celebrating Debian s 19th birthday. As the only DD present at that event (Li Daobing was busy somewhere else), I was honored by my friends to be the one cutting the cake. Above the (very nice) cake before sharing it, below, a few SHLUG members present that evening.

For Debian s birthday, Francesca Ciceri of the Debian Publicity team suggested that developers blog about their first experiences with Debian . I found this a good idea so I m going to share my own early experience. It s quite different from what happens nowadays Before speaking of my early Debian experience, I have to set some context. In my youth, I have always been a Windows user and a fan of Bill Gates. That is until I got Internet at home at that point, I got involved in Usenet and made some friends there. One of those made me discover Perl and it has been somewhat of a revelation for me who had only been programming in Visual Basic, Delphi or ObjectPal. Later the same friend explained me that Perl was working much better on Linux and that Debian Linux installs it by default so I should try this one. I had no idea of what Linux was, but given how I loved Perl, I was eager to try his advice. So I got myself a Tri-Linux CD with Debian/RedHat/Slackware on it and started the installation process (which involved preparing boot floppies). But I did not manage to get the graphical interface working despite lots of fiddling with Xfree86 s configuration file. So I ended up installing RedHat and used it for a few months. But since many of the smart guys in my Usenet community were Debian users, I persisted and finally managed to get it to work! After a few months of usage, I was amazed at everything that was available for free and I wanted to give back. I filed my first bug report in July 1998, I created my first Debian packages in August 1998 and I got accepted as an official Debian developer in September 1998 (after a quick chat over the phone with Martin Schulze or James Troup I never understood the name of my interlocutor on the phone and I was so embarassed to have to use my rusty English over the phone that I never asked). That s right, it took me less than 3 months to become a Debian developer (I was 19 years old back then). I learned a lot during those months by reading and interacting with other Debian developers. Many of those went away from Debian in the mean time but some of them are still involved (Joey Hess, Manoj Srivastava, Ian Jackson, Martin Schulze, Steve McIntyre, Bdale Garbee, Adam Heath, John Goerzen, Marco D Itri, Phil Hands, Lars Wirzenius, Santiago Vila, Matthias Klose, Dan Jacobowitz, Michael Meskes, ). My initial Debian work was centered around Perl: I adopted dpkg-ftp (the FTP method for dselect) because it was written in Perl and had lots of outstanding bug reports. But I also got involved in more generic Quality Assurance work and tried to organize the nascent QA team. It was all really a lot of fun, I could take initiatives and it was clear to me that my work was appreciated. I don t know if you find this story interesting but I had some fun time digging through archives to find out the precise dates if you want to learn more about what I did over the following years, I maintain a webpage for this purpose.

One comment Liked this article? Click here. My blog is Flattr-enabled.

19 years of freedom and counting!

Review: Getting Started with Dwarf Fortress, by Peter Tyson

Publisher:	O'Reilly
Copyright:	May 2012
ISBN:	1-4493-1494-5
Format:	Trade paperback
Pages:	219

If you're unfamiliar with Dwarf Fortress, you're in good company. Most people are, even people who play video games regularly. It was heavily inspired by roguelike games: games such as Hack and Rogue and their more recent variations, which have been around since the 1970s and are still frequently played with simple character graphics on 2D maps. Dwarf Fortress even has a roguelike gameplay mode, but the core of the game (and the only part of the game covered in this book) is the fortress mode, where the player controls a band of dwarfs in an attempt to construct and maintain a fortress. All of this is done (by default, at least) in a simulated-text interface filled with a barrage of strange characters and symbols. A Dwarf Fortress game in progress is almost incomprehensible to the uninitiated. (There are graphical tile sets available, but all the illustrations in this book assume the default display mode.) Dwarf Fortress gains its cult popularity (sufficient to support the primary developer solely through voluntary donations; the game is free) from the incredible depth and richness of the world. Almost everything is modeled in startling detail, down to the individual items of clothing that each dwarf wears, their personalities and history, and a considerable part of the industrial lifecycle of any goods that the fortress needs to produce (such as food and all-important alcohol). That's where this book comes in. The game is so massive and involves so many variables, industries, needs, requirements, and perils that the first-time player is likely to see their first games collapse due to resource problems they have no idea how to address. Getting Started with Dwarf Fortress walks the player through the initial fortress setup, the resource cycles, and the fundamentals of the various parts of the game one has to monitor. The fact that this discussion takes over 200 pages should give you an idea of the depth of the game. I should stop here and warn that, similar to my RPG sourcebook reviews, I read this book somewhat against its intended purpose. I haven't played Dwarf Fortress and don't currently intend to. It's not quite my game type: I don't like open world construction games in which it's possible to lose (and thereby lose all the things that one has built). But the idea of the game, the way it's developed, and the fact that O'Reilly would publish a book about it is so delightfully strange that I wanted to get a feel for the game without investing the time required to learn it. Thankfully, while the book is designed to be a tutorial, it also does an excellent job at conveying the feel of a game. Getting Started with Dwarf Fortress is divided into eleven chapters. After a chapter of introduction, it goes over site selection, some of the options for your initial party, and recommended settings for both. It then provides some advice for the initial rooms and initial fortress layout to get started. Subsequent chapters are more topic-oriented, covering food, merchants, resource management (including Strange Moods), digging, and the various chains of industry. The final chapters cover some of the more intricate details of dwarven life, such as justice, vampires, and hospitals, and then provide an introduction to the military and to dwarven engineering. The engineering chapter, in particular, makes it clear that vast complexity and possibility is left unexamined. One drawback of the printed version of the book (I don't know if this also applies to the ebook) is that all of the screen shots here are black and white. This makes Dwarf Fortress's already-forbidding presentation even more difficult to understand. At times, I had a hard time picking out features that were described in the text. A look at on-line screenshots quickly shows that color is massively helpful in making sense of all the little glyphs. I'm sure color printing would have made the printed version prohibitively expensive, but it is a loss. The text, though, is excellent. Not only is it clear and helpful (although with the caveat that I've not personally tested it), it captures much of the humor and feel of the game. Dwarf Fortress incorporates computer-generated storytelling that narrates the events of the game (and the backstory of the world), which has sparked a tradition of delightfully wry commentary on games, game mechanics, and events in the game (particularly the ones that cause the cascading destruction of the whole fortress). Tyson captures that tone brilliantly, weaving it throughout his descriptions. This is a tutorial that's genuinely fun to read. (Although the Tim Denee comics ending chapters sadly didn't work for me.) It's certainly possible to get started with Dwarf Fortress without this book. There are other tutorials on-line, as well as an impressively huge wiki. But this is a great introduction and is entertainment in its own right. If you've thought about playing the game, or if, like me, you want a good feel for what it's like without investing the time in actually playing it, I recommend it. I should probably note that this book covers Dwarf Fortress up to 0.34.07, and the dead tree version that I have obviously won't be further updated. O'Reilly does note on the back cover that if you purchase the ebook edition, it will receive free updates for the "life of the edition" (however long that is). If you're worried about subsequent changes in the game making the book obsolete (given the ongoing active development, this is something of a worry, although this book mostly covers fundamentals), you may want to grab the electronic version. Rating: 8 out of 10

It's actually quite simple, and this can be used to also track any package that was installed on your system from a different "origin". The "origin" field is defined in the mirror's Release file and represents where the packages come from, be it Debian, Ubuntu, or deb-multimedia (example: here is Debian Wheezy's official Release file). You can check for non official packages in Aptitude using this syntax in the search field, triggered by the / ("slash") key:

!?origin(debian)

en lire plus

What if you have a mis-behaving electronic device, which might corrupt files you store on it? I'm interested in tools to inspect incremental backups, look at file changes and alert me if they are suspicious. For example, if an MP3 changes, did the MPEG data change, or the ID3 tag, or something else? An ID3 change is likely to be on purpose, MPEG data less so. Similar for JPEGs and EXIF metadata. I decided to poke around in my backups of my music player. I discovered some pretty weird stuff. Firstly, quite a few MP3s seem to have changed on my player over time. I found 788 instances of MP3s changing a very small amount: an 11 byte rdiff-format patch. This seemed particularly strange, so I investigated a little:

...
01 Fool's Day.mp3.2012-05-31T22:40:09+01:00.diff
00000000  72 73 02 36 47 00 00 59  01 ad 00                  rs.6G..Y... 
0000000b
dark_entries.mp3.2012-05-31T22:40:09+01:00.diff
00000000  72 73 02 36 47 00 00 54  0f 58 00                  rs.6G..T.X. 
0000000b
...

In a nutshell, the patches appear to do nothing, or at least copy the input file verbatim into the output. (my rdifffs source is a useful document for the rdiff file format, or failing that, the rdiff source itself.) This is probably just a behavioural nuance of my backup software. That leaves 156 changed MP3s with rdiff patches ranging in size from 21 bytes to 26k. The smallest are almost certainly no-ops, just less efficiently stored ones. The largest looks like embedded album art in the ID3 tag being added, and I'm guessing the mid-size ones are ID3 textual changes (spelling corrections etc.), but ID3 changes are very hard to inspect by eye in the raw bytestream. For this reason I think a tool that could sort through file changes and pick out things which might need human investigation might be useful. Such tools could be run automatically after backups complete, or at scheduled times. I'll probably start writing some over the next few weeks, but if you know of any that already exist or might form part of a solution, please let me know!

A recent post by Steve Yegge has made quite a splash. The main thesis of his post is:

Software engineering has its own political axis, ranging from conservative to liberal.

Software engineering, like any other social enterprise, does have a political aspect, but I do not think this thesis is apt. The essential property of politics is that you can not have it both ways. A political problem is a coordination problem, and political decisions by its nature apply for an entire political body. Software engineering as a whole does not have these properties. There is absolutely no reason why any two engineering projects have to follow the same ideals and guidelines. Politics in engineering only appears within boundaries of a project (or, at a slightly higher level, a company), at which point it does not really warrant the name of politics, but rather character traits or personal preferences. If Johnny goes for the puck more often than Louie, that does not really warrant a label of a "liberal".

The fundamental quality that Steve is looking at is actually risk aversiveness, as he noted himself. He should have stopped there. Making that next step of conceptualization in political language does not bring any new insights and just muddles the matter.

It seems that the political labels of "liberal" and "conservative" were picked not for their meaning, but rather for their connotations, as political views are perceived to be 1) very stable, part of a person's self-identity and (therefore) hard to change, 2) inherently polarizing, and 3) difficult or impossible to evaluate objectively. Again, these do not apply to software engineering. For example, probably like many engineers, I am clearly a liberal on personal and small projects, and a conservative on larger and more fundamental ones; so much for the idea of a core identity. As for polarization, it may be prevalent in internet echo chambers, but I have not seen much of that in my professional life, especially when working with experienced engineers. When they do have objections, those objections are grounded in engineering. This leads to the third point, claiming that the approaches can not be compared objectively. This one is the most pernicious of all, because it provides an escape hatch from arguments with substance on what is an engineering decision.

Here is my, admittedly less catchy and impressive, counter thesis: Conservativeness of a software engineering project is an objective decision to be based on circumstances. TL;DR: It depends. (Very original, isn't it?) It is a risk management decision, and those are very tricky, but not subjective.

One thing to note is that the architecture of the system should correspond to the implementation style. Schemaless, heavy on magic, untyped approaches are suited for modular systems where each individual module is of limited complexity, and where the modules are isolated from each other and can recover from failures. The more complex the individual modules (and sometimes the complexity is inherent to the problem), the more benefits from "conservative" techniques. (By the way, this lines up nicely with Steve being liberal and a proponent of service-oriented architectures). If you have the freedom to pick between these two approaches, the decision making does get a bit more ideological. However, neither the "liberal" and "conservative" labels, nor risk averseness by itself is enough for a decision here. Say, if you are developing a service, what is more risky: having a "traditional", monolithic service that is inevitably sensitive to failures and is likely to scale poorly, or a cluster of components that are generally more resistant, but have more complicated aggregate behavior?

Despite the criticisms, I have to give fat credit to Steve. His post was thought-provoking, and it brought attention to the subjective side of engineering, one which is often overlooked. That side should not be left to grow - on the contrary - but the only way to reduce its domain it is to be aware of it. I know I will think twice before making another gut decision where risk averseness plays an important factor.

Thanks to the work of Andrej Belym, Debian has now a new C++ standard library. This work has been done in the context of the Google Summer of Code 2012.
Available in Debian Experimental, this new packages provides both the runtime libraries (libc++abi1) and the C++ headers (libc++-dev). With this library, it is possible to build a C++-based program without any dependency on libstdc++. For example, as detailed in README.Debian, with the (amazing) C++ code:

// foo.cpp
#include <iostream> int main()
std::cout < < "plop" << std::endl;
return 0;

build with clang++ (or g++) will give:

$ clang++ -o plop foo.cpp
$ ldd plop grep c++
libstdc++.so.6 => /usr/lib/x86_64-linux-gnu/libstdc++.so.6 (0x00007f15791cb000)

Using libc++, it will drop the dependency on libstdc++ to use lib++

$ clang++ -stdlib=libc++ -o plop foo.cpp
$ ldd plop grep c++
libc++.so.1 => /usr/lib/x86_64-linux-gnu/libc++.so.1 (0x00007f87464df000)

For the record, it is not that trivial to do with g++. The command being:

g++ -nostdlib -lc++ -lc++abi -std=c++11 -o plop /usr/lib/x86_64-linux-gnu/crt1.o /usr/lib/x86_64-linux-gnu/crti.o foo.cpp /usr/lib/x86_64-linux-gnu/crtn.o -isystem/usr/include/c++/v1 -lc -lgcc_s

Besides this change, libc++ provides a support of C++ 11, considered as "correct" against the C++11 standard by upstream.

// bar.cpp
#include <chrono>
int main()
return 0;

clang++ -stdlib=libc++ -o bar bar.cpp

More information:

• libc++ website
• libc++abi website
• libc++abi Specification

It seems that the UK government recently passed a law that makes it illegal to be unable to decrypt what the law enforcement entities think is encrypted: From http://falkvinge.net/2012/07/12/in-the-uk-you-will-go-to-jail-not-just-for-encryption-but-for-astronomical-noise-too/:

But it s worse than that. Much worse. You re not going to be sent to jail for refusal to give up encryption keys. You re going to be sent to jail for an inability to unlock something that the police think is encrypted. Yes, this is where the hairs rise on our arms: if you have a recorded file with radio noise from the local telescope that you use for generation of random numbers, and the police asks you to produce the decryption key to show them the three documents inside the encrypted container that your radio noise looks like, you will be sent to jail for up to five years for your inability to produce the imagined documents.

This is just insane. Edit: The law was created several years ago, but the blog post somehow made me think it was more recent.

With a current daily build of debian-installer you should now be able to install a VM with Debian s390x. I'm told that even installation within hercules works again. d-i's beta 1 for wheezy has a broken busybox and is hence unusable. But there were more issues:

• zipl-installer was blacklisted from building on s390x by Packages-arch-specific which caused nobootloader to be selected during installation.
• base-installer was unable to pick the correct kernel image due to it not having any rules for this architecture.
• A netcfg fix was needed that removes a 50s timeout while d-i tries to arping the configured gateway. This check seems to be pretty new and if it fails the link is still considered up and the installation continues. The network driver commonly used on s390(x) (qeth) uses layer 3 configuration by default, which means that ARP is meaningless. The IPv4 and IPv6 addresses are configured in the network adapter which then does all the ARP if necessary (i.e. not within the same machine).

The resulting installation even boots. But it shares some problems with squeeze's s390 port:

• udev's persistent network device naming is broken. It includes a volatile device ID that is incremented with each reboot. This is now tracked in Debian bug #684766.
• The TERM variable is set to linux during boot-up instead of dumb (the s390(x) terminals are either line- or form-based, except for one HMC ASCII terminal). Together with the new fancy coloured LSB init output in wheezy the screen gets even more noisy with all those escape sequences. It's yet unclear where this should be fixed. The kernel provides the init system with a TERM=linux default and it's not yet fixed up afterwards (either in initramfs-tools, or busybox, or sysvinit).

Tip of the day: If you see funny characters in x3270, then you maybe selected the wrong EBCDIC code page. If you use Linux you want to select CP1047 instead of the default CP037 in Options Character Set ( Euro). That's the target of the in-kernel ASCII to EBCDIC converter.

Quite on schedule, Weblate 1.2 has been released today. It comes with lot of improvements, especially for project admins, handling of po files and improved performance. Full list of changes for 1.2:

• Weblate now uses South for database migration, please check upgrade instructions if you are upgrading.
• Fixed minor issues with linked git repos.
• New introduction page for engaging people with translating using Weblate.
• Added widgets which can be used for promoting translation projects.
• Added option to reset repository to origin (for privileged users).
• Project or subproject can now be locked for translations.
• Possibility to disable some translations.
• Configurable options for adding new translations.
• Configuration of git commits per project.
• Simple antispam protection.
• Better layout of main page.
• Support for automatically pushing changes on every commit.
• Support for email notifications of translators.
• List only used languages in preferences.
• Improved handling of not known languages when importing project.
• Support for locking translation by translator.
• Optionally maintain Language-Team header in po file.
• Include some statistics in about page.
• Supports (and requires) django-registration 0.8.
• Caching of counted units with failing checks.
• Checking of requirements during setup.
• Documentation improvements.

You can find more information about Weblate on it's website, the code is hosted on Github. If you are curious how it looks, you can try it out on demo server. You can login there with demo account using demo password or register your own user. Ready to run appliances can be found in SUSE Studio Gallery. Weblate is also being used https://l10n.cihar.com/ as official translating service for phpMyAdmin, Gammu, Weblate itself and others. If you are free software project which would like to use Weblate, I'm happy to help you with set up or even host Weblate for you (this will be decided case by case as my hosting space is limited). Update: Weblate appliace has been updated to 1.2 as well.

Filed under: English Weblate 0 comments Flattr this!