Lo hice y lo entendí

En la mayoría de los casos, un usuario de Linux rara vez necesitará enfrentarse a la instalación manual de GRUB, el gestor de arranque más común para Linux, ya que en el momento de la instalación de su distribución favorita, ésta lo hará por él. En muchos casos, puede ser suficiente para el usuario medio saber cómo editar el fichero /boot/grub/menu.lst para modificar las entradas del menú de arranque de acuerdo a sus necesidades. Sin embargo, sigue habiendo casos en los que necesitaremos hacer esta instalación manualmente.

Por ejemplo, en entradas anteriores vimos cómo instalar manualmente GRUB en una memoria USB para poder arrancar múltiples sistemas operativos desde ella:

• Arrancar Linux, Windows y MS-DOS de una memoria USB
• Arrancar MS-DOS desde una memoria USB

También vimos cómo, en caso de estar trabajando sobre un fakeRAID, el instalador de la distribución no es capaz de instalar GRUB con éxito, teniendo que hacerlo nosotros mismos manualmente:

• Instalar Ubuntu 8.04 Hardy Heron sobre un fakeRAID

Esta entrada pretende resumir las diferentes técnicas que ya habíamos visto previamente en un único documento que sirva de referencia, así como dar algunos detalles adicionales sobre el funcionamiento interno de GRUB. Por supuesto, toda esta información ya existe, como no podía ser de otra forma, en el manual de GRUB.

Sigue leyendo »

Hoy la noticia buena y mala del día para los usuarios de Linux ha sido que Adobe ha liberado una versión alpha de su plugin Flash para navegadores: Barrapunto: Flash para 64 bits llega primero a Linux, Penguin.SWF: Now Supporting 16 Exabytes, Descargar versión de Linux de 64 bits de Flash Player 10.

Es una noticia buena para los usuarios de Linux AMD64 después de tanto tiempo pidiéndolo, porque el plugin de Flash es vital para nuestros sistemas de escritorio si queremos tener una experiencia completa en el uso de la web hoy en día. Su alternativa abierta, el Gnash, aún no está preparado para reemplazarlo completamente. La única opción que teníamos era usar el plugin de 32 bits con el nspluginwrapper (Sobre el plugin de Flash en Firefox/Iceweasel en Debian AMD64: El nspluginwrapper aceptado en Testing), una opción que, aunque nos saca del apuro, es muy inestable y nos obligaba muy a menudo a reiniciar el navegador porque el plugin de Flash dejaba de funcionar.

Es una noticia muy mala para los usuarios de Linux porque es lamentable que en nuestro sistema, que nos gustaría ver libre de todo el software propietario, tengamos que pasar por el aro de dos cosas: del dichoso plugin de Flash y de los drivers cerrados. No es casualidad que a menudo sean componentes de software de nuestros sistemas que desearíamos que fueran algo más estables. Es muy desafortunado que tengamos que depender de que los señores de Adobe sean magnánimos con los pobres bichos raros que usan Linux de 64 bits para poder usar lo que todo el mundo usa, Internet.

Y por supuesto, también es lamentable que diseños web que se podrían hacer de forma perfectamente estándar y llamativa con un poco de CSS, HTML y JavaScript, acaben siendo pasto del todopoderoso y monopolístico Flash para desesperación de aquello que llamamos accesibilidad. El uso de Flash para reproducir vídeos en la web es razonable, aunque sería mucho más deseable que se usara cualquiera de los formatos de vídeo abiertos disponibles. Donde sí tiene perfecta cabida, hay que reconocerlo, es en el campo de las animaciones, como los juegos online o los típicos esquemas interactivos que a menudo nos presentan los periódicos en su edición digital.

Bueno, yo he probado hoy esta nueva versión del plugin en mi Ubuntu 8.10 y he de decir que funciona. No lo he probado intensivamente, pero funciona bien con algún juego (¿habéis probado el Play 99 Bricks?) y con Youtube, Metacafe y ZappInternet. Sin embargo, me da la sensación de que usa muchísima CPU.

Para instalarlo, he desinstalado el paquete flashplugin-nonfree:

 $ sudo dpkg -P flashplugin-nonfree
(Reading database ... 134935 files and directories currently installed.)
Removing flashplugin-nonfree ...
Purging configuration files for flashplugin-nonfree ...

y he hecho un autoremove para que elimine el nspluginwrapper también:

$ sudo apt-get autoremove
Reading package lists... Done
Building dependency tree
Reading state information... Done
The following packages were automatically installed and are no longer required:
  nspluginwrapper
The following packages will be REMOVED:
  nspluginwrapper
0 upgraded, 0 newly installed, 1 to remove and 0 not upgraded.
After this operation, 483kB disk space will be freed.
Do you want to continue [Y/n]?
(Reading database ... 134928 files and directories currently installed.)
Removing nspluginwrapper ...
Processing triggers for man-db ...

