American Psycho is a novel by Bret Easton Ellis. It's a first person stream-of-consciousness novel about a mid-to-late twenties Wall Street banker during the late-eighties-early-nineties. Patrick Bateman is a vain, self-obsessed pleasure-seeker, surrounded by a gaggle of similarly self-obsessed bankers and socialites. Bateman and his friends idle away their days thinking about what restaurants to secure dinner bookings; which nightclubs to be seen at; where to score cocaine and pick up women. They compete with one another on points of dress etiquette, and the relative degree of luxury demonstrated by their attire. They are all relatively interchangeable: the reader could be excused for mixing the identi-kit bankers up, and indeed they are frequently confused for each other, and other people, throughout the novel. Bateman describes in vivid detail nearly every item of clothing worn by both his male and female associates, describing both their cut and which fashion house they have come from, occasionally passing judgement. The murders are typically described with the same vivid detail as his more public activities. As well as a yuppie, Bateman is a psychotic, and probably a serial killer: there is a small amount of ambiguity, partially due to the frequent confusions of identity between the various male banker characters in the book. It's possible that Bateman has fantasised his killer side, or embellished it. He's clearly an unreliable narrator. It takes a relatively long time before this aspect of his personality emerges. It's also possible that he is a killer, but the people he kills are so interchangeable that nobody notices, or cares. There is a passage towards the end of the book that strays into Hollywood action-thriller levels of absurdity, possibly the only moment in the book where you have difficulty believing that the events could have occurred as described. Bateman tries repeatedly to talk to people about his crimes, but never succeeds in holding people's attention, or being taken seriously. This particular theme reaches a particularly amusing climax. Reportedly Ellis wrote the novel without the violent scenes and later added them in. I can believe that. The novel is carefully constructed to manipulate the reader in a way I've never been aware of before. The everyday and the horrific mesh to make the whole seem very consistent and lucid. There is a small surreal element woven into the story which is so subtle and downplayed that you can't withdraw into the safety of "this is a fantasy". Similar scenes recur over and over: heading to a restaurant. Heading to a club. Sex. Murder. Ellis uses repetition to lull you into a false sense of security before hitting you hard with an about-face, mid-sentence, like a movie jump-cut. This book has the dubious distinction of being the second novel ever to have made me feel physically queezy after reading a passage (and I was reading the other book in a car, which may have been a contributing factor). The book has been criticised for the level of violence meted out against women. Numerically, Bateman describes a roughly even number of male and female murders. However his female victims are dispatched with a shockingly higher level of planned sadism: most of his male victims are opportunistic rather than planned. Some critics theorise that the even male/female victim count is a deliberate pre-emption on the part of the author from criticism for the violence against women. I don't quite see the argument, here: Bateman is not a sympathetic character. He's a monster, and the fact he's a sexist monster is only one unpleasant facet of many. To me, the disdain and hatred shown towards homeless people was a far more prevalent problem, not least because it wasn't limited to murders, or even Bateman: many of the other characters are cruel towards them. What would this book be, without the murder? Quite similar to a number of Ellis' other stories, if their blurbs are anything to go by: explorations of the emptiness of the lives of privileged, upper class contemporary Americans. Is the psychopathy central to the story? I think so. The contrast between the corporate and the murderous is at the core. Would I recommend this novel? I'd hesitate to do so to anyone with a nervous disposition: otherwise, it has left a lasting impression and a desire to discuss it further, which you can take as praise. There's a good critical review at the M/C Journal.

More than two years ago I wrote arbtt, a tool that silently records what programs you are using and allows you to do statistics on that data later, based on rules that you define afterwards, hence the name automatic rule based time tracker. I wasn t doing much with it recently (the last release has been half a year ago), but it nevertheless was running on my machine and by now has tracked a total time span of 248 days in 350000 records. Yesterday, I had a use for it again: measuring the time spent creating a certain document with LaTeX. So I added a rule to my categorize.cfg and ran arbtt-stats. I knew that it was not very fast, and that my data set has grown considerably since I last used it. And indeed, it took more than 6 minutes to process the data and spit out the result. Since I m currently working on the GHC 7.4.1 transition in Debian anyways, I decided to check what happens if I compile the code with that version of the Haskell compiler, instead of the previous version 7.0.4. And behold: The whole process took merely 17.3 seconds to complete! At first I did not believe it, but the result was identical, both binaries were built with the same option, i.e. no profiling enabled or anything like that. Wouldn t you also like to have such speed ups for free, just by waiting for someone else to improve their work?

I tried to find out the reason for the speed up and created profiling output from both the old and the new binary. The old binary spends 83% of the time in Categorize.checkRegex, which basically just call Text.Regex.PCRE.Light.match. Since the version of pcre-light is the same in both binaries, I conclude that the Foreign Function Interface that GHC provides to interact with C libraries (libpcre in this case) is much faster now, although I do not find any mention in the release notes. And even if I do not count the 83% time spent in checkRegex, the code from the new compiler is still 2.7 times faster. Thanks, GHC devs, great work!

Flattr this post

