Joe Wikert swears off business books: http://jwikert.typepad.com/the_average_joe/2008/11/business-book-breakdown.html and in the process, he highlights one of the reasons for Squeezed Books to exist: most business books are pretty high on the fluff/content ratio. Even a lot of the good ones which present a noteworthy idea need to pad out those ideas to make a book out of them, as the basic idea can usually be described in a few pages. The part of Squeezed Books that I really hope to get going is the discussion of books, because I think that can add a lot of value for people. Reading a book is part of learning, but you often internalize and consider things more deeply when you actually discuss the ideas in the book, subjecting them to critical examination, and applying them to situations you have experienced. Incidentally, I also rejigged the site's look and feel, using the blueprint CSS 'framework'. I'm not much of a designer, so I have to aim for simple and not unpleasant, rather than beautiful and flashy.

No software is perfect, and most users happen to have some itches they would like to scratch on them. I don’t know anyone who hasn’t thought some day “why can’t that software do <some feature>”. But not everybody is able to scratch these itches. For a starter, most people aren’t developers, or aren’t able to modify source code to reach some known goal, be it fixing a bug or implementing a missing feature. But even when they are able to do so, most applications can’t be fixed or improved easily: most widespread applications are still proprietary software where access to the source code is either impossible or prohibitively expensive. That’s the good thing about open source and free software: you are able to itch these scratches yourself ; and as a free software user and developer, I often do so in the software I use. I must say it’s even frustrating when you are used to this possibility but end up on damn stupid bugs or limitations you can’t fix in proprietary software. I have quite a bunch of such examples, the most recent ones being with VMware ESX, but that’s another story. Mobile phones are everywhere nowadays. In some countries, there are even more mobile phones than people. A huge amount of people are using them daily. Or maybe should I say “endure”. When you go to shop for a laptop, digital camera, or digital portable music player, you can find demonstration models you can fiddle with, see what the user interface looks like, how it behaves, see if whatever feature you like on such devices is present and how easily you can do what you want. With a mobile phone, you don’t have all that (at least in France and Japan, where I experienced this). You’re lucky if one of the sellers owns the exact model you’d like to test and lends it to you for a minute. Most of the time, the “thing” to watch is a plastic model, not even remotely related to the real thing in colour, weight… and obviously, it has as much use as a brick (not even so, actually, as you can’t, for instance, break windows with it). And most of the time, you end up regretting the choice you made, because the UI is so unuseable, or so slow after a while, or so buggy, etc. More and more phones nowadays have multimedia as their main feature. While it can be nice, especially when you see how some are pretty good at it, and when you consider it avoids you to carry both a phone and a multimedia device. Sadly, they usually forget to be good phones, too. Sometimes even, multimedia(-related) features are crippled by the carriers. As an example, my phone, while able to read mp3 music, has been limited by the carrier to refuse to use them as ring tones, while, according to the maker and to various forums, the phone is perfectly able to do so. It’s even worse than that, because even converted as 3gp, which it otherwise allows as ring tones if you download them at a ridiculous price, it still doesn’t allow to put your music as a ring tone. You got it, features in phones are also limited for big money-making. Fortunately, there is a hole in my phone where I can set a 3gp as ring tone if I do it from the music player instead of the file browser. Most articles I read about Android, or the iPhone SDK, relate how they are great opportunities to enable developers to provide nice applications for users, using the provided frameworks. But the thing is : they’re only applications. An application is not the core of the phone. An application won’t take care of ring tones, or vibration types. And that’s what open source in mobile phones should also allow users to do. That’s what it all should be about. As a user and free-software developer, I would like to enhance my phone like I can enhance my laptop. For instance, my phone will only allow crappy polyphonic tones for SMS or e-mail reception. Digital music is only available when you receive a call. Why ? There is obviously nothing preventing digital musing when receiving SMS or e-mail, except a stupid software restriction that could be fixed if the firmware were open-source. Very few phones in France appear to allow japanese input, let alone proper display of japanese characters in e-mail or on the web. My previous phone was able to display japanese correctly. My current phone doesn’t. Neither of them is able to input japanese (which is not unexpected in France, actually). I know the iPhone does both. Anyways, these are informations very hard to get a hand on before buying a model, and something that open-source would allow me to fix. Even better, it would allow me to take the pieces from the asian version of the same (or similar) phone which probably has the functionality. The phone I had when I was living in Japan had a nice feature that I haven’t seen in any phone in France (but again, this kind of information is very hard to get): different vibration types. For example, you had a vibration type making short vibrations, another one long vibrations, yet another one 3 short vibrations, a short pause, then 3 short vibrations again, etc. This is very useful when you disable ring tones during a meeting or some other occasions where you don’t want to bother the people around you with your phone ringing: depending on how the phone vibrates, you know whether you have to take the call or can ignore it, or if it’s only an e-mail, without taking a look at the phone. Again, an open-source firmware would allow me to implement this. I’m sad so much of what open-source can bring to mobile phones is so badly publicized.

In the productive procrastination department: I repackaged rcs using debhelper (it feels like the future) and while I was at it, I implemented MadCoder's git maintenance scheme where changes from upstream are maintained in a rebased integration branch and serialized as patches in the Debian branch (master in my case) using git format-patch. It's pretty nice:

• I can use native Git commands to edit/refresh patches, which beats quilt any day;
• Changes to upstream are visible both as a git branch and as separated, commented patches in the Debian branch;
• If necessary (e.g. in case of NMU), outside contributors can just dump a -p1 patch in debian/patches and be done with it.

Of course this is a very low-maintenance package (the last upstream release was 13 years ago) so it doesn't matter very much which maintenance strategy it uses, but after implementing it I'm pretty confident that it works and I might switch my other packages to it.

If you're interested in knowing more about clever ways to use modern VCS for packaging, you may want to join the vcs-pkg mailing-list.

Recently I suggested to some students that they could use the Gnu Linear Programming Toolkit from C++. Shortly afterwards I thought I had better verify that I had not just sent people on a hopeless mission. To test things out, I decided to try using GLPK as part of an ongoing project with Lars Schewe The basic idea of this example is to use glpk to solve an integer program with row generation. The main hurdle (assuming you want to actually write object oriented c++) is how to make the glpk callback work in an object oriented way. Luckily glpk provides a pointer "info" that can be passed to the solver, and which is passed back to the callback routine. This can be used to keep track of what object is involved. Here is the class header

