Cosas mías

CUPS es mi Némesis o, como diría mi amigo Juan, mi “mosca cojonera, aaaaaay”. Y es que no tengo suerte con este software bajo Linux. Nunca he conseguido que funcionara bien del todo.

Ahora el problema era sencillo: pese a haber dado de alta correctamente mi HP 1010 láser, los documentos impresos iban a la cuarta dimensión, o generaban el error de client-not-nosequé. Y un log configurado como nivel debu2 no me daba ninguna pista, todo lo que el sistema escribía en ese log era normal… En fin.

 En un reinicio, ya ni siquiera se cargaba el servicio, diciendome algo de un error 15. Eso fue ayer. Hoy han publicado una nueva versión que, parece ser, funciona. La he reinstalado sobreescribiendo los ficheros de configuración, he vuelto a agregar la impresora y, de momento, funciona.

Veremos lo que dura, porque otras veces he observado el mismo comportamiento y cuando he ido a imprimir… no funcionaba y he tenido de reiniciar en Windows para poder hacerlo…

Hacer funcionar la cámara Web, una Genus GE111, también, cómo no, ha resultado toda una odisea inenarrable. Una rápida búsqueda por Internet me ha dicho que mi driver es el spca5xx y que no está incluído en el kernel, sino que es necesario parchearlo… Pero mi Gentoo lo tiene como paquete independiente y símplemente con un

emerge spca5xx

he podido instalar el driver y cargarlo en el núcleo… para descubrir que me afecta el bug del ancho de banda. Este bug, presente en algunas configuraciones, hace que el driver no pueda asignar bien el ancho de banda dentro del USB (cosa que he descubierto, claro está, navegando por Internet).

Hay tres soluciones, dos de ellas sencillas que no me han funcionado y la tercera, parchear el parche. Así que, igual que con el módulo PyQt explicado en la primera entrada de esta serie, he tenido que colocar una nueva versión en el overlay de mi Portage, subir una revisión, modificar el fichero ebuild para que aplique el parche, y actualizar el módulo. Y por supuesto reiniciar linux para que cargue el nuevo módulo, pues no lo tengo compilado con la posibilidad de descargarlos.

Y de momento funciona… mejor que en Windows.

El puto Skype es harina de otro costal. Tras muchas horas mirando aquí y allá, no tengo audio con él porque a la gente que lo hace no le sale de los ejem recompilarlo para 64 bits. Y es que el Skype, que tenemos a nivel corporativo como aplicación de videoconferencia, no es trigo limpio; se trata de un sistema autoencriptado y con código automodificable que al parecer no compila bien bajo 64 bits… 

Mi primera lectura completamente en inglés fuera de la documentación y libros técnicos que manejo, todo un logro personal, porque pese a tratarse de un mero cuento sin mucha profundidad, lo he entendido perfectamente. El argumento es flojo, un detective privado en Marte es encargado de investigar la desaparición del marido de la dueña de una empresa de tranferencia de cuerpos (en lugar de viajar físicamente, viaja tu mente, que colocan en cyborgs adaptados). Al final, con dos vueltas de tuerca, nadie es quien se piensa que es, muestro héroe se hace un poco el sueco, y asistimos a la comprobación de si realmente eres chica gracias a lo que ya expuso Mark Twain en otro lado. Hasta ahora mis contactos con la literatura inglesa han sido esporádicos y muy cortos. Ignoro si es cosa del relato o no, pero abundan las repeticiones de palabras, las mismas construcciones gramaticales repetidas unas detrás de otras, y un cierto aire de “demasiado sencillo”. En fin

Otra tarea pendiente y que he solucionado a medias consiste en mi Microsoft Wireless Natural Multimedia Keyboard (sí, esos partidos) y su ratón correspondiente. Para decirlo con pocas palabras, simplemente hay que decir que bajo Linux no funciona.

No funciona conectado al puerto PS/2 porque genera una serie de texto basura como consecuencia de lo que yo considero es un bug del núcleo 2.6, pues no contempla las 255 teclas, pero no tengo ganas de meterme en líos. Lo curioso es que conectado mediante USB no presenta ese problema.

