I have a few small shell scripts that connect podracer and obexftp, so I automatically get the newest podcasts uploaded to my mobile via Bluetooth when I log in. So far, so good, but most podcasts are longer than my average commute, so I need to pause and restart. If I don't turn off the phone or listen to other stuff, this is still fine, but if I ever lose the stream position, I'm boned, because Nokia's music player cannot seek properly. Whenever I seek further than about 30 seconds (the numbers vary, depending on what position I'm at, and how far I have already seeked), it will simply skip to the next MP3. I can see two options at the moment -- Nokia releasing an update, or me porting Linux to the 6230i. I shall be hacking a JTAG connector soon.

Via tha ABC:

Queensland’s Police and Corrective Services Minister Judy Spence […] told Parliament […] “Palmer and Comrie got it right, the Department of Immigration is unwilling to review and reform itself and it isn’t helped by an incompetent and indolent minister who isn’t willing to push these reforms.”

So today’s award for the promotion of indolence as a term and a lifestyle is jointly awarded to Ms Spence and Ms Vanstone! Congratulations to both our winners!

I've got some exciting news about the Ajax Developers' Day at XTech, which is on Tuesday 16 April.  Ajax guru Alex Russell of the Dojo toolkit project will be delivering the day's keynote presentation. He's subjecting himself to a punishing flight schedule on our behalf, so I'm grateful that he's able to take part.

In addition, Yahoo! genius Simon Willison will be chairing the Ajax day. As well as delivering a talk on the Yahoo! interface toolkit, Simon will be marshaling the speakers and discussion so everybody gets the best out of the day.

Be there, or forever regret your old fashioned UI.

Jim Gettys wrote about a problem regarding localisation that the OLPC project will face in the future. The One Laptop Per Child project aims to provide the famous $100 laptop to children in the developing world. They are Free Software based, and as most GNU/Linux distributions, the bundled software will be available in a number of languages. For now, it'll only be ten or so, but as OLPC grows, the number will skyrocket... just think about the number of languages spoken only in Africa. The $100 laptops don't have a hard drive. Instead, they have a 1 gigabyte of compact flash memory, which is enough to run the software, but it can't store that much extra data. The most common way of internationalising and localising Free Software is to use GNU gettext, which provides an easy to handle text file format for translations, with a series of sentences and labels that the translators need to fill in in their language. The applications ship these translations in .mo files, which are the same .PO files, in compiled binary format the gettext enabled programs can read. Each application installs one .mo file per language it is translated into. When the apps are big enough, these files can amount to several megabytes per application, which is a problem for embedded systems or projects like OLPC. Ubuntu has been trying a different approach to the distribution of translations. Instead of packaging all the translation files with the applications .deb packages, they are stripped off from the packages, and provided by language packs. Language packs offer the translations for all the applications and libraries of the main component of Ubuntu. This includes GNOME, KDE and many other popular applications. When you install Ubuntu, you select the main language of the interface, and the installer program will download the appropriate language pack, plus a selection of useful localisation-related packages like dictionaries, translated manuals, etc. These language packs are generated periodically by Rosetta, a web-based translation portal which is sponsored by Canonical, Ubuntu's and Launchpad.net's parent company. Rosetta offers a very easy to use translation infrastructure, and Ubuntu users can start translating the applications they are running with just two clicks on the application's interface. With Rosetta lowering the barrier for people wanting to translate Free Software, Ubuntu can have, and is now having, lots of people improving the translations of not only the next version of the software, which is what translation groups have traditionally worked on, but also the version you are running at that same moment. There is no need to wait for the next version of Ubuntu to see your translations complete. Help your team translate whatever is missing, and wait for the next language pack update. Voil ! If the OLPC project adopted the language pack scheme and Rosetta, they could install a raw OLPC laptop without translations, and only install the language packs that are needed in the target country or area. The langpacks are currently split into GNOME, KDE and the rest , but any derivative could fine-grain the components they wish to include. Furthermore, the system helps improving the localisation of the system after the laptops have been deployed. Just stick a USB drive to the laptop, and use your usual package manager to install the updated language packs contained in it. Or just use the Internet if it's available. In environments where network access is completely impossible, making the availability of updated packs from a remote server a no-op, as well as online translation in the Rosetta server, other solutions could come in place. Generating langpacks from a set of local PO files should be pretty easy.

