[opensuse-es] Mozilla Firefox (rama 2.x) ¿EOL?
Hola, ¿Sabéis si la rama de Firefox 2.x ya no va a seguir teniendo parches de seguridad por parte de Mozilla y, obviamente, opensuse? :-? Tengo actualmente la 2.0.0.19 ¿se podría instalar la 3.0 en paralelo, sin eliminar la versión anterior? 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
¿Sabéis si la rama de Firefox 2.x ya no va a seguir teniendo parches de seguridad por parte de Mozilla y, obviamente, opensuse? :-?
Tengo actualmente la 2.0.0.19 ¿se podría instalar la 3.0 en paralelo, sin eliminar la versión anterior?
Para no tener problemas podrias descargar el codigo fuente de firefox 3.0 y compilarlo y asi tendrias las dos versiones Referente a si habra actualizaciones de seguridad no tengo ni idea Salud -- 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
El 4/02/09, Xavier Barnada escribió:
Para no tener problemas podrias descargar el codigo fuente de firefox 3.0 y compilarlo y asi tendrias las dos versiones
Es una opción... pero ¿hay que compilarlo? ¿no tiene algún auto-instalador sencillito, como el Google Earth? :-} <modo cobarde on> La pega es que me quedaría sin las actualizaciones a través de you, sí, eso, eso... mejor me espero a actualizar suse a la 10.2... total, si uso konqui casi siempre O:-P 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
Es una opción... pero ¿hay que compilarlo? ¿no tiene algún auto-instalador sencillito, como el Google Earth? :-}
Creo que si lo descargas de aqui: http://www.mozilla-europe.org/es/firefox/ es la version de 32 bits y ya esta compilada , lista para usar si no me equivoco -- 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
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 El 2009-02-04 a las 22:19 +0100, Camaleón escribió:
El 4/02/09, Xavier Barnada escribió:
Para no tener problemas podrias descargar el codigo fuente de firefox 3.0 y compilarlo y asi tendrias las dos versiones
Es una opción... pero ¿hay que compilarlo? ¿no tiene algún auto-instalador sencillito, como el Google Earth? :-}
No hace falta, te instalas la versión "estandard" de mozilla, sin los ajustes de novell. Tienes las actualizaciones que hagan ellos. Respecto a parches de seguridad de la serie 2, lo dudo: si te fijas, en la SLES suelen cambiar la versión del mozilla cuando llega a cierto punto, porque no debe ser posible mantener la misma versión durante 5 años. Incluso lo hacen con la open, nos cambian la versión, contrariamente a la política de SuSE.
<modo cobarde on>
La pega es que me quedaría sin las actualizaciones a través de you, sí, eso, eso... mejor me espero a actualizar suse a la 10.2... total, si uso konqui casi siempre O:-P
¿A la 10.2? ¿Que es lo que estás usando en esa máquina entonces, la 5? :-P - -- Saludos Carlos E.R. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (GNU/Linux) iEYEARECAAYFAkmKKmoACgkQtTMYHG2NR9WZLACfUo0M4IreRQXyD1MkkY6ULN9h uLAAoI1k2dATdE4ysCPaoS08dvtahnvL =cOzw -----END PGP SIGNATURE-----
El 5/02/09, Carlos E. R. escribió:
El 2009-02-04 a las 22:19 +0100, Camaleón escribió:
Es una opción... pero ¿hay que compilarlo? ¿no tiene algún auto-instalador sencillito, como el Google Earth? :-}
No hace falta, te instalas la versión "estandard" de mozilla, sin los ajustes de novell. Tienes las actualizaciones que hagan ellos.
Si es como comentaba Xavier, que ya está compilada, la probaré a instalar este fin de semana, en un equipo secundario O:-)
Respecto a parches de seguridad de la serie 2, lo dudo: si te fijas, en la SLES suelen cambiar la versión del mozilla cuando llega a cierto punto, porque no debe ser posible mantener la misma versión durante 5 años. Incluso lo hacen con la open, nos cambian la versión, contrariamente a la política de SuSE.
Lo de los parches, pues es que me avisó hace poco el firefox de un windows, que pasara a la 3.0 pero no le hice caso... pero ayer me pareció leer que ya no tenía parches de seguridad, la rama de la 2.x y aunque el firefox no lo uso casi, prefiero que esté al día.
<modo cobarde on>
La pega es que me quedaría sin las actualizaciones a través de you, sí, eso, eso... mejor me espero a actualizar suse a la 10.2... total, si uso konqui casi siempre O:-P
¿A la 10.2? ¿Que es lo que estás usando en esa máquina entonces, la 5? :-P
¡Grrr! :-) Quería decir la 11.2. P.S. El correo de antes ha salido disparado, en blanco, se ve que tenía prisa. P.S. (2) Si genero un bucle en el asunto no es mi culpa (no puedo cambiar el asunto porque me deshilo) :-P 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
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Content-ID:
No hace falta, te instalas la versión "estandard" de mozilla, sin los ajustes de novell. Tienes las actualizaciones que hagan ellos.
Si es como comentaba Xavier, que ya está compilada, la probaré a instalar este fin de semana, en un equipo secundario O:-)
Si yo lo he puesto en mi "Me" virtualizado, tú puedes :-)
pareció leer que ya no tenía parches de seguridad, la rama de la 2.x y aunque el firefox no lo uso casi, prefiero que esté al día.
Basta que lo uses un dia y pases por un sitio con la azada adecuada para el agujero.
¿A la 10.2? ¿Que es lo que estás usando en esa máquina entonces, la 5? :-P
¡Grrr! :-)
Quería decir la 11.2.
Fale :-)
P.S. El correo de antes ha salido disparado, en blanco, se ve que tenía prisa. P.S. (2) Si genero un bucle en el asunto no es mi culpa (no puedo cambiar el asunto porque me deshilo) :-P
El problema viene causado por esto: Subject: [opensuse-es] =?ISO-8859-1?B?UmU6IFtvcGVuc3VzZS1lc10gUmU6IFtvcGVuc3VzZS1lc10gTW96aWxsYSBGaXJlZm94IA==?= =?ISO-8859-1?B?KHJhbWEgMi54KSC/RU9MPw==?= así es como sale tu "subject". Y así es como lo mandé yo: Subject: =?UTF-8?Q?Re=3A_=5Bopensuse-es=5D_Re=3A_=5Bopensuse-es=5D_Mozilla_Firefox_=28rama_2=2Ex=29_=C2=BFEOL=3F?= Tu lo mandas en latin1 con mime, yo en utf-8. Lo acabo de reescribir desde cero quitando el "¿", que es el que causa el problema. - -- Saludos Carlos E.R. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (GNU/Linux) iEYEARECAAYFAkmKyhwACgkQtTMYHG2NR9WJ+gCgj/0jFR83M+jTnss1u0DQdPj7 LuwAniEk5QtkZDnbeEydg29iHVufn8/F =Nv/k -----END PGP SIGNATURE-----
El 5/02/09, Carlos E. R. escribió:
El 2009-02-05 a las 08:58 +0100, Camaleón escribió:
Si es como comentaba Xavier, que ya está compilada, la probaré a instalar este fin de semana, en un equipo secundario O:-)
Si yo lo he puesto en mi "Me" virtualizado, tú puedes :-)
Je... Bueno, pues al final lo he actualizado desde los repos de /mozilla y a freír monas. No me sirve de nada mantener la versión antigua, así que, fuera... (probando la 3.0.6...) Hum... pues carga muy rápido :-O
pareció leer que ya no tenía parches de seguridad, la rama de la 2.x y aunque el firefox no lo uso casi, prefiero que esté al día.
Basta que lo uses un dia y pases por un sitio con la azada adecuada para el agujero.
Sí... con el navegador no me arriesgo a dejarlo sin actualizar, aunque este lo use poco.
P.S. (2) Si genero un bucle en el asunto no es mi culpa (no puedo cambiar el asunto porque me deshilo) :-P
El problema viene causado por esto:
Subject: [opensuse-es] =?ISO-8859-1?B?UmU6IFtvcGVuc3VzZS1lc10gUmU6IFtvcGVuc3VzZS1lc10gTW96aWxsYSBGaXJlZm94IA==?= =?ISO-8859-1?B?KHJhbWEgMi54KSC/RU9MPw==?=
así es como sale tu "subject". Y así es como lo mandé yo:
Subject: =?UTF-8?Q?Re=3A_=5Bopensuse-es=5D_Re=3A_=5Bopensuse-es=5D_Mozilla_Firefox_=28rama_2=2Ex=29_=C2=BFEOL=3F?=
Tu lo mandas en latin1 con mime, yo en utf-8. Lo acabo de reescribir desde cero quitando el "¿", que es el que causa el problema.
Puede ser... pero no puedo enviar con utf-8 porque entonces me muerde el bug de la lista+webmail de gmail. Qué lata... pero que conste en acta que ayer instalé Mutt para enviar los correos de esta lista con él, pero jupe, tenía dos problemas: - El paquete de suse viene sin soporte smtp (no podía usar el servidor de gmail) - Se descargaba los 30 y pico mil correos de gmail, no sé si podría haberlo configurado para que no lo hiciera, pero necesitaba que vigilara los correos que tengo en esta etiqueta porque uso filtros, y los correos entran directamente a la etiqueta que tengo para cada lista. Y con el kmail... pues se quedó frito al intentar cargar esos 30 y pico mil correos :-/ Así que de momento, lo dejo para tiempos mejores... 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
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Content-ID:
Subject: Re: [opensuse-es] Mozilla Firefox (rama 2.x) EOL?
Perfecto >;-)
El 5/02/09, Carlos E. R. escribió:
El problema viene causado por esto:
Subject: [opensuse-es] =?ISO-8859-1?B?UmU6IFtvcGVuc3VzZS1lc10gUmU6IFtvcGVuc3VzZS1lc10gTW96aWxsYSBGaXJlZm94IA==?= =?ISO-8859-1?B?KHJhbWEgMi54KSC/RU9MPw==?=
así es como sale tu "subject". Y así es como lo mandé yo:
Subject: =?UTF-8?Q?Re=3A_=5Bopensuse-es=5D_Re=3A_=5Bopensuse-es=5D_Mozilla_Firefox_=28rama_2=2Ex=29_=C2=BFEOL=3F?=
Tu lo mandas en latin1 con mime, yo en utf-8. Lo acabo de reescribir desde cero quitando el "¿", que es el que causa el problema.
Puede ser... pero no puedo enviar con utf-8 porque entonces me muerde el bug de la lista+webmail de gmail. Qué lata... pero que conste en acta que ayer instalé Mutt para enviar los correos de esta lista con él, pero jupe, tenía dos problemas:
No digo que envies con utf, digo que cambia. Además, se trata de las cabeceras, no del contenido. Yo tengo que enviar con utf-8, porque si no se hace un lio, sobre todo al firmar, dado (creo) que la consola es utf Y tu mira que atreverte con mutt... dicen que es como el pine con esteroides. A mi se me atraganta.
- El paquete de suse viene sin soporte smtp (no podía usar el servidor de gmail)
Ah, pues le pones a que envíe a través del postfix. Yo te cuento como se hace.
- Se descargaba los 30 y pico mil correos de gmail, no sé si podría haberlo configurado para que no lo hiciera, pero necesitaba que vigilara los correos que tengo en esta etiqueta porque uso filtros, y los correos entran directamente a la etiqueta que tengo para cada lista.
Por lo menos se tiene que descargar las cabeceras, sí.
Y con el kmail... pues se quedó frito al intentar cargar esos 30 y pico mil correos :-/
Cierto, lo probé.
Así que de momento, lo dejo para tiempos mejores...
:-) - -- Saludos Carlos E.R. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (GNU/Linux) iEYEARECAAYFAkmMgmQACgkQtTMYHG2NR9Xo6ACdEXUyKaCyICOwSA3Q4TflQDSE h4cAnReN+QkLZKn7/sawdudNPJb7y5h7 =Tskd -----END PGP SIGNATURE-----
On Fri, Feb 06, 2009 at 07:33:00PM +0100, Carlos E. R. wrote:
Perfecto >;-)
Si ya decía yo que era por vuestros formatos... "dita" sea >:-)
No digo que envies con utf, digo que cambia. Además, se trata de las cabeceras, no del contenido.
Pues a ver cómo sale éste :-P
Yo tengo que enviar con utf-8, porque si no se hace un lio, sobre todo al firmar, dado (creo) que la consola es utf
Y tu mira que atreverte con mutt... dicen que es como el pine con esteroides. A mi se me atraganta.
El más completo entre los clientes de texto, decía en la wiki. Pues nada, a ver cómo resulta.
Ah, pues le pones a que envíe a través del postfix. Yo te cuento como se hace.
Sí, eso he hecho al final...
Por lo menos se tiene que descargar las cabeceras, sí.
Voy a ver si me puedo hacer con el Mutt para configurar esto... así se primeras es un poco pesado trabajar con él. Creo que usa vim como editor y a este no hay quien le entienda.
Cierto, lo probé.
Son muchos correos, pero vaya, que se queda bloqueado y si lo paras, se cierra :-/ P.S. Si hay algún problema con este correo (formato, acentos, saltos de línea o lo que sea...), lo siento. Es el primer Mutt que configuro y estoy de pruebas con el Gmail :-) 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
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Content-ID:
On Fri, Feb 06, 2009 at 07:33:00PM +0100, Carlos E. R. wrote:
Perfecto >;-)
Si ya decía yo que era por vuestros formatos... "dita" sea >:-)
No, por el tuyo, por poner caracteres raros en el subject :-p De todas maneras, algo han cambiado los de gmail, porque esto pasa sólo recientemente.
No digo que envies con utf, digo que cambia. Además, se trata de las cabeceras, no del contenido.
Pues a ver cómo sale éste :-P
Igual, bien. Mientras no uses caracteres por encima del 127, bien.
Yo tengo que enviar con utf-8, porque si no se hace un lio, sobre todo al firmar, dado (creo) que la consola es utf
Y tu mira que atreverte con mutt... dicen que es como el pine con esteroides. A mi se me atraganta.
El más completo entre los clientes de texto, decía en la wiki. Pues nada, a ver cómo resulta.
Jupe, pues ya son ganas, meterse con el mutt. ¿Y porqué no el pine/alpine?
Voy a ver si me puedo hacer con el Mutt para configurar esto... así se primeras es un poco pesado trabajar con él. Creo que usa vim como editor y a este no hay quien le entienda.
Puede que se deje cambiar. En el pine se puede cambiar, al joe, por ejemplo. - -- Saludos Carlos E.R. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (GNU/Linux) iEYEARECAAYFAkmNbM0ACgkQtTMYHG2NR9V8DACfWPDX7CIOwyLKdmcRuYhDxPd6 woUAn2k30nvle1ZACLg5rt+hpAHaIAmR =woFT -----END PGP SIGNATURE-----
On Sat, Feb 07, 2009 at 12:13:07PM +0100, Carlos E. R. wrote:
No, por el tuyo, por poner caracteres raros en el subject :-p
Ya }:-) Pues a ver cómo sale éste: le he cambiado el asunto y además he añadido el "símbolo raro"
De todas maneras, algo han cambiado los de gmail, porque esto pasa sólo recientemente.
Hace poco han actualizado la interfaz, pero a parte de eso, no han comentado nada nuevo.
Igual, bien. Mientras no uses caracteres por encima del 127, bien.
El Mutt dirá...
Jupe, pues ya son ganas, meterse con el mutt. ¿Y porqué no el pine/alpine?
Tanto da, uno u otro. El Mutt es más completo y soporta maildir sin necesidad de parches :-P Pero el problema que tengo es un problema de concepto, con el Gmail (etiquetas y filtros). Lo único que me faltaría en el Mutt es poder "archivar" los correos que están en la bandeja de entrada para que se almacenen en su carpeta (label) de la lista, pero no doy con la forma de hacerlo. Los manuales que encuentro no dicen ni cómo, ni si es posible llevarlo a cabo y la mayoría de ellos utilizan una configuración local, es decir, que almacenan los correos en su equipo, no en el servidor. Y no voy a almacenar los 30.000 hilos con 80.000 mensajes en mi equipo, ya tengo bastantes con los del KMail >:-) Si no encuentro una forma de archivar los mensajes en remoto, tendré que volver al webmail :-(
Puede que se deje cambiar. En el pine se puede cambiar, al joe, por ejemplo.
Sí, eso claro que se puede cambiar. Puedes usar el editor que quieras. El vim no está mal, sólo es cuestión de memorizar unas cuantas "teclitas" :-) 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
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Content-ID:
On Sat, Feb 07, 2009 at 12:13:07PM +0100, Carlos E. R. wrote:
No, por el tuyo, por poner caracteres raros en el subject :-p
Ya }:-)
Pues a ver cómo sale éste: le he cambiado el asunto y además he añadido el "símbolo raro"
No lo notarás hasta que yo haga el cambio a utf con éste.
De todas maneras, algo han cambiado los de gmail, porque esto pasa sólo recientemente.
Hace poco han actualizado la interfaz, pero a parte de eso, no han comentado nada nuevo.
Hacen cambios internos continuos.
Igual, bien. Mientras no uses caracteres por encima del 127, bien.
El Mutt dirá...
El mutt es un buen programa, no te hará esas jugarretas.
Jupe, pues ya son ganas, meterse con el mutt. ¿Y porqué no el pine/alpine?
Tanto da, uno u otro. El Mutt es más completo y soporta maildir sin necesidad de parches :-P
Y el Alpine es mucho más completo que el Pine, es más moderno y ha tenido una temporada de desarrollo muy activo. No te puedo decir si soporta maildir porque no lo uso. Espera, tengo un directorio de pruebas con maildir, voy a mirar... [...] No, no lo lee. Tiene esto: cer@nimrodel:~> ls Mail/file/entrada_maildir/ cur new tmp Pero si gmail es imap, lo que usen ellos es transparente para ti. A ver, busco "maildir" en sus listas... no, no soportan maildir y es intencional: +++ Date: Fri Jan 5 23:43:47 2007 From: Mark Crispin Subject: [Alpine-alpha] Maildir support On Sat, 6 Jan 2007, Asheesh Laroia wrote:
Joey Hess filed a bug in the Debian package (*) about Alpine lacking support for the Maildir mail storage format. Apparently the pine source package that Debian ships comes with a patch for Maildir support.
Apparently, it comes with an unsupported third-party maildir driver for the c-client library.
Do you guys (washington.edu) plan to add Maildir support to Alpine?
I (the c-client library developer) do not have any such plans. Sadly, the maildir church claims that I don't do maildir out of some evil intent. Here are the facts: 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. I refuse to have my name associated with IMAP non-compliance. DSB would flame me to a crisp if I don't comply with his maildir specifications. That leaves lousy performance, and I would be flamed for "deliberately making it because [I] dislike maildir." It's a no-win situation for me.
From what I have seen of the third-party maildir drivers, they cut corners on all three. Some also have a negative impact on non-maildir usage.
I've fielded numerous Pine/c-client bug reports which turned out to be caused by these maildir drivers. When it turns out that the user does not use maildir, I recommend that s/he replace whatever distribution with an unmodified UW distribution (which of course has the effect of deleting any other third-party customizations). Similar corner-cutting is done by the IMAP servers that support maildir. For example, Courier actually implements something that it calls maildir++ and a heresy of IMAP that it calls SMAP instead of true maildir and IMAP. The difficulty is that IMAP and maildir have some seriously conflicting requirements. Neither one considered the other when it was designed, and it shows.
If not, has anyone in the community considered writing such a patch for Alpine?
I'm sure that the third-parties which provide maildir drivers for older versions of the c-client library have (or will soon have) updated versions that fit in the imap-2006 version that is used by Alpine. Please be assured that if I had a brainstorm and suddenly realized how to write a maildir driver that works well (as defined above), I would do so. I haven't had such a brainstorm, and apparently nobody else has either. - -- Mark -- http://panda.com/mrc Democracy is two wolves and a sheep deciding what to eat for lunch. Liberty is a well-armed sheep contesting the vote. ++- (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. Mark Crispin - Fri Jan 19 14:37:38 2007: +++ Alpine, and Pine before it, has supported multiple mailbox formats since inception. mix is simply the latest in a long history. mix was developed in 2006 to replace mbx, which was the 1995 solution for the performance problems caused by traditional UNIX (a.k.a. mbox) format. The email world today is very different one from 1995; and what was a good solution to mail in 1995 no longer is so good today. mbox, in turn, was a solution for the 1970s and 1980s. People still use it for a number of reasons, but it is quite obsolete today. ... Both mbx and mix support concurrent access. Furthermore, message and mailbox metadata is stored outside the message texts; no more Status:, X-Status:, X-UID:, etc. lines, and no more DO NOT DELETE message. The main user-visible addition in mix is that it allows "dual-use" mailboxes; that is, mailboxes which contain both messages and other mailboxes. Although this may seem bizarre to Pine users, it's something that users of Outlook, Thunderbird, etc. have been demanding for a long time. mix has a message index, which causes opens of large mailboxes to be MUCH faster than mbx (or mbox); strong data isolation (which reduces the change of mailbox corruption); less data re-writing than mbox; a cache of sort data (which makes first sorts of large mailboxes MUCH faster); and is extensible for recently-defined IMAP extensions which are not yet implemented but will become important. Unlike mbox and mbx, a mix mailbox is a directory. However, unlike mh, netnews, and maildir formats, mix does not require that each message be in a file by itself. Instead, it attempts to collect multiple messages in 1MB (this value is configurable in the code) data files, starting a new data file when the current one fills. This makes backups work much faster, avoids godzilla mailboxes creating godzilla files, and also avoids the excessive inode consumption that happens with mh/netnews/maildir type formats. The godzilla file problem needs some discussion. The current code limits the maximum mbox and mbx mailbox size to 2GB, at which point it craps out. mix does not have this limitation, although there is a limitation, inherited from IMAP, that an individual message can not be more than 4GB (hopefully this limit is good enough for a few more years to come...). There is one negative about both mbx and mix; neither format is supported over NFS and doing so is likely to cause corruption when concurrent access is attempted. NFS is not a suitable remote access mechanism for mailboxes; use IMAP instead. ++- Tira por tierra lo de que mail dir soporte acceso concurrente, es falso: +++
If I remember correctly, it was a big advantage of maildir and similar formats where each message is stored in a single file, that these kind of operations required only a minimum of I/O as in contrary to mbox and IIRC mbx formats, not the whole file had to be rewritten.
There is no synchronization in maildir. This is one of the problems with that format; a message just suddenly vanishes even while another session is still accessing it.
So, how does "mix" format deal with that situation?
mix has modification sequences and locking which permit multiple access (including shared expunge) without pulling the rug out from under other sessions that are still accessing those messages. There are well-defined synchronization points in IMAP in which a session learns about an expunge, and mix guarantees that data from an expunged message in another session remains accessable until those synchronization points.
In the doc file I read something of "burping", but I am not sure I understand fully what is meant by this term here. Are you moving up fragments of other already existing messages from the end of the file to a place that has just been "freed" somehow?
When a message is expunged and there is no concurrent access, the space occupied by that message can be reclaimed. If an expunged message is the last one in the data file, then the file is truncated. Otherwise, the remaining messages in the file are moved on top of the expunge messages and then the file is truncated.
What if the size of the no longer needed area does not fit exactly?
This is not relevant to how it works.
And what happens if the message to be expunged is more than 1 MB and thus split up into multiple files of 1 MB size (the value you told us which is configurable in code) with possibly other message in front of the first or behind the last part?
A message is not split into multiple files. A message larger than 1MB (or whatever is the configured size) is generally written into a file of its own. The exception is with multiple copy/append; all messages in the multiple copy/append are written to a single file regardless of size.
How does the performance compare to e.g. maildir regarding these kinds of operations?
I have no interest in comparing to maildir, since maildir does not correctly implement IMAP semantics. Since maildir can not do concurrent access properly, the advocates of that class of storage insist that IMAP be relaxed to allow what maildir does. Hence you have RFC 2180 sections 4.1.2, 4.1.3, and 4.1.4 as alternatives to 4.1.1 which is the only client friendly behavior. It is very easy to make things faster by saying "we don't need this" and "we don't need that" when "this" and "that" get in the way. For example, a filesystem can be sped up enormously if you don't care about it being robust and consistent in a power failure (the secret of fast Linux filesystems). Similarly, NFS would be severely slowed down if it had to fully implement UNIX filesystem semantics (ever notice that O_EXCL doesn't really work on NFS?). mix format generally does far fewer writes than mbx or mbox format. It never writes the index file unless a message is added or removed; flag changes take place in the status file. Concurrent expunge affects only the index and status files; only single-access expunge will rewrite data files. The data files are much smaller than the flat file formats, leading to much smaller rewrites. Of course, if a data file ends up with no messages, it is deleted rather than rewritten. In the specific case of a 2GB mailbox where the first message is expunged, mbox and mbx formats have to rewrite the entire 2GB mailbox. mix only rewrites the index file, status file, and the data file that holds that message. That may be "slower" than maildir's deletion of a file, but in terms of real time there is no user-visible difference; and in mix you get proper concurrent process synchronization with no confusion about "where did that message just go". - -- Mark -- http://staff.washington.edu/mrc Science does not emerge from voting, party politics, or public debate. Si vis pacem, para bellum. ++- 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 De todas maneras, mix no estaba terminado cuando escribió lo de arriba. Ah, el archivo de lo de arriba dicen que está aquí - no lo he probado: +++ RTFArchive (you have to get your password sent to you first if you don't know it)... see the thread starting here: https://mailman1.u.washington.edu/mailman/private/alpine-alpha/2007-January/... esp: https://mailman1.u.washington.edu/mailman/private/alpine-alpha/2007-January/... https://mailman1.u.washington.edu/mailman/private/alpine-alpha/2007-January/... and the thread starting here: https://mailman1.u.washington.edu/mailman/private/alpine-alpha/2007-January/... ++- De todos modos, Eduardo Chappa hizo un parche para usar maildir; pero ese parche (todos los suyos) los tengo aplicados y no puedo acceder. Tampoco se si ese maildir está correcto. (Son los mismos parches que aplica suse).
Pero el problema que tengo es un problema de concepto, con el Gmail (etiquetas y filtros).
Lo único que me faltaría en el Mutt es poder "archivar" los correos que están en la bandeja de entrada para que se almacenen en su carpeta (label) de la lista, pero no doy con la forma de hacerlo.
Los manuales que encuentro no dicen ni cómo, ni si es posible llevarlo a cabo y la mayoría de ellos utilizan una configuración local, es decir, que almacenan los correos en su equipo, no en el servidor. Y no voy a almacenar los 30.000 hilos con 80.000 mensajes en mi equipo, ya tengo bastantes con los del KMail >:-)
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. (Aclaración para los demás: los labels en el webmail son carpetas en imap, para gmail)
Si no encuentro una forma de archivar los mensajes en remoto, tendré que volver al webmail :-(
Leete la ayuda de gmail antes, está previsto.
Puede que se deje cambiar. En el pine se puede cambiar, al joe, por ejemplo.
Sí, eso claro que se puede cambiar. Puedes usar el editor que quieras.
El vim no está mal, sólo es cuestión de memorizar unas cuantas "teclitas" :-)
¿Unas cuantas? >:-) - -- Saludos Carlos E.R. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (GNU/Linux) iEYEARECAAYFAkmNlz4ACgkQtTMYHG2NR9XUcwCeLOmTBMXp2+QzV5RUxCYV0Hv0 UEsAoIYAj1pvC1jEXaA1xcj81nyiu5ma =ZzAk -----END PGP SIGNATURE-----
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.
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... *** 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 Mutt uses only a fraction of the memory used by most popular e-mail clients. So, if you are using older hardware, Mutt may speed up your computer by freeing some memory. Either way, Mutt will not hog your system's resources. ***
Y el Alpine es mucho más completo que el Pine, es más moderno y ha tenido una temporada de desarrollo muy activo. No te puedo decir si soporta maildir porque no lo uso. Espera, tengo un directorio de pruebas con maildir, voy a mirar... [...] No, no lo lee. Tiene esto:
cer@nimrodel:~> ls Mail/file/entrada_maildir/ cur new tmp
Pero si gmail es imap, lo que usen ellos es transparente para ti.
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.
(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.
Tira por tierra lo de que mail dir soporte acceso concurrente, es falso:
Que no le gusta ni un pelo. Pero me da que no le gusta porque no está normalizado, y no querrá meter la pata desarrollando sobre "supuestos" :-)
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.
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. No es viable. Tendría que poder ejecutar la orden de archivado manualmente, que es lo que estoy buscando.
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. 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
-----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-----
On Sat, Feb 07, 2009 at 06:01:03PM +0100, Carlos E. R. wrote:
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.
Pues eso es más ram que el KMail >:-P
Pos eso. Yo no quiero usar un formato que sólo sea usado por algunos, me puede dejar pillado.
Para pillado cuando el thundercito deja de mostrar los corres :-}
Pos los conviertes a mbox >:-)
Buf... de momento, no. Ya me tocará, cuando actualice a la 11.2 :-)
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.
Cada uno tira para su lado... en la wiki de Mutt también lo comentan: http://wiki.mutt.org/?MuttFaq/Maildir
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.
Los servidores (como Cyrus o Dovecot) utilizarán un sistema propio para gestionar ésto. No he tenido problemas de este tipo con clientes (Kmail) ni con servidores (Cyrus).
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.
No te olvides de otros sistemas de archivos, como el hfs+ de MacOS o el nuevo ZFS de Solaris. No sé cómo se llevarán estos dos con una buena cantidad de archivitos :-? En cuaquier caso, los sistemas de archivos van a tener que adaptarse a estos requerimientos, es lo que viene.
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.
Sigo bsucando cómo domar a "la bestia" :-) El Mutt es potente, pero un poco complicadillo. 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
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 El 2009-02-07 a las 19:41 +0100, Camaleón escribió:
On Sat, Feb 07, 2009 at 06:01:03PM +0100, Carlos E. R. wrote:
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.
Pues eso es más ram que el KMail >:-P
Pues mira ahora: 16741 cer 20 0 13308 5940 3156 S 0.0 0.6 0:03.31 alpine Acabado de arrancar, en la misma carpeta. No puedes comparar con un programa que lleva abierto varios días.
Pos eso. Yo no quiero usar un formato que sólo sea usado por algunos, me puede dejar pillado.
Para pillado cuando el thundercito deja de mostrar los corres :-}
Pos eso, yo no uso el Th. más que cuando necesito ver o responder en html. Pero es lo que te digo, que con mbox puedo tranquilamente elegir que cliente usar: puedo ver las mismas carpetas físicas con Alpine, Kmail balsa o Thunderbird. Y mutt, si me lo propusiera. El evince... en sus día no me gustó, porque hace su propia copia. Yo me refiero a usar las mismas carpetas mbox con uno u otro cliente según me de el día. La otra manera de hacerlo es tener un servidor imap local, donde esté todo tu correo.
Pos los conviertes a mbox >:-)
Buf... de momento, no. Ya me tocará, cuando actualice a la 11.2 :-)
Jeje...
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.
Cada uno tira para su lado... en la wiki de Mutt también lo comentan:
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.
Los servidores (como Cyrus o Dovecot) utilizarán un sistema propio para gestionar ésto.
Cyrus usa algo que parece maildir pero no lo es - según Mark.
No he tenido problemas de este tipo con clientes (Kmail) ni con servidores (Cyrus).
El problema que comenta Mark es con varios clientes accediendo al mismo mensaje.
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.
No te olvides de otros sistemas de archivos, como el hfs+ de MacOS o el nuevo ZFS de Solaris. No sé cómo se llevarán estos dos con una buena cantidad de archivitos :-?
Con una buena cantidad, hay varios que lo toleran. El xfs se lleva muy bien. Pero es que el reiserfs se lleva especialmente bien con ficheros diminutos, que es el caso.
En cuaquier caso, los sistemas de archivos van a tener que adaptarse a estos requerimientos, es lo que viene.
¿Diminutos? No, el único es reiser.
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.
Sigo bsucando cómo domar a "la bestia" :-)
El Mutt es potente, pero un poco complicadillo.
Eso ya te lo dije. Por eso renuncié a el. Una cosa que use o se parezca al vi no entra en mis dominios. Mmm... Tengo que desinstalarlo, sí que está en mis dominios >:-) Alpine tiene filtros de llegada, puede hacer acciones. Lo que pasa es que recomiendan ellos usar preferiblemente los filtros de procmail - que no te valen. Pero es posible que sí soporten (los de alpine) acciones como las que quieres hacer (no lo se). - -- Saludos Carlos E.R. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (GNU/Linux) iEYEARECAAYFAkmN33UACgkQtTMYHG2NR9XP8gCeKqZKb6txeQzZlGpcSIhpl44q IcsAniL5VkS8yaqMHbmi3B2i3SPuR7ej =wo8o -----END PGP SIGNATURE-----
participants (3)
-
Camaleón
-
Carlos E. R.
-
Xavier Barnada