Given that Chromium/Chrome is used more and more (as became apparent with the discussion of including it in Debian's squeeze), I decided to give it some tries, mainly Giuseppe Iuculano's version. I occasionally install Chromium from Fabien Tassin's daily builds. And, to be honest, I have also contributed a good amount (about 400) of translated strings to the Brazilian Portuguese part of Chromium. As a matter of fact, I have even done some "activism" and incentivated other people to create their accounts on Launchpad and help with the projects. But I always come back to Iceweasel/Firefox, especially with Mike Hommey's frequently updated repository. What are my reasons for staying with Iceweasel, and not with Chromium?

• I can disable full zoom in Iceweasel (i.e., I only want to zoom the text, not the images). According to Chromium's project BTS, it seems that this will be a WONTFIX bug, despite many people asking for it (and it having a lot of duplicates).
• I can, in Iceweasel, set my preferred fonts without resorting to hacks on the system level, like say, having to lie with fontconfig or other stuff. And I really want Deja Vu Sans, not a serifed font.
• In Iceweasel, a middle mouse click on "an inactive portion" of the page makes me go to the URL that is the system clipboard, just like pasting stuff in X, in general, works. I guess that there may be some way to enable this in Chromium, but, so far, I have not found it.
• In Iceweasel, I have a way (without resorting to many extensions or hackish solutions) to use the equivalent of Firefox's "View > Page Style > No Style" (i.e., to ignore any CSS sheet that the document author may have specified on the page).
• In Iceweasel, my personal data is encrypted before being synced.
• In Iceweasel, I can press Ctrl+Q and make the damn browser quit, instead of me having to use the mouse/trackpad/pointing device. This is probably a lack of my understanding on how to associate key bindings to Chromium, but the problem still stands.
• Similarly, when there is only one tab open, pressing Ctrl+W in Chromium does not close the tab (say, presenting me a blank tab or the list of most visited sites), nor it closes the application.

I would be satisfied if any of the above were fixed or better documented, but it seems that some of those are, at best, going to wait a long time.

I ve been playing with snapshot.d.o, which is a fantastic resource to look at how Debian has been changing over the years.
Below are some preliminary results about various aspects of source packages: format, packaging helpers, and patch systems.
For clarification:

• modif-files indicates packages that do not use a patch system, but modify files outside debian/.
• no-modif-files indicates packages that do not use a patch system, but do not modify files outside debian/.
• other is everything else . Like packages using dpatch, but still modifying some files outside Debian. Or using both dpatch and quilt. (yes, some packages do that).

Random comments:

• People have been moving away from simple-patchsys and dpatch to quilt since 01/2009 (their usage has been decreasing since then). It seems that discussing the introduction of the new package formats was enough to make people move away from dpatch, even if the 3.0 (quilt) was not usable yet. We now have less than 1000 packages still using dpatch or simple-patchsys. Can we get rid of them all for wheezy? It would be nice to standardize on quilt.
• The growth of the 3.0 (quilt) format is impressive. Its adoption is much faster than the adoption of dh7. That surprises me a lot, since I had the impression that more people were unhappy about 3.0 (quilt) than about dh7.
• The number of packages with no packaging helper, but no modified files outside debian/ is dropping. Either than means that we are patching upstream more and more (unlikely), or that means that people are switching to 3.0 (quilt) even if they have no patches, probably due to the other benefits! Could this mean that we could standardize on 3.0 (quilt) and 3.0 (native) for wheezy or wheezy+1?
• The number of packages that modify files outside debian/ without using a patch system has been constantly dropping since 2005.
• dh7 is not a cdbs killer. While it seems to be the cause for a huge drop in classic debhelper packaging, the number of packages using cdbs is still progressing.

If you have other ideas of things to investigate using snapshot.d.o, don t hesitate to ask in comments.

We have customers, which require a report about what we've done during maintenance windows. Usually this includes a report about upgrades, newly installed packages etc. and obviously everything we've done apart from that.
Till now we've prepared them manually. For a greater bunch of systems this is a big PITA, because to be somehow useful you have to collect the data for all systems and after that, prepare a report where you have:

• The upgrades done on all systems (e.g. a libc or kernel update)
  
  seperated from
  
• the updates specific to a certain system or system class

Its also error-prone because humans make mistakes.

Perl to the rescue!
At least the part about generating a report about installed/upgraded/removed packages could be automated, because dpkg writes a well-formed logfile in /var/log/dpkg.log. But I noticed that there appearently is no library specialised at parsing that file. Its not a big deal, because the format of that file is really simple, but a proper library would be nice anyway.
And so I wrote such a library.
It basically takes a logfile, reads it line by line and stores each line parameterized into a generic object.

Its features include:

• Parsing the logfile (obviously)
• Storing each line in a logfile as a DPKG::Log::Entry object that holds informations about the entry type (e.g. action or status update), the package associated (if any), timestamp, verbatim line, line number etc.

• Limiting the number of lines parsed to a time range specified by DateTime objects

Based on that, I wrote another library DPKG::Log::Analyse, which takes a log, parses it with DPKG::Log and then extracts the more relevant information such as installed packages, upgraded packages, removed packages etc.

This, in turn, features:
- Info about newly installed packages
- Info about removed packages
- Info about upgraded packages
- Info about packages which got installed and removed again
- Info about packages which stayed halfinstalled or halfconfigured at the end of the logfile (or defined reporting period)


These libraries are already uploaded to CPAN and packaged for Debian.
They passed the NEW queue very quickly and are therefore available for Sid:

http://packages.debian.org/sid/libdpkg-log-perl

As an example use (and for my own use case, as stated above), I wrote dpkg-report, which uses the module and a Template::Toolkit based template to generate a report about what happened in the given logfile.
It currently misses some documentation, but it works somehow like this:

Report for a single host over the full log:
dpkg-report

Report for a single host for the last two days:
dpkg-report --last-two-days

Report for multiple hosts (and logfiles):
The script expects that each log file has the name <systemname>.dpkg.log so that it can guess the hostname from the system and can grab all such log files from a directory if a directory is specified as log-file arguments:</systemname>

dpkg-report --log-file /path/to/logs

This will generate a report about all systems without any merging.

Report for multiple hosts with merging:
dpkg-report --log-file /path/to/logs --merge

This will do the following:

• Report packages which where installed/removed/etc. on all systems seperate from the upgrades only done on the specific systems
• If systems start with a common name and end on a number (e.g. mail1, mail2, mail3 etc.), report packages which where installed on all systems with that common name seperate from the upgrades only done on the specific systems
• For a specific system list only the changes on that particular system and nothing else.

A (fictive) report could look some what like this:

dpkg-Report for all:
------------------------
Newly Installed:
abc
Removed:
foo
Upgraded:
bar (0.99-12 - 1.00-1)

dpkg-Report for test*:
------------------------
Newly Installed:
blub

dpkg-Report for test1:
------------------------
Upgraded:
baz (1.0.0-1 -> 1.0.0-2)

dpkg-Report for test2:
------------------------
Upgraded:
zab (0.9.7 -> 0.9.8)

Currently this report generator is only included in the source package or in the git(hub) repository of the library. I wonder if it makes sense to let the source package build another binary package for it.
But its only a 238 lines perl script with a dependency on the perl library so I'm unsure if it warrants a new binary package. What do others think?

I have been packaging for Debian for a few years now. My first serious package was Wt back in 2007, but I had been backporting for Ubuntu for at least 2 years already, which means I have been doing .deb packaging for about 5 years (!). Last week I decided it was about time stop nagging my sponsors (Vincent Bernat, Thomas Girard and Sune Vuorela) every time I wanted to update the packages I maintain (witty, ace and libmsn), and I finally started the Debian New Maintainer process. The main reason I had not applied for Debian Maintainer yet was it requires some bureaucracy and, well, I d rather spend my time coding or packaging than doing paperwork I sent my Declaration of Intent and soon after, Thomas and Vincent replied and supported my application with very very nice and kind words. Thank you, guys! I m flattered! Had I known I would be buttered up so much, I would have certainly applied a long time ago! But you know what is the best part of this? It shows how open source projects take advantage of all the tools and communications channels we have (IRC, mailing lists, sprints, conferences, etc), and make distributed development work very well: here we have a 900-developers project in which two French guys are praising an Spanish guy they have never, ever met face-to-face (only e-mail, occasional IRC, and the most important of all: code review). Meritocracy at its full extent. Have you ever seen that in a traditional 100,000 workers company with hundreds of developers working in a single project?

...For the cases where, yes, you actually do want it. For the impatient assuming you're in a clean checkout on the tip of your current branch:

git merge -s ours ref-to-be-merged
git diff ref-to-be-merged   git apply -R --index
git commit -F .git/COMMIT_EDITMSG --amend

you can then double check that everything is as you expect with git diff ref-to-be-merged, which should be empty. The longer story It's noted from time to time that git does not have a -s theirs option to complement the -s ours strategy when merging (or, it did, but it was removed long ago, see below). For those not savvy the idea with git merge -s ours is to pretend as though a merge from some other branch has occurred, though the result remains the current branch's contents, unchanged. This is a neat trick that can be used to show that all changes in some branch have been superceded by the current branch, which can help ease merges further down the line as parallel devlopment continues. However, there is no corresponding -s theirs option, which would conversely say that "everything developed up to here is superceded by this other branch". This feature was discussed and discarded by one of the git authors, who instead advised a developer to throw away the previous work and start on a fresh branch:

One big problem "-s theirs" has, compared to the above "reset to origin, discarding or setting aside the failed history" is that your 'master' history that your further development is based on will keep your failed crap in it forever if you did "-s theirs". Hopefully you will become a better programmer over time, and you may eventually have something worth sharing with the world near the tip of your master branch. When that happens, however, you cannot offer your master branch to be pulled by the upstream, as the wider world will not be interested in your earlier mistakes at all.

In what would probably qualify as "most cases", he's right, but sometimes you do want to do this, and not because you have "crap" in your history, but perhaps because you want to change the baseline for development in a public repository where rebasing should be avoided. In debian, for example, it's pretty common for maintainers who use git-buildpackage to build debian packages from git to have two branches: an "upstream" branch and a "debianized" branch. The upstream branch will follow the changes from the upstream project (either by importing tarballs, or by pulling directly from the project's git repo if they also use git), while the debianized branch contains all the packaging related changes as well as any debian-specific changes to the code. In this context, if the upstream project uses git and rebases their history (out of your control), or if they shift development to a different branch, you might want to have a way to merge with their latest changes without rebasing/abandoning your current debian branch. Hence, a "theirs" merge. The author is totally right that the upstream project may be less interested in pulling from such a repository (since they would drag in the entire previous history), and if that's a problem you might need to splinter off the old branch and start a fresh branch instead. But at least for the projects with which I work, I find that it's more likely that pulling is pretty much one way upstream to debian, and that the patches flow back to the upstream project by way of bug trackers, git format-patch sendmail, or quilt patches sitting in the patch-tracker. And if it becomes a problem later you're no worse off, you can still split off a new branch or take some other action. So anyway, I asked Teh Internetz and found a few hits in the right direction, such as this guy at stack overflow, or this guy here. But from an aesthetic point of view I thought their solutions still left some room for improvement--they were both more complicated, involved setting up temporary branches, and I don't know, just weren't pretty on the eyes. So, ending where I started, this is the relatively clean and easy to follow 3 lines I conjured up, which I will give to teh internetz for posterity.

git merge -s ours ref-to-be-merged
git diff ref-to-be-merged   git apply -R --index
git commit -F .git/COMMIT_EDITMSG --amend

Alternatively, if you want to keep the local upstream branches fast-forwardable, a potential compromise is to work with the understanding that for sid/unstable, the upstream branch can from time to time be reset/rebased (based on events that are ultimately out of your control on the upstream project's side). This isn't a big deal and working with that assumption means that it's easy to keep the local upstream branch in a state where it only takes fast-forward updates. However, on the debian branch your less interested in the clean upstream development, and instead want to keep a sane history of the debianization work, so on this branch you still do something like a merge -s theirs (though in this case, you probably want to amend the previous version's ./debian dir back in post-merge). So applying the same approach as above with the slight modification, in practice (assuming you're on the clean tip of the debian unstable branch, that'd be):

git branch -m upstream-unstable upstream-unstable-save
git branch upstream-unstable upstream-remote/master
git merge -s ours upstream-unstable
git diff ref-to-be-merged   git apply -R --index --exclude="debian/*"
git commit -F .git/COMMIT_EDITMSG --amend

PS In spirit, this is a similar approach to what's done by the XSF team, though I would argue that with what I'm describing both the approach and the resulting history are a bit cleaner and easier to follow. Also, thanks to ron, mrvn, jcristau, and nthykier on #debian-devel for some quick reviewing of this.

Short version: Dear FSF, thanks for your appreciation of Debian Squeeze achievements in getting rid of non-free firmware blobs. We still disagree on the overall freeness assessment of Debian, but I'm positive that steps like this one can further future collaboration, in the interest of both projects. Long version follows.

---

Historically, the relationships among Debian and the FSF have gone through mixed fortune (and that's quite an euphemism). On the one hand, Debian is committed to 100% Free Software, is an open project explicitly inspired by "the spirit of GNU", has been sponsored by FSF in its infancy, and properly calls itself "GNU/Linux" (or even "GNU/kFreeBSD"). On the other hand, Debian is the project who considers the GNU FDL license to be only conditionally free and which is not considered to be an entirely Free system according to FSF.
So much for the history corner. As a long time member of the Debian Project, as well as an FSF(E) fellow, I've always felt a bit sad about this state of affairs. Not because the two projects should have aligned goals; they clearly focus on different aspects of the quest for a Free (Software) world. Not even because they should agree on how to build a Free distribution: history has shown that FSF technical positions do not always get along with Debian's more "pragmatic" style, as embodied by point 5 of the Social Contract. Rather, my sadness is rooted in the belief that not getting along have encouraged duplication of efforts which could have been easily avoided (e.g. multiple distributions concurrently freeing up kernels). Furthermore, I'm more and more convinced that Debian nowadays enjoys a rather privileged position among Free Software vendors. Indeed, even though GNU/Linux distributions have reached a popularity we didn't dare to imagine 15 years ago or so, most distributions are under the direct or indirect control of commercial vendors. Those commercial vendors play a very important role in the promotion of Free Software. For instance, they are structured in ways that enable them to seal OEM deals with hardware manufacturers to sell computers with GNU/Linux pre-installed. Commercial vendors, by their own nature, are also in general better at marketing than non-commercial vendors. On the flip side however, commercial vendors are not yet relevant enough to drive proprietary drivers out of the market and, as a consequence, cannot yet afford not to support hardware which need such proprietary bits to work. Among mainstream GNU/Linux distributions[1] Debian is one of the very few vendors if not the only one that is both very relevant and, thanks to its independence, can afford taking Free Software's side: no commercial urgency can force Debian to negotiate on that. That is quite an asset to be used in the promotion of Free Software, especially to a public that is interested in and willing to understand what Free Software really is about. Such an "aware" public is on the rise as of lately, together with the general awareness increase of risks entailed by living a digital life, when that life is not under our control (think, as an example, at how often the "Facebook privacy debate" has hit mainstream medias in the last year). The "aware" public is the natural target of both Debian and the FSF. Dividing it would not serve well the cause of Free Software. With all that in mind, last August I took the chance of being on the "right" side of the Atlantic Ocean for DebConf10, to discuss possible venues of collaboration among Debian and the FSF. I sat down and discussed at length with John Sullivan, who I happen to know for his Debian involvement, in his capacities of FSF representative and operations manager. We discussed various topics, with the intention of bringing them up to the respective communities[2]. Then, inevitably, we ended up talking about the overall freeness of Debian and his exclusion from FSF listing of Free systems. (FSF is of course entitled to such judgements, pretty much as Debian is entitled to its own judgements on FSF licenses. Nevertheless those judgements contribute to dividing our public and might lead to wasteful duplication of efforts, where Free Software could better be served by collaboration.) The main ground for exclusion from that list used to be the compromises Debian has made in the past about non-free firmware blobs. But, as I pointed out back in August, those compromises would have been gone starting with Squeeze, making that argument moot. Today 6 months later I'm delighted to cheer at FSF's decision to publicly recognize the achievements Debian has delivered with Squeeze.
Thanks! It's a nice gesture that I've very much appreciated. I'm confident steps like this one will help future collaboration if, on both sides, we will be able to spot actual venues for collaboration. Needlessly to say, I still disagree with the overall FSF assessment of Debian non-freeness. Apparently, it still stands on the basis that Debian also provides a repository of nonfree software [ ] [which] is not part of the Debian system. [ ] but users would be hard-pressed to make a distinction and that people can readily learn about software available through it by browsing Debian's online package database. I respect the principle of non advertising non-free software and I even agree that it is a good principle. But unfortunately it's also a very blurry principle on which, in my opinion, Debian actually scores very well. No non-free software is offered to users by Debian; it's just for users that really want to have non-free software (or need to, in order to run a Free OS on their computers), that Debian tries to stay out of their way. For the "aware" public discussed above, I think it's much better to draw the line where software freedom ends and use that line to explain what does crossing it entails, than locking them up pretending non-free software do not exist. But fair enough: for the time being, I guess, we will need to agree to disagree on this one. Getting a little bit closer in the occasion of the Squeeze release is still an important step forward. It's up to each of us now to seek out initiatives which attract the interest of both projects and that can benefit from synergies.

---

[1] Sorry, I've no decent definition of "mainstream distribution" to offer, besides folklore and well-established distribution review sites. (Heck, I don't even have a decent definition of "well-established distribution review site" to offer!).
[2] which hasn't happened yet, due to the proverbial amount of available spare time.

We have many orphaned packages in Debian. Those are packages that no longer have a maintainer willing to care for them. They are a problem for several reasons. Often, there have better alternatives (that s often why the maintainer gave up maintenance), but users keep installing them because they show up in apt-cache search. Or, they might be broken, without anybody noticing because they only have a few users. Also, developers need to take them into account. They might slow down transitions, have RC bugs that need fixing, etc. So, there are good reasons to remove some of the orphaned packages from the Debian archive. Not all of them. But those that have been orphaned for a long time without anybody stepping up to take over the maintenance, have very few users according to popcon, etc. Removing some of them also makes it easier to expose the ones that should really find an adopter. Also, that removal is not final. The good reason to do this now is that we are at the beginning of a release cycle, and that it will be easy to reintroduce packages that are really needed during the next two years. Also, packages (both source and binaries) are still available on snapshot.debian.org, so users can still install them from there, and re-uploading them to Debian is very easy if someone wants to adopt them. So, how do I proceed? I use bapase, and go through specific sets of packages (using a custom version of bapase to restrict the list to those packages). For example, orphaned packages that have a popcon lower than 50, have been orphaned for more than 500 days, and whose orphaning bugs have not been modified in the last 100 days. Then, I read the bug log, and decide if there s a reason to keep the package. If there s not, I request the removal. As of today, there are 471 orphaned packages in Debian. The goal is not to get down to zero, but it s certainly possible to get down to 200 or 250. How can you help? Start from the list, and find some easy targets. You can take a look at bug #483252 if you want to re-use my template. Also, one thing that is currently missing in the process is that orphaned packages that have reverse-dependencies should not be removed without removing their dependencies (if appropriate). An easy and efficient way to know if a given package has reverse (build-)?dependencies would be great, so I could integrate this info into bapase and exclude those packages from the list, or mark them somehow.

Paul Wise called attention recently to the fact that there's renewed activity around multiarch in the face of the squeeze release. Although I fervently wish we could have gotten multiarch support into squeeze, it's better late than never; and real progress is being made now, thanks mostly to the efforts of wonderful package management experts like Raphael Hertzog, Guillem Jover, and David Kalnischkies. Don't believe it's finally coming? Here's some output from my amd64 multiarch chroot:

$ dpkg -l '*:i386'
Desired=Unknown/Install/Remove/Purge/Hold
  Status=Not/Inst/Conf-files/Unpacked/halF-conf/Half-inst/trig-aWait/Trig-pend
 / Err?=(none)/Reinst-required (Status,Err: uppercase=bad)
 / Name           Version        Description
+++-==============-==============-============================================
ii  gcc-4.5-base   4.5.2-3ubuntu2 The GNU Compiler Collection (base package)
ii  libc6          2.13-0ubuntu1+ Embedded GNU C Library: Shared libraries
ii  libdb4.8       4.8.30-5multia Berkeley v4.8 Database Libraries [runtime]
ii  libgcc1        1:4.5.2-3ubunt GCC support library
in  libpam-modules <none>         (no description available)
ii  libpam0g       1.1.2-2ubuntu1 Pluggable Authentication Modules library
ii  libselinux1    2.0.96-1multia SELinux runtime shared libraries
ii  libstdc++6     4.5.2-3ubuntu2 The GNU Standard C++ Library v3
iU  libuuid1       2.17.2-9.1ubun Universally Unique ID library
ii  selinux-utils  2.0.96-1multia SELinux utility programs
ii  zlib1g         1:1.2.3.4.dfsg compression library - runtime

If you're as excited about this making its way into Debian as I am, you might be wondering what you can do to help. That's great, because I'd love to tell you! Perhaps you happen to maintain a package that provides executables; and perhaps other packages depend on your package exclusively to use those executables; and perhaps some of those packages depending on your package are shared libraries. If all of the above is true, please consider declaring this package to be Multi-Arch: foreign as defined here. Note: it is very important that you not use this on any package that will provide architecture-dependent interfaces to its reverse-dependencies. So if you're shipping both shared libraries and executables in the same binary package, don't do this. But if your package does fit this description, this is one part of multiarch that you can safely start implementing today. This will go a long way towards getting the system ready to handle multiarch libraries when they land. My own efforts to help with getting Multi-Arch: foreign packages documented in the archive are trackable here.

squeeze is released but this doesn't mean the end of the ordinary RC bug; old ones are still around, & new ones keep floating in.

as a short reminder to take the occasional look at the RC bug list I'm again posting what I've done in the last weeks. as you can see no NMUs but only work on packages I have a relation to, & often only uploading packages prepared by others (yeah teamwork!).

• #599794 libcgi-application-extra-plugin-bundle-perl: "libcgi-application-extra-plugin-bundle-perl: Copyright etc of icons in Authentication module not declared"
  upload package prepared by periapt (pkg-perl)
• #603252 libthread-queue-perl: "libthread-queue-perl: obsoleted by perl in squeeze"
  upload new upstream release prepared by periapt (pkg-perl)
• #603253 libtime-local-perl: "libtime-local-perl: obsoleted by perl in squeeze"
  upload new upstream release prepared by periapt (pkg-perl)
• #605795 src:libconfig-model-backend-augeas-perl: "libconfig-model-backend-augeas-perl: FTBFS: failed tests"
  upload package prepared by dod (pkg-perl)
• #605796 libdevel-ebug-perl: "FTBFS: failed tests"
  update bug info, later closed by carnil (pkg-perl)
• #605809 src:libhtml-widget-perl: "libhtml-widget-perl: FTBFS: failed tests"
  patch to make tests compatible with libhtml-tree-perl >= 4 (pkg-perl)
• #612723 iodine: "iodine overwrites /etc/default/iodine during upgrade with a sourced version of that file"
  change config script to read variables from configuration file instead of sourcing it (maintainer upload)
• #613187 libogre-perl: "xs/SceneQuery.xs:28: error: cannot convert [..]"
  upload new upstream version (pkg-perl)
• #613388 libproc-processtable-perl: "libproc-processtable-perl: FTBFS on kFreeBSD"
  apply kFreeBSD patch (pkg-perl)
• #613390 src:libgearman-client-async-perl: "libgearman-client-async-perl: FTBFS: tests hang"
  merge and tag confirmed (pkg-perl)
• #613395 libnet-twitter-lite-perl: "libnet-twitter-lite-perl: FTBFS: spelling tests fail"
  run tests under LANG=C, later disable POD tests (pkg-perl)
• #613398 libpoe-perl: "libpoe-perl: FTBFS: tests fail"
  upload new upstream release, prepared by periapt (pkg-perl)
• #613731 libtest-www-mechanize-perl: "libtest-www-mechanize-perl: FTBFS: test failures"
  upload fixed package prepared by roam (pkg-perl)
• #613732 libtest-xml-simple-perl: "libtest-xml-simple-perl: FTBFS: test failures"
  upload fixed package prepared by roam (pkg-perl)
• #613942 perlipq: "perlipq: FTBFS on armel - Failed 1/2 subtests"
  adjust patch in test suite to only run first test (pkg-perl)

(Non-Debian readers can stop reading now, I'm talking about so-called "orphaned packages" and not anything of real-world importance.) In 2008 I stopped maintaining non-native packages in Debian. At the time I maintained a fair amount of stuff. It's interesting to see what happened to it after I gave it up, partly because some of the results seem so random and partly because some of what has happened seems to point at weaknesses in Debian. First, the success stories. More than half of my packages are now being maintained by others: xaos, longrun, fbreader, liblinebreak, analog, xgalaga, znc, sysnews, metastore, bsdgames, uqm, oneko, kobodeluxe, archivemail, unclutter I still use much of this stuff, some only occasionally, and other daily, and am glad it's being kept alive. (It's surprising that someone still care about longrun.) I was unhappy to have to NMU procmeter3 just before the release of Debian 6.0 to fix a trivial to debug RC bug that almost got it removed from the release. I hope that was just a bump in its road. Also, splitvt is now maintained again after being orphaned a long time. I'm not sure if it makes sense to keep it in Debian, since screen can do the same thing, and it has a security history, but someone wants to, so that's fine. Two packages are left on life support. I'm surprised nobody wants to maintain grepmail, unless we're all using notmuch or mairix now? And dgen is the best Sega emulator I know of. Several games were not picked up by the games team, despite them showing some interest originally, and were removed: xtris, xjewel, xemeraldia, xbl Of those, xemeraldia in particular is a lot of fun, I'm surprised nobody cared to keep it. Also, the nestra Nintendo emulator was shipped with squeeze, but now is removed as it never got a maintainer. I don't know if there is a better NES emulator in Debian. The intercal programming language was removed. Surprising. Debian does at least still have clc-intercal for all our pressing Intercal needs. Finally, sparkline-php was removed today despite never having had any bugs, needing no maintenance, and being a suggests of ikiwiki, which is now more buggy (broken relationships, outdated docs) and less featureful in Debian.

There are many ways to run some commands simultaneously on multiple hosts like cssh or dsh. They come handy for example when you are installing software updates on a set of hosts. dsh is a rather simple comandline tool allowing to execute a command over ssh on multiple hosts. However it doesn't allow any interactive input -- so you can't look at the potentially upgrading packages and press y to accept and you can't go through debconf promts or similar. This is solved by cssh which opens a XTerm for every host and a input area that is broadcastet to all of them. this is working really well -- you can execute your update on all hosts and still do individual adjustments just as needed: switch focus from the broadcasted input to one of the terminal windows and anything you type just goes there. Now cssh has a big disadvantage: it requires a running X server (and doesn't do too well with a fullscreen windowmanager). Requiring X is quite a blocker if you need to run that ssh multiplexer on a remote host, for example if the firewalling doesn't allow direct connections. Fortunately you can make tmux behave as we want -- in a simple terminal: First you need a script spawning the ssh sessions in separate tmux panes and direct input to all of them -- here called ssh-everywhere.sh (you could also write a tmux config I guess):

#/bin/sh
# ssh-everywhere.sh
for i in $HOSTS
do
  tmux splitw "ssh $i"
  tmux select-layout tiled
done
tmux set-window-option synchronize-panes on

Now start the whole thing:

tmux new 'exec sh ssh-everywhere.sh'

And be done. Update If you want to type in just one pane (on one host) you can do that as well: C-b : set-window-option synchronize-panes off and moving to the right pane (C-b + Arrow keys)

When Reddit sold to Cond Nast and the founders all moved to California, their old place in Davis Square was empty for a few months and they let Mika I move in and take it over. It's an awesome place and we're still there along with some Web 2.0 graffiti they left on the roof. And so it is with pleasure that I've agreed to be interviewed by redditor Danny Piccirillo in a giant igloo he helped build -- if the unseasonably warm weather streak of weather doesn't manage to melt it before next week. Questions are being gathered at Reddit so feel free to go there and ask me any question you'd like to see me answer in an igloo.

Nokia is in the news for it s CEO announcing that they have a Burning Platform , Jeff Waugh gives an interesting analysis of the situation [1].What is a Platform for Phones?This whole scenario makes me wonder about what a platform should mean in terms of mobile devices. Wikipedia says A computing platform is some sort of hardware architecture and software framework (including application frameworks) that allows software to run. Typical platforms include a computer s architecture, operating system, programming languages and related user interface (run-time system libraries or graphical user interface). [2]I think that Nokia s problem was that it didn t leverage it s strength in making great phone hardware. Nokia used to have a commanding share of the market due to simply making better phones. They had phones that were upwardly compatible (the same UI and used the same chargers), their phones were always very solidly constructed, and they had some good design features such as having the battery comprise part of the case which allowed a replacement battery to be physically larger for longer battery life. Even now they have hardware features which are better than the rest such as the N8 which is widely regarded as having the best camera of any phone. Nokia also did some smart things like releasing their N800 series of phones with more open software than most companies used, they supported running arbitrary Linux applications.While they kept the platform as the API interface on a phone OS and maintained several different OSs (with multiple versions in production at any time) they made a less desirable platform for developers and a lot more development work for themselves.Nokia fragmented their own market. There is no technical reason why they couldn t manufacture a phone that is capable of running a choice of their own OS as well as Android (or alternatively their own OS or the Windows Phone OS). There may be technical issues that prevent designing a phone to run either Android or Windows phone, but they could have got two out of three options available.On top of a hardware phone platform we could have multiple software platforms, Android, Windows, Meego, etc. The users could then decide which one to use.A Hardware Platform for PhonesI think that it would be ideal if a phone company offered phones with a choice of OS and allowed the user to change the OS. The N8 is a great phone and the hardware is really appealing, I would have definitely bought one for my wife if it ran Android. Also the resale value of phones can be improved if they can be re-purposed. If someone knew that people on ebay were paying good rates for an old phone because it could be re-programmed then they would be more likely to buy it. As phones are essentially free for most people due to telco deals, a phone that has a resale value of $200 is a lot more desirable than one with a resale value of $100 if all other things are equal.I would like to see the mobile phone as a platform just as the IBM PC compatible was a platform. Imagine if IBM had sued Compaq into oblivion when they first cloned the PC, if that had happened I don t think that I would be using an IBM PC (Thinkpad) right now. The early IBM PCs really weren t great systems for home use, for pretty much anything you might want to do the early PCs didn t compete well with CP/M systems and systems from Commodore and Apple. It was only when cheap clones flooded the market that the PC platform took off. Modern PCs can boot from disks that were created 20 years ago. At every time during the PC s history there has been a choice of OSs available that work with the standard BIOS boot loader and expect certain essential hardware (such as a BIOS interface for video, keyboard, and storage). This choice increased the market allowing economies of scale in production. It also allowed competition between vendors which forced the margins to be low and resulted in PCs becoming cheap over the last 20 years every aspect of a PC apart from Intel CPUs and Microsoft Software has steadily dropped in price.I would like to see phones designed with a common boot loader, a common core set of CPU functions (I believe that with ARM CPUs a lot is optional), and common interfaces to the touch-screen and the GSM system. The boot loader would ideally have support for booting multiple OSs, in a typical end-user case the store would provide the phone configured to quietly only boot one of the available OSs but it would be trivial to offer the user a choice of OS at boot time for advanced users. The process of installing a custom ROM image in a phone is regarded as dangerous at the moment and most people who would like to do such things are hesitant due to the risk of bricking their phone. If booting the last good OS was an option then more people would try new OSs. With the current situation I am a little hesitant to re-program my new phones (and I m braver about such things than most people).One of the many problems with the current situation is that the phone vendor has to officially support every phone OS. One example of the problems with this is the Sony Ericsson Xperia X10 which is a fine piece of hardware that has been saddled with an older version of Android for it s entire life, Sony has stated that they won t produce any more updates and thus the demand for this phone is a lot lower than it might be. I believe that this is why the Xperia X10 is significantly cheaper than any other phone with similar features. Sony is losing money because they have a closed hardware platform and don t support the recent versions of Android!Ways of Booting the OSIt shouldn t be a technical challenge to have support for basic touch-screen IO and 3G Internet access in the boot loader of the phone. Then an OS such as Android could be loaded from the network before being booted without needing an older version of Android running. 80386 systems with a few megs of RAM used to be able to boot from a LAN, a modern phone has much more powerful hardware and a network connection that s at least as good as 10base2 networking so it should be able to do the same.Modern phones have micro-SD cards for local storage. There s no reason why the OS couldn t be loaded on micro-SD card. Fixing the OS on a phone that was bricked could be achieved by putting the micro-SD card in a PC and then copying the files across just as I often fix PC OS problems by installing the hard drive in a working system.Changing the OS of a phone should be easier than changing a PC between Ubuntu and Fedora (the Linux distributions that seem to have the most usage by less technical users).ConclusionIf Sony had made their platform the hardware then they could have spent their effort on what they do well (making great phone hardware) and delegated almost all of the work related to creating the OS to other companies (Google, MS, telcos, etc).If the entire industry moved to a hardware platform for phones then the result would be lower prices and some thin margins for manufacturers. This would be good for users and OK for manufacturers. The current situation however is quite bad for users who can never get phones to do exactly what they want and not so good for phone manufacturers such as Nokia (and everyone else who does business with Microsoft) who find themselves on the wrong side of market forces. The phone as a hardware platform shouldn t be too bad for Microsoft either, they did OK on the PC hardware platform.

• [1] http://bethesignal.org/blog/2011/02/11/elopocalypse-nokia-chooses-microsoft/
• [2] http://en.wikipedia.org/wiki/Computing_platform

In Ubuntu, the use of ptrace is restricted. The default allowed relationship between the debugger and the debuggee is that parents are allowed to ptrace their descendants. This means that running gdb /some/program and strace /some/program Just Works. Using gdb s attach and strace s -p options need CAP_SYS_PTRACE, care of sudo. The next most common use-case was that of crash handlers needing to do a live ptrace of a crashing program (in the rare case of Apport being insufficient). For example, KDE applications have a segfault handler that calls out to kdeinit and requests that the crash handling process be started on it, and then sits in a loop waiting to be attached to. While kdeinit is the parent of both the crashing program (debuggee) and the crash handling program (debugger), the debugger cannot attach to the debugee since they are siblings, not parent/descendant. To solve this, a prctl() call was added so that the debugee could declare who s descendants were going to attach to it. KDE patched their segfault handler to make the prctl() and everything Just Works again. Breakpad, the crash handler for Firefox and Chromium, was updated to do effectively the same thing, though they had to add code to pass the process id back to the debuggee since they didn t have it handy like KDE. Another use-case was Wine, where for emulation to work correctly, they needed to allow all Wine processes to ptrace each other to correctly emulate Windows. For this, they just declared that all descendants of the wine-server could debug a given Wine process, there-by confining their ptrace festival to just Wine programs. One of the remaining use-cases is that of a debugging IDE that doesn t directly use ptrace itself. For example, qtcreator will launch a program and then later attach to it by launching gdb and using the attach command. This looks a lot like the crash handler use-case, except that the debuggee doesn t have any idea that it is running under an IDE. A simple solution for this is to have the IDE run its programs with the LD_PRELOAD environment variable aimed at a short library that just calls prctl() with the parent process id, and suddenly the IDE and its descendants (i.e. gdb) can debug the program all day long. I ve got an example of this preloadable library written. If it turns out this is generally useful for IDEs, I could package it up like fakeroot and faketime.

David Paleino asks:

I'm still missing how to reliably detect if a device is a "wired" or a "wireless" one. I suspect that checking the existence of /phy80211 would be enough, but I can't really tell, and seems like I'm not able to find an exhaustive sysfs reference manual.

Sadly there is no exhaustive manual, but many attributes found in sysfs are documented under Documentation/ABI/. In this case you need the DEVTYPE name from the net device's uevent, which may be e.g. 'wlan' or 'wwan' (and is absent for wired Ethernet devices). I don't know why this isn't also exposed as an attribute in its own right.

In case you missed the news on webkit-dev, Collabora has been working on developing a clutter port of WebKit. It shares the build system with EFL, and most of the backend code comes from the GTK+ port. That means networking is handled by soup, drawing by cairo, multimedia by GStreamer, and so on. If you d like to give it a try, you can clone the repository from gitorious: $ git clone git://gitorious.org/webkit-clutter/webkit-clutter.git Then to build it you use cmake. From inside the source code directory do this: $ mkdir build
$ cd build
$ cmake .. -DPORT=Clutter -DSHARED_CORE=1 -DBUILD_MX_LIB=1
$ make
The BUILD_MX_LIB option is optional it will build what we call the Mx toolkit library in addition to the vanilla one. Then you can test that the library is built and working by running the programs inside the Programs directory. Enjoy!

I have just got a new Xperia X10i for my wife. It s with Virgin who use the Optus network. Optus apparently have better coverage than Three (who we have been using for 6.5 years) and Virgin offers the best deals they have good phones on low monthly rates and do nice things like selling most phones unlocked (the Xperia is one that comes unlocked).I chose the phone for use in system administration work. A large screen should be good for reading email and running a ssh client. Hopefully I will be able to use the phone s Wifi to provide mobile net access to a laptop for any problem that can t be solved on a tiny screen. My wife doesn t do much sysadmin work nowadays, but it ll save some effort if we can both use the same model of phone. Also according to Amobil.no the Xperia X10 is the second best phone for camera-phone functionality [1], and my wife would really like to take some good pictures with her phone (she loves the LG U990 Viewty that she has right now).ScreenOne major reason for choosing this phone is that it has the biggest and highest resolution of any phone that doesn t cost a huge amount of money. It does well in this regard, the screen is very good to look at. However it is apparently not particularly sensitive and we still have the protective cover on the screen which makes the swipe to unlock operation quite difficult. My wife generally likes to keep the protective plastic on such screens for a while to prevent damage, but she may take this off sooner than on other devices.Sony FoolishnessOne reason that this phone is cheaper than any other phone with similar specs is that it s made by Sony. Sony won t provide updates to Android 2.2 or better and they have their own stupid applications installed in an intrusive manner. The main screen of the phone has a large icon for the Sony Timescape program. If you choose a background image of a person s face then the Timescape logo is in the ideal location to obscure the person s eyes. Generally it s not desired to have the person in your phone background look like Zorro. Fortunately you can delete icons from the home screen, you just have to press and hold the icon until a trash-can appears at the bottom of the screen and then drag it to the trash.Phone BookThe core phone functionality is fairly important for a mobile phone. But it seems that every modern phone has some serious failings in this regard. The Xperia comes with a phone book that is reasonably good for managing contacts and partially coalesces multiple entries with the same name which is convenient as I somehow managed to import 3 copies of each entry in my wife s phone book. The down-side is that the multiple entries are still stored, so when it comes time to update someone s phone number my wife will have to separate the entries and then delete all but one of them, adding probably a minute of effort for each one. With 60 phone book entries that s probably an hour of wasted time during the course of her phone use.They really should do a time based analysis of phone use and optimise the UI for efficiently performing common tasks. I think that an ideal design would start off by asking the user to rate the importance of phone functionality, camera, facebook, twitter, etc and then give a UI that matches the important tasks. A device that has 384M of RAM, 1G of built-in Flash storage, and an 8G micro-SD card (which Virgin provided with the phone) should be able to offer a selection of UIs.CameraThe configuration for the camera allows some settings to be changed easily and others have to be changed through the advanced settings which requires one more button press and a few extra taps on the screen. One real stupidity is to have the phone light be in the advanced settings, so if the room happens to be a little darker than expected you suddenly need to go to a lot of extra effort to turn on the light.Finally it would be really good to be able to take a quick picture. I would like to be able to be able to press a combination of buttons and have it immediately take a picture regardless of what had been running before. Not press the main menu button, the camera icon (which I made a link from the home screen), wait a second for it to load, and then press the shutter button. Ideally I would like to press a combination of hardware buttons to have it immediately take a picture even when the screen is locked. I don t want to wait for the screen unlock process, sometimes the perfect shot is only available for a second.WifiIt doesn t support ad-hoc networks. This is really annoying for me as I don t own an access point and I don t plan to buy one just for a phone. My laptop (Thinkpad T61 with Intel Corporation PRO/Wireless 3945ABG [Golan]) doesn t seem to support running as an access point, and my EeePC 701 with an Atheros AR5001 has the same problem, here is the error message:# iwconfig wlan0 mode master essid x
Error for wireless request Set Mode (8B06) :
SET failed on device wlan0 ; Invalid argument.I have a cheap Realtec USB Wifi device that claims to support being an access point but just fails when I try it. So presumably it doesn t really support it but the driver is buggy.It seems that I may need to put a custom Android installation on it to get ad-hoc working.Also it s apparently necessary to root the Xperia to get Wifi tethering to work for providing net access to a laptop. So I guess I ll hacking it soon.Internet AccessThe Virgin web site couldn t help me set up the Internet access because I ported a phone number from another Telco. I had to use the phone number supplied by Virgin to login to their web site and the site then wanted to sent (probably SMS) the settings to my phone, but of course it couldn t SMS to that number as I ve got the Three number active. Presumably they were expecting that customers would setup Internet access before porting their old number.I phoned the Virgin tech support and used the settings they suggested, but it didn t work. Then I took the phone to a Virgin store and it started working after they rebooted it with no changes to settings. Just like Windows used to be. :(Email Access Default AppThe email setup defaults to port 143 IMAP access, so even when a mail server provides access on port 993 for IMAPS and on port 995 for POP3S probably most users will not use any encryption because their phone doesn t default to it. Also one annoying feature is that when I gave it the email address test@coker.com.au it decided to use test as the user-name for IMAP by default. It seems that a very large portion of the active email accounts nowadays are on systems that handle multiple domains and thus require the domain name in authentication, and a large portion of the remainder accept domain names even when they aren t required. Besides it s a lot easier to delete a domain name when it s not needed than to type it in when it is.The default hostname for sending and receiving mail is the domain name, if the MUA configuration program had checked the MX record it would have known that smtp.sws.net.au is a better default choice for the mail server. I ve now started the practice of creating a CNAME entry named m in every domain I run, so when someone is setting up a mobile phone they just have to add m. to the start of the default hostname to use for sending and receiving mail. By doing this I can probably save an average user at least 30 seconds of typing, which is particularly important if I happen to be talking them through the process!The MUA uses IMAP commands to load the text of the message without attachments and then loads attachments on demand, this will be handy for when people attach unreasonably large files. With IMAP caching and partial loads the core functionality seems OK, and some quick tests of standard but not commonly used IMAP functions such as noticing that mail has been deleted by another client seemed to work well. The performance of loading a new mailbox with 369 message was quite poor, I m not sure how much of this is due to the network connection and how much is due to the client implementation. This is a real concern for me as I typically have about 7,000 messages in my IMAP account and 3,000 unread messages most of which are in two folders.Another problem is the fact that there seems to be no way of searching in the list of messages, sorting/grouping by subject or sender, or showing unread messages. This makes the Xperia unsuitable for the task of reading mailing lists when on public transport. I would really like to be able to sort through a folder of mailing-list mail, delete messages that I don t need to keep and flag ones that need attention when I have the resources of a desktop system when I m on a tram or in other situations where a laptop can be inconvenient.One undeniable bug I discovered (as opposed to the missing features I listed) is that when a message has a line with a URL followed by many spaces it won t load correctly in the web browser, the spaces will be treated as part of the URL. I ve changed the default signature in my email to have a description followed by a URL to avoid triggering this bug. Presumably other Android phones are bug for bug compatible. :(Moxier MailThere is a complete set of email and calendaring applications preloaded from Moxier.com. The Moxier mail client uses company.com as an example domain name (they should use example.com does no-one read the RFCs?). It s nice that they verify the SSL certificate and display the details when it s not signed.Unfortunately Moxier doesn t support anything other than Exchange, and I can t delete it either as it s part of the base set of applications from Sony.SMSThe SMS application is supposedly conversation based. This doesn t seem like a benefit to me, it s a pity that there is no option to make it act more like every other SMS implementation I ve used over the last 12 years.BatteryThe battery is described as having a capacity of 1500mAh, for comparison a AA rechargeable batteries have capacities ranging from 1800mAh to 2800mAh. My first mobile phone had a rechargeable battery that took the same space as 4*AA batteries and the phone was designed to run on AA batteries if the main battery wasn t charged. I would like to have an Android phone that had a battery pack of similar size to at least 2*AA batteries, and 4*AA would be OK too.The Xperia battery was reported as being half discharged after playing with the phone for less than an hour. Basically when doing anything with the phone that is remotely intensive I need to have it plugged in. Unless of course I m using one of the star-chart applications LightsThere are two white leds in the gaps between the keys for Settings, Main-Menu, and Back on the front. They are quite bright and annoying to look into at night.SSHSSH was one of the reasons for getting an Android phone, but it was one of the last things I worked on because everything else was so much fun. I m currently using ConnectBot, it supports storing ssh host keys, generating a key-pair from random screen touches, locking and unlocking the key-pair (with a pass-phrase) and pasting the public key to an open window. All the basic functions just work although it s rather inconvenient to enter the CTRL keys.The next thing to investigate is a small and light Bluetooth keyboard. Using an external hardware keyboard will save me from the pain of entering CTRL keys (which is even worse than the pain of entering passwords that contain digits and mixed case). It will also allow me to type a lot faster and use the entire screen for the ssh session.Current Bug SummaryWifi doesn t do ad-hoc mode or tethering.MUA doesn t correctly handle URLs in messages if many spaces follow the URL and is also unsuitable for mailing list mail.Sometimes requires a reboot to make Internet access settings take affect.Camera light can t be easily turned on and off.This isn t too bad.ConclusionMost things do what I want. Once I get a MUA working with all my email, Wifi doing what I want, and a Bluetooth keyboard it ll be a fairly ideal mobile sysadmin terminal. I ll probably order one for myself this weekend.

• [1] http://www.amobil.no/artikler/norges_beste_kameramobil/79081

Maximilian, along with the other members of the Debian kernel team, has the overwhelming job of maintaining the Linux kernel in Debian. It s one of the largest package and certainly one where dealing with bug reports is really difficult as most of them are hardware-specific, and thus difficult to reproduce. He s very enthusiastic and energetic, and does not fear criticizing when something doesn t please him. You ll see. My questions are in bold, the rest is by Maximilian. Who are you? My name is Maximilian Attems. I am a theoretical physicist in my last year of PhD at the Technical University of Vienna. My main research area is the early phase of a Quark-Gluon Plasma as produced in heavy ion collisions at the LHC at CERN. I am developing simulations that take weeks on the Vienna Scientific Cluster (in the TOP 500 list). The rest of the lab is much less fancy and boils down to straight intel boxes without any binary blobs or external drivers (although lately we add radeon graphics for decent free 3D). Mathematica and Maple are the rare exceptions to the many dev tools of Debian (LaTeX, editors, git, IDE s, Open MPI, ..) found at the institute, as those are unfortunately yet unmatched in Free Software for symbolic computations. The lab mostly runs a combination of Debian stable (testing starting from freeze) for desktops and oldstable/stable for servers. Debian is in use for more than 10 years. So people in the institute know some ups and downs of the project. Newcomers like my room neighbors are always surprised how functional a free Debian Desktop is. What s your biggest achievement within Debian? Building lots and lots of kernels together with an growing uptake of the officially released linux images. I joined the Debian kernel team shortly after Herbert Xu departed. I had been upstream Maintainer of the linux-2.6 janitor project for almost a year brewing hundreds of small cleanups with quilt in a tree named kjt for early linux-2.6. In Debian we had lots of fun in sorting out the troubles that the long 2.5 freeze had imposed: Meaning we were sitting on a huge diverging monolithic semi-good patchset. It was great fun to prepare 2.6.8 for Sarge with a huge team enthusiastic in shipping something real close to mainline (You have to imagine that back then you had no stable or longterm release nor any useful free tools like git. This involved passing patches around, hand editing them and seeing what the result does.) From the Sarge install reports a common pattern emerged that the current Debian early userspace was causing lots of boot failures. This motivated me to develop an alternative using the new upstream initramfs features. So I got involved in early userspace. Thanks to large and active development team initramfs-tools got a nice ecosystem. It still tries to be as generic and flexible as possible and thus gains many nice features. Also H. Peter Anvin (hpa) gave me the official co-maintenance of klibc. klibc saw uptake and good patches from Google in the last 2 years. I am proud that the early userspace is working out fairly well these days, meaning you can shuffle discs around and see your box boot. Later on we focused on 2.6.18 for Etch, which turned out to a be good release and picked up by several other distributions. Only very much later we would see such a sync again. With 2.6.26 for Lenny we got somehow unlucky as we just missed the new longterm release by one release. We also pushed for another update very late (during freeze) in the release cycle, which turned out to semi-work as too much things depend on linux-2.6. For Squeeze 2.6.32 got picked thanks to discussions at Portland Linux Plumbers and it turned out to be a good release picked up by many distributions and external patchsets. The long-term support is going very well. Greg KH is doing a great job in collecting various needed fixes for it. Somehow we had hoped that the Squeeze freeze would start sooner and that the freeze duration would be shorter, since we were ready for a release starting from the actual freeze on. The only real big bastard on the cool 2.6.32 sync is Red Hat. Red Hat Enterprise 6.0 is shipping the linux-2.6 2.6.32 in obfuscated form. They released their linux-2.6 as one big tarball clashing with the spirit of the GPL. One can only mildly guess from the changelog which patches get applied. This is in sharp contrast to any previous Red Hat release and has not yet generated the sharp and snide comments in press it deserves. Red Hat should really step back and not make such stupid management moves. Next to them even the semi-maintained Oracle Unbreakable 2.6.32 branch looks better: It is git fetchable. What are your plans and those of the kernel team for Debian Wheezy? Since 2.6.32 many of the used patches landed upstream or are on the way (speakup, Kbuild Debian specific targets, ..). The proper vfs based unionfs is something we d be looking forward. We haven t yet picked the next upstream release we will base Wheezy on, so currently we can happily jump to the most recent ones. There are plans for better interaction with Debian Installer thanks to generating our udebs properly in linux-2.6 source itself. Also we are looking forward to using git as tool of maintenance. We d hope that this will also allow for even better cross distribution collaboration. Concerning early userspace I plan to release an initramfs-tools with more generic userspace for the default case and finally also a klibc only for embedded or tuning cases. What do you like most in Debian? For one thing I do like the 2 year release cycle. It is not too long to have completely outdated software and on the other hand it gives enough time to really see huge progress from release to release. Also at my institute the software is is recent enough without too much admin overhead. For servers the three years support are a bit short, but on the manageable side. I do enjoy a lot the testing distribution. For my personal use it is very stable and thus I mainly run testing on my desktop and work boxes. (Occasionally mixing in things from sid for unbreaking transition or newer security fixes). Debian is independent and not a commercial entity. I think this is its main force and even more important these days. I enjoy using the Debian platform a lot at work thus in return this motivates me to contribute to Debian itself. I also like the fact that we strive for technical correctness. Is there some recurrent problem that hinders the progress of Debian? The New Maintainer process is a strange way to discourage people to contribute to Debian. It is particularly bureaucratic and a huge waste of time both for the applicant and his manager. It should be completely thrown overboard. One needs a more scalable approach for trust and credibility that also enhances the technical knowledge for coding and packaging of the applicant. NM is currently set in stone as any outside critics is automatically rejected. Young and energetic people are crucial for Debian and the long-term viability of the project, this is the reason why I d consider the New Maintainer process as Debian s biggest problem. Note from Rapha l Hertzog: I must say I do not share this point of view on the New Maintainer process, I have witnessed lots of improvements lately thanks to the addition of the Debian Maintainer status, and to the fact that a good history of contribution can easily subsume the annoying Tasks & Skills questionnaire. Another thing I miss is professional graphics input both for the desktop theme and the website. I know that effort has been done there lately and it is good to see movement there, but the end result is still lacking. Another trouble of Debian is its marketing capabilities. It should learn to better sell itself. It is the distribution users want to run and use not the rebranded copies of itself with lock-in sugar . Debian is about choice and it offers plenty of it: it is a great default Desktop. Linus Torvalds doesn t find Debian (and/or Ubuntu) a good platform to hack on the kernel. Do you know why and what can we do about this? The Fedora linux-2.6 receives contributions from several Red Hat employed upstream sub-Maintainers. Thus it typically carries huge patches which are not yet upstream. As a consequence eventual userland troubles get revealed quite quickly and are often seen there first. The cutting edge nature of Fedora rawhide is appealing for many developers. The usual Debian package division of library development files and the library itself is traditionally an entry barrier for dev on Debian. Debian got pretty easily usable these days, although we could and should again improve a lot more in this sector. Personally I think that Linus hasn t tried Debian for years. I have the feeling that the implication of the Debian Kernel team in LKML has been on the rise. Is that true and how do you explain this? Ben Hutchings is the Nr.1 contributor for 2.6.33. He also is top listed as author of patches on stable 2.6.32. Debian is not listed as organization as many send their linux-2.6 patches from their corporate or personal email address and thus it won t be attributed to Debian. There is currently no means to see how many patches get forwarded for the stable tree, but I certainly forwarded more then fifty patches. I was very happy when Greg KH personally thanked me in the 2.6.32.12 release. In the Squeeze kernel, the firmwares have been stripped and moved into separate packages in the non-free section. What should a user do to ensure his system keeps working? There is a debconf warning on linux-2.6 installation. It is quite clear that the free linux-2.6 can t depend on the firmware of the non-free archive (also there is no strict dependency there technically). On the terminal you d also see warnings by update-initramfs on the initramfs generation for drivers included in the initramfs. The debconf warning lists the filename(s) of the missing firmware(s). One can then apt-cache search for the firmware package name and install it via the non-free repository. The check runs against the current loaded modules. The match is not 100% accurate for special cases as the one where the device might be handled well by this driver without firmware, but is accurate enough to warrant the warning. The set of virtualization technologies that the official Debian kernel supports seems to change regularly. Which of the currently available options would you recommend to users who want to build on something that will last? KVM has been a smooth ride from day zero. It almost got included instantly upstream. The uptake it has is great as it sees both dev from Intel and AMD. Together with libvirt it s management is easy. Also the performance of virtio is very good. The linux containers are the thing we are looking forward for enhanced chroots in the Wheezy schedule. They are also manageable by libvirt. Xen being the bad outside boy has an incredible shrinking patchset, thus is fair to expect to see it for Wheezy and beyond. For many it may come a bit late, but for old hardware without relevant CPU it is there. Many tend to overstate the importance of the virtualization tech. I d be much more looking forward to the better Desktop support in newer linux-2.6. The Desktop is important for linux and something that is in heavy use. The much better graphics support of the radeon and nouveau drivers:

• For Nouveau in 32 with 33 drm we could only deliver a first taste meaning something better then rusty nv.
• For Radeon the support for Evergreen and newer is only been shaping now.

The performance optimizations thanks to dcache scalability work and the neat automatic task-grouping for the CPU scheduler are very promising features for the usability of the linux desktop. Another nice to have feature is the online defrag of ext4 and its faster mkfs. Even cooler would be better scalability in ext4 (This side seems to have seen not enough effort lately). Is there someone in Debian that you admire for their contributions? Hans Peter Anvin and Ted Tso are a huge source of deep linux-2.6 knowledge and personal wisdom. I do enjoy all sorts of interactions with them. Christoph Hellwig with Matthew Wilcox and also William Irwin for setting up the Debian kernel Team. Several Debian leaders including the previous and the current one for their engagement, which very often happens behind the scene. The Debian Gnome Team work is great, also the interactions have always been always easy and a pleasure. Martin Michlmayr and previously Thiemo Seufer do an incredible job in porting Debian on funny and interesting ARM and MIPS boxes. Debian has a lot of upcoming potential on this area. I m looking forward to other young enthusiastic people in that area. Colin Watson is bridging Debian and Ubuntu, which is an immense task. Michael Prokop bases on Debian an excellent recovery boot CD: http://www.grml.org. I d be happy if any Debian Developer would work as carefully coding and working.

---

Thank you to Maximilian 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.

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

Using a virtual IP managed by heartbeat is a nice way to work around the slow fallback behavior with multiple nameservers in /etc/hosts. But unlike ntpd, bind9 doesn't automatically listen on new IPs on the system. Here's a cute hack to fix that:

# cat /etc/ha.d/haresources
server01 bind9release IPaddr::10.0.0.3 bind9takeover
# cat /etc/ha.d/resource.d/bind9release
#!/bin/sh
# when giving up resources, reload bind9
case $1 in
        stop) /etc/init.d/bind9 reload ;;
esac
exit 0
# cat /etc/ha.d/resource.d/bind9takeover
#!/bin/sh
# on takeover, reload bind9
case $1 in
        start) /etc/init.d/bind9 reload ;;
esac
exit 0

Another day, another "which ^(&^%*&*^&()* version should I use?!" with github: https://github.com/gramos/easy-fckeditor/network Github is nice, but very, very often all the forks are the very model of a modern major paradox of choice. Which one should I use? Which one is best? Do the forks exist because 1) the original author stopped bothering? 2) because the forkers just wanted to be 'cool' and have their own fork? 3) because the forkers don't have a clue about open source and don't attempt to submit their patches back? Who the hell knows, in most cases. This is frustrating. I had a random idea that might help some: if the 'network' view were able to show you, at a glance, the amount of interaction between different forks: pull requests accepted and rejected. At least we'd get an idea of what sort of community is forming around the project, and also have an idea whether the forkers and/or the authors are good open source citizens or not. Of course, as my friend Salvatore says, "pull requests are not conversations", but it's better than nothing.