Voil ! In                                                       view, a humble
 vaudevillian                                                  veteran, cast 
  vicariously as both                                         victim and
   villain by the                                            vicissitudes of Fate. This 
    visage, no mere                                         veneer of
     vanity, is a                                          vestige of the
      vox populi, now                                     vacant,
       vanished, as the once                             vital
        voice of the                                    verisimilitude now
         venerates what they once                      vilified. However, this 
          valorous                                    visitation of a bygone
           vexation stands                           vivified, and has
            vowed to                                vanquish these 
             venal and                             virulent                   Remember, remember the 5th of November
              vermin                              vanguarding
               vice and                          vouchsafing the
                violently                       vicious and
                 voracious                     violation of
                  volition. The only          verdict is 
                   vengeance; a              vendetta held as a 
                    votive, not in          vain, for the
                     value and             veracity of such shall one day
                      vindicate the       vigilant and the
                       virtuous.         Verily, this 
                        vichyssoise of  verbiage 
                         veers most    verbose
                          vis- -vis an introduction,
                           and so it is my
                            very good honor
                             to meet you
                              and you may
                               call me
                                  V.

Yes, I've seen V for Vendetta today. Very impressing movie, highly recommended! Makes you start to think...

Hi! This is Comas, the conference management system we all know and love! Perhaps you remember me from /www.consol.org.mx/">/www.consol.org.mx/">CONSOL 2004 and 2005, Debconf 5 and 6, CICOL, Seminario Globalizaci n, Conocimiento y Desarrollo or other such great conferences! Well, it is a pleasure for me to announce I am moving.
That's right - My developers have felt too constrained by CVS to keep being merry and productive, and decided to move away from it and to Subversion. If you are tracking my development history, you should have noticed a new file in my base CVS directory, called DONT_USE_THIS_REPOSITORY_ANYMORE. I will reproduce it here following Gunnar's wishes, and hoping it is useful to you.

PLEASE DON'T USE THIS REPOSITORY ANYMORE! Just in the meantime, while we migrate our current installations to point to the correct server, while our users take note, and while the kind GBorg admins lock down this project: PLEASE DON'T USE THIS REPOSITORY. WE HAVE MOVED. The Comas project will no longer be hosted at GBorg - We are moving to Debian's Alioth.
Comas' webpage (although it is still ugly :) ) is still the same as always. The repository will no longer be handled through CVS - We switched to Subversion. Don't worry, the usage is basically the same. You can use anonymous access to get the Subversion tree. If you want to participate in the project, register at Alioth and ask us for commit access. You can also use the very nice SVN Web interface, which allows you to look at each of the files, view the changes, and even subscribe to the Comas RSS feeds! Development goes on. Stay tuned! Greetings, - Gunnar Wolf

Of course, as in any migration, there is still a lot of things to do. Mail the other contributors and interested people notifying them of the move. Migrate (and check the validity of) any tickets we have in the old site. Point all the places where there is Comas-related information to the new repository. Close the existing project page at GBorg. Sanely re-structure the repository in a more standard and functional way (and hope it does not break current installations ;-) ). Rework the documentation that has been neglected in the last months. Rework the bits of logic that never smelt very good but -as a dead rat- now positively stink. Fixe the things that will eventually stink as well... Anyway, I'm sure this will speed up my growth!
I am very excited on which way my dear authors will continue to push me - I know I'm quite a lousy program for many things, and I know there is a lot for me to learn until I am a military-grade conference management system - But my many parents have written me with deep love, and I understand they had to write hastily parts of my code. I understand their mistakes, but I hope they make them go away soon.

Google has hired Bram Moolenaar, author of vim. I bet the next beta-service Google announces will be "Google Vim" ;-) Or maybe not... (via digg.com)

Wow. Crisp morning. Temperature dropped to -3 C last night and we didn't turn the heat on in the house. I *love* this temperature. When it's sunny out and the morning is so cold that I have to wear my Birkenstocks around the house. I used to get up at 6am and bike to school in this weather. Then the day will warm up nicely to 8 or 10 degrees. Not quite t-shirt weather, but really close. There have even been birds singing outside the last two nights.<br /><br />And next weekend we have daylight savings time, so it will even be dark when I wake up. I'm excited!

I'm joining the crowd who is giving up on ICQ. I'm receiving too much spam and too many strange authorization requests. I will continue to be available via Google Talk, MSN and Yahoo (thanks to GAIM for making it easy).

