Si, lo sé, los títulos empiezan a rayar lo imposible pero prometo estarme tranquilo una temporada.

Una de las partes, a mi juicio, más interesantes del anuncio de la liberación de Debian GNU/Linux 7, «wheezy», es la inclusión oficial de la multiarquitectura. La posibilidad de instalar un software hecho a medida para una determinada arquitectura en otra y sin que esto suponga un quebradero de cabeza (como venía siendo últimamente), es un avance enorme. Hace algún tiempo publiqué una entrada dedicada a este tema, Entendiendo la multiarquitectura en Debian GNU/Linux con Citrix y ya en la primera línea dejaba claro que el cliente ICA es para un entorno corporativo y que la verdadera prueba de fuego sería Skype. Bien, pues ha llegado el día de las pruebas.

Han coincidido varios factores. Por un lado, la última actualización ya estaba pidiendo la desinstalación de la librería ia32-libs; hace dos días se liberó wheezy con este tema presente en todas las notas, avisos y comentarios; y, además, hoy estoy de ese humor en que el cuerpo te pide riesgos.

Pero volvamos al tema. Lo primero de todo es hacer una pequeña actualización y limpieza del sistema antes de empezar:

diego@denox:~$ sudo aptitude update
diego@denox:~$ sudo aptitude full-upgrade

Probablemente, desinstalará varios paquetes, entre ellos la mencionada ia32-libs y todas sus dependencias. Nada de lágrimas, eso es lo que perseguimos. A continuación, añadimos la segunda arquitectura a dpkg, en mi caso, i386:

diego@denox:~$ sudo dpkg --add-architecture i386

El resto es sencillo. Podría usar dpkg para comprobar las dependencias pero ya he dicho que hoy estoy guerrero, así que instalo directamente skype (bajado de la web oficial):


diego@denox:~$ sudo dpkg -i skype-debian_4.1.0.20-1_i386.deb
Seleccionando el paquete skype previamente no seleccionado.
(Leyendo la base de datos ... 126982 ficheros o directorios instalados actualmente.)
Desempaquetando skype (de skype-debian_4.1.0.20-1_i386.deb) ...
dpkg: problemas de dependencias impiden la configuración de skype:
skype depende de libqtwebkit4 (>= 2.1.0~2011week13).

dpkg: error al procesar skype (--install):
problemas de dependencias - se deja sin configurar
Procesando disparadores para mime-support ...
Procesando disparadores para gnome-menus ...
Procesando disparadores para desktop-file-utils ...
Se encontraron errores al procesar:
skype


Nos comenta que depende de libqtwebkit4 y, al tratar de instalar dicha librería sin indicar la arquitectura, nos corrije:

diego@denox:~$ sudo aptitude install libqtwebkit4
Se configurarán los siguientes paquetes que están ahora parcialmente instalados:
skype:i386{b}
No se instalará, actualizará o eliminará ningún paquete.
0 paquetes actualizados, 0 nuevos instalados, 0 para eliminar y 0 sin actualizar.
Necesito descargar 0 B de ficheros. Después de desempaquetar se usarán 0 B.
No se satisfacen las dependencias de los siguientes paquetes:
skype:i386 : Depende: libqtwebkit4:i386 (>= 2.1.0~2011week13) pero no será instalado.
Las acciones siguientes resolverán estas dependencias

¿Acepta esta solución? [Y/n/q/?]

Hace incapié varias veces en que tanto skype como la librería de la que depende están disponibles para la arquitectura i386, únicamente. Así pues, sólo tenemos que complacer al dpkg, indicándole la arquitectura deseada:

diego@denox:~$ sudo aptitude install libqtwebkit4:i386
Se instalarán los siguiente paquetes NUEVOS:
libgstreamer-plugins-base0.10-0:i386{a} libgstreamer0.10-0:i386{a} liborc-0.4-0:i386{a} libqtwebkit4:i386
Se configurarán los siguientes paquetes que están ahora parcialmente instalados:
skype:i386
0 paquetes actualizados, 4 nuevos instalados, 0 para eliminar y 0 sin actualizar.
Necesito descargar 8.876 kB de ficheros. Después de desempaquetar se usarán 32,5 MB.
¿Quiere continuar? [Y/n/?]

