2009/11/6 Daniel Coletti <[email protected]>: > Daniel Perez escribió: >> 2009/11/5 Diego Woitasen <[email protected]>: >>> Lindo lenguaje, pero que se puede esperar de alguien que recomienda Zimbra. >> >> Bue, dicho por alguien que recomienda horde... dejate de joder. >> Por cierto la licencia de zimbra esta aprobada por la FSF. >> Hoy por hoy simplemente nada le toca el culo a zimbra como mail >> "corporativo". Decir lo contrario es decir que "mis 3 scripts mas el >> webmail que me baje por ahi son re grosos y tienen todo lo que mi >> empresa necesita... porque lo digo yo" >> Hace la prueba de instalar lo que se te ocurra en una empresas de 500+ >> empleados y la de instalar zimbra, mira las reacciones y contame. > > como disfruto de estos mails, realmente lo hago... > > Igualmente, solo para añadir un poco de contenido a la lista... > La definición de qué es mejor o qué es peor para ambientes tan complejos > como +500 usuarios "corporativos" (lease: gente que hace todas las cosas > indebidas con el cliente de colaboración), esta basada en muchas cosas, > además de la técnica hay otras como la estrategia del cliente en lo que > es dirección tecnológica y comercial.
Seguro, pero para la discusion es irrelevante, si alguien por direccion tecnologica y comercial decide poner exchange eso no hace peor a zimbra ni mejor a exchange desde el punto de vista tecnico ni pasa exchange a tocarle el culo a zimbra. Que se entienda bien esto, no estoy diciendo que exchange le toque el culo a zimbra o viceversa, lo que estoy diciendo es que si la razon para implementar uno sobre el otro es la direccion comercial por ejemplo, eso no siginifica que automaticamente el elegido le toque el culo al otro. > > IMHO, kolab es más flexible que zimbra, zimbra es más lindo y amigable > que kolab pero menos flexible (los dos usan cyrus). > > La flexibilidad de kolab está basada -a mi modo de ver- en que se pueden > manejar más cosas por afuera que zimbra (formas de clusterizar, sistemas > de backup, trazabilidad de los correos, redistribución de las casillas > de correo cyrus, elección de clientes y otros). Esto es precisamente lo que se puede hacer con zimbra, basicamente si queres hacer todo eso por *dentro* de zimbra pagas, sino justamente la onda es hacerlo por fuera, clusterizar es un termino vago hoy por hoy, podes clusterizar una aplicacion o podes clusterizar los servers en los que corre una aplicacion, ambas cosas son posibles con zimbra. El backup es un tema, al igual que el backup de una base de datos. Y hay diferencias radicales entre ambientes corporativos (notar que para mi corporativo no es sinonimo de mejor o mas lindo o mas copado sino que hasta casi diria lo contrario) y otros ambientes como por ejemplo un ISP. Lo mismo pasa con las bases de datos, no es lo mismo la de una empresa que trabaja de 9 a 18 los dias de semana que la de un sitio web que vende online por ejemplo. Teniendo esto en cuenta vos podes ver que estrategia de backup tenes que usar, y teniendo en cuenta que zimbra se usa (o al menos tiene mucho mas sentido usarlo) en ambientes corporativos el backup no es tan complicado ni es tan loco pensar que si no tenes otra, bajes el servicio mientras haces un backup en frio. De la misma manera que lo harias con un oracle si tenes que hacer backup con algo que no soporta backups de esa base en caliente. Redistribucion de casillas es feature estandar de zimbra Clientes? Es un servidor de mail podes usar lo que se te ocurra como cliente, no hagas fud. "y otros" es un buen argumento :P >Con zimbra "corporativo" > no podes usar algo más chico que Outlook 2003 y no sé cuán completo es > la compatibilidad con Thunderbird (cliente que funciona en Linux y > Windows, lo menciono porque si una empresa quiere empezar a meter SL > también en el desktop puede ser determinante). ? A ver, zimbra es un conjunto de cosas que apuntan a colaboracion o como mierda se llame la boludez de mandar citas tener un schedule y todas esas cosas que hace por ejemplo exchange. Pero no deja de ser un servidor de correo comun y corriente por abajo. De la misma manera que thunderbird no deja de ser un simple cliente de correo. Si lo que te interesa de zimbra o kolab o lo que sea es usar la parte de colaboracion no vas a usar thunderbird, por la misma razon por la que no lo usarias contra un exchange SI tenes que usar la parte colaborativa. Si solo te interesa bajar el mail o usar imap y listo podes usar thunderbird, o un telnet al 110 o 143 que a zimbra no le importa. Ahora bien si estamos hablando de zimbra o kolab desde el punto de vista de reemplazo de un exchange es una tonteria hablar de thunderbird, nadie que quiera sacarse de encima exchange *y mantener features* va a decir "ah, y de cliente quiero thunderbird" no porque zimbra no sea compatible con thunderbird o cualquier otro cliente imap o pop, sino porque thunderbird no es compatible con todo el tema de colaboracion de zimbra o cualquier otro servidor. Zimbra soporta *cualquier* cliente de correo como tal. Para la parte colaborativa hay soporte y plugins para la mayoria de las cosas que andan dando vueltas desde outlook hasta lotus. Igual obviamente la gracia es usar zimbra desktop y nada impide usar el webmail. > kolab se integra bien con Thunderbird, Kolaboración (aka: herr de KDE) y > también con Outlook 2000+ (usando plugin propietario). kolab es ligero > pero más feo (horde no tiene comparación con el terminado visual y > práctico que tiene la interfaz web de zimbra), la interfaz de > administración de kolab es paupérrima, gracias a Gosa esto puede > mejorarse bastante. De nuevo thunderbird carece de features como para usarlo de cliente de mail corporativo, que lo puedas usar como cliente de mail es otra cosa y como dije antes, si un cliente de mail comun y corriente te alcanza nada te impide usarlo con zimbra. Yo conozco un ISP que vaya uno a saber por que puso zimbra, probablemente porque el admin de turno queria probarlo... pero bue, tienen eso. Y nada les impide a sus clientes usar el cliente de mail que se les ocurra. Zimbra no deja de ser un server pop o imap aparte de otras cosas. En interface de administracion definitivamente con gosa o sin gosa no podes comprar a zimbra con kolab. > Zimbra -en modo corporativo- permite el uso de backberries en modo PUSH > (o algo así), cosa que kolab no (o sea, tenes que hacer que el telefono > busque las cosas, no al revés, y no sé qué tan bien se lleva con lo que > son citas compartidas) La version opensource creo que no usa push pero es absolutamente compatible con blackberries, porque en realidad es al reves las blackberries o iphones son compatibles con mail comun y corriente. > > A zimbra hay que pagarlo anualmente y a eso le vas a tener que sumar la > suscripciones de Red Hat ya que 'comercialmente' están muy pegados > (aunque no técnicamente). ? Se da la casualidad que la empresa que en argentina tiene alguna relacion no muy clara (para mi) con zimbra es la que tambien era representante de redhat en latinoamerica hasta que redhat vino oficialmente. Despues de eso no entiendo el estan muy pegados. Tampoco entiendo porque vas a pagar zimbra si el 99% de lo que se viene hablando aca son features que tiene la version opensource y mucho menos entiendo la trampa de sumarle el costo de un sistema operativo por abajo cuando zimbra soporta oficialmente la gran mayoria de las distribuciones que hay por ahi entre ellas debian y ubuntu. Si le agregas el costo de redhat a zimbra agregaselo a kolab tambien porque existen exactamente las mismas razones que te obligan a usar redhat con zimbra que las que te obligan a usar redhat con kolab: ninguna. > > Nosotros en XTech pusimos a andar kolab en +1000 usuarios y el cliente > está realmente contento (no tienen casi administradores técnicos, lo que > habla muy bien de la herr ya que viene funcionando sin grandes > inconvenientes desde hace un año). Ahora estamos implementando kolab en > un ambiente +4000. Se evaluó zimbra (y varios más) y por sus > incompatibilidades con Outlook 2000 no fue el elegido, además de la > atadura comercial había cosas de cómo maneja su alta disponibilidad y > balanceo de carga que requerían un cambio importante en la topología de > red de su interconexión entre los datacenters que tienen. ???? No se quien hizo la evaluacion daniel pero o se equivoco o no sabe. Las incompatibilidades con outlook 2000 no las tengo presente pero igual repito lo de antes, la gracia de zimbra no es solo reemplazar al servidor, vos lo podes usar con outlook pero tiene mucho mas sentido usar su interface web o zimbra desktop. No me imagino cambios en la topologia de red a los que te obligue zimbra y no te los obligue cualquier otra solucion. Ya que la alta disponibilidad y el balanceo de carga son cosas que se pueden tranquilamente armar por afuera de zimbra. Es como decir que la alta disponibilidad de apache te obliga a cambios en la topologia de red que no los tenes que hacer para alta disponibilidad de lighttpd > > Yendo a las definiciones 'banales' que venían incluidas en los > antecesores de este thread, existen casos (nosotros ya encontramos dos) > donde desgraciadamente zimbra ya tenía el culo roto por lo que no se lo > rompía a nadie. Digo desgraciadamente porque yo personalmente quería > implementar zimbra. Pero kolab esquivo las patadas a su culo porque no > tuvimos que migrar de outlook 2000 y sus cuatrocientos formularios ya > programados por el cliente a outlook 2003 o superior, podemos elegir > entre las múltiples formas de hacer HA+LB y de a poquito podemos ir > reemplazando los Outlooks por Thunderbird en la medida que se logren > migrar estos formularios (pedorros) a un workflow denserio. > Así que en este último caso kolab pudo pegarle algunas patadas al culo > de zimbra, no sé si se lo llegó a romper, pero quedó feliz por haber > salido victorioso :-P Si estas reemplazando outlook por thunderbird estas dejando features de lado. No entiendo como el tema es las supuestas incompatibilidades de zimbra con outlook y despues la onda es cambiar outlook por thunderbird. Si tus necesidades de correo se cumplen con tunderbird entonces no necesitas un server como exchange, kolab o zimbra. Y no me digas que los plugins de thunderbird y kolab te dan algo equivalente a un exchange-outlook porque entonces me estas tomando el pelo. Thunderbird-kolab es un parche horrible hasta que kolab tenga un cliente desktop en serio. Y no solo no es comparable a exchange-outlook mal que me pese sino tampoco a zimbra-outlook o zimbra-zimbra-desktop Lo que yo noto en los mails de ustedes es que no tienen idea de zimbra o la ultima version, bueno mas abajo esto se confirma, que probaron es del siglo pasado. Honestamente si me estas hablando de thunderbird como cliente entonces sencillamente no tenes idea de lo que es zimbra. Estamos hablando de cosas totalemente distintas. Que a mi me pueda gustar thunderbird no quiere decir que si voy a una empresa que usar outlook-exchange a ofrecerle una migracion a software libre le voy a ofrecer thunderbird como reemplazo de outlook. Por mas plugins para kolab que tenga no es lo mismo. Si una empresa puede pasar de outlook a thunderbird nunca debio usar outlook-exchange en primer lugar y entonces felicitaciones por sacarlos de ahi pero no cuenta como ejemplo. Hay en el mail una serie de chicanas que no hacian falta a) pretender que hay que pagar por zimbra si o si, yo en todo momento hablo de los features de la version opensource b) pretender que encima hay que pagar por RHEL si pones zimbra, no asi si pones kolab... c) pretender que alta disponibilidad o backups son cosas que dependen enteramente de la aplicacion que se use. Pues no, son cosas que algunas aplicaciones tienen implicitas en su funcionamiento y te pueden cobrar por ello, caso zimbra garpo, o son cosas que se resuelven por afuera de la aplicacion siendo la aplicacion irrelevante d) pretender que unas supuestas incompatibilidades con outlook es un showstopper para usar zimbra pero luego ese outlook es reemplazado por un thunderbird... Saludos, -- Daniel H. Perez -- Para desuscribirte tenés que visitar la página https://listas.linux.org.ar/mailman/listinfo/lugar-gral/ Usuarios Software Libre Argentina (USLA)
