Para ello se edita el fichero /etc/grub.d/40_custom:


#!/bin/sh
exec tail -n +3 $0
# This file provides an easy way to add custom menu entries. Simply type the
# menu entries you want to add after this comment. Be careful not to change
# the 'exec tail' line above.
menuentry "FreeBSD 8.0-RELEASE AMD64" {
set root=(hd0,0)
chainloader +1
}


Una vez terminado se actualiza grub con el comando update-grub.

El paquete usepackage viene en nuestra ayuda. En debian podemos instalarlo como

apt-get install usepackage

A continuación se escribe en los ficheros de configuración las variables de entorno a cargar según el entorno deseado. Va a usarse como caso práctico diferentes versiones de grails.

Editamos .bashrc para cargar use al inicio de sesión:

. /usr/share/usepackage/use.bsh

Se crea el fichero /etc/usepackage/grails.conf con el siguiente contenido:

# GRails 1.1.1
>> grails1.1.1: "Grails 1.1.1" <<
grails1.1.1 * * * * : GRAILS_HOME = /usr/local/grails-1.1.1,
PATH+= /usr/local/grails-1.1.1/bin;

# GRails 1.2.1
>> grails1.2.1: "Grails 1.2.1" <<
grails1.1.2 * * * * : GRAILS_HOME = /usr/local/grails-1.2.1,
PATH+= /usr/local/grails-1.2.1/bin;

Y finalmente creamos ~/.packages para insertar:

(include /etc/usepackage/grails.conf)

Refrescando la configuración (source .bashrc) y ejecutando use -l podremos ver los diferentes entornos disponibles, de los que nos interesan:

grails1.1.1 - Grails 1.1.1
grails1.2.1 - Grails 1.2.1

Y cargamos el deseado con use grails1.2.1 por ejemplo.

En determinados entornos no tenemos disponible un IDE o ni siquiera un entorno de ventanas, pero aún así se puede editar código Java. Primero hablemos de la configuración de Vim para numeración de líneas, identación de código con cuatro espacios y resalte la sintáxis.

set nu
set tabstop=4
syntax on


La anterior configuración debe añadirse al fichero .vimrc en nuestro directorio HOME de usuario. Los leguajes más populares están soportados, y de no ser así en la web de podemos encontrar los ficheros necesarios para otros lenguajes.

public class Hello {
    public static void main(String[] args) {
        System.out.println("Hello World!");
    }
}

Subversion guarda la información de archivos versionados dentro de un directorio oculto con nombre svn, por lo tanto si se te presentan problemas, puedes borrarlo y añadir los nuevos directorios al repositorio de código, y digo nuevos, porque al borrar el registro subversion no sabrá que ya estaban ahí.

Para no ir uno a uno, porque se alcena uno por directorio, realizaremos una búsqueda que se usará como entrada para el comando de borrado recursivo:

find . -name .svn | xargs rm -fr

Instalamos subversion:

apt-get install subversion

Se crea el repositorio

svnadmin create /usr/local/src/jmdocbook

se crea el directorio /tmp/jmdocbook/trunk que alojará los módulos y se hace la primera importación.

svn import /tmp/jmdocbook file:///usr/local/src/jmdocbook -m "Initial import."

Comandos útiles para ver los proyectos versionados y descargarlos:

svn list file:///usr/local/src/jmdocbook/trunk

svn co file:///usr/local/src/jmdocbook/trunk/modulo

cd modulo
svn status // para ver los cambios
svn add directorio // para versionar un directorio y su contenido
svn del directorio // para eliminarlo
svn commit -m "Mensaje explicativo."

Para mas información visitar la wiki de debian sobre subversion.

Como siempre he tirado más para UNIX decidí darle una oportunidad a FreeBSD, pero como el usuario final iba a ser mi hermana y no yo, opté por buscar una variante mas amigable. Y encontré PC-BSD.

