A través del monitor

$ su
# aptitude install googleearth-package
# make-googleearth-package
# dpkg -i googleearth_4.1.7076.4458+0.2.0-1_i386.deb

Ahora me toca averiguar por qué al ocultar la barra lateral anda funciona tan lento.

Una de las ventajas de usar aptitude en lugar de apt para administrar paquetes, es que trata de mejor forma las dependencias, ya que no sólo instala paquetes necesarios, además elimina los que ya no lo son, permitiendo así mantener limpio el sistema sin complicaciones. Sin embargo, y de manera paradójica, por defecto está configurado para instalar paquetes recomendados. Por ejemplo, al querer instalar Gwenview con dicha opción activada se obtiene:

# aptitude install gwenview
Reading package lists… Done
Building dependency tree
Reading state information… Done
Reading extended state information
Initializing package states… Done
Reading task descriptions… Done
Building tag database… Done
The following NEW packages will be automatically installed:
cdparanoia cdrdao dcraw dvd+rw-tools exiv2 genisoimage imagemagick k3b
kaddressbook kdepim-kio-plugins kipi-plugins kmail kooka libao2
libbluetooth2 libcdio6 libdvdread3 libexiv2-0 libflac++6 libgnokii3
libgpgme11 libieee1284-3 libiso9660-4 libk3b3 libkcal2b libkdepim1a
libkexif1 libkipi0 libkleopatra1 libkmime2 libkpimidentities1 libkscan1
libksieve0 libktnef1 libmagick++9c2a libmimelib1c2a libpth20 libsane
libvcdinfo0 ocrad sane-utils vcdimager wodim

Mientras que al desactivarla:

# aptitude install gwenview
Reading package lists… Done
Building dependency tree
Reading state information… Done
Reading extended state information
Initializing package states… Done
Reading task descriptions… Done
Building tag database… Done
The following NEW packages will be automatically installed:
libexiv2-0 libkipi0

Los paquetes recomendados no son necesarios, pero podrían mejorar el desempeño del que intentamos instalar, ya que de alguna manera se relacionan con este. Personalmente, no me gusta que aptitude instale paquetes que podría, quizás, a lo mejor, tal vez, llegar a utilizar, por lo que desactivé la opción. Para ello:

$ su
# aptitude

Y en la GUI que aparecerá vamos a Options, Dependency handling y desmarcamos Install Recommended packages automatically.

Hace dos días pensaba que sería usuaria de Kubuntu por bastante más tiempo, sin embargo, ayer en la tarde decidí que, entre limpiar el sistema o hacer una instalación limpia, tardaría menos tiempo con la segunda opción. Y ya que estamos reinstalando, que valga la pena. A sí que, como el Brujo me demostró que instalar Debian hoy en día es más fácil que en los tiempos en que instalé Mandrake 8.0, y en los cuales miraba a la espiral como la más computín de las distribuciones computines, covardemente decidí que hoy sería el día de dar el gran paso.

Menos mal que nVIDIA se empeña en no liberar sus drivers, porque si no el proceso habría sido realmente aburrido… Léase con ironía. Me puse a instalar a las 10:00 y decidí que era suficiente cerca de las 18:00. Escogí como método de instalación la imagen business card, que es la más pequeña, y recibe los paquetes necesarios desde Internet. Con la conexión que tengo rara vez descargó a menos de 300 KBps, por lo que el proceso no tardó más de 20 minutos. Pero, por la cresta, que costó instalar los controladores oficiales de nVIDIA. De haberme conformado con la rama Stable (Etch), habría sido pan comido gracias a module-assitant, pero como quería KDE 3.5.6 y Compiz Fusion, tenía que instalar Testing (Lenny). El conflicto se produce por una incompatibilidad con la GPL 2.0 (sí, la licencia, ¡carajo!) entre el núcleo precompilado 2.6.2x-k7 (y como tengo un procesador AMD Athlon XP…) y el controlador nVIDIA. Al final, la mejor forma de instalar el controlador con el mencionado núcleo es siguiendo la guía Instalar driver privativo de Nvidia con kernel Linux >= 2.6.20 publicada en CRySoL. San Ignucius los bendiga. Ahora me toca averiguar exáctamente cual es la incompatibilidad con la GPL 2.0 y apiedrar las dependencias de nVIDIA. De no ser por el pequeño detalle habría tenido el sistema funcionando en media hora.

Pero todo el show valió la pena, a medias. Si bien tengo KDE 3.5.7, aún no logro instalar Compiz Fusion. Se supone que se puede en Testing, pero por el momento, no me resulta. Y no me quiero cambiar a Unstable, al menos no por el momento, porque fue demasiado lidiar día entero con el controlador famoso, como para continuar durante la noche.

