eMartos

Sí, Linux también falla, pero a diferencia de Windows, se puede arreglar. Además, en favor de Linux, debo decir que no parece un error de software, sino de hardware.

Resumiendo: Ayer, cuando me disponía a apagar el equipo, donde tengo instalado un Kubuntu 10.04.1 LTS, empecé a notar una lentitud extrema en los procesos y, como colofón, un bloqueo de escritura en disco. Esto no suele anticipar nada bueno. Sólo conozco cuatro causas por las que se bloquea la escritura en disco en Linux:

1. No queda suficiente espacio libre en disco.
2. Se ha rebasado el número de punteros de disco permitidos.
3. La versión de Linux instalada tiene un error a nivel de core que bloquea la escritura a disco arbitrariamente.
4. El disco tiene sectores defectuosos.

La mía fue la cuarta. Esta mañana, al reiniciar el equipo, me encontré sin modo gráfico ni línea de comandos: Me recibió un sobrio mensaje de error de disco.

El primer reflejo fue reiniciar en modo recuperación, pero el resultado final fue el mismo. Tras varios intentos fallidos, di con la tecla, aunque no garantizo que le sirva a todo el mundo:

1. Arrancar con un live CD.
2. Ejecutar, en una terminal, el siguiente comando:

   sudo fsck -f /etc/sdb1

   (reemplazar sdb1 por el disco duro afectado)
