BSD frente a Linux 5

Esto es sólo una traducción, yo no soy el autor.

Artículo original en:
http://www.over-yonder.net/~fullermd/rants/bsd4linux/05

La ingenieria de las versiones

Todos los BSD’s mantienen el sistema bajo un control de revisiones, los tres BSD’s libres usan CVS. Un control de revisiones básicamente es un proceso mediante el cual la edición de un programa significa desproteger un archivo o grupo de archivos, realizar los cambios, a continuación, subir y proteger esos archivos en las nuevas versiones, junto con un mensaje que describa el cambio. Una historia completa de todos los cambios realizados se mantiene en el sistema de control de revisiones, por lo que se puede ver un historial de los cambios, echa un vistazo a una versión antigua, ver las diferencias entre algunas versiones arbitrarias, etc.

Todos los BSD’s facilitan el acceso público a sus repositorios CVS de un modo u otro, generalmente a través de CVS anónimo, o un mirror CVSup, o a menudo ambas cosas. Esto significa que, como usuario, puedes ver exactamente qué cambios ocurrieron cuando, quién los hizo y por qué los hicieron. También siempre puedes tener los últimos cambios (en unas horas, dependiendo de las estrategias del mirror). Todos los BSD’s libres tienen listas de correo a las que puedes suscribirte y ver los cambios que se hacen. De hecho, todos ellos tienen archivos de las listas de correo. Se puede hurgar en todo el árbol de fuentes de FreeBSD online en http://cvsweb.freebsd.org/src/, y ver toda la historia de cada archivo.

En Linux, históricamente, no se ha utilizado ningún tipo de control de revisiónes del kernel. En algún momento en los días de la versión 2.4 comenzó a mantenerse en un repositorio público de BitKeeper. Muchas de las otras utilidades usan control de revisiones, pero ya que todos se desarrollan por separado, no hay ningún lugar central donde se pueda ir a mirar todos los cambios. Por lo tanto, a veces es difícil incluso obtener una imagen histórica parcial y por tanto una distribución entera es casi imposible.

Nota: Ha habido cierta controversia sobre el último párrafo. Mientras que muchos desarrolladores han utilizado CVS para ciertas partes del núcleo, la información disponible indica que Linus nunca lo ha utilizado para núcleo entero, con lo que todo no estaba en un control de revisiones coherente hasta que pasó a Bitkeeper.

Esto lleva a una gran cantidad de diferencias. Realmente, los sistemas BSD se desarrollan constantemente, siempre puedo actualizar mi sistema al último código existente, independientemente de las versiones. En Linux, eso no tiene mucho sentido ya que el proceso de liberación es muy diferente. Creo que el verbo más apropiado para una versión de Linux es “encajar”. Una versión de Linux se encaja a partir de la versión A.B de este programa, además de la versión C.D de este otro programa, además de la versión E.F de este programa … todo junto con la versión X.Y.Z del kernel. En BSD, sin embargo, ya que las piezas son desarrollados en conjunto, el verbo “cortar” (cut) tiene mucho más sentido, una versión es “cortada” en un momento determinado.

Linux libera el kernel en dos líneas paralelas (bueno, a menudo más de 2, pero estamos simplificando), una versión con un número de versión menor impar, como la versión de “desarrollo”, y una versión con un número de versión aún menor, como una versión de “producción”. Los sistemas BSD también tienen “desarrollo” y “producción”, pero se manejan de manera diferente.

CVS, como la mayoría de los sistemas de control de revisiones, tiene el concepto de “ramas”. Es fácil de entender, pero un poco difícil de explicar. Básicamente, cuando haces una “rama” de un archivo o conjunto de archivos (o un árbol de directorio entero), se crea una nueva versión del archivo que existe en paralelo con la versión primaria. Cuando se realizan cambios en la versión primaria, no afecta a la versión ramificada. Y puedes hacer cambios en la versión independiente sin afectar a la primaria.

En FreeBSD, por lo general, hay dos ramas de desarrollo activas, una llamada “CURRENT” (actual), que es la versión de desarrollo, y la otra se llama “-STABLE”, que es la versión de producción. Ambas, por supuesto, están en desarrollo, y ambas se intentan mantener utilizables. STABLE, por regla general, tiene actualizaciones de errores (bugs) y parches de seguridad, pero sólo obtienen nuevas características que han sido muy testeados, por lo general en CURRENT. CURRENT tiene nuevas características, grandes cambios en la arquitectura y todas esas cosas de nuevo desarrollo. Debe tenerse en cuenta que la nomenclatura de las ramas no significa necesariamente lo que parece. Mientras -STABLE normalmente es “estable”, “robusto”, no siempre es así. El término “estable” se refiere más al hecho de que la misma base del código no tiene introducidos grandes cambios.

En el mundo Linux, Debian hace algo similar con sus normas de liberación de versiones. Tienen una versión estable (Stable), que ebásicamente sólo tiene correcciones de grandes errores. Esto es más o menos lo mismo que pasa en el RELEASE de FreeBSD. También hay (en Debian) una versión de prueba (Testing), que tiene las características más nuevas, pero sólo después de que hayan sido probadas por un tiempo y no tengan ningún problema “importante”. Esto es similar a la rama STABLE de FreeBSD. Y tienen una versión inestable (Unstable), que es donde ocurre todo el desarrollo y dónde aparecen las nuevas versiones de paquetes. Se parece a CURRENT de FreeBSD. (Nota: No conozco muy bien el proceso de liberación de Debian, podría estar completamente equivocado. Seguramente alguien me enviará un correo con la información correcta si lo estoy).

