Valkertown Blog

Slax es quizá el mejor Linux live que he usado, sobre todo por que se ajusta a todas mis necesidades, este post va un poco al trabajo que realice recientemente con Slax a modo de no perderlo y compartirlo.

Slax en principio es Slackware GNU/Linux por lo que mi experiencia en Slackware es de provecho a la hora de modificarlo de la forma que lo hice.

Como todos mis envios, no son para principiantes y asumo mucho conocimiento, quizá es una buena guia para saber que estudiar.

Objetivo de Modificación

El principal objetivo es modificar Slax de forma que pueda ser utilizado en una plataforma embedida.
Para esto se requiere:

• Cambiar el Kernel por un kernel de tiempo real
• Arranque por memoria USB
• Mantener la modularidad de Slax

Preparación

Para todo esto es necesario escojer una versión de Slax, por mi parte utilice Slax Frodo por ser la más pequeña y la más suceptible a modificaciones.
La imagen se debe copiar al disco duro para ir modificando las partes y al final volver a generar una imagen final para CDROM, USB o lo que sea.
Es una excelente idea utilizar un emulador de i386 tipo qemu, en las etapas del arranque pues esto lleva un tiempo largo.

Kernel RTAI

La primera tarea sobre Slax es cambiar el kernel por defecto por uno aceptable para las labores del laboratorio y es tiempo real. Por demás la arquitectura i386 es terrible en cuanto a tiempo real se refiere, sin embargo RTAI cumple su función más allá de los 100uS lo cual es aceptable.

La presencia de un periferico conocido como APIC marca la diferencia entre latencias de atención a interrupciones y cambios de tareas en el SO. Con APIC la latencia de atención es supera 1uS sin APIC cae por debajo de los 25uS, esto teniendo en cuenta un procesador común x86 a 1Ghz, no me quiero extender en como se realizan estas mediciones y los números estan bastante gruesos.

En la mayoria de procesadores x86 actuales el APIC es un periferico común, sin embargo en el mercado de procesadores embedidos x86 el APIC es un periferico excaso.

La configuración del Kernel RTAI depende en gran medida de la presencia del APIC y los requerimientos particulares de SLAX.

Al momento de escribir este envio SLAX esta trabajando con SquashFS y UnionFS, parches para el Kernel que pronton estarán incluidos en el arbol principal del Kernel de Linux si es que ya no lo estan.

Ahora, son tres parches los que hay que aplicar a un kernel vanilla y cada uno es compatible con una colección diferente de versiones del kernel por lo que la selección del kernel vainilla es algo complicada.

Los enlaces para los tres parches:

• RTAI
• UnionFS
• SquashFS

Ahora la estabilidad del sistema depende de lo bien que se escoja la combinación de versiones de estos parches, en algunos es posible ir por versiones recientes incluso experimentales y en otros una aproximación más conservadora es la mejor opción.

Cada parche tiene sus instrucciones y sus propias configuración, leer la documentación de cada uno es bastante importante.

La parte critica de la configuración es por parte de RTAI, pues este tiene requerimientos especificos en la configuración en especial la parte del APIC.

Si se tiene APIC seleccionar la familia de procesadores para obtener la mejor optimización mejora bastante el desempeño en el tiempo real. En el caso de no tener APIC la mejor opción es desactivar todo lo referente a él en la configuración y seleccionar la familia i586(o en el caso de una anterior la correspondiente a su familia).

Initrd

Una parte critica del cambio del kernel, en especial si se trata de un kernel 2.6 es mantener un initrd con todo lo necesario para que el sistema arranque limpiamente.

La idea del initrd es tener un sistema base de arranque, por lo general se trata de un ramdisk de solo lectura.

El primer paso es reutilizar el ramdisk que provee Slax y reemplazar los modulos y los archivos correspondientes en /lib/.

UnionFS requiere de unas herramientas en espacio de usuario, estas tambien deben ir en el initrd.

Lograr el arranque completo lleva varios pasos y requiere de un buen entendimiento de los requerimientos del sistema para arrancar via USB, CDROM o el medio necesario, por lo que insisto en utilizar quemu, bochs, vmware.

Arranque

El arranque puede ser complicado, por mi parte utilice syslinux, que es bastante sencillo y funciono perfectamente.

A este hay que indicarle nuestro initrd y la imagen del kernel que se acaba de compilar.

Una vez se logre arrancar el sistema al punto en el que los scripts de arranque de Slax intentan cargar los modulos de Slax, es hora de continuar haciendo cambios.

