Ubuntu, impresoras idénticas, udev

Hace un tiempo, en la empresa de mi viejo, compramos dos impresoras Samsung ML-1665. Son impresoras láser y se están utilizando para imprimir facturas. La máquina de la caja, a la cual están conectadas, tiene Ubuntu 10.04. Después de seguir un excelente howto para instalarlas, la primera fue detectada correctamente y comenzó a funcionar a la perfección.

Al conectar la segunda impresora, exactamente igual que la primera, la detección fue también satifactoria. Aunque surgió un pequeño gran problema: al imprimir sobre ésta última, la impresión se realizaba sobre la primera. Observando la configuración de ambas, me percaté de que tenían exactamente el mismo Device URI.

La solución fue bastante rápida: editar el archivo /etc/cups/printers.conf, y cambiar el device URI, que era algo así como “usb:/Samsung…” por “file:/dev/usblp0”, y la otra impresora por “file:/dev/usblp1”. Con esto el problema fue resuelto y todo comenzó a funcionar como uno esperaba. Aunque no tardó en surgir otro inconveniente.

Continuá leyendo Ubuntu, impresoras idénticas, udev

Si usás Buildbot con Mercurial…

… y la versión de Buildbot es la 0.7.11p3 (la última al momento de escribir este post) y Mercurial 1.3.1, que son las versiones que están en Karmic, quizá tengas un problema cuando el Build Slave intenta bajar el código del repositorio para comenzar el ciclo de compilación/testing.

Arquitectura de Buildbot
Arquitectura de Buildbot

Buildbot permite configurar de varias formas el modo en que va a obtener el código fuente del proyecto y cómo realizará las actualizaciones subsiguientes. Por ejemplo, el modo “update” hace que las operaciones de checkout/update se ejecuten en el directorio de trabajo, y no en uno independiente, como en el modo “copy” o “clobber”, que mantienen un directorio separado y limpio del repositorio (en el caso de Mercurial, “copia de trabajo” en el caso de Subversion) y hacen una copia del mismo para realizar la compilación (esto asegura que siempre se compile todo y que no influyan archivos generados en procesos anteriores, además de otros problemas menos comunes pero que existen).

El problema que estuve teniendo es cuando utilizo Mercurial. Al intentar traer el código fuente, Buildbot entra en un bucle infinito donde realiza el checkout (clone), borra el directorio, otra vez clone y asi… me pareció rarísimo el comportamiento. Versiones anteriores de Buildbot con versiones anteriores de Mercurial funcionan bien.

En uno de los pasos para realizar el checkout/update, Buildbot verifica si ha cambiado la URL del repositorio. Si esto es así, entonces hace clobbering, o sea, vuelve a bajar todos los cambios (checkout) y obviamente no realiza un update, aunque el modo no sea “clobbering”. Para saber si dicha URL ha cambiado, ejecuta un “hg paths default” en el directorio de trabajo y lo compara con la URL asignada en el archivo de configuración central del Build Master.

El bug está en que al ejecutar “hg paths default” Mercurial 1.3.1 devuelve el password oculto con asteriscos:

$ hg paths default 
http://miltondp:***@url.mi_proyecto.com/path/al/repo

… y, obviamente, la URL asignada en el archivo de configuración está completa (sin el password oculto). Al compararse ambas, son distintas, y por lo tanto siempre se hace clobbering.

Continuá leyendo Si usás Buildbot con Mercurial…

sl: Steam Locomotive

¿Nunca escribieron LS o sl cuando en realidad quisieron ejecutar “ls” en la terminal? Bueno, si les pasó, habrán visto que en Ubuntu salta el siguiente mensaje:

$ sl
El programa «sl» no está instalado actualmente.  Puede instalarlo escribiendo:
sudo apt-get install sl
bash: sl: orden no encontrada

La primera vez que lo vi me pareció extraño, así que instalé el paquete “sl” como me sugería. La descripción del paquete es esta:

