Yesterday was my birthday, and it was full of cookies, pies, magical pixie dust and things made entirely of sugar and spice! The remainder of the day was spent re-installing Debian Lenny upon my EEE PC - Somehow I managed to completely screw the system. Because the EEE PC is one of those ultra-portable machines I mostly used it when I was travelling, or outdoors. That mean I was generally receiving poor connectivity and the system packages weren't up to date. While I was in bed I figured I'd dist-upgrade it to the recently released Lenny. Unfortunately I started the dist-upgrade inside X.org, once I realised this I figured I'd cancel the operation via Ctrl-c. Bad news everbody: I think I was unlucky enough to interrupt an upgrade of libc, or something equally critical. Every single application gave segfaults afterward. I had two open root terminals and I could navigate around via cd .., and "echo *", but all other commands such as sudo, dpkg, strace just gave segfaults. (Even static commands gave errors - so it might have been the dynamic loader that was borked, I admit I didn't look too closely.) I figured reinstalling would be a good solution since the machine has a 4Gb root partition and /home was stored on a separate 16Gb volume. Unfortunately I managed to misjudge the installer's partitioning step and nuke the partition table on the external volume so I ended up losing the whole system. Happily reinstallation was a breeze as my home network is setup to allow installation via PXE network booting (at some point I should document NFS-root PXE-booting). It took me longer to fiddle with the BIOS on the EEE PC to allow network booting than it did to complete a minimal install. Which I guess is good. I still need to restore my backup of /home/, but that can wait a few days. Right now I'm loathe to touch the machine at all - although I did distract myself by getting KVM to PXE boot:

# create 4gb disk image
dd if=/dev/zero of=/tmp/img.img bs=1024 count=4096k
# launch KVM
sudo kvm -no-acpi
  -boot n -tftp /var/lib/tftpboot/ -bootp /pxelinux.0
  -hda /tmp/img.img
  -net nic,macaddr=00:0E:35:be:de:ad  -net user

It seems that KVM wants to have access to the local TFTP root directory so I just pointed it at that. Since my desktop machine is also my TFTP + DHCP host that works out nicely. (A quick scan of the manual suggests that QEMU/KVM has funky built-in TFTP code, so it doesn't actually forward TFTP requests over the network.) DHCP requests were certainly passed around as expected though and were answered via my local dnsmasq installation. I did see errors at every DHCP request in syslog, but they seemed harmleess enough:

gold dnsmasq[29241]: no address range available for DHCP request via qemu0

*shrugs* ObFilm: Never Been Kissed.

Thanks to Google s watchful eyes I found out that I was mentioned in a Letter to the President of Ghana, published pseudonymously on ghanaweb.com, that advocates Free Software to the new President of Ghana, John Atta-Mills. So, to all new presidents out there, if you need advice, just ask me :-)

I was not in a work mood tonight and then decided to lose my time reading about timezones (thanks to a Chinese user who wants to add Beijing to the list of timezones for China...which has only one, including the colonies of Tibet and Xinjiang). The list given on Wikipedia is a completelt hilarious time waster, indeed. My favourite one is probably the mention then some parts of British Columbia (Canada) are in UTC-7, namely Most of Peace River Regional District except Fort Ware, Pink Mountain as well as Regional District of East Kootenay and finally (take a breath!) Regional District of Central Kootenay east of the Kootenay River and parts east of Kootenay Lake that are south of and including Riondel (Creston doesn't observe DST), and Columbia-Shuswap Regional District east of the Selkirk Mountains. Canada timezones are really a gem, where one learns that Northwest Territories (one of the largest states) follows UTC-7 except a town named Tungsten and.....a tungten mine. Some other gems in that page are the places that leave in the future at UTC+13 and UTC+14, in Tonga and Kiribati. A other one? Arizona is also funny with the entire state being UTF-7, but the Navajo nation not observing DST, but the Hopi reservation (that's an enclave of the Navajo nation) observing it. That gives an interesting nightmare when travelling over there in summer. And finally, living in Florida probably requires a very high intelligence to understand what time it can be when "east of the Apalachicola River, plus the portions of Franklin County and Gulf County south of the Intracoastal Waterway, west of the Apalachicola River" uses UTC-5 while "west of the Apalachicola River, except for the portions of Franklin County and Gulf County south of the Intracoastal Waterway" use UTC-6. There are other such hilarious thingies on that page. I hope you'll enjoy it as much as I did.

If you are managing a Free Software project, you may eventually be confronted with a security vulnerability. Normally bugs in the Open Source world are discussed in a transparent way on public forums. In the case of security bugs however, there are benefits to temporarily withholding these details from the public.

Some people describe this approach as responsible disclosure. It boils down to this:

if the vulnerability is not publicly known, warn the vendors first and give them some time to fix it before making the details public.

If the vulnerability is already public knowledge, then you can focus on fixing it as soon as possible and maybe let reporters know about a better way to report their findings.
Sample Security PolicyHere's the procedure we now follow in the Mahara project for security bugs we found ourselves or which have been privately disclosed to us through security@mahara.org:

1. Figure out the extent of the problem: which versions of Mahara are affected by this problem?
2. Fix the problem on all supported branches of the project in a private source control repository.
3. Share the vulnerability information with vendor-sec and request a CVE identifier.
   
4. Prepare release tarballs and packages.
5. Draft a security advisory for the Security forum.
6. Wait until the embargo date to push the release out.
   

Emails to vendor-sec should include:

• a description of the problem
• any proof of concept code demonstrating the vulnerability
  
• the list of affected versions
• any patches you have prepared
• a proposed embargo date

Benefits of properly handling security bugs
First and foremost, it protects end-users by giving them a chance to download and install fixed versions of your software before widespread exploitation of the security flaws.

Secondly, it may increase your project credibility. While you are admitting that your software has flaws, you are also demonstrating that your project is committed to dealing with the most serious ones promptly and in a responsible manner.

Finally, sharing security flaws and having your fixes reviewed by a select group of experts may reveal extra vulnerabilities you missed while preparing your patches. This gives you an opportunity to improve your fixes before they are released and to avoid having to issue yet another security advisory a few days later.

Big thanks to Steffen Joeris for his help in shaping the Mahara policy!

Once your new Free Software project has had some traction and is gaining users, you will probably want to supplement its initial homepage with a few extra services. However, the most important aspects of managing a Free Software community have more to do with relating to human beings.
Social Interactions in Small ProjectsIn the early days of your project, support requests usually only come in through personal emails to the lead developer. In order to build your community, make sure new users feel welcome:

