-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 El 2009-01-30 a las 21:25 +0100, Camaleón escribió:
El 30/01/09, Carlos E. R. escribió:
Huy, tengo al menos un amigo por ahí que me manda presentaciones, otro vídeos, otro álbumes de fotos de su viaje por Disneyland o Tokío... sin contar los spam.
Algún correo que recibes de vez de cuando con fotos... eso no cuenta :-P
El culpable debe haber perdido mi dirección y yo me he hecho el sueco O:-) Quedan otros que me envían vídeos y presentaciones.
Los spam no llevan adjuntos, suelen ser de poco tamaño y de formato texto.
¡Que te crees tu eso! Mirando a boleo he visto varios de 300 kilobytes. Y si se trata de correos "pesados" con archivos anexos de esos gordos que dices, el Alpine tiene una característica que no tienen otros: puedo borrar los anexos. Es decir, lo grabo aparte (lo cual lo tengo que hacer de todas formas para abrirlo), y luego lo borro. El correo se guarda, pero sin el anexo. No lo uso a menudo, pero puedo hacerlo.
La teoría es que maildir es más robusto, pero la realidad es que en diez años no he tenido un solo problema. Además, es que lo puedes reconstruir con un editor de texto.
Ya veré cómo funciona cuando "migre"...
A mi no me ha dado problemas, si bien es verdad que mi programa normal es el alpine, que es bastante robusto, aparte del procmail.
Pues diselo a todos los gestores de bases de datos, están basados todos en archivos únicos. El sistema de archivos múltiples no se usa por poco eficaz.
De hecho, uno de los fuertes del sistema de archivos reiser es que permite pensar en bases de datos con un archivo por registro, por primera vez, siendo eficaz.
¿A qué te refieres exactamente con que los gestores de bdd usan "archivos únicos"? >:-?
Pues eso, todos los motores de bases de datos, desde el dbase hasta el mysql funcionan con archivos únicos. A veces dividen, y tienen uno para los datos y otro u otros para los índices. Yo una vez me estuve programando mi propio motor de base de datos, y funcionaba con archivo único; incluso el índice lo podías regenerar a partir del principal. Las ordenaciones se hacen cambiando el índice o generando otro. Pueden haber variaciones, y meter cada tabla en un archivo separado, que es lo que hace el mysql. Pero lo que no hace ninguno es meter cada registro (equivale a cada correo) en un archivo separado. Otra variación que emplean algunos motores es grabar directamente en una partición "raw", sin formato. Es decir, graba directamente en los clusters del disco, y usa su propio sistema de indexación para saber donde está cada registro y cada campo. Yo reconozco que maildir es un formato muy útil para guardar los correos en los servidores, sobre todo los imap, porque permiten añadir y borrar correos concurrentemente. Pero en cambio, para un cliente, es menos útil.
¿Y porqué va a estar corrupto? No tengo ninguno corrupto.
No tiene por qué estarlo, pero no es más que una cuestión de probabilidades: los archivos únicos sólo se escriben una vez al disco, en cambio, en un archivo mbox estás ejecutando continuamente operaciones de lectura y escritura de datos, es más fácil que falle, que se graben mal los datos o que se corrompa el archivo.
Las operaciones de lectura y escritura por programas distintos se bloquean, sólo se le permite a uno la escritura. A mi, con la combinación de procmail y Alpine me ha funcionado perfectamente durante años, con un volumen de correo razonablemente grande. En cambio, procmail + T/K no van tan bien. Al menos el T. no se entera de cuando entran correos. Pero no es el caso cuando usas el propio programa para recoger los correos
En absoluto.
Si tienes un giga de correo real, transmitirlo como fichero único es transmitir un sólo giga, mientras que como ficheros separados, tengo que transmitir varios miles de ficheros, lo cual, con cualquier protocolo supone crear fichero, añadirle contenido, cerrarlo... y eso es siempre una operación lenta con cualquier sistema de ficheros. Transmitir uno solo es abrir uno solo, asignar un sólo inodo, y hala, a enviar bytes sin pausa. Que va, es mucho más eficaz transmitir archivos únicos.
¿Operación lenta...? ¿Con el hardware actual? Hum... tampoco lo he "medido".
Los mismos bytes en mil ficheros es más lento que en uno. Eso es un hecho, por la sobrecarga de tener que crear los archivos.
La ventaja es que tienes la opción de no tener que copiar 2 gigas, sólo los correos nuevos que han entrado porque maildir permite hacer copias diferenciales. Tiene sus ventajas si estás usando herramientas de sincronización.
Ah, vale, pero eso no lo explicaste antes. Sí, si estás replicando correos hay una diferencia. Pero se pueden hacer algoritmos de sincronización con mbox y sólo copiar las partes interesantes, marcando como borrados los desaparecidos, sin borrarlos realmente hasta otro momento.
Lo único que no es eficaz en mbox es borrar correos sueltos o reordenarlos (físicamente). Todas las demás operaciones son más rápidas.
No te olvides de los bloqueos...
Sí, vale, tienes que bloquear y esperar. Pero muy rara vez noto un bloqueo.
Dices que tienes 31.577; pues bien, de media en cada archivo pierdes 4 kilobytes en ext3 (con un tamaño de cluster de 8K). Cuenta. Estás desperdiciando... 123 megas de espacio en disco.
¿Con Reiser? >:-)
Con reiser no, es la excepción.
Si lo es. La reindexación completa en kmail es muy lenta. Es un hecho conocido.
Pero no estás haciendo una comparativa justa porque no abres nunca el kmail, no trabajas con él. Si lo usaras a diario, desde kde, notarías la diferencia.
Lo que pasa es que la indexación es paulatina y no se nota tan descaradamente. Pero dado que la recogida de correo nunca se la dejo hacer al programa cliente, sino que la tengo centralizada en fetchmail, el kmail se daría de tortas.
Y si accedieras a directorios maildir desde un cliente de correo ncurses, también.
Lo he hecho, y no funciona muy bien.
Para ser justos, no he probado el formato mbox desde kmail, sólo lo tengo en el Thundercito, quizá el culpable de la lentitud sea el cliente no el formato.
Es posible.
Aún así, me quedo (de momento, vaya, luego tendré que cambiar) con maildir.
La ventaja de mbox es simplemente que todos los programas lo entienden, es más compatible. - -- Saludos Carlos E.R. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (GNU/Linux) iEYEARECAAYFAkmDlnYACgkQtTMYHG2NR9UmLQCdGc6MeIR4UXJW4/ZqxIkqs1GO LcsAn2lwvWS3cCA9qqAADtgEHh+aqqei =Z/op -----END PGP SIGNATURE-----