Can you see anything like this in BLR? Originally uploaded by aanjhan
No, I will not see

I do very little law-firm-life blogging here, although that life is where I spend the overwhelming majority of my time. Consider Real Lawyers Have Blogs (something of a misnomer — they mean real firms have blogs). Counterpoint: Be Careful What You Post (motion to amend to assert defamation counterclaim against new defendant for comment on blog entry granted). In any event, in case I have any law firm associate readers, I’ll send props to the ABA’s free Litigation Podcast. It has a high signal to noise ratio, and the episodes are usually short enough to complete in my walk to and from the train. I’d like to draw attention to the latest post (”cast?”), The Secrets of Superstar Associates (21.1 MB MP3). Although on some level the advice should seem obvious, the “rules of the game” are seldom spelled out so clearly. I recommend it to any law students looking to join a firm and junior associates as well. In fact, even if you’re not a lawyer, much of the advice is transferable to surviving in any highly-skilled-professional organization. Technorati Tags: ABA, American Bar Association, Litigation Podcast, Law Firm

Share This

Fundamental fact: non-technical people can't or won't read mail bounces. They (the bounces) are far too technical. Most people, even if they could understand them intellectually, most won't even try to read them. Their input channel gets jammed, their parser shuts down, whatever you want to call it. Obviously, this is extremely frustrating, especially because I take care that my spam filter never drops mail but always rejects it so that the sending mail server can generate a proper bounce. Proposed solution (and don't tell me this can easily be scripted in mutt. The people I'm talking about wouldn't even recognize mutt as an email program if they'd ever see one): Index all outgoing Message-Id's. When a bounce comes in for a known message, don't display it but display some kind of locally generated, friendly substitute with a direct 'correct address and re-send' button and a clickable link to the original message.

Now that I've got a little more time on my hands, I've updated and done some bugfixing on my patch to quirk ICH devices over from PIIX-compatibility mode to AHCI mode. It turns out that ICH8 is a little different to ICH7, and needs an extra bit to be set. Without that being done, the AHCI BAR would still be programmed as i/o ports. Interpreting this as mmio space let to unsurprising crashes. With a bit of luck, this should also fix the "My CD drive is no longer there" issue - you'll still need to load ata_piix in order to access it, but make sure you do it after ahci has bound to the sata controller.

Patch against 2.6.24 is here - let me know if it works for you.