Grabé el CD para una instalación mínima y completarla por Internet, y debo decir que fue muy satisfactoria: el instalador es totalmente gráfico y detectó y configuró todo sin problemas. No en vano el portatil tiene ya sus años y daba por hecho que estaría soportado.

El interfaz gráfico es KDE en su versión 4.2 con un acabado muy agradable, y donde la instalación de nuevos programas se ha simplificado mucho comparado con la compilación vía ports tradicional de FreeBSD. El sistema de paquetes que propone esta distribución se base en incluir todo en el binario, sin presuponer la existencia de librerías en el sistema, de una forma similar a como opera OS X. Seguramente no es la solución óptima, pero funciona y sin quebraderos de cabeza. Instalé Mozilla Firefox como navegador predeterminado y tras comprobar que visualizaba correctamente webs de correo electrónico y de redes sociales, lo dí por finiquitado y se lo cedí a mi hermana que se ha mostrado encantada.

Finalmente, aunque recomendaba Ubuntu Linux a los amigos que se querían iniciar o deseaban alargar la vida útil de su computadora, esta variación BSD me parece que ha hecho un excelente trabajo simplificando la instalación del sistema operativo y la gestión del software mediante su sistema PBI. KDE como interfaz gráfico me parece correcto, porque a pesar de ser una aplicación pesada corre fluidamente en un hardware de hace casi cinco años.

Pero cómo se puede documentar un proyecto software de forma sencilla y satisfactoria? En los tiempos en que UNIX era practicamente el único sistema operativo se usaban ficheros de texto plano, de hecho muchos de las guías rápidas de Linux o howtos también.

Si a estas alturas eso no nos parece una barbaridad debe faltar poco. Y por supuesto sustituir los ficheros de texto plano por archivos de Word no me parece una solución aceptable. Al fin y al cabo el hecho de tener que cambiar de aplicación para realizar una consulta es de todo menos eficiente, máxime cuando a pesar de las mejoras en potencia de cálculo sigue tardando una eternidad en abrir un simple fichero más o menos formateado.

Y si además se considera que los diferentes desarrolladores pueden no estar geográficamente (ni temporalmente seamos relativistas) en el mismo lugar. Se puede argüir que el correo electrónico salva este inconveniente. Pero en este caso hay que utilizar una segunda aplicación: el cliente de correo electrónico, para descargar el fichero y abrirlo con otra aplicación.

Sin duda alguna los proyectos de software libre, que adoro, han resuelto de forma satisfactoria este problema porque su propia supervivencia dependía de ello. Al ser proyectos colaborativos internacionales, y donde principalmente los desarrolladores aportan su conocimiento, ganas y tiempo libre, es de vital importancia que cada miembro sepa lo que debe hacer, para averiguar cómo hacerlo, y todo ello en el menor tiempo posible.

Es aquí donde el hipertexto o HTML demuestra sus virtudes:

• Información accesible en línea
• Referencias enlazadas en el documento principal gracias a los hiperenlaces
• Estándar

A día de hoy donde muchas de las aplicaciones software a desarrollar hacen uso del navegador, tiene sentido usar esa misma herramienta para presentar la documentación. Al hilo de esta idea han surgido diferentes propuestas como wikis y blogs que además permiten la edición colaborativa.

Pero a todo esto le veo un problema. Por ser un aficionado a la lectura aprecio una correcta impresión, y se debe reconocer que un fichero HTML impreso es de una calidad inferior a un libro barato. De hecho durante bastante tiempo he usado LaTeX para generar documentación impresa de calidad como es costumbre entre científicos e ingenieros (de verdad).

Y aunque LaTeX está bien, por sus muchas virtudes, alguno de sus inconvenientes es aprender un lenguaje de macros (es anterior a la popularización de HTML) y que fue concebido como generador de documentos a imprimir.

Existe algo a día de hoy omnipresente en la sociedad de la información, que estructure correctamente la información, independiente de plataforma, a ser posible un estándar, donde prime el contenido, relevándonos de los detalles de composición y que permita un procesado ágil? Sí, XML.