At the Emdebian ARM sprint, cross-building experiments on a Multi-Arch base are going fairly well. It is looking like the hacks in dpkg-cross may finally be avoidable, possibly before Wheezy gets released. Elsewhere, debhelper has been updated to allow dh_strip and other tools to work directly with the binutils package from the cross-building toolchain and not to need binutils-multiarch any more. dpkg-cross has been updated to only Suggest binutils-multiarch, which makes room for more architectures to be covered by binutils-multiarch (which, therefore, will be getting quite a lot bigger quite soon).

Cross-building in Debian is therefore entering a period of transition and the old ways of dpkg-cross - and the tools it has spawned like apt-cross, xapt, pdebuild-cross and others - will be gradually side-lined and finally rendered obsolete. Like all transitions, there will be breakage, there will be pain, there will be things which don't cross-build now and which have no prospect of being fixed until the transition is deeply entrenched. There are packages which used to cross-build and which will stop cross-building and, again, won't be fixable for months. Sadly, Squeeze released with cross-building breakage too, due to changes within apt during the release freeze. A Lenny chroot is possibly the best place to do cross-building for now.

This is a major transition. It WILL break things. Badly and often.
What's more, just because we decide to implement stuff using one method now does not mean that the same method will even exist in a month or two.

In other words, if you've got a working cross-build chroot or installation currently and you absolutely need it to continue working leave it alone.

Don't go changing real packages to use the changes we're trying out!

If you enjoy fixing stuff, don't mind pain and fancy risking your system as I've been doing (unlinking /etc/, deleting /lib64 on amd64 or forcing package installation such that no shared libraries are accessible any longer) then you are:

1. insane
2. welcome to join the work

Check out the current state of things via the #emdebian channel on oftc.net and the very risky Emdebian multiarch SVN experiments along with the even more risky Emdebian Multiarch Mirror, courtesy of Steve McIntyre and Phil Hands.

The README in SVN is very clear - DON'T INSTALL THESE OUTSIDE A CHROOT and even if you do, don't come crying to me when it breaks your entire system (even when used inside a chroot).

No warranty, no guarantees, no promises, none of this is fit for any purpose whatsoever and we'll say when we finally have something which might actually be useful.

Sometimes, free software isn't better than proprietary, it's true - and one of the principal reasons is that the majority of free software does not use the full power of the freedom of the software. Far too many free software projects are single-developer projects. Many single-developer projects at SourceForge or Savannah and elsewhere have a single maintainer for the distribution providing the packages too and some (including nearly all of my own) have one person doing both jobs. In other words, there is no collaboration upstream or in packaging, so there is little or no benefit to the code of being free software...

It begs the question of what happens when the omnipresent developer-under-a-bus risk actually bites.

When comparing free software and proprietary, considering end-of-life effects can be very illuminating, especially when considering the interests of third-parties who come to rely upon the output of the project. When a proprietary software producer declares a software product to be end-of-life (whether due to collapse/purchase of the company or some other restructuring) third parties are left high and dry. In effect, all proprietary software is directly equivalent to a single developer writing free software. The more important the software, the worse this gets because at least if the single free software developer does disappear, the third party can try and pick up the pieces.

The bigger problem for free software is the common failure to actually collaborate. This has been my main upstream bug bear for a long time now. The model must change. New contributors must be dissuaded from writing new code just because they prefer one language over another. Distributions need to change their guidelines for new developers to actively discourage new packagers from starting with new upstream code. We are in danger of undermining the main appeal of free software by not stamping harder on the NotInventedHere (NIH) syndrome. NIH is pernicious, NIH is dangerous and there is even an argument for considering NIH as an anti-feature.
New is considered harmful
New is not necessarily a good idea, new can be positively harmful to the interests of the wider software community. New promotes reinventing the wheel. It's another incidence of "Just because we can, does not mean we should."

If free software advocates neglect to counteract the poison of NIH, then free software will lose the argument by losing the fundamental merit of free software. A freedom which is not utilised is akin to not having that freedom at all. Yes, someone can pick up a free software project after the single developer abandons it but, in practise, what actually happens is that someone else comes along whilst the single developer is struggling along alone and decides to fall prey to NIH simply because the original is written in C and their preferred language is Python or Ruby or Haskell or whatever.