(Context: AHCI provides support for various features that the PIIX compatible mode doesn't, including link-level power saving. This is potentially beneficial for mobile users)

Installing Debian on your Eee PC is even easier now, as the option to install over wireless is now present in our custom debian-installer image. Also, the new installer automates installation of many more things than prior releases, so wireless, acpi hotkeys and suspend all ‘just work’ out of the box. Two barriers remain to including wireless support for the Eee in Debian main. The first is the lack of wireless support in the official d-i installer. The second is the dependency on the non-free madwifi driver. I have no illusions about this being ready for Lenny, but I hope in Lenny + 1 this will be realized. The good news is that Nick Kossifidis is working on getting support for the Eee into ath5k. For patches, see: http://kernel.org/pub/linux/kernel/people/mickflemm. I have created a stub page FreeYourEee in our wiki about making a completely DFSG free install of Debian on the Eee. I encourage anyone going this route to contribute.

I thought the spanish region of Extremadura had 4 million inhabitants and 200000 computers running GNU/Linex, a custom Debian distribution.

I was wrong. It's 1 million inhabitants and ca. 100000 computers running Linex - which is a much better ratio :-)

The exact number is not really known, because about 2000 computers (or so, details...!) don't provide data back for some unknown reasons. Probably a configuration detail.

Details are sooo important, and I love that. But at the same time, details are irrelevant (100000 or 102000...), I love that too.

Personally, I think the Debian Edu developer gathering the last 3.5 days here in Extremadura was very productive and fun. It was so productive, there were so many fun, interesting and insightful discusssions, that currently I can only think of one detail, I want to mention here, which really isn't a detail, but something bigger. I'm very very happy about the work which was put into bug 311188 here, mostly by Winnie. #311188 is just a meta bug, the juice is in the details, all the bugs which are blocking this bug.

And as you are probably interesting in this detail, why we care so much about this bug, let me explain: the blocking bugs of that bug will prevent upgrades from Lenny to Lenny+1 from working without problems for Debian Edu installations. That's why we care - it's only a detail, but an important one.

And now I'll run to get a last drink from the hotel bar, instead of correcting details in this post. Thank you, Cesar y Jose, for arranging this great meeting and everybody else, who makes Debian a fun thing to work on details and the great picture!

Mutt

Fran ois Marier has recently been posting some interesting entries about the Mutt mail client upon his blog. His tips are pretty basic, but that doesn't make them less useful. So here's my tip of the day: reply_regexp. When you're viewing a mail, and you choose to reply it the subject of that mail is the basis of your message's subject. For example given a message with "Subject: hello" your reply will typically have the subject "Subject: Re: hello". This is real rocket science here, people. Imagine you're using SPAM filtering which tags messages it isn't sure about with a prefix "UNS:". Suddenly things don't look so hot, as you might end up with a mail with the subject:

Subject: UNS: Re: Hello

Reply to that mail, whilst being half-asleep, and what do you get? You get this:

Subject: Re: UNS: Re: Hello

Bad. Ugly. Wrong. The following snippet in my ~/.muttrc file correctly deals with this case:

set reply_regexp="^(((UNS:[ \t]) [rR][eE]:[ \t])*)+"

Neat. Cool. Nice.

Advertising

I've paid for some advertising upon the LWN.net site. (No link, I'm not trying to game things here.) I didn't know what to expect, but I was willing to risk the expenditure as a way of saying thanks to them for their great content. (Because of my Debian Project membership I get a free LWN subscription, as do all developers. see here for details if you're a developer without a subscription.) I've paid $30 and that has given me a months run of my advert, with clickthroughs hovering around 1%. Not horribly bad at all! I probably won't repeat the experiment for the forseeable future, but I'm glad that I did it at least once. If you have something appropriate for a Debian-based audience don't forget you're welcome to advertise upon the Debian Administration website for free - See the Advert FAQ for details.

ObQuote: The Craft Update: jquery was accepted yesterday. Today I uploaded a new version to more closely align it with the javascript-policy.

Are you rebasing or merging? seems to be the 64 thousand dollar question over in vcs-pkg discussions. Various people have offered their preferences, and indeed, several case studies of work flows have been presented, what is lacking is an analysis of the work-flow; an exploration of which methodology has advantages, and whether there are scenarios in which the other work flow would have been better. Oh, what are all these work flows about, you ask? Most of the issues with packaging software for distributions have a few things in common: there is a mainline or upstream source of development. There are zero or more independent lines of development or ongoing bug fixes that are to be managed. And then there is the tree from which the distribution package is to be built. All this talk about packaging software work flows is how to best manage asynchronous development upstream and in the independent lines of development, and how to create a coherent, debuggable, integrated tree from which to build the distributions package. The rebasing question goes to the heart of how to handle the independent lines of development using git; since these lines of development are based off the main line of development, and must be periodically synchronized. Here is a first look at a couple of important factors that will have bearing on that question, and packaging software for a distribution using Git in general. This is heavily geared towards git (nothing else does rebases so easily, I think), but some of the concepts should be generic. I am not considering the stacked set of quilt patches source controlled with Git in this article (I don t understand that model well enough to do an analysis) As a teaser, there is a third answer: neither. You can just add an independent line of development, and just let it sit: don t rebase, and don t merge; and in some circumstances that is a winning strategy.

(image found at www.noooxml.org/start)

---

An email saying that Nectarine now has three, new dedicated streams for music is not spam, and it never will be. You can now find one stream for chiptunes, one for oldskool songs, and one for songs only included in a demoscene production. And yes, this is the right time to sign up for Solskogen 2008.

