Have you ever wondered which tool you should use to set the background of your X11 desktop? There are tons of it and every single one does need different command line options. And if you picked one, you could be sure, you ll once come to a machine or operating system, where that one isn t available. When I started to play around with the tiling window manager awesome, I also noticed that the awesome Debian package contains awesome s own desktop background image setting tool named awsetbg . Yet another one! I thought. But I was wrong: Today I noticed the word wrapper in awsetbg s man page. I became curious and had a peek into its source code. And indeed, it s an awesome desktop background image setting POSIX bourne shell compatible shell-script: It knows about not less than 15 other desktop background image setting tools and can be used as frontend wrapper for those who don t want to remember each tool s command line syntax:

• Eterm s Esetroot
• habak
• feh
• hsetroot
• chbg
• FVWM s fvwm-root
• ImageMagick s display
• qiv
• xv (non-free, .deb packages available from Mowgli)
• xsri
• xli
• xsetbg from xloadimage
• WindowMaker s wmsetbg
• xsetroot from x11-xserver-utils
• IceWM s icewmbg (currently disabled by default with comment broken )

Needless to say that most of them are also available in Debian. :-) You may wonder what s useful with it. Well, it does something you no more need to do yourself or in one of your own scripts: Checking which desktop background image setting tools are available on the machine you re currently working and using the appropriate command line options for tiling, fullscreen, whatever. Only drawback I found so far: In Debian, you need the awesome window manager package to be installed, if you want to get the script via APT. But on the other hand, it s just a shell script. You can easily put it into your $HOME/bin or so. :-)

The bug webinterface of the Universal Debian Database currently knows about the following release critical bugs:

In Total:	713
Affecting Squeeze:	283
Squeeze only:	74
Remaining to be fixed in Squeeze:	209

Of these 209 bugs, the following tags are set:

Pending in Squeeze:	18
Patched in Squeeze:	50
Duplicates in Squeeze:	18
Can be fixed in a security Update:	16
Contrib or non-free in Squeeze:	6
Otherwise fixed in Squeeze:	26

Ignoring all the above (multiple tags possible), 127 bugs need to be fixed by Debian Contributors to get Debian 6.0 Squeeze released. However, with the view of the Release Managers, 170 need to be dealt with for the release to happen. Please see Interpreting the release critical bug statistics for an explanation of the different numbers.

Election TomorrowOn Saturday we will have a Victorian state election. As usual for state elections most people will vote on issues related to the federal government, the mainstream media has little coverage of state politics and people seem to vote on what they see on TV. Presumably that means we have a good chance of having a similar situation to the last Federal Election where the Labor and Liberal parties each won 72 seats in the lower house and Labor formed a coalition with the Greens MP and three independents.The independent MPs didn t give much explanation of the reasons for their choices. But it seems that a large motivating factor was the Greens success in the senate, as Labor was more willing to work with the Greens that meant that if a Liberal based coalition had won in the lower house there was a good chance of a Double Dissolution.The Liberal party can t make dealsIn a world where sanity prevailed the result of this would be the Liberal party firstly adjusting their policies to appeal to Greens voters and secondly trying to make some deals with the Greens at a high level to allow the possibility of a Liberal/Green coalition government. While there are substantial policy conflicts between the Liberal and Green parties it does seem possible to get a coalition working if both sides accept that they won t get everything that they want. Forming government and getting only some of your policy implemented seems like a better option than being in the opposition and getting almost none of your policy implemented. Also there is no reason why we couldn t have a Liberal/Labor coalition government in the next decade it seems unlikely that any election will deliver a result that doesn t have Liberal + Labor comprising more than 50% of the seats in both houses.But it seems that sanity doesn t prevail. The Liberal party have put the Greens below Labor on their preferences for the upper house and on their How To Vote cards for the lower house [1]. This greatly increases the probability of Labor scoring an outright win. It also seems likely to drive a wedge against the conservative voters who want to conserve the environment.The Sad State of the Liberal PartyKevin Andrews (Liberal MP and former minister) wrote a strange and amusing diatribe titled The ideological drive behind the Greens [2]. Here is what I regard as the best part:First, those who vote Green as their primary vote: This is the Don s Party group that used to be in the ALP in the 60s and 70s: young university students or graduates, frequently working or still studying in academia, no kids, often gay, arts and drama type degrees or architecture where they specialise is designing environmentally friendly suburbs, agnostic or atheist, often US or Canadian refugees from capitalism, but well paid in professional consulting or media jobs. According to the CIA World Factbook [3] the median age of Australians is 37.5, the majority of the population were born in 1972 or later. The film Don's_Party was released in 1976 and was about the 1969 election. While Kevin Andrews was old enough to remember the 1969 election clearly the majority of the Australian population weren t even born before that election and isn t old enough to have watched the movie when it was in the cinemas. Kevin is making it quite clear that he and his party represent a time that is past. The rest of that paragraph is filled with strangeness that is a good sample of the rest of his article.The sad thing is that he seems to think that this appeal to the minority of people who are old enough to remember the 1969 election, bigoted enough to appreciate the discrimination against homosexuals (which is a long standing Liberal policy), and politically clueless enough to support McCarthyist policies against alleged communists.We need a decent and sane conservative party to represent the decent and sane Australian citizens who are politically conservative. I am beginning to doubt that the Liberal party could ever be reformed enough to become such a party.

• [1] http://www.abc.net.au/7.30/content/2010/s3074524.htm
• [2] http://www.abc.net.au/unleashed/41010.html
• [3] https://www.cia.gov/library/publications/the-world-factbook/geos/as.html

You may wonder how I manage to write one Useful but Unknown Unix Something blog posting per day. Well, I don t. I write them in bursts, but don t want to flood Planet Debian and Planet Symlink with more than one such posting a day. The first bunch of postings were mostly slides (or part of a slide plus what I tell while showing the slide) from my Unknown but Useful Unix Tools talk and written somewhen last week. And this blog posting and yesterday s blog posting were written in a row, too. What does that have to do with Unix commandline tools? Well I use Blosxom as blogging engine and it s based on simple text files lounging around in some directories, and the last modification time stamp is the posting s date which is cached after first time seen by the entries_index plugin so that I can fix typos without resetting the posting s release date. Postings with a modification date in the future won t be shown before that time. So how do you set the last modification date to a date in the future? With touch from GNU Coreutils of course. Like date , touch also knows the option -d to explicity set a date and time instead of using the current date and time. Now in my humble opinion the cool feature is that you can easily describe dates by giving touch values like now + 1 hour , 12:00 tomorrow or so:

$ touch bla
$ ls -l
total 0
-rw-r--r-- 1 abe abe 0 2010-11-23 22:59 bla
$ touch -d 'now + 1 day + 23 hours - 42 minutes' bla
$ ls -l
total 0
-rw-r--r-- 1 abe abe 0 2010-11-25 21:17 bla
$

To see all the possibilities you have to describe relative dates with touch , date , and maybe other GNU Coreutils tools, check that you have info installed and call:

$ info '(coreutils.info.gz)Relative items in date strings'

