Please do not hide the arguments given to the compiler from me.

It's hard to realize something is going wrong if you do not see what is happening. If the argument list is too long, do something against that instead of hiding it.

Make sure you follow policy when packaging software

Debian packages should be compiled with -Wall -g, but more and more do not. Please check you do, but check at the correct place. Do not look into the debian/rules file, but in the build log. If the Makefile sets a default with a single equal sign ("="), running 'CFLAGS="-Wall -g -O2" make' will not suffice. Try 'make CFLAGS="-Wall -g -O2"' instead. (Actually, there is no good reason to put them before the command. Always try to put things as arguments first, both with make or with ./configure)

It really makes everyone's live easier if those options are set.

Keep the argument list tidy.

Many argument lists are longer than necessary. If there is some -I/ in the argument list on a Debian system, there is something fishy. (It's not the universial collection of different stuff all going whereever it wants, after all). Common cases are:

- buggy scripts to add -I/usr/include

Better fix those scripts. Also make sure they do not cause other problems, like linking your program against libraries your program does not use directly. (Possibly causing funny segfaults when those libs link against other versions of those libraries)

- -I/usr/X11R6/include

For upstream packages this might perhaps be useful to support older operating systems and people unable to give it to CFLAGS themselves. But for FHS systems, this is not needed at all, as it mandates this handy /usr/include/X11 -> /usr/X11R6/include/X11 symlink. And newer X directly puts the headers in the correct place.

- packages working around upstreams breaking compatibility

Life would be too easy if upstream would not break APIs. But if they make a new incompatible version, and even change the library name for that, would it have been that difficult to also change what programs written/ported for that new incompatible API have to place in their #include line?

- plainly broken upstreams

putting stuff in $ PREFIX /include/subdir/ and #include'ing other files from that subdirectory without the subdir deserves application of some large LART.

- oversight

often it is just not necessary, and everything gets much more readable and easier if left away.

Other things makeing things unreadable are large armounts of -Ds generated by ./configure. AM_CONFIG_HEADER can help here a lot with non-path stuff. Stuff containing paths is suprisingly often not used at all.

I just read a story on The Register entitled Oklahoma city threatens to call FBI over "renegade" Linux maker. Quite hilarious. Apparently Jerry Taylor, city manager for Tuttle, Oklahoma, noticed that the city's webpage wasn't working right. He got the default "test page" for the Apache webserver on CentOS. Instead of calling the hosting company, he sent a series of vicious emails to CentOS, even threatening to call the FBI. The CentOS folks really went out of their way to help this guy -- he was not even their customer. And he repaid them by saying they should have helped him sooner. Of course, there was the obligatory comment about being computer literate: "I am computer literate! I have 22 years in computer systems engineering and operation. Now, can you tell me how to remove 'your software' that you acknowledge you provided free of charge? I consider this 'hacking.'" The Register story is hilarious, and the original discussion even more so because it includes a full transcript of the event. Favorite quote (to the city manager):

If you will not let me help you, or at least talk to someone who knows what Linux is, then you will look like an idiot. Your choice.

Should anyone wish to write to the city manager of Tuttle, OK, to complain about his outrageous behavior, his e-mail address is citymgr@cityoftuttle.org. Assuming they have figured out how to properly configure e-mail. He's probably not worth his $63k salary and with a personality like this almost certainly isn't giving his employees the "feeling that we're 'working together'" (see that link). Sigh. Why do people hire a guy like this in the first place?

I think it is safe for me to mention this now. I will soon be starting to work for the Debian-friendly hosting company Bytemark, working with their Xen + UML systems & etc. Fun stuff.

Our @debian.org addresses are just too polluted. It's a fact, and nobody moves. It's really tiredsome. I happen to also be a co-admin on a mail server, that accepts almost 300k per MX, which is not very big, but quite big enough. I've written a little tool called whitelister. It's used in conjunction with postgrey that we use as a POLICY daemon for postfix. Basicaly, what it does is quite simple:

• it checks a lot of RBL (also possibly SPF, but my experience is that it's a very bad idea), and if the mail is clean for every R(H)BL it is configured to check, then it accepts the mail,
• else postgrey takes the relay, and do its greylist thing.

This approach has spectacular results: Edit: the same statistics on our backup/secondary MX The green area are the mails we accept for delivery (after the AV-checks and classicale anti-UCE-checks). The red line is the amount of messages that the bayesian antispam (bogofilter) marks as spam. Since our clever greylisting is up, the results are just unbelievable: we drop a huge amount of spam, without needing bayesian spamfilter or clamav or any CPU-intensive checks, so almost for free. The statistics we run show that a very few mails are actually submitted again (less than 20 per week), and most of them are spam anyway. And an analysis of the remaining spams shows that those are spam that come from redirections services (mail lists, @debian.org, ). We almost drop 99% of the spam that is submitted into the SMTP network through one of our MX's. For the record, we only use cbl.abuseat.org, dul.dnsbl.sorbs.net and dynablock.njabl.org. why doing it that way ? greylisting is all about creating a dynamic map of the SMTP queues of the planet. What I do, is only using RBL's that already exists to make that principle converge faster. Moreover, even if you use "bad" blacklists that have too many false positives, the greylist is here to let legitimates mails through. So basicaly, it combines two bad^[1] methods, to make a good one:

• RBL's already exists, and allow us to avoid the delays that greylist implies for most of the legitimate mail sources (and if a SMTP forwards spam, greylist won't save us, it's a SMTP, it will submit it again, so avoid to greylist it in the first place);
• the greylist saves the few errors the RBL can let you make, with a relatively small penality.

It's a win-win use. Conclusion I'd really like to see such a system be installed on our main MX's. @debian.org emails addresses are overloaded with spam (and 90% of the spam I receive, comes from my @debian address). btw, in a MTA like exim (that some of our MX use), a tool like whitelister is not needed. It's possible to achieve the same thing within the exim configuration files (but don't ask me how, I never used exim, I just know it's possible to do it). Is there anybody out there to support such an idea ?

Living with mricon I get exposed to the way the other half lives. One thing I've noticed is that the RPM tools automatically build extra -debuginfo packages that contain the debugging symbols for the binaries in the package, which gdb can use. I thought too myself "That's cool, why doesn't Debian do that?" Of course, after some research it's actually very easy to accomplish the same thing in a DEB. First step is just to add a dbg package to your debian/control file like so:

Package: giblib1-dbg
Architecture: any
Section: libdevel
Priority: extra
Depends: giblib1 (= $ Source-Version )
Description: debugging symbols for giblib1
 giblib is a library of handy stuff. Contains an imlib2 wrapper to avoid the
 context stuff, doubly-linked lists and font styles.
 .
 This package contains the debugging symbols for giblib1.

Then change your call to dh_strip in your debian/rules files so it looks like this:

dh_strip --dbg-package=giblib1-dbg

If you use cdbs then just add the line:

DEB_DH_STRIP_ARGS := --dbg-package=giblib1-dbg

These cause dh_strip to place the debugging symbols under /usr/lib/debug in the named package. Make sure you have debhelper compatibility level set to 5, as the semantics for the --dbg-package switch in 4 and earlier were different and weird. So add a -dbg package to your library or binary today!

Do you remember the good old days, before everything got "service oriented"? It used to be that people were hired for dealing with the customers' wishes, and that is what they got paid for. Nowadays, those people are paid for being friendly, and while I admit that friendliness is important, sometimes I'd prefer a disgruntled Bavarian getting a document from a file for me while bemoaning the fact that he just had to get up from his chair, over the young, friendly girl who smiles at me and tells me that she cannot help me because that document I asked for only exists in paper form and cannot be retrieved from the computer system. I was aware of that, otherwise I'd sent an email asking for it in electronic form, and more precisely, I know that it is a paper in a file with my name on it because I had it put there seven years ago.

Per Isaac Jones’s request, here it is: Planet Haskell. (The current URI is hopefully not the final one, but this one will redirect to the new one once we have one.) Haskellers: please email me your blog feed URIs (English only, please; no need to restrict to Haskell only, though). I will not add you if you don’t.

Looks like I will be celebrating my 30th in Spain. I arrive in Madrid on my b-day. Oddly the only presents I want are also only apparently only available for shipping to Europe, so that works out pretty well, in theory: This is a pretty good kite design, my only other one in this design is fanny pack sized and works pretty well. If you ever wondered how to make my happy with just 2 euros, this is how. Er, that was my idea, so it's only fair..

My personal hero of the day is Gustavo Franco, for this email to debian-devel. He writes how to get your Gnome/Pango/Glib applications that don't work since yesterday's upgrade like evolution (#358071) working again:

$ G_SLICE=always-malloc evolution

And you should be able to read your email again.

Via Guilded Lilies (Grown Women Playing Games):

One of the things I find interesting in the development of computer games is the selective application of the increased realism that has been made possible by improvements in game engine technology. [...] What I find to be ironic is that there has been an industry-wide movement toward more realism through the function of, for example, physics AI in computer game design, without there necessarily being a concurrent application of that ideal to the creation of certain female body parts. This point has generated the response that games are not about realism, but rather fantasy, and thus do not have an obligation to represent women realistically

I've decided to take a look at emacs-muse (muse-el Debian package).I share many of JoeyH's sentiments with regards to what wiki should have.But maybe that's only an evidence that I'm an old-type.One thing I liked about emacs-wiki (which is what emacs-muse is a fork of)is that it allowed editing of wiki files from emacs, or whatever plain text editor,and allowed viewing of HTML after processing. They are just plain text, and can be controlled with version controlled systems.There was this nifty thing called elserv-wiki, which made emacs a webserver, and allowed wiki editing, but apparently, it's not available for museyet, and thus I can't make it a fully-fledged wiki engine.I'm slowly exploring the space.Apparently, emacs-muse doesn't really work right now for Japanese PDF generation, somebody needs to hack on it. HTML output works, so no problem right now.RSS output seems to be unavailable, along with handling of ChangeLog which used to exist in emacs-wiki.Anyway, I converted tokyodebian project webpage to emacs-muse, rather than hand-crafted HTML, and I'm happy.

Blog Power? Over the past few months I’ve written entries here which have elicited some interesting replies. I ranted about poor support from SuSE and received personal emails from company representatives who wanted to help me out. Last week I wrote about LinuxGazette disappearing (turned out to be DNS errors on my side) and received a comment from Heather suggesting I was mistaken. Interesting that so many people see what I write, and also slightly intimidating given that my sense of humour has repeatedly been misintepretted in the past .. online and offline. I don’t really have a good conclusion here, but I suspect I just got lucky. I tend to write fairly trivial things, and rarely take any of it very serious. ObDebian: I’m in the middle of turning a spare bedroom into a real office. I now have three low-end machines in a line across two desks, and a decentish desktop machine too. It looks likely that I’ll have a lot more time to contribute to Debian over the coming months (although this isn’t confirmed yet). Either way I’ll have a much nicer “working” environment at home. ObSocial: The postcards I sent to Debian folks seemed to all arrive, except for the one I mailed to Amaya (despite having several rounds of back and forth to get the address right). That was returned to me yesterday. Try again tomorrow I guess. Cross-Country postal-services suck. Although I know they handle a lot of letters/parcels I seem to always get the unlucky straw. ObDebian-Admin: The Debian admin site now allows users to submit tags. Took a while to get right, but I’m happy with the Web 2.0 ajax code. How very ..

I would really wish that I could travel around the world and do evangelization about i18n just like Jordi, Daffyd and Michael have been able to do. Of course, this is a known difference between a development model where people are paid to work on development and a completely volunteer development model. However, I really hope that all the good things that will be done to better support Asian languages in Ubuntu will end up in Debian really soon. After all, much of the initial work has been done in Debian itself by the wonderful Japanese/Chinese/Korean developers, or by the "debian-in" project lead by Jaldhar H. Vyas for Indic languages support. Don't take me wrong: I don't have any griefs towards Ubuntu when it comes at i18n. This is an area where the collaboration is already quite good and I hope it will become better if we manage to converge towards common tools (just free up the bloody Rosetta, Mark!). This is one of the goals I personnally set for the i18n session in Extremadura. Our goals here are common: we want more and more pleaces in the world to be able to use the Best Operating System ever and we will paint it red. (another way to say this: "we want the world and we want it NOW") For this, we just have to cooperate.

I'm miraculously on my way back from London, after spending a week with daf, mvo and two guests, abel and thep, from Hong Kong and Thailand, working on improving some l10n aspects of the upcoming Ubuntu release, dapper. The most visible result of the stuff that we've been doing is that if all goes well, users of the Chinese, Japanese, Thai, Bengali, Lao or Korean languages will get their required input methods, fonts and dictionaries Just Working as soon as their drives spit their dapper install CDs. We've learned quite a bit about the state of many of the Asian languages in the Free Software world today. Daf and I can certainly tell when an app renders Bengali or Thai correctly and when it doesn't, after closely comparing how different browsers do the job on various websites and font test pages. We've learned more than we probably like about fontconfig, and thanks to mvo, there is now a mechanism to get custom fonts.conf snippets depending on the default language of the system set by language-selector, so users get the right fonts installed and used by default. Thep's and Abel's help to get this straight is invaluable. On Friday, daf and I went to the ExCel Novotel where the Launchpad team is having a sprint, in order to lend a hand with the dapper translation import that is going on right now, but for a series of reasons we ended up working on l10n sprint stuff. At least I got to see the team again, and specially kiko, who greeted me with a "Qu pasa, hijo de puta!" The real life side of this sprint has been less exciting than on other occasions, as due to being few in number and being quite tired, we haven't gone out of Earl's Court area until today. Still, our exploring around the hotel has yield some nice discoveries. On Sunday, mvo and I were looking for a place to have dinner, and stumbled uppon the Troubadour a place which can either be a pub, a restaurant, a social club or a theatre, depending on your mood. The food was excellent, and the staff was really friendly. I found a Dictionary of Slang in one of the book shelves, and learned a few funny phrases. Other days we've been to good Italian, Indian or Chinese restaurants, but we couldn't resist to go back to Trobadour again. On our last night, Mark took us to a place in the South Kesington area, with again was very good. Abel left just after dinner as his flight was at 5AM from Stansted, and we hope he made it OK to the Netherlands, as at 00:30 or so he phoned us and seemed to be pretty lost somewhere. mvo left early in the morning, so daf, thep and I went to visit some bits of the city. My plane was at 16:45GMT, and we calculated that I should be leaving the K&K at 15:00 to be well on track for my flight. We went to Monument to see the tower, went up and enjoyed both the great views over London and the Thames river, as well as the really cold wind which made me swear once again about the %*@!# lack of Spring in the UK. It was getting quite late for me, so we went to China Town for lunch. Despite the restaurant people being really quick, I only managed to leave the place at 14:50, but given my travel plan was pretty conservative, I was supposed to be safe still. Daf left me at the tube station entrance, and there I started my way too stressful journey back to Val ncia. If on our way to London Carlos and were quite close to find our flight closed, this time, I think I hit the limits. I really don't know how daf and I arrived to the conclusion that leaving Earl's Court at 15:20 was acceptable to get in Heathrow on time. I ran up and down the tube stations, grabbed by luggage, and rushed back to the station, but I had just missed a train to Heathrow and that made me lose some precious 10 minutes. As stations passed by, it became clearer that we had fucked up somewhere when deciding at what time I needed to leave. At 15:35 I was still in the Hammersmith station, with half of the Picadilly line ahead before arriving to the aiport. I sent a message to daf, so he started to get prepared about me staying to sleep somewhere in London. As soon as the train's doors opened, a number of people rushed out. Someone ahead of me fell when climbing the automatic staircase and I somehow managed to jump over him, with luggage and all. After a run that seemed like half an hour, I arrived at the Iberia desk and, panting, I could only articulate "Tarde para Val ncia?". The guy at the counter looked at me, and with a "this can't be true" expression in his face, he picked up a phone and asked "Is it already closed? [...] Can you open it for one more piece of luggage? Thanks." In the meanwhile, I had been busy removing a 500 ml yoghourt from my bag, fearing having all my clothes smelling like strawberry back in Val ncia. The guy handed me a boarding pass, and gave me instructions about the "Iberia Room" near my gate. I asked him what that was about, and he says "oh, of course, you're in Business Class". For a second, I was reminded of stargirl's tricks to get free upgrades when flying, and immediately I was reminded that I was still in a hurry, and I should rush to my gate. And so I did, forgetting to thank the guy for being so kind. I left my yoghourt there though, so at least he could get some food if he was hungry. The long line before the security check was exasperating, and when I finally went past it, I had to run all over terminal two to my gate, where everyone appeared to be waiting just for me. The doors closed as soon as I entered the aircraft, and I sat in the first row, got a free newspaper and a free meal. I couldn't believe my luck. As I write this, we've gone over the Pyrenees, which are not as snowy as a month ago, but they still look beautiful from up here. I'm glad to be back in Val ncia.

As I've had to use Windows on a daily basis, I've found that I am no longer able to maintain my air of detached tolerance for the foibles of the system. In fact, I'm starting to get really infuriated with the utter boneheadedness of so many facets of it. Not so much things that are broken, as things that are done badly, and done so in the face of widespread examples of how to do it right.

Here are two simple examples that are emblematic of what Windows users have to suffer through.

(a) Mandatory file locks.

On Windows, every access to a file, by default, acquires a mandatory lock on it. Want to recompile the program you're working on? Sorry, you have to track down and kill all its running instances. Want to read that file on the network server? Sorry, you'll have to run around the office and ask all the people using it to close it.

Last week I got an email asking me to unlock a directory on our local fileserver so it could be renamed. It turned out that I was running an acroread process to view a PDF file...and that locked the directory from being renamed. Because, of course, the universe would implode if someone were to rename a file I had already loaded into memory. This is, however, better than how shared libraries are treated; trying to register a new version of a shared library with the system (the Windows version of ldconfig) will silently fail if programs have the old version mapped into memory. WTF? No, really, WTF?

Windows users get around this by having tools to find out which processes have a file open so they can terminate them with extreme prejudice. This is considered normal and acceptable behavior for a computer in the Windows universe. After all, in the real world two people can't use the same document at once, so why should they be able to do so on a computer?

(b) C# events.

They've been invented many times. Signals, events, hooks, whatever you want to call them, they're collections of function objects that are invoked when some particular condition occurs. It's a great way to make it easy to connect together objects that don't know about each other, they're simple enough that your average CS sophomore could implement them in a half hour, and the concept is so obvious (besides having dozens of examples of working and deployed implementations) that there's no way to screw it up, right?

Wrong.

Now, C# is generally a somewhat clunky language, but this is nothing to do with that (I am not, for instance, surprised that it's cumbersome to bind extra parameters to an event in a language that has little support for higher-order programming anyway). No, this is one of those utter idiocies that just make you scratch your head and go what the *@&# were they on when they did that? You see, when you call an event with no attached listeners, C# throws an exception. Just, you know, as a friendly way of letting you know that you didn't connect to that event.

But wait! It gets better! In order to test whether the event has any connected delegates (the Microsoft term for a function object), you ... compare it to the null pointer. Yes, that's right. Every time you call an event, you have to do this:

if(Event != null)
    Event();

...because, of course, an empty collection of events is clearly the same thing as a nonexistant object.

I really wish I could be a fly on the wall at the meeting where this was decided. My imagination supplies a scene along these lines:

Scene: A smoke-free office somewhere deep in the sterile labyrinth of the Microsoft campus

Programmer 1: "...and we call this bold new innovation 'events'! It's a way for you to perform method calls without knowing which method you're calling. We've found that it's amazingly useful when doing UI programming. I'm sure that introducing this new idea to the world will be yet another chapter in the Microsoft story of advancing technology!"

Programmer 2: "Have you checked the corner cases? What happens if there is no method available to call?"

Programmer 1: "Oh, of course! In that case, the list of methods is null, so we throw a NullPointerException. We thought about adding an IsEmpty property, but who would want to look up properties on the null pointer? Besides, hardly anyone will ever want to create an event that might not get connected to."

Programmer 2: "Uhhh, sure, that makes sense to me."

...!!!?!?!?!

To make a long story short I obliterated the working directory of my current project with a bad invocation of rsync, but I have been able to recover most data with a few hours of work using the unrm and lazarus programs from The Coroner's Toolkit maintained by Wietse Venema and Dan Farmer. If you use ext3 and do not have an undelete command then this is the next best thing. (This current project is the major reason for why I have not been very active with my Debian packages in the last month.)

After listening to a lecture by the illustrious Dr. Gabriella ("biella") Coleman on the ethics of Free Software hackers yesterday, I read the expulsion thread on -devel. Hearing what biella talked about makes me think that Debian, as a culture, isn't ready to start expelling people based on their ability to get along with the rest of the project. It conflicts far too much with our ideals. On the other hand, drumming a person out so they feel so unwelcome that they choose to leave is pretty well Ok with us. If we're going to make interactions between developers more civil and friendly and less personally hostile then we need a different kind of stick. Maybe a carrot of sorts is in order too?

In other news, I've proposed a mechanism to "facilitate communication" so that the DPL candidates can stop repeating it every year. This mechanism is inherent in the constitution, and if we start expecting that the DPL assume this responsibility and exercise this right, it'll actually happen and the DPL will at least have some more concrete way in which to do some leading. Maybe it'll help the whole project gain some momentum and not get bogged down by some of the long-running debates that have plagued us in the past.