Notas publicadas en la categoría Linux

Poco tiempo atrás escribí sobre los periplos de trabajar con un portátil que resultó dañada por un problema eléctrico.Se trataba de un portátil Dell 700m. Un portátil pequeño (12,1"), liviano (2,1 kgs), pero incapaz de resistir una taza de café y un buen golpe eléctrico.

Hace poco me asignaron un nuevo portátil: Un Toshiba Portégé R505, también conocido como la respuesta de Toshiba al MacBook Air de Apple. «Respuesta» en términos de especificaciones (al menos), porque Apple siempre logra muy buenos diseños en sus equipos.

La Portégé R505 pesa 799 gramos, frente a los 1.300 gramos del Air. Ahora, cuando tomo el 700m, lo encuentro pesado y grueso, siendo que antes lo encontraba liviano. La Portégé R505 cerrada es tan gruesa como el grueso de mi dedo índice. Y, literalmente, pesa más el bolso que el equipo.

Lo primero que hice fue arrancarlo con el CD de Ubuntu Gutsy (7.10), pero no mostró imagen al arrancar X. No es que se hubiera colgado, simplemente no mostraba imagen. Reinicie el equipo y procedí a arrancarlo con el CD de Ubuntu Hardy (Alpha 6), que había sido liberado uno o dos días atrás.

Reparticioné el disco, dejando 135 GB para Linux y 25 GB para Vista Bussiness. Lo dejé sóĺo porque estaba la licencia en el equipo; además que en las garantías muchas veces exigen que esté el sistema operativo original.

En general, todo bien. Vamos al detalle, pero antes es necesario acotar que indico el modelo de las tarjetas sólo como referencia, puesto que, en general, el hardware quedó funcionando después de la instalación sin ajustes manuales:

  • Tarjeta de red Intel 82573L Gigabit Ethernet. Funciona impecable.
  • Tarjeta inalámbrica Intel 4965AG. Funciona bien y sólo tiene un pequeño detalle: Al desactivarla por teclado y ejecutar iwconfig, no indica «Radio-off», por lo que uno tiende a desconfiar si realmente está deshabilitada; aunque obviamente no encuentra ninguna red en esas condiciones.
  • Tarjeta Bluetooth 2.0. Funciona bien, pero me costó pillarla. Se trata de una tarjeta USB incorporada, la cual se activa con la misma tecla de función con que se activa/desactiva la red inalámbrica. Es decir, para realmente deshabilitar los dispositivos inalámbricos es necesario presionar 3 veces la combinación de teclas. Por omisión, al arrancar, Bluetooth está deshabilitado.
  • La interfaz Firewire, el lector SD y la PCMCIA no los he probado aún.
  • Tarjeta de sonido Realtek ALC262 (de la familia Intel ICH7). Funciona bien, pero al conectar el audífono aún se escucha el parlante del equipo. En el mezclador aparece un canal «Front» que es necesario apagar y santo remedio. Este problema es bastante común y no solamente en portátiles.
  • Tarjeta gráfica Intel 945GM. Funciona bien, pero algunas veces (al principio) se congeló la imagen. Pude reiniciar sin problemas, pero no es una situación que debiera ocurrir. Esto con el controlador intel. Al conectar un monitor externo, es reconocido correctamente, le puedo definir la resolución, pero no llega imagen. Con el controlador i810 si puedo configurarlo con Xinerama y Clone, usando la configuración del 700m. Se pierde XRandR, porque es un controlador más antiguo.
  • Lector de huella digital AuthenTec. No es reconocido automáticamente, por lo que es necesario instalar los programas en forma manual. En este caso, fprint t libfprint. Sólo lo probe para ver su funcionamiento.
  • Acelerómetro. Este equipo tiene incluído un acelerómetro, pero tampoco es reconocido automáticamente. Tampoco he indagado mayormente.
  • Suspender/Hibernar. Llega a suspender, pero en un segundo vuelve a activarse. Es necesario investigar que módulos provocan conflicto. Tampoco he indagado mayormente, pero si es una característica importante.
  • Batería. Acorde a la especificación, la duración debiera ser 12,5 horas, aunque no se indica en qué situación o con qué baterías. Lo batería de 3 celdas que trae, tiene una duración apróximada de 4 horas. Este fue el único motivo por lo cual arranqué el equipo con el sistema operativo provisto en el equipo (luego de 1 semana), sólo para verificar que la estimación en Vista Bussiness no variaba mucho de la entregada por Linux.
Como nota adicional quiero añadir que, en general, los parlantes de los portátiles suelen tener mal sonido. Pero este se distingue al resto porque es monofónico y le da un toque especial a los tangos: uno siente que los escucha directamente de una vitrola.

Si no te gustan los tangos, tal vez este portátil no sea de tu agrado.

Así como hay días buenos y días malos, también los hay en semanas y en años. Esta semana promete ser malísima. Algunos problemas que pasaron a ser menores cuando me encontré con lo siguiente:

Filesystem "sda5": XFS internal error xfs_bmap_read_extents(1) at line
4565 of file fs/xfs/xfs_bmap.c.  Caller 0xc02e7c99
 [<c02ca11e>] xfs_bmap_read_extents+0x488/0x4a2
 [<c02e7c99>] xfs_iread_extents+0xa0/0xbb
 [<c02e5b5f>] xfs_iext_realloc_direct+0xb3/0xc1
 [<c02e7c99>] xfs_iread_extents+0xa0/0xbb
 [<c02c2a54>] xfs_bmap_last_offset+0x94/0xdc
 [<c02d5269>] xfs_dir2_isblock+0x1b/0x60
 [<c0324085>] __make_request+0x384/0x495
 [<c02d59fb>] xfs_dir_lookup+0x8e/0xeb
 [<c02c7615>] xfs_bmapi+0x25b/0x1fd7
 [<c02fb04f>] xfs_dir_lookup_int+0x2c/0xd4
 [<c01230c4>] down_write+0x8/0x10
 [<c02e41ad>] xfs_ilock+0x47/0x67
 [<c02fe944>] xfs_lookup+0x50/0x76
 [<c05ff4cc>] __mutex_lock_slowpath+0x1ac/0x1b4
 [...]

Esa es una de las particiones de un servidor con problemas. Luego continúa:

# xfs_repair -n /dev/sda5
Phase 1 - find and verify superblock...
Phase 2 - using internal log
       - scan filesystem freespace and inode maps...
       - found root inode chunk
[...]
Phase 6 - check inode connectivity...
       - traversing filesystem starting at / ...
entry "etc" in directory inode 128 points to free inode 1310848, would
junk entry
corrupt dinode 786561, (btree extents).  This is a bug.
Please report it to xfs@oss...

El énfasis es mío. Hay que notar que la opción -n de xfs_repair indica que muestre lo que haría, pero no toma acción alguna. Previamente, xfs_check también se lució con:

# xfs_check /dev/sda5
[...]
dir 1310848 block 8388608 extra leaf entry fc4e7e74 e7
dir 1310848 block 8388608 extra leaf entry fcdbb5f3 8f
dir 1310848 block 8388608 extra leaf entry fddcbf74 164
/usr/bin/xfs_check: line 28: 14691 Segmentation fault
xfs_db$DBOPTS -i -p xfs_check -c "check$OPTS" $1

Buscando por aquí y por allá, me encontré con 2 posibles alternativas:

  • Memoria RAM con problemas, de donde se hayan guardado datos corruptos en disco.
  • Un fallo en el módulo XFS del núcleo.
Se trataba de memorias ECC, pero de todas formas probé con memtest para descartar la primera posibilidad. Se trata de un fallo.

Afortunadamente, los problemas no ocurrían en la fase 1 ó 2, sino que bien avanzado. XFS está hecho para ser utilizado en hardware robusto. Un reset de un dispositivo SCSI o IDE, que a veces se dejan ver en los registros del sistema, es razón suficiente para causar corrupción de datos en el sistema de archivos. No es el caso, pero sirve para ejemplificar la situación.

Al menos, después de la recuperación, en el directorio lost+found quedaron guardados archivos completos. No pedazos de datos que usualmente veía con ext2/ext3 (cuando habían problemas).

Justo en un mal momento. En una mala semana. Me ha consumido muchas horas y concentración. La planificación de mis estudios se me fue a las pailas. Aún quedan datos por verificar y reconstruir.

Luego de una encuesta realizada en línea, Dell anunció que vendería equipos Dell con Ubuntu pre-instalado. Durante la semana era posible ver que «venía en camino» y hoy al revisar el sitio de Dell, ya es una realidad... aunque por el momento sólo para el mercado de los Estados Unidos.

Hoy di lo que fue mi primera charla del año. La charla fue sobre Python y ví un par de ejemplos de extensiones usando PyGTK. Pensé que tendría tiempo para preparar una, pero finalmente tomé una que di el año pasado. Por tiempo, no pude asistir a las charlas de la tarde. Espero que Javier continúe organizando charlas, más esporádicas y no necesariamente de todo el día.

Hay muchos alumnos interesados y eso que faltaron muchos otros que me consta que son amigos del pingüino. Se ve que hay ganas de realizar actividades y de participar, aunque por ahora hay mucha dispersión. Lamentablemente, ya no tengo ni el ánimo ni el humor para organizar nada que tenga que ver con la FACE o con la universidad; aunque no tengo problemas en dar charlas o consejos (siempre que no sean en la FACE).

Me llamó la atención una parte del comentario de Fernando Ruiz:

[...] me agredo conocer a [...] German Poo, que pa mi era como un mito urbano eso que trabajaba en la ubb[...]
«mito urbano», ¿qué tal? :-)