After the April fools joke that wasn't, the hangovers have cleared and OOXML has passed. Unless it is successfully appealed, it will become standard in 2 months. Thankfully, it is being appealed. If you can, lobby your national standards authority to appeal and stop this. All around the blogosphere, people have been slating ISO for passing this. While a lot of irregularities happened to pass it, for which the ISO should be ashamed, we need to be aware of one thing: ISO is on the good side, folks: we want standards. Most people who are involved in ISO, want good standards. Microsoft don't. Those on ISO committees felt worldly wise about corporate lobbying: they'd seen it before. They were used to companies lobbying them to rubberstamp their technology as an international standard. But Microsoft were playing a different game. They don't want standards. They already have their monopoly. They don't even want their formats to be standarised. They want to be able to change them every release, and force another sale of Office 2010,etc. What they want to do is trash the idea of standards, and they're succeeding. ISO was used to being the battleground, the referee. Instead it was the target, and didn't know how to cope. This battle is like the Celts fighting the Romans. Used to cattle-raids-as-warfare, they hole up and defend themselves when the Romans come marching in, and expect the Romans to give up in a day or two when their 'cattle raid' fails. Instead the Romans dig in for the long siege, and win, while the Celts look on puzzled, and lose. We need to retake ISO and defend it. I set up the iso-codes project within Debian several years ago to minimize the number of country and language lists out there. Now with OOXML it appears we have to also track the Microsoft list, and incompatabilities, as OOXML requires it. Ditto with DrawingML instead of SVG, and a wholew host of other standards. Standards committee work is hard and boring. But if we don't get involved theres a lot of boring coding ahead, just tracking Microsoft. Time to join the National standards committees, somehow. Or should we lobby ISO to join as an international body? Tags standards, iso, ooxml, iso-codes

From the official press release:

April 3, 2008 - The Swiss Open Systems User Group /ch/open organizes the first international Hackontest sponsored by Google as part of informatica08, the Swiss year of computer science 2008. Hackontest is a 24-hour programming competition of three teams of different open source projects. Its goals are to enhance popular Free Software projects according to user needs and to demonstrate to the public how enthusiastically open source software is being developed. Starting in April 2008 users and developers of open source software may submit feature requests for their favorite Free Software projects and rate and comment them. On Swiss national holiday August 1st, 2008 the Hackontest jury will pick the three most promising teams. They may travel to Switzerland on September 24/25, 2008 to participate in the competition located at the OpenExpo Z rich 2008. The jury is staffed of ten highly renowned open source hackers such as Jeremy Alison (founder of Samba), Bruce Perens (founder of the Open Source Initiative), Alexander Limi (founder of Plone), Harald Welte (founder of gpl-violations.org) and Jono Bacon (Ubuntu community leader). The Hackontest platform and further information about the event is located at www.hackontest.org.

I have been asked to serve on the jury. This sounds like it ll be a fun and interesting event, and if not only I finally get to meet Alexander Limi, with whom I ve worked on Plone, and Bram Moolenaar, author of the best editor around. Now, Debian! Let s get some proposals in! NP: The Good, the Bad & the Queen: The Good, the Bad & the Queen

I Just released NBD 2.9.10. It had been upcoming for a while already, with a few interesting patches being applied. In addition, some bugfixes were applied to subversion, and some more interesting things had happened. Really, a release was getting overdue. Sometimes life just intervenes. Anyway, apart from the upstream release, I of course also did a Debian update of these packages, which also contains some changes that had been pending for a while. Combined, the changelog mentions five different bugs of which none are l10n bugs, which is a record (there had been 5-bug uploads before, but those did include l10n bugs). On top of that, I closed some other outstanding bugs which really had been closed a while back, but either I forgot to close the bug, or I forgot that there even was a bug in the first place. I should stop slacking so much. While preparing this upload, it occurred to me that nbd has come a long way since I got involved with it back in 2001. The original nbd-server that Pavel Macheck had written did work well, but it was a bit of a hack; it did not fork() upon startup or anything similar, so starting it was a pain. It could only serve one device at a time. It was not documented. It had no concept of a configuration file. The code, frankly, was also bit of a mess; it was written on a hack night, and not much design had gone into it. I guess it was no surprise, then, that no single distribution had a package for nbd at the time. I only packaged it because I actually had some use for nbd; at the time, I'd just bought quickstep, my first functional m68k machine, and had installed Debian on its 250MB hard disk. However, running a buildd on that machine proved problematic, to say the least; with so little disk space, you could hardly boot Debian, and due to speed and clock skew issues, NFS was not an option. So I went with NBD, which worked great. After a while, quickstep got a bigger hard disk (it has an 18G disk today), so diskspace was less of an issue at that point; but, well, I'd been maintaining it already, and that was fun, so I didn't think of giving up. When Pavel lost interest in nbd back in 2003, he gave maintenance of the kernel bits to Paul Clements, and maintenance of the userspace bits to me. I promptly went ahead with what I thought should have been done already, but felt reluctant to do at the time to suggest that: refactoring the code, adding features, etc. Today, nbd-server does support all of the above things of which I mentioned it was lacking; and, probably as a result of that, apart from Debian, there are now packages of nbd in, at least, SuSE, Fedora, Gentoo, uClibc, and FreeBSD (the latter obviously only containing the server). Well—the fact that LTSP uses it might have something to do with it, too ;-) That's not to say there's nothing left to be done, but I'm quite happy about how far we've come. Really.

