I have always been against FeedBurner. I don't like it at all. I've never liked it, as a matter of fact, I have no actual idea why I've been using it on my blog. I do know why I used it on the country feeds on Planeta Linux, and that is because it was very easy to mask all of our URL changes with some level of stability on the subscribers (in times where me being technically competent was a bad joke for myself). Plus, we could plug AdSense into it (that later on I removed because I like to earn actual dollars, not pennies, you cheap clickers!). Or maybe I'm just so against it because of pure jealousy: A few RSS feed geeks, like myself, sold a sub-parproduct to Google in a hundred million dollars. At the very end, I've never had a good reason to use FeedBurner or to stick with it, so hereby I'm dropping it entirely from my own personal blog.

It's obvious that some people who subscribed to my feed using that FeedBurner URL aren't reading this very blog post. It's alright, I've lost reigns before, I will get over it and conquer their hearts again. But you, dear blog reader, planet subscriber, or eventual visitor, have the power to change things, to help workaround the evils of FeedBurner and make me be myself again. Please, help me myself again! And that is, from now on, use this feed URL and only this feed URL, I promise I will support as long as nice good looking HTTP servers (such as nginx or Cherokee) exist:

http://stereonaut.net/feed/

That said, I will get you a beer next time we meet each other and you, dear reader, mention this blog post and mention that you changed to this new feed URL of mine. I'm not kidding. Just go ahead and tell me

Thank you.

Remember Vitacilina? A small aggregation library I wrote last year to be intended to replace Planet on Planeta Linux? Well, it never quite replaced it but it achieved some level of stability since I was using it for a number of tasks at work. So, during this long holiday weekend, I received a notification that the Request To Package bug I had filled against the Work-Needing and Prospective Packages in Debian has already been taken care of and the library had been uploaded. Of course, I could have made this myself a long time ago, but at the time it was simpler and faster just to hope someone else would do it at some point.

So, Dario did it. He packaged it and uploaded version 0.1 under the umbrella of the Debian Perl Group. Hurray!

But then I realized that Alexandr Ciornii had implemented some nice changes to Vitacilina back in September that I never got to include or release as a CPAN distribution. And so I just did. I've uploaded 0.2 to CPAN and you can fetch it with cpanf Vitacilina or wait for the Debian Perl folks to update it

It's very pleasant for me to announce that the probably most descriptive domain name in Mexico for Linux, linux.org.mx, is now powered by Planeta Linux México.

I see this as a great milestone of all the members of the Mexican Linux community that have made Planeta Linux the number one Web site in Mexico for Linux. Also, please raise your drinks for @negrabarba, who made this possible, administrator of the DNS at UPN, where the domain name points to; and of course for Miguel, the owner of it.

So I've spent quite some time in the last couple of months (whenever I had a chance, actually), to redesign how the core of Planeta Linux works, and I'll explain all the changes I've made to make it a much better solution that fully fits our current needs. If you are reading this with a feed reader, star this item, share the item, retweet the post! Let everyone know we are doing this for the Linux Latin American community!

If you're naive enough, you'll think about Planeta Linux as a simple Planet aggregation instance with a different set of people collections, which we used to call, ironically, instances, which aren't anything else but countries. If you don't know how we've been doing Planeta Linux for almost five years now, you'll think it's all just config.ini being fed to the planetplanet binary. Well, it has been like that, yes, but having a big set of planets (more than ten now) makes it a bit of a hassle to do any changes or try to do anything else but add, edit and remove people. The way we were handling it with Apache was already documented in the past.

Some of the multiple issues Planeta Linux has had in the past could be summarized as:

• Inability to have a unified templates set.
• Repeated feeds of the same person on multiple countries.
• Inability to know when a feed started to properly return valid items.
• Error-prone parsing.
• Difficulty to test on local environments.
• Decentralized subdomains with difficulty on sharing content or awkward navigation between contries.

And the list could go on. I realized this was a huge pain in the ass when I had the intention to centralize the subdomains into a single one: Instead of using the model $country.planetalinux.org, everything would have to come out from just planetalinux.org. Changing to that on our previous scheme was simply an hemorrhoid. So, I changed it all and the new model is much better and robust, even though you probably don't see a single difference on the current Planeta Linux output.

