The Foursquare Blog

Under about:config, set network.dns.disableIPv6 to true.

I've been experimenting with Debian Squeeze on an older T40 Thinkpad, and I've been noticing some disturbing trends. Trends that I probably haven't noticed since I haven't had hardware that new, and have been fairly happy using xterms and make on Debian Lenny.

I'm noticing a divergence between the command line and the GUI... a divergence that is horrifying. I installed the base system, got WiFi going using /etc/network/interfaces, and was happy. Then I installed the GUI, and my carefully configured network stopped working. The GUI had its own way to configure things. Yes, the GUI worked, if it was allowed to operate by itself, but that's not the point. Why have two? Why break one to make the other work? I still don't know where the GUI stores its network settings. They sure don't show up in the /etc config files.

Divergence #2: DNS works snappy from the command line, but somehow Firefox labours to find Google, or Slashdot, even though it was just there a few minutes ago. Really? This is 2010. I poke around the network with tcpdump to see what on God's green earth Firefox is doing. And it's looking up DNS entries for a tab I'm not even on.

Look, I know IPv6 is the next big thing, but don't turn it on unless it has zero impact on what people need right now. Let me easily choose which network has priority. And give me one place to set it. Not two. Not five. One.

So I say goodbye to Firefox and load Mozilla.. the ancient browser... it's worked for me in the past. Maybe it will be too old to fail. I load my home page, and watch the network with tcpdump. I see it going through the page, looking up DNS for all the links. Great, I think, at least it will be cached for me. I click on some links. A little better at first, but soon goes downhill. Still more forgetful than an Alzheimer's patient.

Why is it so hard to get networking working in 2010? My friend went through this with Ubuntu back in 2007, and it didn't work right. At least now it sort of hobbles along, but back then, NetworkManager only managed to dig itself a grave.

Enough about networks: my laptop is fairly old, and the battery is getting flakey. This is to be expected, I don't mind, the battery is still useful for an hour or two, and I'm happy. So I load up Gnome and work away on the battery. The icon shows me the battery discharge progress. Then it gets to the point where the battery is low. It pops up a gigantic black notification message, over top of other windows, telling me this. Fine. Thanks, I guess. Go away now. Then it gets critically low, and shows me another one. Ok ok, I get it, calm down. Then it alternates back and forth between low and critical. I even saw two notification messages on the screen at once... hiding other windows that I needed! And there is no way to turn these off! Unbelievable. Do I have to hack the code to get rid of these monstrosities? Why not just warn me once and let me deal with the consequences? Why pester me and assume I have no brain? I know the battery is low. I know that means I have 30 minutes of power left. Stop telling me what I already know!

Does every poor end user need to download some Gnome C code, and hack around in the code to figure out how to tune the system? I've already had to do it once to figure out how to disable automatic Suspend mode, when the GUI helpfully left that option off the menu. Now again for notifications? Good grief on a stick!

Poor Linux. Everybody running around the system, coding their own little kingdoms in their own little sandboxes, and the distros are including it as if it was something stable for end users. The kernel guys do one thing, the udev guys do another, the hotplugging notification guys do something else, the GUI guys do yet more (in multiple different ways, of course), and the user tries to push a rope uphill, suffering with a very busy but confused system crippled by lack of configuration options in the menus.

Dear programmers: the first setting you should code in your next fancy new feature is how to turn the bloody thing off.

I feel the need to post about this issue in the hope that similar problems can be avoided in the future.

My initial disclaimer is that I'm not a package maintainer for any of the major distros, so I'm not intimately familiar with the stresses or workloads that they may face everyday. I am, though, the lead developer on a project that I hope one day will be included in major distros.

Whenever I get some interest from potential distro maintainers, I try to stress my keen interest in getting any downstream patches. This is to hopefully lighten their workload as well as to improve the software for everyone.

Unfortunately, it appears to me that the patch that caused the trouble in Debian recently was not fed back to the upstream developers, and if it had, it may have been caught much earlier.

What can be done from an upstream developer's point of view to encourage these upstream patches to keep flowing?

And is it not almost a duty for all downstream package maintainers to send patches upstream whenever possible?

Perhaps in some cases, the upstream packages themselves are not actively maintained, in which case being a distro package maintainer is even harder. But OpenSSL is not such a case.

I've run into 3 cases so far where a bad patch to the libtar library has sneaked into various distros and caused trouble for people trying to compile Barry on their systems. Would it not be better for these distro-specific patches to be fed upstream, and get rejected with a proper reason? Would it not be better for all distro maintainers of a particular package to be subscribed to its development mailing list, and see these issues first hand?

Obviously I think so, but I'd like to hear your thoughts on it. I think it is an issue that needs to be discussed, and now's the perfect time.