Oh, and this whole story about setting modification dates manually to arbitrary values also means that the Tattletale Statistics: Blogtimes November 2010 image in my blog s side bar is absolute nonsense, at least this month. Well, never trust any statistic you haven t faked yourself. ;-) But on the other hand, the dates in the example may give a hint when I really wrote that blog posting. Or not. ;-) And I wonder what my backup tools think about last modification times in the future. Well, they probably only check for modification dates newer than last backup and therefore should be fine. *phew*

Surprisingly, my Monday blog post has received much more attention than I did expect and was source for at least one article full of speculations (in Czech). Hey, there was no new information in the post, nor some secret information leak (not that I know something what is not known publicly). Anyway meanwhile public announcement about UNIX copyrights has been made. I don't think it changes much, but it seems to be one if things people wanted to know. What I find more interesting (and hard to read and understand) is explanation of the currently publicly available bits from a transactional lawyer at The Standards Blog. At least it gave me basic idea why some things are so complex in this deal and just confirmed that I want to avoid need for contact with lawyers language as much as possible :-).

Filed under: Suse 0 comments Flattr this!

Okay, so it's been five months since the last update. Sorry about that. I guess I could force myself to more regular updates. What have you missed? Only the branching of what will eventually (soon?) become FusionForge 5.1. Quoting from the default home page, and in no particular order:

• New Funky theme.
• New UI and features for the document manager (download as zip, locking, referencing documents by URL).
• New progress bar displaying completion state of trackers using a custom status field.
• Improved sorting in trackers.
• More flexible and more powerful role-based access control system.
• New unobtrusive tooltip system based on JQuery and Tipsy to replace old help window.
• New plugins: Blocks, to add free HTML blocks on top of each tool of the project; Gravatar, to display user faces; OSLC, implementing the OSLC-CM API for tracker interoperability with external tools.
• scmgit plugin: Personal Git repositories for project members.
• Simplified configuration system, using standard *.ini files.
• Reorganised, modular Apache configuration.
• RPM packaging.

We've also added many tests to our testsuite, and we'd welcome more. If you're interested in the new features coming to FusionForge, now would be a good time to try them and report the bugs you find. And if you don't want to upgrade your production server just yet, you can use a VM image that builds and installs everything automatically inside a VirtualBox (or another virtualization system). See details of my VM image for easy testing mailing-list post. That VM covers trunk rather than the 5.1 branch, but since the branching is still rather recent there isn't much difference yet. Another tidbit of information: since I recently realized the IPv4 horizon is less than a hundred days away, I've been engaging in a flurry of migrations from IPv4-only to dual-stack, one result of which is that fusionforge.org is now accessible via IPv6. Yay for less NAT and reverse-proxying. And I think that's it for now. There's one obvious piece of news I'm looking forward to announce, but it has to actually happen first