Y pensar que tenía cierto reparo y hasta miedo…

12800 paquetes nuevos, para un total de más de 37493 paquetes, GNOME 3.4, KDE 4.8.4, Xfce 4.8, y LXDE”.

Esta nueva versión de Debian incluye varias funcionalidades interesantes, como, por ejemplo, el soporte multiarquitectura, varias herramientas específicas para desplegar infraestructura de nube privada, un instalador mejorado, y un completo conjunto de códecs y reproductores multimedia que eliminan la necesidad de utilizar repositorios de terceros.

El soporte multiarquitectura, uno de los principales objetivos para Wheezy, permitirá a los usuarios de Debian instalar paquetes para múltiples arquitecturas en la misma máquina. Esto significa que ya es posible, por primera vez, instalar software para 32 bits y 64 bits en el mismo sistema y tener todas las dependencias relevantes resueltas automáticamente.

El proceso de instalación se ha mejorado mucho: ahora se puede instalar Debian usando software de síntesis de voz, por ejemplo para personas con discapacidad visual que no usan un dispositivo Braille. Gracias al esfuerzo combinado de un gran número de traductores el sistema de instalación está disponible en 73 idiomas, y en más de una docena de ellos también se pueden utilizar con el software de síntesis de voz.

Además, por primera vez, Debian soporta la instalación y arranque usando UEFI para PCs nuevos de 64 bits (amd64), aunque aún no hay soporte para arranque seguro

Por cierto, ojo al cambio con los ficheros temporales:

En publicaciones anteriores, se montaban sistemas de ficheros temporales (tmpfs) en /lib/init/rw, /dev/shm/ y opcionalmente en /var/lock y /var/run. Se ha eliminado /lib/init/rw, y los otros sistemas de ficheros se han movido bajo /run. /var/run y /var/lock según la configuración de RAMRUN y RAMLOCK en /etc/default/rcS. Todos estos sistemas de ficheros tmpfs son configurables ahora a través de /etc/default/tmpfs; la configuración anterior no se migra de forma automática.

Como veis, el esfuerzo ha sido grande y es fruto del trabajo de una comunidad orgullosa de colaborar con Debian, activa y generosa. Para los que en nuestro día a día estamos con versiones de desarrollo (Testing o Sid), quizás en nuestros escritorios no veamos estos cambios de una forma tan plausible, pero en los servidores el cambio no es menor.

Sólo hay que ver la lista de paquetes nuevos para darse cuenta. La guía de instalación es muy completa y en este caso, el proceso de actualización de Debian 6 a 7, es un poco más delicado que cuando migramos de Lenny a Squeeze, pero a falta de ponerme a migrar alguno en producción, las instrucciones para hacerlo son claras y ahí se citan posibles problemas más de escritorio que de servers, pero si te puedes fiar de alguien a la hora de actualizar un servidor, pon a Debian muy arriba en la lista ;-;).

Eso sí, no olvides que el fin de soporte para Debian 6 es en julio, aunque como pasó con otras releases, entraron actualizaciones de seguridad pasado el plazo. Fuente e imagen.

Para los SysAdmins, nuevas versiones en Debian 7. Apache 2.2.22, BIND 9.8, lighttpd 1.4.31, MySQL 5.5, PHP 5.4, OpenSSH 6.0, PostgreSQL 9.1, Python 2.7 / 3.2.

Así que…Bienvenido Wheezy y gracias Debian por hacerlo posible !!!

Les explico el problema para que puedan entender cuál fue la motivación para crear este tipo de clases:
Europio Engine, cuenta con objetos genéricos necesarios en cualquier aplicación. Entre ellos, CollectorObject: un objeto colector.

Como explico en el capítulo XVII de mi libro sobre Teoría de Objetos, el objeto colector para un tipo dado, debe ser un Singleton, es decir un objeto de instancia única, pues solo podrá existir una -y solo una- colección para un mismo objeto.

En Europio Engine CollectorObject es un colector genérico. Llamando a CollectorObject::get('NombreDelObjeto') se puede obtener toda la colección de objetos NombreDelObjeto persistentes en el sistema a través de CollectorObject::$collection.

Sin embargo, al ser un objeto de instancia única, si la colección no era recuperada ANTES de solicitar una nueva colección, la última llamada sobrescribía a la primera.