• Be friendly and informal in your responses. Feel free to use the person's first name at the beginning of your emails.


• Be responsive to feedback and request for help. Most Free Software developers are quite busy so this is about letting user know that you'll get back to them or thanking them for their suggestions/feedback. Very few people take the time to contact authors to let them know about the problems they run into. It's important to be supportive of the ones who do.
  


• Be calm when responding to negative feedback. It helps to take a full day to cool off before sending a reply. Thank users for writing to you, but remind them that you are not getting paid to work on this project and that you are doing this for fun in your spare time. Some users seem to forget this.

But of course, remember that the main job of a developer/maintainer is to make the software better. Keep this in mind when replying to support requests and allocate your (limited) time accordingly.
More Tools for Growing ProjectsAs your project grows and handling user-reported issues start becoming more of a burden, consider two things: documentation and distributed support.

The obvious place to start documentation-wise is to start collecting responses that you send to users who get in touch with you. This is the original meaning of a FAQ: answers to actual questions sent in by actual users. Fill your FAQ with irrelevant questions and users won't bother reading it and will email you instead.

In addition to providing good documentation, you should also think about creating a mailing list or a forum where users can post their questions (Google Groups provides a nice blend of the two technologies). There are two main advantages to this service:

• the support load is distributed across other users of the software
• questions and answers are archived by search engines

As your project grows even bigger, you will probably also want to look into getting a bug tracker and a wiki.

Have a look at this excellent online book for more ideas.

I'm eternally confused about the state of powermanagement in Debian (or in Linux generally? Not using any other distribution seriously, I have no idea.) There are just too many scripts who interact or merely run in parallel (see my short note in my first posting about my shiny toy. While I don't actively invest time to educate myself about the situation, I've just tried to uninstall a round of unneeded packages and got rid of apmd and hibernate, which both were installed by default (or by dependencies of other stuff I've got rid of earlier?) but seem not to be necessary. At least the laptop still suspends when I close the lid. This is without rebooting or even just logging out, though, so if it doesn't work out, I'll have to update this entry. Update: Thanks to Michael's comment, pointing to #451380. Scope for a Google Summer of Code project, perhaps? This would be 90% talk to people and get a consensus and only 10% coding, though, but I think it would be worth it so that squeeze would have a powermanagement /acpi framework where different components don't stand on other components' toes all the time.

So I am going to do something that nobody on the Internet is doing lately: post a review of the Kindle 2 after having only used it for three days. Shocking, yes, I know. I had never even seen a Kindle of either model before getting the Kindle 2. I had, though, thought about getting an eInk device for some time. The $359 Kindle 2 price tag caused me significant pause, though in the end I went for it due to the 30-day return policy. On the surface, I thought that it would be weird to have a Kindle. After all, how often am I away from the computer? And there s a small local library a few blocks from where I work. But I had a hunch it might turn out for me like my iPod did: something that didn t sound all that useful from reading about it, but turned out to be tremendously so after having actually used it. Turtleback Delivery I ordered my Kindle 2 with standard shipping, which meant that it went by FedEx Smart Post. Here is my SmartPost rant. There are two words in Smart Post that are misleading. I once had an item take literally a week to make it from St. Louis to Kansas. That is, I kid you not, slower than the Pony Express ran in 1860. This time, my Kindle made it from Kentucky to Kansas in a mere five days. Oh, and it spent more than 24 hours just sitting in St. Louis. The Device Overall, the device is physically quite nice. It is larger and thinner than I had imagined, and the screen also is a bit smaller. It is usually easier to hold than a paperback, due to not having to prevent it from closing too far at the binding edge. The buttons are easy to press, though I could occasionally wish for them to be easier, but that s a minor nit. The Screen The most important consideration for me was the screen. The eInk display as both stunningly awesome and disappointing. This is not the kind of display you get on your computer. Or, for that matter, any other device. It isn t backlit. It reacts to light as paper does. It can be viewed from any angle. And it consumes no power to sustain an image; only to change it. Consequently, it puts up a beautiful portrait of a famous author on the screen when it is put to sleep, and consumes no power to maintain it. The screen s response time isn t anywhere near as good as you d expect from a regular LCD. It flashes to black when you turn a page, and there is no scrolling. On the other hand, this is not really a problem. I found the page turning speed to be more than adequate, and probably faster than I d turn the page on a real book. The resolution of the display has the feeling of being incredible. The whole thing provides a far different, and in my eyes superior, experience to reading on an LCD or CRT screen. My nit is the level of contrast. The background is not really a pure white, but more of a light gray. This results in a contrast level that is quite clearly poorer than that of the printed page. At first I thought this would be a serious problem, though I am growing somewhat more used to it as I read more. Reading Experience Overall, I ve got to say that it is a great device. You can easily get lost in a book reading it on the Kindle. I m reading David Copperfield for the first time, and have beat a rather rapid path through the first five chapters on the Kindle already. And that, I think, is the best thing that could be said about an ebook reader. It stays out of the way and lets you immerse yourself in your reading. The Kindle s smartly-integrated Oxford-American Dictionary was useful too. One thing about a novel written 150 years ago is that there are some words I just haven t ever heard. Nosegay, for instance. You can move a cursor to a word to see a brief pop-up definition appear, or press Enter to see the entire entry. This is nice and so easy that I m looking up words I wouldn t have bothered to if I were reading the book any other way. A nosegay, by the way, is a bouquet of showy flowers. Buying Experience The Kindle has a wireless modem tied to the Sprint network on it. The data charges for this, whatever they may be, are absorbed by Amazon in the cost of the device and/or the books you buy for it. This turned out to be a very smart piece of engineering. I discovered on Amazon s Kindle Daily Post that Random House is offering five mostly highly-rated sci-fi books for free on the Kindle for a limited time. So I went over to the page for each, and made my purchase . It was only a click or two, and I saw a note saying it was being delivered. A few minutes later, I picked up the Kindle off the kitchen counter. Sure enough, my purchases were there ready to read. Impressive. This level of ease of use smells an awful lot like Apple. Actually, I think it s surpassed them. You can delete books from the Kindle and re-download them at any time. You can initiate that operation from either the PC or the Kindle. And you can also browse Amazon s Kindle store directly from the device itself. I haven t subscribed to any magazines or newspapers, but I gather that they deliver each new issue automatically the moment it s released by the publisher, in the middle of the night. I pre-ordered the (free to Kindle) Cook s Illustrated How-to-Cook Library. It makes me way happier than it should to see This item will be auto-delivered to your Kindle on March 26 in the order status. Free Books Amazon s Kindle library has a number of completely free Kindle books as well. These are mostly out-of-copyright books, probably sourced from public etext places like Project Gutenberg, and converted to the Mobipocket format that is the Kindle s native format with a minimum of human intervention. As they are free, you can see them in Amazon s library if you sort by price. And, of course, Amazon will transfer them to the Kindle wirelessly, and maintain a copy of them in your amazon.com account. Unfortunately, as with free etexts in general on the Internet, the quality of these varies. I was very annoyed to find that many free etexts look like they were done on a typewriter, rather than professionally printed. They don t use smart quotes; only the straight ones. When reading on a device that normally shows you a faithful print experience, this is jarring. And I spent an inordinate amount of time trying to find a copy of Return of Sherlock Holmes that actually had the graphic figures in Dancing Men. Ah well. Your Own Content Amazon operates a mail server, username@kindle.com. You can email stuff to it, and it will convert it to the Kindle format and wirelessly upload it to your kindle for a fee of $0.10. Alternatively, you can use username@free.kindle.com, which does the same thing at no charge, but emails you back a link to download the converted work to install via USB yourself. I tried it with a number of PDFs. It rejected about a dozen times from only my single mail message a PDF containing graphic images only. However, it does quite well with most text-heavy PDFs notably doing an excellent job with Return of Sherlock Holmes from bookstacks.org the only source I found that was both beautifully typeset and preserved the original figures. Unfortunately, the PDF converter occasionally has troubles identifying what should be a paragraph, particularly in sections of novels dealing with brief dialog. I have also sent it some HTML files to convert, which it also does a great job with. You can also create Mobipocket files yourself and upload them directly. There is a Mobipocket creator, or you can use mobiperl if you are Windows-impaired or prefer something scriptable on Linux. The device presents itself as a USB mass storage device, so you can see it under any OS. There s a documents folder to put your files in. You can back it up with your regular backup tools, too. And it charges over USB. Web Browser I haven t tried it much. It usually works, but seems to be completely down on occasion. It would get by in a pinch, but is not suitable for any serious work. The guys over at XKCD seem to love it; in fact, their blog post was what finally convinced me to try the Kindle in the first place. Final Thoughts I ve ordered a clip-on light and a leather case for the Kindle. The light, I believe, will completely resolve my contrast complaint. The leather case to protect it, of course. I can t really see myself returning the Kindle anymore. It s way too much fun, and it s making it easier to read more again. And really, if Amazon manages to reach out to a whole generation of people and make it easy and fun for them to read again and make a profit doing it, of course they may move up a notch or two from being an evil patent troll company to a positive social force company. Wow, never thought I d say that one.