Colin Watson is not a high-profile Debian figure, you rarely see him on mailing lists but he cares a lot about Debian and you will see him on Debconf videos sharing many thoughtful comments. I have the pleasure to work with him on dpkg as he maintains the package in Ubuntu, but he does a lot of more interesting things. I also took the opportunity to ask some Ubuntu specific questions since he s worked for Canonical since the start. Read on. My questions are in bold, the rest is by Colin. Who are you? Hi. I m 32 years old, grew up in Belfast in Northern Ireland, but have been living in Cambridge, England, since I was 18. I m married with a stepson and a daughter. I became interested in Debian due to the critical mass of Debian work happening in Cambridge at the time (and perhaps more immediately because my roommate was running Debian: hey, what s that? ), started doing random bits of development in 2000, and joined as a developer in 2001 (a really exciting time, with lots of new people joining who became integral parts of the project). I d only really been intending to do QA work and various bits of packaging around the edges, and maybe some work on the BTS, but then Fabrizio Polacco died and I took over man-db from him, and it sort of snowballed from there. I graduated from university shortly before becoming a Debian developer. I worked for a web server company (Zeus), then a hardware cryptography company (nCipher), before moving to work for Canonical in 2004, since when I ve been working full-time on Ubuntu. By this point, I suspect that going back to work in an office every day would be pretty tough. What s your biggest achievement within Debian or Ubuntu? One thing I should say: I rarely start projects. Firstly I don t think I m very good at it, and secondly I much prefer coming on to an existing project and worrying away at all the broken bits, often after other people have got bored and wandered off to the next new and shiny thing. That s probably why I ended up in the GNU/Linux distribution world in the first place, rather than doing lots of upstream development from the start I like being able to polish things into a finished product that we can give to end users. So, I ve had my fingers in a lot of pies over the years, doing ongoing maintenance and fixing lots of bugs. I think the single project I m most proud of would have to be my work on the Debian installer. I joined that team in early 2004 (a few months before Canonical started up) partly because I was a release assistant at the time and it was an obvious hot-spot, and partly because I thought it d be a good idea to make sure it worked well on the shiny new G4 PowerBook I d just treated myself to. I ended up as one of the powerpc d-i port maintainers for a while (no longer, as that machine is dead), but I ve done a lot of core work as well: much of the work to put progress bars in front of absolutely everything that used to have piles of text output, rescue mode, the current kernel selection framework, a good deal of udev support, several significant debconf extensions, lots of os-prober work, and I think I can claim to be one of the few people who understands the partitioner almost top to bottom. d-i is the very first thing many of our users see, and has a huge range of uses, from simple desktop installs to massive corporate deployments; it s unspeakably important that it works well, and it s a testament to its design that it s been able to trundle along without actually very much serious refactoring for the best part of five years now. I have a soft spot for man-db too. It was my first major project in Debian, starting out from an embarrassingly broken state, and is now nice and stable to the point where I recently had time to spawn a useful generic library out of it (libpipeline). What are your plans for Debian Wheezy? d-i has a lot of code to deal with disks and partitions. Of course a lot of it is in the partitioner, and for that we use libparted so we don t have to worry very much about the minutiae of device naming. But there are several other cases where we do need to care about naming, mainly before the partitioner when detecting disks, and after the partitioner when installing the boot loader. Back in etch, we introduced list-devices , which abstracted away the disk naming assumptions involved in hardware detection. In wheezy, I would like to take all the messy, duplicated, and error-prone code that handles disk naming in the boot loader installers, and design a simple interface to cover all of them. This has only got more important following the addition of the kFreeBSD and Hurd d-i ports in squeeze, but it bites us every time we notice that, say, CCISS arrays aren t handled consistently, and it s a pain to test all that duplicated code. I d also like to spread the use of libpipeline through C programs in the archive, which I think has potential to eliminate a class of security vulnerabilities in a much simpler way than was previously available. If you could spend all your time on Debian, what would you work on? I would love to systematically reduce the need for the current mass of boot loaders. There s a significant cost to having so much variation across architectures here: it s work that needs to be done in N different places, the wildly differing configuration means that d-i has to have huge piles of code to manage them all differently, and there are a bunch of strange arbitrary limitations on what you can do. The reason I m working on GRUB 2 is that, in my view, it s the project with the best chance of centralising all this duplicated work into a single place, and making it easier to bring up new hardware in future (in a way that doesn t compromise software freedom, as many proprietary boot loaders of the kind often found on phones do). Of course, with flexibility tends to come complexity, and some people have a natural objection to that and prefer something simpler. The things I don t quite have time to do here are to figure out a coherent way to address the specific over-complexity problems people have with the configuration framework while still keeping the flexibility we need, and to do enough QA and porting work to be able to roll out GRUB 2 at installation time to all the Debian architectures it theoretically supports. What s the biggest problem of Debian? Backbiting, and too much playing the man rather than the ball. With one or two honourable exceptions, I ve largely stopped reading most Debian mailing lists since it just never seems a productive way to spend time compared to writing code and fixing bugs; and yet I m conscious that they re one of the primary means of communication for the project and I m derelict in not taking part in them. I do find it a bit frustrating that people are seen primarily in terms of their affiliations. I suppose it s natural for people to see me as an Ubuntu guy , but I don t really see myself that way: I ve been working on Debian for nearly twice as long as I ve been working on Ubuntu, and, while I care a great deal about both projects, I ve put far more of my own personal time into Debian and I try to make sure that a decent number of the things I m involved with there aren t to do with work. Work/life separation is a good thing, not that I m very good at it. Generally speaking, when I m working on Debian, I m doing so as a Debian developer, because I want Debian to be better. When that s not the case, if it matters, I try to indicate it explicitly. You re working for Canonical since Ubuntu s inception. If you were Mark Shuttleworth, is there something that you would have done differently? We had many good intentions when we founded Ubuntu. We also had a huge amount of work to deliver, to the point where it wasn t at all clear whether it would be possible (the warty release was named based on the expectations of it, after all, and came out much more usable than we d dared to hope). In hindsight, it might have helped to be quieter about our good intentions, so that we could exceed expectations rather than in some cases failing to meet them. That might have set a very different tone early on. (Personally, I m happy I m not Mark. The decisions in my office are much easier to take.) It seems to me that the community part of Ubuntu is much more eager to cooperate with Debian than the corporate part. It s probably just that more and more Canonical employees are not former Debian contributors. Do you also have this feeling? Are there processes in place to ensure everybody at Canonical is trying to do the right thing towards Debian cooperation? Just to be clear, I m wearing my own hat here which, ironically, is a fedora rather than a company hat. It makes sense for Canonical to be taking on more non-Debian folks; after all, we can t simply hire from the Debian community forever, and a variety of backgrounds is healthy. As you say, it may well be natural that Ubuntu developers who don t work for Canonical are more likely to have a Debianish background, as it tends to take something significant to get people to switch to a very different family of GNU/Linux distributions, and changing jobs is one of the most obvious of those things. Certainly, there was a definite sense among the early developers that we were all part of the Debian family and cared about the success of Debian as well. As Ubuntu has developed its own identity, people involved in it now tend to care primarily about the success of Ubuntu. At the same time, pragmatically, it s still true that getting code changes into Debian is one of the most economical ways to land them; changes made in Debian or upstream land once and tend to stay in place, while changes made only in Ubuntu incur an ongoing merge overhead, which is not at all trivial. In many ways it s human nature to try to fulfil your immediate goals in the most direct way possible. If your goal is to deliver changes to Ubuntu users, then it s natural to concentrate on that rather than looking at the bigger picture (which takes experience). Debian developers often fail to send changes upstream for much the same reason, although there s more variation there because they re normally working on Debian of their own volition and thus tend to have wider goals; the economics are more or less parallel though. Thus, I think the best way to improve things is to make it the path of least resistance for Ubuntu developers to send changes to Debian. We re already seeing how this works with the Ubuntu MOTU group; if you send a patch for review, or work on merging a package from Debian, very often the response includes have you sent these changes to Debian? . We re working on both streamlining our code review through a regular patch pilot programme and requiring more code review for changes in general, so I think this will be a good opportunity to ask more people to work with Debian when they propose changes to Ubuntu. For myself, this may be obvious, but I notice that I m much better at getting changes into Debian when I already have commit access to the Debian package in question. All the work on improving collaborative maintenance in Debian can only help, for Ubuntu as well as for everyone else. It doesn t make so much difference for large changes that require extensive discussion, but there are lots of small changes too. Canonical is upstream of many software projects (unity, indicators infrastructure, etc.). Why aren t those software immediately packaged in Debian? Do you think we can get this to change? I m not sure what the right approach is here, particularly as I haven t been involved with much of that on the Ubuntu side. I suspect it would be helpful to look at this in a similar way to Ubuntu changes in general. It s understandable that those developers have getting changes into Ubuntu as their first goal. And yet, having code in Debian offers a wider, and often technically adept, audience, and most developers like having their code reach a wider audience even if it s not their first priority, particularly if that audience is likely to be able to help with finding problems and fixing bugs. It should be seen as something beneficial to both distributions. The hardest problems will be with things that aren t merely optional add-ons (which should generally be fairly non-controversial in Debian, given the breadth of the archive in general the existence of things like bzr and germinate as Debian packages was never a hard question), but which require changes in established packages. For example, gnome-power-manager in Ubuntu is built with application indicator support, and that s an important part of having a good indicator-based panel: a lot of the point of indicators is consistency. Since I do very little desktop work myself, I don t know exactly what would be involved in making it possible to choose this system based on a Debian desktop, but I think it s probably a bit more complicated than just making sure all the new packages exist in Debian too. Obviously you have to start somewhere. Is there someone in Debian that you admire for his contributions? Christian Perrier is absolutely tireless and has done superb things for the state of translations in Debian. And Russ Allbery, even aside from his fine ongoing work on policy, Lintian, and Kerberos, is a constant voice of sanity and calmness. Release management is incredibly hard work, as I know from my own experience, and anyone who can sustain involvement in it for a long period is somebody pretty special. Steve Langasek and I got involved at about the same time but he outlasted me by quite a few years. He deserves some kind of medal for everything he s done there.

---

Thank you to Colin for the time spent answering my questions. I hope you enjoyed reading his answers as I did. Subscribe to my newsletter to get my monthly summary of the Debian/Ubuntu news and to not miss further interviews. You can also follow along on Identi.ca, Twitter and Facebook.

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

After Samba XP 2008 Andrew and I started keeping a wiki page with our bi-weekly goals and achievements for Samba 4. Because planning in a Free Software project is hard (time availability and priorities change over time, and other volunteers are equally unpredictable) we called this our "Fantasy page"; it listed things we wanted to work on next ("fantasies"), but reality being what it is we would usually actually end up working on something entirely different. We discussed our progress and new plans in - what I would now call - a bi-weekly standup call. There were several reasons for doing this. It gave us some sense of direction as well as a sense of accomplishment; a way to look back at the end of the year and realize how much we had actually achieved. Because Samba 4 is such a long term project (it is 7 years old at this point) it is easy to become disillusioned, to look back at a year of commits and to not see the gradual improvement, just the fact that there is no release yet. We managed to keep this up for two years, much longer than I had anticipated, and eventually started to slip last year. More recently Kai and Tridge have started to blog weekly about their efforts to make Samba 4.0 a reality and I'm going to join them by trying to blog regularly - every two weeks - about my contributions, even if there were none. In the next two weeks I plan to work on finally getting alpha 14 of Samba 4 out and on fixing the daily builds of Samba 4 and OpenChange for Ubuntu on Launchpad after we did a massive reorganization of the private libraries in Samba 4. cp: Zero 7 - Somersault