Este teclado tiene varias teclas completamente muertas, es decir, que el kernel de linux es incapaz de ver, como la de Messenger, la de Cerrar Sesión o la de Suspender. Pero hay otras que sí que ve pero el sistema se encuentra incapaz de remapear convenientemente.

Y son esas las que vamos a forzar a que funcionen y tengan un cometido. No es necesario decirle a las X qué modelo de teclado tenemos, pero si se lo decimos, algunas de esas teclas ya estarán auto asignadas. Por ello, en mi xorg.conf tengo la línea

Option “XkbModel” “microsoft”

El siguiente paso es localizar los keycodes de dichas teclas. Para ello ejecutamos en una consola el programa “xev”. Si no lo tenemos, lo instalamos mediante

emerge xev

Mientras este programa tenga el foco, nos capturará las teclas y nos dará su código de tecla. Entre todo el texto  aparecerá algo como

keycode 240

Eso es lo que necesitamos. El código 240 se corresponde con la tecla de “Mis Documentos” en mi teclado, pero sin embargo la de “Mis Imágenes” no genera ningún código, por lo que no podremos usarla para nada.

Hace tiempo estuve mirando el código fuente del núcleo de linux respecto a este tema, y vi alguna cosa rara pero no me atreví a tocar nada. Lo curioso del tema es que con un núcleo 2.4 funcionan todas, pero con uno 2.6 no, así que me reitero en lo del bug.

El siguiente paso es buscar teclas no asignadas para remapear. Para ello abrimos el fichero /usr/include/X11/keysymdef.h y allí tenemos todos los valores disponibles. En mi caso, y dado que mi teclado sólo llega al F12, he elegido remapear de la F35 hacia abajo.

Remapear una tecla en linux es sencillo: ejecutamos

xmodmap -e ‘keycode <code>=<keyname>’

para asignar un nombre a una tecla que no lo tiene. Por ello, si ejecutamos

xmodmap -e ‘keycode 240=F35′

estaremos diciendo a Linux que la tecla “Mis Documentos” es F35. Y F35 es una tecla válida para asignar allá donde queramos. 

Y ahora viene el truco del almendruco, al menos para el KDE. Si tuviéramos que ejecutar esa línea de comandos para cada tecla y cada vez que entremos en el KDE, sería un absurdo, por lo que creamos un fichero de texto con permisos de ejecución con el nombre que queramos y lo situamos en

.kde/Autostart

y dentro de ese fichero colocamos todas nuestras asignaciones, más o menos así:

#! /bin/sh
xmodmap -e ‘keycode 130=F35′
xmodmap -e ‘keycode 129=F34′
…

De este modo, cada vez que iniciemos KDE se nos remapearán esas teclas y podremos usarlas dentro del entorno. Evidentemente, hay más lugares en donde colocar un script para que se autolance, pero en mi caso me vale así.

Otra cosa que debería hacer es reasignar los dos botones laterales del ratón -lo ideal es que se mapearan en combinaciones de teclas-, pero aparte de reordenarlos y de asignar los de la rueda, no he visto nada… Así que si alguien sabe cómo hacerlo, que por favor me lo diga… 

No era mi intención iniciar otra serie de entradas sobre el tema de arriba, pero considero que puede resultar interesante, y es en lo que estoy ahorita mismo.

Tras terminar de actualizar nuestra placa con Windows CE, nos surge la obligación de realizar los mismos pasos con Linux, ya que varios de nuestros clientes así nos lo exigen.

No es que esté muy contento con ello, porque por experiencia propia sobrevivir bajo este sistema operativo es toda una odisea -muy a persar de lo que digan los fundamentalistas linuxeros-, principalmente porque para hacer cualquier cosa necesitas leerte diez mil documentos, trastear durante dos horas y al final, si hay suerte, te funcionará. O no.

Para mi va a ser toda una aventura, pues será la primera vez que voy a implentar un sistema embebido que no es un PC y que va a ejecutar Linux en sus tripas.

La primera decisión es qué distribución instalar. Todas las distros populares adolecen del mismo problema: cargan todos los módulos del núcleo, son lentísimas a la hora de cargarse y cuando te sales de lo políticamente correcto no hay asistente y tienes que pelearte con los miles de ficheros de texto.