Es entonces que no solo a nivel práctico se hacía necesario poder crear “on the fly” un NombreDelObjetoCollection sino además, ¡a nivel conceptual! Pues un colector genérico, no puede ser de instancia única. Pero, si dejaba de ser de instancia única, dejaba de ser un colector. Así nació la necesidad de crear una clase al vuelo y después de mucho investigar, descubrí que la única forma de hacerlo “sin rodeos ni códigos raros”, era utilizando eval().

Con una simple línea como esta que sigue, quedaba todo resuelto:

# ...

$nombre_del_objeto = "Producto";
$nombre_de_la_nueva_clase = "{$nombre_del_objeto}Collection";
eval("class $nombre_de_la_nueva_clase extends CollectorObject {};");

# ...

Lo anterior, creará al vuelo la clase ProductoCollection produciendo el siguiente código:

class ProductoCollection extends CollectorObject { }

Que al heredar de CollectorObject generaría un Singleton Colector sin más rodeos. Y a raíz de esto, comencé a pensar en la Standard PHP Library (SPL) y su tan discutido ArrayObject.

Para quiénes no estén del todo al tanto, ArrayObject es una clase de PHP que permite tratar a un array como si fuese un objeto (sé que es discutible pero no viene al caso ya que solo se trata de experimentar). Para que se entienda mejor, lo mostraré directamente con el código:

# Ejemplo Nº1: iniciar un array-objeto vacío
$persona = new ArrayObject(array(), 2);  # array-objeto inicializado
$persona->nombre = "Eugenia";  # Agrego la "propiedad" nombre al array-objeto 
$persona->apellido = "Bahit";
$persona->edad = 34;
print_r($persona);

Lo anterior producirá:

ArrayObject Object
(
    [storage:ArrayObject:private] => Array
        (
            [nombre] => Eugenia
            [apellido] => Bahit
            [edad] => 34
        )

)

Otro ejemplo, pero esta vez, creando un objeto desde un array asociativo:

# Ejemplo Nº2: iniciar un array-objeto partiendo de un aray asociativo existente
$datos = array(
    "nombre" => "Eugenia",
    "apellido" => "Bahit",
    "edad" => 34
);
$persona = new ArrayObject($datos, 2);
print $persona->nombre;  # Salida: Eugenia

Como pueden ver, la clase ArrayObject no es para nada compleja de entender e incorporándola a eval(), me podría dar la posibilidad de crear clases al vuelo y prácticamente anónimas, produciendo objetos de diversos tipos. ¿Cómo? Creando una simple clase “estática” que se encargue de todo:

class Object {

    public static function set($clsName, $array=array()) {
        if(!class_exists($clsName)) {
            eval("
                class $clsName extends ArrayObject {
                    public function __construct(\$array=array()) {
                        parent::__construct(\$array, 2);
                    }
                }
            ;");
        }
        return new $clsName($array);
    }
}

De esta forma, crear una clase al vuelo, podría hacerse de dos formas:

# Omitiendo crear la instancia al nuevo (y por qué no, anónimo) objeto

$persona = Object::get('Persona');
# Un objeto Persona ya se encuentra disponible
print_r($persona);
/*
Persona Object
(
    [storage:ArrayObject:private] => Array
        (
        )

)
*/

# Creando la instancia al nuevo objeto para que la cosa no parezca tan anónima

Object::set('Persona');  # Creo la clase al vuelo
$persona = new Persona();  # Creo una instancia del nuevo objeto Persona que antes no existía
print_r($persona);
/*
Persona Object
(
    [storage:ArrayObject:private] => Array
        (
        )

)
*/

Y por supuesto, vale aclarar que en cualquiera de los dos casos, tanto la llamada a Object::set('ClassName'); como la instancia al nuevo objeto $obj = new ClassName(); podrán recibir como parámetro, un array asociativo que emule las propiedades del nuevo objeto.

¡Espero que disfruten del experimento!

En esta edición:

Distribuyendo tus aplicaciones Python en PyPI
Manual de Perl (Parte IV)
Equipos Ágiles: Parte II
Permiso denegado
Pásate a GNU/Linux con ArchLinux: NGiNX+PHP+MariaDB
Refactoring: otra práctica de la Programación eXtrema
Configurando GitWeb en Ubuntu Server
Draw.io: diagramas para tus proyectos
Automatizando tus aplicaciones con Cron
ASCII Art
Zona U!

Descarga | Otras entregas anteriores

Como siempre, todo un orgullo para nosotros tener a nuestra Eugenia en un proyecto con tanto peso y enhorabuena al resto del team -;). No es fácil mantener un proyecto así y puedes ayudar a que se siga publicando a través de una donación.