#ifndef GLPSOL_HH
#define GLPSOL_HH
#include "LP.hh"
#include "Vektor.hh"
#include "glpk.h"
#include "combinat.hh"
namespace mpc  
  class  GLPSol : public LP  
  private:
    glp_iocp parm;
    static Vektor<double> get_primal_sol(glp_prob *prob);
    static void callback(glp_tree *tree, void *info);
    static int output_handler(void *info, const char *s);
  protected:
    glp_prob *root;
  public:
    GLPSol(int columns);
    ~GLPSol()  ;
    virtual void rowgen(const Vektor<double> &candidate)  ;
    bool solve();
    bool add(const LinearConstraint &cnst);
   ;
 
#endif

The class LP is just an abstract base class (like an interface for java-heads) defining the add method. The method rowgen is virtual because it is intended to be overridden by a subclass if row generation is actually required. By default it does nothing. Notice that the callback method here is static; that means it is essentially a C function with a funny name. This will be the function that glpk calls when it wants from help.

#include <assert.h>
#include "GLPSol.hh"
#include "debug.hh"
namespace mpc 
  GLPSol::GLPSol(int columns)  
    // redirect logging to my handler
    glp_term_hook(output_handler,NULL);
    // make an LP problem
    root=glp_create_prob();
    glp_add_cols(root,columns);
    // all of my variables are binary, my objective function is always the same
    //  your milage may vary
    for (int j=1; j<=columns; j++) 
      glp_set_obj_coef(root,j,1.0);
      glp_set_col_kind(root,j,GLP_BV);
     
    glp_init_iocp(&parm);
    // here is the interesting bit; we pass the address of the current object
    // into glpk along with the callback function
    parm.cb_func=GLPSol::callback;
    parm.cb_info=this;
   
  int GLPSol::output_handler(void *info, const char *s) 
    DEBUG(1) << s;
    return 1;
   
  Vektor<double> GLPSol::get_primal_sol(glp_prob *prob) 
    Vektor<double> sol;
    assert(prob);
    for (int i=1; i<=glp_get_num_cols(prob); i++) 
      sol[i]=glp_get_col_prim(prob,i);
     
    return sol;
   
  // the callback function just figures out what object called glpk and forwards
  // the call. I happen to decode the solution into a more convenient form, but 
  // you can do what you like
  void GLPSol::callback(glp_tree *tree, void *info) 
    GLPSol *obj=(GLPSol *)info;
    assert(obj);
    switch(glp_ios_reason(tree)) 
    case GLP_IROWGEN:
      obj->rowgen(get_primal_sol(glp_ios_get_prob(tree)));
      break;
    default:
      break;
     
   
  bool GLPSol::solve(void)    
    int ret=glp_simplex(root,NULL);
    if (ret==0) 
      ret=glp_intopt(root,&parm);
    if (ret==0)
      return (glp_mip_status(root)==GLP_OPT);
    else
      return false;
   
  bool GLPSol::add(const LinearConstraint&cnst) 
    int next_row=glp_add_rows(root,1);
    // for mysterious reasons, glpk wants to index from 1
    int indices[cnst.size()+1];
    double coeff[cnst.size()+1];
    DEBUG(3) << "adding " << cnst << std::endl;
    int j=1;
    for (LinearConstraint::const_iterator p=cnst.begin();
         p!=cnst.end(); p++) 
      indices[j]=p->first;
      coeff[j]=(double)p->second;
      j++;
     
    int gtype=0;
    switch(cnst.type()) 
    case LIN_LEQ:
      gtype=GLP_UP;
      break;
    case LIN_GEQ:
      gtype=GLP_LO;
      break;
    default:
      gtype=GLP_FX;
     
    glp_set_row_bnds(root,next_row,gtype,       
                       (double)cnst.rhs(),(double)cnst.rhs());
    glp_set_mat_row(root,
                    next_row,
                    cnst.size(),
                    indices,
                    coeff);
    return true;
   
 

All this is a big waste of effort unless we actually do some row generation. I'm not especially proud of the crude rounding I do here, but it shows how to do it, and it does, eventually solve problems.

#include "OMGLPSol.hh"
#include "DualGraph.hh"
#include "CutIterator.hh"
#include "IntSet.hh"
namespace mpc 
  void OMGLPSol::rowgen(const Vektor<double>&candidate) 
    if (diameter<=0) 
      DEBUG(1) << "no path constraints to generate" << std::endl;
      return;
     
    DEBUG(3) << "Generating paths for " << candidate << std::endl;
  // this looks like a crude hack, which it is, but motivated by the
  // following: the boundary complex is determined only by the signs
  // of the bases, which we here represent as 0 for - and 1 for +
    Chirotope chi(*this);
    for (Vektor<double>::const_iterator p=candidate.begin();
         p!=candidate.end(); p++) 
      if (p->second > 0.5)  
        chi[p->first]=SIGN_POS;
        else  
        chi[p->first]=SIGN_NEG;
       
     
    BoundaryComplex bc(chi);
    DEBUG(3) << chi;
    DualGraph dg(bc);
    CutIterator pathins(*this,candidate);
    int paths_found=
      dg.all_paths(pathins,
                   IntSet::lex_set(elements(),rank()-1,source_facet),
                   IntSet::lex_set(elements(),rank()-1,sink_facet),
                   diameter-1);
    DEBUG(1) << "row generation found " << paths_found << " realized paths\n";
    DEBUG(1) << "effective cuts: " << pathins.effective() << std::endl;
   
  void OMGLPSol::get_solution(Chirotope &chi)  
    int nv=glp_get_num_cols(root);
    for(int i=1;i<=nv;++i)  
      int val=glp_mip_col_val(root,i);
      chi[i]=(val==0 ? SIGN_NEG : SIGN_POS);
     
   
 

So ignore the problem specific way I generate constraints, the key remaining piece of code is CutIterator which filters the generated constraints to make sure they actually cut off the candidate solution. This is crucial, because row generation must not add constraints in the case that it cannot improve the solution, because glpk assumes that if the user is generating cuts, the solver doesn't have to.