Por eso he elegido una Gentoo, porque yo lo valgo, porque si uno elige Linux ha de elegir lo mejor y porque me siento cómodo con ella. Además, entro a formar parte del selecto grupo de la gentooza, y cuando me surga un problema, voy a saber dónde tocar, pues asistentes tiene pocos.

Compilar una Gentoo desde un estado 3 es casi una bagatela en un AMD64 X2 con 2 Gb de RAM, eso se come el código fuente a espuertas; tardó apenas cuatro horas a compilar el KDE completo junto al KOffice, KDevelop y KDESdk.

El primer problema surge con los formatos de partición. Mi Windows XP tiene NTFS y mi Gentoo, reiserfs. Y debo por lo menos ver las particiones NTFS desde Linux.

El Kernel 2.6.xx trae soporte de serie para montar particiones NTFS de sólo lectura (También lo trae para escribir en ellas, aunque ni borracho se me ocurriría).

Pero sería estupendo si pudiera escribir en NTFS. Por ejemplo, todo el código fuente de la placa colgaría de las mismas ramas que todo mi código fuente Windows, podría utilizar el Opera como lector de correo y news compartido con Windows (Uitiliza el mismo formato de ficheros).

Así que me lío la manta a la cabeza y… descubro ntfs-3g, un parche al kernel y paquete que permite la escritura sobre NTFS sin problemas… en un sistema x86. El autor de la herramienta dice que no puede probar sobre un sistema de 64 bits porque no tiene, pero a la gente que lo ha hecho le ha ido bien.

Efectivamente, funciona de cine, de momento tengo el Opera compartido y no he observado nada extraño.

Para instalar este soporte en una Gentoo es necesario lo primero de todo desenmascarar el paquete ntfs3g y fuse, por lo que hay que añadir estas dos líneas en /etc/portage/package.keywords:

y luego realizar un “emerge ntfs3g”.
¿Sencillo?

Si hubiera funcionado, sí, pero no funciona.

Estos paquetes dependen de PyQt que presenta un bug que impide compilarlo con la biblioteca glib instalada por defecto y de momento no tiene solución, aunque sí rodeo.

Vamos allá. Tenemos que enmascarar la versión actual, la 3.14.1-r2. Pare ello añadimos la línea

<=dev-python/PyQt-3.14.1-r2

al fichero /etc/portage/package.mask

Pero así no podemos compilar el proyecto. Tenemos que hacernos un “portage overlay”, o sea, crearnos una rama interna del Portage, copiar el paquete y subir una versión, cambiando una serie de cosas en sus ficheros de paquetes.

Primero creamos la rama de carpetas /usr/local/portage/dev-python/PyQt y copiamos todo el contiendo de /usr/portage/dev-python/PyQt. Posteriormente copiamos el fichero PyQt-3.14.1-r2.ebuild como PyQt-3.14.1-r3.ebuild, lo editamos y quitamos la línea del parche de compatibilidad. Luego hacemos un digest sobre el propio fichero.

Pero tenemos que decirle al Portage que tenemos nuestra rama de portage personalizada. Para ello abrimos el fichero /etc/make.conf y añadimos el texto “PORTDIR_OVERLAY=/usr/local/portage” sin las comillas.

Ahora, cuando el sistema pida compilar el PyQt verá que hay una versión superor a las enmascaradas en el repositorio local, y usará ese paquete. Y cuando se actualice y se solucione e bug, como poco se presentará la versión r3 si no una superior, y entonces el sistema actualizará la nueva, a no ser que ésta presente el mismo bug y tengamos que repetir el proceso. 

¿Veis lo que quiero decir con lo de sobrevivir?

Seguimos.

Ahora sí que podemos instalar el paquete adecuado. Ya solo nos queda modificar el fstab con el nuevo sistema de ficheros

/dev/partición /punto_montaje ntfs-3g auto,user,uid=1000,rw 0 0

y actualizar el listado de módulos con update_modules. La pega es que cada vez que recompilemos el núcleo debemos regenerar dicho paquete.

