El sistema operativo Minix

Si eres lector habitual de blogs sobre GNU/Linux o software libre seguramente habrás leído alguna vez que GNU/Linux es más que Ubuntu. Sin embargo, también se puede decir que Unix es más que solo GNU/Linux. Hay varios sistemas operativos con la filosofía Unix además de GNU/Linux, si bien es cierto no tan extendidos como este último, por mencionar algunos los de la familia BSD (NetBSD, FreeBSD, OpenBSD, ...), el en continuo estado de desarrollo GNU/Hurd (del que Arch tiene una versión con este núcleo, Arch Hurd), Illumos y Solaris, otros menos conocidos como DragonFly y sobre el que trata esta entrada, Minix.

Como muy posiblemente ya conocerás Minix es el sistema desarrollado por Andrew Tanenbaum (y colaboradores) con el objetivo inicialmente de ser un sistema operativo con el que sus alumnos pudiesen aprender de forma práctica los principios teóricos sobre los que se basan los sistemas operativos. Con la versión 3 también tiene como objetivo ser un sistema usable según la propia página del proyecto.

Las diferencias entre los sistemas operativos Unix son varias que van desde la licencia que usan hasta la arquitectura interna. GNU/Linux utiliza una arquitectura monolítica en la que el kernel se compila como un único programa ejecutable y en el que los drivers se ejecutan en modo kernel. Esta arquitectura tiene la ventaja de que el kernel es más rápido pero a costa de que un fallo en un driver pueda tumbar el sistema. Para evitar este último problema surgen los sistemas operativos basados en un microkernel en el que el kernel propiamente es muy pequeño, de tan solo unas 6000 líneas de código, proporcionando las funciones básicas como un entorno en el que se puedan ejecutar varios programas concurrentemente sin que se interfieran entre ellos. El resto de funcionalidades son proporcionadas por los controladores de dispositivos (p. e. el controlador del disco duro) y unas entidades llamadas servidores usadas por los procesos (p. ej. los servidores de sistemas de archivos) que se ejecutan en modo usuario sin que puedan afectar al kernel.

Los debates entre si es mejor una arquitectura monolítica o una basada en microkernel ha originado alguna que otra discusión entre el propio Linus Torvalds y Andrew Tanenbaum (I, II y III) cada uno defendiendo las ventajas de cada implementación según los objetivos de cada sistema operativo.

Si has llegado hasta esta linea quizá te interese conocer un poco más como funcionan los sistemas operativos y Minix es un buen sistema operativo para ello. Un buen libro publicado por Tanenbaum es «Sistemas operativos. Diseño e implementación». La versión 2 de este libro está disponible en castellano y la versión 3 esta disponible en Amazon y otras tiendas en inglés.

Referencia:
Minix
Guía instalación Minix
Guía post instalación Minix
Lista de discusión de Minix
Código fuente Minix (Git)
http://www.osnews.com/story/15960/Introduction-to-MINIX-3
http://eprints.ucm.es/9519/1/Minix@ARM.pdf
http://wiki.minix3.org/en/MinixResources
http://www.freesoftwaremagazine.com/articles/minix
http://wiki.minix3.org/en/MinixFaq
http://wiki.minix3.org/en/Publications
http://sopa.dis.ulpgc.es/ii-dso/lecminix/lecminix.htm

Virtualbox, Arch Linux y adaptador puente

Haciendo pruebas del Ubuntu Enterprise Cloud de la entrada anterior en una máquina virtual de Virtuabox he usado el adaptador puente en la configuración de la red en vez de la predeterminada, NAT, para que la máquina virtual parezca que esta en la misma red que el sistema anfitrión. Sin embargo, el módulo del kernel que es necesario para usarlo no se carga por defecto en Arch Linux al arrancar el sistema por lo menos instalando el paquete virtualbox-archlinux-modules. Hay que cargarlo explicitamente para usar el adaptador puente sino ocurre el error de la siguiente captura de pantalla.

Para cargar el módulo explicitamente basta con ejecutar el siguiente comando desde la consola:

sudo modprobe vboxnetflt

Una vez cargado el módulo ya podemos iniciar las máquinas virtuales que hagan uso del adaptador puente.

Ubuntu Enterprise Cloud 10.10

