As I see it, there are three positions:

• Those who think that everybody except their candidate is a teletubbie
• Those who think everyone has a chance to win except the teletubbie
• Those who don’t care about teletubbies and would rather vote for Power Rangers

Yes, someone already told it: is that time of the year again. This small and insignificant fact (the DPL election) can shock the entire Debian Community. This kind of stuff makes us the fun, social and rewarding Debian Community some people claim we should be. The people who only cares about developing will keep working disregarding all the social conflicts. So most people won’t take much care about the Election, pick up a candidate, vote and keep working
It says: Welcome - Bolivarian Revolutionary Government of the Merida State David has more than one week in Venezuela. I’m gladly offering him accomodation in my house, bandwidth and all the support he needs for the next twenty years. We spent a weekend in Merida (which is in the Venezuelan Andes) in some Free Software Workshops and the rest of the week we have been working in several migration projects in the Company I’m working with. We have setup g33k!, a small server in my room running Debian (and Cherokee and Jaws) just for fun and testing. He’s leaving to San Crist bal (the capital of a state in the border with Colombia) on Friday and I should be finishing my semester as well. The next big Free Software event in Venezuela is the Latin American Infest. See you there!

n/a

n/a

Got access to a new, more powerful server, moved my blog from Mnemosyne to Wordpress, hopefully did not flood p.d.o, did not move the comments over yet. And not to flood the planet.d.o with the move I did this little change to the Wordpress feed - at the very end of the wp-atom.php file there is this line:
<?php $items_count++; if (($items_count == get_settings('posts_per_rss')) && empty ...
So I changed it to this:
<?php $items_count++; if ((($items_count == get_settings('posts_per_rss')) $post->post_date < 1150758000 ) && empty ...
Where 1150758000 is the UNIX time of some point between the last post from the old blog and the first post in the new blog. And I also imported my old posts entries from an Atom feed using the rss feed import as a base. The diff is after the break
--- rss.php 2005-12-28 22:24:12.000000000 +0200
+++ atom.php 2006-06-18 18:26:03.000000000 +0300
@@ -1,13 +1,13 @@
< ?php -class RSS_Import
+class Atom_Import var $posts = array ();
var $file; function header()
echo '<div class="wrap">';
- echo '<h2>'.__('Import RSS').'</h2>';
+ echo '<h2>'.__('Import Atom').'</h2>';
function footer()
@@ -21,8 +21,8 @@
function greet()
- echo '<p>'.__('Howdy! This importer allows you to extract posts from any RSS 2.0 file into your blog. This is useful if you want to import your posts from a system that is not handled by a custom import tool. Pick an RSS file to upload and click Import.').'</p>';
- wp_import_upload_form("admin.php?import=rss&step=1");
+ echo '<p>'.__('Howdy! This importer allows you to extract posts from any ATOM 1.0 file into your blog. This is useful if you want to import your posts from a system that is not handled by a custom import tool. Pick an Atom file to upload and click Import.').'</p>';
+ wp_import_upload_form("admin.php?import=atom&step=1");
function get_posts()
@@ -33,14 +33,14 @@
$importdata = implode('', $datalines); // squish it
$importdata = str_replace(array ("\r\n", "\r"), "\n", $importdata); - preg_match_all(' <item>(.*?)</item> is', $importdata, $this->posts);
+ preg_match_all(' <entry>(.*?)</entry> is', $importdata, $this->posts);
$this->posts = $this->posts[1];
$index = 0;
foreach ($this->posts as $post)
- preg_match(' <title>(.*?)</title> is', $post, $post_title);
+ preg_match(' <title [^>]*>(.*?)</title> is', $post, $post_title);
$post_title = $wpdb->escape(trim($post_title[1])); - preg_match(' <pubdate>(.*?)</pubdate> is', $post, $post_date);
+ preg_match(' <published>(.*?)</published> is', $post, $post_date); if ($post_date)
$post_date = strtotime($post_date[1]);
@@ -68,13 +68,13 @@
$cat_index++;
- preg_match(' <guid .+?>(.*?)</guid> is', $post, $guid);
+ preg_match(' <id>(.*?)</id> is', $post, $guid);
if ($guid)
$guid = $wpdb->escape(trim($guid[1]));
else
$guid = ''; - preg_match(' <content :encoded>(.*?)</content> is', $post, $post_content);
+ preg_match(' <content [^>]*?>.*?<div .*?>(.*?)</div>\s*?</content> is', $post, $post_content);
$post_content = str_replace(array ('< ![CDATA[', ']]>'), '', $wpdb->escape(trim($post_content[1]))); if (!$post_content)
@@ -85,6 +85,7 @@ // Clean up content
$post_content = preg_replace(' < (/?[A-Z]+) e', "'<' . strtolower('$1')", $post_content);
+ $post_content = str_replace('\n', ' ', $post_content);
$post_content = str_replace('<br>', '<br />', $post_content);
$post_content = str_replace('<hr />', '<hr />', $post_content); @@ -160,12 +161,12 @@
$this->footer();
- function RSS_Import()
+ function Atom_Import()
// Nothing.

-$rss_import = new RSS_Import();
+$atom_import = new Atom_Import(); -register_importer('rss', 'RSS', __('Import posts from an RSS feed'), array ($rss_import, 'dispatch'));
+register_importer('atom', 'Atom', __('Import posts from an Atom feed'), array ($atom_import, 'dispatch'));
?>


Forking debhelper is apparently so much fun that everyone is doing it. Of course, Ubuntu continues to make changes to debhelper with no regard to the possible consequences, no matter how often I point out that this is a dreadful idea. Today I noticed (it's not like they bother to tell me) that they have added a dh_iconcache command to it, so presumably various Ubuntu packages cannot build with Debian's version of debhelper, and if I decide to add a different dh_iconcache command to it, things might build but incorrectly. To add to the fun, the version of debhelper in Debian unstable is now forked from what I guess I have to consider the "upstream" debhelper, since it got NMUed. This fork modifies dh_python in ways that, if I decide I don't like, I will have to either painfully carry forward or break a lot of stuff to get rid of. The reason it was NMUed is because I'm not interested in debhelper being in the middle of the senseless conflict between python-central and python-support. (It's a good time to be a perl user BTW. TMTOWTDI?) All this is not very much motivation for me to continue to work on this stuff, but we'll see I guess.

Thanks to all of the helpful comments people left in response to my last post about hosting. I got some really helpful hints from them -- including the one I eventually followed, to VPSLink.

I wound up going with VPSLink. Their prices are amazing and the performance is good, too.

I have to admit -- I shot myself in the foot not once, not twice, but three times. The shorewall config I was using on my old VPS (which was hosted under UML) apparently doesn't work well under OpenVZ (used at VPSLink). By "doesn't work well", I mean "blocks all traffic to or from the host on startup".

So, I had rsynced over everything from my old host to the new, and rebooted the new. But it didn't come back up. I was pretty sure this was why. I dropped off a ticket to the VPSLink folks asking them to please rm /etc/init.d/shorewall for me.

60 minutes later, they had done it. (And it looks like a bug in their ticket system prevented it from being flagged as "emergency" -- they said they would have done it faster otherwise.)

I then tried to fix shorewall, and it looked like it was working, so I put the init script back and rebooted. Same problem! They fixed it again in about 60 minutes. (The ticket still had normal priority)

Finally, I deleted shorewall entirely, then rsynced my old host to the new one. Things looked good, so I rebooted.... and yes, guess what, that rsync brought back shorewall so it got hosed YET AGAIN. ARGH. This was now well into the overnight hours, but they still helped me out.

All in all, I am so far VERY impressed with VPSLink. I heartily recommend them. I'll be sure to post updates as time goes by.

Regarding Memset, my current provider: Really great company. I heartily recommend them, too. My needs for RAM just wouldn't be ecnomical under their current plans, but they are usually competitive. I also have experience with JohnCompanies. I used them way back when they only did FreeBSD VPSs, on through the Linux days, and we currently use their services at work. These are also great folks and I would recommend them to anyone. Like Mako's suggestion of Rimuhost, both memset and JohnCompanies are "quality first" providers -- not necessarily cheapest, but their systems work as advertised and are almost never down, and they support you with experienced Unix admins. BTW, Memset's current plans use Xen and JohnCompanies uses Virtuozzo.

Many advances have been made in agile software development. Frameworks such as Ruby on Rails embody agile principles by making software easy to write, easy to test, and above all, easy to change.If only we could say the same for the infrastructure on which we develop and deploy web applications. Not every application can be a Rails one, especially where it's been up and running for years. The systems we deploy on often rely on configuration files scattered all over the filesystem, and can be complex results of years of change.By extension, the systems we develop on often don't exactly mirror where we deploy. If we're lucky and careful, then we have a staging server which mirrors the live environment, but that's not too much of an advantage. Among other things, we need ways to evolve and refactor the live environment, and have our development environments easily track that.I'd like to call such an environment "agile infrastructure". Infrastructure that doesn't hamper developers, and allows live configurations to change and evolve. Infrastructure that allows new things to be tried with minimum cost, and can provide the best information possible to help future planning.Tools enable techniques, of course. It's a lot easier to be agile if you're programming in Rails rather than plain old PHP. So what are the tools enabling agile infrastructure?
Techniques I've found usefulWhile there's a long way to go, I'd like to describe some of the techniques I've been using to help create a flexible environment for developing a sizeable PHP/MySQL application.Operating systemAn operating system must be easy to bring into a known state with minimum interference. For this, I've found Ubuntu or Debian to be an ideal choice. Two of the main reasons include the constancy of stable releases and the fact that it's rare you need to stray outside the distribution's servers to get the software you need.DeploymentDeploying an application shouldn't break the cleanliness of your OS build. I prefer to package deployed applications into .deb files. This enables me to build on several advantages of the package management system:

• configuration file handling: deployed machines can keep individual config in /etc, which is preserved over software update.
• no random state: you know for sure exactly the state of the deployed application, no random files left hanging around.
• natural workflow: packages take a little bit of effort to build and deploy, which means it focuses developers on getting them right. If things do go wrong, it's very easy to roll back one version.

Source controlThe case for source control, thankfully, doesn't need making these days. Yet not every source control system is created equal. Developers shouldn't be constrained by source control, it should be cheap and easy to try new ideas and merge these in later.Not only cheap branching, but also easy merging, is required to keep development agile while still retaining the benefits of source control. Many people flock to Subversion these days, predominantly because it fixes some of CVS' more egregious misfeatures. However, merging can still be pretty difficult in Subversion.I prefer to use a system allowing easy merging, such as svk or bazaar. Because so many of us use laptops these days, disconnected operation is also a huge boon. Bazaar-NG offers both repository-oriented and completely decentralized operation, giving the best of both worlds. It also wins the competition for least setup overhead.VirtualizationPreviously a high-powered technology, cheap virtualization is now with us. Many identical virtual machines can be quickly created to enable testing and experimentation. Deployment to virtual machines can enable hardware independence for applications, reducing another big headache.Large organisations have it within their reach to bring new hardware online easily, and have invested much in management systems for it. Virtualization brings this in reach of small and one-man development teams.Desktop-based virtualizationSystems such as VMWare and Parallels untether developers from their desks. I use the OS X desktop daily for its productivity software, but an Ubuntu virtual machine for a large proportion of development work. A simple keypress lets me flick between the two. The advantages of multiple desktops to hand for web development are well known. (In fact, thanks to WINE and IES4Linux I can run Internet Explorer cheaply too from the same virtual machine).
Xen virtualizationAfter the initial novelty wears off, one of the most tedious tasks in the world is bringing new machines online. Combined with the tendency development environments have to get crufty as new ideas and tools are tried out, this makes for increasing disparity between the development and deployment environments.Wouldn't it be nice just to take a clean machine off the shelf, check out the source, and pick up again? Using Xen for Linux, this cheap virtualization is possible.Sadly, Xen isn't yet a packaged part of Ubuntu, but getting it up and running on Ubuntu Dapper isn't too hard. Warning: here's where things get pretty deep. Skip this bit if you're not interested in the nitty-gritty.I followed these steps:

• Followed instructions in the Ubuntu wiki to get the first domain (vm) up and running
  
• Installed the xen-tools package, which provides wrappers for easily creating virtual machines
• Adjusted some of the xen-tools configuration (/etc/xen-tools/hook.d/20-setup-apt) to set up for Ubuntu rather than Debian
• Once the virtual machine was made, adjusted its config to allow for the kernel initrd and configure the network bridge I was using
  

Getting over the DNS mountainIf you want it to be easy to bring new virtual machines up and down, you need to adopt a different approach to managing your DNS. You need to know how to predictably connect to a virtual machine. Yet it's going to get very boring and error prone to manage the IP address space manually in your DNS, or even to map the MAC addresses of your virtual machines in your DHCP configuration.
Help is at hand in the form of mDNS (also known as Rendezvous / Bonjour / ZeroConf). In the host machine, and in each virtual machine, I ensured the avahi-daemon and avahi-utils packages were installed, providing mDNS services. (You should also check that mdns is present in the hosts entry of /etc/nsswitch.conf).What all this does is allow the machines (virtual or otherwise) on the network to resolve names using mDNS. So if I create 3 VMs, alpha, beta and gamma, I can access these right away using the hostnames alpha.local, beta.local and gamma.local.Hey presto! Easily make machines appear and disappear without any need for sysadmin involvement. All the extra steps to add avahi installation can be easily scripted with xen-tools, to reduce the number of commands needed to birth a new machine to one.With this ease of creating new machines, it's much more straightforward to experiment with server topology and conduct experiments on server environments.ConclusionAgile development is necessarily constrained by the infrastructure on which it is conducted. The infrastructure itself is constrained by the tools and platforms of choice.By appropriate tool choice we can reduce the commitment and overhead of infrastructure. This enables developers to get on with the job they do best, and makes experimentation and evolution of infrastructure much simpler.When programming, it's dangerous to fall in love with your code, as the best solution may often involve throwing half of it away. The same hazard exists with infrastructure, with bizarre and awkward effects propagating back into code and operations. Get yourself a low commitment, agile environment, and you'll be able to keep up with the pace. 

My friend Dick rarely asks anyone anything. If he needs some information, he looks it up himself, on the Internet, in a book, from source code, or wherever. Only after spending considerable effort himself will he ask someone else. He takes this so far that he'll get very upset if you give him the information. It ruins his day to get derailed, and then he sulks the rest of the day. My other friend Ollie, on the other hand, always asks immediately when he has a problem. Either on IRC, by e-mail, by calling on the phone, or by shouting over a cubicle wall. He'll even run to the other side of the building to find someone he suspects has the answer. Only if he can't find anyone with the answer will he start looking for the answer himself. Both Dick and Ollie are smart. Both are successful in their careers and both are regarded well enough by their colleagues, but only Dick is considered an expert. Looking things up yourself is slower and harder, in the short run. You spend a lot of energy finding the little bit of information that solves your immediate problem. On the other hand, you learn things on the way. You learn about things related to or surrounding the immediate bit, and most importantly, you learn where to find more information. You might even learn that the bit you're looking for is the wrong bit, and there's an altogether different way of looking at the problem that lets you do things in a much better way. There's nothing wrong in asking questions, but on the whole, it's better for yourself to try finding the answer yourself first. In a hacker culture, where being good at something is valued exceptionally highly, someone asking frequent questions is often considered annoying. Doubly so, if they seem to be an Ollie. Don't be an Ollie. Do yourself a favor and be a Dick. (This entry was written some time ago, in reaction to a certain someone's umpteenth question of the day, and seeing people responding simply with Google's domain. I've postponed publishing it because I didn't want to attack that person directly.)

Hi, for the debian boot process project, the last days I looked at the SUSE, Mandriva and Fedora distributions to analyse their boot process. The most interesting so far was SUSE being LSB compliant and having insserv/startpar to set and ajust the dependencies for parallalel booting. The insserv/chkconfig combinations seems to do the same as FreeBSD's rcorder although rcorder checks dependencies in two stages: with root filesystem and with all mounted filesystems.

Fedora looks like a regular sysvinit process although it contains LSB information in the initscripts that is read by chkconfig to set dependencies in the /etc/rc.d directories. Nevertheless, the dependencies don't adjust to added/substracted scripts.

Finally Mandriva 2006 doesn't seem to have pinit/prcsys in their default configuration so it seems to have a standard sysvinit.

BTW, the first deliverable is being written in latex (with pdf and html versions generated together) and available here.

...or so Spock said. Apparrently. Yesterday, for some reason, I was reading something on Wikipedia. Don't ask me what I started with, I don't remember; however, my journey through Wikipedia eventually got me to the Rare Earth hypothesis, the Principle of Mediocrity, and other related things. Both are subjects relating to whether or not there would be life on other planets. The latter claims that this is, in fact, quite likely; the Principle of Mediocrity basically says that "Earth is a relatively ordinary planet orbiting a relatively ordinary star in a relatively ordinary galaxy which is one of countless others in a giant universe, possibly within an infinite multiverse". This is supported by a number of astronomical findings. The contrast to that, the Rare Earth hypothesis, claims that Earth is, in fact, not a very ordinary planet. That to be able to reach a point where complex multicellular can have evolved—such as on Earth—such a high number of variables have to have the exact right value, with in many cases such low margins for errors, that while possible, the likelihood that life would exist on other planets is very low. They were both interesting reads. However, there is one thing to which I did not find an answer: Why does it have to be Earth-like life? As I understand the theory of our origins, life began on the Planet Earth in a relatively stable body of unclean water—known as the "Oersoep" in Dutch, though I couldn't find the English term for that—on which the sun shone; that sunshine made the elements of the "oersoep" react with eachother so that it eventually formed single-cell life, which then evolved into multi-cellular life, and so on. Even today, the sun still shines on Earth, and almost all energy in use on Earth can in some way or another be attributed to something that once received sunlight; I suspect the only exception to that is nuclear energy. As I understand the Rare Earth hypothesis and the Principle of Mediocrity, both seem to assume the basic premise that the only way in which life could evolve is the way in which it evolved on Earth; that is, you need direct sunlight so that you can have some chemical reactions. You cannot have too much ultraviolet, gamma, or x-ray radiation, because that would kill life. You cannot have too many impacts of extraplanetarian bodies, such as comets or asteroids, because these impacts and the resulting fallout would destroy life. I did not find any argument for that assertion, however; and what I don't see is why it would be necessary. We could define the "oersoep" as some sort of a "stable chaos": a bunch of chemical elements and a varying external influence (sunlight) means that you have a brewing and reacting bunch of matter, where the composition of the matter is constantly changing; however, at the same time, when viewed over a large amount of time, not much did in fact change. The varying external influences have a regular and stable rhythm; the sun appears in the morning and disappears in the evening. The sun shines longer in summer than it does in winter. While it is not the same all the time, there is predictability. If a number of chemical elements react with eachother in a certain way on one day, then they will react the same way again the next day. If this happens for years on end, you may have a series of reactions that is more or less reproducible, where the final result of all the chemical reactions turns out to be the original starting point again. At least almost so. Such a series of chemical reactions could be called "life", especially if it occurs within a small group of chemicals that sticks together, like a cell. While a body of unclean water with regular sunshine certainly is one way to get to a series of repetitive chemical reactions, I fail to see why it would have to be the only possible way. If there were a planet composed mainly of Helium (rather than Hydrogen and Carbon, as on Earth) but also containing a bunch of other elements (so that they can react with eachother) with a star that sends out lots of gamma radiation and an atmosphere which blocks sunlight (I don't know whether Helium can do that, but let's assume it can), then I do not see why it would not be possible for life to evolve on such a planet which would be based on Helium rather than Carbon and Water, and which would require gamma radiation to survive but would die when brought into prolonged contact with light, just like we will die when brought into prolonged contact with gamma radiation. Another example could be a planet where every year a comet of approximately the same composition impacts on the same place on the planet's surface. Such an impact would regularly stir up the chemical elements on this planet, and could provide the needed energy to produce the chemical reactions required to sustain life. If any life were to evolve on this planet, not only would it be able to survive such constant extraplanetary impacts, it would also require these impacts to continue in order to survive. I haven't been able to find any information on that. It would seem that either I'm missing something very basic, or that nobody has thought of this before—and I would find that highly unlikely. So, anyone who's been thinking longer than me about this subject (that is to say, just a few hours) who could enlighten me? Of course, one answer could be to say that God created all life, and that the evolution theory is only a theory, which is not grounded in any reality. But make a comment to that effect on my blog, and I will moderate it away. After having a good-hearted laugh at it.

At the last FOSDEM, I gave an interview to the guys of Source21.nl. Which has been published on their website right now. As you will be able to see if you have a look, I did not have much of a voice—mainly because I had been yelling people to please move away from the bar on friday night. But, well—it still came out pretty well, I think. Yes, my hair looks ugly (I shaved it off a week later or so), and yes, I made some factual errors regarding the release date of Sarge. But let's not dwell on that too much, shall we? ;-)

Just a quick follow up on my Cross-Site-Authentication Attack: My article for the German Linux Magazin which was translated for its English counterpart Linux Magazine is now available online. Before you ask: I did not chose the image there. I’m still waiting for the German version to be opened up, too, but that will probably not happen before October.At the GPN 5 last weekend (a conference compareable to the Chaos Communication Congress, only smaller) I have held a lightning talk on the XSA Attack. In preparation for that, I actually tried it on the internal wiki of the Entropia e.V., and despite the relatively high technical knowledge of its visitors, some fell for the trap. As that was the only preparation of the talk, I wonder how it was perceived. Comments and tipps with regard to the form are welcome.By the way: The German wikipedia page on XSA tells us that newer firefox browsers won’t allow such an attack to work, which is good.

This is going to be a rant on how doing anything music related under Linux currently works very, very bad. Perhaps I shouldn't be writing this since I don't have the time or skillz to help out in improving it any (so anyone interested in posting a comment to that regard should know that I already know ;-P), and because I've done it beforebut let's just ignore that for a few seconds. Hah. I've been a musician since I was 7 years old (well, a bit less if you don't count the first years where I was only learning how to read music and not playing an instrument (the flute) yet). I've always loved doing it, since music is a great way to express one's emotions and to relax, in my opinion. Being able to produce beaty is also extremely satisfying, and I just love music (in a John Miles sort of way). When I started to get into computers at the age of 14, one of the early things I did, even before doing my first BASIC program, was to play with musical software. I fondly remember some old Commodore 64 program of which I have forgotten the name, which would allow me to put notes on bars and play them, which was cool at the time—even if it would not allow me to put more than three notes in one chord, since that was the maximum polyphony which the Commodore's SID chip would allow. Later, when my parents bought our first PC-based system—a 486DX4@100Mhz—I moved on to Finale¹. As a musical notation program, Finale is unsurpassed. It doesn't have a Linux-version, but there is lilypond. Of course, writing down music isn't everything. Any serious musician would also want to play the music he's written, either by having the computer play it itself, or by sending it to a MIDI device. This is usually done through a (hardware or software) MIDI synthesizer and some bit of software called a Sequencer. Traditionally sound cards came with hardware MIDI synthesizers on them, but as computers became more powerful (i.e., after the Sound Blaster 16-era), hardware MIDI synthesizers were replaced by software MIDI synthesizers that had their wavetable on disk and (when playing MIDI) in RAM. That doesn't require huge gobs of ROM chips on the sound card, resulting in either less expensive sound hardware and better MIDI playback (because software wave tables are usually larger than hardware ones). So what's the issue? Everything. While lilypond is nice, and (it has to be said) produces very beautiful output, the interface is way too cumbersome. I mean, what is the clearest thing to read? This:

r4\< e,8-. r8 r4 e8-. r8\!

or this? They represent exactly the same thing, yet someone who knows music needs a split second to decode the below but a few seconds for the above (if they understand lilypond's syntaxis). In fact, at first I thought that I had done something wrong in invoking lilypond-book to produce that snippet, because I had misparsed the code above (which, incidentally, is one bar of some actual music that I have in my ~/data/audio/lilypond directory) The plain text interface certainly does have some advantages, but IMO the downsides by far outweigh the benefits. In general, lilypond is not well suited as a way to actually write music, as opposed to simply typesetting already existing music. I did actually follow a course on harmonics (although I never finished it due to lack of time); when writing some new piece, I find that it often far easier to do the actual writing on a piece of paper and then enter that in lilypond syntaxis, rather than getting distracted over the lilypond syntaxis while trying to concentrate on what chords I can and/or want to use. It is unnatural, and would look like a Japanese person being forced to read and write texts like 'gaka ga e o kaita' which then get postprocesssed into something like ' ' (look ma, Unicode!). Or, in other words: why isn't there just an input method to write music? There are unicode characters for musical notes, you know... When comparing lilypond to finale, it is not hard to understand that entering music in a graphical environment is just so much easier. When I last used it, Finale had four input methods: one with keyboard and mouse (use the numeric keys on the keyboard to enter the desired note length and the mouse to enter the pitch); one with keyboard only (use abcdefg etc. to choose the pitch, and the same numeric keys to enter the desired length); one with keyboard and MIDI keyboard (use the numeric keys to enter a desired note length, and just press a note on the MIDI keyboard to choose it); and finally, it can also quantisise music as you play it (which is the fastest, but least accurate, method to enter music). Lilypond only allows entering music with the keyboard directly, and then only displays notes after 'compiling' them, so that you cannot see your mistakes and typos until much later. I'm disregarding midi2ly, which converts MIDI files to lilypond input files in a reasonably good way; but Finale has MIDI import functionality as well, I do not consider that to be an 'Input Method' as such. After having entered the music, a musician will want to do something with it. Have the computer play it, for instance, or print it out so that he or she can rehearse it and eventually play it themselves. Lilypond will do neither by itself; however, it can produce postscript, PDF, and DVI files which one can use to print, and/or MIDI files which one can have the computer play. The printouts are great, as I've said before; but playing the MIDI files is another matter entirely. As I've explained earlier, playing MIDI used to be done through hardware. When I still had a working SB16-compatible card, I could play MIDI files on my computer perfectly fine by just using the driver for that sound card. Since I currently depend mostly on ESS1371-compatible cards, that do not havve any hardware MIDI synthesizer, however, that doesn't work. So I have to use software sequencing instead. On Windows, software sequencing is done by the sound card's driver. On Linux, there is no software sequencing being done by any driver, so it all has to be done in userland. In theory, that's just fine. Unfortunately, the implementation sucks. The only software MIDI synthesizer available on Debian is timidity. On a 1.33Ghz processor, it requires approximately 60% of my CPU to play a reasonably easy MIDI file with a polyphony of only some 5 to 10 voices. Complex MIDI files are totally out of the question. And it gets worse; when one runs timidity -iA -Os, it will register itself as an ALSA device capable of playing MIDI, so that ALSA-using applications can play MIDI data by just throwing it to the relevant device. However, this requires far more CPU power, not even being able to play as much as two or three voices at the same time on my same system. If one knows that my last Windows-based system (a Pentium I at 166Mhz) was able to play much more complex MIDI files using the same ESS1371-based sound card just fine, it's not hard to see that timidity really (really) sucks. As said, I probably shouldn't be ranting about this as much as I do, since I don't have the time to invest in making this any better. But if anyone feels inclined to contribute some to Open Source Software, and needs some ideas, these might be interesting things to consider. ¹ I should add that, to my shame, I used an illegal copy of both afore-mentioned programs. I didn't really know any better at the time.

This is the time of year when most Free Software-related conferences in Mexico have their calls for papers. CONSOL's CfP closed two weeks ago (agh, I had to CONSOL's CfP closed two weeks ago (agh, I had to /lists.consol.org.mx/pipermail/consol/2006-May/006443.html">/lists.consol.org.mx/pipermail/consol/2006-May/006443.html">send my proposal by mail, and I do hope it gets in the official program - For sentimental reasons more than anything else ;-) CONSOL is, after all, still my baby!). Yesterday I had to come up with something, as CICOL's deadline was also hanging upon me. Now my attention has been brought towards FSL, for which I still have almost one month to think. And, of course, although at other times of year (but, of course, still clashing with other conferences) we will not have one, but three instances of GULEV this year..
WTF?
Mexico's Free Software community is a small and not too productive one, as most communities in our (culturally defined) continent, Latin America. And yes, conferences are quite fun, it's always nice to go to a nice place and meet your friends. But we must not forget the real motivation for them all: The academic program. We currently have four conferences that try to reach to the same audience (yes, in different places of the country, but all of them with a national scope). And if you compare the list of proposed talks (visible currently for three of them), you will see there is no real difference between the set of talks on them. Please explain me, what kind of incentive does this give to anybody to attend? Just to hang out with the friends, entering a talk here and there?
I ended up submitting the same talks for both CONSOL and CICOL, as running Debconf didn't leave me time to prepare or think over anything - That's not what I like to do, and I hope I can be a bit more creative with the topics for FSL. There is no published criteria yet on what will be the focus for (each of the) GULEV, so I'm not committing yet to them. And yes, being a very active Free Software promoter in my country, I try to be present everywhere - but of course, everything has a limit. I will most probably not skip CONSOL (as it is on the city I live, and it is the one I am most sentimentally attached to) or CICOL (as it is just 1hr south from here)... But I'm still uncertain if I'll be at FSL or any of the GULEVs.
Back on my initial questioning, anyway: Do we need four perfectly equivalent conferences in this country? Besides ego clashes, wouldn't we be best served if we had only one or two big conferences a year?

Debcamp was really stressing - It seemed we would not be able to get things to work for Debconf. And it would suck. I was quite down when I last wrote a blog entry - Not in mine, but in Debconf's. Things looked quite hellish, and I was _very_ annoyed - Well, I must say: Thanks to you all for the support. Mooch's request has been honored extensively, and it does help. Really.
Yesterday we had the Debian Day. About 50 Mexicans showed up, after we had to jump through some hoops with the Oaxtepec management people (thank you, thank you, you are great! Real dedication to your job, to make us feel welcome and important). The talks were interesting and well presented, and the people left happy - and some of them, left quite late. We had presence from at least one national newspaper (La Jornada and a magazine, Software Guru. Good.
Then, during the night, we were flooded by arriving foreigners. Boy, the hacklab was packed! Good thing we now will have both hacklabs running.
I have to thank most than to anybody else to my wife, Gaby a.k.a. Nadezhda - She has done all the ugly paperwork... Without her, we would all not be here. And later, I would probably be sitting in jail or something ;-)
Seems that the bugs are ironed out. Now I'll try to attend the "Sun and Debian: can we be friends?" round table.

Ok, the time has come: Now I work with my 20" fan on. Lucky me, my office has no windows, it's in the middle of the building - A bit cold in the Winter, but that's OK with me... But the people with real windows have been sweating for some weeks already. Well, design details of a 50 year old building which cannot be moved :)
Anyway... For people coming to Debconf: Be prepared for hot weather. April-May is Central Mexico's hottest season. For Mexico City, it means we have reached 30 Celsius, and will probably reach them again a couple of times (this week's forecast says we will be under 28, which is good news)... But for the Oaxtepec region (the closest cities are Cuautla and Yautepec) we are reaching 33-35 Celsius every day.
By May, we will have the first scheduled rains (although this has been a rainy Spring, but still, it's formally the dry season), so I hope it will not be _that_ bad... But be prepared to sweat.

Joey Hess blogs about possible dangerous ways to exploit the daylight savings time. Well, for the tenth year in a row (if I am not mistaken), we central-Mexicans can proudly announce we are GMT-5. When I was a kid, we were always told that daylight savings are a very important way to save energy in non-tropical areas, such as the North-Western states, USA, Canada and Europe. We understood that, as tropical beings, we didn't have to worry about that, as it would have neglegible effects for us.
Ten years (eleven?) ago, this changed, and we became first-class world citizens, together with the emotion of shifting the clock's hands twice a year. Of course, we all did stupid things once or thrice - The first time we got back to GMT-6, I moved to GMT-4 instead. We were laughing at the fools who forgot to move the watch. I went to the movies with Nadezhda, and was confronted by a less-than-amused clerk that had to explain the same to too many people along the day. At least he smiled when he noticed we were stupider than most.
Well, today I am a big fan of daylight savings. I simply like having sunlight up to 20:00, sometimes even 21:00 - But I have reversed the old logic I was taught at school. We Mexicans have very little variation in our clocks - We go from maybe 11 to maybe 13 hours of daylight comparing Summer and Winter. Ok, make it 10 and 14, to make it sound more dramatic. Having the sun raise at 6AM makes sense, no matter what time of year it is. Most electricity is spent in the early night (8-10PM)... So it makes a lot of sense. Even for the people in the USA, maybe even Canada, and most of Europe. But...
Why do Nordic countries adhere to daylight savings? I mean... You vary from 4 to 20 hours of sunlight a day - What difference does one hour make anyway? Why follow the hassle we all regular humans have to go through? I can't imagine people in Narvik and Rovaniemi trying to squeeze that little glimpse of sun they have during the winter, and trying to align their sleeping time to the exact the sun is only half-visible in Summer.