El Wed, 24 Feb 2010 22:24:34 +0100, Carlos E. R. escribió:
El 2010-02-24 a las 14:48 -0000, Camaleón escribió:
La carpeta de la bandeja de entrada, por ejemplo, no puede/debe tener el mismo comportamiento que el resto de carpetas que crea el usuario. Y no lo puede/debe tener porque es una carpeta "especial", no de almacenmaiento: todo el correo pasa por ahí, salvo que se haya configurado una regla que derive el mensaje a otra carpeta. Con lo cual, con este maravilloso sistema del mbox, la bandeja de entrada se convierte en un recolector de basura -> correo que pasa, correo que se almacena -> carpeta que necesita compactarse con asiduidad.
La carpeta de entrada no se pone local, es remota, por lo que no hay que hacer nada. Puede tener copia local sincronizada, pero eso es distinto.
Mi inbox es local. De hecho todos las carpetas son locales, salvo las de las cuentas imap.
O bien, puedes ponerte tu propio servidor imap local y guardar todo el correo allí, así puede estar en maildir si quieres.
¿Y? El Thunderc... el Palomino lo pasa a mbox (en local) → chapuza >:-)
¿Lento? ¿Lento...? ¿Lento borrar en archivo de 3 KiB con un micro de 4 núcleos y 8 GiB de ram? Lento es ir de Madrid a Valencia en burro, qué gaitas >:-)
Cuando el mbox tiene sólo 3 kb, sí, es rápido.
Mi mbox _tenía_ 3 KiB. El Palomino metió la gamba (no configuró las opciones adecuadas para evitar la catástrofe) y la aumentó a 650 MiB. Y sin avisar ni "ná".
Pero si tiene cientos de correos y unos cuantos por borrar, sí es lento.
Pero eso tendrá que decidirlo el usuario, no el Palomino. Sólo el usuario puede saber si sus carpetas tienen (o van a tener) 1 o 10.000 correos. Y no se puede tratar de igual forma una carpeta con 1 que con 10.000 archivos.
Ten en cuenta que es un fichero de texto plano, y borrar correos supone en realidad copiar el fichero antiguo en uno nuevo, completo. Es una operación costosa que es preferible hacerla bajo petición o cuando sea necesario.
No, si la teoría ya la he leído, además de que la explica muy bien el Palomino en su página de "excusa", quiero decir, en la FAQ.
La idea de hacer operaciones costosas porque los ordenadores sean más rápidos es lo que hacen los "malos desarrolladores" que han conseguido que el software sea cada vez más lento, porque piensan que todo el mundo tiene procesadores velocísimos, a los que sobrecargan de trabajo innecesario. Se tiene unos ordenadores 10 veces más rápidos que en realidad trabajan sólo 5 veces más rápidos porque no han diseñado bien el software.
No, la idea es hacer las *operaciones lógicas* que permitan obtener el mejor ratio de rendimiento posible, y no veo ninguna lógica en almacenar 650 MiB "ocultos" en la bandeja de entrada y en forzar al usuario a realizar un mantenimiento continuado en el cliente de correo. Ni el "Outlooks 2000" hace eso, oiga. A los 4 GiB, ya no se vuelve a abrir y santas pascuas O:-P
El problema es que ellos _no saben_ cuánto ocupa la bandeja de entrada de los usuarios, ni qué equipo tienen, luego si no lo saben (porque no lo pueden saber) podrían:
1/ Permitir que el usuario lo configure a su gusto.
2/ Incluir alguna rutina de detección del tamaño del directorio que active la necesidad de compactación *sólo* cuando el tamaño de la carpeta sea un factor determinante para ganar velocidad en escritura.
Y de hecho lo tienen. Se dispara por tamaño, estimar la velocidad no se puede estimar a priori.
Y un cuerno. En primer lugar *se almacenan* los datos de manera indiscriminada (sin límite, hasta que hubiera dejado la carpeta inservible, supongo...). Ese es el primer error. En segundo lugar, no permiten configurar ese comportamiento, con lo cual tienes que compactar continuamente la bandeja de entrada, en cualquier caso, para evitar un desastre.
Después de haber probado las mieles del maildir (Kmail) estas cosas me ponen los pelos de punta. Y parece que no están muy interesados en añadir el soporte de maildir, me parece a mí...
Iría fatal en los thundercitos bajo windows.
¿Por...? ¿Acaso tienes datos del rendimiento del NTFS con archivos pequeños? :-? Yo creo que no lo quieren hacer porque el Palomino estará diseñado de forma totalmente dependiente respecto a ese formato. Saludos, -- Camaleón -- Para dar de baja la suscripción, mande un mensaje a: opensuse-es+unsubscribe@opensuse.org Para obtener el resto de direcciones-comando, mande un mensaje a: opensuse-es+help@opensuse.org