Description: SMTP command-line test tool
 swaks (Swiss Army Knife SMTP) is a command-line tool written in Perl
 for testing SMTP setups; it supports STARTTLS and SMTP AUTH (PLAIN,
 LOGIN, CRAM-MD5, SPA, and DIGEST-MD5). swaks allows to stop the SMTP
 dialog at any stage, e.g to check RCPT TO: without actually sending a
 mail.
 .
 If you are spending too much time iterating “telnet foo.example 25”
 swaks is for you.

A very important tool which makes debugging e-mail a breeze. A must for every mail admin.

I got some feedback for the script which tries to find conflicting packages I hacked together after the Chemnitzer Linux-Tage. Seems to be a useful tool, so it might be nice to add it to devscripts? Some criticized, that it won't work perfectly, since I only check against files mentioned in Contents-.gz where files / folder created in a maintainer scripts are not listed. I know that, but I don't know a useful way to solve the problem. It's better than nothing, and maybe I'll find later a way to add support for installation time created files. Thanks to Kevin Mark and Marc Bockschmidt who pointed me to some improvements for the script, which reduced the time the script takes dramatically! While my first hack needed for a simple package nearly 15 minutes, the new one is down to one or two minutes. Thanks! So please test it a bit; feedback is alway welcome. You can find the latest version at http://www.schmehl.info/tmp/conflicts". Special thanks to Alexander Wirt and Thomas Viehmann who did proof of concept rewrites in perl and python. Alexanders perl version is quite fast... but needs a huge amount of memory. Thomas' python version is very elegant! You don't need to understand python to understand his script. Nice done, but could need some further improvements; since it takes as much time nearly as my bash script. And since I hope it might be interesting for devscripts maintainer, and I'm not sure if they would like to add a dependency on python, I think my bash script has - for now - the lead :)) The script could still need some improvements. For example tweaking the code a bit; I'm sure many of the things I do with pipes from awk to another awk to sort (or something like that) can be cone my awk itself. I Just don't kno how. And instead of fetching the Contents-.gz from the main server, the script could tread it from the users prefered mirror... and maybe even support for other downloaders than wget.

The Chemnitzer Linux-Tage are over and I'm back home. Again it was an outstanding event. Starting from the overall organisation to the social event (and their quiz) to the catering... I'm still stuffed with the buffet of the social event :) The first thing in the morning I did a workshop about Debian package building. It was very well visited; only two seats were left empty. The visitors were very good; understood most very fast and corrected me a couple of times, when I did copy'n paste mistakes. It was fun to do that, and I got good feedback. BTW: If you need a small example to show someone how to create a Debian package, you might want to take a look an gnujump. The templates created by dh_make work nearly out of the box (so you can concentrate on explaining what is done, instead of fixing stuff to get it working), while the resulting package has still place for improvements (.menu and .desktop files; splitting the package into a arch dependent and an arch independent; etc.) And most important: It is compiles quite fast, while you still have something to show, so your visitors will see, that you indeed did something. Talking about the feedback I got after the workshop: One guy asked me about a way to check for conflicting packages, and we all wondered, that there's nothing scripted available, yet. So I promised to hack something together to at least check for conflicting files. The result is available at conflict finder (and later an svn.schmehl.info, as soon as I find out how to setup webdav/svn to allow read access to some repositories and not others). To check for packages your package should conflict with, you need to first build your package (or we won't know which files are in your package) and give the path to the resulting .deb as the first parameter to the script. If you have a Contents-foo.gz file somewhere on your hard disc, you can specify the path to that file as the second parameter (if you use apt-file or have a local mirror, it'll try to find it; if everything fails the script will try to download one). Then the script will check for each file of your Debian-Package if there is any other package having the same file. Sounds cool, but is damn slow; the repeated zgrep over the Contents-File is quite time consuming. For a quite small package (xdialog) it took nearly 15 minutes to complete. Wow, when I hacked it together, I wouldn't have thought it would be that slow. As far as I know Alexander Wirt is already working on an improved version using some kind of database (and perl).