Muchos han sido los artículos publicados el día 10 junto con la publicación de Ubuntu Maverick Meerkat (10.10) pero también junto con la versión del escritorio tenemos la versión de servidor destinada a empresas aunque para un entorno de producción es más recomendable usar la versión LTS (10.04) por el mayor tiempo de soporte que posee. Además de la tradicional versión para instalar como servidor también se puede instalar para construir una nube (que tan de moda está) privada o en una nube pública utilizando los recursos de la nube de Amazon.

La Ubuntu Enterprise Cloud (UEC) está formado por un controlador de la nube y uno o varios nodos controladores de las instancias. La nube de Ubuntu se basa en el software Eucalyptus.

El proceso de instalación de una nube privada de Ubuntu se inicia como cualquier instalación de otro sistema operativo introduciendo el CD o mediante una memoria USB (para hacer las pruebas lo más recomendables es utilizar una máquina virtual como Vitrtualbox u otras similares).

Una vez iniciamos el sistema seleccionaremos el lenguaje de la instalación y en vez de seleccionar la opción «Instalar Ubuntu Server» seleccionamos «Instalar Ubuntu Enterprise Cloud», los pasos para completar la instalación son similares a los pasos de instalación de un servidor normal, seleccionaremos el particionado de los discos, la distribución del teclado, el usuario y contraseña para el usuario root, se descargan algunos paquetes, etc... Una vez haya finalizado la instalación y se haya reiniciado el sistema podremos acceder a la consola de administración del nodo controlador de la nube. Para ello tendremos que conocer su dirección IP, lo podemos saber iniciado sesión en el servidor y ejecutando el comando:

$ ifconfig | more

Nos fijaremos en el campo «Direc. inet» de la interfaz br0 si como yo lo estáis probando en una máquina virtual de Virtualbox con una red no NAT sino adaptador puente (no la por defecto NAT).

Una vez conocida la dirección IP abriremos el navegador, la introduciremos en la barra de direcciones y accederemos a la consola de administración donde podremos ver algunos de los parámetros de la nube que estamos creando. El usuario y contraseña por defecto para acceder a la consola de administración es «admin» tanto para el usuario como para la contraseña. Estas son algunas capturas de las opciones de la consola de administración.

En la pestaña Store podremos seleccionar las imágenes que queremos instalar y en las que se instalarán los servicios que propocionará nuestra nube. También podremos subir nuevas imágenes a la nube para servicios personalizados.

Una vez hayamos instalado correctamente una imagen procederemos a iniciarla desde el controlador de la nube, iniciamos sesión en el y lo primero que haremos será obtener las credenciales con:

$ mkdir -p ~/.euca
$ chmod 700 ~/.euca
$ cd ~/.euca
$ sudo euca_conf --get-credentials mycreds.zip
$ unzip mycreds.zip
$ ln -s ~/.euca/eucarc ~/.eucarc
$ cd -

Ahora generaremos la clave privada con un pequeño script con el siguiente contenido:

if [ ! -e ~/.euca/mykey.priv ]; then
    mkdir -p -m 700 ~/.euca
    touch ~/.euca/mykey.priv
    chmod 0600 ~/.euca/mykey.priv
    euca-add-keypair mykey > ~/.euca/mykey.priv
fi

Permitimos el acceso mediante SSH a las instancias que es como nos conectaremos a la consola de cada una de ellas:

$ euca-authorize default -P tcp -p 22 -s 0.0.0.0/0

Arrancaremos una instancia con:

euca-run-instances $EMI -k mykey -t m1.small

Donde $EMI lo sustituiremos por el Id de una imagen de la pestaña Images. En mi caso el Id del emi asignado es «emi-DF56106F».

Cuando la instancia este arrancada nos podremos conectar a ella con:

$ EMI=emi-DF56106F
$ IPADDR=$(euca-describe-instances | grep $EMI | grep running | tail -n1 | awk '{print $4}')
$ ssh -i ~/.euca/mykey.priv ubuntu@$IPADDR

Para parar la instancia usamos el comando:

$ EMI=emi-DF56106F
$ INSTANCEID=$(euca-describe-instances | grep $EMI | grep running | tail -n1 | awk '{print $2}')
$ euca-terminate-instances $INSTANCEID

