Cuando se inicia el sistema operativo Haiku se presentan una serie de iconos para indicar en qué estado del inicio nos encontramos. Estos iconos significan lo siguiente:

• Inicializa los módulos del kernel.
• Monta el sistema de archivos principal en / (rootfs) y monta el sistema de archivos de los dispositivos en /dev (devfs).
• Inicializa el gestor de dispositivos.
• Monta el disco del sistema (/boot).
• Activa los módulos para controlar las características específicas de la CPU.
• Finalización del inicio de los subsistemas (que cargan módulos del disco principal en /boot).
• Carga en memoria e inicia el script (BootScript) que carga los servidores de inicio como el app_server o el input_server.

En una máquina virtual con VirtualBox (en un equipo moderno, todo hay que decirlo) tarda algo menos de 10 segundos en iniciar el sistema. Supongo que en hardware real tardará menos .

Pero resulta que, ya en el 2001, BeOS —y ahora Haiku— tenía su propio cuadro de diálogo de copia de archivos mediante el Tracker (el homólogo al Explorador de Windows) y, fijaos qué casualidad, era así:

¿Y ahora estos vienen con innovaciones? ¡Já!

Actualización: He notado que en Google Chrome no se ve correctamente la imagen del Tracker de Haiku así que, si esto os sucede, probad con Firefox donde no he detectado ningún problema.

Actualización 2: El problema de que se oculte la segunda imagen en Chrome es debido a la extensión AdBlock, así que basta con desactivarla para que se vea dicha imagen (o añadir una excepción, pero no se como se hace ).

Conforme a este estudio, el nuevo rediseño del Explorador… bueno, deja un poco que desear, teniendo en cuenta que han creado una barra de herramientas mucho más grande e intrusiva que las anteriores con acciones que los usuarios apenas usan (menos del 1 % de las veces se usa la opción de la barra de herramientas en detrimento de otras opciones como el menú contextual o una tecla de acceso rápido).

Pero eso no es lo que quiero destacar aquí. Lo que quiero destacar es este gráfico:

Punto de entrada de los comandos en el Explorador de Windows

Es decir, según este gráfico, la mayoría de las acciones que un usuario hace en el Explorador de Windows —esto es, tratamiento de archivos— es mediante el menú contextual; luego mediante una combinación de teclas (teclas rápidas); lo siguiente es el uso de la barra de herramientas; y, finalmente, mediante el menú normal de toda la vida.

De este gráfico mi conclusión es que la barra de menús es un punto de entrada de comandos superfluo que, en cuanto estás acostumbrado a usar el software, obvias en favor de los menús contextuales y de las teclas de acceso rápido. Es decir, a mi parecer, la barra de menús sobraría en muchas interfaces de software.

Entonces, me pregunto ¿por qué los chicos de Apple se empeñan en mantener un menú global que ocupa una parte muy importante del escritorio y que, según el estudio de Microsoft, apenas se usaría?

Por poner un sólo ejemplo, esa zona de la pantalla se usa en Google Chrome y en Mozilla Firefox para acceder más rápidamente a las pestañas teniendo en cuenta que el ratón “no se sale” del borde de la pantalla.

Y esto ocurre con todas las interfaces que copian descaradamente la interfaz de Mac OS X (léase Gnome Shell, Unity…). Vamos, para mí es perder espacio y, sobre todo, funcionalidad y usabilidad. Pero no tengáis miedo de que en Mac OS X (y demás) lo quiten alguna vez (aunque sea por configuración). Ante todo hay que tener señas de identidad. Aunque no sean usables.

P.D.: Tengo en mente escribir algún día sobre las disposiciones de los elementos de los escritorio informáticos —esquinas, bordes…— y la tendencia de hoy en día. El problema es la falta de tiempo… y ganas .

Esta es la primera entrada que escribo desde el sistema operativo HaikuOS, el clon de mi querido BeOS, en una máquina virtual de VirtualBox.

Además, tanto la escritura en el blog como el pantallazo y la posterior edición de la imagen han sido hechas desde la versión R1A3 del propio Haiku —la imagen se editó con WonderBrush y el navegador es WebPositive—, con lo que se podría decir que el sistema operativo ya es bastante completo.

Obviamente todavía falta mucho por hacer, sobre todo teniendo en cuenta que no es un proyecto demasiado atractivo para el gran público y el número de desarrolladores está muy limitado, pero, aunque lento, va por buen camino.