I was thinking about mentors.debian.net and how much it's useful and unknown for many DDs and potential contributors. I don't think our GForge installation (http://alioth.debian.org) reached its full potential (in terms of audience) but is more known than mentors.

I like the mentors documentation on how a non-DD can upload packages to their repository, and almost everything else there except for the need to create yet another account in a website. I would be glad to see the code move to nm.d.o/mentors, but being less hungry why not some integration with Alioth?

I think that if we add OpenID support into GForge and push that to Alioth, services like mentors will benefit instantly any Debian contributor (DD or not) using svn.d.o, for example. I have no knowledge on GForge internals, but feedback from a GForge hacker if this feature is planned or if this contribution would be welcome will be appreciated. That would be great hear the opinions from alioth and mentors admins.

In other words: I want my Alioth OpenID and i'm sure you can think about new interesting use cases (eg.: forums, debian-community anyone?).

Yesterday I stumbled over an interesting article and I thought hey, it would be nice to save it for some time later . Then I thouht just saving is not enough, because I want to know where I found it . But manually writing the URL somewhere as well feels ugly. Therefore I am looking for some kind of document archival tool. Here is how it might work, givinen a command line interface and the invented name nodoc :

$ nodoc get http://labs.google.com/papers/disk_failures.pdf
$ nodoc list
disk_failures.pdf
old_files_on_disks.pdf
$ nodoc info disk
ambiguous file name  disk 
$ nodoc info failures
disk_failures.pdf
    URL: http://labs.google.com/papers/disk_failures.pdf
    Date: Sat, 03 Mar 2007 17:46:03 +0100
    LastUpdate: Sat, 03 Mar 2007 17:46:03 +0100
    Title: Failure Trends in a Large Disk Drive Population
$ nodoc tags failu + google disk statistics
$ nodoc list
disk_failures.pdf       google,disk,statistics
old_files_on_disks.pdf
$ nodoc update
disk_failures.pdf: File up to date
old_files_on_disks.pdf: New version available.... done downloading.
$ nodoc search happyness
happyness not found (full text search in 2 documents)

I think you get the idea. Note that I expect it to read the meta-data from PDF files (which the mentionend article does not contain, but it s just an example). Does anyone know of a simple linux program, text-based or graphical, that does that? I am considering to write it myself, but I don t want to re-invent the wheel.

Shell scripts are good for a lot of things. It's quick and easy to design shell scripts that take input from one program, pass it to another program, munge it for filenames, etc.

But there are a few drawbacks to shell scripts.

The #1 drawback, in my opinion, is that it is extremely difficult to get quoting and escaping right. I often see things like $@ in shell scripts (breaks if a parameter has a space in it). I also see people failing to check for errors properly (set -e helps that). It's also difficult to do a more modern style of exception handling (do a sequence of actions in a temporary directory, and always remove that directory, even if there's an error, but stop processing and propogate the error). Command-line parsing is esoteric and odd, even with getopt. That's not to say that it's impossible to make a secure shell script that handles filenames with spaces in them properly. Just that it's difficult, and makes using common operators like backticks difficult.

Awhile back, I toyed with the idea of making Haskell a shell scripting language. This week, I spent some time to make this a reality. I released HSH, a shell scripting environment for Haskell.

HSH makes it easy to run shell commands, set up pipelines, etc. straight from Haskell. You can either use simple strings to invoke commands (they'll be passed to sh -c), or you can specify arguments as a list (like exec...() takes), which eliminates the strange filename problems.

But the really cool thing is that HSH doesn't just let you pipe from one external program to another. It also lets you pipe to/from pure Haskell functions. Yes, you can pipe the output of ls -l straight into a Haskell version of grep. I've found it to be very nice, especially for more complex processing tasks.

I put these simple examples on the HSH homepage:

run $ "echo /etc/pass*" :: IO String
 -> "/etc/passwd /etc/passwd-"
runIO $ "ls -l" - - "wc -l" 
 -> 12
runIO $ "ls -l" - - wcL
 -> 12

In this example, wcL is a pure-Haskell line-counting function.

The results were surprising. According to SLOCCount, porting hg-buildpackage from a shell script to a HSH script achieved a 20% reduction in source lines of code. And at the same time, gained better error handling, better safety of filenames, better type safety (compile-time type checking), etc. Yet it does exactly the same thing in almost exactly the same way.

Even greater savings will occur too. I decided to reimplement a small part of sed just for fun, and that code is still in my tree. If I removed that and replaced it with a call to sed as in the shell version, that would probably buy another 5% savings.

I didn't really expect to achieve a reduction in lines of code. I thought that I'd be lucky to come close to breaking even. After all, who'd expect something other than the shell to be better at shell scripting?

I don't know if these results are generalizable, but I'm really excited about it.

[ Yes, entry written for my Mexican fellows. My blog is in English. Don't rant about that, your pleads won't be listened ]
Damog just ranted (in Spanish) about too many people coming to Mexico City. I completely agree with him, but not with his conclusions. We are a ~25,000,000 people city, in a ~100,000,000 people country. The inequity we face every day is huge (Cd. Nezahualc yotl, among the poorest in the city, is the most densely populated region in the whole world, but you can easily spot over 2000 sq mt houses in Bosques de las Lomas or similar regions - And the whole Santa F region just scares me, it is an unknown planet I don't even want to think of). But what's really terrible is how living in this city changes our collective moods.
Sometimes it strikes me to understand how people in other countries can live in one town and work in another, over 40 minutes away. Well, for many years I worked at places over one hour away from home - and I didn't even cross the city. Mexico City is, or was last time I checked, 40x70km, and without enough adequate main ways. Of course, people get grumpy and aggressive while driving.
What's my answer?
Don't drive.
Seriously.
Yesterday, for example, I chaired three talks at Linuxworld Mexico. In friggin' Hip dromo de las Am ricas, a convention center located in one of the worst-connected pieces of land in Mexico. Usually, it would take me 40-90 minutes to get there by car, depending on the time of day and phase of Deimos against Fobos. Of course, it took me 70 minutes to go by metro+bus. I took two nice books (La regi n m s transparente, a beautiful book by Carlos Fuentes no Mexico City inhabitant should skip, and Laurence Rosen's Open Source Licensing). And I didn't get bored, and I didn't hate the people I was riding with. Even though I crossed the most crowded metro stations. Not only I saved a fair amount of money (MX$6.50 each way against probably something close to MX$120 between the gas and the parking fee of that unholy convention center), but I used my time much better. Some years ago, when I regularly travelled one hour back and forth to work, I learnt most of what I know today of Computer Science during the long time I spent sitting on small microb s seats. Not the most luxurious way of travelling, but still a very good way of moving around our messy city.
Of course, today I have learnt even more, and I want to advocate it: don't work far from your house, or at least, don't work far from a place reachable by Metro. Sometimes it sounds impossible, but really... How much do you value your time? Do you think that it's better to get MX$20,000 a month in a Santa F office than to get MX$15,000 in an office in Insurgentes? Do you think nobody will pay you decently if the offices are in Ermita Iztapalapa? Good work done brings a good salary. And seriously, the extra MX$5,000 in my first example is not worth the daily anger you will get by crossing the city to get to Nowhere Land and work for the corporate overlords.
I might be extremely lucky, but I work 3Km away from home. I come by bike every day. And yes, I was scared at first - Even in Ciudad Universitaria people drive aggressively. You have to take care where you drive. Taxi drivers are among the worst, as they are always in a hurry. And, yes, my elbow has an ugly scratch, as I prefered to stop and fall off my bike than to land over a car whose driver was in a hurry. I've just had my bike for ~6 weeks (after over 10 years of not riding one, and back then, just for a bit), but I'm confident enough to get off the safety of a protected University with no cafres driving their microb s as they damn well please. Last weekend I had a ~6km drive (Copilco-Miguel ngel de Quevedo-Loreto-Alta Vista-Copilco) using several high transit vialities (Universidad, Revoluci n, Insurgentes). I crossed three times the San ngel bus hub, which scared my ass as I approached - But it's perfectly doable, far easier than what I expected. It was fun. It is a decent excercise. And we need more people to take the streets with their bikes.
This morning I heard on the radio that Marcelo Ebrard (Mexico City mayor) is pushing a plan to boost bycicle usage in the city. Something similar to what has been done inside Ciudad Univeritaria, but -of course- in a larger scale: Useful ciclov as along the main roads, city-owned bike rental places (where you can rent your bike at one and drop it at another spot), all this well connected to the main Metro stations. In this interview (in this morning's 98.5 FM news program - sorry, I don't know who heads it... Mart n something IIRC) they said that today, ~0.7% of the trips outside home in Distrito Federal (where only 8 out of our 25 million people live) are carried out on bycicle, and they expect to raise it to 5% over the next six years. We will see about that, I can only wish this program best luck.
Damog complains that we drive like shit because dealing with too many people for too long pisses us off - Ok, Damog, here is the recipe: Don't get pissed off. Each of us will make a minor but tangible contribution. Don't drive so much. Quit your job so far away, get a decent (even worse paid) job closer to your house, closer to the university. You will be happier. Get a bike. Use it, you live close to UNAM as well. You will be happier. And we will be one step closer to total world domination. (yes, we the bikers, not we the Debianers ;-) )

Recently, I got a comment on an older blog post on Edmonton that basically agreed with another comment that Edmonton was so not the cat’s meow. Despite the winter and many months later, I guess I still do think it is, although in saying so, it is not I think their assessments are wrong, I think my take has as much to do as what has come before (like NJ, which was not the high point o my life), my experiences here, and what is to come in the future. I tend to like Edmonton because there is enough stuff to do but not too much to do. It is that whole freedom from choice that I like because I often shut down in the face of too much choice. What also colors my experience in a positive light is that generally, Canadian politics, social policy, and way of life, are a step up or two (or maybe three) than that of the United States. So the worst of Canada (if you are even to call Edmonton that, which I would not), in this regard, beats out the best of the United States. And I have lived most of my life in the US so that is my point of comparison. Even if you are living in a fantastic American city, you always face the possibility of struggling in ways that will *never* happen in Canada. It makes for a calmer, less aggressive society. For example, I recently learned that Edmonton has the highest murder rate in Canada, at a whopping …. 36 people per year (population of Edmonton = 1 million). I grew up in a place, Puerto Rico where the yearly murder rate hovers at about 700-800 per year (population = 4 million). And yet people here are freaking out over the high rate of murder, which is a good thing because hopefully they can bring it down but this fact should make the US pause and think about what they are doing up north to keep the murder rate so darn low (and the answer I think is pretty easy to find). But perhaps a lot of my love of the place has as much to do or more with my state of mind. After a grueling year of finishing a dissertation under pressure as I had deadline, and then living in NJ where I was on the job market (which meant spending so much time churning out application after application and then flying around interviews), in addition to flying 7 times in one year to visit my mom, my life here just feels so much more sane than it has been in years. What sealed it all was that right before I moved here in August I was lucky enough to be offered a permanent job (which means this summer I will be moving to NYC to join this department and I will be back to the land of overwhelming choice), so that for the first time in 5 years I did not have to apply for anything in the fall that would guarantee my livelihood for the next academic year. I was not faced with a year of lots of travel (and actually traveling in out out Edmonton is really one of my least favorite things). With that firmly in place, I could just concentrate on things like my work, my friends, brewing kombucha and do things routinely, like exercise, which I had not consistently done for years. There are things about Edmonton that I find totally obnoxious like the cities inability to plow roads leaving a thick glaze of black ice on the roads so that when you drive in the city, you basically are at real risk for an accident (and this is despite a 6.6 BILLION government surplus). There are a tad too many strip malls in the outlaying areas, and of course there is the infamous winter. We are still deep in it. The cold temperatures have been with us steadily for months now and according to folks, there are still two more months to look forward to. The cold and the constant layering of clothes are getting to me a little, although I do appreciate that the cold is just not as cold as one would think with the actual temperatures. The lack of wind, the dry conditions, the cute as chubby-as-anything- bunnies that run through the snow, and the overpowering sun all help to make -6 F much more mild, so it is not as bad as you would or I would think it was. So while I am thrilled to join the department where I am moving too, I will be sad when I leave, though perhaps not as sad as Edmontons “darling” hockey player, Ryan Smith, who was just traded by the Oilers to the NY Islanders. The day he left, he literally was shedding tears at the airport. And I have to say, even though I have no attachment to hockey, I found the pictures endearing because there is nothing like seeing a grown Canadian man cry over hockey! : )