Finalmente, he descargado el fichero libflashplayer-10.0.d20.7.linux-x86_64.so.tar.gz y lo he descomprimido en el directorio ~/.mozilla/plugins. Sólo contiene una librería:

~ $ wget http://download.macromedia.com/pub/labs/flashplayer10/libflashplayer-10.0.d20.7.linux-x86_64.so.tar.gz

~ $ cd .mozilla/plugins/

~/.mozilla/plugins $ tar xvf ~/libflashplayer-10.0.d20.7.linux-x86_64.so.tar.gz
libflashplayer.so

Tras reiniciar el navegador, en el about:plugins ya veremos:

Shockwave Flash

File name: libflashplayer.so
Shockwave Flash 10.0 d20

Para instalar el plugin para todos los usuarios del sistema, habría que copiar la nueva librería en /usr/lib/mozilla/plugins/.

En fin, que la noticia deja un sabor muy agridulce. Es como cuando el driver de NVidia va mal y la actualización del driver cerrado arregla el problema. Se agradece la actualización, pero ésta no mitiga la impotencia que da depender de la voluntad que tenga una empresa para arreglar fallos o no hacerlo.

Actualización 20/11/08: The Inquirer: Instalación y rendimiento Adobe Flash 64bits en Linux

:wq

A finales de los 70, los monstruosos ordenadores de la época comenzaron a usar terminales serie para la consola y la entrada salida estándar (teclado y pantalla). Antes de ellos, los ordenadores interactuaban con el usuario usando teletipos (teletype: TTY, ¿te suenan de algo estas siglas?). Los terminales pioneros, tal y como los conocemos ahora, fueron el DEC VT52 y el DEC VT100, por allá por 1978. Éste era su aspecto:

Otros fabricantes desarrollaron otros tipos de terminales, con el mismo concepto, pero incompatibles con otros sistemas, como este HP 700/96, que aún se sigue usando en algunos CPD hoy en día:

Los ordenadores personales, como el PC y los Apple o los Commodore, Spectrum, Amstrad CPC, etc. siguieron otro camino para mostrar la información al usuario, ya que, o bien usaban un sistema de vídeo propietario para mostrar texto y gráficos (p.e. MDA o VGA), o bien se conectaban directamente al televisor.

Los grandes servidores UNIX (basados en AIX, HP-UX, Solaris, etc.) o similares (por ejemplo, basados en OpenVMS, o z/OS) han llegado a nuestros días permitiendo la conexión de un terminal serie para usar la consola, pero cada día es más infrecuente su uso, ya que han sido sustituidos por consolas LAN (accedemos por Telnet o por SSH a una dirección IP diferente a la propia del sistema) o por consolas Web (una página web donde nos aparece la consola), que, por supuesto, nos permiten interactuar con la máquina incluso durante el arranque y la parada.

Hoy en día los terminales serie están bastante en desuso. Sin embargo, los emuladores de terminal están en pleno apogeo, bien sean para conectarnos por Telnet, por SSH, o, por supuesto, por el puerto serie/módem (ya lo vimos en Configurar Linux para permitir el acceso remoto por módem a la consola y por RAS/PPP). Por cierto, ¿qué tipo de terminal emulan la mayoría de emuladores de terminal como mínimo? Pues, por supuesto, el famoso VT100. Pero como otros fabricantes hicieron otros terminales con sus propios protocolos, secuencias de escape y capacidades, hay múltiples tipos de emuladores de terminal. Las emulaciones de terminal ansi y vt100 (y tal vez xterm) son las más usadas.

Sigue leyendo »

A mucha gente no le preocupará la resolución de la consola de Linux, el modo texto que se usa cuando no estamos en el entorno X Window, bien porque no lo hayamos cargado, bien porque hayamos salido temporalmente de él con la combinación de teclas Control+Alt+Fx.

Sin embargo, a mí sí que me gusta mucho salir a la consola. Y especialmente, me gusta ver el arranque detallado del sistema. Si me conformara con ver el bonito logotipo de Debian o de Ubuntu mientras espero a que arranque el sistema, nunca habría descubierto problemas como los que conté en Solucionando el error “attempt to access beyond end of device” con reglas de udev, hal y/o un parche del kernel y en Disk might not be spun down properly. Update shutdown utility..

Es por eso que para mí es importante contar con una resolución en la consola adecuada a la pantalla que esté usando, para que las letras se vean lo más nítidas posibles y sin que sean monstruosamente grandes. La resolución la podemos especificar con el parámetro del kernel vga=DDD o vga=0xHHH, donde DDD es el número del modo VESA que queremos utilizar en decimal y HHH es el mismo número en hexadecimal. El único requisito es que el kernel haya sido compilado con soporte del driver de framebuffer VESA:

$ grep FB_VESA /boot/config-2.6.27-7-generic
CONFIG_FB_VESA=m

