-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Content-ID:
On Sat, Feb 07, 2009 at 03:14:14PM +0100, Carlos E. R. wrote:
No lo notarás hasta que yo haga el cambio a utf con éste.
Vamos a ver pues... aunque no me extrañaría que fuera cosa del imap del gmail, no del cliente.
Hacen cambios internos continuos.
Sí, pero este problema de los "asuntos crecientes" no es nuevo.
Puede ser. Fíjate como este correo está bien.
El mutt es un buen programa, no te hará esas jugarretas.
Buscando información de cómo ponerlo en marcha, encontré una comparativa de clientes en cuanto a uso de memoria, y el Thundercito se lleva la palma al más chupa-ram...
No me extraña, es de la familia del mozilla, que es un tragón que no veas. Es el proceso que más ram traga: PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND 7657 cer 20 0 380m 131m 16m S 5.0 13.0 233:06.18 firefox porque cuando cierras un tab o ventana no libera la memoria, deja agujeros por en medio.
*** Power Up Your E-Mail with Mutt http://www.linuxjournal.com/article/10115
The first obvious advantage of Mutt is its small memory footprint. Below, I show the memory usage of KMail, Thunderbird, Evolution and Mutt on my system:
VIRT RES SHR %MEM COMMAND 156m 37m 19m 3.7 thunderbird-bin 161m 33m 19m 3.3 evolution 96352 23m 17m 2.3 kmail 14548 6092 3180 0.6 mutt
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND 5741 cer 20 0 56672 28m 3036 S 0.0 2.8 27:14.29 alpine Con una carpeta de 8500 correos abierta. Lo he usado en mi otro PC que sólo tiene 32 megas de ram y va rápido.
A ver, busco "maildir" en sus listas... no, no soportan maildir y es intencional:
(...)
Y tan intencional, igual que hacen los de Mozilla con Thundercito, que no soporta maildir porque no quieren :-P.
Pos eso. Yo no quiero usar un formato que sólo sea usado por algunos, me puede dejar pillado.
(Mark es uno de los desarrolladores principales de Pine/Alpine, y Asheesh creo que debe ser alguien en Debian, posiblemente el empaquetador de Alpine)
Lo que si soporta son carpetas "mix", que es otro formato de carpetas de correo bastante optimizado. Me acabo de enterar, por cierto.
Entiendo la postura del desarrollador, pero no la comparto, por tanto, la decisión de usar Mutt también es "intencional" >:-)
Ten en cuenta que todos los correos que tengo en KMail son maildir. El Mutt me puede salvar si en algún momento tengo que acceder a los correos sin entorno gráfico.
Pos los conviertes a mbox >:-)
Tira por tierra lo de que mail dir soporte acceso concurrente, es falso:
Que no le gusta ni un pelo.
No es que no le guste, es que la idea que se dice de que maildir soporta la concurrencia mejor que mbox, no es cierta. Lo que pasa es que si da la casualidad de que un programa accede a un correo y otro programa accede a otro correo distinto, pues claro, no pasa nada. Pero si da la casualidad (rara) de que los dos acceden al mismo correo, la lían. Es el ejemplo que da Mark, que un cliente puede borrar un correo mientras otro cliente está leyendo ese mismo correo. Lo cual, por otro lado, es por culpa de que que Linux la manera de bloquear ficheros está (estaba) mal definida y dependía de cada programador de aplicaciones.
Pero me da que no le gusta porque no está normalizado, y no querrá meter la pata desarrollando sobre "supuestos" :-)
Lo dice claramente, da tres puntos que necesitan cumplirse y que no es capaz de dar soporte a los tres simultáneamente: I do not know how to make a maildir driver that works well, which I define as: . complete compliance with IMAP's specifications . complete compliance with DSB's specifications . satisfactory performance I know how to do two of these, but not all three simultaneously.
Vamos, que lo de Maildir... este hombre está totalmente en contra, y sabe lo que dice. Claro, que puedes decir que es como Stallman :-p
El concepto del maildir es bueno. La implementación les cuesta porque no hay un estándar común.
Me parece mucho mejor el concepto de 'mix', cuyo punto de partida es tener ficheros múltiples (como maildir) pero evitando tener ficheros muy pequeños, incluso por miles (lo contrario que maildir), lo cual enlentece el acceso. Está diseñado como una base de datos especial para correo. Pero 'mix' no existe. Maildir sólo puede funcionar bien en reiserfs.
Ah, ya, quieres aplicar filtros que recojan el correo de la carpeta "inbox" y los muevan a otras carpetas remotas via imap, ¿no? Revisa la ayuda de gmail sobre el acceso imap y los filtros, hablan de esto precisamente. Es mejor, creo, dejar que gmail (servidor) haga ese filtrado y movimiento internamente.
Sí, pero si le digo que los archive nada más llegar, no me avisa de que hay nuevos mensajes en la bandeja de entrada y tengo que descargar los 30.000 hilos de la carpeta que contiene los mensajes de la lista.
Ah... es verdad.
No es viable. Tendría que poder ejecutar la orden de archivado manualmente, que es lo que estoy buscando.
Ya.
Leete la ayuda de gmail antes, está previsto.
La he leído, pero no es cosa del gmail, sino del cliente.
No sé cómo mover los mensajes en el Mutt, estando en remoto, es decir, mover los correos (hilos) a un directorio del imap de gmail, no a uno local.
No se si Alpine lo hace, pero lo que si es seguro es que hacen la correcta implementación del soporte imap, porque este Mark es quien escribió la especificación imap, es invento suyo. - -- Saludos Carlos E.R. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (GNU/Linux) iEYEARECAAYFAkmNvlgACgkQtTMYHG2NR9UyCgCfZX8zIPzlzuJd5TDpSz9Vf0ob xrEAn1YdSBW+cVeDUrh3Emygxf+cft4c =DezH -----END PGP SIGNATURE-----