The famous Wikipedia online encyclopedia starts to suck. Well at least the German, haven't looked at other languages.
First they (ok in particular one wikipedia guy) wanted to delete the article about my favourite live cd grml (crux linux for example is deleted).

Ok could be just an action of some random idiot. But then I read an article in Tim Pritlove's weblog that they also deleted an article about Julia Seelinger a young politician of the green party in Berlin because of their so-called "relevance criterias".

And there are many other discussions about deleting articles, for example here.

WTF has happened to wikipedia? Is there any valid argument to delete an article apart from the argument that the content itself is totally wrong?
Isn't disk storage cheap enough today to keep these articles?
Wasn't one of the goals of wikipedia to catch up all the human knowledge?

Really, I can't understand this bureaucracy currently happening in wikipedia but if some random fools start to delete articles with these arguments I
wouldn't wonder if people stop writing and editing articles for the Wikipedia. It also sad for the people who put their efforts into wikipedia and wrote the articles.

Just sad.

I just uploaded a minor update of Pyroman to unstable and the pyroman download page on alioth. I added support for a complete interface wildcard, and added example configuration files for a single-host setup. Pyroman is a firewall configuration tool I wrote for managing the firewall of a small network consisting of four zones and servers with a dozen different tasks. It plays very well in setups with DMZ, wireless networks, intranet etc. and all kinds of different services. Key benefits are the very simple syntax, safeguards (extensive syntax checks, rollback on failure, safety timeout option for remote administration), scriptability in python and high performance, since it does not run dozens of iptables commands, but generates a script file for iptables-restore. For more benefits, see the pyroman homepage. The next version will probably feature an XML syntax additionally; while the current Python syntax is very powerful and readable, it's pretty much impossible to write a GUI for editing the policy when written this way. That's why I'd like to add an XML syntax (that can be intermixed with Python statements, but only the XML-defined parts will be editable in the GUI) that supports the key parts of configuration (if you want the rules to be generated on the fly from some database or whatever, you'll still be able to do that in Python!): making it easier to write a GUI for it.