Cabe destacar que Debian GNU/Linux tiene un gran protagonismo ya que como podemos leer en la web del proyecto (en mi caso, tengo muy cerca Oviedo y si puedo, intentaré acudir al evento):

El IV FLISOL Oviedo (Asturias) tendrá lugar el sábado 27 de abril de 2013 en el El Olivar, C/ Oscura, 1/3 (Oviedo) y consistirá en unas jornadas de iniciación a la informática con software libre, destinada a personas con pocos conocimientos sobre el tema. No se tratarán aspectos técnicos o avanzados.

La actividad consistirá en una charla-debate de introducción al software libre, seguido de una “toma de contacto” de los participantes con el uso de sistemas GNU y la posibilidad de instalarlo a quien se lleve su ordenador a las jornadas y quiera. Posteriormente al día del evento, habrá otros días de encuentro con los asistentes para tratar de resolver dudas y preguntas que puedan surgir.

Tráete tu ordenador y si quieres, llévate un sistema 100% libre en él instalado (Exe GNU/Linux / Debian GNU/Linux).

Si puedo, como os he dicho me pasaré por allí el día 27 y de cualquier modo, os animamos a acudir quienes podáis, o haceros eco de la iniciativa. Mucha suerte !!!

Aprovecho la ocasión para dar las gracias al amigo Julián Brazuelo por el aviso -;).

#include <stdio.h>

foo(int a, int b) {
    if (a + b > 0) printf("%i ", a + b);
    if (a + b < 100000000) foo(b, a + b);
}

main() {
    foo(-1, 1);
    printf("\n");
}

En Java. Archivo: Foo.java

public class Foo {

    public static void main(String[] args) {
        Foo f = new Foo();
        f.foo(-1, 1);
        System.out.print("\n");
    }

    public void foo(int a, int b) {
        if (a + b > 0) { System.out.print(a + b + " "); }
        if (a + b < 100000000) { this.foo(b, a + b); }
    }

}

En Perl. Archivo: foo.pl

#!/usr/bin/perl

sub foo {
    ($a, $b) = @_;
    if($a + $b > 0) { print $a + $b . " "; }
    if($a + $b < 100000000) { foo($b, $a + $b); }
}

foo(-1, 1);
print "\n";

En Python. Archivo: foo.py

#!/usr/bin/python
from sys import stdout


def foo(a, b):
    if a + b > 0:
        stdout.write("%i " % (a + b))
    if a + b < 100000000:
        foo(b, a + b)


foo(-1, 1)
print ""

En PHP. Archivo: foo.php

#!/usr/bin/php
<?php

function foo($a, $b) {
    if($a + $b > 0) print $a + $b . " ";
    if($a + $b < 100000000) foo($b, $a + $b);
}

foo(-1, 1);
print chr(10);

?>

[nuevo] En Ruby. Archivo: foo.rb

#!/usr/bin/ruby


def foo(a, b)
    if (a + b) > 0
        print a + b , " "
    end
    
    if (a + b) < 100000000
        foo(b, a + b)
    end
end

foo(-1, 1)
puts " "

Exceptuando los archivos en C y Java que deberán ser compilados (ver más adelante), al resto de los archivos les asigné permisos de ejecución para que sea más cómodo correrlos:

chmod +x foo.php foo.py foo.pl foo.rb

Y a continuación, me dediqué primero, a comparar la velocidad de compilación entre Java y C y obtuve estos resultados:

Tiempo de compilación en C:

time gcc foo.c -o fooc

real	0m1.970s
user	0m0.028s
sys	0m0.048s

Tiempo de compilación en Java:

time javac Foo.java

real	0m3.769s
user	0m0.816s
sys	0m0.100s