For those who are not aware, The Archers is a soap opera about rural life, broadcast on BBC Radio 4. Its website has recently been revamped. Unfortunately, I appear to be served the mobile version when I visit the front page (in all of Chromium, Iceweasel and Epiphany on Debian - admittedly not the most mainstream of browsers). BBC Mobile is doing some over-zealous useragent sniffing, it seems. Also amusing: there's a "Who's Who" database of Archers characters, and several of them share the birthday "1st Jan 1970". There was I thinking that Harry Mason and Fallon Rogers had a 15 year age gap... but no. This will be as a result of the underlying database storing values in Unix time, and having a default value of "0". An explanation of Unix time popped up in an episode of The Infinite Monkey Cage the other week, which was nice to hear.

using GNOME with Awesome without die trying I'm an avid GNOME user, but I don't want to give up tiling due to that. After 1.5 years with xmonad+GNOME, I've decided it was about time to give Awesome another try. Last time I tried, integration with GNOME was really sub-optimal; in particular I've been it by the showstopping (for me) issue that it was not possible, back then, to disable Awesome systray in favor of GNOME's. Nowadays, GNOME+Awesome integration is much better. It's very easy to disable all you don't want of Awesome (including systray) to rely upon corresponding GNOME desktop components (check my rc.lua for an example). Still, by renouncing Wibox in favor of GNOME Panel, you (used to) lack some features: (1) the ability to monitor the current layout, (2) (GNOME) run application prompt, and (3) Lua code prompt. It is to overcome these limitations that I've hacked GNOME Awesome Applet. Version 0.1.0 is now available for download from the homepage. It's beta-quality and it's the first (hopefully last?) GNOME Applet I've ever written, you know the drill. Feedback, bug reports, features requests, and code patches are more than welcome. Enjoy!

I ve never quit a job before. Well, not a real job. Quitting PC World was more than easy, it was practically required for my soul not to leave my body. Quitting Waitrose was, well, it was a freaking supermarket job. And Southampton football stadium I just stopped turning up after one girl fainted in the kitchen from heat exhaustion. But a real, proper handing in of notice is something new in no small part because I ve been in the same place since my first job as a new graduate. Not that I m ungrateful, mind. Looking after big iron at the University of Oxford has been pretty awesome more blinky lights than you can shake a stick at but there comes a time when you need to think about your career, and move on to pastures new. I m fairly sure six and a bit years is WELL past that point. When I started looking at work, I had only a few mandatory criteria a sysadmin job, working with Free Software, without any significant decrease to my monthly income. Beyond that well, in this economy, who am I to argue? What I hadn t accounted for, however, was a job whose awesomeness can t be contained. A job with a dedicated Free Software company whose entire staff roster, top to bottom, is filled with the most talented, smart, and generally awesome people you could hope to work with. Such a job would be a fevered dream, the mere ramblings of a madman. Yet, somehow, for the second time running, I find myself in an enviable job, working exclusively on Free Software. Being able to show off root access to a box with 256 cores and a tibibyte of RAM is pretty cool. But you know what s even cooler? A job where I never need to worry about openSUSE 10.1 administration ever again. A job where several of my colleagues are fellow Debian Developers, with all the prestige and knowledge that comes with such a title. And somehow, by rolling proverbial twenties, I find myself in that position. I am very, VERY proud to say that from the start of January, I ll be joining Collabora Ltd as their new Systems Manager.

Michael Biebl suggested to me on IRC, that I changed my automated upgrade testing of the Lenny Gnome and KDE Desktop to do apt-get autoremove when using apt-get. This seem like a very good idea, so I adjusted by test scripts and can now present the updated result from today: This is for Gnome: Installed using apt-get, missing with aptitude

apache2.2-bin aptdaemon baobab binfmt-support browser-plugin-gnash cheese-common cli-common cups-pk-helper dmz-cursor-theme empathy empathy-common freedesktop-sound-theme freeglut3 gconf-defaults-service gdm-themes gedit-plugins geoclue geoclue-hostip geoclue-localnet geoclue-manual geoclue-yahoo gnash gnash-common gnome gnome-backgrounds gnome-cards-data gnome-codec-install gnome-core gnome-desktop-environment gnome-disk-utility gnome-screenshot gnome-search-tool gnome-session-canberra gnome-system-log gnome-themes-extras gnome-themes-more gnome-user-share gstreamer0.10-fluendo-mp3 gstreamer0.10-tools gtk2-engines gtk2-engines-pixbuf gtk2-engines-smooth hamster-applet libapache2-mod-dnssd libapr1 libaprutil1 libaprutil1-dbd-sqlite3 libaprutil1-ldap libart2.0-cil libboost-date-time1.42.0 libboost-python1.42.0 libboost-thread1.42.0 libchamplain-0.4-0 libchamplain-gtk-0.4-0 libcheese-gtk18 libclutter-gtk-0.10-0 libcryptui0 libdiscid0 libelf1 libepc-1.0-2 libepc-common libepc-ui-1.0-2 libfreerdp-plugins-standard libfreerdp0 libgconf2.0-cil libgdata-common libgdata7 libgdu-gtk0 libgee2 libgeoclue0 libgexiv2-0 libgif4 libglade2.0-cil libglib2.0-cil libgmime2.4-cil libgnome-vfs2.0-cil libgnome2.24-cil libgnomepanel2.24-cil libgpod-common libgpod4 libgtk2.0-cil libgtkglext1 libgtksourceview2.0-common libmono-addins-gui0.2-cil libmono-addins0.2-cil libmono-cairo2.0-cil libmono-corlib2.0-cil libmono-i18n-west2.0-cil libmono-posix2.0-cil libmono-security2.0-cil libmono-sharpzip2.84-cil libmono-system2.0-cil libmtp8 libmusicbrainz3-6 libndesk-dbus-glib1.0-cil libndesk-dbus1.0-cil libopal3.6.8 libpolkit-gtk-1-0 libpt2.6.7 libpython2.6 librpm1 librpmio1 libsdl1.2debian libsrtp0 libssh-4 libtelepathy-farsight0 libtelepathy-glib0 libtidy-0.99-0 media-player-info mesa-utils mono-2.0-gac mono-gac mono-runtime nautilus-sendto nautilus-sendto-empathy p7zip-full pkg-config python-aptdaemon python-aptdaemon-gtk python-axiom python-beautifulsoup python-bugbuddy python-clientform python-coherence python-configobj python-crypto python-cupshelpers python-elementtree python-epsilon python-evolution python-feedparser python-gdata python-gdbm python-gst0.10 python-gtkglext1 python-gtksourceview2 python-httplib2 python-louie python-mako python-markupsafe python-mechanize python-nevow python-notify python-opengl python-openssl python-pam python-pkg-resources python-pyasn1 python-pysqlite2 python-rdflib python-serial python-tagpy python-twisted-bin python-twisted-conch python-twisted-core python-twisted-web python-utidylib python-webkit python-xdg python-zope.interface remmina remmina-plugin-data remmina-plugin-rdp remmina-plugin-vnc rhythmbox-plugin-cdrecorder rhythmbox-plugins rpm-common rpm2cpio seahorse-plugins shotwell software-center system-config-printer-udev telepathy-gabble telepathy-mission-control-5 telepathy-salut tomboy totem totem-coherence totem-mozilla totem-plugins transmission-common xdg-user-dirs xdg-user-dirs-gtk xserver-xephyr