Repito, porque es importante, que esto son RAMAS. No versiones. Ramas. No son puntos, sino que son corrientes constantes de desarrollo, cambiando día a día, hora a hora y con frecuencia minuto a minuto. Si cogiera STABLE ahora, y STABLE mañana, probablemente serán diferentes. Sin embargo, debido a que está bajo control de revisiones, puedo decir algo así como “¡Dame el STABLE a partir de las 23:30 del 13 de octubre de 2003!”, y siempre obtendré el mismo código.

De hecho, es todo lo que es una liberación (release), una instantánea de algún punto a lo largo de una rama. Por ejemplo, lo que llamamos “2.2.6-RELEASE” es en realidad sólo una instantánea de lo que la rama 2.2-STABLE parecía que el 24 de marzo de 1998. El 25 de marzo, se le llamó “2.2.6-STABLE”, a pesar de que casi nada había cambiado. Y siguió siendo llamado “2.2.6-STABLE” hasta el 21 de julio cuando una nueva instantánea se llamaba “2.2.7-RELEASE”. Y así sucesivamente.

Ahora, notará que hay una numeración en las ramas también. Tenemos 2.1-STABLE, y 2.2-STABLE, y 3-ESTABLE y 4-STABLE. Para entender eso, vamos a ver de dónde estas ramas vienen. En un momento dado, hubo un 3-CURRENT. En términos de CVS, era la cabeza del árbol, no una rama, pero la línea principal. Con el tiempo, hubo un momento en que se decidió hacer esta rama lista para la producción, por lo que se colocó una etiqueta para establecer un cierto punto como “3.0-RELEASE”. En ese momento, la rama 3 era todavía CURRENT, 2.2 era STABLE. Cuando nos acercamos a 3.1-RELEASE, se decidió que era el momento de crear la rama 3-STABLE. Por lo tanto, una rama fue creada y llamada “3-STABLE”, y CURRENT fue renombrado a “4-CURRENT”.

Lo mismo ocurrió (más o menos) cuando 4-STABLE y CURRENT se convirtieron en 5, y lo mismo va a pasar de nuevo cuando 5-STABLE y CURRENT se conviertan en 6. A veces sólo x.0 se quita antes de que la rama se convierta en STABLE, a veces incluso x.1 y x.2 también. 5.0-RELEASE es una instantánea de 5-CURRENT. Así es 5.1-RELEASE. Así es 5.2-RELEASE. En el momento actual, el plan es que 5.3-RELEASE sea la a-ser-creada rama 5-STABLE, aunque eso podría cambiar. Todo depende del estado del árbol.

Se habrá dado cuenta, por supuesto, que a pesar de que 4.x o 4-STABLE sigan siendo (por el momento) la línea de producción, la rama 3-STABLE todavía existe (aunque no se ha hecho ningún cambio en mucho tiempo). Así como 2.2-STABLE y 2.1-STABLE también existen todavía, aunque no han conseguido ningún cambio en mucho más tiempo. Convencionalmente, STABLE sin ningún número, se refiere a la última rama STABLE. Realmente, la única posibilidad de que haya alguna confusión es cuando una nueva rama se acaba de crear, por lo que una gran cantidad de personas están todavía en la vieja. Entonces puede utilizar el número para que sea inequívoco.

También tenga en cuenta que 5.1-RELEASE salió antes que 4.9-RELEASE. Y 5.0-RELEASE antes 4.8-RELEASE. Cuando una rama está en sus últimos días y otra rama se encuentra en sus primeros días, las cosas se ponen realmente confusas. Es entonces cuando las diferencias de CURRENT y STABLE se notan. Para hacer una analogía muy burda, 5-CURRENT es como Linux 2.5, mientras que 4-STABLE es como Linux 2.4. Pero, antes de eso, 4-CURRENT era como Linux 2.3, y en el futuro, 5-STABLE será como Linux 2.6. Por supuesto no es una analogía perfecta, en parte porque estamos hablando del sistema completo con todas sus piezas, no sólo el núcleo. Pero está lo suficientemente cerca como para que se pueda hacer una idea.

Así que, ¿qué quiere decir todo esto? No mucho, tal vez. Pero, con esto, tal vez puedas obtener una mejor idea de qué es lo que sucede y cuando, y de lo que significan los nombres de las ramas y los números de las versiones.

Más información sobre CURRENT frente a STABLE está disponible en el manual de FreeBSD
También hay un artículo en la documentación oficial sobre el proceso de desarrollo de las versiones

Ver también:
BSD frente a Linux 1
BSD frente a Linux 2
BSD frente a Linux 3
BSD frente a Linux 4

Anuncios

Responder

Introduce tus datos o haz clic en un icono para iniciar sesión:

Logo de WordPress.com

Estás comentando usando tu cuenta de WordPress.com. Cerrar sesión / Cambiar )

Imagen de Twitter

Estás comentando usando tu cuenta de Twitter. Cerrar sesión / Cambiar )

Foto de Facebook

Estás comentando usando tu cuenta de Facebook. Cerrar sesión / Cambiar )

Google+ photo

Estás comentando usando tu cuenta de Google+. Cerrar sesión / Cambiar )

Conectando a %s