Our society is one that is pretty well defined by timeliness. TV programs start at a precise time, down to the second. Schools have elaborate timekeeping systems. Even church services are carefully timed. We know how fast we re going, and our GPS or phones tell us when we ll get there. And we re pretty confident that we will, in fact, get there. Somehow this doesn t apply to our pickup. This pickup, in case you re wondering, is a thing of stories, shall we say. After a particularly frustrating experience with it one week (oh yes, the battle extended several days), I likened it to the Greek gods. And Terah had a good laughing fit when I began a sentence with The reason there s a towel connecting the brake pedal to the steering wheel But I guess the thrifty side of me won out, and somewhere along the line, I relented. My brother fixed up the carburetor. I got it a new battery. The flat tire is repaired. The starter broke, and I got it replaced. And I even got an oil change. Fancy, I know. So today, when I needed to take some backbreaking junk off the yard, I was hoping the pickup would work. I hadn t driven it in months, and any manner of catastrophe could have struck it in that time. So I was mildly relieved when it started on the 6th try. That is, quite seriously, quite the improvement, and shows how skilled a mechanic my brother is. The speedometer, of course, isn t working. The odometer stupidly reads 21531 or something like that (it was only a 5-digit odometer, broke long ago, so who knows how many miles it really has.) And I like to keep things like grease and heavy ancient air conditioners (one of the things I was hauling) away from my watch, so I wasn t wearing it. The result: I have no idea what time it is, how fast I m going, when I ll get there, IF I ll get there, or all those things. I set out, and made it a good half mile before it died as I was rounding a corner at the bottom of the hill. Always a great place for a finicky old stick-shift vehicle to die, right? Anyhow, a few random adjustments to the choke later, and the thing sputtered then roared (and I do mean roared) back to life. A little lurching up the hill and I was back on my way. Now, I was stuck there in the middle of the road, but it was a country road, so I d have probably had a good hour to get it fixed before worrying about blocking anybody s way. My first stop: my great uncle s place. He has a scrap metal for charity project going on. He is looking for old motors, air conditioners, dehumidifiers, etc. He takes them apart, separates out the metals, sells them, and donates the result to MCC, a world relief agency. I knew I had an old dehumidifier in the basement, and thought I remembered seeing an old window air conditioner in the elevator. That thing is probably the single heaviest object I have ever moved without help. I have a bandaid to prove it. It was way too heavy to carry, so I kind of rolled it, side to side, from the side of the elevator on to the pickup. If you were watching, you d have heard me making struggling noises, followed by BANG rattle rattle rattle pause struggling noises . BANG rattle rattle rattle as I rolled it along the ground, and waited for the internal bits to settle after each quarter turn. So anyway, eventually I got it to the pickup, and then had the sickening realization: I have no way to get this thing up there. Oops. I eventually placed it on top of an old tire rim, balanced it there as I knelt down, and somehow still not quite sure how managed to lift the entire thing a few feet until I could get some leverage to shove it onto the pickup. I later commented to my dad that it was a Chrysler brand air conditioner, somewhat to my surprise, and he said that it was probably my great-grandpa s. That was a surprise. Anyhow, back to the pickup. I drove down the few miles to my great grandpa s place, not really knowing how fast I was going. I smelled the familiar smells of the old pickup: exhaust fumes, oil on hot surfaces it shouldn t be on, a touch of hot antifreeze. You never have any doubt about whether the engine is running. It was sort of nice to not know, or particularly care, how fast I was going, or what time it was. Sometimes I d idly wonder, but you know, it didn t really matter and there wasn t a thing I could do about it anyhow. I got to uncle s place, unloaded the junk sorta dropped the air conditioner off the back of the pickup with a terrific BANG, then rolled it all the way to his trailer and got back in. On to town. I hadn t put gas in the pickup in a few years, and I suspected it was getting low. (The gas gauge, you guessed it, doesn t work right either.) Plus we had some large recyclables built up and it was time to get rid of them. And for that, I had to drive on the highway a ways. The speed limit there is 65MPH. I have no idea how fast I was going, but it wasn t 65. Maybe it was 45. I got passed a lot, but nobody looked particularly surprised that a pickup that looks like mine wasn t going 65. Partway there, I smelled a different smoke smell. Not an oil smoke, but more of a grassy or wood smoke. Hmm, I thought. That s odd. Hope it s not coming from the pickup. I didn t really see smoke anywhere else, so I just drove on until I couldn t smell it anymore. I unloaded the recyclables, then went to the gas station. As the pump readout neared $50, I decided: 1) the gas tank really was pretty empty, and 2) I just can t put more gas in it anymore. That would be more than the truck s worth. So I drove home. The drive home was into the wind. My face got pretty cold I always drive with the windows open to prevent carbon monoxide poisoning (remember the fumes?) I got home and prepared to pack up the pickup close the windows, replace the bungee cord holding the brake pedal up, etc. I then thought I d have a look under the hood to see if there was anything, well, on fire. Nope, but there was a packrat nest that fell down as soon as the wind hit it. Source of grassy-smelling smoke identified. It s amazing what difference simple lack of knowledge makes sometimes. Not knowing what time it is or how fast I m going means I don t have to worry about those things. I wonder how society has changed simply because accurate and cheap watches are available. I kind of like driving the old truck. It s a bit of an adventure, a bit of a challenge, a bit of randomness, and a bit of an escape from the normal and predictable. Not a bad deal for a $75 vehicle.

Ben Hutchings writes:

There is an alternative to using C-c, and that is M-#. This adds a '#' to the start of the line, commenting it out, and then behaves as if you pressed Return. The result is that the command is cancelled but still remains on-screen and in your history. You can then copy the command later using the mouse or keyboard.

Naturally, there is a zsh equivalent for this (there always is...): pound-insert. Quoth the manpage:

pound-insert
If there is no # character at the beginning of the buffer, add one to the beginning of each line. If there is one, remove a # from each line that has one. In either case, accept the current line. The INTERACTIVE_COMMENTS option must be set for this to have any usefulness.

So if you want the same for zsh, a simple

bindkey '^[#' pound-insert

is all you need. Update: Clint Adams noted another way to do (almost) the same.

Cleaning up a local repo:

git rebase -s ours -i --autosquash HEAD~20

Allowing the remote to be clobbered:

git config receive.denyNonFastForwards false

Pushing from local repo:

git push --force

Safe-guarding the remote once again:

git config receive.denyNonFastForwards true

In case you are rebasing an ikiwiki, you want to clobber the local checkout on your server, as well:

git remote update && git reset --hard @ u 

Done.

I've just uploaded version 3.9.3.0 of Debian Policy. The really big change in this version is the 1.0 version of the copyright format specification, but that will get a separate announcement once the www team has had a chance to put it in place on the web site. There are a bunch of other fixes, though, including some normative changes. Here's the upgrading checklist (duplicated from my announcement, but formatted a bit prettier):

2.4

New archive sections education, introspection, and metapackages added.

5.6.8

The Architecture field in *.dsc files may now contain the value any all for source packages building both architecture-independent and architecture-dependent packages.

7.1

If a dependency is restricted to particular architectures, the list of architectures must be non-empty.

9.1.1

/run is allowed as an exception to the FHS and replaces /var/run. /run/lock replaces /var/lock. The FHS requirements for the older directories apply to these directories as well. Backward compatibility links will be maintained and packages need not switch to referencing /run directly yet. Files in /run should be stored in a temporary file system.

9.1.4

New section spelling out the requirements for packages that use files in /run, /var/run, or /var/lock. This generalizes information previously only in 9.3.2.

9.5

Cron job file names must not contain "." or "+" or they will be ignored by cron. They should replace those characters with "_". If a package provides multiple cron job files in the same directory, they should each start with the package name (possibly modified as above), "-", and then some suitable suffix.

9.10

Packages using doc-base do not need to call install-docs anymore.

10.7.4

Packages that declare the same conffile may see left-over configuration files from each other even if they conflict.

11.8

The Policy rules around Motif libraries were just a special case of normal rules for non-free dependencies and were largely obsolete, so they have been removed.

12.5