Si estamos probando Ubuntu Enterprise Cloud en una máquina virtual como Virtualbox y reiniciamos la máquina virtual deberemos modificar el archivo ./.euca/.eucarc y las variables S3_URL y EC2_URL con la nueva IP que se le asigne a la máquina que será la misma que hemos obtenido con el comand if config de unos cuantos pasos antes. Una vez modificado el archivo ejecutamos los siguiente para recargar las variables:

$ . ~/.euca/eucarc

O le cambiamos a la interfaz de red la IP a la que tiene el archivo ./.euca/.eucarc con el comando:

$ ifconfig br0 85.84.32.71

Referencia:
http://www.ubuntu.com/cloud
https://help.ubuntu.com/community/UEC
https://help.ubuntu.com/community/UEC/CDInstall
http://www.eucalyptus.com/
Eucalyptus beginners guide
5 opciones de hosting para aplicaciones Java

Instalar la Ubuntu font en Arch Linux

Dentro de unos días será publicado la versión 10.10 de Ubuntu conocida como Maverick Meerkat. Una de las novedades más visibles de cara al usuario será la incorporación del la fuente llamada Ubuntu font. Esta fuente destaca por sus formas simples y por su fácil lectura.

Pero los usuarios de Arch Linux también podemos disfrutar de ella. Basta con instalar el paquete ttf-ubuntu-family-fonts del repositorio AUR y cambiar la fuente en Sistema > Preferencias > Apariencia > Tipografías.

$ yaourt -S ttf-ubuntu-font-family

La página oficial de Ubuntu hace uso de ella así que si quieres echarle un vistazo sin instalar nada pasate por la página de Ubuntu o haz click en una de las capturas de pantalla que adjunto.

GNOME 2.32 publicado, rumbo a GNOME 3.0

La versión 2.32 del entorno de escritorio GNOME ha sido publicada hace unos pocos días. Las novedades que incorpora no son tan numerosas como en versiones anteriores ya que los desarrolladores se están centrando en la siguiente revisión mayor de este entorno de escritorio, la versión 3.0, a ser publicada según su calendario el 6 de abril si todo va vien y no hay nuevos retrasos. Esto es lo que nos espera en la versión 3.0.



Pero de momento toca disfrutar de la 2.32. En las notas de publicación puedes encontrar las modificaciones más relevantes realizadas.

Para los usuarios de Arch Linux no tadará en estar disponible en los respositorios para actualizarse y los usuarios de Ubuntu podrán disfrutarla el día 10.10.10, ¡ya solo quedan unos pocos días de espera!.

Copiar archivos desde y a un dispositivo bluetooth

Hay que reconocerlo, a veces las cosas en Linux no funcionan sin más y hay que emplear alguna artimaña para conseguir lo que queremos. Estoy hablando, en mi caso, sobre el copiar archivos desde y a un dispositivo bluetooth como por ejemplo un móvil. Por alguna razón el examinar archivos y enviar archivos utilizando el icono del bluetooth que proporciana GNOME normalmente me falla quedándose las operaciones que le pido que haga bloqueadas al inicio de la operación.

Sin embargo, si a alguien le pasa lo mismo quizá no este todo perdido y la siguiente forma que voy a explicar a continuación le funcione. La forma con la que he conseguido copiar archivos con un dispositivo bluetooth es utilizando el comando obexfs. Este comando lo que hace básicamente es montar el sistema de archivos del dispositivo bluetooth en una carpeta del sistema de archivos de nuestra computadora donde posteriormente podremos hacer las operaciones tal y como si estuviésemos trabajando con los archivos de nuestro disco duro, por ejemplo utilizando el navegador de archivos nautilus.

Para instalarlo ejecutamos el comando:

$ sudo pacman -S obexfs

Para montar el sistema de archivos del dispositivo bluetooth ejecutamos:

$ obexfs -b [dirección dispositivo bluetooth] [carpeta montaje]

Con el siguiente comando se puede montar el sistema de archivos de un dispositivo bluetooth en una carpeta en el escritorio:

$ obexfs -b 00:1C:9A:42:25:BE ~/Desktop/movil