Además de Compiz Fusion, me queda averiguar cuales son los enlaces simbólicos que tengo que crear para tener Flash y Java en Firefox, porque Iceweasel no lo instalo ni ca… Mover los productos de Mozilla a non-free hubiese sido una solución más sana, digo yo. Apoyo todo fork, mientras tenga razón de ser, y la lesera del logo no me convence para nada, después de todo, en ningún modo el logo privativo (al menos en el caso de Firefox) socava libertades de usuario.

También me falta hacer funcionar la rueda del ratón, que por el momento sólo trabaja como botón central, e instalar BOINC, y ver que tal anda el sistema con dicha aplicación corriendo. Algo me dice que Kubuntu estaba obeso por culpa de mi amor a la ciencia (BOINC estaba configurado para consumir el 100% de los recursos…) pero de todos modos es agradable ver que el KMenu está casi vacío: las aplicaciones que jamás iba a usar y que no podía desinstalar de Kubuntu me enfermaban.

Aún así, Canonical ha hecho un gran trabajo. Según he percibido, Linux tiene más usuarios finales gracias a sus productos que a los de Novell o Mandriva, que dominaban entre los usuarios domésticos. Pero no se podrá dormir en los laureles, porque estoy casi segura de que la próxima vez que me pregunten por una distribución Linux para un usuario poco experimentado, voy a recomendar Debian.

Hago eco de la útil herramienta explicada por Mark para mantener el sistema limpio de locale inecesarios.

Un locale es un conjunto de reglas culturales que definen el país, idioma, caracteres y otras preferencias de la interfaz del usuario. En Linux las interfaces de todas las aplicaciones dependen de que locale estén instaladas en el sistema.

Al parecer, algunas aplicaciones instalan sus propios locale aunque no los vayamos a utilizar, ocupando espacio en el disco duro. localepurge es un paquete para Debian y distribuciones basadas en ella que permite mantener sólo los locale necesarios.

Inmediatamente después de instalarlo aparece una pantalla en el terminal (yo utilicé aptitude, imagino que las herramientas gráficas también la ejecutan) donde se deben seleccionar los idiomas que utilizaremos. En mi caso fueron:

• en
• en_GB.ISO-8859-15
• en_GB.UTF-8
• es
• es_CL
• es_CL.UTF-8

Dónde los esenciales son en y es ya que contienen la información general respecto al idioma. Mark me explicó que conservar el inglés se debe a que hay aplicaciones que no han sido traducidas al español, no sé si es necesario, pero frente a la duda… Elegí inglés británico de caprichosa.

Lista la instalación lo ejecutamos con permisos de administrador: sudo localepurge, y en pocos segundos entregará los resultados. En mi caso:

localepurge: Disk space freed in /usr/share/locale: 32784K
localepurge: Disk space freed in /usr/share/man: 2268K
Total disk space freed by localepurge: 35052K

Y desde ahora, cada vez que se instala una aplicación mediante apt-get localepurge se ejecutará automáticamente. Yo instalé KOffice con aptitude y no sucedió, aunque no sé si se debe a que aptitude y localepurge no son compatibles o a que no había locale que eliminar.

Hace algo escribí lo que se puede considerar una introducción a la computación distribuida, desde una mirada pragmática: herramienta para la astronomía en el marco de SETI. Lo siguiente es un Como sobre la instalación y configuración de BOINC en GNU desde la consola, con el fin de que se arranque automáticamente cada vez que el computador sea encendido. Antes de comenzar, me toca agradecer enormemente la paciencia y disposición que Zerjillo tuvo con migo en los foros de Astroseti.org, y pasarle a él todo el crédito. BOINC fue la primera aplicación para GNU/Linux que instalé de forma manual, por lo que me encontraba totalmente perdida. Comencemos.

Aclaraciones previas.

Técnicas.

Si hay algo que me molesta de las distribuciones de GNU/Linux es el poco respeto que a veces tienen con lo que podríamos considerar un estándar de facto. Son cuestiones mínimas, pero que a la hora de escribir documentación se convierten en grandes complicaciones. Por tanto, es necesario considerar dos aspectos:

1. Como ya todos sabrán, para llevar a cabo tareas administrativas en GNU/Linux, como la que nos disponemos a realizar, se necesitan permisos de administrador. Normalmente esto se consigue ingresando directamente al sistema como usuario root, o convirtiéndonos en él a través del comando su. Sin embargo, conozco el caso de cierta distribución que carece de usuario dicho usuario. Al instalar BOINC mediante sudo, se me presentaron algunos inconvenientes, por tanto, si es esa la distribución que usan, recomiendo:
   • trabajar con el Root Terminal, ubicado en Aplicaciones, Herramientas del sistema,
   • Activar la cuenta del usuario root.
2. La configuración de los scripts de arranque al parecer varían de distribución en distribución. Como yo estoy trabajando en Ubuntu, basada en Debian, los pasos aquí descritos funcionan en cualquier distribución basada en Debian. Agradecería información respecto a aquellas distribuciones donde el proceso varía.

Finalmente han de recordar que los signos $ y # no deben ser escritos, pues corresponden al prompt del interprete de comandos según nuestro estado (usuario normal y super usuario respectivamente).