Y ahora viene el publicar este post. El Opera se arma la picha un lío con los campos de edición y hace unos desbarajustes de cojones. El Konqueror no entiende el login de Geeks.ms, por lo que mientras escribo este texto en el Kate, compilo el Firefox 2.0, que también he tenido que poner en package.keywords.

Y ya es hora de publicar el post, pero antes tengo que añadir el Firefox a la lista de menús, por lo que tengo que ejecutar el “Actualizador de Menús”… ¿Van entendiendo?

Tengo que copiar el texto desde el Kate, y en el proceso se pierde el formato… con lo que tengo que volver a meter todos los párrafos y las indentaciones y, finalmente, aquí está el post.

Mañana hablaremos sobre cómo hacer funcionar las teclas multimedia… cuando estas no funcionan.
 

Llevo como tres meses dándole caña al Windows CE 5.0, principalmente como ayuda a uno de nuestros partners tecnológicos, ya que se encuentran desbordados de trabajo y nuestros clientes nos exigen/quieren ciertas actualizaciones y mejoras al desarrollo base, no de las bibliotecas ofrecidas, sino de la propia plataforma y del modo de desarrollar, que ciertamente se abandonó en preferencia a la creación de una biblioteca de clases, puesto que el dispositivo que ahora tenemos es de los denominados no head, o sea, sin vídeo.

No es que nuestra placa no disponga de pantalla, que la tiene, sino que se ha eliminado todo lo relativo al GUI que trae Windows CE de serie y se ha sustituído por una biblioteca gráfica mucho más potente y acorde con el destino del dispositivo, al modo de las Direct X, pero con otros conceptos sobre los cuales no puedo hablar.

Esta entrada quiere ser, pues, un punto de introducción sobre Windows CE y la construcción de sistemas operativos a partir de él. Por lo tanto, comencemos por el principio.

Windows CE es un sistema operativo de tiempo real no estricto, adecuado para ser instalado en multitud de arquitecturas y microprocesadores de 32 bits, que van desde el clásio x86 hasta los modernos ARM 9, XScale, SuperH, y un largo etcétera. Y por si eso fuera poco, Windows CE está compuesto por un sistema modular que ofrece la posibilidad de incluir aquellos componentes que estimemos oportunos.

Además, el coste de la licencia básica es, si no me equivoco, de 4 dólares USA.

El Platform Builder es la herramienta con la que se construye el sistema. Disponemos de un amplísimo catálogo de componentes que podemos ir instalando en nuestro proyecto, para luego pasar a la construcción del sistema operativo en sí. La tarea a simple vista puede parecer trivial, y generalmente lo es, aunque a veces pueden presentarse problemas insospechados.

Por otro lado, el fabricante del microprocesador tiene que suministrarnos lo que se llama la BSP, que es un bloque de código fuente, así como una serie de archivos que instruyen al Platform Builder de la arquitectura y de los recursos disponibles, de forma que la conjunción de estos dos elementos constituye lo único necesario para tener rápidamente un sistema operativo específicamente construido para nuestra placa.

Evidentemente, necesitamos una placa sobre la que ejecutar dicho sistema operativo, y desde mi opinión es el punto más difícil de todos, y requiere buenos ingenieros de hardware dada la complejidad del asunto. Construir una placa para Windows CE no es tarea trivial. Consideremos que una PDA o un teléfono móvil son dos ejemplos tipo, y de hecho ambos ejecutan versiones modificadas de Windows CE, ya que los Windows Mobile no son mas que versiones modificadas de Windows CE, aunque no aparezcan en los catálogos del Platform Builder.

Un dispositivo que ejecute Windows CE permite varios modelos o formas de desarrollo, algunas de ellas casí idénticas -pero con ciertas limitaciones- a las de PC. El marco de trabajo básico es un subconjunto bastante amplio del API de Win32, y sobre él se ejecutan otras bibliotecas como las MFC y otros marcos más modernos, como las versiones Compact del -NET 1.0 y 2.0. Podemos, pues, desarrollar los siguientes tipos de aplicativos:

• Win32 en C o C++ con el eMBedded Visual C++ o el Visual Studio 2005
• MFC o ATL con las mismas herramientas anteriores.
• .NET Compact Framework 1.0, en C# y VB.NET con el Visual Studio 2003
• .NET Compact Framework 2.0, en C# y VB.NET con el Visual Studio 2005
• Visual Basic 3.0, una versión especial de Visual Basic ahora completamente descatalogada pero que todavía se puede encontrar.

Podemos comprobar que las posibilidades de desarrollo son enormes. El autor de estas líneas ha realizado proyectos en Win32, MFC y .NET 2.0 en C#, y puede afirmar que el rendimiento, dentro de las características, es muy bueno, sobre todo con lenguajes no tan evidentes como el C#.

En una próxima entrega hablaremos de las diferencias entre programar para PC y para dispositivos embebidos.

En Windows XP Profesional x86 no sé, pero en x64 no hay ninguno que merezca la pena. Vamos allá:

Outlook Express:

• Si inspeccionas un mensaje, el programa se cae solo cuando le toca actualizar, sólo pasa 1 de cada 10 veces aprox.
• A veces las cuentas se cambian de sitio. Es una cosa muy extraña, y no suele ser muy habitual, pero cuando ocurre te entra una mala leche…. Simplemente una cuenta de news se convierte en cuenta de correo.
• Pierde mensajes. De repente, una carpeta aparece vacía.
• En un sistema multimonitor, no funciona en el secundario (y yo me pregunto qué tendrá que ver el tocino con la velocidad).
• Cuando sólo hay un mensaje sin leer (y a veces cuando hay muchos también), Ctrl-U dice que no hay mensajes y pregunta si cambia a la siguiente carpeta.
• Cuando hay mensajes sin leer en carpetas anteriores y llegas a la última, te dice que no hay más mensajes sin leer.

Opera:

• No conserva los hilos, rompe la secuencia general y a veces no sabes ni donde estás.
• El sistema de seguimiento de mensajes propio no funciona.
• Dependiendo de qué servidores y qué grupos, consume el 100% de recursos de la máquina y hay que matarlo.
• A veces, sin ton ni son, deja de actualizar un grupo y no hay cojones a que lo vuelva a hacer si no es borrando TODAS las cuentas y TODAS las carpetas de almacén.
• A veces se le olvida bajarse algún mensaje de correo electrónico, y este permanece en la bandeja de entrada ad-infinitum.
• Muchas veces no ve grupos nuevos en los servidores.
• Tienes que bajar 250 mensajes por cuenta cuando lo instalas, ni uno más ni uno menos.
• El nuevo sistema de almacenamiento es más lento que una caca, con lo bien que iba el anterior.
• Cuando has leído un grupo/carpeta, no salta automáticamente al siguiente.
• A veces se queda marcado que quedan x mensajes sin leer y éstos no aparecen por ningún lado, y la solución es borrar el servidor y los ficheros asociados.
• No soporta ROT13 (creo) ni "unir y decodificar".

Mozilla Thunderbird:

• La mitad de las veces los cuadros de diálogo no se cierran con OK o Aceptar, por lo que no puedes cambiar opciones.
• No actualiza los mensajes al iniciar aunque se lo digas.
• Tampoco pulsando el botón rápido adecuado, hay que bajar las cuentas a mano.
• Los RSS se repiten muchas veces.
• Pasar de online a ofline no funciona, se queda enganchado intentando bajar mensajes que no existen.
• No siempre se bajan todos los RSS, a veces hay que bajarlos a mano.
• No importa bien los mensajes, se deja carpetas vacías y sólo importa dos niveles de carpetas, pero sólo a veces.
• El archivo de firma ha de estar en ASCII, con lo que no se pueden poner acentos desde un editor externo.
• La tecla "n" no cambia a veces al siguiente mensaje sin leer, sobre todo si no estás sobre un mensaje y con el foco sobre la lista de mensajes.
• De vez en cuando se le va la cabeza y te arma la de dios y te toca regenerar los índices.
• A veces pierde mensajes, cada vez que abres la carpeta correspondiente, te pierde uno.
• No soporta ROT13 (creo) ni "unir y decodificar".
• Pasar de online a offline a veces te baja todos los mensajes de nuevo… hasta en grupos con varios miles.

