Barrapunto

Los sistemas BSD sacan una versión estable cada 6 meses. Al generar un ciclo de lanzamientos fijo es mucho más fácil planificar la estabilización de aplicaciones, la actualización de sistemas, ...

Usando este ejemplo, se puede generar un ciclo de lanzamientos estricto, con lo que se puede saber cuando de "congela" la distribución, y sobre todo se puede saber cuando dispondremos de una nueva.
Esto tiene el inconveniente de la flexibilidad y crea la "necesidad" de nuevos lanzamientos.

Otra de las características interesantes de "los primos" BSD es la diferenciación entre el sistema (¿core?) y los ports. El sistema es el kernel y todo lo asociado al mismo, instaladores, shells, utilidades del sistema. Los "ports" son las aplicaciones que se pueden instalar sobre dicho sistema, pudiendose independizar una cosa con la otra.

Con toda esta chapa intento mostrar la necesidad de aprender y acercarnos a "nuestros primos" para que se conviertan en "nuestros hermanos", aprendiendo de su experiencia y buen hacer (me doy hasco de lo cursi que puedo llegar a ser).

---
Por un diálogo de verdad entre BSD y Linux

¿Diferenciar los ports de la base del sistema no hace que los ports puedan ser inestables?

Quiero decir, que si los ports van por libre ¿Cómo se sabe que el conjunto de sistema base más ports es estable y se comporta bien en conjunto?

Puede que los ports que se "congelaron" cuando salió la estable seis meses después no sean igual de estables y si los instalas rompas algo. ¿No sería algo parecido a usar una base de Woody y la rama no oficial backports.org?

Cada sistema tiene sus bondades e inconvenientes, pero en estos momentos parece que funciona mejor el sistema de los BSD's (que yo sepa FreeBSD también saca versiones cada seis meses, más o menos), que el sistema de una versión "cuando se acabe"

Respecto a los ports, el tener separado el núcleo del sistema de las aplicaciones propicia escenarios mucho más amplios. Podemos "estabilizar" cada parte por su lado, realizando lanzamientos conforme a las necesidades y sin que una parte del proyecto paralice TODO.

Imaginemos que tenemos una versión del core cada seis meses, una versión de los servicios "de servidor" cada el mismo tiempo y una versión de los servicios de escritorio cada tres, cada una con sus lanzamientos y parches de seguridad. Con esto conseguiriamos mayor flexibilidad, con escaso impacto negativo.