The "choice" argument is simply invalid - providing another implementation of program foo in a different language is just a way of reinventing the bugs already fixed in foo in new ways in a new language - and then adding some more which are unique to that language. Yes, the new developer might argue that the new code is more active but for how long? Long enough to become just as stable as the abandoned code? What benefit is that? In a few years time we will have two abandoned codebases in two different languages written by two different developers who never collaborated on the actual problem both of them were trying to solve independently. Lunacy.

The dilemma for distributions like Debian is that the list of Debian Packages that Need Lovin' is a burden to Debian during a release freeze yet provides an ideal launchpad for new developers to refresh stale code. I've long thought that Debian needs to be more strict on removing such packages, yet at the same time I cannot help but feel that this tends to encourage more NIH behaviour.

It's a common mantra amongst free software developers that many eyes make all bugs shallow. The problem for free software is that outside certain key teams, there are simply too few eyes and the community is not doing enough to shine a light on existing code before dancing to the sound of the NIH drum.

Far too much free software is at risk from that omnipresent bus called "RealLife" and this makes far too much free software little better than proprietary software. Pandering to the fashions of NIH only makes things worse.

This isn't a technical problem that can be solved with a new cool tool (which itself is subject to the NIH poison), it is a social problem and, sadly, the free software community has a history of failing to tackle purely social problems successfully.

There is a small role for existing technical solutions to make it easier to spot NIH tendencies, including sites like SourceForge and Savannah having greater scrutiny about new projects and distributors like Debian being more averse to adding yet more ITP bugs (or closing them automatically unless something happens within a month). Fundamentally, it comes down to how new and existing members of the free software community decide to handle their own projects and bugs. The model of "do it this way because that's more fun" has got us so far, the challenge is to remove NIH tendencies without removing that fun.

