Though rarely, interactions of mine with other members of the Debian community have been punctually more aggressive than I would have liked, and I have (almost) always regretted afterwards. I have no doubts there’ll be further occasions in the future in which re-reading posts like these, together with remembering my feelings while reading some of the surrounding posts, will positively affect the outcome of the situation. NP: Ant nia Font, Patxanga

I try hard not to hate Redhat, I really do. I don't visibly grimace when someone says "I'm running $REDHAT_DERIVED_DISTRO", and my first solution to "I can't get this to work on $REDHAT_DERIVED_DISTRO" is almost never "just install Debian,Ubuntu ". But Redhat makes it so hard to not beat them with a stick. For instance, I'm working on building a SOE for a client, and so I've got a bunch of scripts (calling random poorly documented and hard-to-find utilities) to help me do that. Naturally, I'm pruning the package list, which requires me to rebuild the list of packages which are on the CD. No problems, I can handle that. Oh, but the tool that builds the package list can't deal with the correct "ordering" of packages in the list. Why is ordering important? Because, and this will make you laugh, the installer can't actually deal with dependencies. Yes, that's right, anaconda will install your packages in any old order you specify, regardless of what is actually needed. Brain-damaged, certainly, but I've dealt with Windows, so this is ultimately a minor setback. The tools for building the packages lists are in a certain package, which I dutifully install. They then proceed to fail horribly. Why, do you ask? Because the script requires python modules from another package. Gee, wouldn't be handy if there was a mechanism by which a package could specify that it needed another package to operate? OH WAIT, THERE IS -- IT'S CALLED DEPENDENCIES, FOR $DEITY'S SAKE! YOU WROTE THE GODDAMN RPM SPECIFICATION, REDHAT, WHY CAN'T YOU ACTUALLY USE SOME OF IT'S FRIGGING FEATURES! But wait, there's more! Installing the package which contains the module doesn't actually make the module accessable to anything else on the system, because the module is installed in some god-forsaken, out of the way location, where Python fears to tread. You need to specify PYTHONPATH to make it work. Apparently someone was sure that specifying absolute paths in scripts (instead of letting the system search it's environment) was a bad idea, but didn't have problem with not putting modules in standard, well-known locations. Then, of course, the (other) tool segfaults. Why? Because it's reading an empty file. Wow. An empty file causes this thing to fall over in a screaming heap. Not "Sorry bub, but your file's empty" just an unceremonious segfault. Wow. Thanks. And that's even before we get around to actually doing an install...

A new release of Backup Manager has just been published: 0.5.9b

This release provides DVD burning support with growisofs and two new
methods for generating archives: one for backing up SVN repositories
(with svnadmin), the other for making generic archives based on the
output of a given command. Some bugs have also been closed, the
generated MD5 files are now compliant with the md5 program.

The Debian package will come soon…

Coding Mistakes

I broke my debian administration website yesterday. Predictably enough I’d woken up around 9AM and thought that it would be a good time to make significant refactering changes. Tested them on my laptop, committed them to CVS, then updated the live site. Had a quick play to make sure nothing had obviously broken - but didn’t try to leave a comment on an article. Went to sleep and woke up around 4pm to find 15 emails telling me things were broken. Most mails on the site in a single day! Should be fixed now. But I’ll never again make changes before lunchtime, I’m just not good with the whole sleepy-coding thing.

Things I have never coded: 1

Inspired by Joey Hess’s “Ten years of free software”. Things I have never coded part 1. I have never coded a text editor. *shock* In the past I have written simple wrappers around the various text controls in different environments - for example under Windows I once coded a tabbed text editor called MyNotepad, which featured a novel dockable tree-control to the side which allowed navigation and loading of files easily. When I first started working with Java I coded a similar thing, but with the ability to load external Java .class files as plugins. This editor was called Rosetta, inspired by the band Rosetta Stone (who were in turn inspired by the actual Rosetta stone ) At times I think about text editors. I use them daily, obviously, and I love working with some more than others. My editor is usually GNU Emacs but I’m also partial to Vim. I will use both happily; although neither is pleasant without my personal customizations. Simple text editors are a traditional project for coders, and freshmeat is littered with their discared corpses. Probably the only reason I’ve not started - that and apathy. My ideal editor would be:

• Both curses and x11 based.
• Scriptable (Lua is love?)
• Extensible.
• Portable between (at least) GNU/Linux and Solaris.
• Modeless.

Hey, no one asked me, but here are my endorsements for tomorrow’s city council election:

• Mayor: Maura Hennigan. I actually think Tom Menino is doing all right, and he will obviously win, so this is more of a “strategic” vote. I think it’s generally bad for elected leaders to be too certain of their grip on power, and voting for the challenger hopefully will keep them on their toes and more responsive to the community. It also may lay the groundwork for a better challenger in the next election four years from now. (This is why I voted for Bobbie Rush in Chicago in 1999, even though he had no chance of winning).
• City Council - At Large
  • Felix Arroyo: Hands down the best guy on the council. I heard him referred to as a “rock star” on WBUR this morning. I can’t think of anyone I would prefer for Mayor in 2009.
  • Matt O’Malley: I agree with him on just about every issue, plus there’s a strong Roslindale “home town” feeling for Matt. Someone showed me some of his campaign literature from the last time around where he was unfairly critical of Felix Arroyo, but my feeling (and hope) is that he has matured significantly since then.
  • Sam Yoon: Yoon seems to have the best chance of the newcomers/outsiders of actually getting elected, and he has been absorbed into the progressive fold with Arroyo, Chuck Turner, and Charles Yancey. That would be a nice block to have on the council. Certainly having the first Asian-American on the council would be a good thing as well.
  • John Connolly: Mostly, I just prefer him to the remaining four candidates. Although I’m a bit torn because I would also like to see more women on the council, I’m not convinced that Patricia White is the candidate to do it. Ed Flynn’s entire campaign platform seems to be “veteran,” and he opposes reproductive rights and same-sex marriage, so he’s (way) out. Steve Murphy lost my support when the only house in our neighborhood to sport large Bush/Cheney signs also posted Murphy signs. Michael Flaherty lost my support when he procedurally squashed a resolution that would have opposed the PATRIOT Act.

In any case, if you’re a Boston voter, be sure to participate tomorrow, whomever you choose to support.

So, finally we got it out. You can buy right now from the web page http://www.nokia.com/770 and in US starting from 11.11.2005. It works with Debian GNU/Linux, so you will have a Debian machine in your pocket, right beside your Debian installation CD/USB key. If you applied for the developer program, you should be getting it soon. PS: If you think this is Spam, killfile me. But i still think this is fun, having Debian in my pocket.

Poor Guido Boehm is suffering a lack of Google Juice, as searching for him results in the Devil's Pie home page. Hopefully this will help Guido out!

My laptops all run MasqMail so that they can always send mail, no matter where I am. This is good, and works very well. However, masqmail is suffering from non-maintenance. So, do I change my MTA, or do I adopt MasqMail? Ideally I'd switch to another MTA, as long as it's simple and will automatically change the delivery method depending on some external data (generally the name of the current network interface). Any suggestions? Or should I start reviewing the bugs and hijack the package? Update: Oliver Kurth, previously absent maintainer of MasqMail, just did a new upstream release and uploaded to Debian. Dilemma over! NP: In Between Dreams, Jack Johnson.

From now on, I’ll be using dato(at)the-barrel.org as my main address, instead of asp16(at)alu.ua.es. (But this second one, provided by my Uni, will continue to work for some more years, and not unlikely forever.) I was not that dissatisfied with the MX host for alu.ua.es, but it has been getting on my nerves on occasion during the last five years, so I decided it was better for my health to make the change. Kudos to Alberto Gonzalez Iniesta (agi@d.o) for being my postmaster from now on, since I really didn’t feel like running my own mailserver. The story behind the-barrel.org is certainly not unrelated to this Google search.

Stumbled across a blog post earlier today on a cool new “connection sharing” feature in SSH 4.0. Basically it multiplexs multiple SSH sessions over a single TCP connection so that subsequent sessions don’t suffer the key exchange and round trip setup delay. Given that I use SSH extensively to a small number of hosts pretty much continuously during my work day this sounds like a very handy feature for me. Read more at: http://little.xmtp.net/blog/2005/11/04/ssh-connection-sharing-c-visibility-share-libraries-and-gcc-attributes-oh-my/ In other knews, I’ve been doing some more hacking on darpwatch as a result of some patches I received, so there will be a new release happening soon there. I’m still battling away against Glade, GTK# and F-Spot in my quest to get all my photos exported out of gallery and into a nice F-Spot + Original setup. Updated PHPwiki packages have been built and have been pending upload for a week or two now, but my sponsor is quite busy at the moment, so there is a bit of a delay at that point inthe path. If you’re desparate for the new packages you can grab them from http://www.mattb.net.nz/debian/.