It's crazy to think that this is just past the one-year anniversary of my surgery. A year out and I can lift about 12kg (25lbs for the Americans and Iranians), I'm not on routine or regular pain killers of any sort. I still have to take it easy and need to make sure I get to the gym more often - when I don't I start to get pain and have trouble keeping up with Leif. I have discovered that I can't sleep on airplanes anymore, even in Air Canada business class. So, no more red-eyes for me. It's hard to shed a tear over that one. =) I suppose I have a lot of little limitations like that, but a year in I don't notice them so much anymore.

I shudder a bit to think that at this time last year, I was just home from the hospital. A long walk for me was a trip to the mailbox: I was only up for it every couple of days, and it took me about 30 minutes, including stops for sitting.

Thanks for your love and support, everyone.

Django Lint is a static analysis tool that checks (or lints) web applications that are built around the Django web development framework. It aims to encourage the development of high-quality reusable Django applications. It currently reports on:

• Nullable CharField or TextField model fields
• Missing recommended configuration variables in settings.py
• Mismatch of null=True and blank=False for model fields
• Use of BooleanField with default=True or use of NullBooleanField
• Where myapp.models is actually a directory-based package instead of a single models.py
• Excessive number of models in a single application
• Models within an application having a common prefix
• Use of unique_for_date, unique_for_month or unique_for_year modifiers
• Naive tree structure implementations using ForeignKey('self')
• Missing __unicode__ methods or use of __str__
• Incorrect ordering of standard model methods relative to Django style guidelines
• Misordered middleware in settings.py
• Models with too many fields (or zero) fields
• Extremely large CharField fields
• Use of the PositiveSmallIntegerField or SmallIntegerField fields
• Use of auto_now or auto_now_add modifiers on date fields
• Instances of URLField without an explicit verify_exists value
• (and more)

Admittedly, some of the checks are based on the implementation details of MySQL, PostgreSQL and SQLite backends, but this fits with the goal of promoting re-usable applications anyway. GPLv3 source, tarballs, etc. Patches welcome.

One of the recent poor trends in mailing list discussions is to reply to a message with a comment such as FAIL or EPIC FAIL . The FAIL meme has been around for a while and actually does some in some situations, slate has a good article about it [1]. The first example cited in that article is that when Ben Bernanke and Henry Paulson testified before the Senate banking committee last month about Paulson s proposed bailout bill, a demonstrator in the audience held up an 8.5-by-11 piece of paper with one word scrawled on it in block letters: FAIL. . This is an effective form of political demonstration, short words generally work well on placards (if only because the letters can be larger and therefore read from a greater distance) and anyone can understand the meaning of FAIL in that context. There are some blogs dedicated to publicising supposed failures, failblog.org and ShipmentOfFail.com are two examples. I cite these as supposed failures because some of the pictures that they contain are obviously staged. It s basically an Internet equivalent of the Funniest Home Videos shows that I never watched because they were not particularly funny. So using the word FAIL on it s own can be an effective form of political protest and can be used for mildly amusing web sites. But where it falls down is when it s applied to a discussion that involves people who are from different cultures or have different levels of background knowledge - which covers most mailing list discussions. Something that might be obviously wrong to some people is often not obvious at all to others. For example being forced to reboot a computer for any reason other than a kernel upgrade seems obviously wrong to me (and to most people who use Linux or other Unix systems) but Windows users seem happy to reboot machines after applying patches or upgrades. So writing a message with FAIL as the only word in a discussion with Windows users would not be productive. It could however be reasonable to forward a link to a page on a Microsoft web site to Linux people for their amusement with FAIL as the only comment - anyone who would find the link in question amusing would require no more explanation. Sometimes when in a debate someone will write a message that only says FAIL , this is a very unconvincing argument that will not convince the opposition or any onlookers. Generally it seems that using FAIL in a discussion with other like-minded people when talking about someone outside your group for the purpose of amusement can be effective. But any other use is going to be a FAIL . As a more general rule single-word messages seem to have little value apart from certain limited situations. I have identified the following seven scenarios where a single word message is useful. Can anyone think of any others?