I started by getting rid of the horrible config.ini editing. Whenever you want to add an author, you simple drop a YAML file into the authors directory. It doesn't matter the location of the file as long as it's inside the authors directory. When I started importing all of the subscribers, I ended up with more than 620+ author files so I made a simple separation of files a-la CPAN: authors/d/da/david_moreno.yml. But at the end, it doesn't really matter, a) what your file is named, and b) where you put it, they will all get parsed and interpreted. Now, inside that YAML file there's a bunch of goodies. Firstly, you have the feed URL, the name of the person, his or her email, an array of countries where the feed should be aggregated into and other stuff such as the path for the hackergotchi, a twitter parameter for the Twitter feed, an enabled switch, etc. The good thing about it is that you can have all the parameters you want so we can build on top of that later (maybe identica profiles, LastFM usernames, whatever).

One of my future intentions is to have also an array of feeds on each author file which would empower us to have the same info for several feeds. With the new model, this should be much easier to implement anyway.

Anyway, basically, when you want to add or edit a feed, you just edit or drop the file on the authors directory. KISS.

Second big change, we switched to Planet Venus, as opposed to just Planet for the aggregation engine and you no longer need to have it installed since it's included now on the entire Planeta Linux tree under the venus directory. Venus implements a whole new world of features and good stuff on top of Planet, it was just a no-brainer to switch to it.

However, Venus still requires config.ini for each of its instances, so this is where the whole build process comes to play. I implemented a tool, script/build that does exactly that, it gathers all the info from authors and builds each of the countries. To create a new country, you just basically only have to add it to config/countries.list. The build script will use all of them as tasks and execute them at will.

Now, how the build tool works? As said, it gathers the data from authors and generates a config.ini on the fly. There's a config.ini template file on the template directory, as well as an index.html template (and rss.xml), and for the build script, it's just another Template Toolkit file so you can do all sorts of awesome and crazy shit with it. So it's all generated dynamically, with the information from authors, information from the config directory and it dumps it all on the www directory. Because of that, you can generate your own working copy of Planeta Linux or implement others or just play with it!

So basically, the whole process is like this for each of the countries:

The good thing about it is that there's no interaction for the administrator to deal with the config.ini either when adding an instance since I integrated a tool that adds a new subscriber to the authors tree automatically:

~/axiombox/planetalinux :master $ ./script/planetalinux.pl help add
planetalinux.pl add [-p] [long options...]

Adds a new author to Planeta Linux. The name, email, feed URL and
country where to place the author are mandatory. If the hackergotchi
image path is provided, the script will check the size for the image
and resize it if needed (ImageMagick needed). Any other flags and
values passed to this command will be appended on the resulting
YAML file.

Examples:

./script/planetalinux.pl add \
--feed http://example.com/feed \
--name "Tía Chonita" \
--email tia@chonita.com \
--countries ve \
--hackergotchi ~/images/chonita.jpg \
--twitter @chonita

./script/planetalinux.pl add \
--feed http://blog.wordpress.com/feed/atom \
--name "Isela Crelló" \
--email yeah@yeah.com.mx \
--countries mx,sv,gt \

./script/planetalinux.pl add \
--feed http://cofradia.sucks/feed \
--portal \
...etc

--feed feed URL -- mandatory
--name name of author of feed -- mandatory
--email email of author of feed -- mandatory
--countries country(ies) of author -- mandatory
--hackergotchi path to the hackergotchi image -- optional
-p --portal portal site flag -- optional
--twitter twitter feed of author -- optional

~/axiombox/planetalinux :master $

Cool things about this new "adder" script:

• It ensures that the author has an stored feed, name, email and country, at the very least.
• It checks whether the URL is a valid feed URL against the W3C feed validator.
• It checks that the email is valid.
• It checks that the countries specified are supported by the system.
• It takes a file path for the hackergotchi and using ImageMagick, it resizes it, converts it into the proper image type and places it under the appropiate image heads path.
• It creates the YAML and places under an appropriate location under the authors directory.
• It's awesome

Tutorial

Now, one of the good things about all of this is that you can create your own Planeta Linux running right there on your machine, given that well, it's just a nice big glue involving Perl for the processing, Python for the parsing and aggregation, the cache is stored on the tree as well, etc.

To start, you'll have to clone the repository if you haven't done it yet:

$ git clone git://github.com/axiombox/planetalinux.git

Change the directory to the repository and just run the dependencies installer for all of the modules used:

$ sudo perl installdeps.pl

Note that you'll have to be running perl 5.10 (it's been stable for almost two years now, dude! Upgrade!). If you already have most of the modules installed on your system, this shouldn't take that long. If you have nearly no Perl modules installed, it will probably take a little while. It might even need your intervention for some basic CPAN configuration. Once it's done, you should see something like this, at the end of the output:

.. testing loading modules...
- App::Cmd
- App::PPBuild
- Config::IniFiles
- Data::Validate::Email
- DateTime
- File::MimeInfo::Simple
- File::Path
- Modern::Perl
- Net::Domain::ES::ccTLD
- Template
- WebService::Validator::Feed::W3C
- YAML::Syck

.. done. enjoy!

.. please make sure you have PerlMagick installed.
.. the recommended way is: `port install p5-perlmagick` in Mac,
.. ..or 'aptitude install perlmagick' in Debian/Ubuntu.

Now, for the ImageMagick Perl bindings (for the "adder" funcionality) you'll need to install it depending on your operating system. If you are running some flavor of Debian (or Ubuntu), you just have to install the perlmagick package. On MacOS, I recommend installing the ImageMagick MacPorts port with the "+perl" flag. Depending on your configuration, you might need to install the Image::Magick module either from the CPAN shell or downloading it from web. Once all of that is done, you can just fire up the building system:

$ ./script/build all

You can just fire up a single country or other tasks by seeing which ones are available:

$ ./script/build --tasks

At this point you can go to your browser and navigate to the www directory on the repository where all the output has been dumped.

If you have any issues running your own local copy of Planeta Linux, please put a comment on this post, I'll glad you help you solve it and you'll be helping us making Planeta Linux much better than ever.

I implemented a simple dependencies installer for the new Planeta Linux. I spent some time trying to find how to make CPAN::Shell::install to install modules without running the test units, it's quite simple.

CPAN::Shell->rematein("notest", "install", $module);

Kudos to mst for the pointer.

As I'm rewriting the core of Planeta Linux (you can track progress here), I needed a reliable way to map a country TLD to its Spanish name. I headed to CPAN to see what was already built to do that and found out Locales::Country that looked awesome but it didn't work for me, code2country('ni') would return undef for me, plus the countries that were actually there had the encoding all fubar, so fuck it, drop it.

So I came up with Net::Domain::ES::ccTLD using the data from the Spanish Wikipedia for the countries TLDs:

use Net::Domain::ES::ccTLD;

my $country = find_name_by_cctld('mx')     # $country is 'México'
  or die "Couldn't find name.";

my $current = find_name_by_cctld('us');    # $current is 'Estados Unidos';

Why would I reinvent the wheel for this? Because it was easier and faster for me and it's all about practicality, isn't it? Plus the code is super tiny, maybe the smallest module I have in CPAN in terms of actual code.

Feel free to use if you will.

Una de las cosas más bonitas que puedes hacer gracias a mod_perl, son las PerlSections.

Básicamente con éstas, lo que puedes hacer es definir dinámicamente directivas de configuración de Apache y hacer cosas bien interesantes. Por ejemplo, recientemente, para Planeta Linux quería tener una sola configuración de Apache para los virtual hosts que son repetitivos dada cada instancia (mx.planetalinux.org, ve.planetalinux.org, gt.planetalinux.org, etc). Precisamente lo que quiero evitar es tener que poner una interminable lista de VirtualHost's, así que lo puedo hacer con secciones en Perl (que son denotadas en cualquier archivo de configuración en Apache con <Perl> y </Perl>):

<Perl>

	my $names = {
		cl => 'PlanetaLinuxChile',
		co => 'PlanetaLinuxColombia',
		cr => 'PlanetaLinuxCostaRica',
		ec => 'PlanetaLinuxEcuador',
		sv => 'PlanetaLinuxElSalvador',
		es => 'PlanetaLinuxEspana',
		gt => 'PlanetaLinuxGuatemala',
		mx => 'PlanetaLinuxMexico',
		ni => 'PlanetaLinuxNicaragua',
		pa => 'PlanetaLinuxPanama',
		pe => 'PlanetaLinuxPeru',
		ve => 'PlanetaLinuxVenezuela',
		debian => 'PlanetaDebian',
	};

Defino una referencia a hash en $names que lista contra los "TLDs" de cada instancia y con su nombre largo.

	my $instancias = [keys %{$names}];

Para facilitar trabajar con las llaves, creo una referencia a un arreglo que contiene exclusivamente las llaves del hash que previamente tenía definido.

	$VirtualHost{"*:80"} = [];