Y quizás os preguntéis ¿por qué otro sistema operativo? La respuesta es sencilla: porque aunque BeOS es de principios de 1990, tanto BeOS como Haiku son los únicos sistemas operativos que se podrían considerar “modernos” ya que tanto su arquitectura principal como su API son innovadoras desechando modelos obsoletos y atreviéndose a hacer las cosas mejor sin mantener la compatibilidad.

¿Y eso es bueno? Yo opino que sí porque así que se consigue avance e innovación haciendo las cosas más rápidas y mejores. Pero es sólo una opinión .

En resumen, BeOS ya era muy rápido en mi Pentium II a 350 MHz (11 segundos en arrancar). Además, tanto en BeOS como ahora en Haiku, es muy fácil programar para ellos gracias a su API sencilla pero potente en C++. Y muchas otras virtudes y algún que otro defecto.

No pretendo con esto que hagáis de Haiku vuestro sistema principal (a día de hoy sería inviable) pero sí que le déis una oportunidad revisándolo de vez en cuando.

Todo este tinglado de letras y números en el título de la entrada no es más que para hacerse eco de la salida de la versión Release 1 Alpha 3 del sistema operativo Haiku, el clon libre de mi querido BeOS, un año y un mes después de la Alpha 2 (que no comenté aquí, por cierto).

Los cambios principales son:

• Hardware: mejor soporte de hardware con nuevos controladores.
• Sistemas de archivos: soporte para btrfs, ext4 y exFAT.
• Localización: soporte para traducir y localizar el sistema operativo.
• Layout API: nuevo API para la colocación de componentes en el desarrollo de aplicaciones.
• Aplicaciones: mejores en la funcionalidad y en las aplicaciones.
• Gestión de ventanas: apilado y ordenación de ventanas. Y con accesos directos de teclado.
• Multimedia: más formatos de audio y vídeo y mejoras en la reproducción de contenidos.
• Solución de errores: más de 950 incidencias resueltas desde la versión anterior.

En definitiva, el avance es lento de constante, lo que me lleva a pensar que, quizás, dentro de ¿un año? ¿dos años? podamos disfrutar de la primera versión de HaikuOS.

Por supuesto, hoy en día no es alternativa de uso; es, simplemente, para trastear, para aprender, para desarrollar… en definitiva, para quién le gusten las cosas bien hechas. Y sí, he dicho bien hechas. Hay mucha documentación sobre BeOS y Haiku para ver el porqué .

Pues la solución es bien sencilla, aunque muy chapucera. Basta con ejecutar el comando:

diego@ubuntu:~:$ compiz --replace &

Con esto se reinicia el decorador de ventanas y desaparecen los síntomas… al menos durante un rato.

Que esta sea una posible solución indica que es compiz quien falla, así que lo chicos de desarrollo deberían darle un repaso. A ver si pronto hay una buena actualización…

Esta nuevo sistema pretende imitar la manida bandeja del sistema de Windows donde aplicaciones en segundo plano incrustan su icono para tener constancia de su ejecución y poder realizar acciones sobre las mismas.

Y, a lo que voy: los iconos son muy bonitos, pero la funcionalidad es una basura. Siento ser tan duro, pero me fastidia mucho que involucionemos en lugar de evolucionar. Porque en cada icono de la antigua bandeja del sistema yo podía hacer clic, doble clic y clic con el botón secundario para realizar diferentes acciones, mientras que con este sistema sólo puedo hacer un clic normal y siempre saldrá un menú de acciones.

¿Es esto evolución? ¿Mejora esto la usabilidad del sistema?

A mi entender no. Mismamente, con la aplicación Dropbox (el primer icono empezando por la izquierda de la imagen), antes al hacer clic se abría la carpeta de Dropbox y, con el botón secundario, salía un menú. Ahora siempre sale un menú con el clic. ¿Dónde está el resto de funcionalidad?

¿Creen los desarrolladores de Ubuntu que eliminando funcionalidad se mejora la usabilidad? Yo creo que no.

Hasta aquí mi pataleta de hoy. Otro día seguiré con Unity, que para él tiene…