I'm looking for a calendaring application with the following features:

1. Must have a (limited) command line interface. I want to be able to view my appointments of the day in plain text format, so that I can put that in my .profile; it'd be nice if it allows me to view my appointments on any random date, but that isn't required. Moreover, when someone sends me a meeting invitation, I want to be able to pipe the ical file into something which puts it in my calendar, with optionally also sending an email to the person who sent me the invitation that I'm accepting it (optionally, as in, it must have the feature, and it should allow me to decide whether to send the mail on a case-by-case basis, not as in it would be nice if the feature existed.)
   More command line features are nice, but not necessary.
2. Must have the ability to export ical files to a text file on my local hard disk; must not require me to set up a server with some weird login scheme and ditto protocol so that I can please put my webcalendar somewhere—and no, I won't sign up for one of those "free" webcalendar services. I'll put it online myself, thank you very much.
   This requirement rules out evolution, unless I missed some plugin somewhere (I don't think so).
3. Must have basic calendaring functionality. I.e., I should somehow be able to get an overview of my appointments of any given day, to get a weekly, monthly or yearly overview, to print out things, etc.
4. Must not require ages to start up. This, definately, rules out evolution. When I have a phone call, I want to be able to see within a few seconds whether I'm available at any given time.
5. The ability to synchronize my calendar with my cellphone somehow would be nice, but isn't absolutely required. I'm willing to jump through a number of hoops here. Note that gnokii supports my cellphone.

Suggestions are welcome.

The Latin American Infest finally ended yesterday. In Caracas, it was a week of hard work with people of the Science and Technology Department and the IT Office (government offices) but the event in Caracas ended succesfully. It was a world-class event featuring renowned keynote speakers who spoke about Web Development using Frameworks (featuring TurboGears, Rails and Catalyst) and software development paradigms migration from privative platforms to GNU/Linux (Gambas and Mono). Other talks included basic security in Debian GNU/Linux and a speak about electronic signature security by an officer of the Venezuelan Government CA. We had a speak about Clusters, hosted by a female member of the Venezuelan Free Software Community and Debian User, and a speak about Free Software in the Venezuelan Education, by a 16-year-old Venezuelan GNU/Linux user and a willing Debian Maintainer. Of course, the Installation Festival took place in the Knowledge Square, in the Auditorium Building Lobby, with the extraordinary support of the Venezuelan Free Software Users Community. Debian GNU/Linux Sarge netinst and CD1 was distributed (several hundreds) as well as Knoppix and Ubuntu Hoary. Ernesto Hern ndez-Novich (maintainer) and me wore Debian T-Shirts on Saturday, and he made a great speech about the Project, named “Debian is inexorable“. We had demonstrations of Linux on a Mac Mini, using XGl and presenting several applications, as well as Debian running Enlightenment on an old Presario 1246 laptop. I would like to thank all the speakers and the attendees for making of FLISOL Caracas a great event. More information about FLISOL Caracas is in my blog and the homepage (spanish). Pics are here.

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've been using Drupal for this blog for most of its life. However, I'm starting to be quite annoyed by several things:

• The Captcha module is seriously broken and opens up the door for various security problems
• The Spam module is there, and works mostly, but is not effective enough to keep spam down
• The badbehavior module is over-aggressive and doesn't work well anyway
• Spam becomes a serious drag on load of the server

So I'm planning to switch to something else. Something where blogging will be fun again, without all the hassle of tracking down spam. It looks like either Wordpress or Serendipity, and I'm leaning towards Serendipity for now.

Listening to music with CDs is a pain. Because every CD gets boring quickly. Radio stations are fun for some time, but they also play the same bad songs over and over again. So I still have a collection of MP3 songs (albeit all CDs I converted recently are now ogg vorbis, since this offers a better compression, and my portable player can play ogg, too). So if you try to maintain a collection of your favourite MP3s, you'll sooner or later end up having some duplicates. Or many of them. The cleanest approach would of course be to just delete your whole collection and start converting your CDs again (this time paying more attention to tagging and such). But this would take a lot of time again... I've written a small tool which uses the musicbrainz library to generate audio fingerprints of songs; these are then stored in a small database, and another tool can list duplicates from that database. This of course still doesn't catch all duplicates (well, some songs are slightly different among different albums, and sometimes they result in the same TRM id, sometimes they do not) but does a fairly good job. Beware of (rare) false positives, however. It should work on Windows, too. But I really have no clue on how to setup musicbrainz, pyogg and pymad on Windows. Debian users can just apt-get them. Don't ask me about how to install on windows: I don't use windows. Grab it from it's temp home for the TRM-dupefinder (grab all .py files, trmdb.py is the main lib, the others are the applications). Calculating all the audio fingerprints takes a long time; but the gen tool will only process each file once and continue where it left off. So you can do it in multiple runs. Then run the dupe tool at the end. Tunepimp is probably a smarter way to do this (and maybe verify tags in the same run), especially since it apparently can store the TRM id in the ID3 tag, to avoid recalculation even better. However, I didn't get the python-tunepimp bindings to work properly.

Over the last 2.5 weeks I have built the complete Debian archive on a quad-core MIPS machine donated by Broadcom using the recently released version 4.1 of GCC. In parallel, I have done the same on an EM64T box donated to Debian by Intel. The purpose of this exercise was three-fold:

• Find out about compiler problems in GCC 4.1 itself as well as in packages that may fail with the new version before GCC 4.1 is uploaded to unstable. GCC, in particular G++, is becoming stricter regarding adherence to standards and packages may fail to build with 4.1 due to invalid code that was accepted previously.
• Find out about MIPS specific problems in GCC 4.1 and to answer Matthias Klose's question as to which platforms can move to GCC 4.1 as the default compiler once it is uploaded to unstable.
• Find MIPS specific assembler warnings and create a list of all users of xgot (a MIPS specific toolchain problem).

Executive summary GCC 4.1 itself appears to be very stable, both on MIPS and AMD64. There are, however, a large number of packages using code (especially C++) which GCC 4.1 treats as errors. Fortunately, most of them are trivial to fix. By compiling about 6200 packages, over 500 new bugs have been discovered and submitted, 280 of which are specific to the increased strictness of GCC 4.1. Patches for 2/3 of those GCC 4.1 specific bugs have been submitted. Based on my findings, Ben Hutchings has prepared a summary of the most common C++ syntax errors (that weren't treated as errors before G++ 4.1). Most common programming errors Basically, it all boils down to broken C++ code. There were a few bugs in C code, but the majority was in C++. The most common errors I found are:

• extra qualification
• reliance on friend injection
• wrong escape characters (e.g. "\.", most commonly seen in regular expressions)
• iterator problems (such as assigning 0 or NULL to an iterator)
• template specialisation in wrong namespace
• template reliance on a function declared later
• use of template's base class members, unqualified, where the base class is dependent
• use of assert without #include <cassert>
• dereferencing type-punned pointer will break strict-aliasing rules (a warning) combined with -Werror

I've posted a detailed report to debian-devel. Acknowledgements (abridged)

• Broadcom for supporting our MIPS port through the donation of hardware to the project and developers. Without Broadcom, our little and big endian MIPS ports would have a hard time meeting the release criteria regarding autobuilders.
• Google for supporting my PhD, thereby allowing me to spend two weeks compiling the archive with GCC 4.1 and sorting out failures.
• Intel for supporting some PhD work which led to this experiment.
• Ben Hutchings for explaining many of the C++ bugs I found to me. I've learned more about C++ in these two weeks than I ever wanted to know. ;-)

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.

Needed a mailclient wich can handle a lot of folders and is very customiable
also i more and more need to read my mails via ssh on very slow connections
so evolution was unusable
Mutt isn't the right thing when you have a lot of folders and subfolder
Switched to Gnus
Ganneff helped me a lot so now it works fine
Figured out that if you want imapS do:

(setq nnimap-address "mailhost")
(setq nnimap-list-pattern "*")
(setq nnimap-authinfo-file "~/.nnimap")
(setq gnus-select-method'
(nnimap "mailhost"
(nnimap-stream ssl)
))

and other than in all the documentation do not write the port thing into .nnimap
only write:

machine mailhost login username password topsecret

otherwise it will still doing IMAP without S

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 ?

Linux kernel has a limitation on how many times it will resolve the symbolic links.Apparently, you won't be able to 'open' a file which has more than 5 indirections, if youlet the kernel resolve the symbolic link.This is a well-meaning limitation to avoid DoS.Unrealistic workaround that come up to my mind such as to hack glibc to stat the symbolic links before opening, or making applications to call canonicalize_file_name before open.Sometimes, this gets annoying.