Libertonia || Comments || Cuando falla el proceso


Portada · Todo · Software Libre · Desarrolladores · Comunidad · Internet · Tecnología · Meta · Diarios

Cuando falla el proceso | 52 comentarios (52 temáticos, editoriales, 0 ocultos)

Monopolios software libre (4.88 / 9) (#25)
por svampa a las Tue Dec 2nd, 2003 at 07:31:07 PM CET
(Información Usuario)

El software libre tiene algunos de los problemas del propietario, y los suyos propios.

Uno de los primeros problemas del software libre es que tambien tiene sus "monopolios". Son las aplicaciones "killer" que prácticamente se han apropiado de un determinado nicho. Estas aplicaciones han llegado por méritos propios a la actual posición, sin embargo, una vez ha alcazado el status, pueden empezar padecer el sindrome del monopolio, en mayor o menor medida. ¿A alguien se le ocurre una alternativa a Apache? probablemente las hay, pero las probabilidades de "entrar en el mercado" son escasas.

Eso da a los lideres de un proyecto de este estilo una situación de privilegio, y como humanos que son, pueden empecinarse en una mala idea, y nos la tragaremos todos. Si la cosa se vuelve demasiado demencial puede surgir un fork, o una alternativa, que independientemente de su calidad (puede ser muy superior) debera enfrentarse a todo un monopolio. Y es probable que los lideres del programa original, heridos en su amor propio, usen técnicas de FUD.

De hecho, este tipo de proyectos prácticamente han abandonado el modelo "bazar" para ser "catedral", o al menos hay unos sumos sacerdotes con poder inmenso que deciden que entra y sale del bazar.

En el software libre se piensa que una sana competencia es buena para mejorar. La competencia genera ganadores y perdores, y los ganadores (al igual que entre las empresas) no serán los mejores técnicamente, sino los que tengan mejor difusión (por habilidad de sus lideres o por azar), o los que hayan llegado primero y estén más implantados.

Por ejemplo, un nuevo servidor de webs, con una superioridad aplastante en rendimiento y seguridad al Apache, con una documentación excelente, pero escrita en ruso, no tendrá ninguna repercusión. Y si el que lo traduce al inglés, no lo hace muy bien, además siempre con atraso dará la sensación de que está a medio hacer.

El Ruby, por ejemplo, escrito por japoneses, le ha costado tiempo abrirse camino. Y desde luego, su implantación está a años luz del Perl.

El sendmail, un venerable programa, pero monolitico, con continuos problemas de seguridad, ha costado muchisimo sustituirlo por alternativas como Exim, postfix y qmail, más agiles y fiables. De hecho, hay muchisimos sitios donde se sigue utilizando.

El XFree, a pesar de los defectos que se le atribuyen, y su estancamiento, ha costado años que alguien se atreviera a hacer un fork, y aun estamos esperando a ver como termina.

El bind, es un desastre, y no es la primera vez que lo oigo. A pesar de eso, el 90% de los servidores unix lo usan.

¿Y Linux? ¿es mejor cualquiera de los BSDs? ¿Es unix el final de la evolución, no habría que intentar algo más? ¿Hurd triunfará sobre Linux?. No importa si la respuesta es positiva o negativa, la cuestión es que a cualquier alternativa, independientemente de sus virtudes, le costaría años superar a Linux. Si el señor Torvalds de repente se empecianara en un error ¿Quien se atrevería a hacer un fork?

Otro de los problemas evidentes es que depende de voluntarios, y por tanto de la buena voluntad, que suele ser menos constante que las ganas de ganar dinero.

Otra de las pegas, por el modelo de desarrollo, más bien incremental, es que para cierto tipo de proyectos no funciona bien.

Una vez leí una comparación del software libre con la cosntrucción: Para consturir una casa, la empiezas pequeñita y terminas teniendo una palacio. Pero no funciona para construir una presa, no puedes empezar una presa pequeñita en el Amazonas. La presa la has de contruir entera, y no servirá para nada hasta que no esté terminada. Este último tipo de proyectos, no atrae a desearrolladores voluntarios.

Por último, los que dedican muchas horas a un proyecto, puede hartarse de dedicar horas sin más recompensa que quejas de maleducados. Así que pueden decantarse por dos opciones, abandonar el proyecto, o intentar ganar dinero con él, lo que es díficil. Así que la tentación de ocultar información, para cobrar por sus conocimientos exclusivos de desarrollador, es muy alta.

A esto le sumamos las empresas, que han empezado a meter la cuchara, lo que significa que intentan obtener "exclusividad" para ser más competitvos, lo que no encaja demasiado con el espiritu del software libre.

Y esto de los proyecto con éxito. Luego está la legión de proyectos apenas empezados, mal pesandos y peor diseñados. De personas con experiencia en pequeños programas para si mismos, o hackerar programas de otros, pero que no tienen ni idea de como organizar una proyecto que va a circular por el mundo, ni la constancia necesaria para terminarlo, al menos hasta un mínimo.

Sigo consderando que el software libre tiene muchas ventajas, pero desde luego no es la solución a todo. Tiene también muchos problemas.

Ah sí, sendmail (4.00 / 3) (#28)
por man ls a las Wed Dec 3rd, 2003 at 01:32:36 AM CET
(Información Usuario)

Se me olvidó poner el enlace, también de Bernstein como el de BIND, criticando Sendmail Inc. y sus prácticas.

También hablas de Linux y el señor Torvalds. Nadie es perfecto (ni siquiera yo ;-) y, por lo poco que entiendo de esto, la postura más discutible que he visto es su uso y defensa de BitKeeper para mantener el código fuente del kernel.

En lwn, encontré esta interesante discusión entre Ciaran O'Riordan (FSF Europa) y Larry McVoy (dueño de BitMover, la empresa que desarrolla BitKeeper). Incluyo aquí unas citas de este último.

Si estáis intentando copiar BitKeeper, olvidadlo. Seguiremos los pasos de todas las empresas que se han encontrado en esta situación, y cambiaremos el protocolo cada 6 meses. Como siempre estaréis por detrás de nosotros, no nos vais a alcanzar nunca. Si a pesar de todo consiguiérais seguirnos los pasos, pondríamos firmas digitales en el protocolo para impedir que vuestra copia se comunique con BitKeeper.

Esperad, que todavía hay más en el mismo hilo:

Haya o no haya derechos legales, si intentáis sacar el protocolo de BitKeeper mediante ingeniería inversa, dejamos de distribuirlo gratis. ¿Ves? Así de fácil.

Y aún hay más (este tío es una mina):

Hay muchos que se ponen nerviosos porque las malvadas corporaciones están bloqueándolo todo con DRM, y leyes como la DMCA. La gente habla sobre cómo se violan sus "derechos", lo horrible que es todo, etc, etc, etc.

Lo que parece que se olvida aquí es que la gente que está bloqueándolo todo son los dueños, y los que se quejan son los que consiguieron las cosas de forma ilegal y gratis.

[...]

La comunidad open-source, en mi opinión, es un factor decisivo para la aparición de la ley DMCA y los distintos DRM. Esta comunidad piensa que es aceptable copiar cualquier cosa que les parezca útil.

[...]

Las grandes corporaciones están vigilando cómo van casos como nuestro BitKeeper, al igual que otras empresas que intentan hacerle el juego al mundo open-source. ¿Qué es lo que ven? Que, si no se bloquean las cosas, el mundo open-source no tiene conciencia, ni respeto, y roba todo lo que no está bajo tres cerrojos. Muéstrame un solo ejemplo en que la comunidad haya dicho "no, no podemos hacer eso, alguien se tomó mucho trabajo para hacerlo, no nosotros". No creo que lo encuentres. En su lugar, dicen: "oye, eso está bien, vamos a copiarlo". Sin tener en cuenta que la creación de un producto cuesta 100 veces más que la copia.

¿Os pensáis que las corporaciones van a quedarse sentados viéndoos, y no van a hacer nada para pararos los pies? Claro que no, tienen un instinto de conservación muy fuerte, y tienen los recursos para hacer frente al problema. La DMCA, DRM, y demás son sólo el principio. Vosotros responderéis con todo tipo de trucos para saltaros las protecciones, y ellos responderán con trucos aún más ingeniosos para pararos. Tienen más recursos y maś en juego, así que ganarán.

Lo penoso es que sea tan obvio para mí que las corporaciones van a ganar, que van a protegerse: tienen el dinero para hacer presión al gobierno para que saque las leyes que ellos quieran, y para hacer la tecnología que necesiten. Cuanto más empujéis, más bajo llave acabarán las cosas.

Como veis, todo un defensor del software libre.

[ Padre ]

No quisiera una guerra (none / 0) (#32)
por thuban a las Wed Dec 3rd, 2003 at 10:29:58 AM CET
(Información Usuario)

Pero me parece completamente razonable lo que dice el amigo Larry. El defiende lo suyo.

Ha hecho una aplicacion para llevar el control de versiones que le ha costado dios y ayuda llevar a buen termino, tiene una base de clientes y una respetable facturacion. Si ve el riesgo de que alguien haga un cliente o un servidor compatible y lo ponga gratis por ahi quitandole clientes, lo hara incompatible cambiando... los bytes de los enteros de orden, por ejemplo.

Porque es suyo y puede.

No esta atacando al software libre. Esta defendiendo el software propietario. En concreto, esta defendiendo su software. El no se mete con el CVS (y podria, porque es competencia), con el Konqueror o con Mozilla. El dice que hara que su protocolo solo se pueda usar con sus productos.

Vamos a ver. Me viene muy bien que el Gaim pueda trabajar con varios protocolos porque asi solo tengo que tener un programa abierto, pero me parece normal que los de Microsoft o los de Yahoo se dediquen a cambiar los protocolos para que tenga que usar sus productos, porque ellos tienen que pagar las maquinas, los canutos y los sueldos de los adminsitradores de los servidores. Igual que me parece normal, y agradezco, que los chicos de Gaim se empeñen en desentrañar de nuevo los protocolos.

En fin, no quiero empezar una guerra y espero que no os tomeis esto muy a las bravas, que parece que este hilo es un poco tenso, pero es que no me parece que el software propietario sea ningun enemigo. Es software y nada mas. Otra oferta.

[ Padre ]

¡Es la guerra! (none / 0) (#35)
por man ls a las Wed Dec 3rd, 2003 at 12:43:30 PM CET
(Información Usuario)

No, es broma, yo tampoco quiero una guerra. Claro que McVoy puede hacer lo que quiera. Pero no me parece un personaje al que yo confiaría mi código fuente. El colega no dice: "ingenieria-inversad todo lo que queráis, nuestro producto siempre será mejor"; más bien acaba diciendo "la pelota es mía y tenéis que jugar con mis reglas".

Igual que me parece normal, y agradezco, que los chicos de Gaim se empeñen en desentrañar de nuevo los protocolos.

Si el pollo éste tiene razón, a lo mejor dentro de poco se vuelve ilegal hacer ingeniería inversa sobre los protocolos propietarios. Eso no sería nada divertido.

[ Padre ]

Sobre ilegalidades (none / 0) (#36)
por advocatux a las Wed Dec 3rd, 2003 at 01:38:29 PM CET
(Información Usuario)

[...] a lo mejor dentro de poco se vuelve ilegal hacer ingeniería inversa sobre los protocolos propietarios [...]

YA lo es.
--
- Por una Europa libre de Patentes de Software - EuropeSwPatentFree
[ Padre ]

Excepto en ciertos supuestos en la UE (4.00 / 1) (#40)
por iarenaza a las Thu Dec 4th, 2003 at 11:05:05 AM CET
(Información Usuario) http://www.escomposlinux.org/

Si no estoy equivocado, en la UE (y casi con toda seguridad en España) es legal hacer ingeniería inversa a efectos de compatibilidad o interoperabilidad con otros productos (la redacción no es esta, pero me suena algo muy similar en la letra, y desde luego en el espiritu). No tengo a mano una copia de la LPI para apoyar esta afirmación, pero tratare de buscar la referencia concreta.

Saludos. Iñaki.

[ Padre ]

Creo que depende de la licencia (none / 0) (#42)
por sanko (jsancho@aditel.org) a las Thu Dec 4th, 2003 at 03:40:38 PM CET
(Información Usuario) http://www.jsancho.org/

No estoy muy seguro de lo que voy a decir ni tengo fuentes en las que apoyarme pero creo que la legalidad de la ingeniería inversa viene determinada por la licencia del producto en cuestión.

Si en la licencia viene determinado que no se puede estudiar el funcionamiento del programa, entonces no se puede y se podría demandar al que lo hiciera.

Esto es debido a que las licencias tienen el mismo valor que los contratos. En el momento que pulsas el botón "Acepto" es como si estuvieras firmando el contrato y si la licencia dice que no se puede usar un desensamblador con el programa estas dando tu conformidad al aceptar.

En el caso de los formatos ya no estoy tan seguro, pero con los programas creo que es así.

[ Padre ]

Contratos y clausulas ilegales (none / 0) (#45)
por iarenaza a las Thu Dec 4th, 2003 at 09:16:38 PM CET
(Información Usuario) http://www.escomposlinux.org/

Si no estoy equivocado (no soy un abogado, ni juego a ser uno en la red ;), un contrato no puede incluir clausulas que no sean legales. Y de hacerlo, dichas clausulas (y en esto no estoy tan seguro como en lo anterior) se anulan automáticamente.

Si lo anterior es como creo, da igual lo que ponga la licencia, ya que la Ley de Propiedad Intelectual está por encima suya (es precisamente quien regula el que se pueda licenciar) y por tanto anula dichas clausulas.

Saludos. Iñaki.

[ Padre ]

Aquí esta la referencia (none / 0) (#46)
por iarenaza a las Thu Dec 4th, 2003 at 10:02:02 PM CET
(Información Usuario) http://www.escomposlinux.org/

Me he tenido que tragar buena parte del tocho de la LPI, pero ha valido la pena. Se trata del punto 5, del artículo 100, del título VII de la Ley de Propiedad Intelectual de 1996 (se puede encontrar una copia aquí, por ejemplo).

Saludos. Iñaki.

[ Padre ]

No me gusta la LPI (5.00 / 1) (#49)
por sanko (jsancho@aditel.org) a las Fri Dec 5th, 2003 at 08:50:32 AM CET
(Información Usuario) http://www.jsancho.org/

Cada vez que tengo que pegar un vistazo a la LPI me encuentro con más y más contradicciones.

Por ejemplo, con respecto al tema que nos ocupa, veo en el Artículo 96 que:

4. No estarán protegidos mediante los derechos de autor con arreglo a la presente Ley las ideas y principios en los que se basan cualquiera de los elementos de un programa de ordenador incluidos los que sirven de fundamento a sus interfaces.

Y el Artículo 100 dice:

3. El usuario legítimo de la copia de un programa estará facultado para observar, estudiar o verificar su funcionamiento, sin autorización previa del titular, con el fin de determinar las ideas y principios implícitos en cualquier elemento del programa, siempre que lo haga durante cualquiera de las operaciones de carga, visualización, ejecución, transmisión o almacenamiento del programa que tiene derecho a hacer.

Según entiendo nos esta diciendo que es legal la ingeniería inversa. Sin embargo, si seguimos leyendo nos encontramos con algunas perlas como estas:

6. La excepción contemplada en el apartado 5 de este artículo será aplicable siempre que la información así obtenida:

a) Se utilice únicamente para conseguir la interoperabilidad del programa creado de forma independiente.

b) Sólo se comunique a terceros cuando sea necesario para la interoperabilidad del programa creado de forma independiente.

c) No se utilice para el desarrollo, producción o comercialización de un programa sustancialmente similar en su expresión, o para cualquier otro acto que infrinja los derechos de autor.

Y ahora es cuando me asaltan las dudas. Quizás soy algo paranoico, pero yo diría que el apartado b) habla de que si hago un programa basado en algo que he obtenido estudiando otro programa no puedo hacerlo de código abierto, ya que no es necesario que el código sea abierto para la interoperabilidad del programa.

Y según el apartado c) no puedo estudiar un reproductor de películas con formato privado ZZZ para crear un reproductor alternativo que tambien use el formato ZZZ.

En resumen, mira pero no toques.

[ Padre ]

Gracias por la referencia (none / 0) (#48)
por man ls a las Fri Dec 5th, 2003 at 12:44:56 AM CET
(Información Usuario)

Es muy interesante, además algunos de los puntos de Larry McVoy en el hilo citado arriba son inválidos. Por ejemplo, respondiendo a:

"Señor Juez, nuestra ley alemana de copyright explícitamente declara que tal cláusula es inválida."

No, no lo es. Vuestra casuística está basada en una *compra* o *alquiler* de un producto por *dinero*. Si nos hubieras pagado dinero, podrías tener razón. Pero no nos has pagado. Puedes usar el producto gratis, y hasta que no haya casuística en contrario, hacemos las reglas que queremos. Y nuestras reglas dicen que no puedes hacer ingeniería inversa. Siento que no te guste, no derrocho precisamente simpatía por alguien que no ha pagado un duro y encima se queja de que no puede descifrar y robar lo que no ha pagado.

Compárese con la LPI:

No será necesaria la autorización del titular del derecho cuando la reproducción del código y la traducción de su forma en el sentido de los párrafos a) y b) del artículo 99 de la presente Ley, sea indispensable para obtener la información necesaria para la interoperabilidad de un programa creado de forma independiente con otros programas, siempre que se cumplan los siguientes requisitos:

a) Que tales actos sean realizados por el usuario legítimo o por cualquier otra persona facultada para utilizar una copia del programa, o, en su nombre, por parte de una persona debidamente autorizada.

Obviamente, no hay que pagar dinero para ser un "usuario legítimo"; y obviamente, en España no nos regimos por la casuística, como en Estados Unidos.

La verdad es que dormiré más tranquilo después de leer esto.

[ Padre ]

A ver dónde me meto (none / 0) (#37)
por man ls a las Wed Dec 3rd, 2003 at 02:50:31 PM CET
(Información Usuario)

Seguramente sea mala idea entrar en una discusión sobre leyes con un abogado... :-)

Bueno, por si acaso yo pregunto: ¿dónde es ilegal? En Estados Unidos es ilegal la ingeniería inversa sobre protecciones y medidas de seguridad, que yo sepa; en la Unión Europea creo que se garantiza el derecho a la interoperabilidad. ¿A qué te refieres?

[ Padre ]

Los monopolios son inevitables (4.00 / 2) (#31)
por sanko (jsancho@aditel.org) a las Wed Dec 3rd, 2003 at 10:24:52 AM CET
(Información Usuario) http://www.jsancho.org/

Desde mi punto de vista tiene lógica. Si un producto es mejor o es más bonito o simplemente es más conocido o en resumen tiene ventaja sobre el resto de productos, es lógico que la mayoría de usuarios tienda a usar ese producto. Diría que es inevitable.

Y sin embargo son dos situaciones muy distintas las que se dan en el software libre y en el software propietario. Según lo veo yo se dan dos tipos de monopolio, de producto y de empresa, y son completamente diferentes.

Los monopolios de empresa controlan y abusan del mercado, impidiendo que otras empresas puedan entrar en el mercado y eliminando toda posibilidad de competencia seria. Es el caso del software propietario.

Los monopolios de producto implican que una gran mayoría de usuarios tienen un determinado programa funcionando en sus ordenadores. Pero eso no quiere decir que ese producto este sujeto a los caprichos de una determinada empresa, y el mercado es completamente abierto.

El ejemplo más claro es Linux. Es un monopolio de producto total, pero tenemos distribuciones para parar un tren (Red Hat, Fedora, Debian, Suse, Mandrake, Linex, ...), unas de empresas y otras no. No existe ninguna empresa que controle el destino de Linux, ni tampoco Linus Torvalds ni Allan Cox. Sus decisiones pueden afectar pero no son determinantes para la globalidad del producto.

Por eso no comparto tu afirmación de que las probabilidades de entrar en el mercado son escasas. Justamente lo contrario, entrar es lo fácil. Pero en un mercado tan competitivo como es el del software libre despuntar y triunfar es lo díficil. Tienes que ser de los mejores para conseguirlo. Pero tienes la oportunidad de enfrentarte a los mejores y de intentar ganar, tienes esa elección, en el software propietario no te dejan ni intentarlo.

Respecto a los colaboradores voluntarios, pienso que en ocasiones el que te guste un proyecto puede prevalecer sobre el dinero que ganes. Si trabajas en una empresa en la que no te gusta mucho lo que haces y te ofrecen otra cosa por el mismo dinero hay posibilidades de que cambies. Por supuesto, todo depende de la situación de la persona en concreto, pero pienso que el hecho de que te paguen no es garantía de que vayas a continuar fielmente en el proyecto.

De todas formas coincido en que hay proyectos que no atraen a nadie por el motivo que sea y que la única forma de conseguir que la gente trabaje en ellos es pagando.

Yo también pienso que el software libre no es la solución a todo, pero hoy por hoy creo que es la solución menos mala de todas.

[ Padre ]

No creo que se pueda hablar de monopolios (none / 0) (#27)
por Ed hunter (eduardo.mestreENhispalinux.es) a las Wed Dec 3rd, 2003 at 01:05:14 AM CET
(Información Usuario) http://speedball.servemp3.com

Hay alternativas a Apache como servidor web. De hecho hay muchas alternativas: Roxen, Zope (aunque puede "integrarse" con Apache usa su própio servidor web... incluso Webmin tiene su propio servidor. Es cierto que Apache tiene más "features" pero es que mayoritariamente provienen del propio proyecto Apache. Si el resto no las tienen es porque sus desarrolladores son menos activos... o porque como mayoritariamente se usa Apache, hay más programadores de Apache.

Linux no tiene ni de lejos el monopolio de los sistemas operativos libres. De hecho si me pongo agorero predigo que seguramente Linux perderá mucho fuelle si Hurd llega al 2.0, cosa que sólo conseguirá si pasa de ser una catedral a un bazar. Y es que en realidad el secreto de Linux es ese, que es un bazar, y no importa demasiado que Linus meta la pata, siempre habrá un Cox de turno que seguirá el camino correcto (o viceversa).

Alternativas a Bind, las hay y muchas. ¿Por qué se usa Bind si es tan malo? porque, y aquí agarrense, Bind no es malo, pero tampoco es chachipiruli. Lo mismo pasa con Sendmail.

El caso que más se aproxima a lo de monopolio es sin duda XFree86. Todas las distribuciones usan XFree86, todos los sitemas operativos libres likeUNIX (Linux, *BSD...) usan XFree86. Incluso los unices prisioneros según circustáncias tienen que recurrir a XFree86. De hecho el Xconsorcium ha tenido que doblegarse a XFree86, ya que tiene más usuarios que todos los demas juntos. Apenas hay alternativas dentro de X-Window a XFree86, y las que hay son marginales (tanto libres como prisioneras). La cuestión es ¿se puede mejorar XFree86 manteniendose dentro de X-Window o hay que superar el modelo Xlib?

Speedball la banda de heavy más chunga
Ven al Helvete Metal Bar
[ Padre ]

diferencias entre Zope y Apache (none / 0) (#29)
por preage a las Wed Dec 3rd, 2003 at 01:56:24 AM CET
(Información Usuario) http://geocities.com/dariapra

Apache no es lo mismo que Zope. Apache es un servidor http mientras que Zope es un servidor de aplicaciones.

Apache tiene una gran cantidad de módulos, algunos de los cuales permiten la generación dinámica de páginas web.

Esencialmente, Apache es un servidor web con la capacidad de aceptar módulos que le permiten integrar nuevas funcionalidades.

El caso de Zope es distinto. Zope es un servidor de aplicaciones. Incorpora, entre otras cosas, un servidor http. La diferencia es que Zope no precisa de ningún tipo de módulo adicional para ser servidor de aplicaciones. Es más, el servidor http que tiene Zope es, en mi opinión, algo que está bien para un entorno de desarrollo o un entorno en producción del que no se espera que vaya a soportar grandes cargas. Vamos, lo que estoy diciendo es que ese servidor http está bien para "salir" del paso.

Es más, Zope incorpora una base de datos llamada ZODB. Quiero decir con esto que no hace falta instalar ningún módulo adicional para que esta base de datos esté en funcionamiento.

A la hora de servir páginas web, dudo mucho que el servidor http de Zope se pueda comparar con el servidor http Apache en rendimiento. Apache está escrito en C++ mientras que Zope está escrito en su práctica totalidad en Python, que es un lenguaje interpretado.

Por lo tanto, no creo que Zope y Apache sean comparables. Es más, Zope incorpora también un servidor FTP que está disponible sin necesidad de instalar ningún módulo adicional.

Una situación parecida se da con a Tomcat, la implementación de referencia de la especificación servlets/JSP. Tomcat tiene también un servidor http, que está disponible sin necesidad de instalar ningún tipo de software adicional. De nuevo, como servidor http, Tomcat no es comparable en prestaciones a Apache.

No creo, por lo tanto, que Zope y Apache sean productos comparables.

[ Padre ]

Ya lo sabía, pero hablo de otra cosa (4.50 / 2) (#33)
por Ed hunter (eduardo.mestreENhispalinux.es) a las Wed Dec 3rd, 2003 at 10:37:49 AM CET
(Información Usuario) http://speedball.servemp3.com

En mi comentario original pone "Zope (aunque puede "integrarse" con Apache usa su própio servidor web" (falta cerrar el paréntesis, pero bueno), es decir, Zope tiene un servidor web, aparte de tener otras cosas y poder integrarse con Apache. Bueno, no queda muy claro, pero lo que si quería decir es que para servir páginas web no hace falta usar Apache en absoluto, existen diferentes alternativas, entre ellas usar Zope (¿si o si?), aunque Apache es la más completa (gracias a los modulos, por supuesto). Que Apache tenga 290 modulos sin duda se debe a la gran flexibilidad del diseño de Apache, a ser el más usado y a que Apache tiene una comunidad muy viva.

Puedes creer lo que quieras, pero Zope va muy bien, y tiene un buen rendimiento (para lo que he probado en el curro). Evidentemente no puedes comparar el rendimiento de Zope (que siempre sirve páginas dinámicas) con el de Apache sirviendo páginas estáticas.

Zope y Apache son comparables en cuanto los dos sirven páginas web, pero los dos estan dirigidos a segmentos diferentes. De todas formas, nada te impide usar exclusivamente el servidor web de Zope e ignorar la parte de servidor de aplicaciones.

Lo mismo pasa con Webmin. No es un producto comparable al Apache, ni a Zope, pero te ofrece un entorno web con el que administrar tus máquinas UNIX o Linux.

Básicamente quiero decir que para servir páginas web a traves de la red no es imprescindible ni necesario tener Apache, tienes muchas alternativas, con lo que no puede hablarse de monopolio de servicio http. En Windows si que existe dicho monopolio, ya que la mayoría de aplicaciones web requieren que este instalado el IIS, ya sea para ofrecer servicios de administración por web, o lo que sea.

Otra cosa que quería indicar es la leyenda de compilado más rápido que interpretado. Como regla general, es cierto, pero siempre hablando del mismo código. Por ejemplo, puedo tener una aplicación escrita en C para ordenar elementos mucho más lenta que otra escrita en python, simplemente por una mala selección de algoridmos. Si la primera usa el algoridmo de la burbuja y el segundo un qsort la diferencia puede ser de varios ordenes de magnitud. Si los dos utilizan el mismo algoridmo, la diferencia será una constante, con lo que al final puede llegar a ser despreciable, por ejemplo, si uno tarda 1h y el otro 1h20s. Además, los lenguajes interpretados suelen ser de un nivel mucho más alto que los compilados, con lo que la diferencia se reduce todavía más. Total, que excepto en situaciones críticas, cada vez importa menos si es compilado o interpretado. Y hay que tener en cuenta que las situaciones críticas evolucionan. Por ejemplo, en su día el Pac-Man necesitaba ser programado en ensamblador, y el Frozen-Bubble esta escrito en Perl. Dentro de diez años se podrá hacer el Doom3 en Java o en Ruby.

Speedball la banda de heavy más chunga
Ven al Helvete Metal Bar
[ Padre ]

segmentos de mercado y mis impresiones sobre Zope (none / 0) (#38)
por preage a las Wed Dec 3rd, 2003 at 05:16:39 PM CET
(Información Usuario) http://geocities.com/dariapra

Una de las cosas que quería decir es que Zope y Apache al ser productos tan diferentes son productos que, en mi opinión, van dirigidos a distintos segmentos de mercado. Ocurre que Zope tiene un servidor http y en este sentido, hay un "solapamiento" entre ambos productos.

Zope sin duda es muy atractivo para una empresa o institución que quiera un "todo en uno": puede ver en Zope una forma de reducir costes de mantenimiento comparado con tener un servidor http Apache por un lado, un servidor FTP por otro... cuyo mantenimiento por separado probablemente suponga más horas que en el caso de Zope.

De ahí que piense que Zope y Apache está dirigidos a segmentos de mercado distintos y que no vea que Zope y Apache compitan.

Puedes creer lo que quieras, pero Zope va muy bien, y tiene un buen rendimiento (para lo que he probado en el curro). Evidentemente no puedes comparar el rendimiento de Zope (que siempre sirve páginas dinámicas) con el de Apache sirviendo páginas estáticas.

Yo he trabajado con las versiones 2.6.0 y 2.6.1 de Zope con Red Hat Linux durante casi 4 meses y mi experiencia con Zope no es tan positiva como la tuya.

Del rendimiento de Zope no puedo hablar, ya que dejé la empresa cuando se iba a empezar a instalar maquetas de Zope sobre las que se iban a hacer diversas pruebas de stress.

Mi experiencia no del todo satisfactoria con Zope viene dada por el hecho de que Zope a veces se caía por las buenas. Podía estar funcionando sin problema durante días e incluso semanas y sin causa aparente, caerse. Como encargado de la instalación y administración de Zope, la mirada que importa, la del jefe de proyecto, apuntaba a servidor.

Jamás supe qué pasaba exactamente. Estas caídas desaparecieron cuando cambié la versión de Zope de 2.6.0 a 2.6.1. Al menos hasta que dejé de trabajar en esa empresa, después de dicho upgrade las únicas paradas de Zope eran las que hacíamos voluntariamente.

La idea de hacer dicho upgrade la tuve cuando vi que en una maqueta "guarra" para hacer pruebas de Zope versión 2.6.1, Zope se ejecutaba sobre su propio intérprete Python (lo cual , por supuesto, se podía cambiar), lo cual me parecía un poco raro habida cuenta de que uno de los requisitos para la instalación de Zope es tener previamente una instalación de Python hecha. Visto eso y que la maqueta "guarra" de Zope con versión 2.6.1 en la que se hacían pruebas jamás se había caído (para saberlo realmente, revisé los logs), sugerí, y así se decidió, cambiar la versión de la maqueta "buena" de Zope de 2.6.0 a 2.6.1... dejando que Zope se ejecutase sobre su propio intérprete Python.

Otra cosa que no me gustó nada de Zope (y esto es algo totalmente subjetivo) fue el lenguaje DTML. Lo encuentro innecesariamente complicado.

Sobre el futuro de Zope, creo que cuando Zope y sus productos "estrella" (como CMF o Plone) evolucionen más y estén mejor documentados (mis impresiones datan de finales de abril del 2003), Zope empezará a ser un gran producto. Por ahora me parece una promesa bastante sólida.

[ Padre ]

Cuando falla el proceso | 52 comentarios (52 temáticos, editoriales, 0 ocultos)

Menu

· crear cuenta
· FAQ
· búsqueda
· Fuentes de Noticias

Login


Nueva cuenta
Usuario:
Contraseña:

Todas las Marcas Registradas y copyrights de esta página son propiedad de sus respectivos dueños.
Los comentarios son propiedad del que los escribe.
Los iconos de las noticias y el logotipo son propiedad de Javier Malonda.
El Resto © 2002 Escomposlinux.org y aledaños.

Puedes sindicar los contenidos de libertonia en formato RSS 1.0 y RDF 0.9. También se puede sindicar la cola de envíos pendientes de moderación.

El proyecto escomposlinux.org está dedicado a la memoria de tas

crear cuenta | faq | búsqueda