1. Code review - someone posts code (or design for code) and people who like it will write ACK or something similar.


2. Arranging a meeting - the question who wants to meet for lunch tomorrow has me as a valid answer.


3. Voting - yes and no are valid answers for a poll, but a mailing list or forum probably isn t the best place for it.


4. Citing an example to refute a claim - often a single word won t be a great response but may be adequate to prove a point.


5. Answering a request for a recommendation - if asked to recommend a laptop I might say Thinkpad or if asked to recommend a server I might say HP . Both those answers are poor (I recommend EeePC for netbooks and Dell for small/cheap servers), so while such an answer would be useful it would be below my usual quality standards for email (I prefer to write at least two paragraphs explaining why I recommend something).


6. Informing people that something has been done by replying to a request with the word Done .


7. Agreeing to a contract or proposal with OK or Yes .

Update: I added another two reasonable uses of single word messages,

• [1] http://www.slate.com/id/2202262/pagenum/all/

So, fanatical readers of my blog (are there any?) may remember a long time back that I got bored and wrote a little script that amused me. While testing something out yesterday, I needed to find a domain that I wasn t using in production so I could test on it. I stumbled across Cheese Nibbles which had a lovely We ll be back with something cool soon message on it. So, I did my tests, and they worked. Everything s good. I d actually forgotten what was on Cheese Nibbles in the first place, so I started rooting round in the code. I found the old site, and I decided to resurrect it. I posted in a couple of IRC channels, to see if other people found the site amusing, and got the following back in response

<Daviey> neat
<Daviey> Mez: rss feed needed
<Mez> Daviey: *chuckles*
<Mez> but then it d be twitter
<Daviey> sure, but a shared account
<Daviey> Or.. make it twitter when changed

So, well, thanks to Dave Walker s suggestion, I did a quick google, and within 6 minutes, had it working. You can find the twitter feed at http://twitter.com/cheesenibbles Also, over the last couple of weeks I ve been working with Zeth from my local LUG (and the tech, who shall remain anonymous, like The Stig ) on a podcast, which we are, for now calling The Podcast (imaginative I know). I was interviewed in the first podcast (which Zeth did alone, and I (apparently) provided the comedy element for) and presented with Zeth for the second one. Also, as the second one was recorded during the Ubuntu Global Bug Jam, of which I was running one of the venues, I actually allowed myself to be interviewed for it aswell. The podcast is very rough around the edges at the moment, and well, we haven t got a website, or an RSS feed yet, but you can find the show notes here, and download the podcast episode in either MP3 Format, or OGG Format All comments/thoughts/suggestions welcome!

[Originally posted in June 2006; updated with new links several times, most recently in March 2009] Eric Flint: A Matter of Principle, Jim Baen s Universe 1 (1), 2006.
Eric Flint: Copyright: What Are the Proper Terms for the Debate?, Jim Baen s Universe 1 (2), 2006.
Eric Flint: Copyright: How Long Should It Be?, Jim Baen s Universe 1 (3), 2006.
Eric Flint: What is Fair Use, Jim Baen s Universe 1 (4), 2006.
Eric Flint: Lies, and More Lies, Jim Baen s Universe 1 (5), 2007.
Eric Flint: There Ain t No Such Thing as a Free Lunch, Jim Baen s Universe 1 (6), 2007.
Eric Flint: Books: The Opaque Market, Jim Baen s Universe 2 (1), 2007.
Eric Flint: Spillage: or, The Way Fair Use Works in Favor of Authors and Publishers, Jim Baen s Universe 2 (2), 2007.
Eric Flint: The Economics of Writing, Jim Baen s Universe 2 (3), 2007.
Eric Flint: The Pig-in-a-Poke Factor, Jim Baen s Universe 2 (4), 2007.
Eric Flint: Paper books are not going to be joining the dodo any time soon. If ever., Jim Baen s Universe 2 (5), 2008
Eric Flint: A Matter of Symbiosis. Jim Baen s Universe 2 (6), 2008
Eric Flint: The Nature of Transitions. Jim Baen s Universe 3 (1), 2008
Eric Flint: Adventures with a Search Engine. Jim Baen s Universe 3 (2), 2008
Eric Flint: The Problem is Legal Scarcity, not Illegal Greed. Jim Baen s Universe 3 (3), 2008
Eric Flint: Foam and Froth and Mighty (Upside-down) Pyramids. Jim Baen s Universe 3 (4), 2009 Eric Flint is a fairly successful sf author. These columns explore the evils of Digital Restrictions Management (DRM, also known as Don t Read Me).

I'm working on aptitude's dependency resolver at the moment. Mostly I'm working on some changes to support better UI, but while I have all the code in my head I'd like to try to fix some of the nagging speed problems it has. I've already managed to clear up some simple but large problems with aptitude safe-upgrade, because I could get them to happen on my computer. The problem is, most of these problems don't happen on my computer. I have a half dozen or so specific ideas that might speed aptitude up, but I don't want to just randomly apply tweaks without some baseline tests that I can use to make sure that I'm actually making things better and not just perturbing the code for no reason. Plus, seeing why aptitude is actually running slowly might help when it comes to finding ways to improve its performance. So, this is where you come in. If you are using lenny and aptitude takes a long time to resolve dependencies on your computer outside of aptitude safe-upgrade, I would like to hear from you. All you need to do is to run this command when aptitude is slow, before you upgrade any packages:

$ aptitude-create-state-bundle aptitude-state.tar.bz2

Then, find a way to get the resulting large file to me. Email will work if your outgoing server accepts it; send to dburrows@algebraicthunk.net. That will tar up /etc/apt, /var/lib/apt, /var/cache/apt, and a few other directories: run aptitude-create-state-bundle --print-inputs to see exactly what it will include. Thanks! [UPDATE]: PS: please also include a brief description of the problem that you're seeing so I know what to test. Something like, e.g., when I run aptitude full-upgrade it takes thirty minutes to complete. [UPDATE]: PPS: of course you have to run aptitude-create-state-bundle before you actually upgrade any packages! i.e., you must type n at aptitude's command-line prompt or quit the program if you're using the curses interface. Otherwise, your state snapshot will just tell me what you upgraded to, which is only half the information I need (I also need the state of all packages prior to the upgrade).

