23 de octubre de 2011

Perdiendo el miedo a Akonadi

Al actualizarme a Fedora 16 Beta he tenido que enfrentarme a uno de los retos que como usuario de Kmail temía: El paso a "Kmail 2", también conocido como "Kmail basado en Akonadi".

Akonadi es uno de los mayores problemas-capricho que mucha gente tiene a día de hoy con KDE. Por problema-capricho hemos de entender no un "problema" en si, sino más bien uno de esos caprichos tecno-estéticos que la gente tiene a veces (yo el primero) con el software: No se trata de que Akonadi les impida usar KDE, sino de que no les gusta, no les da la impresión de que sirva para nada, y consideran que la existencia de una instancia de mysql en un escritorio es un error intolerable que debería ser corregido.

No voy a discutir la razón de ser de Akonadi (porque hace años que tengo un borrador a medio escribir que toca el tema y quiero terminarlo algún día), pero podría simplificarlo en que todos tienen una pequeña parte de razón: si, tener una base de datos en el escritorio es algo recargado, pero también es cierto que poder programar un cliente de correo simple en 10 minutos es síntoma de que hay algo que se está haciendo bien.

En anteriores ocasiones mi experiencia con Akonadi había sido bastante negativa. Entendía la enorme utilidad de lo que querían hacer, pero el resultado final era tan desesperante que uno se lo tomaba como una empresa quijotesca sin futuro: El miedo natural a la idea de guardar todos mis correos y datos de escritorio en una base de datos mysql, unido a los fallos constantes que veía en Akonadi, me hacía huir de todo ello como la peste. Sobre todo, en lo referente a mi sagrado archivo de correos en formato maildir. No entendía porque tenía que renunciar a maildir. Tal vez para un usuario de formato mailbox sea más fácil.

Esto se debía a que no tenía ni puñetera idea. Akonadi no consiste en eso. Los correos no se guardan en mysql, siguen guardándose en formato maildir. ¿Qué demonios hace Akonadi, entonces? Podría decirse que es una especie de "cache": kmail accede a los correos a través de las interfaces de Akonadi, y es Akonadi quien lee el formato maildir y crea cachés (que se guardan en bases de datos mysql) de esas peticiones. La cuentas de correo pasan a ser parte de la configuración de Akonadi, y el proceso de bajar el correo nuevo consiste en que el recurso de akonadi pop3 descarga el correo, actualiza los caches de Akonadi y el recurso maildir sincroniza a Akonadi con mi archivo de correos, añadiendo el correo descargado. Los caches de Akonadi se van creando y destruyendo dinámicamente, pero son sólo eso, caches, pueden borrarse por completo y no pasa nada, Akonadi simplemente los reconstruirá.

El resultado final ha sido es que mi migración a Kmail2/Akonadi ha sido completamente inofensiva y ha desterrado todos mis miedos. Mi único problema fue con la migración, algo que resolví prescindiendo de la herramienta de migración (increíblemente lenta) y creando las cuentas pop3 en Akonadi de cero, y una de maildir que apuntara a mi archivo actual. La primera actualización del caché de Akonadi tardó un montón, pero una vez completada me he olvidado de todo esto. Akonadi es muy sólido, y no he tenido problemas de fiabilidad ningún tipo.

El único problema es la lentitud. Abrir una carpeta no cacheada es demasiado lento, muchas operaciones que consistan en copiar, mover o cambiar el estatus de los mensajes son lentas. A veces, el simple hecho de leer un mensaje muestra un "espere, por favor..." debido a que por alguna razón hay otras operaciones simultaneas (¿las copias de seguridad automáticas que he configurado en Akonadi?) que bloquean a las demás. Creyendo que el problema era que mysql era demasiado pesado cambié el "backend" de Akonadi a sqlite, pensando que la ligereza de sqlite era ideal para Akonadi, pero la realidad es que su rendimiento es peor (mucho peor: mysql existe por algo). No sé hasta que punto influirá el hecho de que utilizo btrfs: el fsync() en btrfs es aun algo lento, y la fragmentación de las bases de datos debido al COW es muy notoria.

Por otra parte, la operación normal de leer correos sin hacer cosas raras es instantánea. Sólo he notado lentitud y problemas al hacer cosas atípicas (copiar muchos correos de una carpeta a otra), y mi archivo de correo maildir está seguro. Está claro que Akonadi y Kmail2 son muy nuevos y tienen que mejorar, pero son perfectamente usables. Y no olvidemos que Akonadi no sólo sirve para correos, también sirve para notas, calendarios, mensajes de IM, etc.

PD: El cambio de apariencia del blog era necesario para poder usar las nuevas plantillas de blogger.