Lo único que necesitamos saber es qué modos VESA acepta nuestro adaptador gráfico y qué números tienen. Los más comunes (800×600, 1024×768, 1200×1024, etc.) son bien conocidos, y es a lo que dediqué precisamente la tercera entrada de este blog: Modos VESA aceptados por el kernel de Linux.

Sin embargo, el advenimiento de infinidad de portátiles y pantallas con resoluciones nativas poco convencionales (1680×1050, 1400×1050, 1400×900, etc.) no nos facilita precisamente el saber qué modos soportará nuestra pantalla y nuestro adaptador gráfico ya que, en ocasiones, el modo ni siquiera está estandarizado.

Sigue leyendo »

El paquete sysstat es una colección de herramientas de monitorización de rendimiento. Nos puede proporcionar datos instantáneos de rendimiento, así como almacenarlos como históricos para nuestra futura referencia. Especialmente en entornos de servidor, sus datos nos proporcionan información muy valiosa sobre las posibles carencias y cuellos de botella de nuestro sistema.

Las herramientas que incluye son:

• iostat(1) reports CPU statistics and input/output statistics for devices, partitions and network filesystems.
• mpstat(1) reports individual or combined processor related statistics.
• pidstat(1) reports statistics for Linux tasks (processes) : I/O, CPU, memory, etc.
• sar(1) collects, reports and saves system activity information (CPU, memory, disks, interrupts, network interfaces, TTY, kernel tables,etc.)
• sadc(8) is the system activity data collector, used as a backend for sar.
• sa1(8) collects and stores binary data in the system activity daily data file. It is a front end to sadc designed to be run
  from cron.
• sa2(8) writes a summarized daily activity report. It is a front end to sar designed to be run from cron.
• sadf(1) displays data collected by sar in multiple formats (CSV, XML, etc.) This is useful to load performance data into a database, or import them in a spreadsheet to make graphs.

En Debian y Ubuntu, tras instalar el paquete (apt-get install sysstat), ya podemos ver datos instantáneos. Todos los comandos aceptan como parámetros:

[ interval [ count ] ]

con los que le decimos al comando cuántos valores queremos y cada cuántos segundos. Por ejemplo, 5 valores de uso de CPU separados un segundo:

$ sar 1 5
Linux 2.6.27-7-generic (sistema) 	11/08/2008 	_x86_64_

10:17:37 AM     CPU     %user     %nice   %system   %iowait    %steal     %idle
10:17:38 AM     all      2.45      0.00      1.47      0.00      0.00     96.08
10:17:39 AM     all      1.96      0.00      0.98      0.00      0.00     97.06
10:17:40 AM     all     11.17      0.00      2.91      0.00      0.00     85.92
10:17:41 AM     all     13.11      0.00      1.94      0.00      0.00     84.95
10:17:42 AM     all      3.37      0.00      2.88      0.00      0.00     93.75
Average:        all      6.42      0.00      2.04      0.00      0.00     91.54

Sigue leyendo »

Hace tiempo que lo venía haciendo en algunos sistemas Linux, pero últimamente, cada vez me he vuelto más estricto con esto: ¡Se acabaron las particiones de memoria de virtual o de swap en sistemas domésticos!

Si lo pensamos detenidamente, tener una partición de swap, es tener una cantidad de espacio ahí abandonada y que en rarísimas ocasiones veremos usar. Y si el kernel llega a usarla, hemos de prepararnos, en la mayoría de los casos, a experimentar un sistema extraordinariamente pesado, con lo que si es una situación habitual, más nos vale comprar una ampliación de la memoria. De nuevo, recalcar que me refiero a sistemas domésticos. En un servidor, la memoria swap nos puede ayudar a absorber un pico puntual de trabajo que sólo se da en ocasiones aisladas y que no podemos dejar de atender.

Para nuestro sistema doméstico, resulta mucho más conveniente un fichero de swap, igual que hacen todos los Windows basados en NT con el pagefile.sys. Las ventajas son muchas:

• Lo podemos poner en la partición/sistema de ficheros que queramos
• Podemos borrarlo para liberar espacio si éste nos hace falta
• Podemos crear uno nuevo en cualquier momento
• No supone tener un espacio en disco bloqueado inservible para otros propósitos
• Posiblemente su rendimiento sea algo peor que el de una partición dedicada de swap, pero si la memoria swap llega a tener que usarse intensivamente, el rendimiento será ya nefasto, ¿qué más da que sea un poco peor?

Y, además, lo último, lo de que el rendimiento es peor parece que ni siquiera es cierto. En la LKML leemos que usando kernels 2.6 el rendimiento de un fichero de swap no es peor que el de una partición de swap (Jesper Juhl: a swap file is just as fast as a swap partition):

With a 2.4.x kernel swap files were slower than swap partitions, but with the 2.6 kernel a swap file is just as fast as a swap partition.

Sigue leyendo »