3. Desinstalar el driver de vídeo:

   sudo dpkg --purge fglrx

   (los propietarios de nVidia deben reemplazar //fglrx// por //nvidia//)
4. Instalar el driver de vídeo:

   sudo apt-get install fglrx

   (los propietarios de nVidia deben reemplazar //fglrx// por //nvidia//)

Con estos sencillos pasos, he conseguido estabilizar el sistema. Gracias a la nube y a los backups programados, en ningún momento he temido por mis datos, y en caso de catástrofe extrema, la mayor parte del software que utilizo también reside en la nube (creo que se salvan Spotify, Eclipse, OpenOffice y los propios navegadores).

¡Por fin una buena noticia sobre el DNIe! Después de tantos problemas, de tantos trucos (a veces infructuosos) para echar a andar la autenticación y la firma no sólo en sistemas Linux, sino también en Windows, parece que vamos hacia un camino de simplificación gracias al manual de comandos del DNIe.

¿Por qué es esto tan importante? Porque este manual permite una comunicación directa con el chip del DNIe, sin necesidad de acudir a sus drivers nativos, que como todos sabemos, rara vez funcionaban en sistemas Linux.

Además, este manual abre la puerta a un camino más sencillo para la instalación del entorno adecuado por parte del usuario final, lo que no sólo beneficia a éste, sino también a todas las empresas que quieran sacarle partido a la autenticación y firma que ofrece el documento de identidad electrónico.

Vía GenBeta.

Buscando una manera definitiva de instalar el DNIe en Linux, he encontrado un excelente tutorial en bitelia que lo explica paso a paso y en un tono muy asequible para usuarios de cualquier nivel.

Lo ideal sería que el soporte fuera oficial, y aunque ya se han publicado los fuentes PKCS11, todavía queda mucho camino por recorrer para que Linux sea considerado por las autoridades una opción tan válida como Windows.

A veces, la tecla Alt Gr (alternativa gráfica) deja de funcionar en Ubuntu desde la versión 9.10 (Karmic Koala). Para solucionarlo (en Gnome, al menos), hay que acceder a la configuración del teclado:

1. Sistema > Preferencias > Teclado > Pestaña Distribuciones > Botón Opciones de distribución.
2. Desplegar opción Tecla para escoger el tercer nivel.
3. Activar Alt derecha.

No sé si es una solución definitiva, pero a mí no me ha vuelto a dar problemas.

El sábado 1 de mayo estuve con @spesgmd en el Encuentro Gnome Sevilla, organizado por Yaco y Emergya. No había escrito nada hasta ahora porque he tenido una semana de perros, y sábado y domingo los he usado para un merecido descanso. Hecho el inciso de justificación, prosigo.

Las oficinas de Yaco son realmente atractivas; creo que no hay dos paredes del mismo color, casi todos los espacios son abiertos y tienen una mesa de billar. Como llegamos para la charla de las 12:30 sobre accesibilidad, y había gente desde primera hora, nos tuvimos que conformar con participar desde los laterales del aula, pero con las ventanas abiertas se escuchaba bien.

Gracias a los comentarios de los compañeros que participaron, me puse al día en lo que a accesibilidad open source se refiere. Se habló de aplicaciones y utilidades como at-spi2 (hook entre los lectores de pantalla y el sistema operativo), Orca (el lector de pantalla OS por excelencia), Evince (un lector PDF accesible en cuanto a menús y controles, pero no muy maduro en lo que a los propios documentos se refiere) un lector de PDF que no parece estar muy maduro (creo que se llama Lince, pero no he encontrado referencias al respecto), OCR Reader (un lector OCR para ciegos) y Caribou (teclado virtual para personas con movilidad reducidas). También se trató la diferencia entre Gnome y KDE en lo que a accesibilidad se refiere (al fondo, en una pizarra, se leía: "The world is blue like KDE"), aunque desde mi humilde punto de vista, sería interesante coordinar desarrollos comunes para que la opción de usar un escritorio, para personas con problemas de accesibilidad, fuera tan libre como para cualquiera. Por último, se expusieron las necesidades actuales, que se pueden resumir en lectores de braille, software de reconocimiento de voz y comunicadores pictográficos, así como en centros interesados tanto en consumir estas soluciones como en asesorarlas para que sean realmente útiles (ONCE, centros de parálisis cerebral, etc.).

La segunda charla versaba sobre CouchDB y vino de la mano de Rodrigo Moya. Se trata de un servidor de documentos almacenados en base de datos que son servidos mediante REST. Forma parte de los sistemas NoSQL, es decir, bases de datos no relacionales. Entre sus características más notables está el hecho de ser distribuido, con soporte para sincronización entre distintas instancias, y de poseer un sistema de detección y gestión de conflictos, lo que lo convierte en un sistema ciertamente robusto y fiable.

Los documentos se almacenan en formato JSON. Soportan tipos de datos básicos, listas y estructuras, objetos, estructuras libres y ficheros adjuntos. Cada documento tiene un identificador único (_id) y un número de revisión (_rev).

Una base de datos contiene una colección de documentos, y su número no está restringido, así como tampoco su tamaño ni el número de documentos que puede almacenar. CouchDB está escrito en Erlang, lo que, al parecer, garantiza que los datos no se corromperán aunque el sistema se caiga.

Las consultas se canalizan a través de las vistas, que se escriben en JavaScript y devuelven resultados formateados. Se definen dentro de un documento de la base de datos con un nombre especial y conteniendo una función en JavaScript. Como las vistas tradicionales de cualquier SGBD, cachean los resultados.

Otro aspecto interesante, y en el que se basaba realmente la charla, es la sincronización, que permite replicar datos entre cuantas instancias se desee de manera bidireccional. Se copian sólo los documentos y campos que han sido modificados, lo que según Rodrigo es muy eficiente, pero que un compañero discutió arguyendo haber realizado pruebas de rendimiento con CouchDB, las cuales demostraban un descenso del mismo con un volumen alto de documentos. El algoritmo de generación de revisiones es idéntico en todas las instancias, lo que asegura la detección de las últimas versiones reales y permite detectar y gestionar los conflictos, actualmente de manera manual, y en el futuro, esperan, de forma automática.

CouchDB se integra con C (a través de la librería couchdb-glib, con bindings en desarrollo para Mono, Vala y Python), Python (a través de python-couchdb) y Java (a través de jcouchdb).

Se quedó en el tintero una explicación más detallada del descubrimiento de instancias y publicación de servicios a través de Avahi.

La última parte de la charla versó acerca de DesktopCouch, una integración de CouchDB en aplicaciones de escritorio para la replicación y sincronización automática de información entre ordenadores. Forma parte de la integración de Ubuntu One en el escritorio. La idea central consiste en mantener sincronizados nuestros contactos, notas y marcadores (y en el futuro, otro tipo de datos) con servidores distribuidos para acceder a nuestra información desde cualquier lugar y con nuestras aplicaciones favoritas. La integración ya es un hecho con Tomboy, Convoy y Tomdroid para las notas; Evolution, Akonadi y Thunderbird para los contactos; y Firefox para los marcadores.

Claro que no todo el trabajo está hecho. Una de los problemas que están intentando resolver es la estandarización de formatos, algo imprescindible para que las aplicaciones puedan trabajar entre sí, y que tiene mucha relación con la web semántica. Uno de los objetivos más ambiciosos es que aplicaciones en principio incompatibles, como las de KDE y Gnome, puedan por fin entenderse.

A corto plazo, la intención es integrar las tareas en Evolution y sincronizar la configuración de Gsettings, lo que significaría que puedes sentarte frente a un ordenador de un desconocido y tener tu configuración personal replicada. A medio plazo, se proponen integrar calendario y tareas en Evolution y Akonadi, así como los metadatos de Tracker. A largo plazo, que todos nuestros datos estén replicados en nuestras máquinas y dispositivos móviles, y por qué no, dominar el mundo.

Mi impresión de las dos charlas, además de mi profundo desconocimiento de los temas que se trataron, fue que el panorama open source se está consolidando en nuestra región, pero son pocas las empresas que apuestan realmente por esta filosofía. Es de esperar que este movimiento acabe cuajando y se convierta en lo habitual.

Actualización 11/05/2010. Agradezco a @spesgmd que me haya sacado de la confusión entre Lince (que no existe) y Evince.

Con la reciente creación de la página de eMartos en Tuenti, he iniciado un debate sobre el uso de Linux como sistema operativo de escritorio. Los motivos que esgrimo en favor del sistema libre se basan en mi experiencia y creo que son asequibles para usuarios no técnicos:

1. Linux no se degrada. Dicho de otra forma, no es necesario formatear el ordenador de cuando en cuando, ni de un día para otro empieza a ir más lento.
2. Linux permite recuperar un sistema de ficheros roto. En Windows, cuando se pierde un fichero o el disco duro tiene problemas de integridad, rara vez es posible recuperarlo, y para intentarlo es preciso usar herramientas de terceros. En Linux, la recuperación es automática y se puede realizar con herramientas nativas.
3. En Linux no hay virus. Aunque es cierto que existen algunas condiciones que permitirían ejecutar código malicioso en Linux, es bastante improbable que esto suceda gracias al sistema de permisos del sistema operativo y al hecho de que la gran mayoría de las aplicaciones se instalan, desde repositorios de confianza, a partir de código fuente. En Windows, los virus son una lacra insufrible, y el sistema carece de antivirus propio.
4. En Linux, la mayoría de aplicaciones necesarias son gratuitas. Y no me refiero a que se puedan conseguir vía p2p, sino a que sus autores las ofrecen sin coste. En Windows, ni siquiera podemos grabar un DVD sin tener que buscar un programa específico. Esto no significa que todo en Linux sea gratuito, pero sí lo esencial.
5. Linux logra un mejor rendimiento de ordenadores viejos. Los ordenadores antiguos, esos que nadie quiere porque no se les puede instalar ni un XP, suelen funcionar bastante bien con casi cualquier distribución de Linux, con lo que se les puede dar una nueva vida.

Y lo más importante de todo: Windows no tiene mascota.

Anoche estaba trabajando en este sitio web que usted lee ahora mismo. Desde entonces hasta este preciso instante en que yo escribo, todo ha sido un cúmulo de despropósitos que intentaré resumir de una manera amena:

• Síntoma: Mi instancia de Drupal empieza a hacer cosas raras, entre ellas hablarme mal de su propio sistema de caché con mensajes que no voy a repetir por su escasa utilidad. Dando por buenas sus quejas, limpio la caché y entonces todo deja de tener sentido: Drupal se deteriora gravemente.
• Intento nº 0: Reinicio MySQL. La parada muy bien, pero el arranque me deja tirado. Lo intento tres veces más sin éxito.
  Compruebo que el disco tiene suficiente espacio libre. 15 GB no es gran cosa, pero tampoco es para que se agobie. Pensando que se trata de un bloqueo transitorio del disco duro marca Debian, decido reiniciar.
  • Resultado: Pésima idea, sobre todo si se pretende terminar un trabajo a las tres de la mañana: El sistema no arranca, no es capaz de montar las particiones y aparece la shell de BusyBox ("la navaja suiza de Linux").
• Intento nº 1: Arranco desde un live cd y trato de abrir la unidad de disco.
  • Resultado: No es posible abrir la unidad de disco. Salta el siguiente mensaje de error:
    
    

    mount: wrong fs type, bad option, bad superblock on /dev/sda1

    
    
    Nota: Sustituya sda1 por el dispositivo que corresponda.
    

• Intento nº 2: Teniendo ya presente que los descriptores del disco se han ido a paseo, intento profundizar en la cuestión:
  
  

  dmesg | tail

  • Resultado: Obtenemos, entre otras cosas, este mensaje:
    
    

    EXT3-fs: group descriptors corrupted!

• Intento nº 3: Como lo importante no es tener todas las respuestas, sino saber encontrarlas, se va uno a Google y busca la maldita frase. Entre los resultados encontramos uno que parece bueno.
  • Resultado final: Si seguimos los pasos descritos por nuestro sysadmin de cdbarra, y esperamos pacientemente a que el proceso de fsck.ext3 termine, de momento ya podremos acceder al disco duro. A continuación, le recomiendo almacenar la información importante en un sistema de almacenamiento externo (o mejor, en la red si dispone de un canuto medio decente) y tras ello, reiniciar. Lo más probable es que haya perdido información temporal y poco más. En mi caso, alegremente, puedo decir que no he perdido ni un bit, aunque lo cierto es que mi copia de seguridad funciona religiosamente todos los días.

Sea como fuere, hay que dar las gracias al autor del artículo que ha salvado nuestro disco duro. ¡Gracias, sysadmin de cdbarra!

Hoy me he encontrado con el típico problema informático-casero que te roba toda la tarde (y parte de la noche) no para mejorar, sino simplemente para seguir como estabas. El caso es que he mi Kubuntu 9.04 no ha arrancado muy católico: el escritorio (todos los plasmas) estaba bloqueado. Tras un par de reinicios de comprobación, el asunto seguía igual de feo, así que recurrí a los típicos intentos de recuperación (pulsar escape mientras el sistema está arrancando para que el amable Grub nos invite a iniciar el agente de recuperación): fsck, xfix, dpkg-reconfigure, etc., todos ellos sin éxito. Creo recordar que también probé a actualizar KDE vía apt-get y reconfiguré manualmente los paquetes importantes. Esta vez, al reiniciar, todo empeoró: ni siquiera arrancaba el escritorio, y en su lugar aparecía una pantalla llena de píxeles con colores aleatorios. Es decir, el driver gráfico fastidiado.

Ya me tuve que poner serio y recurrí a un buen enlace que me proporcionó las herramientas para seguir pilotando en solitairo. El caso es que mi distro es Jaunty Jackalope, no Edgy (aunque luego descubrí que existía un manual específico para Jaunty), y al final mi vida se ha resuelto con los siguientes pasos:

1. Descargar la última versión de los drivers propietarios de mi tarjeta (cuyo modelo se averigua ejecutando: 

   lspci | grep VGA

   en una terminal) del sitio web de ATI.
2. Instalar los drivers siguiendo las instrucciones proporcionadas por ATI en la mencionada web. En mi caso concreto: 

   sh ati-driver-installer-9-8-x86.x86_64.run

3. Desinstalar los plasma de KDE: 

   apt-get remove kdebase-plasma

4. Volver a instalar los plasma: 

   apt-get install kdebase-plasma

NOTA: Evidentemente, estos comandos debe ejecutarlos un usuario que tenga privilegios de root (es decir, precedidos por sudo), o con el propio usuario root.

Hace unos días, tras hacer algo inofensivo en una Ubuntu Intrepid, GDM dejó de funcionar y, como consecuencia, el inicio de sesión en el sistema se fue a tomar viento fresco. Concretamente, tras introducir usuario y password correctos (si son incorrectos, muestra un error), aparecía un mensaje en consola y volvía a solicitar las credenciales.

Dado que confío en el poder de regeneración de Linux, entré en modo de recuperación, realicé todas las verificaciones pertinentes, creé un nuevo usuario... Nada funcionó. Las búsquedas en Google fracasaron, pero aun así, seguí insistiendo. Probé, por ejemplo, a reconstruir el fichero /etc/passwd, pero tampoco sirvió de nada. Estaba a punto de desistir cuando recordé haber visto, justo antes de la catástrofe, un segmentation fault que no venía a cuento. Nuevamente en modo recuperación, ejecuté un passwd como root, que generó un lindo segmentation fault. Así las cosas, googleé lo siguiente:

passwd segmentation fault cannot login tty1

Y por fin, tras días de ardua indagación, llegué hasta este foro, donde un acertadísimo mould resolvió mis problemas: Elimina el paquete libpam-smbpass y tu vida volverá a ser satisfactoria. Así lo hice, y aunque no me ha bajado la hipoteca ni he ganado la lotería, hace un rato pude acceder nuevamente a mi Ubuntu Intrepid, que estuvo a punto de convertirse en una Kubuntu Jaunty Jackalope.