Installed using apt-get, removed with aptitude

cheese ekiga eog epiphany-extensions evolution-exchange fast-user-switch-applet file-roller gcalctool gconf-editor gdm gedit gedit-common gnome-games gnome-games-data gnome-nettool gnome-system-tools gnome-themes gnuchess gucharmap guile-1.8-libs libavahi-ui0 libdmx1 libgalago3 libgtk-vnc-1.0-0 libgtksourceview2.0-0 liblircclient0 libsdl1.2debian-alsa libspeexdsp1 libsvga1 rhythmbox seahorse sound-juicer system-config-printer totem-common transmission-gtk vinagre vino

Installed using aptitude, missing with apt-get

gstreamer0.10-gnomevfs

Installed using aptitude, removed with apt-get

[nothing]

This is for KDE: Installed using apt-get, missing with aptitude

ksmserver

Installed using apt-get, removed with aptitude

kwin network-manager-kde

Installed using aptitude, missing with apt-get

arts dolphin freespacenotifier google-gadgets-gst google-gadgets-xul kappfinder kcalc kcharselect kde-core kde-plasma-desktop kde-standard kde-window-manager kdeartwork kdeartwork-emoticons kdeartwork-style kdeartwork-theme-icon kdebase kdebase-apps kdebase-workspace kdebase-workspace-bin kdebase-workspace-data kdeeject kdelibs kdeplasma-addons kdeutils kdewallpapers kdf kfloppy kgpg khelpcenter4 kinfocenter konq-plugins-l10n konqueror-nsplugins kscreensaver kscreensaver-xsavers ktimer kwrite libgle3 libkde4-ruby1.8 libkonq5 libkonq5-templates libnetpbm10 libplasma-ruby libplasma-ruby1.8 libqt4-ruby1.8 marble-data marble-plugins netpbm nuvola-icon-theme plasma-dataengines-workspace plasma-desktop plasma-desktopthemes-artwork plasma-runners-addons plasma-scriptengine-googlegadgets plasma-scriptengine-python plasma-scriptengine-qedje plasma-scriptengine-ruby plasma-scriptengine-webkit plasma-scriptengines plasma-wallpapers-addons plasma-widget-folderview plasma-widget-networkmanagement ruby sweeper update-notifier-kde xscreensaver-data-extra xscreensaver-gl xscreensaver-gl-extra xscreensaver-screensaver-bsod

Installed using aptitude, removed with apt-get

ark google-gadgets-common google-gadgets-qt htdig kate kdebase-bin kdebase-data kdepasswd kfind klipper konq-plugins konqueror ksysguard ksysguardd libarchive1 libcln6 libeet1 libeina-svn-06 libggadget-1.0-0b libggadget-qt-1.0-0b libgps19 libkdecorations4 libkephal4 libkonq4 libkonqsidebarplugin4a libkscreensaver5 libksgrd4 libksignalplotter4 libkunitconversion4 libkwineffects1a libmarblewidget4 libntrack-qt4-1 libntrack0 libplasma-geolocation-interface4 libplasmaclock4a libplasmagenericshell4 libprocesscore4a libprocessui4a libqalculate5 libqedje0a libqtruby4shared2 libqzion0a libruby1.8 libscim8c2a libsmokekdecore4-3 libsmokekdeui4-3 libsmokekfile3 libsmokekhtml3 libsmokekio3 libsmokeknewstuff2-3 libsmokeknewstuff3-3 libsmokekparts3 libsmokektexteditor3 libsmokekutils3 libsmokenepomuk3 libsmokephonon3 libsmokeplasma3 libsmokeqtcore4-3 libsmokeqtdbus4-3 libsmokeqtgui4-3 libsmokeqtnetwork4-3 libsmokeqtopengl4-3 libsmokeqtscript4-3 libsmokeqtsql4-3 libsmokeqtsvg4-3 libsmokeqttest4-3 libsmokeqtuitools4-3 libsmokeqtwebkit4-3 libsmokeqtxml4-3 libsmokesolid3 libsmokesoprano3 libtaskmanager4a libtidy-0.99-0 libweather-ion4a libxklavier16 libxxf86misc1 okteta oxygencursors plasma-dataengines-addons plasma-scriptengine-superkaramba plasma-widget-lancelot plasma-widgets-addons plasma-widgets-workspace polkit-kde-1 ruby1.8 systemsettings update-notifier-common

Running apt-get autoremove made the results using apt-get and aptitude a bit more similar, but there are still quite a lott of differences. I have no idea what packages should be installed after the upgrade, but hope those that do can have a look.

I have been asked how Ubuntu relates to Debian, and how packages flow from one to the other. So here s my attempt at clarifying the whole picture.

Where do the packages come from? Most packages are created by Debian contributors and they are uploaded in Debian unstable (or Debian experimental). New packages are reviewed by the Debian ftpmasters before being accepted in the official archive. The packages are held in the NEW queue until the review is over, and the time spent there varies between a few hours and a few months (usually they are processed within one week or two). Ubuntu imports all the official Debian packages, but they also add some packages of their own. About 7% of the Ubuntu packages are third-party software that have been packaged for Ubuntu but not for Debian. What are the changes made by Ubuntu? From all the source packages coming from Debian, 17% have additional changes made by Ubuntu. Many of them are part of the main repository, which is actively maintained by Canonical and Ubuntu core developers. The universe repository is usually closer to the official Debian packages. Many of the changes made by Ubuntu are the results of the decisions taken during the Ubuntu Developer Summit in order to reach specific goals: provide a better user interface, offer faster boot times, become a better platform for third-party software developers, offer a good integration with their online services (Launchpad, Ubuntu One), etc. Other changes are simply the result of fixing bugs reported by Ubuntu users. Note that even non-modified source packages will result in different binary packages for Ubuntu. That s because Ubuntu has made changes to the build environment. They only support Intel-based computers with a 686-class (or newer) CPU, they enable some compiler options that Debian doesn t, etc. And all binary packages are modified by a program called pkgbinarymangler. Ubuntu s release cycle and the relation with Debian Ubuntu releases every 6 months (that s what time based releases is about). Debian has a very different schedule. How does Ubuntu manage to reuse Debian s work? Ubuntu imports packages from Debian unstable (even experimental sometimes) to get the newest packages. If the Ubuntu package already has Ubuntu-specific changes, they merge their changes in the updated Debian package. Otherwise the Debian package is simply grabbed and rebuilt in Ubuntu. This works well because Debian unstable is much more usable than the name suggests. And this process only goes on during the first 2 months of the cycle (until the Debian Import Freeze), so there s plenty of time afterward to fix the biggest problems. In the third and fourth month, it s still possible to pick updated packages from Debian but it must be requested by a developer, it won t be done automatically. At the end of the fourth month, the feature freeze is put in place. The 2 months left are dedicated to bug fixing and polishing the distribution. There are various sub-freezes that happen in this period, you can check the Natty release schedule as an example. Picking updated packages from Debian is now the exception, it will only be allowed if the update on the Debian side is a bug-fix only release. Credits: some figures taken from a talk of Lucas Nussbaum, they were collected based on the packages available in the Lucid Lynx release of Ubuntu. Click here to subscribe to my newsletter and get my monthly update on what s going on in Debian and Ubuntu.

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