Por otro lado, anteriormente me habían invitado del Instituto Profesional Virginio Gómez de Los Angeles para la FLISOL, pero no pude ir.

Para el 30 de junio estoy invitado a dar 2 charlas en «Open Community», que se realizará en la Universidad de Ciencias de la Informática, en Santiago. Una será de Mercurial y la otra será de desarrollo en GNOME con PyGTK.

En general, los ambientes integrados de desarrollo (también conocidos como IDE) son similares en su concepción: están orientados al desarrollo de nuevos programas o aplicaciones. Y en las charlas de programación que he dado, siempre es una pregunta frecuente entre los interesados en un nuevo lenguaje o ambiente.

Por otro lado, todo libro de Ingeniería de software indica que el mayor esfuerzo se encuentra en la mantención del código; ya sea vía añadir una nueva funcionalidad o bien corregir algún un fallo. Pero los IDE no tienen una orientación hacia la mantención. Hay un estudio hecho en la Universidad de Carnegie Mellon, publicado en diciembre de 2006 en IEEE Transactions on Software Engineering, titulado «An Exploratory Study of How Developers Seek, Relate, and Collect Relevant Information during Software Maintenance Tasks» (disponible en la página del autor), que sirve para darse una idea del comportamiento de los programadores cuando deben mantener código ajeno.

