Last night someone told me about this amazing archive of “ephemera”l videos made possible by the work of Rick Prelinger. I spent a lot of time last night wathching videos and while they cover a wide host of topics (and there is a tag cloud to help with the categorization), they are generally short educational, advertising, or corporate films that would never had survived if it were not for these types of archives/efforts.

Steven Hanley was pondering how to keep /var/cache/apt/archives empty on the mirror that I help administer. This sounds vaguely similar to mounting the /usr filesystem read-write at the start of an APT run and read-only again at the end. (A practice I used to believe in, but due to various package upgrades making /usr busy for no good reason, and it artificially inflating the maximal mount-count and prematurely causing a fsck at boot, I've discontinued) So, putting

DPkg::Post-Invoke   "apt-get clean";  ;

in /etc/apt/apt.conf (or in a file in /etc/apt/apt.conf.d) ought to do the trick.

Last week, eight pounds of Perl books arrived at my doorstep, courtesy of deciding to work for Best Practical this upcoming summer. They’re cool people, very free software friendly, and conveniently located in Davis Square. They are also the makers of RT among other things, which Debian uses for a variety of purposes. It should be a good time. (No, I probably won’t actually be hacking on RT, but exactly what I’ll be working on is as yet undetermined.) Speaking of the summer, I have a vague plan to make a West-coast visit for a week or so at some point. I’ll be hitting at least Seattle and San Francisco; if you’re around either of these areas or possibly even somewhere in between and would like to hang out, drop me a line in comments or via email.

The packages is already done, thanks to Bradley Smith for the patch, you can find it here.I'm working right now in the unstable versions but the GCC 4.3 issues remains, in rtorrent there seems the issue isn't solved with the actual patch but libtorrent does, I will ask someone to upload them to experimental as soon as I get something ready.

There is some discussion again about what should be on topic for Planet Debian, whether it should be used for Debian-related announcements and what the archival policy should be. I believe that this discussion is rooted in two circulating views of what Planet Debian should be:

1. A forum for DD's to post Debian-related thoughts and ideas, to be used for those cases where they think a mailing list post may be less appropriate;
2. A way to collect stories about what DD's do and think in any context, the human interest angle: get to know your Debian peers more than just in technical matters.

Although I always regarded Planet Debian to be the latter and I appreciate reading posts telling me about someone's job or other interests, either one isn't an invalid approach per se. They do however prompt different choices about listing policy (Debian-only feeds vs. everything goes), how much effort it is to keep up with them and perhaps archival. The best way to match the expectations of those two groups would be to create two "planets", one for each group. Create an aggregator where any DD can add any of their feeds, and another one with a strict listing policy: only feeds that carry posts actually related to Debian development matters (probably a subset of the first). Then only the question remains which one will get to carry the Planet Debian name...

...is just not enough time to see the place properly. I took Friday and Monday off, and Thursday night a week ago, Sarah and I flew down to San Diego for a bit of a "Yay, we've achieved normality" escape. We'd intended to go to SeaWorld on Friday, vege out for two days, go to San Diego Zoo on Monday, then fly home on Monday night. Well we did SeaWorld and the zoo as planned, but lazing around the pool never happened, we ended up running ourselves ragged exploring San Diego all day Saturday and Sunday instead. We stayed at The Dana on Mission Bay, which we picked because it was the closest to SeaWorld. The accommodation was more like a motel than a hotel. There were numerous two-storey buildings across a fairly sprawling area. It had frontage onto what I presume was Mission Bay, and also had a Marina attached to it, so the outlook was quite nice. It also had free WiFi, so we could upload photos throughout the stay. The food offerings were pretty good, and reasonably priced as well. SeaWorld was really good. It's been a long time since I've been to the Australian equivalent, but I don't remember it as being as interactive. San Diego's SeaWorld had a Bay Ray feeding area, where you could purchase food (small whole fish), and hand-feed the Bat Rays. That was pretty cool. It took a bit of a courage to leave your hand in the water, palm up, with something the size of sardine dangling between your fingers and let these huge rays literally swim right over your hand so they could suck the fish from between your fingers. There was also a dolphin feeding area, where you could purchase some small fish again, and give the dolphins a pat on the head and then throw them a fish. I really love dolphins, and one day I'd like to be able to swim with them. The main attraction of SeaWorld is the various shows that they do. I think we caught all of the different ones. The killer whales are just amazing. There were a few different programs where for an additional fee, you could swim with various animals. Dolphins and Beluga whales seemed to be the ones we noticed in particular. There were a few oddities, though: The park is owned by a beer company, so there was a part where you could go and get free samples. Two per person per day (I think on the honour system). At least at the food outlet where we bought lunch (they don't allow you to bring in any food or drink from the outside "for the safety of the animals", so they have a nice monopoly on catering) every kid's meal came in a commemorative Shamu blue plastic lunch pail - whether you wanted it or not. There were two empty ones left on the table that Sarah and I sat down at. The lady cleaning up the tables asked us if we wanted them, and we said no, and she promptly chucked them out with the trash. This just struck me as a terrible waste. They obviously cost money and energy to produce, and they're just going to end up in landfill. They could have been washed and reused instead. I felt this was very hypocritical for a park that was trying to send people away with a message about conservation. Other than this nitpick, I thought SeaWorld was really great. It was a good size, and it was doable in one day, in their normal opening hours. I guess it'd be a bit slower with kids. Photos from the day are here. The next two days we spent exploring San Diego. The hotel was conveniently located on an MTS loop, which ran surprising frequently for a weekend (at least compared to public transit in the Bay Area), so we bought day passes on Saturday and Sunday and used it to get to the Old Town transit centre. On Saturday we explored Old Town, which was a historic preservation of how San Diego looked "back in the day". In the afternoon, we also bought 48-hour tickets for the red double-decker "hop on, hop off" tour bus, and did one of the two loops that it offered. The next day, we caught the loop in the opposite direction, and checked out Mission Beach, which was probably the best beach I've seen in California so far (although the water was still far too cold), saw some pretty cool alternative accommodation (possibly for next time), and did part of the other loop on the tour bus, getting off at the USS Midway. This massive retired aircraft carrier is permanently moored at San Diego, and for a fee, you can crawl all over most of it. It was very interesting, and gave a good insight into the life of a sailor. We blew a good 4 hours or so here, and ran out of time to see the entire thing (we didn't make it onto the "island" part of the ship, which we were a bit bummed about). We then caught the trolley back to Old Town, and grabbed a beer at a pub that sold it by the yard glass and half yard glass. We opted for the half yard glass, since the full yard glass seemed a bit unwieldly, and we thought it looked like a hell of a lot of beer, but the half yard glass, whilst also looking like a lot of beer, was only about one and a half pints. We then grabbed some dinner at one of the very authentic looking Mexican restaurants (they had women out the front, almost on the sidewalk making fresh tortillas on the spot) and headed back home. Photos from our exploration are here. On the last day, we went to the San Diego Zoo (which every time I read the URL for, I read it as "Sandie go Zoo!"). This zoo is purportedly the best zoo in the country, but it really didn't blow my socks off. We seemed to have a really hard time navigating the place, and spent a lot of the day walking around in circles trying to find various exhibits. It's also in a bit of a valley, so the circles tended to be up and down hills, which was tiring. I really don't think we were very efficient at all in our coverage of the place. The other thing that I personally found annoying was the cages. The wire was very close together, which made it really hard to take photos, because the camera would keep focusing on the wire, instead of what was behind it. I guess this is why God invented manual focus, but that made it very hard to photograph big cats stalking their cages. The photos we did manage to get are here. Overall, we had a great time in San Diego, and it seems we didn't really scratch the surface. I'd like to go back again and see Balboa Park, the Gaslamp district, and I thought there were more naval vessels that you could look at, but I might be mistaken. Definitely a very nice city.

I m a person who isn t satisfied with a lot of things. This both affects me and helps me on several circumstances in life, such it is. The latter also affects my way to deal with mail, mail serving and MUAs. For years, I was a strong Novell Evolution user, mainly because it was quite easy to use, it was pretty and it used to understand the needs that people like me, involved in a lot of things (some of the worthwhile, some of them shitty), required. But in the last couple of years, it began to bloat, to handle connections Bayesian filters and SpamAssassin in a way that was utterly broken and decomposed. I took a break years ago, and tried Mutt, as many free software folks and Debian developers use them on a daily basis to deal with even more incoming mail. I actually liked it, but I was just unable to deal with spam too. My local config was probably broken, fixing it was an obscure fart of Benedict XVI and hidden folders for mailing lists were just a way to forget that I actually was subscribed to mailing lists and focused only on the incoming mail on the inbox. I then tried KMail, since I started usign KDE. It was good enough for it was sometimes slow when trying to load or search on about 100 000 mails and it just didn t fulfill me. I also tried Thunderbird which only made me hate its very closed format to display its ugly UI. Besides, a lot of things on it were getting my angry, like the message filters, etc. So I just didn t give a damn and moved my whole personal mail accounts to Google Apps, giving an opportunity to a totally different approach on mail handling. So I started using the Web interface of GMail. At first I was shocked watching me dealing with a Webmail but after a while I started getting used to it and liking it. Its way to put all conversations threaded on a central inbox was sweet (i was able to filter, tag and take out of inbox too). So I liked it. Some things have never liked me whatsoever: It will always use your default mail address to reply to all messages, even if they are delivered to another recipient, which I consider retarded; its way to let users to top-post, etc, (you should also see how debian-private is seen on GMail and how the google sponsored links propose products based on all its threads xD). The good thing here also was that while not being a total purist, I loved that most spam has automatically handled for me, oh thank Lord I m a lazy bastard. Then I found Sup, which I think is like GMail but on mutt. It is written in Ruby and distributed as a gem (I d prefer it to be in C/C++, but I ll always give the benefit of doubt). Its main feature? A console mail client featuring GMail s features, such as, one inbox, one big archive and labels all over the place, which is exactly what I was (probably) looking for. As the time of writing,Sup can only connect to IMAPs remote servers or read a number of local file formats. So, I undusted fetchmail and set it up. Since all my mail accounts now are forwarded to the main GMail account, I only need to handle one fetchmail config to get messages with POP (and some procmail recipes salting touch). Here comes the sweetest thing from all this setup, by enabling GMail s POP support, you can also specify if you want it to delete the GMail copy or store it. Since I ve used 2% of all my storage, the best thing to do right now is to store and archive, which means that while i download all my email everyday and several times a day, all downloaded copies are also being stored on GMail, so in case I don t have access to my machine, I can still find messages on the web interface. GMail also works nicely when you are sending an email from your remote mail client and using GMail s SMTP, then also the mail you are sending gets stored on your GMail web interface, which is totally cool. So I think I m mildly content now with what I have. This also leads me to another awesome feature for me: Spam gets processed by GMail before I fetch it, so most of my downloaded POP mail is ham. In case I want to see some spam, the web interface will have it as usual for 30 days before being deleted. I like to improve my time for productivity, to get more things done in less time, I do like learning about it, and the proof of concept for GMail handling being used by Sup and the free facilities that Google offers to dudes like me is just a great of avoiding procrastination. It s a hell nice bag of features for me, and probably for you, why not try it?

Recently a Debian Developer resigned from a position of responsibility in the project by writing a blog post. I won’t name the DD or the position he resigned as I think that there are general issues which need discussion and specific examples will get in the way (everyone who is seriously involved will know who it is anyway - for those who don’t know, it’s not really exciting). Also I think that the issue of the scope of a Planet installation is of wider importance than the Debian project, so it would be of benefit for outsiders who stumble upon this to see a discussion of general issues rather than some disagreements within the Debian project. There has been some mild criticism of the DD in question for announcing his resignation via a blog post. I don’t think that this is appropriate. In the absence of evidence to the contrary I’ll assume that the DD in question announced his resignation to the relevant people (probably the team he worked with and the Debian Project Leader) via private email which was GPG signed (if he indeed intended to formally resign). The resignation of one DD from one of the many positions of authority and responsibility in the project is not going to have a great affect on the work of most DDs. Therefore I don’t think that it was necessarily a requirement to post to the debian-private mailing list (the main list for communication between all developers regarding issues within the project) about this. It was however an issue that was bound to get discussed on debian-private (given that the circumstances of the resignation might be considered to be controversial) so it seems to me that sending an email of the form “here is a blog post I’ve written about my resignation” would have saved some pointless discussion (allowing us to skip the “why didn’t you send email” and get right on to the main discussion). A resignation letter from a public position of responsibility is a significant document. Having such documents stored on publicly accessible places is good for the community. Having a record of all such documents that you have written stored on your own server for reference (by yourself and by other people you work with) is a good thing. Therefore it seems to me that a blog is an ideal place for a resignation letter. It used to be regarded that there was a certain formality in such things, and that a letter of resignation was required to be delivered in the most direct way possible (by hand if convenient) to the person who receives it. If such conventions were followed then a blog post would occur after the receipt of the letter of resignation had been confirmed (possibly in this case a confirmation email from the DPL). But in recent times things have become less formal and the free software community is particularly informal. So it seems quite appropriate to me to have the blog post come first and the email notification merely contain the URL. Now a letter of resignation is expected to contain certain specific details. It should say specifically what duties are being resigned (particularly important when a person performs many tasks), it should have a date from which it will take effect, and it might be appropriate to mention issues related to the hand-over of tasks (whether the person resigning is willing to work with their replacements). The “resignation” (if we should call it that) in question did not contain any of the specific details that I would expect to see in a formal resignation. This indicates to me that it could be interpreted as not being a formal and official resignation, but instead being a post (possibly written in haste while angry) about a situation which may not end up being an official resignation. Until we get some more information we won’t know for sure either way. This demonstrates one problem with blogs, people usually have a mixture of serious documents and trivial things on the one blog. It can be difficult to determine how seriously to take blog posts. I’m not sure that there can be a good solution to this. At the moment some people are suggesting that every DD should read Planet Debian [1]. I disagree with that. If there is an issue which is significant and affects the entire project then it should be announced on one of the mailing lists such as debian-private, debian-announce, or debian-devel-announce (and will be announced on one of them eventually even if not by the person closest to the events). Forcing every DD to read a lot of blog posts is not in the best interests of the project. Now we could create a separate Planet installation for such things, there is already Debian Times [2] and Debian Administration [3] which serve as a proof of concept. If there was a Planet installation for important stuff related to Debian which had it’s content syndicated in various ways (including an email gateway - Feedburner.com provides a quite useful one) then requesting that everyone read it’s content in some way (either by web browsing, an RSS feed reader, syndication in another Planet, email, or something else) would not be unreasonable. The volume of posts on such a Planet would be quite small (similar to the current announcement mailing lists) so if received by email it wouldn’t fill anyone’s mailbox and if people visited the web site they would only need to do so every second month if that suited them. The issue of what types of posts are suitable for Planet Debian is probably going to get raised again soon as a result of this.

• [1] http://planet.debian.org/


• [2] http://times.debian.net/


• [3] http://www.debian-administration.org/

Share This

I was recently checking to see what, if any follow-up there had been from Sun’s ham-handed handling of the Open Solaris Trademark, and I ran across this very interesting comment from Jon Plocher’s Candidate Statement for the Open Solaris Governing Board:

“I also think there was a misunderstanding about what Sun desired when it launched the community (in part) to encourage developers to adopt and use Solaris. My take is that, while there *is* value in getting more kernel, driver and utility developers contributing to and porting the (open) Solaris operating system, there is significantly *more* value in having a whole undivided ecosystem based on a compatible set of distributions, where application developers, university students, custom distro builders and users are all able to take advantage of each other’s work. Put these two things together, and you can see Sun’s predicament. Sun *wanted* a community that empowered application developers, but *got* a community aimed squarely at kernel hackers. Whether you see this as the “kernel.org -vs- Ubuntu” fight, or the “fully open -vs- MySQL model” argument, in my opinion, it all is simply a reflection of the above mismatched expectations.”

So that explains why it’s take three long years to try to get basic open source development tools (such as putting Open Solaris source code in a distributed SCM located outside of the Sun firewall) for Open Solaris. It was never was Sun’s intention to try to promote a kernel engineering community, or at least, it was certainly not a high priority for them to do so. This can be shown by the fact that as of this writing they still are using the incredibly clunky requester/sponsor system for getting patches into Solaris; setting up a git or mercurial server is not rocket science. This lack explains why Linus gets more contributions while brushing his teeth than Open Solaris gets in a week. So if you run into a Sun salescritter or a Sun CEO claiming that OpenSolaris is just like Linux, it’s not. Fundamentally, Open Solaris has been released under a Open Source license, but it is not an Open Source development community. Maybe it will be someday, as some Sun executives have claimed, but it’s definitely not a priority by Sun; if it was, it would have been done before now. And why not? After all, they are getting all of the marketing benefit of claiming that Solaris is “just like Linux”, without having to deal with any of the messy costs of working with an outside community. As a tactical measure, astroturfing is certainly a valid marketing trick. But after three years, the excuse of “just you wait a little longer, we’re just trying to figure this open source community stuff out”, is starting to wear a little thin. Furthermore, if (as Jon Ploncher claims) this was about “empowering application programmers”, why was it that Sun’s first act was to trumpet how wonderful it was to release the Solaris source code under a Open Source license? This only seems to make sense if the Open Solaris initiative was really a cynical marketing tactic to try to save Solaris from being viewed as irrelevant. If that was Sun’s intention, I think it is fair to say that from a marketing point of view, the tactic has been at least partially successful — although as Jon has admitted, the goal of creating a full community with application developers, university students, and so on, hasn’t materialized for Open Solaris. Sun has the dream; the Linux community is living it. However, from business standpoint, I wonder if Sun will really be able to sustain their Solaris engineering team if they will really be doing all of the work themselves, and outside contributions continue at the rate of 0.6 patches per day. After all, the margins when you are selling low-cost AMD servers are much lower than when you are selling ber-expensive SPARC servers. With Linux, we have a major advantage in that kernel improvements are coming from multiple companies in the ecosystem, instead of being paid for by a single company. And given that 70-80% of Sun’s AMD servers are running Linux, not Solaris, it’s not clear how Sun justifies their Solaris engineering costs to their shareholders. Furthermore, if Solaris on x86_64 were to actually take off, there’s nothing to stop competitors from selling Solaris support — except the competitors won’t have to pay the engineering costs to maintain and improve Solaris, so they would be able to provide the support much more cheaply than Sun could. So while Sun’s marketing tactics have kept Solaris alive in some verticals, I have to question how successful Sun will be in the long-term.

Section 5.7.2 of the ACPI specification provides for a method called _OSI. Platform firmware can query for various interfaces, which allow it to tweak its behaviour depending on the interfaces that the OS supports. Linux claims to support the following interfaces:

• Windows 2000
  
• Windows 2001
  
• Windows 2001 SP1
  
• Windows 2001 SP2
  
• Windows 2001.1
  
• Windows 2001.1 SP1
  
• Windows 2006

which all correspond (unsurprisingly) to different versions of Windows. Linux used to be in there, but was removed for reasons I'll get into later.

The typical way in which this feature is used by a platform is by querying each of the interfaces in turn, starting with the most recent a firmware is aware of. After the first match, a value will be stashed somewhere and used elsewhere in the firmware when making certain decisions. An example of this may be only enabling certain devices (such as the HPET) if the OS claims to support Windows Vista.

As I mentioned, recent versions of Linux no longer claim to support the Linux interface. There's a couple of reasons for this. Firstly, some platforms break if they're told that they're running on Linux. It's usually an entirely untested codepath. Secondly, the whole point of the _OSI method is to provide the platform with information about the interface supported by an OS. "Linux" is too coarse grained - we make no guarantees that the interface between the OS and the platform will remain constant. "Linux 2.6.25" isn't all that much better, since distribution patches may alter the behaviour and BIOSes would become specific to a given kernel version. We could have something like "Linux ABI 1" and then bump that every time we altered the behaviour of the kernel in this respect, but this would become unwieldy fairly quickly (what would count as an ABI breaking change?)

So what kind of interface can we claim to provide? The sad truth of the matter is that most vendors will only test their code against Windows, and that as a result Windows provides the de-facto specification for OS/platform interaction. We could skip claiming to be Windows, but (in the best case) that means that the system will assume it's working with an OS that supports no advanced features. Rather than getting support for brightness changes being handled by the OS, we get stuck with SMM traps and unexpectedly missing time. If we want hardware to work to its full potential, we need to claim to be a recent version of Windows.

Does this mean the entire _OSI mechanism is useless? Not really. It's still useful for providing information about supported functionality. One example used in the spec is whether or not the OS implements the ACPI 3.0 thermal model. Another obvious (but unspecced) example might be whether or not the video opregion spec is implemented in the OS. _OSI strings which explicitly advertise the existence of advanced functionality are something that should be specified and encouraged. What they shouldn't be used for is as a way of advertising lacking functionality, which is effectively the only way that Linux can be usefully interpreted today. We don't want machines to automatically repost their video if they detect they're running Linux. It makes it harder to implement proper kernel-level graphics resume code. We don't want them to suddenly alter their keyboard behaviour, because that probably makes it harder to support older machines that don't have these workarounds.

Message to vendors: If we're not behaving in the same way as Windows does, let us know. We'll fix it. This has the benefit of fixing not only your latest and greatest platform, but also all the older ones that expected the same behaviour. Please don't try to work around our bugs in your BIOS - it just means that we need to special case you forever, and in the long run your hardware won't work as well as it would if we just fixed things properly.

Yesterday I signed the contract for a new job in Berlin. I'll start begin of June.
It's remarkable how fast the subscription to debian-jobs mailing list resulted in a new job, although I think that this is not necessarily the same for everyone subscribed there. :-)

I spent the entire week at the SambaXP conference in G ttingen, Germany. The conference is the annual conference of the community of developers, contributors and users of Samba. I general call it "my annual german pilgrimage" as I attended all seven editions of the conference, the only FLOSS conference I attend on my work time, as my daily work involves quite a lot of uses of samba. This year featured a workshop or training session held by John Terpstra, longstanding FLOSS evangelist and member of the Samba Team for over 10 years, and Karolin Seeger, the brand new release manager of Samba. This has indeed been an incredible opportunity to have discussions with them about the packaging work for Samba. Actually, the work we did in the last 3 years to bring Samba Debian packages in a very good shape (when I don't screw up) is much appreciated. I think these days have been another opportunity to keep that link very closed. I have been impressed by the promising work of Karolin with respect to the preparation of the release and the very serious way she has to do that work....as well as her very friendly, while still discreet approach to technical discussion. Some work was done on Samba package bugs, though less than usually (the remaining ones are harder and harder to tackle!). I mostly work on Debian packages as well as .deb packages prepared by Sernet (the services company that organises the conference and employer of some Samba Team members), as these could some day become the packages provided by the Samba Team. Talks at the conference were pretty interesting, to keep connected with Samba 3.2 and 4.0 development. News from Andrew Tridgell about exchanges with Microsoft (yes, The Evil) and access to MS documentation, are very promising. The collaboration between Samba developers and Microsoft enginneers is now working well again, at the engineers level (as Tridge says: "lawyers are away, now, we can talk at the engineers level and restore the link that existed in the early 90's"). I also could measure the progress of the Openchange project whose ultimate aim is to provide a complete Microsoft Exchange replacement solution. They currently have working MAPI libraries and an Evolution plugin for Exchange is under development, while the bricks to build a server are patiently being put together. Good discussions with Julien Kerihuel, the lead (and French) developer and manager of the project. Jelmer Vernooij and I also settled the final plans to get Samba4 packages in Debian. I proposed to make a first upload to experimental, but quite soon to upload to unstable, the point being a largest as possible exposure of that code, so that upstream developers (Jelmer himself, Andrew Bartlett and a few others...) get as much feedback as possible. That upload will not be targeted for lenny (we'll block it from entering testing). For that reason and also because Samba 3 and 4 will certainly coexist for years, the source package will be named "samba4". Expect more news quite soon. And final conclusion of that week: I've also been delighted to be able to visit Alex and Meike in Hildesheim, as well as Andreas in Wernigerode. It's always a great pleasure to see longstanding Debian friends. At the beginning of the week, I planned to see *two DD and finally, at the end of the week, I can tell I've seen *three* Debian developers, finally!

They ve came down with a participant number for fisl9.0: 7417. That s it over SEVEN THOUSAND! I was told it s still an estimate, since they haven t merged the databases yet (anyway, that s the official number so far). This fisl is huge! One more picture of the crowd, just for the record: Now everything is fine. TVSL went online with no problems (once the network was fixed) and remained broadcasting the event the whole day long. All was so fine that one can think it s even boring! I spent half the day attending our company booth and the other half trying to help the organizing committee. While walking around, two linux-driven home-made robots called my attention. The first one serves water to the guy in front of it: The other one just walks around: On the Debian side of the trench , I met Jo o Eriberto Mota Filho, Debian Developer wannabe who asked me to sign his key. I ve seem he before, since he s a frequent speaker at fisl and welcome him as a future developer. Meanwhile I was reminded by faw that I still owe him my signature since DebConf4!! I signed so many keys in the KSP we held then, that one or two might have been missed I intend to fix that RSN ;-)

The default keyboard autorepeat setting on most systems is boringly slow. Even worse, the delay before autorepeat kicks in is so long. This is great for novice users, but we programmers deserve better. Here's a calibration procedure that I use:

• The autorepeat delay should be as short as possible, but a concentrated, damp but short keypress should not cause multiple keypress events.
• To determine the most suitable autorepeat rate, test your accuracy. Open an editor and try to enter multiple lines of about 50 characters using the autorepeat feature. Pick the highest setting with which you can consistently get the line length within 2-3 characters of the target. (The 2-3 character margin comes from the practice of releasing the autorepeated key a little early and entering the remaining 1-3 characters, if any, with separate keystrokes.)

For me an autorepeat delay of ~250ms and 80 char/s rate works well. To get your numbers, you can use the command xset q grep 'repeat rate' . This tweak make the standard direction keys (and particularly the backspace & delete keys) much more useful: you can frequently get away without using special editor commands or, say, having to select things to delete them and thus resetting the X buffer. It makes things a little faster and more responsive. Try reverting to the standard setting after a few weeks of fast repeat to feel the difference.

Some come, others kind of go.

I warmly welcome the new 19 developers (great female ratio there!) and humbly ask the rest of us to support the new blood carriers. If they made it through this, they are surely worthy of our cause and will probably accomplish a lot more if us, the old farts, make it easier for the ones to come in the future.

Where do I join the Debian elderly club?

when I woke up today (after sleeping in for the first time with my new roll-top in front of my bedroom window) I was surprised & confused by a couple of "congratulations!" messages in my irc away-log. it took me a bit of time & coffee (& looking into my mailbox) to begin to realize that my Debian account had indeed been created while I was asleep. — in fact I guess I still haven't completely realized my new status as Debian Developer.

as others I'd like to follow the good tradition of taking the opportunity to thank some of the people who helped me to get there:

• first & foremost Tony Mancill, my advocate, permanent sponsor, & long-time co-maintainer; for all his support in preparing & quickly uploading packages, tracking down bugs, encouraging & advocating me but also for our very pleasant "chats" via email. — we have already agreed to continue co-maintaining each other's packages.
• the friendly & helpful guys from the Debian Perl Group: Gunnar Wolf, for always encouraging me (to join the group, to apply for the New Maintainer Process, ...); Damyan Ivanov, for teaching me so much (even if he called it "nitpicking"); Gunnar, Damyan, Krzysztof Krzyżaniak, Niko Tyni, Roberto C. Sánchez, Stephen Gran, Frank Lichtenheld, Jaldhar H. Vyas, Russ Allbery, Raphaël Hertzog, & some others for uploading packages I've prepared & helping me when I had questions or problems; Martín Ferrari, for all his help, expertise, & especially for the fun & the good times we share on IRC.
• my Application Manager Wouter Verhelst; for guiding me through the New Maintainer process not only fast but also in a very helpful, at the same time demanding & supporting way.
• the Debian Women sub-project; for making Debian a better & friendlier place not only for women but in general.
• finally: the people who used the time while I was asleep to actually create my account tonight :)