I've been working for a while on a new reprepro-based personal Debian repository, replacing the old one that was managed by debarchiver. I was going to hold off on switching until I uploaded every package that was in the old repository, but then I realized that was kind of silly and some of those packages need more attention. So I finally did the cutover today. For details on my personal repository, see my Debian packages page. The new repository is signed with a different key, not my personal key, so that I can automatically sign package uploads. You will now want to install the eyrie-keyring package from the repository or follow the alternative instructions on that page to import the key. The packages in that repository are mostly software I developed that's not of sufficient general interest to upload or packages that aren't up to Debian quality standards for one reason or another. I love reprepro. debarchiver did very well for me for quite a while, and I'm happy to have used it, but reprepro is just very nice. It's great to be able to use package pools and do automatic propagation of new uploads into multiple repositories, too. Now I just need to find time to do more software releases.

all programs that interact with e-mail are broken in one way or another. Please be careful. - Lars Wirzenius

I seem to have a cunning knack of finding problems with configuring server software, particularly involving e-mail, where a) I can t find answers in Google, b) most people I go and ask for help say they d usually ask me such things, and c) if I go onto IRC or mailing lists I end up helping other people and not getting any help with my problem. It s quite likely this is just because I m something of a perfectionist, so the ridiculous crappy hacks people come up with and seem content to entrust their mail to are unacceptable to me for one reason or another. Anyway, in my ongoing quest for the perfect mail system, I ve painted myself into a corner again. (I m currently running with postfix, postgrey, clamav-milter, dspam, dovecot using LDA, managesieve and the cmusieve & antispam plugins. If I can get the current incarnation working, I ve had enough requests to write up a full HOWTO, and seen enough around with pretty questionable content, that I ll probably do it before too long.) I ve got postfix s local transport configured to hand mail to dspam over LMTP, using mailbox_transport = lmtp:unix:/dspam/dspam.sock. dspam is configured to listen here, add X-DSPAM-Result and signature headers, and then deliver the mail with dovecot s deliver LDA (which I ve set to 4750 root:dspam). From dspam.conf: ServerParameters "--deliver=innocent,spam -d %u"
ServerDomainSocketPath "/var/spool/postfix/dspam/dspam.sock"
...
Preference "spamAction=tag"
Preference "signatureLocation=headers"
...
TrustedDeliveryAgent "/usr/lib/dovecot/deliver" My dovecot configuration is pretty standard, using PAM for both passdb and userdb, and provides the auth-master socket that deliver needs. The problem I have is that postfix s local transport is qualifying the local username with the FQDN of the machine before delivering it to dspam with LMTP (the local mail transfer protocol), even for locally-originated mail which was only addressed with a bare username! dspam doesn t mangle it or care if the user is local or not, and then cheerfully invokes deliver -d robot101@omega.example.co.uk, which returns EX_NOUSER (addressee unknown) because my username is just robot101. From mail robot101: Mar 6 02:25:40 omega postfix/pickup[13607]: DAA4942F41F: uid=1000 from=<robot101>
Mar 6 02:25:40 omega postfix/cleanup[13637]: DAA4942F41F: message-id=<20090306022540.DAA4942F41F@omega.example.co.uk>
Mar 6 02:25:40 omega postfix/qmgr[12552]: DAA4942F41F: from=<robot101@omega.example.co.uk>, size=339, nrcpt=1 (queue active)
Mar 6 02:25:40 omega dovecot: auth(default): passwd(robot101@omega.example.co.uk): unknown user
Mar 6 02:25:40 omega dspam[13527]: Delivery agent returned exit code 67: /usr/lib/dovecot/deliver -d robot101@omega.example.co.uk
Mar 6 02:25:40 omega postfix/lmtp[13640]: DAA4942F41F: to=<robot101@omega.example.co.uk>, orig_to=<robot101>, relay=omega.example.co.uk[/dspam/dspam.sock], delay=0.08, delays=0.05/0.01/0.01/0.03, dsn=4.3.0, status=deferred (host omega.example.co.uk[/dspam/dspam.sock] said: 421 4.3.0 <robot101@omega.example.co.uk> Delivered (in reply to end of DATA command)) So, no e-mail for me. Dearest lazyweb, which of the three components is behaving wrongly, and how can I fix it? (And no, I m not just going to switch to GMail. I store my data on hard drives, which are sometimes in servers, not in the cloud . Until about a month ago, most people I knew spoke about clouds which were made of particles of water in the sky, rather than as a data storage media. What if it rains? ;)

all programs that interact with e-mail are broken in one way or another. Please be careful. - Lars Wirzenius