Bernie S wrote in: “Bit concerned RTBF not showing Flanders on Sunday (4 hrs last year). Only Eurosport (19 east) and RAI Tre (13 east) I can find so far. I just checked ARD/ZDF no deal there. Also France 3 said on Sunday at CI that Flanders is not live there. So, coverage is a bit sparse, although NOS will probably show but are encrypted.” Thanks Bernie. Eurosport is schedules show it as 13:00-17:00 CET and RAI Tre has it 15:10-18:00 CET (which probably means Eurosport will overrun and not show the presentations, as sadly usual). Unusually, it’s also on SFinfo (13 east) at 13:00 CET. Highlights 15:15 CET Monday and 13:30 CET Wednesday on Eurosport.

I have been using Arch to package my Debian packages since 2003; which means that Arch has had a good long run as my SCM of choice. I have been using CVS for a few years before I moved to arch, and the migration took me about six months, since it involved a while new philosophy of packaging; I am hoping that migrating to git would not involve such a major paradigm shift, and thus be less disruptive and time consuming. What follows is a narrative of my efforts to get educated about Git. This article is meant to be an annotated, selective, organized set of links to information about Git. How does it differ from the myriad of other link collections about Git proliferating on the web? Well, the value add is in the annotations and the organization: while not quite a narrative of my exploration, this is an idealized version of what I think my discovery process should have been, to be most effective. Staging the information is important; google finds one lots of information that is incomprehensible to someone just coming to Git. This selection of links is actually selective; I have included only pointers to resources that fed me information at the level that I could handle at that stage, and I have eliminated links to information that was not new at that point. I have tried to select the best (in terms of information and clarity) of breed for each kind of information source I have come across so far. There is a caveat: while still a beginner, though I am able to better judge now what is confusing to a beginner than I shall be when I have become more familiar with the system, I am still enough of a novice not to trust my judgement on what really is best practice. I can fix the latter as I gain experience, but then I ll need to be careful not to overload on complexity too early in the learning curve. On the down side, this selection is subjective, and probably shall be even in the long term: I include what appealed to me, and will probably miss loads of pointers to information that I have not yet come across. However, I hope this will make it easier for other people to reach the same goal: use git for their version control needs. Have fun.

Hej! Jeg har nu ndret ops tningen i min mailserver, s dan at den p mails sendt med smtp auth skriver en mindre detaljeret Recieved:-header. Kort og godt har jeg fjernet forekomsten af: (scrooge.local) [77.75.167.214] i Recieved:. (Det er navnet p maskinen - og den ip min internetudbyder sender mig ud igennem[1]) Nu stryger al mail lige igennem fpo.mail.dk. Det er lige f r man skulle overveje om postmesteren p fpo.mail.dk havde et defekt anti-spam-setup - noget med at melde tempor r fejl hvis en ip i en Recieved-headers var fundet p en blackliste. Umiddelbart lyder det i hvert fald defekt i mine rer. Hvis du kender postmesteren p fpo.mail.dk, s prik lige venligst til ham og bed ham fikse sit setup. Til de exim-interesserede har jeg brugt f lgende konfigurationselement i main-delen:

received_header_text = "Received: \
$ if !def:sender_host_authenticated $ if def:sender_rcvhost from $sender_rcvhost\n\t \
$ if def:sender_ident from $sender_ident \
$ if def:sender_helo_name (helo=$sender_helo_name)\n\t \
by $primary_hostname \
$ if def:received_protocol with $received_protocol \
$ if def:tls_cipher ($tls_cipher)\n\t \
(Exim $version_number)\n\t\
id $message_id\
$ if def:received_for \n\tfor $received_for "
[1] Jeg bor p kollegie og deler offentlig ip med 287 andre mennesker. Det g r at den ip-adresse altid er p mindst en eller to blacklister. At v re p blacklister er ogs sj ldent en midlertidig tilstand.

Hmm, looks like my wordpress installation got pwned and inserted spam into my posts. That’ll teach me to keep my install up to date. My apologies to anyone affected.

Recently I took stock of my Javascript programming efforts, with the intention of simplifying things. To date I've put together three sites which make use of Javascript:

debian-administration.org

There isn't very much javascript in use upon this site, and you might be forgiven for thinking there was none at all if you don't have an account, or don't login. There's a tagging system which is starting to creak under the sheer number of different tags, and several back-end parts of the site make use of AJAX calls. Most of the script lives in a single file common.js which I cobbled via a process of trial and error, augmented with a little copy & paste coding. It works. But I knew I could do better ..

ctrl-alt-date

This was my first attempt to make a site be truely dynamic and "pretty". It has succeeded in that respect, although the lack of members makes the site itself essentially a failure. This time round I decided that I'd utterly refuse to write my own Javascript. So instead I used script.aculo.us (damn I hate those ugly URLS). This library made it almost too easy to add flash. I liked it a lot. Having said that though the sheer scope of the library and the way it didn't fit in the way that I coded made it painful to use at times. It works, and it works well. Like it? Yes. Love it no?

mail-scanning.com

This site has a fair amount of javascript upon it, but that isn't obvious unless you're actually a user. The only piece that I can recall is the real-time count of spam caught upon the front-page. (Realtime stats are cool!) Most of the code here is the simple kind, reverting back to the way I worked on the Debian Administration site; we're talking about basic effects such as:

• show/hide a div
• make an AJAX request every now and again.
• Do a bit of auto-completion.

To get more of a feel for whats out there I wrote this initially with my own code, then later migrated it to jQuery. Quite frankly jQuery rocks. The way it works is a little strange at first, but it is so natural after a while. As an example:

// find the div called "foo" - hide it.
$("#foo").hide()

I'm liking this library a lot recently, but only time will tell if I use it more.

In conclusion I filed #473125: ITP jQuery failing to see the existing ITP already present. Once the package makes it through the NEW queue I will update it to follow the skeletal javascript-policy. I disagree about the naming scheme suggested by that policy primarily because we already have packages of several of the "big" javascript libraries, such as scriptalicious, and see no gain in renaming them. But otherwise the policy is sane enough; following it will cause no harm at the very least. ObQuote: Stand By Me

After 2005, 2006 and 2007, I did it again. Here are my yearly stats about Jabber clients! 1244 users were online on the Apinc Jabber server when I ran the poll, and 1163 clients answered. Telepathy doesn’t seem to answer to jabber:iq:version, and it seems that a bug prevents Gajim from answering in some obscure cases (even when the “send info about OS” option is enabled). Systems:

• GNU/Linux 40%
• Unknown 36% (Pidgin doesn’t report the OS)
• Windows 17%
• MacOS 5%
• Others 0% (4 clients)

Clients:

• Pidgin 27% (2007: gaim: 22%)
• Gajim 20% (2007: 22%)
• Psi 16% (2007: 24%)
• Kopete 14% (2007: 11%)
• libpurple (Adium) 6% (2007: 5%)
• iChat 4% (2007: 9%)
• Other clients with 2% or less: gajim, BitlBee, Miranda, Pandion, neos, pidgin (with ‘p’ instead of ‘P’), Trillian, Exodus, Coccinella, JabberLib, Tkabber, Gossip, Digsby Client, sim, Finch, JAJC, Bluejabb, Spark.