debian/copyright is no longer required to list the Debian maintainers involved in the creation of the package (although note that the requirement to list copyright information is unchanged).

copyright-format

Version 1.0 of the "Machine-readable debian/copyright file" specification is included.

mime

This separate document has been retired and and its (short) contents merged into Policy section 9.7. There are no changes to the requirements.

perl

Packages may declare an interest in the <perl-major-upgrade> trigger to be notified of major upgrades of perl.

virtual

ttf-japanese- mincho,gothic have been renamed to fonts-japanese- mincho,gothic .

Please review and update your packages as necessary the next time you make an upload.

I ve been running an IPv6 tunnel for a long time, but occasionally I ve been seeing traffic hang on it. It looks like it was the MTU, defaulting at 1500 bytes, causing issues when large amounts of data were being shuffled OUT from my Linux box, back to the net . The fix is easy: /etc/network/interfaces should have an up line for the interface definition saying: up ip link set mtu 1280 dev henet, where henet is the name of your tunnel interface. Easy enough to skip this line if your tunnel appears to be working OK, but interesting to track down.

phpMyAdmin is quite popular software (to give some numbers let's mention 10000 downloads daily on SourceForge.net or 122685 reports in Debian's popcon) and as such is quite attractive target for various scripted attacks. If you run phpMyAdmin installation somewhere you should really make sure it is enough secured, so that these script kiddies don't get through. In past month I've looked at what kind of attacks are these guys trying and in all cases these are pretty old vulnerabilities, some of them fixed years ago. So the first thing you should do is to update. It is always good to run latest stable version, but in case you can not for whatever reason, try at least taking the most important fixes and using them. In ideal world your distribution would do this job for you, but in case it did not, you can for example take patches from Debian, which is pretty good at taking our patches (surprisingly it is not much related to my involvement there). To check which patches they have applied you can use excellent patch-tracker tool, which exposes patches from all released packages. To give you overview of which issues are mostly being attempted to exploit by script kiddies right now, here is the list:

• PMASA-2010-3 - yes, more than two years old, but still unpatched in some places
• PMASA-2011-5 - "only" half year old
• PMASA-2011-6 - only useful together with wrongly configured PHP

If you have fixed these, you should be pretty safe for now, but follow our security announcements for possible future issues (you can use RSS feed or subscribe to news mailing list, where all security issues are announced as well). However there are more things you can do to keep you safer:

• remove setup directory from phpMyAdmin, you will probably not use it after initial setup
• prevent access to libraries directory from browser, as it is not needed, supplied .htaccess file does this
• properly choose authentication method - cookie is probably the best choice for shared hosting
• in case you don't want all MySQL users to be able to access phpMyAdmin, you can use AllowDeny rules to limit them
• consider hiding phpMyAdmin behind authentication proxy, so that MySQL credenticals are not all users need to login

So these are the basic steps which will help you against possible compromise, I might return to some of these in more details in future posts.

Filed under: Debian English Phpmyadmin Suse 0 comments Flattr this!

Fixing hardware Thanks to the nice Debian Swiss Knives initiative! Fixing software Besides trying to maintain the whole X stack as usual, and preparing the funky wayland, mesa, and weston trio for experimental, I got myself into other areas. Debugging gzip Jakup Wilk noticed a while ago that some multiarchified packages couldn t be co-installed due to gzipped files being different between architectures. That was reported as #647522 against the gzip package. While some developers consider the lack of determinism (as in: it s not in the gzip specification, and the current implementation generates different packages anyway!) as a dead-end for the multiarch experiment, it didn t look like undebuggable or unfixable. And indeed, as confirmed by a quick analysis: a lack of clean-up when several files are processed at once can lead to different results, depending on the order in which files are specified on the command line; the patch for that is trivial, and was later made smaller and the need for it was explained. Working in the Release Team I reviewed/approved a few packages for squeeze, but also took care of handling or finishing a few transitions (as seen in my hints file), among which the funny iceweasel9/libmozjs ones; release tools are nice, but one gets to learn lots of stuff at once (which isn t a negative aspect). I hacked a tiny collision detector so that packages involved in several transitions can be easily spotted. Given the huge number of ongoing transitions we had lately, that didn t look overkill. Squashing bugs It had been a very long time since my last working on totally random RC bugs. The Bug Squashing Party organized at IRILL was a very nice opportunity to get back to totally crazy bugs in unknown packages, but also to meet with other Debian contributors; sponsoring maintainers with good patches on their first try was nice, but walking other contributors through their first patches sent to the BTS or through their first NMUs was nice too. Waving good bye to yada Back in the M rida QA meeting I attended in 2007, there were already jokes about how bad yada was, and how it should die in a fire etc. When I started looking at the RC bug list, I quickly switched to scrolling it backwards, and I wondered how much work was left. The details can be seen in #660548, and the result is: yada is gone! sanity++; packages.debian.org Both long descriptions and translations for packages in some suites disappeared after the switch to Description-md5. Thanks to a quick and reduced packages.debian.org setup (mostly: en+de for squeeze+sid+experimental), I managed to find my way through Perl and DB files to propose patches for #657557. I m still waiting for a confirmation, but in case it works fine, we could even get a fix for DDTP/DDTSS.

Now is the point in the Debian release cycle where I usually try to go through my packages and bring them generally up to date. In case other people are doing the same thing, here are a few new facilities or techniques that I'm rolling out across my packages. (This is apart from the obvious stuff, like multiarch where appropriate and debhelper 9, and the older stuff, like using dh.)

• dh-autoreconf is a new helper tool that runs autoreconf on the package during the build and cleans up properly afterwards. I've started switching all of my packages that use Autoconf and Automake and can use autoreconf over to it. (Some upstreams have more complex scripts that have to be run to regenerate the build system.) It plugs in trivially as a dh add-on, and even adds support for --as-needed (see below). I'm doing this even for packages where I don't patch the build system, on the grounds that rebuilding everything from source, including the build system, is a good idea. It also means that I can patch the build system when I need to without having to add additional machinery at the time.
• Linking with --as-needed. As I build new packages, I'm looking for anything that has warnings about generating unnecessary dependencies and adding --as-needed to the linker flags. The combination of dh-autoreconf and the new dpkg-buildflags support makes this trivial to do for most packages. Just add something like:

      export DEB_LDFLAGS_MAINT_APPEND = -Wl,--as-needed

  to debian/rules. It's worth being aware that --as-needed can break some unusual uses of special cases around shared library loading, but I've not run into any of those cases with any of the software that I package.