• La actualización ha transcurrido sin ningún problema aún usando el sistema mientras dura la misma. Eso sí, ha tardado unas 4 horas (o algo más) ya que tenía que descargar más de dos mil paquetes.
• Una vez reiniciado, en general el sistema va más rápido. Y esta es la conclusión a la que llego cada vez que actualizo por lo que no sé cuán objetiva es.
• Por defecto inicia Unity y no el escritorio clásico, con lo que, dependiendo de tus gustos, tendrás que volver al anterior (o no) que seguirá ahí.
• Por defecto instala gnome-wm como gestor de ventanas. Este archivo es un script que inicia compiz como gestor de ventanas siempre que pueda y, en caso de error, iniciará metacity (el antiguo de Gnome). Esto se puede cambiar fácilmente en la configuración (con gconf-editor). De mutter, el gestor de ventanas de Gnome3, no se sabe nada.
• En general compiz (y sus plugins) funciona bastante mejor en esta versión ganando en estabilidad y retocando algunas cosas en cuanto a la apariencia.
• Se desinstala el Java oficial de Sun (ahora Oracle) para instalar openjdk. Llevo usándolo unos días y funciona bien, aunque hace un tiempo no lo hacía.
• Se sustituye Rhythmbox (bonita palabra inglesa con 9 letras y sólo una vocal) por Banshee como reproductor de audio.
• Un fallo, a mi entender bastante grande, es que no se pueden reubicar los botones del panel de la lista de ventanas en el escritorio de Gnome clásico.
• Otro fallo, esta vez creo que es debido a compiz, es que, a veces, haciendo clic en la barra de título de una aplicación, esta gana el foco pero no se visualiza en dicha barra (esto es, no cambia de color ni indica nada que muestre que dicha ventana tiene el foco).
• Y el fallo más “raro” que me ha pasado es que parece que hay una ventana invisible en el medio de la pantalla de unos 300×100 píxeles (aproximados, que no se ve, sólo se intuye debido a los síntomas) que impide hacer clic sobre la ventana que esté debajo. Incluso cambia el cursor cuando estás en gedit, por ejemplo. La he identificado con el comando xwininfo y, al matarla con xkill, se ha reiniciado el gestor de ventanas y esta ventana invisible ha desaparecido (ya no hay síntomas).

Del resto todo bien. Creo que con cada versión que sacan los chicos de Ubuntu esto va a mejor, por supuesto sin desmerecer a los chicos del kernel, así que merece la pena la actualización.

Esta aplicación sirve para crear widgets del mismo estilo que el gestor de energía de Android 2.x (el widget con los botones para activar el Wifi, el Bluetooth, el GPS, la sincronización y el brillo) pero con un botón para (casi) cualquier acción posible dentro de la configuración de Android.

Además cuenta con varios estilos personalizados para hacerlo lo más parecido al tema que estés usando en cada momento pudiendo elegir tanto el color de fondo, el color de los iconos o el color de la barra que indica si el elemento está activado o no.

Lo mejor, a parte de la gran cantidad de configuración que tiene, es que es gratuita, aunque también existe una versión donate que cuesta 1 €.

Lo peor es que la interfaz no es muy amigable (la gente se empeña en crear su propia interfaz cuando el sistema ya trae la suya; y a veces no es la mejor opción).

Pero el problema más grave que he detectado es que consume muchísima batería. Al menos en estas versiones en mi Magic se pasa de durar la batería día y medio (uso normal) a durar ¡medio día! Además, aunque elimines todos los widgets, queda el servicio de Widgetsoid en ejecución. Espero que solucionen pronto esto porque es una aplicación muy interesante.

Y para que no lo pierda, mi configuración es:

• En el widget principal: Wifi, Bluetooth, GPS, temporizador de pantalla y brillo.
• En el secundario: sincronización, sincronizar ahora, activar/desactivar 2G/3G y activar/desactivar acceso a Internet (datos).

Pero, por supuesto, todo esto se puede configurar hasta llegar al extremo .

Después de buscar un rato, una de las razones que se dan es que, debido a las actualizaciones en lugar de a una reinstalación limpia del sistema operativo, puede que queden archivos de configuración incorrectos que dan lugar a este consumo excesivo de memoria.

Y después de seguir buscando… no aparece nada más excepto que este problema se da en bastante usuarios.

Una forma de mitigarlo es matar el proceso nm-applet en el administrador de procesos y, posteriormente, iniciarlo como root presionando Alt+F2 y ejecutando gksu nm-applet --sm-disable.

Así que, de momento, no hay resolución. Habrá que estar atento para que el proceso no se desboque y podamos seguir trabajando sin reiniciar.

Pues ese problema se produce en más ocasiones y, una de ellas, es que cuando el sistema operativo no se apaga correctamente, es decir, no se apaga con reboot o poweroff sino que hay un fallo en el sistema operativo o hay un fallo de corriente, al reiniciar de nuevo, a GRUB2 le da por esperar hasta que el usuario seleccione una de las entradas de su lista de sistemas operativos.