Como voy a definir todos mis VirtualHost's apuntando hacia "*:80", defino el valor de la llave "*:80" del hash pre-definido $VirtualHost (pre-definido por mod_perl), hacia una referencia de arreglo vacío (por el momento).

	for my $pais(@{$instancias}) {

Empiezo a interar cada uno de los elementos de $instancias y asigno cada valor en la interación a $pais.

		my $vhost = $pais.".planetalinux.org";

		if ($pais eq 'debian') {
			$vhost = 'planeta.debian.net';
		}

El nombre del servidor será $pais.".planetalinux.org", a menos que sea "debian", que no lleva el dominio de Planeta Linux.

		my $virtualh = {
			SuexecUserGroup => ["planetalinux", "planetalinux"],
			ServerAdmin => 'planetalinux@googlegroups.com',
			ServerName => $vhost,
			DocumentRoot => "/var/www/planetalinux/".$vhost,
			ErrorLog => "/var/log/apache2/planetalinux_".$pais."_error",
			CustomLog => ["/var/log/apache2/planetalinux_".$pais."_access", "combined"],
			LogLevel => "info",
			Alias => ["/images/", "/home/planetalinux/current/www/instancias/".$pais."/images/"],
			Redirect => ["/rss20.xml", "http://feedproxy.google.com/".$names->{$pais}],
		};

Aquí defino la referencia al hash principal del virtual host. Los valores son definidos con los nombres de las directivas que utiliza Apache:

• SuexecUserGroup, pues utilizamos suexec en el servidor se asigna a una referencia de arreglo anónima con dos valores, que son los dos valores que se le pasan a Apache en sus directivas regulares.
• ServerAdmin, es el mismo para todas las instancias, nuestra lista de correos.
• ServerName, es el nombre que definí previamente como $vhost.
• DocumentRoot, depende también de $vhost pues así lo tenemos definido en nuestro sistema de archivos.
• ErrorLog, caso similar a DocumentRoot.
• CustomLog, caso similar a ErrorLog, pero defino, igual que en SuexecUserGroup, un arreglo anónimo con los dos valores que toma este parámetro.
• LogLevel, igual que en Apache.
• Alias. Defino un alias simple.
• Redirect, puedo utilizar cualquier tipo de directivas, Alias, Redirect, lo que sea. En este caso, realizo la redirección de los viejos feeds "/rss20.xml" hacia la nueva URL de FeedBurner, que es ahora como manejamos los feeds en Planeta Linux. El valor que se concatena al final es el valor del hash %{$names} dada la llave $pais.

		push @{$VirtualHost{"*:80"}}, $virtualh;

Agrego cada $virtualh al arreglo de VirtualHosts en "*:80". Si tuviera una IP por cada uno de los VirtualHosts, no es necesario hacer push a un arreglo, simplemente tendría que declarar las variables $VirtualHost con la IP como llave. Sin embargo, si declaro muchas veces la misma variable, como en este caso, $VirtualHost{"*:80"}, en cada interación el valor se reescribirá, es por eso que mod_perl nos ofrece definir esa variable como referecia a arreglo en donde podemos meter cuantos virtual hosts como queramos.

	}

Termino el ciclo for.

</Perl>

Las posibilidades son muchas para la configuración dinámica de Apache y en secciones Perl puedes utilizar cualquier cosa, abrir tus archivos para ver otros parámetros de configuración, conectarte a bases de datos para sacar información, lo que sea.

Si te interesa ver todo el archivo de configuración, está acá, en el GitHub público de Planeta Linux.

Con la reciente y repentina muerte de Cofradía, la comunidad de linuxeros (y demás rarezas) en México necesita más que nunca un nuevo nicho. Afortunadamente, Planeta Linux México se ha consolidado como una verdadera comunidad de linuxeros mexicanos, y tan es así que ahora somos el resultado número uno en Google y en Google México para «linux méxico».

Aunado a ésto, algunos colegas y yo hemos iniciado un simple y sencillo grupo LinkedIn de Linux en México para que todos nosotros, profesionales, desarrolladores (y usuarios también, ¿por qué no?) hagamos networking. Únanse.

Linux México en LinkedIn.

Hace unos cuantos días vi que un nuevo proyecto de blogueros sobre Linux estaba siendo formado, Galaxia Linux. Al formar parte del selecto grupo de administradores de Planeta Linux, siempre nos interesa sumar esfuerzos: No nos gusta pensar que hay proyectos que lo único que quieren es aprovechar el trabajo de los demás sin crédito, me gusta pensar en Planeta Linux como un proyecto que puede ayudar a muchos otros más a formarse reforzando la comunidad latinoamericana linuxera, engordándola, consolidándola, sin embargo, bueno, ésto no es lo mismo en la dirección opuesta.