Ever wondered how to test or connect to a WebDAV server on the commandline? Don t want to use a bloaty GUI file manager to connect to a WebDAV server? Then use cadaver (Debian package), a WebDAV client reminiscent of the classic ftp commandline client (plus tab completion :-).

$ cadaver https://webdav.phys.ethz.ch/unixhome/abe/vortraege
Authentication required for D-PHYS on server  webdav.phys.ethz.ch':
Username: abe
Password: 
dav:/unixhome/abe/vortraege/> ls
Listing collection  /unixhome/abe/vortraege/': succeeded.
Coll:   wml                                    0  Mar 13  2007
dav:/unixhome/abe/vortraege/> quit
Connection to  webdav.phys.ethz.ch' closed.

There is also nd which works more like ncftpget/ncftpput/wget/wput, but I didn t get the current version in Debian to work with our WebDAV server. Last time I used nd was back then at ECOS times more than half a decade ago.

I'm still running upgrade testing of the Lenny Gnome and KDE Desktop, but have not had time to spend on reporting the status. Here is a short update based on a test I ran 20101118. I still do not know what a correct migration should look like, so I report any differences between apt and aptitude and hope someone else can see if anything should be changed. This is for Gnome: Installed using apt-get, missing with aptitude

apache2.2-bin aptdaemon at-spi baobab binfmt-support browser-plugin-gnash cheese-common cli-common cpp-4.3 cups-pk-helper dmz-cursor-theme empathy empathy-common finger freedesktop-sound-theme freeglut3 gconf-defaults-service gdm-themes gedit-plugins geoclue geoclue-hostip geoclue-localnet geoclue-manual geoclue-yahoo gnash gnash-common gnome gnome-backgrounds gnome-cards-data gnome-codec-install gnome-core gnome-desktop-environment gnome-disk-utility gnome-screenshot gnome-search-tool gnome-session-canberra gnome-spell gnome-system-log gnome-themes-extras gnome-themes-more gnome-user-share gs-common gstreamer0.10-fluendo-mp3 gstreamer0.10-tools gtk2-engines gtk2-engines-pixbuf gtk2-engines-smooth hal-info hamster-applet libapache2-mod-dnssd libapr1 libaprutil1 libaprutil1-dbd-sqlite3 libaprutil1-ldap libart2.0-cil libatspi1.0-0 libboost-date-time1.42.0 libboost-python1.42.0 libboost-thread1.42.0 libchamplain-0.4-0 libchamplain-gtk-0.4-0 libcheese-gtk18 libclutter-gtk-0.10-0 libcryptui0 libcupsys2 libdiscid0 libeel2-data libelf1 libepc-1.0-2 libepc-common libepc-ui-1.0-2 libfreerdp-plugins-standard libfreerdp0 libgail-common libgconf2.0-cil libgdata-common libgdata7 libgdl-1-common libgdu-gtk0 libgee2 libgeoclue0 libgexiv2-0 libgif4 libglade2.0-cil libglib2.0-cil libgmime2.4-cil libgnome-vfs2.0-cil libgnome2.24-cil libgnomepanel2.24-cil libgnomeprint2.2-data libgnomeprintui2.2-common libgnomevfs2-bin libgpod-common libgpod4 libgtk2.0-cil libgtkglext1 libgtksourceview-common libgtksourceview2.0-common libmono-addins-gui0.2-cil libmono-addins0.2-cil libmono-cairo2.0-cil libmono-corlib2.0-cil libmono-i18n-west2.0-cil libmono-posix2.0-cil libmono-security2.0-cil libmono-sharpzip2.84-cil libmono-system2.0-cil libmtp8 libmusicbrainz3-6 libndesk-dbus-glib1.0-cil libndesk-dbus1.0-cil libopal3.6.8 libpolkit-gtk-1-0 libpt-1.10.10-plugins-alsa libpt-1.10.10-plugins-v4l libpt2.6.7 libpython2.6 librpm1 librpmio1 libsdl1.2debian libservlet2.4-java libsrtp0 libssh-4 libtelepathy-farsight0 libtelepathy-glib0 libtidy-0.99-0 libxalan2-java libxerces2-java media-player-info mesa-utils mono-2.0-gac mono-gac mono-runtime nautilus-sendto nautilus-sendto-empathy openoffice.org-writer2latex openssl-blacklist p7zip p7zip-full pkg-config python-4suite-xml python-aptdaemon python-aptdaemon-gtk python-axiom python-beautifulsoup python-bugbuddy python-clientform python-coherence python-configobj python-crypto python-cupshelpers python-cupsutils python-eggtrayicon python-elementtree python-epsilon python-evolution python-feedparser python-gdata python-gdbm python-gst0.10 python-gtkglext1 python-gtkmozembed python-gtksourceview2 python-httplib2 python-louie python-mako python-markupsafe python-mechanize python-nevow python-notify python-opengl python-openssl python-pam python-pkg-resources python-pyasn1 python-pysqlite2 python-rdflib python-serial python-tagpy python-twisted-bin python-twisted-conch python-twisted-core python-twisted-web python-utidylib python-webkit python-xdg python-zope.interface remmina remmina-plugin-data remmina-plugin-rdp remmina-plugin-vnc rhythmbox-plugin-cdrecorder rhythmbox-plugins rpm-common rpm2cpio seahorse-plugins shotwell software-center svgalibg1 system-config-printer-udev telepathy-gabble telepathy-mission-control-5 telepathy-salut tomboy totem totem-coherence totem-mozilla totem-plugins transmission-common xdg-user-dirs xdg-user-dirs-gtk xserver-xephyr zip

Installed using apt-get, removed with aptitude