The Canberra Perl Users Group is having one of its extremely irregular meetings next week. If you're in Canberra, or will be on November 2, let me know. The last one wasn't too bad. http://mail.pm.org/pipermail/canberra-pm/2005-October/000146.html

One of the things about the whole money thing and free software is the question of whether it’ll take all the fun and spontaneity out of hax0ring. As it turns out, that doesn’t even work when you try; so instead of doing dak work last weekend, like I’d planned and like the market was indicating, I ended up hacking on britney until about 5am Sunday morning, leaving the dak stuff to be spread over the week, instead. (After the last post, dak might seem cursed, but trust me it’s not. More on that RSN, but not just yet) For those playing along at home, britney is the name of the scripts used to update Debian’s testing distribution; basically it automates some of the hard problems of Debian release management. Naturally, this is a pretty tricky job – there’re over 200,000 packages in Debian unstable (spread across eleven architectures), with fairly complicated sets of interdependencies amongst them. It gets complicated enough, in fact, that the core analysis britney undertakes isn’t just too processor intensive to do in perl or python, it’s too memory intensive to use standard malloc for its data structures. (Cynical and Coding, and the UQ CS228 class of ‘98 will probably have some idea of the fun to come at this point…) The problem is that britney uses an absurd number of linked lists to resolve dependency issues, with each entry in the list being an independent block of a dozen or so bytes; and adding the usual malloc overhead to this can effectively double the memory usage. Worse, britney also likes to reuse memory quite a lot, does a fair bit of backtracking, and generally acts like the prima donna she is. Up until last week, britney’s memory was managed by the use of a parallel bitfield indicating whether memory was free or not: so britney would first allocate a 128kB block using standard malloc, note it’s all free, then every request for 12 or 52 bytes would result in some bits being twiddled; and every free would twiddle the bits back, so they could be reused later. This means two things: one is that the free invocation has to include the size of the memory to be freed as well as the address, and the other is that finding an appropriate sized block of freed memory can be awkward, leading to some degree of fragmentation. This fragmentation seemed to lead to britney having a gradual memory leak, which would mean that if the release managers were doing some complicated transitions gigabytes of memory would end up being used and OOMing; or, since britney runs on ftp-master and it’s probably not a good idea to have the OOM killer start on the machine that ensures the Debian archive’s integrity, the ulimit is reached, and britney aborts unhappily. Unfortunately, though, the use of a “roll your own” malloc means you can’t use the standard memory checkers to see what’s going on, so you’re left with guessing and hoping. And as a consequence the memory leak’s been around for ages, causing fairly regular minor annoyance. This changed last week when Micha Nelissen (neli) got into the act:

<neli> why does it need so much memory ?
<aba> neli: because it needs to check how the changes affect the installability count
<neli> aba: ok…but still does not seem like a big deal
<neli> how large trees are we talking then?
<aj> it has to do a lot of backtracking
<aj> how large is the longest dependency tree in debian?
<neli> backtracking only takes time, not space, right?
<aj> you need a list of things to backtrack over
<aba> neli: it also consumes memory, at least with the current dpkg-implem ntation
<aba> (well, there are ideas how to avoid this memory fragmentation, but that’s something else)
<aj> (it’s not actually memory usage, it’s memory fragmentation)
<neli> hmm, bad memory manager ?
<aj> imperfect, *shrug*

After poking around at getting britney to run locally, and doing some basic analysis on how it was used, neli decided to rewrite the memory manager to use chunk-size pools – so that a separate pool would be used for 4 byte allocations, for 8 byte allocations, for 12 byte allocations, etc. That’s possible due to two factors: one is that the special memory allocation is only needed for data structures which are all made from fairly small sizes, and are a multiple of the word size. It also means that fragmentation can be avoided completely – since you can use the “free” elements to store a free list taking up no extra space. Happily, that change also made the memory allocation much simpler. (It also shows the benefits of a fresh look at code; I’d been thinking of doing something similar for ages, but always been stopped because I couldn’t figure how to make it cope with the various different sized blocks I’d need. As it turned out though, I’d solved that problem ages ago when I wrote a separate allocator to deal with strings, which would’ve required my malloc to cope with a much larger variety of sizes) What it didn’t do was actually solve the memory leak. Which was pretty confusing, since the old memory checker had some tests to ensure that memory wasn’t really being leaked, and if the memory’s not being lost due to a missing free, or being lost to fragmentation, where is it going? At this point, the real benefit of having a simpler malloc implementation came across; because suddenly it was plausible to add some debugging code to allocate a separate pool for every memory allocation, and to report how much memory is being used at any point, per line of code. That gave me output like:

pool 8B/1:751; 1962683 used 1965960 allocated (99.8% of 22 MiB)

So I knew that line 751 (of dpkg.c), was allocating 8B chunks, had used up to 22MiB in the past, and was currently using 99.8% of that. (Actually, I made an off by one error initially, so the “8B” above is actually 12B, as you can see if you divide 22MiB by 1965960) That let me see two “leaks”. One turned out to be fairly easy to diagnose; as an optimisation, when I say “package foo is installable”, I note that “but we used bar to see that, so if we later update/remove bar, note that we’ll have to see if foo is still installable”. So the datastructure for bar ends up with a linked list of all the packages, foo, that relied on it. But I don’t check that list for dupes, so if I note that both bar and baz were required for foo to be installable, then update bar, when I recheck foo, I’ll add it to both bar’s and baz’s lists; which is fine for bar, whose list I cleared when I updated it; but not so fine for baz, because it’s now got two entries for foo. Having already added a check for dupes when trying to see if my guess was right, extending that check to skip the addition was pretty easy. The other leak required a little more investigation. It was in a fairly tight loop which could reasonably be using a fair amount of memory; but by the end of the loop it should all be freed. Adding some more debug code to the allocation functions confirmed the problem:

<aj> pool 8B/11:1231; 1618157 used 1703936 allocated (95.0% of 13 MiB, 9.05% current)
<aj> so it looks like ~9% of those allocations are never freed to me
<aj> 9.05% = used/alloc
<aj> where used is incrememnted on b_m, decremented on b_f
<aj> alloc is incrememneted on b_m, never decremented

The code was meant to either add the allocated block to a larger list that’s being traversed, or to free it immediately – the problem turned out to be that there were some nested ifs, and an internal if was lacking an else that should have freed the block. Fixing that changed the results to:

pool 8B/11:1228; 160 used 131072 allocated (0.1% of 1 MiB, 0.01% current)

Which both dropped the leak – only allocating a maximum of 130,000 nodes instead of almost 2,000,000 – and resulted in almost all the allocations that had ever been made, having been freed once britney had been running for even a fairly short while. As it turned out, though, the cure for the first leak was worse than the disease – checking for duplicates in a linked list turned out to take too long, and the memory wasted in that section wasn’t that big a deal. Using a red-black tree or similar instead would’ve been a solution, but so far doesn’t seem necessary. There haven’t been any OOMs since, happily; and even better, the reduced bloat seems to have made the overall checking a bit faster. Sweet.

A dramatic title for a not so dramatic post. The Sydney suburban train network runs several sorts of rolling stock. The newest of these are the much-maligned "Millenium Trains", which bring local train users (all 18 of them) into the 20th century. One of the features of these technological masterpieces is an irritatingly obsequious voice which announces the current and next stations on the train's journey, and an LED board displaying the same info. So far, so good. Of course, I was a little curious as to how the boards and little-miss-noisy were kept in-sync with where they were. I was thinking transponders, maybe something that the train guard did. Then, last week, I found my explanation. This train announced each station as being the preceding one. So, we'd stop at Central, l-m-n would announce "This train will stop at Museum". We stop at Green Square, l-m-n says "This train will stop at Central". And so on. At least the voice and the board were in sync, even if the voice and reality were eyeing each other off at quite some considerable distance... My goal now is to find a train which is announcing stations for the wrong line completely, rather than just one station behind on the current line -- but considering I only get these new-fandangled millenium trains a couple of times a week (they spend the rest of their time in the sheds being fixed, apparently) it may be a while.

Name Overload?

First there was Debian Planet then along came the Planet Debian, unfortunate naming collision, but something we could mostly get used to and understand. If you’re not confused yet: well done. You soon will be:

• http://www.planetdebian.com

Guess which site that is? A third completely new name comprised of the two words “Debian” & “Planet”. WTF? Think that was fun? Lets try again. Stick with me: First there was Debian Help - now there’s another new site which is comprised of the two words “Debian” & “Help”:

• http://www.debianhelp.co.uk/

*Ugh* Now I’m personally of the opinion that competition is a good thing, but please people - can we all just get along without confusing our users/visitors? I’ll sidestep the whole trademark issue, in case my site is in trouble too