Me interesó mucho que Galaxia Linux intentara hacer un ranking hispanoamericano de blogs sobre Linux y quise saber cómo lo hacían. Me sorprendió que en su sitio, para "formar parte" había que colocar una simple y burda imagen en el sitio. ¿Así es como rankean a los sitios? Lo puse pues, en varias de las instancias de Planeta Linux y cada que recargaba el sitio, se le sumaba una hit más al contador en la página del ranking. ¿No es lo más burdo e ineficaz que se les ocurre? ¿Cómo lo estaban haciendo? Su banner es claramente un GIF generado por un script en PHP. Me lo imagino tan simple como que cada que se ejecuta, lee la variable HTTP_REFERER, si el sitio ya se encuentra en una base de datos, aumenta el contador, si no es así, crea un nuevo sitio en la tablita con el hit en 1. Y ya, ese es el ranking que intentan crear. Luego, en la página principal, pues simplemente ponen los sitios que tienen más hits, aparentemente "semanalmente". Es decir, si en el sexto día de la semana, un sitio con muchísimo tráfico "se une", básicamente se la pela porque el contador semanal ya contó hits para otros sitios durante seis días y un par de sitios puede que tengan más por los seis días que un verdadero sitio en uno solo. Jugando, puedes hacer ésto:


use LWP::UserAgent;
my $ua = LWP::UserAgent->new;
# Ternurita...
$ua->agent("Mozilla/4.0 (compatible; MSIE 5.5; Windows 98)");
while(1) {
# Para ahorrar ancho de banda, hago HEAD, en lugar de GET
my $req = HTTP::Request->new(HEAD => 'http://www.galaxialinux.com/rank/banners/banner.php');
$req->referer('http://mx.planetalinux.org/');
my $res = $c->request($req);
# Gracias, vuelvas prontos.
}


Claro, ésto también pudo haber sido hecho mucho más rápido con lwp-request, por ejemplo, que hace precisamente lo mismo utilizando LWP. O como dice MaoP en los comentarios, claro, con wget.

¿Qué define un ranking? Rankear blogs o sitios web no es nada sencillo, no es nada más darles a los sitios una imagen para que la inserten, me gustaría saber qué opina por ejemplo, Alianzo o Bloglines, o Technorati, o Google Reader, de la forma en que Galaxia Linux rankea los sitios: No es algo sencillo, no es algo a la ligera. Corrí mi script desde varios lugares y luego de un ratito Planeta Linux México estaba en primer lugar (luego ya no estuvo, supongo que se dieron cuenta que mi ranking "subió" rápido en poco tiempo y le quitaron hits, este tipo de cosas tampoco debería tener intervención manual, quita la fiabilidad).

Invito a la gente de Galaxia Linux a que arreglen los problemas de fiabilidad y credibilidad que tienen en su sistema porque es una excelente idea, y nadie se las va a quitar o robar, si hacen bien las cosas y no se lo toman a la ligera.

UPDATE: "El sitio es beta" es uno de los pobres argumentos. Bueno, si realmente desean hacer un ranking fiable, la imagen que le ofrecen insertar a la gente está de más, ¿cuando no sea beta el sitio la imagen dejará de necesitarse? Debería, ¿no? Porque seguir haciendo un ranking basado en referers y hits… ¿dónde se ha visto eso? El objetivo es claro y bueno, la forma en que lo hacen no, todo su diseño de concepto está errado.
UPDATE: He cambiado el término que uso de visitas por hits, porque tiene más claridad y evita ambigüedad pues fueron páginas vistas, o hits, a lo que me referí todo el tiempo. Hasta un simio pudo haberlo entendido.
UPDATE: Las reacciones no se hicieron esperar, mi tocayo David Valdez lo cuenta mejor.
UPDATE: Había optado por mantener despublicado esta entrada para evitar mayores confrontaciones y le había ofrecido una disculpa a la gente de Galaxia Linux por no haber escogido bien mis palabras desde el principio, pero dada su reacción y ataque, he decidido volver a publicar este post.

El próximo mes Planeta Linux cumplirá cuatro años. Cuatro, casi media década. Ésto amerita hacer una fiestecita o algunos cambios interesantes que traigo en la cabeza desde hace… mucho tiempo.