arj bluez-utils cheese dhcdbd djvulibre-desktop ekiga eog epiphany-extensions epiphany-gecko evolution-exchange fast-user-switch-applet file-roller gcalctool gconf-editor gdm gedit gedit-common gnome-app-install gnome-games gnome-games-data gnome-nettool gnome-system-tools gnome-themes gnome-utils gnome-vfs-obexftp gnome-volume-manager gnuchess gucharmap guile-1.8-libs hal libavahi-compat-libdnssd1 libavahi-core5 libavahi-ui0 libbind9-50 libbluetooth2 libcamel1.2-11 libcdio7 libcucul0 libcurl3 libdirectfb-1.0-0 libdmx1 libdvdread3 libedata-cal1.2-6 libedataserver1.2-9 libeel2-2.20 libepc-1.0-1 libepc-ui-1.0-1 libexchange-storage1.2-3 libfaad0 libgadu3 libgalago3 libgd2-noxpm libgda3-3 libgda3-common libggz2 libggzcore9 libggzmod4 libgksu1.2-0 libgksuui1.0-1 libgmyth0 libgnome-desktop-2 libgnome-pilot2 libgnomecups1.0-1 libgnomeprint2.2-0 libgnomeprintui2.2-0 libgpod3 libgraphviz4 libgtk-vnc-1.0-0 libgtkhtml2-0 libgtksourceview1.0-0 libgtksourceview2.0-0 libgucharmap6 libhesiod0 libicu38 libisccc50 libisccfg50 libiw29 libjaxp1.3-java-gcj libkpathsea4 liblircclient0 libltdl3 liblwres50 libmagick++10 libmagick10 libmalaga7 libmozjs1d libmpfr1ldbl libmtp7 libmysqlclient15off libnautilus-burn4 libneon27 libnm-glib0 libnm-util0 libopal-2.2 libosp5 libparted1.8-10 libpisock9 libpisync1 libpoppler-glib3 libpoppler3 libpt-1.10.10 libraw1394-8 libsdl1.2debian-alsa libsensors3 libsexy2 libsmbios2 libsoup2.2-8 libspeexdsp1 libssh2-1 libsuitesparse-3.1.0 libsvga1 libswfdec-0.6-90 libtalloc1 libtotem-plparser10 libtrackerclient0 libvoikko1 libxalan2-java-gcj libxerces2-java-gcj libxklavier12 libxtrap6 libxxf86misc1 libzephyr3 mysql-common rhythmbox seahorse sound-juicer swfdec-gnome system-config-printer totem-common totem-gstreamer transmission-gtk vinagre vino w3c-dtd-xhtml wodim

Installed using aptitude, missing with apt-get

gstreamer0.10-gnomevfs

Installed using aptitude, removed with apt-get

[nothing]

This is for KDE: Installed using apt-get, missing with aptitude

autopoint bomber bovo cantor cantor-backend-kalgebra cpp-4.3 dcoprss edict espeak espeak-data eyesapplet fifteenapplet finger gettext ghostscript-x git gnome-audio gnugo granatier gs-common gstreamer0.10-pulseaudio indi kaddressbook-plugins kalgebra kalzium-data kanjidic kapman kate-plugins kblocks kbreakout kbstate kde-icons-mono kdeaccessibility kdeaddons-kfile-plugins kdeadmin-kfile-plugins kdeartwork-misc kdeartwork-theme-window kdeedu kdeedu-data kdeedu-kvtml-data kdegames kdegames-card-data kdegames-mahjongg-data kdegraphics-kfile-plugins kdelirc kdemultimedia-kfile-plugins kdenetwork-kfile-plugins kdepim-kfile-plugins kdepim-kio-plugins kdessh kdetoys kdewebdev kdiamond kdnssd kfilereplace kfourinline kgeography-data kigo killbots kiriki klettres-data kmoon kmrml knewsticker-scripts kollision kpf krosspython ksirk ksmserver ksquares kstars-data ksudoku kubrick kweather libasound2-plugins libboost-python1.42.0 libcfitsio3 libconvert-binhex-perl libcrypt-ssleay-perl libdb4.6++ libdjvulibre-text libdotconf1.0 liberror-perl libespeak1 libfinance-quote-perl libgail-common libgsl0ldbl libhtml-parser-perl libhtml-tableextract-perl libhtml-tagset-perl libhtml-tree-perl libio-stringy-perl libkdeedu4 libkdegames5 libkiten4 libkpathsea5 libkrossui4 libmailtools-perl libmime-tools-perl libnews-nntpclient-perl libopenbabel3 libportaudio2 libpulse-browse0 libservlet2.4-java libspeechd2 libtiff-tools libtimedate-perl libunistring0 liburi-perl libwww-perl libxalan2-java libxerces2-java lirc luatex marble networkstatus noatun-plugins openoffice.org-writer2latex palapeli palapeli-data parley parley-data poster psutils pulseaudio pulseaudio-esound-compat pulseaudio-module-x11 pulseaudio-utils quanta-data rocs rsync speech-dispatcher step svgalibg1 texlive-binaries texlive-luatex ttf-sazanami-gothic

Installed using apt-get, removed with aptitude

amor artsbuilder atlantik atlantikdesigner blinken bluez-utils cvs dhcdbd djvulibre-desktop imlib-base imlib11 kalzium kanagram kandy kasteroids katomic kbackgammon kbattleship kblackbox kbounce kbruch kcron kdat kdemultimedia-kappfinder-data kdeprint kdict kdvi kedit keduca kenolaba kfax kfaxview kfouleggs kgeography kghostview kgoldrunner khangman khexedit kiconedit kig kimagemapeditor kitchensync kiten kjumpingcube klatin klettres klickety klines klinkstatus kmag kmahjongg kmailcvt kmenuedit kmid kmilo kmines kmousetool kmouth kmplot knetwalk kodo kolf kommander konquest kooka kpager kpat kpdf kpercentage kpilot kpoker kpovmodeler krec kregexpeditor kreversi ksame ksayit kshisen ksig ksim ksirc ksirtet ksmiletris ksnake ksokoban kspaceduel kstars ksvg ksysv kteatime ktip ktnef ktouch ktron kttsd ktuberling kturtle ktux kuickshow kverbos kview kviewshell kvoctrain kwifimanager kwin kwin4 kwordquiz kworldclock kxsldbg libakode2 libarts1-akode libarts1-audiofile libarts1-mpeglib libarts1-xine libavahi-compat-libdnssd1 libavahi-core5 libavc1394-0 libbind9-50 libbluetooth2 libboost-python1.34.1 libcucul0 libcurl3 libcvsservice0 libdirectfb-1.0-0 libdjvulibre21 libdvdread3 libfaad0 libfreebob0 libgd2-noxpm libgraphviz4 libgsmme1c2a libgtkhtml2-0 libicu38 libiec61883-0 libindex0 libisccc50 libisccfg50 libiw29 libjaxp1.3-java-gcj libk3b3 libkcal2b libkcddb1 libkdeedu3 libkdegames1 libkdepim1a libkgantt0 libkleopatra1 libkmime2 libkpathsea4 libkpimexchange1 libkpimidentities1 libkscan1 libksieve0 libktnef1 liblockdev1 libltdl3 liblwres50 libmagick10 libmimelib1c2a libmodplug0c2 libmozjs1d libmpcdec3 libmpfr1ldbl libneon27 libnm-util0 libopensync0 libpisock9 libpoppler-glib3 libpoppler-qt2 libpoppler3 libraw1394-8 librss1 libsensors3 libsmbios2 libssh2-1 libsuitesparse-3.1.0 libswfdec-0.6-90 libtalloc1 libxalan2-java-gcj libxerces2-java-gcj libxtrap6 lskat mpeglib network-manager-kde noatun pmount tex-common texlive-base texlive-common texlive-doc-base texlive-fonts-recommended tidy ttf-dustin ttf-kochi-gothic ttf-sjfonts