#ifndef PATH_CONSTRAINT_ITERATOR_HH
#define PATH_CONSTRAINT_ITERATOR_HH
#include "PathConstraint.hh"
#include "CNF.hh"
namespace mpc  
  class CutIterator : public std::iterator<std::output_iterator_tag,
                                                      void,
                                                      void,
                                                      void,
                                                      void> 
  private:
    LP& _list;
    Vektor<double> _sol;
    std::size_t _pcount;
    std::size_t _ccount;
  public:
    CutIterator (LP& list, const Vektor<double>& sol) : _list(list),_sol(sol), _pcount(0), _ccount(0)  
    CutIterator& operator=(const Path& p)  
      PathConstraint pc(p);
      _ccount+=pc.appendTo(_list,&_sol);
      _pcount++;
      if (_pcount %10000==0)  
        DEBUG(1) << _pcount << " paths generated" << std::endl;
       
      return *this;
     
    CutIterator& operator*()  return *this; 
    CutIterator& operator++()  return *this; 
    CutIterator& operator++(int)  return *this; 
    int effective()   return _ccount;  ;
   ;
 
#endif

Oh heck, another level of detail; the actual filtering actually happens in the appendTo method the PathConstraint class. This is just computing the dot product of two vectors. I would leave it as an exercise to the readier, but remember some fuzz is neccesary to to these kinds of comparisons with floating point numbers. Eventually, the decision is made by the following feasible method of the LinearConstraint class.

 bool feasible(const
Vektor<double> & x)  double sum=0; for (const_iterator
p=begin();p!=end(); p++)  sum+= p->second*x.at(p->first);  
      switch (type()) 
      case LIN_LEQ:
        return (sum <= _rhs+epsilon);
      case LIN_GEQ:
        return (sum >= _rhs-epsilon);
    default:
      return (sum <= _rhs+epsilon) &&
        (sum >= _rhs-epsilon);
       
     

Today again somebody commented on probably simplest patch I ever attempted contribute to some free software. And it memorized me the funny fact that this simple change lies for five years in bugtracker without single comment from developers. Only occasionally some random hacker founds it and ask why such simple issue has not yet been solved. Latest change in bug adds flag, that this is still broken in all recent Python versions including 3.0 :-).

I’m getting increasingly annoyed by the state of some aspects of hardware support in Linux. My laptop (old Dell Latitude D610, Intel-based with ATI graphics) used to suspend/resume correctly with Linux 2.6.24 (ie, > 95% success rate). Later changes made the success rate drop significantly, and added a problem with kacpid taking 100% CPU because of an interrupt storm. And now, with 2.6.28-rc6, it’s completely broken. (partially documented in bug 11563, but I admit I gave up on this bug, because I’m going to change my laptop soon). My desktop used to wake-on-lan correctly with 2.6.24 (but required some hacks, because it wouldn’t wake up if the NIC was DOWNed before shutdown), but changes in the r8169 driver broke it. (documented in bug 9512). As a result, I’m forced to run old kernel versions on the two systems I have at home. I can understand that those issues aren’t considered high priority (not everybody use WoL), but the fact that in both cases, they are regressions, worries me a bit. How many things are routinely broken during each kernel release cycle? Hardware support is difficult, of course, but are we really doing everything we could to make it suck less? Some things I really would like to see:

• Distro packages for development kernel versions. For Debian, there’s this repository, but it doesn’t always contain the latest kernel versions. Maybe that’s something that should be moved to a kernel.org umbrella and generalized to all distributions, to provide beta-testers with easy-to-install packages. git bisect isn’t that user-friendly.
• Funding for driver developers to buy specific hardware. Many drivers cover a wide range of chips/cards, and developers often only have on a small subset of them, making it difficult to debug issues specific to one chip.
• Better/updated bugzilla on kernel.org. Many bug logs are totally confusing, and cover different issues. They could maybe benefit from new or specifically developed bugzilla features (and more bug triagers, of course).

Can anyone recommend me (erich AT debian DOT org) a good Java visualization library? Open source only, please.I've looked at a few such as prefuse, but usually they all are too high-level for me, providing a whole UI and data model and parsing and ...What I'm interested in is:

• open source java library
• drawing handling, to both screen and file output (vector graphics is a must)
• view handling, that is zooming, panning, rotation (when in 3D projection)
• can interface my data structures, without me having to transform them into the libraries own data format
• Allows me to plot basic things such as points (with icons), lines, arrows, circles, ellipses without having to think about the view handling and projections myself
• Bonus: tooltip-like actions to show extra information about the data objects visualized