some final thoughts about the NM process from my point of view:

• it took me some time to actually apply for NM; what deterred me was not that I knew it would take some time but that I didn't know how long the time would be; & that I knew that the bigger part of the overall time would consist of waiting.
• I applied on 2007-04-03, my account was created on 2008-04-18; 380 days is not bad altogether in my opinion; the actual work with my AM was from 2007-08-12 until 2007-11-28 (i.e. 108 days, or 28% of the whole duration).
• I did enjoy the actual checks; I had to read & think a lot, & I learned a lot in that period.
• Front Desk (i.e. Christoph Berg) was very quick on all necessary steps.
• I was never demotivated about my Debian work because of all the people supporting me & taking the burden of uploading packages I had prepared. but I have to admit that I got a little bored in the last months of waiting after the report had been submitted by my Application Manager.

& now it's time first to celebrate & then to try to fully grasp my new rights & responsibilities.

*Ahem*... I'm soooo excited! After 884 days, I just became a DD. It was almost two years and a half of much work, learning, patience, struggling to keep the morale up, and more work. In fact, Debian is already taking almost all my free time since months ago, something I don't regret at all. I was able to do most of the things I wanted to do, even without an account, including: DebConf organisation, team-maintaining packages (sorry pkg-perl folks, dc8 didn't leave me much time lately), some QA work, coding tools, etc. But this small feat has a huge symbolic importance to me, now the project as a whole is recognising me as a full member; many people already did individually, but sometimes you need the "official" stuff. So thanks to all the people that helped me during the way (sorry for the omissions!): maxy, for introducing me to Debian, marga for encouraging me to apply to NM —and all the moral support—, des for the help and the sarcasm, damog for being my first AM, even if we had our problems, ana for being my second AM and being so supportive, the Perl-lings for being such a nice bunch of people to work with and to learn from. Thanks also to all the nice people I've met along the way (dudes!), you make Debian a nicer place. Update: There was another paragraph that I butchered after noticing that the actual process in the last 24 hours was different than what I thought. But anyway, my thanks to Sam, Myon and Ganneff for their respective help in this process. Also, I don't want to forget to thank Ganneff for the trust he'd put on me during this time. Tags: Planet Lugfi, Planet Debian, Debian

Yay! A big fat thank you to:

zobel for advocating me

aba for being a great (and thorough) AM

HE for checking my application so fast

DSA, DAM and the Keyring Maintainer for pushing the right buttons and especially for doing so on a friday, so nothing gets in the way of a proper celebration tonight!

Tolimar for moral support

Pia for her invaluable support with T&S2

PS: Independently from recent events my account and also the other 18 where not created by Jörg, but on James' initiative. Just to put things straight.

Phrack is back..

Chronicle

My blog compiler received a bit of love recently, primarily because MJ Ray wanted to use it. As mentioned before I've added a simple spooling system, and the mercurial repository now contains a simple RSS importer.

Debian Work

In other news I've been working on various Debian packages, here is a brief summery:

bash-completion

After seeing a RFH bug I closed a few bash-completion bugs, and submitted patches for a couple more. I was intending to do more, but I'm still waiting for the package code to be uploaded to the the alioth project.

javascript work

I've updated the jquery package I uploaded to follow the new "Javascript standard" - in quotes only because it is both minimal and new. Once the alioth project has been configured I'll upload my sources.

Apache2

I've agreed to work on a couple of SSL-related bugs in the Apache 2.x package(s) - time disappeared but I hope to get that done this weekend. Initially that was because I was hoping I could trade a little love for getting a minor patch applied to mod_vhost_alias - instead I've now copied that module into libapache2-mod-vhost-bytemark and we'll maintain our own external module.

Hardware

I've been loaned a Nokia 770 which is very nice. Having used it with vim, ssh & etc I think that I'd rather have a device with a real keyboard. The Nokia 810 looks pretty ideal for me. I'm going to be asking around to see if I can get a donated/loaned device to play with for a while before I take the plunge and pay for one of my own.

I've got a couple more things on the go at the moment, but mostly being outdoors is more interesting to me than the alternative. Hence the downturn in writing and releasing security advisories. I'll pick things up more fully over the coming weeks I'm sure. ObQuote: Shaun of the Dead