Why you won't be voting for me for DPL this year. Or, my plans for Debian stuff over the next year (or three). Most of these plans embody larger themes and directions that I feel Debian should take. I am a strong beliver that working code and getting stuff done is the best way to work toward larger goals, so I won't bother to try to explain the larger goals. constantly usable testing This is so important that it has its own page. This is my first public posting of that proposal, and it should not be considered finished. I plan to finish it, and get to work on it. website www.debian.org is deprecated, but this is not obvious to either users or developers. That's because it's not formally deprecated, we just treat it like it is: We don't use it for anything new. Instead we have wikis, planet, times.debian.net, etc, etc, etc, etc. Unfortunatly that has created a bit of a mess for users, who are still often stuck trying to use www.debian.org, or who can't find new stuff that is on other sites. A solution could be creating an alternate starting point for users, to help them learn about Debian, install it, and point them to docs and all the other useful sites once they're more involved and using Debian. I hope to find time to work on and promote such a thing. I plan to continue moving stuff that needs to be maintained actively and grow off of www.debian.org to the wiki (as I've done with some of d-i stuff, for example), and encourage others to do so as well. Anything under /devel/ on www.debian.org is an especially good candidate for the wiki. double the archive sync frequency again Now that we've switched to updating the archive twice a day, and dealt with the (minor) issues caused by it, it should be easier to increase it to a frequency that is more likely to cause noticible turnaround time improvements and thus speed up some development. As it is, many people sleep through one or the other archive update. So I support doubling it to four times a day, or more (six seems better). automated whole system testing Automated whole system testing is important because Debian needs to keep working in so many obscure and annoying to test situations. Does d-i work on m68k? Does the desktop task install properly and work? Does debootstrap install a usable system on every architecture? If we rely on user reports, things can fall through the cracks entirely or not be noticed for too long. I've been running a d-i lab for a few years, which tries to automatically test installs on 6 architectures. However, between the current kernel not supporting several of my test machines due to hardware and software bugs, and the general time sync of keeping a rack of aging and obscure test boxes working, this has not been very useful lately. I feel that the solution is emulation: It should be possible to run Debian under emulation for most architectures. I hope to get an absurdly powerful server donated, and switch my test lab over to running in emulation on it. developer (virtual) machines The other benefit of emulation is that everything needed for testing stuff under emulation can be easily distributed to others. Getting developer accessible machines for certian architectures has been a problem in Debian. Emulated systems can sidestep this problem. All that's needed is a collection of documents and/or bootable images that developers can use to set up virtual machines for as many architectures as possible. We have steps in this direction. Hercules contains documentation for how to install in it using d-i. There is a kernel flavor and d-i boot images for mips on qemu. Having to ssh out to a DSA adminned box to deal with a buld failure on $ARCH, and having to wait for build deps to be installed should begin to feel antequated and quaint. It is. find the next nslu2 Debian's support for the nslu2 is an excellent development. It opens up using Debian for a whole new set of tasks, that need low-powered, semi-embedded, commodity hardware, that before were the province of special-purpose embedded distros. It also blew the popcon numbers for arm through the roof. We need to find the next nslu2-like target and get to work on it. I'm hoping that it will be a wireless router, because that's the only thing I'm not running Debian on now. :-) But it could also be a cell phone, or PDA..