La dirección del dispositivo bluetooth (en mi caso 00:1C:9A:42:25:BE) la podéis obtener usando el comando hcitool mediante (recordad configurar el dispositivo bluetooth en modo visible e instalar el comando si no lo tenéis):

$ hcitool scan

Cuando terminemos de copiar archivos mediante nautilus podemos desmontar el sistema de archivos del dispositivo bluetooth con:

$ sudo umount ~/Desktop/movil

Utilización del comando obexfs

Enlaces:
Arch Linux wiki bluetooth

Programación orientada a aspectos con la clase Proxy

La programación orientada aspectos (AOP) es uno de los conceptos que en estos días se usa muy habitualmente en el desarrollo de aplicaciones Java. Básicamente, nos permite separar cierta lógica de soporte de la lógica propia de la aplicación, por ejemplo, se puede utilizar si necesitamos medir el tiempo que tarda en ejecutarse un determinado método, cuantas veces se llama, sacar trazas, aplicar seguridad, obtener conexiones a base de datos, gestionar la transaccionalidad, etc... En vez de añadir el código de estas funcionalidades a las clases de nuesta aplicación lo podemos añadir a una clase que se encarge de implementar el aspecto.

La librería Spring proporciona un amplio soporte para la programación orientada a aspectos, sin embargo, hay veces en el que no tenemos control sobre las librerías que podemos utilizar en nuestro proyecto. En este caso nos tenemos que limitar a lo que nos proporciona el propio JDK.

A pesar de que hoy el concepto es muy conocido se puede venir haciendo desde el JDK 1.3 (desde el año 2000) a través de la clase Proxy y su uso es realmente sencillo para las ventajas que aporta al código de una aplicación.

Supongamos que necesitamos medir cuanto tiempo tardan en ejecutarse los métodos de un determinado objeto (en realidad de una interfaz). En vez de calcular el tiempo dentro de la propia clase que queremos medir podemos implementarlo mediante un aspecto con la clase Proxy de la siguiente forma (el método main no es realmente necesario solo está incluido para hacer simple el probar el ejemplo):

import java.lang.reflect.InvocationHandler;
import java.lang.reflect.Method;
import java.lang.reflect.Proxy;
import java.util.Date;
import java.util.HashSet;
import java.util.Set;
import java.util.TreeSet;

public class ProfileProxy implements InvocationHandler {

    protected Object object;
    protected Proxy proxy;

    public ProfileProxy(Object object) {
        this.object = object;
        // Creación del proxy que intercepta las llamadas a los métodos del objeto
        proxy = (Proxy) roxy.newProxyInstance(object.getClass().getClassLoader(), object.getClass().getInterfaces(), this);
    }

    public Proxy getProxy() {
        return proxy;
    }

    public Object invoke(Object proxy, Method method, Object[] args) throws Throwable {
        long start = new Date().getTime();
            
        // Invocar al servicio
        Object o = method.invoke(object, args);
            
        long end = new Date().getTime();
        System.out.println("Tiempo: " + (end - start) + "ms");
        
        return o;
    }
    
    public static void main(String[] args) throws Exception {
        Set data = new HashSet(); 
        for (int i = 0; i < 100000; ++i) {
            data.add(new Integer((int) (Math.random() * 100000)));
        }
        
        HashSet hashSet  = new HashSet();
        TreeSet treeSet  = new TreeSet();
        
        Set proxyHashSet  = (Set) new ProfileProxy(hashSet).getProxy();
        Set proxyTreeSet  = (Set) new ProfileProxy(treeSet).getProxy();
        
        proxyHashSet.addAll(data);
        proxyTreeSet.addAll(data);
    }
}

El método main del ejempo trata de medir cuanto tiempo se tarda en añadir los elementos de un Set a otro para un HashSet y para un TreeSet. Dado que la clase TreeSet mantiene los elementos ordenados según su orden natural es de esperar que tarde más tiempo.

En mi equipo añadir cien mil elementos de un Set a un HashSet tarda 62ms y añadir el mismo número de elementos a un TreeSet 110ms.

Pero todo no son cosas buenas, una pequeña limitación de utilizar la clase Proxy es que la interceptación de las llamadas se tienen que hacer sobre los métodos de una interfaz que implemente el objeto.