• dpkg-buildflags comes essentially for free with debhelper 9, but it's worth mentioning that, as mentioned above, it's a really easy way to add additional flags. And if you have to pass in flags via some other mechanism, use dpkg-buildflags to get the default flags.
• Once you're up to debhelper 9 and are using dpkg-buildflags, adding hardening flags is easy. You get the default ones for free, and that's a pretty good start. (Install hardening-includes and use hardening-check to check the status of the binaries built by your package.) I always add at least hardening=+bindnow to DEB_BUILD_MAINT_OPTIONS (set with export in debian/rules), since the minor speed hit at startup doesn't matter for anything that I'm packaging. (It might for something like ls that runs all the time.) I usually try to also add +pie, but be careful of that. Libtool will cope correctly with it and switch it back to PIC for shared libraries, but other shared library build processes may not. And it doesn't always work; for example, gnubg (GNU Backgammon) just immediately dies if built PIE, for reasons that I didn't track down.
• If, like me, you maintain your packaging in Git without using a separate tool that exports a patch series, and therefore use the single-debian-patch option, there is new support for applying that option only to your build as the maintainer but not to any other build that people do of your source package. This is good, since it means that any NMU diffs will be kept separate from your maintainer diff because they'll get the version of the NMU package added. To get this behavior, move debian/source/patch-header to debian/source/local-patch-header and debian/source/options to debian/source/local-options (assuming that's your only option; otherwise, you might need to split it). Then the patch header and options won't be included in the generated source package and hence won't apply to NMUs or other packaging changes based on the source package in the archive instead of on the packaging repository.

It's also worth mentioning that Ubuntu was responsible for breaking a lot of ground here. Due to bug reports and patches submitted from Ubuntu, several of my packages already had hardening build flags and --as-needed issues fixed before this round of packaging refresh, which made adding these features much easier than it would be otherwise.

To use an SSH agent, one usually has to:

1. launch the agent;
2. add his key to it.

The first step can be automated in the desktop or shell startup script (this is a typical use case for login shell-only startup scripts, by the way), but the second one cannot if your private key is protected by a passphrase.Opportunistic key loading GNOME Keyring includes an SSH agent which has an interesting feature I call opportunistic key loading : it asks for the passphrase to decrypt the private key the first time it is needed. This feature mimics the behaviour of PGP agents, and eliminates the second step I previously mentioned. Question Do you know if there exists another SSH agent able to do opportunistic key loading?

Ben mentions he left Google Reader and went back to Liferea, but mentions a series of bugs that keep him from being happy. After pondering it a bit, a couple of months ago I also left Google Reader, but I turned to a free webapp: rssLounge aggregator. Although it does not fully cover Ben's wishlist (I'll get to it now), I am happy using it as it covers my main need: Being able to read my stuff from just about everywhere, without installing even a ssh client (that would make public Windows machines a liability for me, as they could sniff my keystrokes while authenticating to my ssh server). So, for me, a webapp is basically a must. Well, as for Ben's list:

1. MAY be a desktop or web application.
   Check. Well, I don't know what would fail this :)
2. If it's a web application, it MUST be reasonably secure, e.g. it must not be written in PHP.
   Fail. It's PHP. And that's my main reason for not uploading it to Debian I use and enjoy this app every day, but it has some bugs I don't really feel like looking into. And yes, maintaining PHP code is ugly.
3. If it's a web application, it MUST allow for multiple independent users on the same server.
   Don't really remember, I set it up just for myself. But in any case, you could install a different instance per user?
4. If it's a desktop application, it MUST embed a browser engine (presumably Gecko or WebKit) so I can follow links without having to switch windows.
   N/A
5. MUST support organisation of feeds by folders or tags, including combined item lists.
   Pass.
6. MUST keep track of which items have been read.
   Pass.
7. MUST support a global 'unread items' list. SHOULD only remove items from this list when I refresh it, not as soon as I move away from an item.
   Pass. In fact, given that storage is cheap, I have set it to never expire old entries. I don't know if it will ever be useful, but as long as it does not hurt me...
8. SHOULD support a three-pane (folder/list/item) view or something similar. Google Reader's list view with expanding items is perhaps even better, though it means links must be opened in a separate tab.
   It's more like Google Reader's
9. SHOULD support folder and item navigation by keyboard.
   Pass.
10. SHOULD have some way to flag/bookmark items for later attention.
    Pass.
11. If it's a desktop application, it SHOULD have some sort of download manager to support podcasts.
    N/A

So, Ben, with only one (big) fail, it might be a good candidate for you. PS- And hard as it might seem, I am leading an almost-Google-free life now! :) But don't let them hear this, as we want them to keep sponsoring Summer of Code and DebConf.

I switched from Google Reader to Liferea a while back. I was mostly happy with the functionality of Reader but I don't really want my reading history to be recorded or my feed list to be vulnerable to the whim of Google's inscrutable abuse department. I'm still using Liferea but unfortunately it has a lot of problems. Yes I do have bug numbers:

• Calls sync() many times while refreshing feeds (#623619). This is probably related to use of SQLite and not properly batching writes. I work around this by using 'eatmydata' to nullify those calls, but that's not ideal.
• The UI thread also blocks on feed updates. Together with the previous bug, this can make it unresponsive for minutes while updating feeds (#542276).
• It often leaks memory and other resources when I play embedded video (#660593).
• There is no progress or 'busy' indicator for the browser (#660595).
• Error/prompt callbacks are not handled (#660597) - for example, if I follow a link that happens to lead to a PDF, nothing happens.
• There is no progress indicator for downloading 'enclosed' files (typically podcast episodes), and errors are simply ignored (#660599).
• While updating feeds, it may reset the item pane back to the summary (#660602).

So, I'm looking for an alternative again. My requirements are:

1. MAY be a desktop or web application.
2. If it's a web application, it MUST be reasonably secure, e.g. it must not be written in PHP.
3. If it's a web application, it MUST allow for multiple independent users on the same server.
4. If it's a desktop application, it MUST embed a browser engine (presumably Gecko or WebKit) so I can follow links without having to switch windows.
5. MUST support organisation of feeds by folders or tags, including combined item lists.
6. MUST keep track of which items have been read.
7. MUST support a global 'unread items' list. SHOULD only remove items from this list when I refresh it, not as soon as I move away from an item.
8. SHOULD support a three-pane (folder/list/item) view or something similar. Google Reader's list view with expanding items is perhaps even better, though it means links must be opened in a separate tab.
9. SHOULD support folder and item navigation by keyboard.
10. SHOULD have some way to flag/bookmark items for later attention.
11. If it's a desktop application, it SHOULD have some sort of download manager to support podcasts.

During these days, there are various carnivals in Prague. On Saturday I've visited Malostransk masopust, which is probably not the biggest one, but definitely the one in most attractive location, starting at Prague castle and going down to Kampa. This was actually my first visit of this carnival and I quite enjoyed it. Bellow you can find some photos taken during the event to catch the atmosphere:

Filed under: English Photography 0 comments Flattr this!

Intro RAID sucks, and so do all other Free alternatives in the Linux world. Having been in exactly the same situation several times in the past, I have been following Russell Coker's posts regarding data integrity with interest. FWIW, the correct answer to "BTRFS (sic) and Xen" is: subvolumes. Now that Fedora has, once again, decided to postpone their switch to Btrfs as default file system, I decided to write up my own take on this topic. Any and all my considerations are made under the assumption that important data is backed up while semi-important data is at least living on two different machines. Beware, this is a long post, but I do like to think it's well worth reading. RAID Disk failures Let's recap the current situation for "traditional" file systems like xfs, ext 2..4 , etc. In case you need to freshen up on the technical details go here.

• Single disks: Fine for many use cases like Laptops, Desktops, etc, they are what most of us are using for most storage needs.
• RAID 0:If you are using that, you are most likely doing it wrong. Barring increasing caches for SSD-based volumes on machines which you simply take out of your cluster if there is any kind of problem, I don't know of not a sigle valid use case. Other than to get rid of data, that is.
• RAID 1: The default for small servers and important machines which don't need a lot of disk space.
• RAID 5: OK for personal storage servers, avoid once disks become larger than 500GB-1TB, depending on personal preference. To write data, you need to calculate new checksums and thus read all data from all corresponding slices, impacting write performance significantly.
• RAID 6: The RAID 10 people will disagree, but I like this RAID level best. While your write performance will definitely take a hit, you can mitigate this by decreasing your volume sizes. The extra cost in ways of power, disks, controllers, and rack space are a price we gladly pay for the ability to lose two disks and still retain all data.
• RAID 10: Great write performance until the day when two disks in the same RAID position die right after each other and your company's main mail storage dies. Yes, this has happenend to me and it sucks.
• RAID 2,3,4,50,60,foo: Mostly irrelevant in the real world; disregard.

Silent corruption All the RAID levels with redundancy are fine and dandy if you lose a whole disk and put in a new one. Of course, that does not help you the tiniest bit once you get read errors. Controllers which manage RAID 1 or 10 may or may not compare the data while it's being read and may or may not tell you about discrepancies. They can then toss a coin and give you either result. There is no way to determine which is correct. RAID 2, 3, 4, 5, and 6 could, in theory, verify the data as it's being read, but that would limit your read rate to that of a single disk so no one does that. We actually had a massive web presence fail over night, once. No one knew what the cause was as there hadn't been any kind of access logged. As that particular deployment is done directly from a VCS, we simply ran a diff and found one change. We traced the failure down to a syntax error; a one character change made everything fail. Looking at the ASCII table, it was clear that one single bit had flipped. This sucked. A lot. Mitigation So you end up scrubbing your RAID sets on a weekly basis, recovering from silent corruption with the help of your RAID 6's two parity stripes. And even though you schedule the scrubbings with the least priority, you still take a performance hit when randomly seeking a lot. ZFS Some smart people at Sun set out to fix these problems and more, and fix it they did. The "Z" in ZFS is meant to imply that this is the last file system you will ever need and if not for its license, this might have worked. Of course, "last" and "forever" mean "not now" and "10 years" respectively, in computer terms. The limits within ZFS have been chosen so that the entropy needed to create a disk able to max out a ZFS volume would, literally, require our oceans to boil. Let's just say that you won't encounter these limits any time soon. While that is a nice thing to know, it does not say anything about data integrity. There are several mechanisms ensuring data integrity built in ZFS, the most fundamental being extensive checksumming. Checksums are vastly superior to live comparisions which RAID would have to perform as it does not need to sacrifice any significant i/o reading checksum data. With HDD access, you are i/o-bound, and not CPU-bound, anyway, so performing the checksum calculations is laughably cheap when factoring in the added safety. Everything, be data, metadata, inodes, you name it, is checksummed. Every read operation must go through the checksumming functions, ensuring that all data which reaches your user space is correct. If ZFS can't verify the checksum, it will not deliver any data at all, ensuring noticeable, as opposed to silent, corruption. So how does ZFS recover when the checksum does not match the data? copies= 1..3 The easy way is to store several copies of your data within your volume. Mount a ZFS volume or subvolume with copies=2 or 3 and all data that is being written from then on will be copied twice or three times. Trivial in principle, but powerful when built into a file system. RAIDz 1..3 This is where things start to get interesting. RAIDz1, 2, and 3 will allow you to lose 1, 2, or 3 disks respectively while still retaining your data; at the obvious expense of the storage capacity of as many disks. Basically, RAIDz2 is ZFS' variant of RAID 6, but it's so much better than mere RAID 6. Moo! RAIDz will not assign fixed slices and fill them up like RAID does. It will look at the current write speeds and use appropriate slice sizes dynamically. As a direct result, data which has been written at roughly the same time will always be near other data written at the same time. This is very nice for functionality like snapshots, writeable subvolumes and other things and is called COW, ZFS' variant of super cow powers. This also enables ZFS to write data, read it back and verify the checksum and only then point to the new data. Atomic commits done right. Keep rollin' As ZFS has to keep track of what data is still in use in which volumes and subvolumes anyway, it knows which regions are free to be reclaimed. Instead of filling up random places, ZFS will roll over your disks, overwriting unused data on the fly. This bears repeating: Contrary to RAID 5 and 6, ZFS will never need to read old data in order to write new data. Write performance galore and anyone still stuck on RAID 10 can finally enjoy the increased data security. Btrfs To be completely honest, I do not know Btrfs as well as I know ZFS. If I get anything wrong, correct me. If I offend anyone with my outsider's interpretation, that is not my intention. Btrfs has been initiated by Oracle way before it ever even thought about buying Sun or history might have run a different course, for worse or a lot worse. The closing of Java, Solaris, ZFS, Hudson, OpenOffice (since then "gifted" aka thrown away), and others makes me think the latter. As there are few technological developments which caused me as much stress, overtime and pain as OCFS2, I am naturally wary of file systems sponsored by Oracle and their data focus integrity/availability. The fact that there's still no way to fsck a Btrfs volume could be birthing pain or yet another facet of Oracle's stance on this topic, I honestly don't know. Either way, it's a good idea to be wary for now. I can't say too much on Btrfs' technical underpinnings, but I know it uses COW and that it has its own variant of RAID. Toss in snapshots (writeable?), subvolumes and integrated block device management, and you have the building blocks of a decent file system. Still, Btrfs is not ready for prime time. Btrfs has been "one or two years in the future" for a few years now so I will not be holding my breath. And once the first distributions are starting to use Btrfs by default, people will lose data. A year or three after that, I will feel comfortable to use it myself and in production. Commercial solutions You can either hand a lot of money to proprietary vendors who will not tell you a thing about how things work internally (and no way to fix things directly) or you can buy solutions that employ ZFS in the back-end. I prefer my storage hardware to be relatively dumb while keeping the intelligent bits where I can see and poke them so this is not really part of these considerations. So what can you do? Test your disks before deploying them Easy, but vitally important:

disk=/dev/foo
smartctl -a $disk
smartctl -t long $disk
badblocks -swo $vendor_$model_$serial_$timestamp.badblocks.swo $disk
smartctl -a $disk

If you are lazy, get a copy of disktest, a tool I wrote to do exactly this. It should wait for the long self-test to finish, can not read out all vendor names, and does not have a way to document who ran the test, but it's a start. Patches and feedback are, obviously, welcome. And yes, I will package this soonish. Using your disks This list is surprisingly short. You can use

• distinct disks
• RAID as per above
• ZFS-FUSE
• Debian/kFreeBSD
• Nexenta

And that's it. At work, I prefer small RAID 6 volume sets. It sucks, but there is nothing better. For personal use, I have a machine with a FUSE-based RAIDz2 mounted with copies=2. Three disks can fail and my data is still secure. While this setup is slow as molasses due to FUSE, speed is not a consideration for me here; data safety is. A migration to Debian/kFreeBSD in the medium term is still likely. If you have things to add or disagree with me, I would love to hear from you. Update: Jan Christian Kaessens pointed out that, contrary to my experience, zfsonlinux did not bring down his sytem in flames. As zfsonlinux is a kernel module, potential performance is a lot better. Also, it supports ZFS Pool Version 28 as opposed to FUSE-ZFS' 23. While the really nice features are in v 29 and 30 (which are closed thanks to Oracle) v 28 still has some nice changes.

A few people have been using the license-count tool that I wrote to analyze the breakdown of licenses in Debian and draw some conclusions. Unfortunately, some of those conclusions can't be drawn from the output of this specific tool (which doesn't make them wrong, just unproven). So here are a few cautions. license-count was written for a specific purpose: to see how many references there are to a particular license in Debian so that we had some facts behind our discussion of whether to include it in common-licenses. It was not written to classify packages into particular categories, only to find out how many copies of a license we could save by adding it to common-licenses. This means that using it to determine how much software in Debian is covered by a particular license fails in the following ways:

1. license-count numbers cannot be added. Since the goal is to find every reference to a given license, each package is not classified as under one and only one license. If a package has material under the GPL, the LGPL, and the GFDL, it will add one to each of those counts. This means that you cannot determine, from its output, questions like "how many packages are covered under one of the GPL family of licenses?" You will double- or treble-count packages when you add the numbers together.
2. license-count counts any reference, not just "important" ones. If the license is referenced in debian/copyright, that counts, since the goal is to see how many packages might benefit from being able to reference it in common-licenses. This may not be the license that the package is under, just some small portion of the package. For example, all of my packages that use Autotools add to the GPL count because I include all the source code licensing statements, including the statements for libtool and the Automake helper scripts, which say that the files can be released under either the GPL or the license of the including package. These packages are generally under a BSD-style license (or in some cases the Apache 2.0 license), not under the GPL, but since the reproduced license text has a reference to the GPL, license-count adds one to the GPL column for each of those binary packages. For most purposes for counting GPL-covered software, these are false positives. I don't know how many people are as complete in documenting license statements as I am, but just the binary packages that I maintain probably count for at least 50 false positives because of this alone.
3. license-count numbers include dual-licensing. Whether this matters for your analysis or not depends on what question you're asking, of course. If you're asking whether the package is covered under a copyleft license, including the thousands of packages that are dual-licensed under the Artistic license and the GPL may be okay, since the Artistic license is a sort of copyleft (although it allows you to avoid the copyleft requirement by renaming executables, providing the originals, and documenting your changes). But, for example, one of my packages is dual-licensed under a BSD-style license and the GPL (for reasons that aren't worth getting into). This package is not covered by copyleft under any reasonable definition of the term, but license-count will count it as a package using the GPL.

In order to draw interesting conclusions like "how much software in Debian is protected by copyleft," I'm afraid that you'd have to write a much more sophisticated tool than license-count.

At FOSDEM, John Sullivan delivered an interesting talk titled Is copyleft being framed? to verify alleged claims on the decline of GPL-d software. (Slides are available.) The crux of the talk is the analysis he performed on the Debian archive to discover the amount of software we distribute that is covered by GPL, LGPL, or AGPL ("GPL-d" for short in the remainder). John's talk steps in an interesting and long running debate (a recent summary of which is available in this ITWire article). The most interesting part is the discrepancy among John's results and Blackduck's, which are often used to argue how the popularity of the GPL license is declining. That might be the case. Or not. The more analyses we do to find it out, the better. The underlying assumption on John's work is that Debian is a representative sample of the Free Software out there, which I think is a reasonable assumption. I find the analysis presented in the talk completely satisfactorily from a purely scientific point of view. The same cannot be said about Blackduck's result: both their methods and data are secret, making it impossible to reproduce their experiments. Highly unscientific. Still, John's results are surprising: as much as 87 percent of Lenny's packages and 93 percent of Squeeze's are GPL-d. That seems a lot. Puzzled about that, John discussed with me the issue before his talk, in search for pitfalls in his methods or data. Finding none, I pointed him to the almighty DktrKranz for some extra review; who found nothing either. To stay on the safe side, even during his talk John called for independent reviews of his results. What could be wrong? The tool used to gather the data is license-count from the debian-policy package. Input data are the debian/copyright files of all Debian source packages. If license-count is not bugged, our debian/copyright files might be. One thing that occurred to me only a few days ago is the habit of declaring a different license for Debian packaging (the files under debian/) than the software being packaged itself. That's a bad habit because it might cause unwanted license mixtures via patches that live under debian/ but I've seen several occurrences of it in the Debian archive. For name and (self-)shame: I've also been guilty of it in the past, when I was young . Is that reason enough to skew results and overestimate GPL-d software? I don't think so, I hope not, but ultimately I don't know. It'd be nice to rule out the possibility entirely. So if anyone is willing to do some sampling of affected debian/copyright files and propose patches for license-count to exclude those "false positives", please shout. (As a bonus point: that would also help to take more sound decision for the typical use case of license-count, i.e. deciding when a license should be added to /usr/share/common-licenses.) Other independent reviews of the results are equally welcome. Note: the above, as well as John's analysis, would be a trivial exercise if DEP-5 were already widely deployed in the Debian archive.

---

Update: add link to John's slides
Update 19/02/2012: Russ Allbery, author of license-count, posted a way more likely cause of data skew in John's analysis: double counting among the different types of copyleft licenses

The new RcppArmadillo release 0.2.35 now supports the Rcpp::Rcout output stream device. Based on a contributed Rcpp patch by Jelper Ypma, the Rcpp::Rcout output stream gets redirected to R's buffered output. In other words, R's own output and that eminating from C++ code using Rcpp::Rcout are now both in sync. This avoids a stern warning from Section 5.6 in the Writing R Extensions manual:

Using C++ iostreams, as in this example, is best avoided. There is no guarantee that the output will appear in the R console, and indeed it will not on the R for Windows console. Use R code or the C entry points (*note Printing) for all I/O if at all possible.

and does in fact provide exactly what is recommended: the same entry points R itself uses. Below is a sample program, once again using the wonderful inline package to compile, load and link C++ code into R from a simple text variable submitted to the cxxfunction. What is shown in R code to load the package, the definition of the C++ code as assigned to a variable src and the creation of the dynamically-loadaded R function called fun which contains the code from we compiled, link and load via a single call to cxxfunction() given src.

library
library(inline)
src <- '
  Rcpp::Rcout << "Armadillo version: " << arma::arma_version::as_string() << std::endl;
  // directly specify the matrix size (elements are uninitialised)
  arma::mat A(2,3);
  // .n_rows = number of rows    (read only)
  // .n_cols = number of columns (read only)
  Rcpp::Rcout << "A.n_rows = " << A.n_rows << std::endl;
  Rcpp::Rcout << "A.n_cols = " << A.n_cols << std::endl;
  // directly access an element (indexing starts at 0)
  A(1,2) = 456.0;
  A.print("A:");
  // scalars are treated as a 1x1 matrix,
  // hence the code below will set A to have a size of 1x1
  A = 5.0;
  A.print("A:");
  // if you want a matrix with all elements set to a particular value
  // the .fill() member function can be used
  A.set_size(3,3);
  A.fill(5.0);
  A.print("A:");
  arma::mat B;
  // endr indicates "end of row"
  B << 0.555950 << 0.274690 << 0.540605 << 0.798938 << arma::endr
    << 0.108929 << 0.830123 << 0.891726 << 0.895283 << arma::endr
    << 0.948014 << 0.973234 << 0.216504 << 0.883152 << arma::endr
    << 0.023787 << 0.675382 << 0.231751 << 0.450332 << arma::endr;
  // print to the cout stream
  // with an optional string before the contents of the matrix
  B.print("B:");
  // the << operator can also be used to print the matrix
  // to an arbitrary stream (cout in this case)
  Rcpp::Rcout << "B:" << std::endl << B << std::endl;
  // save to disk
  B.save("B.txt", arma::raw_ascii);
  // load from disk
  arma::mat C;
  C.load("B.txt");
  C += 2.0 * B;
  C.print("C:");
  // submatrix types:
  //
  // .submat(first_row, first_column, last_row, last_column)
  // .row(row_number)
  // .col(column_number)
  // .cols(first_column, last_column)
  // .rows(first_row, last_row)
  Rcpp::Rcout << "C.submat(0,0,3,1) =" << std::endl;
  Rcpp::Rcout << C.submat(0,0,3,1) << std::endl;
  // generate the identity matrix
  arma::mat D = arma::eye<arma::mat>(4,4);
  D.submat(0,0,3,1) = C.cols(1,2);
  D.print("D:");
  // transpose
  Rcpp::Rcout << "trans(B) =" << std::endl;
  Rcpp::Rcout << trans(B) << std::endl;
  // maximum from each column (traverse along rows)
  Rcpp::Rcout << "max(B) =" << std::endl;
  Rcpp::Rcout << max(B) << std::endl;
  // maximum from each row (traverse along columns)
  Rcpp::Rcout << "max(B,1) =" << std::endl;
  Rcpp::Rcout << max(B,1) << std::endl;
  // maximum value in B
  Rcpp::Rcout << "max(max(B)) = " << max(max(B)) << std::endl;
  // sum of each column (traverse along rows)
  Rcpp::Rcout << "sum(B) =" << std::endl;
  Rcpp::Rcout << sum(B) << std::endl;
  // sum of each row (traverse along columns)
  Rcpp::Rcout << "sum(B,1) =" << std::endl;
  Rcpp::Rcout << sum(B,1) << std::endl;
  // sum of all elements
  Rcpp::Rcout << "sum(sum(B)) = " << sum(sum(B)) << std::endl;
  Rcpp::Rcout << "accu(B)     = " << accu(B) << std::endl;
  // trace = sum along diagonal
  Rcpp::Rcout << "trace(B)    = " << trace(B) << std::endl;
  Rcpp::Rcout << std::endl;
'
fun <- cxxfunction(signature(), body=src, plugin="RcppArmadillo")
setwd("/tmp")                           # adjust on other OSs
fun()                                   # output to stdout
sink("rcpparma.log.txt")                # start 'sink' to output to file
fun()                                   # no output to screen
sink()                                  # stop 'sink'

We then switch to a temporary directory (as the example code, taken from one of the two examples in Conrad's Armadillo sources, creates a temporary file) and run the new function. To demontrate how it does in fact now mesh perfectly with R, we create an output 'sink' (which catches all output) and re-run. This simple example demonstrated how we can use the new Rcout output stream from Rcpp to have dynamically-loaded C++ code cooperate more cleanly with the (buffered) R output. It also demontrated some of the nice features in Armadillo which we bring to R via RcppArmadillo.

While improving GNOME s servers Nagios Notifications, I ended up working on a nice way to notify the relevant folks through GTalk in case something could go wrong on any of the hosted services. Looking around on the web, I found Seth Vidal s script, modified it to suit my needs and made it working with GTalk, here s the result:

#!/usr/bin/python -tt
import warnings
warnings.simplefilter("ignore")
import xmpp
from xmpp.protocol import Message
from optparse import OptionParser
import ConfigParser
import sys
import os
parser = OptionParser()
opts, args = parser.parse_args()
if len(args) < 1:
    print "xmppsend message [to whom, multiple args]"
    sys.exit(1)
msg = args[0]
msg = msg.replace('\\n', '\n')
# Connect to the server
c  =  xmpp.Client('gmail.com')
c.connect( ( 'talk.google.com', 5223 ) )
# Authenticate to the server
jid  =  xmpp.protocol.JID( 'example@gmail.com' )
c.auth( jid.getNode( ), 'yourgmailpassword' )
if len(args) < 2:
    r = c.getRoster()
    for user in r.keys():
        if user == username:
            continue
        c.send(Message(user, '%s' % msg))
else:
    for user in args[1:]:
        c.send(Message(user, '%s' % msg))

I, then, added the command definitions on the relevant Nagios configuration file:

define command 
        command_name    host-notify-by-xmpp
        command_line    /home/user/bin/xmppsend "Host '$HOSTALIAS$' is $HOSTSTATE$ - Info : $HOSTOUTPUT$" $CONTACTPAGER$
         
define command 
        command_name    notify-by-xmpp
        command_line    /home/user/bin/xmppsend "$NOTIFICATIONTYPE$ $HOSTNAME$ $SERVICEDESC$ $SERVICESTATE$ $SERVICEOUTPUT$ $LONGDATETIME$" $CONTACTPAGER$
         

And in the end on contacts.cfg:

define contact  
        contact_name    admin
        use             generic-contact
        alias           Full Name
        email           example@gmail.com
        pager           example@gmail.com
        service_notification_commands   notify-by-xmpp
        host_notification_commands      host-notify-by-xmpp
 

When done just reload the configuration files with:

sudo /etc/init.d/nagios3 reload

Enjoy your new XMPP Nagios notifications! Update: if you don t want the script to store your username or password, you can use the following modified script together with a nice config file like this one:

[xmpp_nagios]
username=example@gmail.com
password=yourgmailpassword

Then you can invoke xmppsend this way:

xmppsend -a config.ini

We needed a new package at work and once I'd written it, I realised that it could well be useful for others, so I did the ITP and the package is now in Debian unstable.

Ladder - Stepwise repository upgrade tool

Ladder creates a local repository of packages required

to upgrade a tarball of a chroot to a new milestone or

software release.

.

The repository can be signed and includes all specified

target packages and dependencies. The repository can then

be distributed and used to upgrade multiple devices in

sequence without needing network access.

The only dependencies are some simple perl modules, reprepro for the repository, apt and gnupg for the signing. None of those need to be particularly recent versions, so once ladder has had a little time in testing, I will be doing a backport to Squeeze. Lenny is a little less likely but eminently possible if someone specifically asks for it. Not that it particularly needs a backport mind, if you want to run ladder on some other Debian-based system, it's simply a case of installing the version in unstable. reprepro was in Lenny at a suitable version for what ladder requires, so any system remotely recent should be able to run ladder without changes.

Normally, whenever you need to upgrade a device, you need to get that device onto a network, get access over the serial port or some form of pre-configured network connection, run the commands and clean up afterwards. OK, now do that again... oh and here are another 40 or 100 devices which all need precisely the same thing done and they all have to be shipped to paying customers today. What does any geek do? Script it.

Ladder is part of that process. There would need to be some scripting / programming support on the devices concerned but ladder makes it easier to put that support in place at the design stage and then automate the actual update without the device needing to get onto a network and, potentially, allowing you to decide how to offer the upgrade (automatic, user involvement, engineers only etc.) Once that is implemented, the device is simply pointed at a locally mounted filesystem which contains the ladder step for the migration. Each step is a SecureApt signed repository which is available at a deterministic location which can be easily scripted and which contains only the packages necessary (with dependencies) to upgrade any device installed at Milestone A to Milestone B. Nice and small, only the stuff you need, whatever architecture you like and if you need to migrate from Milestone A to Milestone D, then you create a few steps on the ladder and automate the migration from A to B to C to D. All you need is enough space on whatever local media you need to use to plug into the devices. Then copy the media enough times, start the interface on each device and do something useful whilst the upgrade happens. Then, when the next lot need to be upgraded, you already have the media... Oh and ladder does not need to run on the same architecture as the devices - all package handling is entirely architecture-neutral. So create the ladder steps and media on your fast x86 machines and then let the slower SSD devices take their own sweet time via automation. Simple - maybe, hopefully.

I'm expressly talking about devices here because this is where the original requirement arose - embedded devices which don't have direct / automatic / accessible network ports or even a working network configuration preset. These aren't new images to flash onto the device either, these are apt repositories, so only the stuff which needs to be changed is changed which saves a lot of time writing to slow SSD storage.

If the mechanism sounds familiar, yes, it's using the same principles as xapt, multistrap and emdebian-grip but I thought it could be useful, so I generalised the interface (a bit) and uploaded.

Let me know via the BTS if you need tweaks to the support. Ladder isn't particularly about getting desktop machines from Debian Potato to Debian Wheezy because you need to identify a target package to be the top point of the dependency chain which gets into the step repository and all devices should start with the same packages at the same versions. Normally, the kind of devices I use at work have a single top level application which is the sole user interface and which directly or indirectly depends on all the other software required for that device. Whilst the target package value could take a few carefully selected packages instead of just one and there is support for an extra packages field, it's not intended / expected to be useful for desktops. This is for use with multiple devices which all have the same package selection, are at the same milestone at the start and which all need to migrate smoothly to whatever milestone is intended - one step at a time. Ladder could be used to migrate between Debian releases and I've included example config files to support that, but the principle usage is with internal / proprietary repositories based on a common Debian stable platform where the user interface software is managed via identifiable milestones and where users have no direct control over installing packages. It's a production / manufacturing support tool more than a user / admin support tool. If you want to manage servers and desktops which allow users to install (or request to be installed) arbitrary packages, there are plenty of tools which already support this and are used by DSA in Debian for exactly these tasks. Ladder is not puppet but Linp didn't sound like a good name...

Ladder step repositories only include the binary packages, not sources - so if the migration is not going to be done in-house and you're expecting to distribute these steps to users somehow, ensure that the original source repository is available online for the Debian / free software packages concerned. If you can't do that (because the source is proprietary), you possibly shouldn't be distributing the binaries as a user update mechanism in the first place because each step will include packages from the core Debian system which need to have the sources available when distributed.

Inevitably, the ladder source package already contains two POT files for translations of the runtime messages and the POD based manpage. I expect to need to expand / clarify the manpage in due course, so don't rush to translate it yet as it's likely to change.