Licencia de distribución.

A diferencia del resto del contenido de este blog, y por tratarse claramente de documentación, la presente entrada se encuentra bajo los términos de la GNU Free Documentation License.

Ahora sí: manos a la obra.

Creación de una cuenta.

El primer paso para participar en cualquier proyecto de computación distribuida que corra sobre BOINC es crear una cuenta. El proceso se lleva a cabo mediante el sitio web correspondiente. Los proyectos en los que me encuentro participando y tal vez les puedan interesar son los siguientes:

• Seti@home
• Einstein@home
• ClimatePrediction.net
• LHC@home

Instalación.

1. Descargamos la última versión de BOINC para GNU/Linux, ya sea mediante nuestro navegador favorito, o utilizando el comando wget:

   $ wget http://boinc.berkeley.edu/dl/boinc_5.2.4_i686-pc-linux-gnu.sh

2. Una vez hecho, lo movemos al directorio donde será instalado: /opt. Aquí es cuando nos convertimos en root:

   $ su
   Password:
   # mv boinc_5.2.4_i686-pc-linux-gnu.sh /opt/
   # cd /opt

   O ejecutamos el Root Terminal.

3. Le asignamos permisos de ejecución, lo ejecutamos y eliminamos:

   # chmod +x boinc_5.2.4_i686-pc-linux-gnu.sh
   # ./boinc_5.2.4_i686-pc-linux-gnu.sh
   # rm boinc_5.2.4_i686-pc-linux-gnu.sh

Primera ejecución.

1. La primera ejecución de BOINC se hace de forma manual, mediante lo cual adjuntaremos nuestra cuenta al cliente. Para ello ingresamos al directorio creado por el instalador:

   # cd BOINC/
   # ./boinc -attach_project URL-del-proyecto clave-asignada

2. Una vez que la cuenta haya sido adjuntada, y que la aplicación comience a descargar los primeros datos cancelamos su ejecución con Ctrl+C para preparar su arranque como servicio del sistema.

Creación y preparación del script.

Como ya dije, el proceso varía según la distribución, lo cual lo considero una lástima. Para Debian y derivados:

1. Con gedit, o cualquier otro editor de textos, creamos un archivo llamado boinc en /etc/init.d:

   # gedit /etc/init.d/boinc

   En él copiamos y guardamos el siguiente script, tal cual, es decir, esta vez, los # si deben escribirse:

   #!/bin/sh
   # /etc/init.d/boinc
   # Start/stop/restart
   boinc_start() {
   if [ -x /opt/BOINC/run_client ]; then
   echo “Comenzando BOINC.”
   /opt/BOINC/run_client > boinc.log &
   fi
   }
   boinc_stop() {
   echo “Parando BOINC.”
   sudo killall boinc
   }
   boinc_restart() {
   boinc_stop
   sleep 2
   boinc_start
   }
   case “$1″ in
   ’start’)
   boinc_start
   ;;
   ’stop’)
   boinc_stop
   ;;
   ‘restart’)
   boinc_restart
   ;;
   *)
   boinc_start
   esac

   Noten que la salida estándar de BOINC ha sido redirigida al fichero boinc.log que se ubicará dentro de /opt/BOINC, por lo cual cada vez que queramos revisarlo podremos leerlo con:

   $ less /opt/BOINC/boinc.log

2. Ahora haremos ejecutable el script recién creado, y comprobaremos si funciona:

   # chmod +x /etc/init.d/boinc
   # /etc/init.d/boinc start
   # ps -A

   En algún lugar de la lista que aparece al ejecutar el último comando debiésemos leer boinc, lo cual indica que funciona. Siendo así, le diremos al sistema que ejecute el script cada vez que arranque creando un enlace simbólico en /etc/rc2.d:

   # ln -s /etc/init.d/boinc /etc/rc2.d/S99boinc

3. Hecho esto, podemos reiniciar el sistema. No es necesario, pero nos servirá para comprobar que todo ha salido como debe: Cuando nos encontremos nuevamente con este funcionando, podemos ejecutar ps -A para asegurarnos, como ya hicimos, de que leemos boinc, S99boinc y setiathome_4.02 (o la versión correspondiente) en algún lugar de la lista.

Adjuntando otros proyectos.

Si decidimos participar de otros proyectos, el proceso para adjuntarlos es el siguiente:

1. En caso de que hayamos configurado BOINC para que se arranque como servicio y se encuentre corriendo, detenemos su proceso:

   # /etc/init.d/boinc stop

2. Nos movemos a su directorio y adjuntamos, igual que la primera vez, el nuevo proyecto:

   # cd /opt/BOINC
   #./boinc -attach_project URL-del-proyecto clave-asignada

En caso de que haya más proyectos para adjuntar, repetimos los pasos anteriores. Y así, a próxima vez que arranquemos el sistema, se ejecutaran automáticamente, y compartirán los recursos libres del sistema.