I seem to have a cunning knack of finding problems with configuring server software, particularly involving e-mail, where a) I can t find answers in Google, b) most people I go and ask for help say they d usually ask me such things, and c) if I go onto IRC or mailing lists I end up helping other people and not getting any help with my problem. It s quite likely this is just because I m something of a perfectionist, so the ridiculous crappy hacks people come up with and seem content to entrust their mail to are unacceptable to me for one reason or another. Anyway, in my ongoing quest for the perfect mail system, I ve painted myself into a corner again. (I m currently running with postfix, postgrey, clamav-milter, dspam, dovecot using LDA, managesieve and the cmusieve & antispam plugins. If I can get the current incarnation working, I ve had enough requests to write up a full HOWTO, and seen enough around with pretty questionable content, that I ll probably do it before too long.) I ve got postfix s local transport configured to hand mail to dspam over LMTP, using mailbox_transport = lmtp:unix:/dspam/dspam.sock. dspam is configured to listen here, add X-DSPAM-Result and signature headers, and then deliver the mail with dovecot s deliver LDA (which I ve set to 4750 root:dspam). From dspam.conf: ServerParameters "--deliver=innocent,spam -d %u"
ServerDomainSocketPath "/var/spool/postfix/dspam/dspam.sock"
...
Preference "spamAction=tag"
Preference "signatureLocation=headers"
...
TrustedDeliveryAgent "/usr/lib/dovecot/deliver" My dovecot configuration is pretty standard, using PAM for both passdb and userdb, and provides the auth-master socket that deliver needs. The problem I have is that postfix s local transport is qualifying the local username with the FQDN of the machine before delivering it to dspam with LMTP (the local mail transfer protocol), even for locally-originated mail which was only addressed with a bare username! dspam doesn t mangle it or care if the user is local or not, and then cheerfully invokes deliver -d robot101@omega.example.co.uk, which returns EX_NOUSER (addressee unknown) because my username is just robot101. From mail robot101: Mar 6 02:25:40 omega postfix/pickup[13607]: DAA4942F41F: uid=1000 from=<robot101>
Mar 6 02:25:40 omega postfix/cleanup[13637]: DAA4942F41F: message-id=<20090306022540.DAA4942F41F@omega.example.co.uk>
Mar 6 02:25:40 omega postfix/qmgr[12552]: DAA4942F41F: from=<robot101@omega.example.co.uk>, size=339, nrcpt=1 (queue active)
Mar 6 02:25:40 omega dovecot: auth(default): passwd(robot101@omega.example.co.uk): unknown user
Mar 6 02:25:40 omega dspam[13527]: Delivery agent returned exit code 67: /usr/lib/dovecot/deliver -d robot101@omega.example.co.uk
Mar 6 02:25:40 omega postfix/lmtp[13640]: DAA4942F41F: to=<robot101@omega.example.co.uk>, orig_to=<robot101>, relay=omega.example.co.uk[/dspam/dspam.sock], delay=0.08, delays=0.05/0.01/0.01/0.03, dsn=4.3.0, status=deferred (host omega.example.co.uk[/dspam/dspam.sock] said: 421 4.3.0 <robot101@omega.example.co.uk> Delivered (in reply to end of DATA command)) So, no e-mail for me. Dearest lazyweb, which of the three components is behaving wrongly, and how can I fix it? (And no, I m not just going to switch to GMail. I store my data on hard drives, which are sometimes in servers, not in the cloud . Until about a month ago, most people I knew spoke about clouds which were made of particles of water in the sky, rather than as a data storage media. What if it rains? ;) Update: The problem is fixed! Even though arguably the problem is dspam s for not knowing which users are local or not, it s fixable in dovecot 1.1.x using the auth_username_format = %n option. Thanks so much to Angel Marin for helping me out. Update 2: There s also a patch for dspam floating around which adds a StripRcptDomain option, which makes the LMTP server truncate the e-mail address at the @, so essentially assumes everyone to be a local user. The problem with both of these fixes is that they re both blunt instruments which will break virtual users on the same host. I think the real fix would be something more like a LocalDomains option in dspam, to choose which domains should be considered local and truncated from the e-mail addresses for delivery purposes.

I finally decided that it's time for me to upgrade my Xen installation. It used to run etch with backported Xen, because the etch version was increasingly difficult to work with. I also acknowledge that some of the issues I've been having are simply caused by yours truly, but even still the Debian Xen installation is way too fragile to my taste. I've already considered installing XenServer Express locally and running the hosts on it. The big drawback has been that XenCenter (the tool that is used to manage XenServer) is windows only and it doesn't work with wine. So you can imagine my desperation... Anyway, the latest upgrade from etch to lenny was painful as usual. The first part went smoothly, bit of sed magic on sources.list and a few upgrade commands (carefully picking the Xen packages out of the upgrade set). So in the end I had a working lenny installation with backported Xen. Next I made sure that there was nothing major going on in my network (one of the virtual machines acts as my local firewall) and took a deep breath before upgrading the rest of the packages. I knew to be careful about xendomains -script which has reliably restored my virtual machines after reboot to a broken host so I had always ended up restarting my virtual machines after reboot. I carefully cleared XENDOMAINS_AUTO and set XENDOMAINS_RESTORE to false in /etc/default/xendomains so that the virtual machines would be saved but not restored or restarted on reboot. After the normal pre-boot checks I went for it. Oddly enough everything worked normally and the system came up after a bit of waiting. I checked the bridges and everything appeared normal, so it was time to try and restore a single domain to see that everything actually did work as planned.

Hydrogen:~# xm restore /var/lib/xen/save/Aluminium
Error: Device 0 (vif) could not be connected. Hotplug scripts not working.

Oof, Googling for the issue revealed that there were others that had suffered from the same problem on various different platforms the problems were caused by different things. One would assume that the problem is in the vif-bridge script that is mentioned in the xend-config.sxp file as the script that brings up the vif, but after many hours of tial and error and pointless googling (over gprs connection), I couldn't find any solution to the problem. It was time to call it a day (it was almost 3 am already...) During the night I had a new idea about the possible cause. What if the problem isn't in xend, but somewhere else. I fired up udevadm monitor to see what udev saw and it wasn't much. I'm not an expert with udev, but from previous encounters I had a vague feeling that there was supposed to be more events flying around. I wasn't able to pinpoint what was wrong so I decided to purge xen-utils, of which I had 2 versions installed: 3.2-1 and 3.0.2. I also removed everything related to xenstore. After reinstalling the current versions and restoring my configuration files the first host came up just fine. I still had problems resuming the virtual machines and I ended up rebooting them again, which was nothing new, but at least they were running again. In the end I don't know what was the actual cause for udev not handling the devices properly, but I'm happy to have them all running again. And I learned a valuable lesson of all this: udev is an important part of Xen, make sure it works properly.