Installed using aptitude, missing with apt-get

dolphin kde-core kde-plasma-desktop kde-standard kde-window-manager kdeartwork kdebase kdebase-apps kdebase-workspace kdebase-workspace-bin kdebase-workspace-data kdeutils kscreensaver kscreensaver-xsavers libgle3 libkonq5 libkonq5-templates libnetpbm10 netpbm plasma-widget-folderview plasma-widget-networkmanagement xscreensaver-data-extra xscreensaver-gl xscreensaver-gl-extra xscreensaver-screensaver-bsod

Installed using aptitude, removed with apt-get

kdebase-bin konq-plugins konqueror

About six years ago, I spent a chunk of my very first salary on a portable music player, the iRiver H140, a relatively bulky and large hard-disk based player, with a capacity of 40G. Uniquely for music players before or since, the iRiver features both digital and analogue line ins and outs. It also has (more common) recording facilities and an FM tuner, the latter of which I used a great deal (and rules out just about all the iPods). This remarkable player has lasted nearly six years of moderate daily use. For the majority of that time, I've ran the rockbox open source firmware on the player, which has provided me with really wide codec support and excellent recording facilities. In the last month I finally had to replace the iRiver. I bought a Sansa Fuze player, featuring 8G of flash storage and a microsd expansion slot. The Fuze is also capable of running rockbox. This year, 32G microsd cards have arrived. Adding one of those brings the capacity of the new player right back up to 40G. For those who are curious: yes, a Sandisk 32G microsd does work in the Fuze, at least with rockbox, for playback. At the moment, rockbox cannot write to storage on the Fuze, so you need to either use the original firmware or an external reader/writer to manipulate the contents of the microsd. However, I am not sure how well the original firmware can handle the 32G. Whenever I boot it, I see a "refreshing your media" message which lasts longer than my patience. I will write an update once I've established further the degree of support. I kept a canonical copy of my music library on a desktop computer and used rsync to keep the iRiver up-to-date. I can use almost exactly the same procedure for the new player (with some small changes to cope with the split-storage) I now have a 40G player running rockbox exactly as I had before, albeit at a fraction of the size and weight (and cost: approximately half as expensive), and with a nicer display including colours, album art, etc. They both can even play doom (although the controls are even more awkward than iPhone Doom).

Can anyone recommend some videos to me which explain the ins-and-outs of the chef and puppet configuration management tools? I have some familiarity with configuration management, having worked on cfengine (version 2) for a few years. However I haven't managed to evaluate the newer tools effectively. The barrier to entry (setting up at least a master and a slave VM...) has been too high (or I haven't given it enough time!) If there are any good screencasts/videos that cover not just how they work but their individual advantages, that would be excellent: I have some upcoming time in which I can absorb material like that (but not the kind of time in which I could get hands-on).

One in the obvious, now that you mention it category. The package description is good enough:

incron is an "inotify cron" system. It works like the regular cron but is driven by filesystem events instead of time events. This package provides two programs, a daemon called "incrond" (analogous to crond) and a table manipulator "incrontab" (like "crontab").

Where filesystem events is anything that is reported by inotify; see the inotify(7) manpage. I didn't test and/or use it since I stumbled on it while searching for something completely different, but it sure sounds useful. The important feature not mentioned in the package description: can it limit how often an event triggers a script execution? Reading the manpage, it doesn't appear so, but there's IN_NO_LOOP to ... disable monitoring events until the current one is completely handled (until its child process exits). Which obviously opens up all kinds of race conditions. So I guess this tool needs to be used with care. Still, I guess a good candidate is monitoring /etc/aliases to run newaliases on change.

The bug webinterface of the Universal Debian Database currently knows about the following release critical bugs:

In Total:	707
Affecting Squeeze:	271
Squeeze only:	71
Remaining to be fixed in Squeeze:	200

Of these 200 bugs, the following tags are set:

Pending in Squeeze:	12
Patched in Squeeze:	36
Duplicates in Squeeze:	22
Can be fixed in a security Update:	17
Contrib or non-free in Squeeze:	5
Otherwise fixed in Squeeze:	27

Ignoring all the above (multiple tags possible), 123 bugs need to be fixed by Debian Contributors to get Debian 6.0 Squeeze released. However, with the view of the Release Managers, 157 need to be dealt with for the release to happen. Please see Interpreting the release critical bug statistics for an explanation of the different numbers.

Cython is now considering options where to move the main (mercurial) repository, and Robert Bradshaw (one of the main Cython developers) has asked me about my experience with regards to Google Code and GitHub, since we use both with SymPy.

Google Code is older, and it was the first service that provided free (virtually unlimited) number of projects that you could easily and immediately setup. At that time (4 years ago?) that was something unheard of. However, the GitHub guys in the meantime not only made this available too, but also implemented features, that (as far as I know) no one offers at all, in particular hosting your own pages at your own domain (but at GitHub's servers, some examples are sympy.org and docs.sympy.org), commenting on git branches and pull requests before the code gets merged in (I am 100% convinced that this is the right approach, as opposed to comment on the code after it gets in), allow to easily fork the repository and it has simply more social features, that the Google Code doesn't have.

I believe that managing an opensource project is mainly a social activity, and GitHub's social features really make so many things easier. From this point of view, GitHub is clearly the best choice today.

I think there is only one (but potentially big) problem with GitHub, that its issue tracker is very bad, compared to the Google Code one. For that reason (and also because we already use it), we keep our issues at Google Code with SymPy.

The above are the main things to consider. Now there are some little things to keep in mind, that I will briefly touch below: Google Code doesn't support git and blocks access from Cuba and other countries, when you want to change the front page, you need to be an admin, while at GitHub I simply add push access to all sympy developers, so anyone just pushes a patch to this repository: https://github.com/sympy/sympy.github.com, and it automatically appears on our front page (sympy.org), with Google Code we had to write long pages (in our docs) about how to send patches, with GitHub we just say, send us a pull request, and point to: http://help.github.com/pull-requests/. In other words, GitHub takes care of teaching people how to use git and figure out how to send patches, and we can concentrate on reviewing the patches and pushing them in.

Wikipages at github are maintained in git, and they provide the webfrontend to it as opensource, so there is no vendor lock-in. Anyone with github account can modify our wiki pages, while the Google Code pages can only be modified by people that I add to the Google Code project, which forced us to install mediawiki on my linode server (hosted at linode.com, which by the way is an excellent VPS hosting service, that I have been using for couple of years already and I can fully recommend it), and I had to manage it all the time, and now we are moving our pages to the github wiki, so that I have one less thing to worry about.

So as you can see, I, as admin, have less things to worry about, as github manages everything for me now, while with Google Code, I had to manage lots of things on my linodes.

One other thing to consider is that GitHub is only for git, but they also provide svn and hg access (both push and pull, they translate the repository automatically between git and svn/hg), I never really used it much, so I don't know how stable this is. As I wrote before, I think that git is the best tool now for maintaining a project, and I think that github is now the best choice to host it (except the issue tracker, where Google Code is better).