"Guillermo O. Burastero" <[EMAIL PROTECTED]> dijo:
> Cristian Rodriguez escribió:
[...]
> >personalmente me agrada la vision de Torvalds,una decision tecnica en
> >lugar de una religiosa,simplemente BK es la herramienta precisa para
> >el trabajo. nada mas y nada menos.
> >Toda clase de decisiones tan importantes como esa,trae consecuencias y
> >el lo debe tener muy claro.
> No es una cuestión religiosa o Metafísica, es en todo caso una
> cuestión axiológica o sea la parte de la Filosofía que se
> encarga de la Teoría de los Valores. Cuando se supeditan los
> principios a lo pragmático (invirtiendo el orden natural en la
> jerarquía de los valores) se suele, si no es a la corta será a
> la larga, encontrar problemas y esto vale en cualquier orden de la
> vida.
Exacto. Van repetidamente en contra de las condiciones bajo las cuales
te dan permiso gratuitamente de usar un paquete muy bueno, y toda la
comunidad sufre.
> En muchos casos tomar solo la mejor decisión técnica no es
> suficiente, sobre todo cuando están en juego valores que son
> más valiosos, como ser la coherencia con los principios del
> software libre,
Violada repetidas veces, en forma grosera, en las relaciones con BitMover.
> la motivación de la comunidad de desarrolladores,
Bastante mezquinas, muchas de ellas. Como casi todo lo que hay en el
mundo. Cual es la novedad?
> la evolución a mediano y largo plazo,
Nunca ha sido tema en los 25 an~os que llevo en esto. OK, RMS anda con
su cantinela ad hoc, pero es uno de los pocos. Y ninguno de los
profetas tiene idea de lo que habla, IMHO, asi que...
> las vulnerabilidades que
> una solución propietaria conlleva,
Para pocos es un real tema. Tal vez ahora lo sera por unos 5 o 8 an~os...
> etc.
> La prueba está en que por no haberlos seguido en su momento, no se
> estaría ahora con el inconveniente de BitKeeper,
... y por el otro lado tendriamos a linux-2.4.12 como ultima version,
y a Linus y sus tenientes seguros bajo llave en diversas instituciones
siquiatricas. El aumento de productividad del desarrollo de Linux (y
seguramente otros proyectos) es /muy/ real. Y por lo demas, bk si no
otra cosa sirvio para demostrar que eso se podia hacer, y que es una
buena herramienta en la practica. Si quieres, consideralo un prototipo
que llevara a una solucion codigo abierto coherente con el desarrollo
codigo abierto.
> y quizás de haber
> empezado con alguna de las herramientas SCM FOSS disponibles,
... que como Linus dijo muchas veces, no /sirven/ para este proyecto,
y su frustracion con esos proyectos fue lo que preciasmente dio lugar
a las famosas discusiones entre los cabecillas que llevaron al disen~o
de bitkeeper...
> seguramente la gestión del desarrollo hubiera empezado más
> lentamente, pero también es casi seguro que en este mismo lapso
> hubiera mejorado muchísimo, dada la gran capacidad técnica de
> los calificados hackers del kernel. O me equivoco ?
Estas completamente perdido. Ser un excelente hacker del kernel no
hace que alguien sea bueno en SCM, o en ambientes graficos, o lo que
sea. Y no necesariamente esta la motivacion...
--
Dr. Horst H. von Brand User #22616 counter.li.org
Departamento de Informatica Fono: +56 32 654431
Universidad Tecnica Federico Santa Maria +56 32 654239
Casilla 110-V, Valparaiso, Chile Fax: +56 32 797513
From [EMAIL PROTECTED] Mon Apr 18 00:49:54 2005
From: [EMAIL PROTECTED] (Horst von Brand)
Date: Mon Apr 18 13:23:06 2005
Subject: SCM: Linus Torvalds (Linux),
Larry McVoy (BitKeeper) and Andrew Tridgell (Samba, rsync, etc.)
In-Reply-To: Your message of "Sun, 17 Apr 2005 23:39:20 -0400."
<[EMAIL PROTECTED]>
Message-ID: <[EMAIL PROTECTED]>
German Poo Caaman~o <[EMAIL PROTECTED]> dijo:
> El dom, 17-04-2005 a las 21:07 -0400, Horst von Brand escribió:
[...]
> > CVS no se hace sombra ni a si mismo. Y las demas alternativas codigo
> > abierto hasta hoy (incluso con el impulso que el uso de bk dio a
> > algunos) andan a an~os luz de lo que se requiere (Linus quiere un
> > sistema que le da la posibilidad de integrar un parche en algo como un
> > segundo, las alternativas codigo abierto que son contendores (por
> > soportar un modelo de desarrollo distribuido) andan por el cuarto de
> > hora...).
> En realidad, no es que CVS no sirva para nada.
No dije eso.
> Tiene un proposito
> y para ese proposito sirve y ha tenido vida por un monton de an~os.
Se le notan... es de la misma estirpe que SCCS, uno de los primeros
SCM. Fue un gran avance en su tiempo, hoy ya es un dinosaurio del
estilo de FORTRAN.
> Ademas debe ser la herramienta mas utilizada en el mundo del software
> libre.
Porque no habia nada siquiera similar suficientemente probado hasta,
digamos, unos dos an~os atras. Recien ahora SVN esta suficientemente
probado para considerarlos seriamente, las otras alternativas estan en
alpha o beta temprano. Notese que aca estamos hablando de la
infraestructura a la que confias /todo/ tu trabajo, si falla
facilmente puedes perderlo (piensa que pasaria si se dan~ara p.ej. el
repositorio de GCC...). Y para remate, si el repositorio se corrompe,
es bastante probable que no te enteres por bastante tiempo, con lo que
respaldos tampoco son una solucion adecuada.
CVS es un chiste: Solo repositorio central (el trabajo, dado Internet,
desde como el '91, es distribuido...). No hay posibilidad cuerda de
mover un archivo de un lado a otro en el repositorio. Historia archivo
a archivo, no parche a parche. SVN mejora mucho de eso, pero sigue con
el modelo de repositorio unico central (y no es culpa de ellos,
apuntan a ser un reemplazo de CVS por algo mas decente, nada mas).
[Si, use bk por un tiempo (despues de algunos proyectos muy chicos con
RCS), y las restricciones de CVS me molestan.]
[...]
> De cualquier forma, no hay mal que por bien no venga. Cualquiera
> sea la eleccion, ya sea tomar/mejorar una existente o escribir una
> de cero, todo apunta a que sera libre; su desarrollo se acelerara
> e ira en beneficio de todos (los proyectos de software libre).
Linus esta armando una cosa que llama git, que logra lo que buscaba
(integro casi 200 parches en un promedio de 0.8 segundos en una
tirada...). Claro que esta muy en bruto, esta la infraestructura de
base pero muy poco en terminos de comandos para usarlo. Y usa espacio
en disco que da miedo.
La alternativa que mas sonaba como opcion es monotone, pero es muy
lento. arch y sus similes son muy raros de manejar.
--
Dr. Horst H. von Brand User #22616 counter.li.org
Departamento de Informatica Fono: +56 32 654431
Universidad Tecnica Federico Santa Maria +56 32 654239
Casilla 110-V, Valparaiso, Chile Fax: +56 32 797513