A continuation of my intermittent series on Emdebian. This time covering how Emdebian changes component behaviourin Emdebian Grip.
Debian divides packages principally between those which comply with the DFSG (main), those which do not (non-free) and those which could but depend on those which do not (contrib). This leads to an enormous bias towards packages in main, which is good in terms of DFSG compliance but not so good for the size of the Packages files which every machine has to download to be able to install new stuff or upgrade existing stuff.
Emdebian is as concerned about the runtime space requirements of the system as much as the install time space requirements. Little point gaining 20Mb by removing stuff from packages if the next apt-get update adds 30Mb of cache data.
Therefore, Emdebian Grip sub-divides main (we don't have contrib or non-free packages at this time). This gives most users the smallest cache data size whilst allowing other users to add the extra components and get the full list of packages provided in Emdebian.
Alongside this division, the aim with emdebian-grip-server is to help others run secondary Emdebian Grip build machines which have a different range of packages. This allows one server to focus on XFCE and one to use other desktops or no desktops.
Components in Grip
Grip subdivides Debian main into main (~60%), dev (~30%), java, debug and doc components. The main emphasis, therefore, is that most Emdebian Grip machines will not be used to actually build other packages. I covered some of the theory on this step on the debian-embedded mailing list in 2009.
Component allocation
Packages are allocated to particular components by three main mechanisms:

1. Package name suffix - -dev packages into dev, -dbg packages into debug, -doc packages into doc.
2. Section names - devel goes into dev, java goes into java
3. Override files which are visible via the emdebian website.

Override files cover situations where a package is in a problematic Section (e.g. dbus is in Section: devel when it is almost impossible to have a netbook or graphical Debian installation without it). Once Squeeze is released, I might take up these overrides with ftpmaster to see if some rationale can be constructed to make things easier.
Sources
The use of components means that an Emdebian Grip device can choose a range of components in the apt sources line. Any permutation as long as main is preserved.

deb http://www.emdebian.org/grip squeeze main dev debug java doc

More on Filtering
I mentioned last time that Emdebian does not carry all packages available in Debian. As well as filtering the files contained within packages, Emdebian Grip filters the list of packages which are allowed into the repository for each server. This is why Emdebian Grip has under 3,000 packages to be released alongside Squeeze. (Emdebian Grip 1.0 based on Lenny had some 1,000 packages.)
Filtering the list of packages means that the maintainer of the server gets to choose their package set in a similar way to how tasksel can be used to select a functionally complete set of packages at installation time. (Indeed, Emdebian Grip provides some bespoke tasks which optimise the combination of tasksel and repository filtering.) Processing packages for Emdebian Grip takes a finite amount of time per package, per architecture and restricting the total number of packages in Grip has several advantages:

1. Further reductions in cache size - less files in the Packages file, less Packages data to download and cache.
2. Less processing time which makes it easier to maintain an Emdebian Grip server
3. Less data to mirror which makes it attractive for admins already running a full Debian mirror to consider squeezing in Emdebian Grip alongside.

Combining component changes and filters needs a little bit of careful handling in the server side code so that packages remain installable. Override files need to be adjusted manually, library transitions mean that once libfoo0 has been replaced by libfoo1, anything depending on libfoo1 is broken in Emdebian Grip until libfoo1 can be added to the repository (which is also a manual task). I'm glad that edos-debcheck is regaining a machine-parseable output format because this will add the chance to make at least some of these transition additions automatic. Other than these tasks, emdebian-grip-server is almost entirely automated and runs as a cron task creating verbose log files each run.
The server task runs edos-debcheck for each supported architecture and for each suite, carefully combining the various Packages files from the available components. As an alternative assessment, Debian Weather runs edos-debcheck over the Packages file for the main component only, for each suite and each architecture in Emdebian Grip. The combination of the two provides invaluable data to spot missing packages.
Equally, there are times when packages disappear from Debian. Currently, the automated scripts don't handle this aggressively but manual support scripts are available, usually for use before a release when the suites are changing less frequently.
I'll cover migrations between suites next time. In the meantime, if you want to prepare your own package set for Emdebian Grip, install emdebian-grip-server from experimental and file bugs to improve the documentation.
Thanks to those who took on the Herculean task of translating the emdebian-grip-server manpages into German and French - more translations are always welcome. POT file contained inside the source package.

Developers are not usually the right people to write documentation, but in an effort to encourage more Debian folk to consider Emdebian, I'm starting an intermittent series of blog posts to describe how Emdebian works and how it fits with Debian. Emdebian has a variety of ideas and experiments but the principle distribution, to be released alongside Debian Squeeze, is Emdebian Grip. This post, I'll cover the basic stuff. Feel free to let me know if there are particular issues you'd like covered. In particular, if the documentation on the Emdebian Grip website needs improving, let us know.
What's Emdebian Grip all about?
Simply a smaller Debian. Smaller packages, smaller downloads, smaller sets of packages, smaller installation sizes and smaller update sizes; yet always and completely binary compatible with Debian. Every backtrace from an Emdebian Grip device will match the backtrace on a Debian machine of the same architecture, package version etc. Packages can be mixed trivially (with some allowances for strict dependencies like -dbg packages). The name is a derivative of Squeeze - to make Debian smaller, we take a hold of it; Grip it.
Is it cross-building?
NO. Emdebian Grip is not recompiled (natively or cross), it is processed. Packages natively built in Debian are unpacked, files removed and repacked on the server before being included into the Emdebian repositories. dpkg and perl do all the work, not gcc.
What gets taken out?
Translations move out of the source packages and into TDebs (organised by locale) and compiled .mo files are then removed from the binary packages. Manpages and other documentation is lost entirely, copyright is compressed and changelogs are removed. None of the binary files are touched. The SHA256 sum of your /usr/bin/foo executable in Debian will be precisely the same in Emdebian, the same applies to libraries.
How is it done?
The emdebian-grip-server package in Debian processes the package and treats every architecture in the same way. (This allows Emdebian to carry unofficial ports like SH4, armhf etc.)
Why not filter stuff with dpkg?
The straight answer is that there usually isn't room to download the large package first in order to strip it on device. Also, filtering on device is slow. Stripping the package on the server means that the work is only done once. Every Emdebian device is saved the effort of filtering the files one machine at a time. Grip effectively does what dpkg filtering does, just it does it on the server, repacking the results into a new .deb. Instead of every device doing the task again and again, the server does it once.
Why is my pet package not included?
Emdebian restricts the number of packages which are included in the repositories (less than 10% of Debian packages will be included in Emdebian Grip 2.0 which is based on Debian 6.0 "squeeze") but provides tools which can be used (on device or on the desktop) to prepare any other package for installation on an Emdebian Grip device. There is no need for the machine preparing the package to be of the same architecture as the intended device because all processing is architecture-neutral.
Who decides which packages get included?
Me, basically. The merits of adding particular packages is usually discussed on the debian-embedded mailing list. Typical criteria (in rough order) include:

1. Subjectively suitable for an embedded device (so OpenOffice.org does not qualify)


2. most, if not all, dependencies already included in Grip


3. already available in Debian testing


4. not in a state of churn in Debian (rapid upload cycles, frequent library transitions etc.)
   
5. not particularly buggy in Debian

Can I convert Debian to Emdebian Grip
Yes - simply add Emdebian to your apt sources list and watch as your next upgrade releases tens of megabytes of space.
What are these em1 version suffixes?
Emdebian modifies Debian packages, albeit in an architecture-independent manner, by removing files. The resulting packages are therefore different to the originals, albeit containing compatible binaries. Hence, the Emdebian processing adds the em1 version suffix to show which version is installed. Adding the suffix also means that every Emdebian package is considered to be an upgrade compared to the equivalent Debian package, if both exist in your apt sources.
How is Emdebian Grip installed?
It is possible to use Debian Installer (we provide pre-seeding files to help this process) or create a simple tarball using multistrap if that is more suitable for your device.
What about Recommends: ?
Debian defaults to installing all packages listed as Recommends in the package metadata. Emdebian simply drops the entire Recommends field when processing the package. Suggests is also omitted. This dramatically shortens dependency chains and gives developers full control over which packages are installed. It is important here to consider the embedded device user interface. Recommends exists to support those users who need the extra parts of the package, the bells and whistles. Embedded devices strictly control which parts of the package is actually exposed to the user - there is no need for a menu or a desktop. Users can only access the functionality exposed by the device, so no bells and whistles - just the base system and whatever you choose to expose as part of the interface. Rather than require all Emdebian devices to turn off Recommends individually, Emdebian simply drops Recommends at the server and allows the developer to cherry-pick which packages to add.

More to follow . . .

There must be other organisations across the world which do a similar job but this is the local one for me and in lieu of actually getting to a Remembrance Day event this year (I'll be at a bug squashing event for Debian Squeeze), I'm using my blog, just this once, to express my own thanks to those who gave their lives that I may be free to do what I enjoy, writing code to make things just work.

Just in passing, if anyone wants to support my work in Debian and/or Emdebian, there is a simple and free way to do it. Send me some patches, especially for documentation, translations and examples.

I have more than enough stuff that I could be doing and I do hear from users who want more stuff done to suit their particular requirements. Sorry, but time is finite and whilst a "thank you" is always appreciated, it doesn't actually generate a 25 hour day. So please don't just tell me what you want or why the current stuff doesn't do what you want it to do. The source code is all just "out-there" and you know more about what you actually want than I ever could.

If any of my code doesn't quite do what you want, please don't moan about it or file bugs that just moan about it, work out why and how and fix it - get involved. That way, the code will develop even if I don't always have time to work on it.

Neil asks about removing debconf old values when replacing a package with a different one. Usually, you shouldn't need to worry about this; when the old package is finally purged all its debconf values will be cleaned up. In case that doesn't happen for some reason, you do not need to include the templates in the new package in order to get them removed. Actually, due to debconf's reference counting, that shouldn't work anyway. What you need is debconf-communicate(1). Specifically, something like this in a maintainer script of the new package, before it sources debconf's confmodule:

echo purge   debconf-communicate oldpackage

(Updated: Fixed incorrect syntax!)

---

Meh, databases add such complexity.. If I were redesigning debconf today, it would use flat files on disk and those files would be removed by dpkg on purge.

I've been trying to work out how to handle (or whether to handle) the vestigial debconf values from emdebian-tools which was replaced in Debian some months ago. I tried to transfer the postrm script to libemdebian-tools-perl which itself is currently a transitional package. Turns out that when debconf tries to purge libemdebian-tools-perl, it doesn't purge the old emdebian-tools settings (it looks for libemdebian-tools-perl.templates instead of emdebian-tools.templates) - unless those were themselves setup by libemdebian-tools-perl. i.e. users with the original emdebian-tools setup will likely have debconf settings that are not purged by removing the package to which those settings should have migrated.

I have reconstructed a bare templates file locally and a simple script that can purge those values and it works on my system - I'm just not sure if this should be implemented in what is now merely a transitional package (libemdebian-tools-perl) which exists merely to support migrating to the current emdebian-crush package.

It's only three fields - single word values - and debconf settings are only a cache after all. Comments are still disabled on my blog but my email address isn't hard to find. If people really think it's worth writing code to "catch-up" with these redundant settings, I can do something after Squeeze. What I don't want to do is reintroduce debconf templates which are no longer used, merely to remove old settings left behind from the first migration.

So, lazyweb, what's the feeling? Is this worth doing anything about?

This took a bit of searching, so it's here for reference. I'm sure it'll catch out people who upgrade from Lenny to Squeeze as the initial presentation can be deeply mysterious and frustrating.

I keep my pbuilder stuff outside /var/, so I have a file /home/neil/.pbuilderrc and until recently, this worked fine. Naturally, pbuilder needs sudo to call it, so sudo pbuilder update was a routine command. Then it suddenly stopped working and it was mysterious, pbuilder was looking for /home/root/.pbuilderrc which was just weird. root/.pbuilderrc might make a little more sense, /home/root is just plain wrong.

First, blame pbuilder, no, not changed recently - certainly not since I last ran the command successfully. Hmm.

sudo then? Recently updated, aha, the changes listed in the PTS describes something being documented in NEWS.Debian relating to pbuilder - dig, dig, the answer (indirectly) was in the README. Need to add a command to user lines in sudoers:

, env_keep+="HOME"

Also, act on this guidance in sudo visudo:

# Uncomment to allow members of group sudo to not need a password

Even more nastily, sudo does still need a password (because I've set rootpw later) but this line is still required.

Now restart sudo sudo invoke-rc.d sudo restart which is horribly recursive. (Yes, I did mess up visudo at one point and have to use just plain su to get back access.)

Ho hum. It works, so why do I feel that I've done something bad?

(comments still disabled because of spammers - captchas simply don't work, neither does OpenID, so don't blame me. Those who know me already know how to contact me. The details aren't exactly hidden.)

Emdebian Grip 1.0.1 (based on Debian GNU/Linux 5.0.6) is now available.

Emdebian Grip is binary-compatible with Debian, providing smaller packages for use on embedded devices. Emdebian Grip selects a subset of Debian packages and removes documentation and other non-binary content without recompiling the source code. Currently, Emdebian Grip supports amd64, arm, armel, i386, mips, mipsel and powerpc in the stable distribution. ARM support will be dropped in the next stable release in favour of armel.

This is the first update of the stable distribution Emdebian Grip (based on Debian GNU/Linux 5.0), bringing Emdebian Grip up to date with Debian 5.0.6. This update mainly adds corrections for security problems to the stable release, along with a few adjustment to serious problems.

Please note that this update does not constitute a new version of Emdebian Grip 1.0 or Debian GNU/Linux 5.0 but only updates some of the packages included. Systems will upgrade to 1.0.1 via the Emdebian mirror after an installation.

For more details on the changes within Debian through 5.0.1, 5.0.2, 5.0.3, 5.0.4, 5.0.5 and now 5.0.6, see the Debian news website.

As well as updates to packages which already existed in Emdebian Grip 1.0, the update includes many new packages, including apache2, aspell and variants, and matchbox.

e.g. 822 packages were released for armel in Emdebian 1.0; this update increases that number to 1,297.

In case anyone else hasn't found these tweaks:

termcapinfo xterm xterms xs rxvt ti@:te@

In ~/.screenrc gives you Shift-PageUp and Shift-PageDown control again, without resorting to Ctrl-A Esc, inside screen. (Best to do

$ cp /etc/screen.rc ~/.screenrc

as a starting point first, if not done already.)

Also:

/set scroll_page_count /2

/save

In irssi itself (easier than editing the config) gives you internal PageUp, PageDown control within the irssi window.

In each case, the manpage is so long and impenetrable that these may be obvious to those with a special knowledge of terminals but mere mortals like me can't find it in / understand the docs.

Eben Moglen's talk at DebConf10 has inspired a flood of responses and activity at DebConf10. The original talk overran the allotted time within the venue and then outside the venue for something like an hour, HackLab discussions migrated to the single theme and brought in more and more people over lunch. When the Skype talk was left without a speaker in the afternoon, it morphed into a FreedomBox BOF with maybe 100 delegates planning and contributing to the ideas and another BOF is planned for Friday. A rough outline is appearing on the wiki page for those who want to follow it and the video of the original talk is available, linked from that Wiki page.

What gets people excited about this project is that we already have all the components to do the work, people have been doing most of this stuff at home, on their own, for some time and it needs to be brought together as a series of packages and meta packages and other middleware glue to get it working. (multistrap is part of that glue - it's already being used commercially in a similar role. Debian Pure Blends is another part of the glue. This can be a Debian solution, it doesn't have to be a separate project.)

The software and glue doesn't have to be dependent on a single hardware platform, this is about getting the software right and deploying it on whatever hardware can run it - albeit that the architecture itself is likely to be ARM-something.

It is time for social networking to be freed from the man-in-the-middle - time to withdraw user data from central servers owned by some third-party and share directly with your friends (whichever network they use). Aggregate all data from all your friends, keep all your data in your own plug and access it from wherever you are using whatever devices you have to hand. What's more, your friends - especially the non-techy friends - can just buy a cheap beige box that hides away in the corner of their home and have all the same access too - everyone gets to choose exactly which pieces of data get shared and to whom and can then use their friends plugs to store encrypted backups of their other data. Or maybe the final solution will be slightly different - it's up to people in Debian to make it happen. The tools are in our own hands, if we want this, we just need to do it.

What is needed now is some direction, there are choices to be made about how the glue is designed and how this is turned into a "self-discoverable" distributed network service. Yes, IPv6 will make this easier but only once ordinary users can deploy the device transparently and without configuration, so an interim solution will be needed.

Who's up for the challenge?

check-deps.sh
Phil Hands and I devised a little script which is currently packaged as part of multistrap to check the dependencies of a .deb package before installing it - called check-deps.sh and can be found at /usr/share/multistrap/check-deps.sh. I just thought I'd publicise it a bit because it can help with one of my common test cases - when a binary package changes dependencies but you haven't uploaded it yet.

check-deps.sh takes a .deb to the command line -f --file option and outputs the dependencies of that .deb and whether those dependencies (at the requested versions) exist in your apt-cache policy. Optionally, you can use check-deps.sh to also then install those dependencies (not the dependencies that would come from the current version in the repository) and the package itself.

I've found this to be a much more friendly way of satisfying runtime dependencies of a package. Where things like pbuilder would just force install the .deb and then get apt-get -f install to try and fix things, check-deps.sh will fail if the required dependencies are not available in the first place.

The benefits are two-fold. First you get to see the full list and you can easily see if your work to drop a dependency has just resulted in another package bringing that dependency back in etc. Secondly, you can test whether your .deb is installable without breaking your system and then having to remove it - e.g. against backports or a Debian derivative test chroot. It should be possible to extend the script to read Build-Depends but that means reading the input from the source package, not the built binary. Might be just as easy to have a second script for Build-Depends.

(Comments are still disabled due to spammers and time-wasters, but if you would like to see check-deps.sh more widely used or extended it isn't that hard to find my email address at debian.org.)

xapt
Another new perl script, this time using the multistrap and apt-grip core to replace the apt-cross breakage to install cross-dependencies of a Debian source package. xapt has very few dependencies (dpkg-dev, dpkg-cross, apt, perl) and very simple logic. It doesn't try to second-guess which packages to use as dependencies of cross packages, it just gets them all. As such, it still isn't the tool we need for optimal cross-dependency resolution, but then neither is apt-cross - come to that, Multiarch or sysroot aren't going to provide the right tool any time soon either. So xapt at least gets over the worst of the design problems in apt-cross (by not using the apt perl bindings mainly) and seems to just work within clean chroots which is where apt-cross has the most problems.

xapt will be a new binary package, so it will need to go through NEW but I'm looking at using it as part of pdebuild-cross because it is faster than apt-cross and seems to work much more efficiently than apt-cross inside a clean chroot. xapt does not care about multiarch or sysroot, it just gets the packages and passes them to dpkg-cross. Normally, xapt cleans up after itself but you can choose to leave the built packages in /var/lib/xapt/output if that is useful.

I've grown tired of the firefox/iceweasel memory hog for a couple of reasons:

• it is such a memory hog and this isn't a machine particularly short of RAM but I still notice it when compiling with a few FF windows open and FF is just generally slow.
• the upgrade behaviour of iceweasel is getting tedious, begging for a restart every time I do apt-get upgrade recently.

Chromium is just faster, everywhere. A nice touch is the new tab behaviour too - previews of the most recently viewed pages is far more useful than the usual homepage. Chromium is also faster than epiphany/webkit.

I'll still be using two different browsers, because neither iceweasel nor chromium can do the clever smart bookmarks thing of epiphany. I have come to utterly rely on bookmark input boxes for direct access to specific Debian bug numbers, individual PTS pages, Google searches, dwww searches, specific manpages, buildd reports and various other pages where a bookmark really needs to be an input box, not a label, and the bookmark itself sits on a toolbar and can then use http://url/%s which makes life so much easier.
Update
I wondered if epiphany smart bookmarks would be understood but apparently not. So:

The smart bookmarks are BTS, Google, PTS, buildd and man. At work, I've got a wider screen and I add several more for internal bug tracker numbers and similar.
Chromium and iceweasel/FF have nothing like this. Entering a bug number is utterly trivial - it even works with middle mouse button paste which, cleverly, opens the page in a new tab too. Iceweasel/FF can do this ONCE but only once, via an extension. The key points with epiphany are:

• It is trivial to setup - just make a bookmark with a %s and put that bookmark onto a toolbar - any toolbar.


• it is trivial to use and never needs any use of the address bar or editing anything


• It works for any query which can have a single argument at any point in the URL.


• You can have as many as you want, subject to how many toolbars you can use

So, yes, Leo, the way epiphany does this is massively more effective for a "work-type" browser situation where there is such a need to access a specific page immediately, with no editing or keyboard usage.

Neil Williams recently commented on the lack of smart-bookmarks in Firefox/Iceweasel/Chromium and since the post doesn t accept comments, counter-post FTW.
Maybe I didn t understand exactly what was meant, but I m personally trying to see the advantage of having a smart-bookmark sit on the toolbar as opposed to just being a used via a label. Both FF/IW and Chrome can do the label thing, where you bookmark something like http://bugs.debian.org/%s with a shortcut like bugs and can then simply Ctrl-L to the address bar and type bugs 999999 . Done.
Can the way Epiphany does this be more effective? (actually this is the way Galeon did it way back then and I used to love it before I found out I could be way quicker with the keyboard+shortcut thingy. Not to mention having less clutter in the toolbar.) And granted: Chromium s interface doesn t allow the editing of this shortcut and they only work when imported from FF/IW, but I expect this to be fixed eventually. Doesn t make much sense to have such a hidden feature. [UPDATE: nevermind. As handily pointed out by Chris Butler, you can edit the shortcuts under Options Basics Default Search Manage. It might not be the most intuitive of places to put it, but it's there.] As for the rest of the reasons for switching mentioned in the original post, I can certainly see where they re coming from. No real solid counter-arguments there.