Any recommendations?[Update: I was pointed out processing.org which looks interesting but way too much about writing complex animations instead of just allowing me to visualize the data I computed. I also discovered Apache Batik which probably covers 90% of what I need, given that SVG allows for many transformations.][Update #2: VTK looks good, except that I don't want to introduce a non-Java dependency just for the visualizations. Otherwise I would also be considering Gnuplot. Which is also why some of the other suggestions I received aren't too convincing: I want to visualize data points, lines, vectors primarily; a full 3D engine isn't too useful for that (especially since these are typically triangle-oriented)]

I love it when a lack-of-humor and lack-of-appropriateness-originated flamewar causes somebody to point me towards a very nice display of intelligent humor. Specially when it is so close to me, to my roots, to my family and my personal history. FWIW, for several years, while I was a BBS user, I used WereWolf as my nickname. Great thanks to Frank K ster - and, of course, to Christian Morgenstern.

The Werewolf - English translation by Alexander Gross A Werewolf, troubled by his name,
Left wife and brood one night and came
To a hidden graveyard to enlist
The aid of a long-dead philologist. "Oh sage, wake up, please don't berate me,"
He howled sadly, "Just conjugate me."
The seer arose a bit unsteady
Yawned twice, wheezed once, and then was ready. "Well, 'Werewolf' is your plural past,
While 'Waswolf' is singularly cast:
There's 'Amwolf' too, the present tense,
And 'Iswolf,' 'Arewolf' in this same sense." "I know that--I'm no mental cripple--
The future form and participle
Are what I crave," the beast replied.
The scholar paused--again he tried: "A 'Will-be-wolf?' It's just too long:
'Shall-be-wolf?' 'Has-been-wolf?' Utterly wrong!
Such words are wounds beyond all suture--
I'm sorry, but you have no future." The Werewolf knew better--his sons still slept
At home, and homewards now he crept,
Happy, humble, without apology
For such folly of philology.

So today, I happen to be looking at wikis for two small to mid-sized public proojects (MoinMoin and DokuWiki look like frontrunners right now — any suggestions?) Recently, I’ve also looked at blog and CMS software, and a host of other web apps. It’s as if these people have learned nothing about good software practices over the last 20 years. Warning: Rant Ahead So how many of you have been here before? You download WebApp X. It tells you to cd to your DocumentRoot and unzip/untar it there. At this point, most of them will tell you to chmod -R 777 the install directory. Some of the better ones, such as WordPress, will tell you to chmod it 777, or if that makes you nervous, to instead chown it to the user that your webserver runs as. It is at this point that you realize that the Java-based programs ship with their own webserver that takes 2 minutes to load and uses 2GB of RAM, while the PHP-based programs want you to give them 32MB RAM per process, and probably modify your global PHP settings in a way that breaks some other PHP web app you’re already using. As if that isn’t enough to scare you off, generally speaking, config files — including passwords to databases — are stored in the same directory, along with .htaccess files. Many of these programs are also downloading and updating plugins over the Internet, usually without any kind of cryptographic authentication, and overwriting their own program files in the process. Oh, and this is a class of app that is notorious for security problems to start with, and makes your server known to billions of people via search engines. Absolutely no opportunity for trouble here, of course! That sentence was dripping with sarcasm, in case you didn’t get it. It also makes it almost impossible for people such as Debian maintainers to package up some webapps (such as just about every single one that uses Ruby on Rails) because there is just no sane way to make it behave with respect to the Filesystem Hierarchy Standard. I’d love to see web app developers do a few simple things:

1. Separate code from data
2. Separate code from configuration
3. Separate all of the above from the DocumentRoot to the greatest extent possible

I realize that some of this is purportedly to make things easier to install when you have FTP access only. But to me it seems just really poor design. I’ve written webapps, and it’s not that hard to do this part right. Plus, doing the above right means that I no longer have to do something like use git on my WordPress installations because it’s too much of a hassle to apply security and plugin updates on all three separate ones otherwise.

The Timeless Way of Building: Diagnosis and Repair Architect Christopher Alexander's A Pattern Language is well known among programmers as the inspiration for the Design Patterns school of thought, but for some reason his other books are less widely read. My mother and father are both architects—"real" ones, not "software architects." :) My own amateur interest in the subject led me to read several of Alexander's books over the past couple of years. The Timeless Way of Building is the first volume of an open-ended series. (A Pattern Language is the second.) It is in this book that Alexander first lays out the idea of a pattern language. More importantly, he explains an entire theory and practice of design and construction, of which the pattern language is only one piece. Another piece of the Timeless Way is the practice of diagnosis and repair. Rather than a detailed plan of future projects, Alexander prefers to maintain a diagnosis of current problems. Each new project must be targeted at fixing these existing problem in the system: "At every moment we use the defects of the present state as the starting point for the definition of the new state" (p. 485). Alexander's goal is to create a type of spontaneous growth and order that is possible when change is incremental and decision-making authority is decentralized. Alexander was hired to produce a new type of master plan for the University of Oregon campus. The result was published as the third volume in the "Timeless Way" series: The Oregon Experiment. In it, he writes again about diagnosis and repair:

It is still not clear where global order will come from, without a master plan.… How is the problem solved in an organism? Essentially, the problem is solved by a process of diagnosis and local repair.… The master plan tells us what is right for the future. The diagnosis tells us what is wrong for the present. (p. 146–148)

In software, the same problems and conclusions have led to "agile" processes, which emphasize incremental change and flexible planning. But I haven't seen any software companies adopt a consistent practice of "diagnosis"—keeping track of what's wrong or unsatisfactory with the current system. This extends beyond defect tracking; it should include a constantly updated list of code that, although it works, is hard to understand, difficult to change, or otherwise likely to cause problems. (This should be easy to generate—every programmer knows certain parts of their code base that they dread working on for one reason or another.) This knowledge can then guide new development to include "repair" and address such problems before they become defects. I've applied this on a small scale to my own work, and now I wish I had used it at Amazon, where my team spent much more time maintaining and improving old code than writing new code.

It's sad that today in Planet Debian we have hit an Eurocentric geographically discriminating meme. Particularly, one I'd love to take part of. Well, at least I can assure you we have reached the usual low temperature of 2 Celsius in Mexico City... As always, people say it's so cold that this year we _will_ get snow. And as always, I'm sure it's just wishful thinking ;-)
So, even with Marcelo's frozen Z calo live again for this winter, I can only reinforce our tropical paradise stereotypes by reminding you that this is less than 500Km away from home - All year 'round:

This might be a good message to write in Spanish... But then again, a long time ago I decided this is an English-posting site. So be it, I'll only have to give more background information.
This day marks the date when, 98 years ago, Francisco I. Madero started the Mexican Revolution - About a decade of unrest, civil war and ideologies. The revolution is what created the violent, uncivil image of the Mexican, which accompanied us for long years in many foreigners' minds. The revolution brought to an end 30 years of a single-man rule, the Porfiriato. But that's only the major symptom - The Revolution had many, many other consequences. About one million (out of a 10 million population) people died. There was a very significative rearrangement of the society, a rearrangement that took about half a century to settle. But I won't write more background - You can always ask the wikipedia about our Revolution.
The reason I am posting this is that, as it usually happens in this time of year, several so-called analysts in the media have started asking, was the Revolution really worth it? Did it change anything at all? Did the Revolution in the end win, or was it defeated from within? Should we still celebrate it?
And there are, yes, reasons to doubt it. Renato Leduc, at the same time a great journalist and a delicious poet, says it as many - while at the same time, as nobody else: Tiempos en que era Dios omnipotente / y el se or Don Porfirio presidente / Tiempos, ay! tan iguales al presente, or ya se est n muriendo todos / Jes s qu desilusi n...! / se est volviendo gobierno / Ay dios...! La revoluci n.
Anyway... Our media overlords insist on us forgetting the struggles and the real changes that came from them, on rewriting the history... Probably they will push us later on to have the cristeros as the real fathers of the Nation?
Even if so many bits of reality didn't change after Porfirio Diaz's regime fell in 1910, I find it insulting to think that even 70 years of PRI -with very sharp differences between periods, with huge differences between the PRI-born governments- are comparable to 30 years of a one-man rule; even with brutal repressions such as the dirty war against so many subversive movements in the 50s-80s (as officially There Was No Armed Struggle Anymore, just some pesky communist subversives), it cannot be compared to the Porfirian Peace (ask Cananea and R o Blanco). Today we might have a shameful concentration of money and power in very few hands (including the world's richest man), but it certainly does not reach the point of 1910 where most of the Mexican soil was owned by less than 30 families, with latifundios as big as many states...
Anyway - So far, nothing new - just bits I heard here and there, and my reactions to them. But this morning, around 8:25, I tuned in to Noticias IMER, the news program of one of the few public, non-gubernamental, independent radio stations. An interview was under way, but I could not get the interviewed person's name (I guess, a historian - will write to ask for his data). His comments were very interesting, and very worth echoing. I'll try not to distort him.
The Revolution started off very organized, and with a very simple goal: Get Porfirio Diaz out, and call for real federal elections. Sufragio efectivo, no reelecci n. Of course, the fight was very short, and Madero became the president, with an overwhelming majority. Of course, also, the reactionary sectors set up a coup and killed Madero. Victoriano Huerta seized the power - and that's where the real revolution really began. Groups all over the country (some of which were at unrest since Madero, as they were not seeing the changes they needed - changes that would bring an end to the huge class differences and disrespect to the native Mexican population) rose in arms, and forced Huerta into exile. Then, they battled each other for many more years. It became known as la bola - When somebody joined the revolutionary forces, people said he went to fight with the crowd. But, inside the crowd, there were very different points of view. No, Carranza, Villa and Zapata (the foremost leaders in the hardest part of the fight) were not power-hungry barbarians - much to the contrary. They had very full, very complex views of the problem and possible solutions. I won't delve much into them, also, as I'm not an expert...
Villa and Zapata had the most compatible approaches, seeking an aggresive land redistribution, a communal property system (closest to most of the indigenous population's roots, what we would now call usos y costumbres). For the government, both favored going towards a Europe-like parliamentary system, where the parliament were the real force, and the president (or prime minister or whatever) would only be the designated person to implement the parliament's decision. Both Villa and Zapata feared the evil stemming from the unlimited power that the Presidential Chair symbolized (Fui soldado de Francisco Villa / de aquel hombre de fama mundial, / que aunque estuvo sentado en la silla / no envidiaba la presidencial). They met at the Aguascalientes convention, and were quite close to each other - but were defeated by the superior Venustiano Carranza (Constitucionalista) army.
Carranza, although vilified for his corruption (nowadays, carrancear is still a synonim for stealing), had an opposite view - also originating from a very deep analysis. Carranza saw that what brought down Madero was, in the end, the lack of power of the President to rule the country without support from the legislative power. So, he pushed a political program making the President the strongest man in Mexico. He and his people wrote and passed the 1917 Constitution, valid today. This constitution goes to great lengths pushing revolutionary ideals - Land and wealth redistribution, universal and free education, keeps a complete separation between state and church, ensures state control over strategic areas... The 1917 constitution is one of our history's greatest achievements.
But, of course, it is not perfect - it paved the way for a hegemonic party controlling the real power behind it all. PRI started as a very heterogeneous mixture of the whole revolutionary family, but slowly became a bureaucratic, stagnated monolith.
And in a somehow ironic twist of destiny, the forces that today push for deepest changes, and precisely in the same direction that Villa and Zapata wished, are... Ej rcito Zapatista de Liberaci n Nacional (EZLN) and Frente Popular Francisco Villa (FPFV). EZLN is far more successful and advanced in its social experiment. Again, I won't comment further in what I don't really understand.
As a last point, the commenter I'm quoting (and whose name I must get, to update this post!), said that practically in every country that has transited from any sort of dictatorship towards a more-or-less believable democracy (say, everywhere in South America, or Spain, or Eastern Europe, or...), one of the first steps has been to update or replace the constitution with a new one, preventing the mistakes overlooked by the previous one from being reinstated. In our country, we have long heard about the "Reforma del Estado", a very nice-sounding-term which nobody believes in. After the 2006 electoral mess (no matter who won in the end, everybody will agree it was a mess that should be prevented from happening again, we had high hopes of real changes being introduced. A parliamentary, or at least semi-presidentialist regime was strongly suggested as a way forward. Changing the electoral system towards having second-rounds if needed. _anything!_ But no, we were stuck with... The same as always.
So, did the Revolution win or lose? It is clear to me. It won, and it really shaped -for better- what would happen in the next 100 years. However, in a century, we have been able to twist the law to make it turn against itself. I have to agree with my EZLN-minded friends (I sympathize with EZLN's general goals, but don't think its way forward is the right way to go): Pushing the change from within the government is just wishful thinking, but a strong delusion. However, is there a way to push our country forward without repeating a violent cycle? I really hope so. Our current situation is simply pathetic.
I lack a good closing for this post... So I'll let good old Jefe Pluma Blanca, Renato Leduc, do it for me.
Tiempos de Pancho Villa
y de la guerra de mentadas y tiros en la sierra.
Tiempos de fe
no en Dios sino en la tierra Por el cerro de la Pila
fueron entrando a Torre n
mi general Pancho Villa
y atr s la revoluci n...
Ay jijos...! ya se nos hizo
cu nto diablo bigot n... Ya viene Toribio Ortega
subiendo y bajando cerros
y no te enredes ni enga es
que ah anda Pablito Se ez
haciendo ladrar los perros. Cu nto usurero barb n...!
Ay jijos... c mo les vuela
de la levita el fald n...!
Ay jijos... ya se nos hizo:
triunf la revoluci n...! Tenemos camino andado...
No hay que juntarse con rotos
siempre te juegan traici n
ya Madero est vengado
ya muri la usurpaci n. En su caballo retinto
lleg Emiliano Zapata
bonita su silla charra
y sus botones de plata
pero mucho m s bonito
su famoso Plan de Ayala... Este gallo es de navaja
y no es gallo de espol n
si quieres tierra trabaja
trabaja no seas huev n... Ya lleg don Venustiano
con sus anteojos oscuros
y Villa y Zapata gritan:
No s que tengo en los ojos...
porque ya en Pablo Gonz lez
se vislumbra la traici n
Ay reata no te revientes
que es el ltimo jal n...! ya se est n muriendo todos
Jes s qu desilusi n...!
se est volviendo gobierno
Ay dios...! La revoluci n.

I am a bit of a bookworm, so I could not resist this meme:

• Grab the nearest book.
• Open it to page 56.
• Find the fifth sentence.
• Post the text of the sentence in your journal along with these instructions.
• Don't dig for your favorite book, the cool book, or the intellectual one: pick the CLOSEST.

The book is actually a Lithuanian translation, but I'll translate the sentence into English for you: After entering the palace, he seduced the king's wife, killed the king with her help and seized his throne. Can you guess which book the sentence is from?

It is often argued that companies have to work with the FOSS community and there are good reasons for doing so. I've tried to collect a number of case stories of good and bad community interaction that may help as a starting point for further exploration of this topic:

• NVidia is probably the best example of a company that is not interested in providing open source drivers for their graphics chips. There are lots of folks who won't buy hardware with NVidia chips for this reason. Intel is the number 1 choice at the moment because they work closely with the community. Related to this, the Linux Foundation and kernel community released a statement regarding open drivers.
• When Sun finally made Java available as open source, they argued that it would help inclusion and distribution of Java (e.g. inclusion into Debian). Sun also felt that the GPL provides the strongest protection "against misbehaviour by monopolists in the Java platform".
• The Novell/Microsoft deal was not perceived well by the community, which led to web sites like http://boycottnovell.com
• Nokia recently had an insightful blog posting about the problems when nobody knows about the open source contributions you make: for example, you cannot influence decisions in a project as easily.
• Sun is often criticized for dominating all open source projects they run. They can be used as a good example that you have to give up some control in order to get outside participation.
• The fact that Xen is not in the mainline kernel is a key reason why a number of companies (e.g. IBM, Red Hat) are looking at KVM (which is in the mainline kernel and actively developed in the community). In fact, "looking" is probably not the best word. IBM is actively working on KVM to make it a viable solution and Red Hat recently acquired Qumranet, the company behind KVM.
• Oracle got fairly bad press for copying the Red Hat distribution and changing Red Hat to Oracle, without engaging in the Red Hat community.
• There's a paper that looks at "empirical evidence on the incentives of firms that engage in OS activities." They look at 146 Italian companies supplying open source solutions, but unfortunately the study doesn't include any major company.

Can you think of other examples? (Originally published on FOSSBazaar where comments are possible)

I just read the news that PC Magazine is being canceled. It’s not exactly a shock, given the state of technical magazines right now. I haven’t read one of those in years, since they turned to be more of a consumer than a technical publication. But I hope I am not the only one out there that remembers PC Magazine from the mid to late 1980s. I had two favorite parts in each issue: the programming example, and the “Abort, Retry, Fail” page at the back of the magazine. The programming example was usually some sort of DOS (or, on occasion, OS/2) utility. It was usually written in assembly, and would be accompanied by a BASIC program you could type in to get the resulting binary, as assemblers weren’t readily available. The BASIC program was line after line of decimal numbers that would decode them and write out the resulting binary — sort of a primitive uuencode for paper. Trying to type those in gave me some serious eyestrain on more than one occasion. By now, I forget what most of those utilities did, but I remember one: BatchMan. It was a collection of tools for use in DOS batch files, and could do things like display output in color or even — yes — play monophonic music. It came with an example that displayed some lyrics about batch programming on-screen, set to what I later realized was the Batman theme. Geek nirvana, right? But Batchman was too big to publish the source code, or the BASIC decoder, in print. It might have been one of those things that eventually led me to a CompuServe account. PC Magazine had some deal with CompuServe that you could get their utilities for free, or reduced cost — I forget. CompuServe was probably where I sent my first email, from my account which was 71510,1421 — comma and all. In later years, you could pay a small fee to send email to the Internet, and I had the amazingly attractive email address of 71510.1421@cis.compuserve.com. Take that, gmail. PC Magazine eventually stopped running utilities that taught people about assembly or batch programming and shifted more to the genre of Windows screensavers. They stopped their articles about how hard disks work and what SCSI is all about, and instead have cover stories like “Vista made easy!” I am, sadly, not making this up. Gone are the days of investigating alternative operating systems like OS/2. It appears that “Abort, Retry, Fail” is gone, too. It was a one-page thing at the back of each magazine that featured braindead error messages and funny stories about people that did things like FAX an image of a floppy disk to a remote office — before such stories were cliche. Sort of like DailyWTF these days. The sad truth is that the people that would FAX an image of a floppy are probably the ones that are reading PC Magazine today. I still have a bunch of PC Magazine issues — the good ones — in my parents’ basement. I also still have my floppies with the utilities on them somewhere. One day, when I get some time — I’m estimating this will be about when Jacob goes to college — I’ll go back and take another look at them.

As I have reported lately I obtained a Nikon D90 DSLR some weeks ago. Gphoto2 (and other application depending on its functionality like digikam) didn't recognized the D90 in PTP mode and the camera can't be configured yet to offer the SD card as a mass storage device.

In the meantime I found out that the D90 does work with gphoto2 in generic PTP mode - at least this is with Ubuntu Intrepid on my x86 laptop while Debian Sid on my G4 PowerPC fails to detect the D90. It detects the camera, the pictures, loads some 1 or 2 thumbs and hangs.
So, I don't know whether there are some differences between Intrepid and Sid (gphoto2 is the same version as reported by dpkg - with the exception of the "ubuntu" version string in Intrepid) or a PPC vs x86 issue - or maybe a kernel issue as this is different between those two machines as well.

This is just a quick note, mostly for myself. I'll try to get more details within the next days and file a bugreport. But if you, dear lazyweb, have some additional pointers for me, I'd appreciate those! :-)

I started building the Debian archive with GCC 4.4 ten days ago to report build errors. I've completed the archive build now and reported about 220 bugs (the majority with patches). There are roughly 30 build failures left that I haven't analyzed yet. There are also about 35 packages that fail because the boost headers don't work with GCC 4.4. I'll try to build them when the boost headers get fixed. The majority of GCC 4.4 build errors are trivial. The large majority of failures is because of missing #include statements. There are also about 20 build errors because of improved preprocessor checks. I'll try to do another archive build when the gcc-4.4 package is in Debian.

One month with Emacs and counting - Part 2 A while ago I've blogged about my switch from Vim to Emacs, promising a blog post series, quite a mouthful nevertheless, it's time to continue the series. The first part was about why I think that nowadays Emacs is ready to be switching to. This second part is about flawed Vim design choices which substantially contributed to my choice. (Of course all this post is under a IMO-/rant-disclaimer, it can't be otherwise, so take it cum grano salis) Flawed Vim design choices Vim started as a wonderful editor, following the path of Vi, which in turn has got right a good deal of design choices. One is the often debated modality. In spite of being a HCI PITA in general, modality is not a problem at all for software you are using every single day (and the editor is the 2nd program I use the most, with the terminal being the 1st), because you learn it as a habit. In the case of Vim, modality is good because it let you use powerful yet simple motions in command mode, which can be easily combined with operator-pending commands. This can be considered yet another incarnation of the UNIX philosophy, casted inside the editor itself. ... which brings us to the good old joke which describes Emacs as a great operating system, lacking only a decent editor. In fact, Vim is no longer the nice Unix philosophy player which it used to be, and Emacs plays much more nicely with external tools than Vim. As arguments, let's consider a few (not so) recent Vim evolutions:

• Spell checking. Starting with version 7, Vim has got support for on-the-fly spell-checking of text buffers. It is a super-nice feature, which I've advertised in the past, because spell checking is needed in many tasks we daily do with editors (mail/doc writing, code commenting), and having a single interface to do it comes handy. Unfortunately, how that is implemented in Vim is definitely not along the lines of the UNIX philosophy. We have countless different FOOspell implementations whereas Vim implemented yet another one, without relying on any pre-existing implementation. Even more so, the file format of spell files is basically ad-hoc, and not sharable with other tools. This is already a PITA for packaging (let's add to Debian another 20 binary packages vim-spellfiles-FOO), but is even worst than that: the spell files must be generated in ad-hoc ways which are seriously prone to failures (guess why in Debian we don't have yet the vim-spellfiles-FOO packages which used to exist in experimental a long time ago?). What would have been the UNIX-friendly way of achieving the same result? Well, obviously spawning FOOspell and interact with its process from the editor. Keep that in mind.
• Internal grep. A feature of Vim I've always loved is :grep (yet another instance of quick-fixing, which is also used for jumping to compile-time errors). In its original incarnation it was as simple as invoking grep and parse its output. KISS. Then, Vim started to have a problem: grep -r can take ages and in the meantime the editor was stuck. Hence, starting with Vim 7, vimgrep has born: an internal re-implementation of grep. OK, it is more portable (but how many of us do care? on how many system you use you are missing grep? damn, I used to install it also on Windoze!), and the editor retain control. Control that is exploited just to show a nice progress bar of what is being scanned ..., while the editor is still stuck. Well, to me it looks like the problem would have been solved much more nicely by adding the ability to interact with an external process (deja vu?). That process can then be grep -r. Full stop.
• Lack of debugging support (on purpose). Long standing missing feature of Vim: you can not "easily" drive a debugger from Vim, because a firm choice in Vim is to ... (OK, I confess, I'm starting to beat a dead horse) ... not have support for interaction with external processes. I found such a choice quite dumb: to me it is evident that it induces a trade-off between being feature-complete wrt programmer needs (as available external tools get available to face those needs) and not "re-implementing the wheel" inside the editor. Going back to the lack of debugging support in Vim, that has spawned projects like GdbVim, Clewn, Bram's Agide, and my own tiny teeny incarnation specific to ocamldebug called WOWcamldebug. Every single project of that list acts as an intermediary between Vim and an external process (a debugger of some sort), whereas that could have been implemented by an editor plugin, provided that the editor offer, guess what, support for interaction with external processes.
• Top-level. Similar to the debugging support issue, there is the interpreter issue, namely how to evaluate "phrases" of your interpreted language of choice directly from the editor. Nowadays a lot of languages have the so called top-levels which evaluate language phrases interactively (Python, Ruby, OCaml, many Lisps, ...) and show evaluation results. That ability can speed up testing considerably, but can become cumbersome to use for large code snippets without editor support (good luck with copy and paste). Yes, Vim has support for that, but the implementation choice is close to be ridicolous: only if you have linked Vim together the interpreted for a given language, then you will be able to interactive evaluate phrases of that language. What if you program in Python, Ruby, and Perl? Well, you need to link all of them. What if you also program in OCaml? Then you're screwed, because Vim currently does not support linking with it. (Yes, I know that there are other reasons for doing that linking, they are discussed below.) Do I need to tell you which feature will be enough to address top-level support? interaction with extern.. OK, I'll drop it, you know that already.

Well, I acknowledge that Emacs got this choice right, and that it's an important one: Emacs supports interaction with external processes, and plugin authors have been happy to exploit it to create really cool stuff (sticking to the UNIX philosophy). Please welcome: Flyspell, M-x grep (shameless smartass plug: same number of keystroke of :grep), Grand Unified Debugger, a sampling of language-specific major modes with top-level support. (But I recommend having a look at least once at the coolness of other stuff built-on top of external process support, like Flymake, mentioned by dancer not a long ago.)

• Its own scripting language. I've bored you enough with the external process topic, hence here is the second one: the saga of Vim and its scripting language, i.e., the programming language using which you can customize the editor. Note that the choice of scripting language impacts on 2 different targets: final users in need of fire and forget automations (when they start to get to complex to be implemented on top of, say, macros), and developer of editor extensions such as addons. The impact of scripting language on extension developer is crucial for the evolution of an editor aiming at being powerful. If the scripting language and the API towards the editor is flexible enough, then a lot of cool extensions and features will be developed by third party authors, otherwise the burden stays on editor upstream author.
  1. In its phase 1 (my term, Vim < 7.0) Vim pretended that it needed only a minimal scripting language (Vim script) and that everything else can be developed using external programming languages, linked in the editor. As a consequence Vim script was just a tiny teeny procedural language with editor interfacing capabilities, most notably lacking any "decent" data structures (no lists, no dictionaries, ...). In that phase, if you were a user it was fair enough. You just had to chose your external programming language (at compile time ...), and you were able to write your quick hacks with it. But if you were willing to develop an extension you were screwed, because you had either to impose your external programming language to the final user (that is what gave born to absurdities like vim-full, look at the deps!) or to enjoy a good deal of masochism to explode your 30 lines of Python extension into 200 lines of Vim script to make your Vim extension more "portable".
  2. In its phase 2 (Vim >= 7.0) it has been realized that something were wrong in the initial choices about Vim script, and data structures (lists, dictionaries, function references!) have been added to it, relieving a bit the pain of programming portable extensions. Nevertheless, and probably due to how it started, Vim script is far from being a programming language one can enjoy programming in. Consider for example the standard library of the language. It started as a random collection of unrelated functions being added on a "as-needed" basis, ... and continued along that path! Now the API reference lists together totally unrelated functions, organized inconsistently, and making really painful finding what you need (assuming it exists).

Even in this respect, I acknowledge that Emacs got this right. It has chosen a single, now full-fledged, programming language (Elisp), which is offered both to the final user (fact: the average Emacs user knows much better how to program her own editor than the average Vim user) and to extensions developer. The standard library of the language is organized with a consistent naming (even though not always intuitive) and documented in an organized manner. You might not like the language, but at least is has been taken seriously and managed as such. Finally, being a Lisp dialect, you might need what you learn with Elisp elsewhere. Vim script is too committing: it is useful only inside Vim. I believe that contributed significantly in its scarce diffusion among Vim users. The fact that Elisp was born together with Emacs and that it is also used internally for the editor implementation is not relevant here: I do care about what is offered to me as an user and as an extension developer. What I see on the Emacs side in this respect is much better that what I see on the Vim side. Moreover, from the point of view of the users, is the difference between what is inside the editor and what is outside (i.e., the extensions) that relevant? I think it is not, and that brings me to the final Vim choice which I consider flawed and which has the potential of seriously limit its future evolutions:

• Editor as a distribution. Emacs is managed as a intermediate software distribution layer, similarly to what happens in other softwares where many third party authors cooperates (e.g., TeXLive). The distribution architecture has advantages and contributes to the longevity and potentialities of a software project. What does this mean concretely in the Vim vs Emacs dispute? For example it means that Emacs get more feature-complete each passing release, still preserving uniformity in documentation and keybindings. On the contrary Vim sports many addons, which are very likely to step on each other feet when enabled simultaneously. Actually, that is one of the reason which brought me to the creation of vim-addons: you cannot enable all the content of vim-scripts together due to various kind of conflicts. As we know well in Debian, distributions have a fundamental role in blending together lightly-coupled software components, that's role is missing in Vim evolutionary path and I find that worrisome.

Where to from here in this blog post series? For sure some tips on how to migrate for hard-core Vim users, then we'll see ... If you did enjoy the read please let me know commenting in the discussion page (as you did in the last post, thanks!).

One of the speakers at OSCon this year — I forget which one — made a point that ran something like this, heavily paraphrased:

Education used to be an end in itself, not a means. It wasn’t about having a high-paying career. It was about knowing the world, about having knowledge and wisdom for its own sake. It was, quite bluntly, the accumulation of useless knowledge by the elite — those that could afford to spend time on such things, knowing that useless knowledge has a way of becoming useful in the most unexpected of ways. How fortunate we are to live in an age where the accumulation of useless knowledge is available to so many, and how sad it is that so few take advantage of it.

What a powerful statement, and it rings true to me. I remember in high school, when people from the local liberal arts college would come and talk. They’d talk about the value throughout a lifetime of knowledge in a broad range of disciplines: English, history, political science, religion, science, and the arts. They’d talk about how their graduates went on to lead distinguished lives, how this broad core of knowledge serves a person well through life. I guess I didn’t believe them, because due to their lack of a computer science major, I went elsewhere. That local school may not have been the best choice for me for other reasons, but as I look back on it, I think they had a much stronger message than I realized back then. Here I am, just two math classes, one computer science class, and one biology class away from a degree. Yet I have had not one class covering the history of east Asia, not one class on different world cultures or religions, and only a very basic understanding of one foreign language (German). This hits me in the face almost every day. Yesterday I was wondering about the history of slavery and racism in Europe. Today I’m curious about China’s history as an economic powerhouse. Last week I was curious about Roman law and daily life. The fact is, everything from philosophy to calculus is screamingly relevant to daily, modern life. We hear talk of “an American revolution” in Washington, of a shift of power in the Senate. It seems we forget that the notion of a Senate is considerably older than the United States is — and that we have such a thing because our founders were aware of this. Macroeconomic theory is thrust in our faces on an almost daily basis these days, yet I’ve never had a class on economics at all. We might feel fear of terrorist attacks, or see our fellow citizens lash out at “the Arabs.” Our own short memories fail to remind us of the light in which we are seen, fail to put the really quite minor terrorist threat in context of what London or Dresden endured in World War II. We demand our government to make us safer, and our government responds by making us less safe but making us *feel* safer at airports. In my own field, I see some universities buckling to pressure from Business to turn out large numbers of mediocre programmers that know the Java or .NET standard library well, but have no sense of the theory behind computer science, and would be utterly lost if asked to, say, write a recursive QuickSort. I find myself almost completely baffled that some companies that want to hire the world’s best programmers are only looking for people that are already fluent in $LANGUAGE — not ones that are good programmers, and so well-versed in computer science that they can easily pick up any language. I think there is a lot to the argument that a good, broad, classical education can serve a person well in any career. I wish I had realized that a little earlier.

After just three days of beta operation I could already make screenshots.debian.net go live. Within the first day I fixed a few typos, optimized database queries and added proper HTTP headers for caching. We got a huge load spike after my announcement on debian-devel-announce. I’m very happy and proud to have this service running and appreciate the help from the SQLAlchemy, Pylons and Debian community. Michael Vogt has already added screenshots support to the Synaptic package manager. Martin Stigge has joined the admin team to speed up approving screenshots in the moderation queue. (It would nice if someone else volunteered who is from .us or .au to deal with uploads while we sleep.) And above all I’d like to thank ‘zepolen’ from car.gr for allowing me to host the web application on his server. I think neither of us estimated so much interest in the service. May his server not melt under the load. Honestly the first feedback wasn’t very motivating (developers tend to point out errors first) but I enjoy seeing how quickly the news is spreading. And thanks to everybody for uploading further screenshots. I’ll keep on watching the moderation queue and enjoy how others blog about it.