Se podría decir que la compilación en C, tardó (más o menos) la mitad del tiempo que la compilación en Java.

Finalmente ejecuté cada uno de los micro-programas, dos veces cada uno: la primera, para que se cachearan y la segunda, para comparar la diferencia en la velocidad de ejecución y ésto, fue lo que obtuve:

Tiempo de ejecución en C: 0.002 segundos

eugenia@trisquel:~$ time ./fooc
1 1 2 3 5 8 13 21 34 55 89 144 233 377 610 987 1597 2584 4181
6765 10946 17711 28657 46368 75025 121393 196418 317811 
514229 832040 1346269 2178309 3524578 5702887 9227465 
14930352 24157817 39088169 63245986 102334155 

real	0m0.002s
user	0m0.000s
sys	0m0.000s

Tiempo de ejecución en Java: 0.143 segundos

eugenia@trisquel:~$ time java Foo
1 1 2 3 5 8 13 21 34 55 89 144 233 377 610 987 1597 2584 4181
6765 10946 17711 28657 46368 75025 121393 196418 317811 
514229 832040 1346269 2178309 3524578 5702887 9227465 
14930352 24157817 39088169 63245986 102334155 

real	0m0.143s
user	0m0.112s
sys	0m0.028s

Tiempo de ejecución en Perl: 0.003 segundos

eugenia@trisquel:~$ time ./foo.pl
1 1 2 3 5 8 13 21 34 55 89 144 233 377 610 987 1597 2584 4181
6765 10946 17711 28657 46368 75025 121393 196418 317811 
514229 832040 1346269 2178309 3524578 5702887 9227465 
14930352 24157817 39088169 63245986 102334155 

real	0m0.003s
user	0m0.000s
sys	0m0.000s

Tiempo de ejecución en Python: 0.038 segundos

eugenia@trisquel:~$ time ./foo.py
1 1 2 3 5 8 13 21 34 55 89 144 233 377 610 987 1597 2584 4181
6765 10946 17711 28657 46368 75025 121393 196418 317811 
514229 832040 1346269 2178309 3524578 5702887 9227465 
14930352 24157817 39088169 63245986 102334155 

real	0m0.038s
user	0m0.024s
sys	0m0.012s

Tiempo de ejecución en PHP: 0.027 segundos

eugenia@trisquel:~$ time ./foo.php
1 1 2 3 5 8 13 21 34 55 89 144 233 377 610 987 1597 2584 4181
6765 10946 17711 28657 46368 75025 121393 196418 317811 
514229 832040 1346269 2178309 3524578 5702887 9227465 
14930352 24157817 39088169 63245986 102334155 

real	0m0.027s
user	0m0.020s
sys	0m0.004s

Tiempo de ejecución en Ruby: 0.009 segundos

eugenia@trisquel:~$ time ./foo.rb
1 1 2 3 5 8 13 21 34 55 89 144 233 377 610 987 1597 2584 4181
6765 10946 17711 28657 46368 75025 121393 196418 317811 
514229 832040 1346269 2178309 3524578 5702887 9227465 
14930352 24157817 39088169 63245986 102334155  

real	0m0.009s
user	0m0.004s
sys	0m0.004s

Si se tratara de una carrera de autos la tabla de posiciones sería como la siguiente:

================================================
     Turismo Compilación
================================================
Primer puesto:   C
Segundo puesto:  Java

================================================
     Turismo Ejecución
================================================

PUESTO       PILOTO        TIEMPO (en segundos)
------------------------------------------------
1º           C             0.002
2º           Perl          0.003
3º           Ruby          0.009 ¡Nuevo competidor!  

4º           PHP           0.027
5º           Python        0.038

6º           Java          0.143

Es decir que PHP demoró 13.5 veces más que C; Python, 12.6 veces más que Perl y Java... mejor no lo comparo con ninguno

Pero no imporota, porque somos gente de bien, casi profesionales (algunos) y al rato surgió la idea (debish, again ): haríamos una entrada conjunta para celebrar el aniversario porque no todos los días se cumple otra nueva vuelta alrededor del sol. Así, imbuídos por el espirítu de algún escritor de fichero README, nos pusimos a aporrear los teclados con furia. Y sólo tardamos tres días en cerrarlo. El resultado, a continuación.
n1mh.