Algunas cosas para recordar:

• EL initrd por defecto viene bastante estrecho en espacio libre, es necesario crear uno nuevo
• El tamaño de ramdisk que se le pasa al kernel por defecto en Slax es bastante pequeño y debe ser ajustado al tamaño del ramdisk que creemos
• dd if=/dev/zero of=zeros.img bc=xxxx
• mke2fs zeros.img
• mv zeros.img initrd
• gzip initrd
• gunzip initrd.gz
• mount initrd /mnt/hd -o loop

Bien para ver esto(XGL) (medio)funcionar en slackware hace falta tener una aceleradora y tener instalada la distribución adicional de dropline-gnome para slackware 10.2. Esto si no se quiere compilar todo a mano desde el principio cosa que aparentemente es increiblemente tedioso de hacer funcionar.

Por otro lado Diffie un desarrollador de dropline-gnome se encarga de Xorg 7.0 y de XGL en distribución binaria. A Diffie se le encuentra facilmente en los foros de Dropline GNOME.

La tarea se resume en:

1. Instalar Slackware 10.2
2. Instalar Dropline-Gnome para Slackware 10.2
3. Obtener los paquetes de Xorg 7.0.0 y XGL de repositorio de testing de Dropline-Gnome
4. ../xorg7tgz/# upgradepkg *.tgz
5. En mi caso tengo una aceleradora NVIDIA: sh NVIDIA-Install… blah
6. ../xgltgz/# upgradepkg *.tgz
8. sh startxgl.sh 1

En general eso es suficiente, sin embargo las librerias MESA de NVIDIA y que Dropline colisionan un poco a la hora de cargar Xgl server y el WM Compiz, por que cada uno quire usar una en particular. Al final de buscar por los foros se me ocurrio solucionar el problema de la siguiente forma:


Listing startxgl.sh
#!/bin/bash
LIBGL1=/usr/lib/libGL.so.1.0.8178 #NVIDIA Lib Notese la version particular de mi driver de NVIDIA
LIBGL2=/usr/lib/libGL.so.1.2 # Dropline Mesa Lib
echo “>Starting XGL at Display: $1″
echo “========= XGL ============”
# nvidia
LD_PRELOAD=$LIBGL1 Xgl :$1 -ac -accel xv:fbo -accel glx:pbuffer &
# ati
#Xgl :1 -ac -accel glx:pbuffer -accel xv:pbuffer &
sleep 3
echo “======= COMPIZ ===========”
DISPLAY=:$1 LD_PRELOAD=$LIBGL2 LD_LIBRARY_PATH=/usr/lib compiz –replace decoration wobbly fade switcher minimize cube rotate zoom scale move resize place opacity &
sleep 3
echo “====== DECORATIONS =======”
DISPLAY=:$1 gnome-window-decorator &
sleep 3
echo “======= GNOME ============”
DISPLAY=:$1 gnome-session
EOF


Cosa que funciona a medias por que en mi opinión el LiveCD de Korora tiene un desempeño muy superior y menos “aritfacts” en la presentación.
Es bueno probarlo y saber que mi startx usual funciona aun con esta modificación, solo me daño las fuentes Artwiz que tendre que instalarlas otra vez.

Enlaces

• Pagina Principal Dropline-Gnome
• TGZ Xorg7.0.0 para Slack10.2
• TGZ xgl para Slack10.2
• Foro DroplineGnome
• Hilo del Foro sobre Xorg 7.0 y Xgl

EOT

Desde hace algún tiempo me obsesione con poner una pequeña bandera de Colombia en el prompt y al final lo logré:

La foto no esta centrada intencionalmente

Luego me mude y blogsome sugería utilizar codificación UTF-8 para los envíos y durante la mudanza aparecieron mezclas de codificaciones por lo que decidi investigar un poco el asunto y me encontre que quizá esa sería la solución que estaba buscando para mi bandera.

El resultado fue una migración total de mi entorno de trabajo de codificación ISO 8859-1 (Latin-1) a ISO 10646 Nivel 3 (UTF-8). A primera vista el cambio de codificación no resulta gran cosa, solo la aparición de la dichosa bandera, sin embargo como pueden ver en el screenshot, va mucho más allá, ahora mis terminales son mucho más poderosas de lo que eran anteriormente, con formulas matemáticas y mezclas de caracteres de diferentes lenguas.

EXTENDED BODY:
Básicamente toda la información necesaria para hacer la migración, o simplemente establecerse en UTF-8 esta en el siguiente enlace :