18 comentarios:

  1. Je... Yo no usaría el Akonadi para nada. No vaya a ser, que, con las bases de datos implementadas se me estruje el sistema por algo que no me va a dar resultados.

    No lo digo por mal, que sé de lo que hace el Akonadi. No lo tengo activado. A no ser que quiera hacer pruebas. Pero como no uso KMail, pues no lo uso.

    Sólo una cosa, que lo que MENOS me gusta, es el kded4, que es el único proceso, que si no lo mato, consume memoria a raudales cuando están días y días en funcionamiento el sistema. No me gusta ese servicio. Ni mucho menos, de lo que hace, ni bajo supervisión. Sé que no me convence, pero queriéndolo, podría quererlo, pero me da un repelús que p'a qué.

    Slds...

    ResponderEliminar
  2. Ah, olvidé decir, que NO uso KMail, sino, Thunderbird.

    ResponderEliminar
  3. Como dices, creo que Akonadi tiene que mejorar, sobre todo en velocidad, pero, para mi, también es intolerable tener una instancia de MySQL en un ordenador de escritorio.

    Y es que yo he estado con BeOS desde hace mucho y me resulta muy curioso que no se aprovechen las características de los sistemas de archivos actuales, como BtrFS, que tiene atributos extendidos.

    Porque en BeOS, con su sistema de archivos BFS, los correos electrónicos eran simples archivos de texto guardados en carpetas. Cada atributo del mismo (asunto, origen, destino…) era guardado en un atributo en propio sistema de archivos y, gracias a las 'queries' también propias del sistema de archivos, podías hacer búsquedas de cualquier tipo. Vamos, BFS era (y es, ahora en Haiku) —casi— como una base de datos.

    Y lo que me pregunto hoy es ¿por qué en sistemas operativos modernos no se hace uso extensivo de los atributos extendidos de los sistemas de archivos y siempre se requiere tener un software externo, como una base de datos, para todas estas cosas de campos "nombre:valor" y consultas?

    ResponderEliminar
  4. Diego: Lo que BFS hace no se puede implementar con los atributos extendidos de los sistemas de archivos habituales, es más complejo.

    ResponderEliminar
  5. Exacto. ES demasiado complejo hoy en día. El BFS no es para eso de momento y, tardará un tiempo largo o muy largo (quizá nunca) pueda soportar incluyendo las bases de datos de gran tamaño.

    Slds...

    ResponderEliminar
  6. No entiendo a qué os referís cuando decís que es "muy complejo".

    ResponderEliminar
  7. Nos referimos a la estructura del sistema de ficheros BFS, que a la postre, no gana con lo que hacen actualmente EXT3/EXT4 (el EXT4 gana por goleada en algunas implementaciones, no en bases de datos sqlite).
    Hay mucho material e información al respecto.

    ResponderEliminar
  8. Diego: Quiero decir que lo que hace BEOS no se puede hacer en Linux a día de hoy.

    ResponderEliminar
  9. Eso depende Diego. No es una cosa igual lo que hace BEOS que lo que haga Linux. Son dos cosas distintas. ;-)

    Slds...

    ResponderEliminar
  10. De acuerdo. Puede que todavía no haya queries implementadas en ningún sistema de archivos soportado en Linux, pero ¿qué pasa con los atributos extendidos? Esos sí que están implementados y no se usan en absoluto.

    ResponderEliminar
  11. En sistema de ficheros distintos al BFS, como JFX/XFS/EXT4/EXT3.

    Slds...

    ResponderEliminar
  12. Diego: los atributos extendidos se usan habitualmente (SELinux, por ejemplo), pero no se pueden usar para hacer búsquedas en base al contenido del atributo

    ResponderEliminar
  13. Desde siempre el SELinux no lo uso. Ni mucho menos. ¿Para qué?

    Si es para causas de fuerza mayor, o que se requiera guardado de bases de datos en jaulas, entonces, me callo.

    Slds...

    ResponderEliminar
  14. Agustín Dall'Alba10:32 p. m.

    Si puedo hacer una recomendación en cuanto al diseño, el ancho mínimo de 1100px es poco conveniente en pantallas "chicas". Yo lo bajaría a 900~1000px así todo el contenido es visible a 640x480 (900~1000px - 300px del sidebar - 80px de padding - 60px de margen - 16px de scrollbar = 444~544px, y se puede ver toda la página sin scroll horizontal a 1024x768.
    No se muy bien como funciona Blogger, pero en el tag style id='template-skin-1' (tercero en el HTML de la pagina), en la segunda linea está el min-width de todo el body de la pagina, y justo abajo en la quinta linea esta el min-width del contenido.

    Cabe mencionar que no soy ningún experto, diseñador, ni nada de eso, sólo un lector que prefiere usar una ventana chica para navegar en lugar de tener el navegador maximizado. Un saludo :)

    ResponderEliminar
  15. Agustín: Dado que la tuya es la única sugerencia que he recibido, he optado por bajarlo a 1000px (además con el editor de plantillas de blogger sólo es cuestión de mover una barra)

    ResponderEliminar
  16. Agustín Dall'Alba12:13 a. m.

    Oh, es cierto! Gracias! :D

    ResponderEliminar
  17. Justo te hiba a preguntar si se podia usar splite...
    deverias probarla en otra particion y comenta, yo lo haria pero ahora estoy solo con una tablet con 1 ghz, monocore y 512 ram
    Forever alone para estos emprendimientos jaja.
    Suerte y excelente post, se nota que sos o procuras ser objetivo

    ResponderEliminar
  18. Creo que akonadi, significa: querés usar Linux en el desktop? OK, nos pondremos en el medio y trataremos de joderte la vida para que no lo hagas. Eso

    ResponderEliminar