Dear Ladies, if you'd like your husband / boyfriend to go shopping with you, get your shop to be at least a bit friendly to him. There is nothing wrong, if you need two hours to buy a new blouse. (Actually, I heard some men need some time for shopping, too, so that doesn't even count as "typical feemale".) There is nothing wrong, when your man has nothing to do... beside trying to find your clothes in an other size... or trying to figure out, if that color is apricot or peach, and if it would look good to something of the color pumpkin. What makes such trips horrible is that boutiques are often overheated (Well, that might be a must; they must not be too cold for a women to take her clothes of), narrow (How many clothes stands can you squeeze into a 10m² shop?) and loud. If you want us to go shopping with you, go to a boutique, where a men can at least have a seat. Possibly with a water cooler nearby. That would make it a lot easier for us. A positive example is Eierund. They have some kind of "men and children area". Children will find comics and can watch movies, and men can read car and computer magazines (or steal the comics from the children). They even have sweet apples and a really comfortable couch. That's how you make your man enjoy going shopping with you! PS: Having a nice girlfriend, who doesn't take that long shopping helps a lot, too.

Via Jamie, an interview with an amazing espresso artist. As I’ve wondered before, it would be interesting to know if anyone has ever attempted to protect their copyright in espresso art. On further reflection, I think espresso art should meet the “fixed in a tangible medium” requirement, at least as much as ice sculptures which also tend to lose their form over time. I assume ice sculptures can be protected, although could not find an example in a quick search. I suspect the copyright office would accept a photograph as “identifying material” for the purposes of a registration deposit on a cup of espresso, as in the case of sculptural works. Be sure to check out the embedded video — it eliminates any concern that the espresso art photographs might have been digitally enhanced.