[UTF-8 and Unicode FAQ for Unix/GNU/Linux](http://www.cl.cam.ac.uk/~mgk25/unicode.html)

De todas formas el soporte para UTF-8 Bajo GNU/Linux-CLI ha sido poco menos que perfecto por lo que el cambio ha sido completamente satisfactorio.

Para empezar la migración para X11, aún no he probado en la consola plana, hace falta :

1. Fuentes UTF-8: En el [FAQ-UTF](http://www.cl.cam.ac.uk/~mgk25/unicode.html) están una buena lista de fuentes UTF-8
3. Programas con soporte UTF-8 o wide-characters: LA mayoria de programas en GNU/Linux los soportan.
4. Configuraciones Saber como configurar el entorno para UTF-8, lo que es el proposito de este envio.

Fuentes UTF-8:

Conseguir estas fuentes puede ser complicado ya que las opciones no son muchas y son colecciones son bastante tradicionales.
Sin embargo la gamma disponible para mi resulta bastante satisfactoria.

Por ahora la fuente que he escogido para mis terminales es:

-Misc-Fixed-Medium-R-Normal–18-120-100-100-C-90-ISO10646-1

Que seguramente esta disponible en casi toda distribución reciente de Xorg.

Programas UTF-8:

Como dije la gran mayoria de programas en GNU soportan UTF-8 así que se reduce a configurarlos. Con la mayoria de los programas de CLI no es nisiquiera necesario configurarlos ya que la terminal es quien se encarga de interpretar los caracteres. Por otra parte los editores si es conveniente configurarlos.
Una lista de programas que soportan UTF-8 esta en el enlace anterior, por lo que no me extiendo.
Mi terminal favorita aterm fue reemplazada por unicode-rxvt; que hasta ahora se ha comportado igual y mejor que aterm.
xterm tambien soporta UTF-8, sin embargo es posible que tenga que ser parchado el código fuente.

Configuración:

La configuración de emuladores de terminal se puede dar en distintas partes como parametros en la llamada al emulador o como parametros en el Xresources o .Xresources, dependiendo hasta que punto se desea realizar la migración.

Voy a dejar este envio incompleto por que me da pereza terminarlo en este punto ya que lo tengo atrasado hace mucho tiempo, solo me queda decir :

• unicode-rxvt Solo hace falta decirle que utilice la fuente adecuada de las fixed que más les guste, xfontsel es útil para esto
• Vim y Emacs: Ellos se basan en las variables de entorno y el formato individual del archivo para la codificacion por lo que no hay mucho problema
• En el .bashrc y el .bash_profile hace falta colocar, si no se quiere que quede todo en español (TODO) cambiar es_CO por en_US :
  1 export LC_CTYPE=es_CO.UTF-8
  2 export LC_ALL=es_CO.UTF-8

Espero que lo poco que esta les sea útil.

EOT

Bueno, hace algún tiempo me pagaron un pequeño trabajo con la compra de una SounBlaster Live 24bits 7.1 y hasta hace muy poco núnca pase de hacerle funcionar en mi GNU/Linux con dos canales.

Recientemente decidi que debia utilizarla completamente y compre un pequeño juego de sonido 5.1.

Para hacer funcionar todos los canles con ALSA resulto algo cercado a trivial solo que es tan tonto que no se espera:

$aplay -Dplug:surround51 archivo_de_6_canales.wav


Encontre algunos WAV de 6 Canales con los que probar y todo va de maravilla hasta este punto.
Pero existe un grave problema!! el 99.9% de mis Mp3/Ogg/FLAC/MUSE son de dos canales exceptuando algunas canciones que Herulor me paso (Sailormoon PST Versión Español, Con P de pirata).

Para solucionar este condenado problema, pues solo sonaban los tweeters del frente rebusque la documentación de ALSA, esto me enseño bastante aunqe al final me dejo algo frustrado en algunos aspectos.

Como mi idea es hacer el post breve, my .asoundrc quedo:

1 pcm.dmix_front{
2 type dmix
3 ipc_key 1024
4 slave.pcm front
5 slave.channels 2
6 }
7 pcm.dmix_rear{
8 type dmix
9 ipc_key 1025
10 slave.pcm rear
11 slave.channels 2
12 }
13 pcm.dmix_center{
14 type dmix
15 ipc_key 1026
16 slave.pcm center_lfe
17 slave.channels 2
18 }
19 pcm.dmix_side{
20 type dmix
21 ipc_key 1027
22 slave.pcm side
23 slave.channels 2
24 }
25 pcm.dmix51_a{
26 type multi;
27 slaves.a.pcm “dmix_front”;
28 slaves.a.channels 2;
29 slaves.b.pcm “dmix_rear”;
30 slaves.b.channels 2;
31 slaves.c.pcm “dmix_center”;
32 slaves.c.channels 2;
33 bindings.0.slave a;
34 bindings.0.channel 0;
35 bindings.1.slave a;
36 bindings.1.channel 1;
37 bindings.2.slave b;
38 bindings.2.channel 0;
39 bindings.3.slave b;
40 bindings.3.channel 1;
41 bindings.4.slave c;
42 bindings.4.channel 0;
43 bindings.5.slave c;
44 bindings.5.channel 1;
46 pcm.!default {
47 type plug
48 slave.pcm plug:surround51
49 slave.channels 6
50 route_policy duplicate
51 }


Bien, si que quiere fijar un poco en el archivo para lograr el efecto deseado solo hacen falta las lineas 46-51, sin embargo en el trancurso de la creación de ese archivo descubri como hacer mezclas de dos clases:

Mezcla(Mixing): Se utiliza el plugin dmix y permite que varios programas utilicen el mismo dispositivo de sonido al tiempo y el se encarga de hacer la mezcla. Usualmente esto me resulta molesto pero queria probar si se podia.

Mexcla de Canales o TSonido(Multi): Este es una propiedad de alsa bastante interesante, con esto se pueden simular dispositivos de un numero de canales igual a la suma de todos los canales disponibles en TODAS las tarjetas de sonido disponibles. Con esto no hace falta tener una tarjeta 4.0,5.1,7.1 bastaria con aprovechar las tarjetas de sonido adicionales con las que se cuente. En mi archivo queria hacer un mega-dispositivo que pudiese tener full surround y Mixing, pero alsa se quejo de mi configuración. Google dice que es posible pero mi ALSA dice que no, cuando recompile todo lo relacionado lo volvere a intentar.

Eso es todo y va para el log.

EOT

Bien esto me saco de quicio mucho tiempo hasta que hoy decidi ponerme a la tarea de solucionarlo.

Me encanta GNU-Screen lo uso todo el tiempo y es dificil vivir sin él, me he acostumbrado demasiado a tenerlo andando todo el tiempo; sin embargo siempre he tenido una queja sobre los scrollbars y el mousewheel de los emuladores de terminal, hacer scrollback con las combinaciones de teclas que trae screen es bastante aburrido y lento, de echo ni siquiera funciona shift+pup/pdw algo a lo que todos estamos muy acostumbrados y realmente molesta de screen. Bien la solución viene (como era de esperarse ) al modificar las termcaps y ajustar todo el ambiente.

Esto soluciona parcialmente el problema pues todas las sesiones de screen quedan compartiendo el mismo scroll-buffer sin embargo es suficiente en muchos casos.

En el .screenrc añadi:

termcapinfo xterm ti@:te@
termcapinfo xterm ‘hs:ts=\E]2;:fs=07:ds=\E]2;screen07′
termcapinfo rxvt ti@:te@
termcapinfo rxvt ‘hs:ts=\E]2;:fs=07:ds=\E]2;screen07′


Esto para que funcione con xterm y rxvt(atern,unicode-rxvt,…).

Al invocar screen es conveniente ajustar la variable de entorno TERM para que el ajuste sea coherente:

rxvt -e screen -T rxvt
xterm -e screen -T xterm


Esta linea en el .bashrc corrige un defecto de algunos emuladores de terminal con los comandos que se extienden más allá del ancho y estos solo retornan al principio de la linea esto se vuelve sumamente molesto con el tiempo.

shopt -s checkwinsize


Una buena opción para utilizar al invocar tanto xterm como rxvt :

$ urxvt -j
$ rxvt -j -s
$ xterm -j -s

Esto acelera considerablemente el scroll de las terminales y la ejecución de algunos programas que se ven retardados por esto

Del manual :

-j This option indicates that xterm should do jump scrolling.
Normally, text is scrolled one line at a time; this option
allows xterm to move multiple lines at a time so that it does
not fall as far behind. Its use is strongly recommended since
it makes xterm much faster


-s This option indicates that xterm may scroll asynchronously,
meaning that the screen does not have to be kept completely up
to date while scrolling. This allows xterm to run faster


EOT