Eso no está nada mal cuando es un ordenador de escritorio, así puede saber que ha ocurrido un error y entrar en el modo seguro para solucionarlo. El problema viene cuando el sistema operativo se está ejecutando en un servidor que no tiene ni pantalla ni teclado. Te puedes tirar un día intentando conectar por ssh probando diferentes IP y diferentes cables hasta que, por fin, te decides ir a la sala donde está y poner un monitor y un teclado para ver, con entre sorpresa y cabreo, que llevas una jornada intentando conectar con GRUB porque está esperando a que algún usuario compasivo presione Enter.

Este es un error de GRUB, no es que haya una configuración rara por ahí, así está programado en sus scripts. Existe una variable de este cargador de arranque que se llama recordfail que es la que se fija cuando se apaga correctamente y que es la que hace esperar cuando hay un error.

Para intentar aplicar un parche para solucionarlo hay que editar dos archivos. El primero es el archivo /etc/default/grub. En ese archivo hay que comentar (con una almohadilla como primer carácter de la línea: #) la línea que contiene el texto GRUB_HIDDEN_TIMEOUT="0". Además, si estás en un servidor, también se pueden quitar los parámetros por defecto del kernel, quiet splash, para que salga la información de inicio en lugar de la agradable imagen de inicio del sistema.

El segundo archivo que hay que modificar es el archivo /etc/grub.d/00_header. Hay que modificar la función make_timeout() (a partir de la línea 238, más o menos) comentando (también con una almohadilla como primer carácter de la línea: #) la línea que pone set timeout=-1 y añadiendo, justo debajo, la línea set timeout=15, donde 15 es el número de segundos que esperará GRUB a iniciar en caso de error (en caso de que recordfail esté a 1). Y digo comentar en vez de sustituir la línea para que, en caso de que no funcione, se pueda volver sin problemas a la versión anterior de este archivo.

Con estos cambios conseguiremos que aunque el equipo no se apague correctamente, sí se inicie correctamente cuando vuelva la luz (o cuando se inicie de nuevo). Y, en caso de que el fallo sea de hardware o de software, no os preocupéis que el propio Linux ya indicará información sobre el error.

diego@box:~/projects/my_lib/test:$ ./test
test: error while loading shared libraries: libsxxx.so: cannot open shared object file: No such file or directory
diego@box:~/projects/my_lib/test:$

Para solucionarlo basta que con insertes en la variable de entorno LD_LIBRARY_PATH el directorio donde está esta librería:

diego@box:~/projects/my_lib/test:$ export LD_LIBRARY_PATH=$LD_LIBRARY_PATH:../lib

Suponiendo que la librería está en ../lib.

Con esto ya se ejecutará tu programa de prueba sin problemas, aunque hay que tener en cuenta que cuando salgas de ese terminal esta variable va a volver a su valor original (que suele ser la cadena vacía).

Una vez que instales tu librería en alguna ruta del sistema (generalmente las librerías propias irán en /usr/local/lib) debes ejecutar el comando ldconfig para que se actualice la caché de librerías y todos los programas que la usen la encuentren sin problemas.

Dicen que Windows NT es (o era) bastante portable y que lleva años funcionando en procesadores ARM dentro de los laborarios de Microsoft, pero ¿cuánto de Windows NT tiene Windows 7?

Además, espero que sea rápido porque Android ya está muy metido en harina, sobre todo en tablets que, a mi entender, son el futuro cercano de las comunicaciones móviles junto con los teléfonos “inteligentes” o smartphones.

Estaremos atentos a los movimientos en el patio.

Hace ya algún tiempo que Mark Shuttleworth propuso el uso de la interfaz Unity para la nueva versión de Ubuntu, la 11.04.

Esta interfaz es bastante distinta a lo que estamos acostumbrados, esto es, una barra de tareas en la parte inferior y ventanas por el escritorio, además de iconos en el mismo junto a un menú desplegable de aplicaciones. Ahora lo que tendremos es una barra de tareas a la izquierda, el menú de las aplicaciones de forma global —estilo Mac OS X— y un lanzador global de aplicaciones que se muestra a pantalla completa para elegir la aplicación que queremos ejecutar.

Esto, visto así y después de probarlo un rato, tengo que reconocer que la idea no está mal. Integración, sencillez, facilidad de uso,… más al estilo Web o al estilo interfaz de teléfono móvil que al de las interfaces típicas de los sistemas operativos a los que estamos acostumbrados.

El problema que le encuentro es que creo que este tipo de interfaces está diseñado para pantallas pequeñas, esto es, de los Netbook (entre 8 y 12 pulgadas), y en las pantallas de un ordenador de sobremesa, no sólo no se le saca todo el partido, sino que resta productividad.

Uno de los problemas que encuentro con pantallas grandes es que la mayoría de las aplicaciones están maximizadas por defecto, por lo que no puedes ver más de una ventana a la vez. Cierto es que se pueden restaurar, pero el comportamiento por defecto es el de pantalla completa. Además, el menú de cada aplicación se pasa al menú global —otra vez estilo Mac OS X— y hay ciertas aplicaciones en las que no funciona, como en Eclipse.

En cambio, algo que sí me gusta es el lanzador, y no precisamente porque esté a la izquierda (aunque ahí no podría quejarme porque el de BeOS estaba a la derecha y es mi sistema operativo favorito) sino por su funcionalidad y su interfaz. La forma de comprimir los botones cuando hay muchas aplicaciones me parece bastante buena lo que repercute en un uso muy sencillo e intuitivo.

En resumen, creo que esta interfaz está bien para dispositivos con pantallas pequeñas y también para pantallas táctiles, pero la decisión de incluirlo como interfaz por defecto en el sistema operativo de sobremesa no me parece en absoluto acertada. Espero que haya una forma sencilla de revertir esta decisión para volver a usar Gnome.

Para centrarnos un poco pero sin profundizar, una interfaz virtual es una interfaz ficticia asociada a una interfaz real, esto es, simular dos tarjetas de red teniendo sólo una. También se llaman “alias”.

¿Y esto para que sirve? Pues para acceder, por ejemplo, a dos redes diferentes desde el mismo equipo. Por ejemplo, la IP real de nuestro equipo es 192.168.1.42 con máscara de subred 255.255.255.0 y queremos acceder a un equipo cuya IP es 192.168.2.100 con máscara de subred 255.255.255.0. Como están en distinta red no se puede acceder directamente, a no ser que creemos una interfaz virtual o alias de red.

Para ello basta con configurar en el archivo /etc/network/interfaces la nueva interfaz. Suponiendo que nuestra interfaz principal se llame eth0, el archivo de configuración quedaría así (además de lo que hubiese antes):

auto eth0:1
iface eth0:1 inet static
address 192.168.2.42
netmask 255.255.255.0
network 192.1638.2.0
broadcast 192.168.2.255

En caso de que nuestra interfaz tuviese un nombre diferente, por ejemplo ra0, el nombre de la interfaz virtual debería ser ra0:1 (o cualquier otro número entero detrás de los dos puntos).

Una vez hecha la configuración, la nueva interfaz virtual se activa mediante el comando:

diego@box:~:$ sudo ifup eth0:1

Pero, como reza el título de esta entrada y como ya iba siendo hora de contarlo, si usas Ubuntu con NetworkManager, en el próximo reinicio de la máquina la interfaz virtual no se activará porque NetworkManager no soporta interfaces virtuales.

Pero como (casi) siempre, en Linux hay solución. Para ello hay que hacer uso de la ejecución de los scripts que usa NetworkManager. Estos scripts se encuentran en el directorio /etc/NetworkManager/dispatcher.d. Ahí hay que crear un archivo —al que llamaré updownaliases— con el siguiente contenido (cambiando el nombre de la interfaz según corresponda):

Este archivo debe pertenecer a root (los que no pertenecen a root son ignorados) y luego hay que darle los permisos de ejecución mediante el comando:

diego@box:~:$ sudo chmod 755 updownaliases

Para probarlo basta con que desactivéis y activéis la red desde el NetworkManager (botón derecho sobre el icono y hacer clic en el menú «Activar red»). Para comprobar si todo es correcto hay que ejecutar el comando:

diego@box:~:$ ifconfig

Y ahí tienen que salir todas las interfaces, tanto la real (que generalmente es eth0) como la virtual o alias, que, en este caso, es eth0:1.

Pero de vez en cuando a Eclipse le da por petarse con un SIGSEGV. Vamos, con una violación de segmento de toda la vida. Y esto es porque el OpenJDK tiene algún error.

Para solucionarlo basta con desinstalar el OpenJDK e instalar la versión oficial de Java que está en los repositorios:

diego@box:~:$ sudo apt-get remove openjdk
[...]
diego@box:~:$ sudo apt-get install sun-java6*
[...]
diego@box:~:$

Con estos simples comandos, aunque perdemos la pureza que algunos quieren darle a los sistemas GNU/Linux de que todo el software sea libre, tu Eclipse estará contento y trabajarás mucho mejor. Porque de lo que se trata es de que trabajes bien y a gusto con tu sistema informático. La filosofía la dejamos para otro día.