Debish

n1mh

Dabo

Eugenia

Nuevo aniversario de Debian Hackers que me toma de sorpresa, abstinente de nicotina y alquitrán

… tres años en Internet; los tres mejores compañeros de equipo y una de las mejores experiencias de mi vida… Si Debian y GNU/Linux significaban mucho en mi vida, Debian Hackers fue quien hizo que lo significaran todo.

Gracias por permitirme ser parte de este gran proyecto

Feliz Aniversario, colegas! Happy Hacking!

En ciertas ocasiones, nos vemos en la necesidad de abordar un problema desde la base, partir de cero y diseñar paso a paso un protocolo para resolverlo de la forma más eficiente posible. Esto ocurre, por ejemplo, en el campo de la bioinformática, donde ciertos problemas pueden requerir un planteamiento independiente a pesar de ser de la misma naturaleza que otros muchos. En estos casos y en otros tantos (modelización matemática, ingeniería, estadística, etc) es necesario comenzar a trabajar a nivel de algoritmo para poder alcanzar soluciones válidas y sobre todo viables (en tiempo y recursos) a nuestro problema.

Es por ello que habitualmente una de las preocupaciones principales a la hora de diseñar un algoritmo es cómo de rápido funcionará. Y en este punto es habitual encontrar a quien piensa que una serie de medidas puntuales en una máquina concreta pueden arrojar resultados significativos y extrapolables a otras máquinas. Error, gran error. La forma de evaluar la eficiencia de un algoritmo debe ser universal (independiente de hardware) y además estar basada en el funcionamiento natural de cualquier algoritmo, las operaciones. Así, lo mas lógico es tratar de comprender y evaluar el número de operaciones que nuestro algoritmo llevará a cabo. Y de igual forma, la cantidad de memoria que el algoritmo necesitará para funcionar. Imaginemos un algoritmo sencillo que opera sobre dos strings de tamaños m y n, comparando su contenido. En este caso, el número de operaciones es proporcional al producto del tamaño de los inputs (los strings) y podemos afirmar que el algoritmo es de orden m·n. En caso de que ambos fueran del mismo tamaño, estaríamos hablando de un algoritmo de orden m². Tanto en un caso como en otro, la notación utilizada es la denominada big-O-notation, siendo O(mn) para el primer caso y O(m²) para el segundo. También cabe la posibilidad de que la eficiencia del algoritmo sea independiente del tamaño del input (por ejemplo, acceder al índice de un array) lo cual se denotaría O(1), o que la dependencia sea de tipo polinómico, exponencial, etc.

Es fundamental comprender la complejidad de cada algoritmo candidato para así poder evaluar cuál va a ser la diferencia en cuanto a eficiencia entre unos y otros. Por ejemplo, un algoritmo de orden exponencial duplica el número de operaciones con un input n+1 en comparación a un input n. Es posible que te permita realizar un análisis exhaustivo de tus datos, pero también que el número de operaciones que requiera para inputs moderados sea inaceptable. Un breve resumen qué tipo de algoritmo aumenta su complejidad más al aumentar el input sería:

n! > 2^n > n³ > n² > n·log n > log n > 1

 Por todo lo anterior, a la hora abordar el diseño del algoritmo debemos considerar siempre el mejor caso (donde el algoritmo sea exigido en sus mínimos), caso promedio y peor de los casos, para poder determinar si el algoritmo va a poder ser implementado y ejecutado para resolver nuestro problema concreto. En ocasiones, el problema nos permitirá movernos en el mejor de los casos la mayor parte de las veces y pocas en el peor de los casos, pero puede haber otras ocasiones en que ocurra al revés, y debe ser algo a tener siempre en cuenta para cada problemática en particular.

 En definitiva, se trata de evaluar cómo va a responder el algoritmo en términos universales y considerando siempre todos los casos posibles de uso, para así asegurar que su futura implementación y funcionamiento ocurran acordes a las necesidades y limitaciones inherentes al problema que enfrentamos. Más vale invertir algo más de tiempo en diseñar un buen algoritmo, que hacerlo a la ligera y tener que tirar todo el trabajo de implementación porque al final resulta no ser viable. Evaluad, valorad y entonces y sólo entonces, implementad.

Happy hacking!