I'm excited to see that wikiHow now lets people log in with OpenID, and also provides identities to all wikiHow users. (I'm not sure what wikiHow project members are called -- my best guess is "wikiHowards", but I'm pretty sure that's not right.) wikiHow is a great company, and the people I know there -- Jack and Travis -- are personable and smart. I think wikiHow is a great example of a conscientious company participating well in Open Content and the wiki world; I think implementing OpenID is one example of their good wikizenship. One of the things I really wanted with implementing the MediaWiki OpenID extension was that we'd get really portable identity across wikis; that someone who'd established a reputation on Wikipedia could expect some respect for that reputation on Wikevent or Wikioutdoors or whatever. I think there's some danger to that model -- so many wikis today are implemented on wiki farms like Wikia or Pbwiki. I think some wiki farm companies see value in corraling their users into only using wikis on their servers, rather than in participating in the larger wikisphere. (You can occasionally even see this attitude in the Wikimedia community, although obviously that community is more self-governing and evolved about Free Culture and peer-to-peer processes.) That attitude is short-sighted, and wiki hosting companies that insist on maintaining identity silos are probably going to pay for it in the future. It's a competitive market; people have a lot of choice, and nobody wants to be fenced in. If there's been one lesson of Web 2.0, it's that openness is a competitive advantage. Good karma pays off in intense customer loyalty. And, yes, I'll stop using wiki-prefixed neologisms now. Sorry about that. Anyways, I'm really glad to hear that wikiHow is joining the OpenID network. I hope it continues to work well for them. tags: wikihow openid wikisphere wikizenship wikineologism

Rands in Repose I continue to find it mind-boggling that this gay alien is also a well-known blogger about software. Yeah, I know, I know, Jerkcity guys: they're just cartoon characters. They're not people. But still. In ancient times, I did an interview with Rands for Pigdog Journal. I guess that's a long time ago, though. tags: rands jerkcity interview pigdogjournal

Not quite spongeworthy So, there was an article in Slate about Wikipedia biographies over the weekend about how saddy-sad it is when your biography is deleted from Wikipedia (and how writing an article about Wikipedia can save that biography quite well). I've seen a lot of such breast-beating in blogs and such lately. I think it's important for folks to remember that Wikipedia is an encyclopedia, not a wiki-about-everything. Some people, places, and things meet an encyclopedia's requirements for notability (see Wikipedia:Notability (people)); others don't. That's just the way it is. But just because your bio isn't on Wikipedia, doesn't mean you can't have an Open Content, wiki bio preserved for posterity. I've written about WikiBios before, but I have to insist that it's one of the most awe-inspiring projects I've seen: a biography for every human. Every human. That's all they do. Yeah, their sample text is a little bit trivial, but I think looking beyond that, you can see a pretty amazing possibility for a project. Maybe Timothy Noah and all the other people who are teetering on the edge of being spongeworthy for Wikipedia should take some time to build out their WikiBios page. Get friends, colleagues and family to contribute, and really build out a high-quality bio. If at some period in the future WP deigns to include them, then the bio is right there -- GFDL-licensed, no less. Anyways, here's Evan Prodromou's WikiBio. Feel free to fill it out. tags: slate wikipedia timothy noah wikibios

BarCampAustin While I'm thinking about BarCamps -- I'm a little nervous about my presentation at DemoCampMontreal1 -- I'm finding out that BarCampAustin is going to be the same week as South-by-Southwest Interactive 2007. Which, really, makes a lot of sense. I'm going to try to show up for Friday morning -- it'll be interesting to bounce back and forth between SxSW and a BarCamp. tags: sxsw barcamp barcampaustin

