Debian

Christian, you forgot to mention the Linux kernel, where a member of the kernel team deliberately broke hardware support.
Thanks to Holger for these links, he has listed several more. I disagree with the suggestion that shipping the old firewire stack in the linux-extra-modules package is sufficient workaround; unless this is not prohibiting it from being included in the installer to support ethernet over firewire? (though in such case it will certainly have implications due to the fact that this package should be pulled in when the installer used eth1394)

So Adrian, you too may want to reconsider if Debian really does have less compatibility regressions than other distributions.

Wouter, I wonder why you didn't just rsync the whole filesystem over and used it as a chroot, while gradually rolling over services to the actual new system?

A month or two ago, I installed Etch/amd64 on a HP system which uses the ATI SB400 chipset. It worked great mostly, but sound was choppy from the start.
I decided this week to investigate and quickly discovered that oss emulation on this chipset is giving most people issues. It turns out the solution, for a GNOME desktop, is really simple: remove the libesd0 package and install libesd-alsa0 instead, so that esd does not use OSS emulation.

Which begs the question, could the Debian installation system be made smarter so that systems using ALSA drivers wouldn't use OSS unless for applications that only support the latter?

While I did not aim for it, it was a little disappointing to learn that I got soooooo close to hitting #350000.

Trying to build the unofficial Sarge DVD images for AMD64 today, jigdo-lite could not find several packages on the regular mirrors. Next it tried to fallback to amd64-cdsnap.debian.net, which I believe is a mirror listed in the jigdo template, but still failed to find them over there. Browsing the port pages, I found out that the Sarge release for amd64 is hosted on amd64.debian.net rather than that -cdsnap location. It seems those jigdo templates need an update...

Past monday (sunday night, actually) I was struck by gastorenteritis. I've had this before, but this time it was worse: even tuesday evening I had trouble eating anything small, my stomach turned all over itself again though I was fairly hungry.

On the upside, after a few days rest and once I started feeling a bit better again, I had plenty time to finish a pending upload for GNOME Apt. No new features, just some code refactoring on the inside – to fix bugs and compilation with newer library versions. One particular change was to substitute GnomeConfig with a simple replacement wrapper based on GKeyFile. I had two reasons not to use GConf: backwards compatibility, and the fact that I believe GConf is over-architectured for an application such as gnome-apt which rather needs a barebones configuration system instead. Only if I would figure out a way to initially run as non-root and do privilege elevation in-process rather than start from gksu or some similar helper, would it be useful to take a look at GConf again.
On a somewhat related note, I have also quickpatched my private copy of stormpkg to be installable again with libapt 0.6.x, but it seems that finally the archive has outgrown it's CList-based package tree implementation. When I tried to swap out gnome-apt's internal widget for a TreeStore, the latter turned out to be too slow to be usable, but the stormpkg CList could easily handle the same packages datasets and kept doing so for a while. But now it has become even worse than that TreeStore implementation used to be; apparently it has now crossed a certain threshold and it takes minutes even just to start. Time to let it go, it has had it's time.