Correct you if you type `sl' by mistake
Sl is a program that can display animations aimed to correct you
if you type 'sl' by mistake.
SL stands for Steam Locomotive.

Me imagino que tendrán ahora la intriga de qué es lo que pasa si ejecutan “sl”. Simplemente tengan cuidado 😛

Netboot install con dnsmasq

Tengo en mi casa un Pentium III de 800 MHz con 128 MBs de RAM. Es de César y la vamos a utilizar para el proyecto. No tiene lectora de CD y no tiene soporte para bootear por la red. Les muestro en este post lo que tuve que hacer para instalar Ubuntu Server en una máquina así, de esta forma si lo tienen que hacer se ahorran trabajo.

Continuá leyendo Netboot install con dnsmasq

Agregar números de página a un PDF

Tengo un libro en PDF que no tiene los números de página, y como lo voy imprimiendo de a poco (por miedo a imprimirlo completamente y dejarlo tirado), con el objetivo de abrochar al final todas las páginas o encuadernarlo, hay riesgo de que algún día se me caigan todas las hojas o se me despapele y no sepa cómo ordenarlo rápidamente.

Intenté agregarles el número de página con OpenOffice.org, usando el plugin pdfimport. Parece que el funcionamiento consiste en convertir el PDF a un documento de Draw. El problema es que no encontré, por lo menos en forma directa, cómo agregar un pie de página en esta aplicación.

Me encontré con una solución que explica cómo hacer todo con un script (usa pdftk) y un poco de OpenOffice.org. No se si es la solución más rápida, directa y obvia, pero ahora mi PDF tiene los números de página.

GNU/Linux y el disco duro

Hace unos meses salió una noticia, por varios medios, que apuntaban a Ubuntu un supuesto problema con los discos duros de las laptops.

Investigué un poco (sólo un poco) sobre los discos duros modernos. Los nuevos discos tienen una tecnología “load/unload”, en contraposición con CSS (Contact Start-Stop). En ésta última, las cabezas de los discos, al no estar éste en uso, quedan sobre la superficie del disco. Si hay movimiento de la laptop cuando ésta está encendida por ejemplo, esas cabezas pueden dañar el disco, entre otros problemas que tiene esta tecnología. En cambio con “load/unload”, la cabeza se mueve a un área especial, reduciendo el riesgo de dañar la superficie. En una laptop (móvil) esto es beneficioso. Otras ventajas son una mayor densidad de datos en los discos, mayor durabilidad (lo que dije antes) y menor consumo de energía.

Hay un límite en la cantidad de estos movimientos que un disco puede hacer, después del cual pueden aparecer problemas. Generalmente los discos duros actuales soportan unos 600.000 (más algunos, menos otros).

En la página del bug de Ubuntu, se menciona la experiencia de una persona con GNU/Linux y estos discos duros. Fea experiencia. En aproximadamente 2 años, usando dos laptops, una como servidor y la otra como workstation, tuvo que cambiar el disco rígido 4 veces. Otro tipo, como se puede leer en este comentario, perdió su disco en sólo 7 meses.

Recién estaba en Ubuntu Gutsy, la distro que utilizo, y el disco realizaba estos movimientos bastante seguido (no saqué cuentas, pero era mucho). Hay veces que parece tranquilizarse un poco, pero en algunos momentos, en un período de 10 minutos, realiza aproximadamente 20 de estos movimientos. Reinicié en Windows Vista Home Premium (que vino con la compra de la laptop), y ahora estoy escribiendo el post allí. El disco se encuentra mucho más tranquilo. Realiza esos movimientos de la cabeza, pero no tan exageradamente. Además la temperatura se mantiene normal (45-48 grados). Todo esto me da un poco de bronca, la verdad.

Bueno, creo que este post será más que interesante para los que usan el sistema operativo del pingüino en sus laptops.

Continuá leyendo GNU/Linux y el disco duro