Now, more on those network problems I mentioned - it looks like one device on our inbound route is hiccoughing and dropping packets. That royally screwed up a suboptimal OpenVPN and all VoIP traffic. I've changed some settings on the OpenVPN (made the various MTUs fit neatly, for example), but I'm still waiting for a response from the network engineers about the broken device. While I was investigating, I discovered that the router really doesn't tell me much useful information, but it should be able to run OpenWRT - I think I'll try it because being able to sit on the edge of my network and watch the traffic going past would be helpful for debugging things So, has anyone got tips/tricks/warnings about OpenWRT they'd like to share?

A problem everyone stumbles across (at least) once:

% tar zcf stats_2005.tar.gz stats_2005*
zsh: argument list too long: tar

The reason? Too many files for the ARG_MAX limit. ARG_MAX defines the maximum length of arguments to the exec function (more precise: bytes of args plus environment for exec), defined in /usr/include/linux/limits.h on your Linux system:

% ls -la   grep -c stats_2005
9037
% getconf ARG_MAX
131072
% cpp << EOF   tail -1
#include <limits.h>
ARG_MAX
EOF
131072
%

Ok. But how to work around the issue? Possible solution for GNU:

% find . -name 'stats_2005*' > filelist
% tar zcf stats_2005.tar.gz --files-from filelist

Without the temporary file (filelist in our example):

% find . -name 'stats_2005*' -print   tar zcf stats_2005.tar.gz --files-from -

zsh provides zargs (but AFAIK it doesn’t work with gzip in the same command line due to the way zargs works, so create the archive in one step and compress it in another step later):

% autoload zargs
% zargs -- stats_2005* -- tar --ignore-failed-read -rpf stats_2005.tar

The approach works with other tools than tar as well of course, usage example for afio:

find . -name 'stats_2005*' -print   afio -o -Z stats_2005.afio

Depending on the type of problem (rm, cp, mv,…) you can choose differented approaches as well, some further examples:

% for file in stats_2005* ; do rm -f -- "$file" ; done
% perl -e 'unlink <stats_2005*>'
% zsh -c 'zmodload zsh/files && rm -f -- stats_2005*'
% zsh -c 'autoload -U zargs; zargs -r ./stats_2005* -- rm -f'
% ksh93 -c 'command -x rm -f -- stats_2005*'
% find . -maxdepth 1 -name 'stats_2005*' -print0   xargs -r0 rm -f
% find . -name 'stats_2005*' -print0   xargs -0 mv -i --target-dir=/destination
% zmodload zsh/files ; mv -- stats_2005* /destination

I recently came across two old and unrelated writings about law, both of which are worth reading, especially for people with strong opinions but no formal training. The first is this piece, entitled Seven Ways in Which Code Equals Law (And One in Which It Does Not), by recently-appointed New York Law School professor James Grimmelmann and EFF Legal Director Cindy Cohn. Several observations are particularly appropriate for the slashdot crowd (and, to a lesser extent, certain members of the Debian community and others who grew up on a diet of BASIC, Pascal, and then C and later perl). I especially like this bit about “hacking the law”:

Some people, seeing this connection, and remembering the values of good code, try to improve the legal system by treating it as a computer. People come to me with ideas for hacking the law. The government says that cryptography is a weapon, they say, but the Bill of Rights says we have the right to bear arms. So that means we have a Constitutional right to use cryptography. But the legal system isn t a computer. If you can t convince a judge that what you re proposing is consistent with the values underlying a law, your argument will go nowhere. People go to jail every year because they think they ve found a way to hack the Sixteenth Amendment. The income tax is illegal, they say, or, The income tax is voluntary, see, it says so right here, and then they get convicted of tax evasion and sent to jail. We did convince several judges about the Constitutional dimension of cryptography, but the claim started from the values of the First Amendment, not a mechanical reading of its words. It s a category mistake to treat the legal system as just another architecture with its own specialized language. Code and law are different ways of regulating; they have different textures. All of those people who are required to make the legal system work leave their mark on its outcomes: they make a certain amount of drift and discretion almost inevitable. Code doesn t have such a limit: it can make perfectly hard-nosed bright-line rules and hold everyone in the world to them. Code is capable of a kind of regulatory clarity and intensity that law can only state, never really achieve.

I don’t entirely agree with the other article, entitled What I Ate For Breakfast and Other Mysteries of Judicial Decision Making by outspoken Ninth Circuit Judge Alex Kozinski (unofficial site maintained by Aaron Swartz, wikipedia entry). For example, I think critical legal studies has resulted in some interesting insights, some of which actually have practical applciation. Still, Judge Kozinski makes an important point about the numerous factors that act as a check on discretion in judicial decisionmaking:

It is popular in some circles to suppose that judicial decision making can be explained largely by frivolous factors, perhaps for example the relationship between what judges eat and what they decide. Answering questions about such relationships is quite simple - it is like being asked to write a scholarly essay on the snakes of Ireland: There are none. But as far back as I can remember in law school, the notion was advanced with some vigor that judicial decision making is a farce. Under this theory, what judges do is glance at a case and decide who should win - and they do this on the basis of their digestion (or how they slept the night before or some other variety of personal factors). If the judge has a good breakfast and a good night’s sleep, he might feel lenient and jolly, and sympathize with the downtrodden. If he had indigestion or a bad night’s sleep, he might be a grouch and take it out on the litigants. Of course, even judges can’t make both sides lose; I know, I’ve tried. So a grouchy mood, the theory went, is likely to cause the judge to take it out on the litigant he least identifies with, usually the guy who got run over by the railroad or is being foreclosed on by the bank. This theory immodestly called itself Legal Realism. Just to prove that even the silliest idea can be pursued to its illogical conclusion, Legal Realism spawned Critical Legal Studies. As I understand this so-called theory, the notion is that because legal rules don’t mean much anyway, and judges can reach any result they wish by invoking the right incantation, they should engraft their own political philosophy onto the decision-making process and use their power to change the way our society works. So, if you accept that what a judge has for breakfast affects his decisions that day, judges should be encouraged to have a consistent diet so their decisions will consistently favor one set of litigants over the other. I am here to tell you that this is all horse manure. And, like all horse manure, it contains little seeds of truth from which tiny birds can take intellectual nourishment. The little truths are these: Under our law judges do in fact have considerable discretion in certain of their decisions: making findings of fact, interpreting language in the Constitution, statutes and regulations; determining whether officials of the executive branch have abused their discretion; and, fashioning remedies for violations of the law, including fairly sweeping powers to grant injunctive relief. The larger reality, however, is that judges exercise their powers subject to very significant constraints. They simply can’t do anything they well please.

Finally, I will link, but not embed, this video of the Anna Nicole Smith court order, for an entirely different perspective on the legal process. You almost don’t really want to have to see this stuff.

Ever wanted to insert a character in your terminal but don’t have a keybinding for that character? zsh provides a nifty feature called insert-unicode-char:

autoload insert-unicode-char
zle -N insert-unicode-char
bindkey '^Xi' insert-unicode-char

Figure out the character’s code (take a look at unicode.org/charts/ for example) and press ‘ctrl-x i’, followed by the character’s code and press ‘ctrl-x i’ once more. Usage example: ‘ctrl-x i 00A7 ctrl-x i’ will give you an ‘ ’.

We went to Scotland on a family holiday this week (brave or stupid, answers on a postcard). You would not believe the number of puns you can get from the simple town of Ayr. For example, R: “You should have turned right there!” Me: “Oh well. To Ayr is human.” I shall spare you the rest: if your mind isn’t already overflowing with similar appalling jokes, you’re no friend of mine. Whilst in Ayr, I came across a marvellous whisky shop, Robbie’s Drams, and bought a bottle of Laphroaig quarter-cask and another of Smokehead. This article, or what remains of it, is to describe the Laphroaig quarter-cask whisky. Should you wish to avoid the Flash-animated website, here’s a precis. Tales are told of a time when the business of Laphroaig was carried on less than legally and it was useful to carry away smaller casks when the Excise men were coming than the more conventional full-size casks. Over the past few years, they have tried their best to recreate the whisky that would have been drunk as Laphroaig a couple of centuries ago: quarter-sized casks, slightly higher strength and an older filtration model. The effect of the smaller barrels is to increase the surface area to volume ratio substantially, so more flavour will enter the whisky from the barrel. Thus, they bottle it much younger than their standard ten-year-old offering. To smell it, a sweet smell hits the nose — perhaps toffee apple. On the taste, there is an initial earthy sensation followed quickly by a brief flash of kedgeree, leaving the smoky aftertaste of turmeric at the back of the throat. This is a much more subtle whisky than Laphroaig’s ten-year-old: thinner and less oily, and with a much more delicate, though still substantial, peaty hit. Because it’s not chill-filtered, the whisky becomes delightfully cloudy when water is added. I recommend that you try it both with and without additional water: many of the flavours become more muted with water, but a creamy taste comes to the fore. In summary: if you can get your hands on a bottle or two of this, it’s well worth doing so. An excellent whisky. I should also say that even if you’ve disliked other Laphroaigs in the past, give this a shot. It may just be your way into the other delights from the Laphroaig distillery.