Tal vez podría entenderse como un estudio de usabilidad de un IDE, en este caso: Eclipse. Se muestran los puntos débiles así como sugerencias para mejorar el entorno de cara a la mantención.

De forma particular, el artículo me llamó la atención porque precisamente mi incursión en el código de Postgresql para mi proyecto en Google. No es que el artículo me fuera ayudar mucho en términos prácticos, pero si para satisface mi curiosidad acerca de lo que se teje últimamente al respecto.

Uno de los aspectos relevantes es la falta de un buen apoyo en la navegación del código. Allí no mencionaron que existen otras herramientas para dicho proceso, que muchas veces pasan desapercibidas. Es el caso de CScope, que existe hace mucho tiempo en UNIX y que es libre desde el año 2000.

CScope es una herramienta para buscar y navegar a través del código. Para que la búsqueda sea rápida, CScope genera una base de datos de todos los símbolos de un proyecto. Y es realmente rápido. En los IDE existen algunos mecanismos de búsqueda, pero no tan cómodos y potentes.

Interfaz curses de CScope
Interfaz curses de CScope

Es muy útil, no sólo cuando se carece familiaridad con el código. Lo que desconocía es que nuestros vecinos de KDE disponen de una interfaz gráfica llamada KScope. Es fácil tener a la vista desde que archivos se hace referencia a un símbolo (sea función, variable, etc.) e incluso una gráfica personalizable. En cada caja es posible ver donde se define, que funciones llama, desde donde es utilizada, entre otras búsquedas.

Interfaz KDE de CScope