Y todo esto de lo que ahora me acuerdo, que seguro se me escapan cosas. Capón a las empresas de software propietario y a la gente del Open Source.

Sé que hay más lectores:

• Agent: es tan sumamente complejo y lioso que al final te armas un jaleo de cojones; es lento de cojones y sólo permite modo online/ofline y es una jodienda eso de ir marcando mensajes uno a uno.
• XNEWS: Un poco obsoleto ya, no me convence porque está pensado para grupos binarios y las cosas que pueden hacerse con ellos.
• MesNews: No termina de convencerme, quizás lo pruebe más a fondo.

Último volumen de la serie original, y como tal a mi modo de ver el peor de todos. Si en el anterior el tema introspectivo llega a absurdos desesperantes, en este todavía resulta peor, como también empeora el nivel de barbaridad y los absurdos, en competición con la física más evidente.

Obra totalmente prescindible, de hecho es la segunda vez que la leo y espero recordar no volver a hacerlo más.

En ella la Senda de Oro llega a su desenlace final, con la introducción del amor dentro de la Bene Gesserit así como la mezcla con las Honoradas Matres, y ciertos serres humanos consiguen trascender por completo el espacio y el tiempo, quedando fuera y completamente libres de cualquier atadura física.

Cuarto tomo de la saga original, del que apenas recordaba nada pese a haberlo leído ya dos veces, tres con ésta.

Y es razonable que no recuerde nada de él, puesto que salvo un final apoteósico y etonante -excesivo a mi modo de ver-, casi nada ocurre en el libro. Un ghola Duncan Idaho es entrenado en Gammu, el Bashar Miles Teg la arma bien gorda, la aparición de las Honoradas Matres y poco más. Y encima con errores de bulto, algunos bastante evidentes. Edificios que resisten diez mil años, no-estancias antes de que fueran inventadas…

Aunque han transcurrido más de tres mil años desde la muerte del Tirano, su Senda de Oro todavía está en camino, apoyada sin querer por la Bene Gesserit, y finalmente comprendida. Esa Senda de Oro pretende conseguir seres humanos capaces de trascender el espacio y el tiempo, capaces de ver más allá de la realidad aparante y ser capaces de forjarse su propio futuro, más allá de la física, como al final veremos en el sexto y último libro de la serie original.

Y lo peor y más cargante de todo es ese aire instrospectivo, pesado y completamente fuera de lugar.

Con altibajos en la narración, plagada de inconsistencias (no creo que la gente en aquella época tuviera despachos, o inquietudes ecológicas, etc), en un tono llano y carente de toda pretensión el autor nos cuenta el inicio de la construcción de las primeras pirámides, lo que le sirve de via para narrarnos una aventura de misterio, con malos malosos y buenos buenosos.

El libro es lo que es: una mera novela de entretenimiento, sin pretensiones y con algún que otro fallo argumental, como inconsistencias temporales o escenas forzadas en exceso. 

Cuarta entrega de la serie original, en ella Herbert nos presenta a un dios vivo, a un ser inmortal y todopoderoso que controla a la humanidad con mano de hierro. Es el tirano de los tiranos, el gran opresor y el gran asesino, la suma de todos los tiranos habidos y por haber… Pero sin embargo sus intenciones son buenas, pues sin él, la humanidad habría desaparecido del universo.

Herbert quiere hacernos comprender dos cosas. La primera es que todos los tiranos, desde su punto de vista, están llenos de buenas intenciones… para ellos mismos. La segundo es que sin trabajo no hay ganancia.

Leto oprime a la humanidad para reconcentrar sus propias fuerzas, para que desarrolle todo su potencial, a través de la ya citada opresión y mediante un programa genético para que la humanidad no deje rastros en el continuo espaciotemporal y no pueda ser seguida por seres prescientes, para así liberarla de toda atadura.

El libro, aunque pudiera parecer largo y pesado, apenas contiene los hechos y la sociedad que Herbert nos quiere contar. Y de hecho se necesita una segunda lectura para sacar todo el jugo al mismo.