I have a bit of money invested in stocks and funds, passively managed by my bank. I ve made a bit with risky speculations, and I ve lost about the same amount with the markets dive of the last 18 months. Net benefit: zero cash, a bit of experience. Time to move on I am not an interesting customer, so I was all the more surprised to get a call from an employee of the bank the other day. He identified himself as Crisis Manager or something similarly ridiculous, mentioned at least 20 times that he was a regular employee and wouldn t receive provisions, and he also kept assuring me that he s doing himself what he s suggesting to me: leveraging the cost-average effect. I turned him down, probably a bit too briskily. Let s investigate why. Banks are good at devising ingenious tricks to fool people; it s their business after all. One of those tricks is the so-called cost-average effect. It s awesome, they say, because it is the first product that adapts to the ever-changing market: when prices are up, it buys smaller numbers of shares, and in low times, it stocks up on them by buying larger quantities, automatically. Fancy, no? It isn t, because the entire idea is to get your signature on a contract that obliges you to pay a fixed sum each month, with which shares are then bought. Obviously, when prices are up, numbers you get for your money are low, and vice versa. Observe how well the banks manage to turn that basic rule into a selling point. They are good at that. In fact, that s probably all they re good at. Obviously , inflation is also factored in, so the monthly fixed sum actually increases by a projected 5% each year, which they call inflation protection . While this strategy investing fixed-sum installments rather than lump sums certainly has its benefits, and can level out the risk of throwing a large sum of money at the market, it is commonly considered a suboptimal strategy, especially when employed over longer spans of time. For more information, I refer you to the frequently cited article Nobody gains from dollar cost averaging analytical, numerical and empirical results , published in the 1992/1993 issue of the Financial Services Review journal. So why would the bank approach me with this offer ? Let s go hypothetical and check out Ashley s investment practices: Ashley bought a fund five years ago at 100 per share, and it s now down to 80 . The loss is thus 20%, a -4% factor (20% / 5 years) that affects the overall performance of the portfolio. Ashley doesn t really care much about the percentages. After all, the only thing that counts is the worth of the shares when sold right now. Everything else is history and only influences the size of the tears one weeps in times like this, which is a psychological malfunction, not a function of the financial markets crisis. The bank, however, does not like negative performance values. Positive percentages yield happy (blinded?) customers, who get much more enthusiastic (greedy?) to put more money into the giant machine that makes the banks tick which is still in the process of blowing up into their faces. But negative performance values cause investors to become conservative and leery. They d rather hold on to their hard-earned cash for fear of losing more. That s the flip-side of aforementioned psychological malfunction, and this is the core of the reason why some of the big investors get bigger even in times like this they do not succomb to the feeling . The banks, however, need cash, and loads of it, and while the state is busy printing notes, they take every chance to get more. Private clients are wonderful prey, as they are less informed about the system than investors. So, to get cash from the clients, the banks have to circumvent the psychological malfunction. They cannot boost the market value share, but there are two values that factor into a percentage, and the cost-average effect, sold as the best thing since sliced bread, is nothing but a way to affect the other number: the sale price, the divisor. If the fund stays below the original sale price (100 ), each time Ashley pumps more cash into the machinery each month, this divisor decreases, effectively decreasing the percentage value. In the long run, this yields happier customers, who are willing to put more money in, especially if the performance turns positive. The baseline is now lower, so a return to previous heights would correspond to larger performance values than ever before. Obviously, a positive market causes the baseline to grow, but the cost-average deals continues to pay off for the banks. Since Ashley put that signature on the contract, the bank has a guaranteed cash flow for the contract s duration, while Ashley wonders why the percentage remains dampened. Cost-average means decreasing the percentage, in good as well as in bad times. Just now, the bank doesn t have to work so hard to get even more money from you. It gets worse: usually, those contracts are embedded in some sort of life insurance deals with grand promises in 40 years to come, and over all that time, it ll be quite clear who wins and who loses. Scary, huh? I was going to end with the advice to stay away from the cost-average effect, but I think I can just as well make it more general: if you don t understand a deal, don t sign it. If you abide by that rule, you would stay away from cost-average effect deals all by yourself. Maybe my little writeup has helped, nonetheless. NP: DJ Ti sto: Live at Innercity

At some point in the past, when I was still thinking that Glest can be packaged in a sane way, I had a conversation with upstream developer martinho on the Glest forum (they call it board) about them integrating a patch in order to support big endian machines.

After some messages on their board, it was clear that they don't want to integrate any patches and started to throw out random fake arguments against the integration of my patch and other patches.

When he figured out that I replied and debunked all of his fake arguments, he went on and actually removed my posts from the forum. It was so weird since I have never seen that kind of behaviour before and some of his posts and other people's posts were replies to my posts and things didn't made any sense after the deletion.

At that moment I have managed to save one small bit of the conversation via Google's cache, but now I have finally decided to make it public.


Note: Back then, I kept this post private in the hope that I was maybe too involved in the conversation at that moment to make a rational decision about it, and hoped things would get better in time. They didn't. Meanwhile they migrated to another forum software and they said they lost most/all(?) of the previous content from the old forum.



Here is the conversation bit I managed to save.
Original text is in italic font. Regular font is for my current comments for clearing up the context of the discussion. The text retains the BB syntax and [quote]-d text is martinho's own words.



[quote="martinho"]thebohemian, eddyd,

I think you guys are missing the point, this is not the place for any [/quote]

Congrats, you are avoiding to answer the points I have raised.

[quote]
- The Glest project is made by a bunch of friends for fun, we ask for nothing, we answer to no one. So I beg you not co complain, because it is out of order.
[/quote]

In that case I don't see the point of the "development" forum. care to explain?
And, from my PoV, these are your users you're arrogantly dismissing.


The following was a reply to my request to add big endian support through a patch I provided at that time. The patch wasn't complete to actually make glest work on BE machines, but it didn't broke little endian support at all. He was trying to argue that there were no valid big endian machines on which the game would run. Integrating the patch would have made my life a lot easier in continuing the work on the patch.