Lo mejor de todo, es que uno puede utilizar indistintamente cualquiera de éstas dos interfaces. La gracia de KScope es la persistencia de la sesión, así, la siguiente vez se inicia en el mismo punto que uno quedó en la última sesión.

Mañana se libera Ubuntu Feisty. Con fuerte énfasis en Software Libre, quizás por eso hay ciertos problemillas no resueltos con paquetes no libres.

Lo interesante de este cuento, es que Feisty trae Xorg 7.2; la cual tiene problemas con programas propietarios, como Java (aún no es libre aunque está la promesa). El problema se produce porque hay un cambio desde la antigua Xlib a su reemplazo XCB.

En el caso de Java, está enlazado estáticamente con una versión de Xlib de XFree86 del año 2000; la cual tiene conflictos con la versión actual de XCB.

David Nusinow explicó que esa es la razón por la cual «Xorg 7.2 aún no está en Debian inestable». Es decir, no está en Debian inestable, porque tiene produce algunas regresiones. Pero estará en la versión estable de Ubuntu. Al parecer, el problema no ha sido resuelto en Ubuntu. Y es difícil, porque el problema aún no está resuelto en Sun, quienes proveen Java.

Si dependes de algún programa en Java que no funcione con gcj, tal vez valga la pena esperar un poco.

Para comenzar, seguiré la siguiente línea de trabajo:

Si el guía trabaja de una forma, intenta trabajar como tu guía hasta que te sientas suficientemente cómodo para seguir tu propio camino.

Lo primero es definir la estructura de directorios de acuerdo al flujo de trabajo. En este caso, seguiré la forma en que Alvaro lo hace.

    pgsql/
             source
             install
             build

Dentro de source, un directorio por cada versión de trabajo. Alvaro maneja múltiples versiones porque es su trabajo. Yo sólo necesito 2: la rama principal de desarrollo (CVS HEAD) y el árbol para mi proyecto: autovacumm. Similar caso sucede para los directorios install y build, para la instalación y contrucción de los programas, respectivamente.

Tengo algunas alternativas para trabajar. Mantener vía cvs la rama principal, y en dicha copia manejarla con Mercurial. Así, por cada actualización (cvs update), aplicaré los cambios en el repositorio con Mercurial (hg commit).

El repositorio de trabajo, entonces, es una rama de mi repositorio principal, la cual la puedo crear con hg clone. Cada cierto tiempo, puedo sincronizar ambos repositorios y si se presentan conflictos, resolverlos tan pronto como sea posible; en vez de esperar hasta el final, donde puede ser más difícil conciliar los cambios. Esto vía hg pull desde el repositorio de trabajo y hg merge.

Como alternativa de trabajo, puedo manejar una cola de parches, con la extensión mq. Esto es, antes de sincronizar ambos repositorios, extraer los cambios en el repositorio de trabajo (vía hg qpop -a), sincronizar y posteriormente volver a aplicar los cambios (vía hg qpush -a).

Con cualquiera de las dos alternativas, y en caso de conflicto, puedo mezclar visualmente los cambios con meld, que es ejecutado automáticamente cuando surge un conflicto.

Lo siguiente es obtener el código fuente. Las instrucciones para obtener el código vía cvs es distinta a las que usualmente he empleado en otros proyectos. Ellos exportan el árbol con toda la historia de cvs vía rsync. Sólo necesito una imagen de lo que hay en el repositorio en un momento determinado. Mi tiempo cero de desarrollo es cuando obtengo el repositorio por primera vez, y puedo abstraerme del historial antiguo.

Siguiendo la estructura de directorios y el flujo de trabajo de Alvaro (aunque con ligeras modificaciones para manejarlos con Mercurial), puedo usar los mismos scripts que él, de los cuales comentaré mas adelante.

Ha sido lenta mi partida. Intentaré describir mi experiencia por si resultase útil para algún futuro interesado.

Hace unos días, llegó un aviso de una suscripción automática a dos grupos de discusión (privados) para los postulantes que fueron aceptados en los «veranos de programación». Una es de discusión general, mientras que la otra es la lista de estudiantes.