[quote]
- Our target plarforms are PCs running Windows (I'm responsible for this) or Linux (matze is the boss here). We don't care if Glest doesn't run in a big endian dishwasher with Solaris.
[/quote]

Linux on PowerPC is a viable platform. So is Mac OS X on PowerPC.



I made the mistake of saying that some parts of the code where not that clean and could be improved. More on that below.

[quote]
- One of the keys of Glest success is how extremely clean our code is. Bringing random people in would break this, and we are not going to do it. [/quote]

So you are the only keepers of true knowledge of clean code? Hahahaha!

There were at least 3 patches that provided this through word/double-word swapping. I don't see how embedding the patch can affect the unity of the code.

BTW, you are aware you can "carve" people into coding in your style before accepting in, aren't you?



I suggested using int8, uint8, int16, uint16 in order to make sure that the parameters are of the expected fixed size since plain char, int, long, long long have different sizes depending on the architecture. The usage of int and int16 was inconsistent and I also suggested using always the numbered variants.

I said the approach that was then taken in code was not portable and that was the reason for the proposed change.

[quote]
- Glest has been coded with portability in mind, some of your comments about portability are really naive (compilers don't care if you declare function parameters with fixed byte length, they just use whatever is the fastest int in the platform). Fixed length data types are used when needed,
[/quote]

What? When did I say anything about that? I said the code uses inconsistently "int" and "int16" and should use the later always because the code assumes the sizes on i386, which are not always applicable - see long on amd64.


If you mean that I can't enforce the width of the parameter, then you should know better, those types are defined in a platform dependent way to be platform independent. Yes, there are cases where [b]on the stack[/b] the size of the passed data is bigger (they might be padded), but that is transparent to the functions and, in spite of that, the functions will see the proper values for the parameters.

Also, the packing behaviour is compiler and architecture dependent, and some compilers produce the weirdest packing (if you are allowed access to such docs, look for Green Hills compilers' for V850 and you'll be stunned).


Please, don't make a fool of yourself by trying to discredit me, just not to loose face.

Later he just removed my posts not to loose face.




As a sane programmer, I made my patch to do the swapping only on big endian platforms, and the code was enabled in through the precompiler, so there was no performance hit on the little endian arches.

Of course, any more-than-newbie programmer would agree that having two data sets for a single game is stupid and is better to do the swapping in the application itself to avoid space wastage and maintaing an alternate big endian data set.

[quote]
no more, no less. About endianness, we don't care. If we wanted to fix the problem anyway, the right way is to do the byte swap in the data, this is how it is done in commercial games, since it is more efficient.
[/quote]

You just proved how much bullshit you can deliver in one phrase just for the sake of winning an argument. All portable games and all applications that have data files prefer to do swapping on the spot just because swapping the data on the disk (or providing BE and LE data) is plain stupid and inefficient from a disk and bandwidth PoV.

For Glest, swapping the data after reading from disk is not even affecting performance in a manner that could be significant or noticed, not even for a processor running at 500MHz, since that would be done only on load, once, and just for the bits of data which are relevant; these are mostly headers, since the actual data, in most cases, is just a long byte vector. This translates in not more than 3 or 4 instructions in assembler (an init, an exchange, an increment and/or a loop instruction), and that would happen before starting a game, which is dead time anyway and wouldn't be noticed unless the data would be huge (order of hundreds of MB or GB) and the whole data set would need swapping.

Even if the data itself (not headers) represents data which needs to be swapped, that is still irrelevant in terms of speed.


BTW, the reason that in commercial games it might be done like that is because there the games are distributed in a package per platform anyway and having two data sets is not an issue since they are using the same amount of CDs/DVDs, but doing the same for a game like Glest would mean doubling the storage used and it would increase the complexity for a release, not to count the confusion of the users.

I still doubt commercial games do this, but I might be wrong.

I've been a bit surprised by the strong positive response to my previous post. People generally seemed to think it was quite non-ranty; maybe I should clean the rust off my flamethrower. :-) My hope was that I'd be able to persuade people to change some practices, so I guess that's a good thing. Of course, there are many very smart people doing bug triage very well, and I don't want to impugn their fine work. Like its medical namesake, bug triage is a skilled discipline. While it's often repetitive, and there are lots of people showing up with similar symptoms, a triage nurse can really make a difference by spotting urgent cases, cleaning up some of the initial blood, and referring the patient quickly to a doctor for attention. Or, if a pattern of cases suddenly appears, a triage nurse might be able to warn of an incipient epidemic. [Note: I have no medical experience, so please excuse me if I'm talking crap here. :-)] The bug triagers who do this well are an absolute godsend; especially when they respond to repetitive tasks with tremendously useful pieces of automation like bughelper. The cases I have trouble with are more like somebody showing up untrained, going through everyone in the waiting room, and telling each of them that they just need to go home, get some rest, and stop complaining so much. Sometimes of course they'll be right, but without taking the time to understand the problem they're probably going to do more harm than good. Ian Jackson reminded me that it's worth mentioning the purpose of bug reports on free software: namely, to improve the software. The GNU Project has some advice to maintainers on this. I think sometimes we stray into regarding bug reports more like support tickets. In that case it would be appropriate to focus on resolving each case as quickly as possible, if necessary by means of a workaround rather than by a software change, and only bother the developers when necessary. This is the wrong way to look at bug reports, though. The reason that we needed to set up a bug triage community in Ubuntu was that we had a relatively low developer-to-package ratio and a very high user-to-developer ratio, and we were getting a lot of bug reports that weren't fleshed out enough for a developer to investigate them without spending a lot of time in back-and-forth with the reporter, so a number of people volunteered to take care of the initial back-and-forth so that good clear bug reports could be handed over to developers. This is all well and good, and indeed I encouraged it because I was personally finding myself unable to keep up with incoming bugs and actually fix anything at the same time. Somewhere along the way, though, some people got the impression that what we wanted was a first-line support firewall to try to defend developers from users, which of course naturally leads to ideas such as closing wishlist bugs containing ideas because obviously those important developers wouldn't want to be bothered by them, and closing old bugs because clearly they must just be getting in developers' way. Let me be clear about this now: I absolutely appreciate help getting bug reports into a state where I can deal with them efficiently, but I do not want to be defended from my users! I don't have a basis from which to state that all developers feel the same way, but my guess is that most do. Antti-Juhani Kaijanaho said he'd experienced most of these problems in Debian. I hadn't actually intended my post to go to Planet Debian - I'd forgotten that the "ubuntu" category on my blog goes there too, which generally I see as a feature, but if I'd remembered that I would have been a little clearer that I was talking about Ubuntu bug triage. If I had been talking about Debian bug triage I'd probably have emphasised different things. Nevertheless, it's interesting that at least one Debian (and non-Ubuntu) developer had experienced similar problems. Justin Dugger mentions a practice of marking duplicate bugs invalid that he has problems with. I agree that this is suboptimal and try not to do it myself. That said, this is not something I object to to the same extent. Given that the purpose of bugs is to improve the software, the real goal is to be able to spend more time fixing bugs, not to get bugs into the ideal state when the underlying problem has already been solved. If it's a choice between somebody having to spend time tracking down the exact duplicate bug number versus fixing another bug, I know which I'd take. Obviously, when doing this, it's worth apologising that you weren't able to find the original bug number, and explaining what the user can do if they believe that you're mistaken (particularly if it's a bug that's believed to be fixed); the stock text people often use for this doesn't seem informative enough to me. Sebastien Bacher commented that preferred bug triage practices differ among teams: for instance, the Ubuntu desktop team deals with packages that are very much to the forefront of users' attention and so get a lot of duplicate bugs. Indeed - and bug triagers who are working closely with the desktop team on this are almost certainly doing things the way the developers on the desktop team prefer, so I have no problem with that. The best advice I can give bug triagers is that their ultimate aim is to help developers, and so they should figure out which developers they need to work with and go and talk to them! That way, rather than duplicating work or being counterproductive, they can tailor their work to be most effective. Everybody wins.