El inicio es caótico. Y juzgar por algunos mensajes, años anteriores también ha sido así. Llegan muchos mensajes del tipo «¿Alguién más es de Timbuctú?». Y algunos buscan más detalles, preguntando por una determinada universidad. En una lista de 1536 suscritos, con que un 10% tome semejante actitud es suficiente para inundar de mensajes inútiles una lista que pretende ser útil.

Otro tipo de mensajes es: «Mi propuesta aceptada/rechazada está en ..., ¿Alguien las puede comentar?». Nadie las comenta; pero si un montón de gente sigue la corriente preguntando cada uno por sus propias propuestas.

Y para no ser menos, al parecer el año pasado hubo avalancha de presentaciones: «Yo soy Fulano, estudio en ... y mi proyecto es ...». Si parte uno, se produce un efecto dominó. Para prevenir este problema, alguno de los encargados creo una página en donde cada postulante ingresa su perfil. Todo bien, excepto que un grupo no menor, responde al mensaje donde se hizo dicho anuncio con un «Mi perfil ya está actualizado».

En unos tres días no sé cuantos mensaje habré recibido, pero fácilmente más de 300. De los cuales 3 ó 4 son útiles y el resto paja molida.

Hoy enviaron un correo indicando que de persistir ese comportamiento, se iba a comenzar a moderar. Un llamado a la cordura parecía suficiente. Pero siguieron llegando algunos de esos mensajes inútiles. La lista ahora es moderada. ¡Qué alivio!.

De los mensajes rescatados, debo enviar un certificado de alumno de la universidad y resolver el asunto de los impuestos para recibir el pago. Seguro que Eduardo Silva tiene recomendaciones. Es su segundo año participando.

Y otro dato útil fue, una bitácora del proyecto.

Tal como lo indiqué en en mi comentario anterior, este año presente dos propuestas para el programa «Summer of Code» de Google. Una de ellas fue aceptada, se trata de un proyecto para Postgres: Autovacuum Scheduling, cuyo guía será Alvaro Herrera.

Hoy nos dieron la bienvenida en la lista de desarrollo de Postgres. Cada proyecto tiene matices distintos respecto a este programa para estudiantes, algunos más orientados a atraer nuevos colabores, otros orientados a potenciar sus colaboradores, otros a lograr la implementación de características o una mezcla de cualquiera de ellas.

En el caso de Postgres, sugieren enviar a la lista de desarrollo la propuesta antes de postular en Google, para discutir y perfeccionar la idea. Y si se presentan otras propuestas similares, quiene haya enviado a la lista de correo la propuesta se le concede preferencia sobre el tema (siempre que sea buena y sea candidata a ser elegida).

En proyectos como Debian, no me imagino como una persona que no es colaborador del proyecto podría postular en forma exitosa. Llegar a ser mantenedor de un producto en Debian tarda mucho tiempo, y son más de mil desarrolladores. Pero esto es sólo una conjetura.

En proyectos como GNOME, tenía una fuerte convicción en atraer nuevos colaboradores más que lograr una características rebuscada dentro del proyecto; aunque se admitían excepciones. Y las hubo. Allí presente una idea, pero en las preguntas/respuestas en el período de selección no realice defensa alguna de mi propuesta; por el tenor de una pregunta, intuí que habían otras similares y preferí dar un paso al costado. Además, que por un par de preguntas intuí que debía saber más respecto del tema a abordar o bien, tener un cierto grado de avance con el cual desarrollar el problema. Honestamente, no tenía ninguno de los dos. Fue Mathias Hasselmann quien lo desarrollará. Es un tipo que ha contribuido antes con Pango, lo cual es bastante.

Para postular es requisito estar estudiando. Así es que estoy estudiando. Y combinar trabajo tiempo completo, maestría, ensayos de teatro y hogar; toma su tiempo de adaptación. Aunque debo resolverlo rápido.

Lo de la maestría es algo que había comentado a pocas personas. Y me incomoda un poco, porque hay una suerte de «alta expectativa» respecto a mis resultados, lo cual no es relajante precisamente. Además, que debo adelantar en mis estudios tanto como pueda entre abril y mayo, porque después es más complicado laboralmente.

Más adelante daré detalles sobre mis avances (o no) de este «invierno de programación» y de mis impresiones de los cursos de la maestría.