439 lines
15 KiB
XML
439 lines
15 KiB
XML
<?xml version="1.0" encoding="iso-8859-1" standalone="no"?>
|
|
<!DOCTYPE article PUBLIC "-//FreeBSD//DTD DocBook XML V4.2-Based Extension//EN"
|
|
"../../../share/sgml/freebsd42.dtd" [
|
|
<!ENTITY % entities PUBLIC "-//FreeBSD//ENTITIES DocBook FreeBSD Entity Set//ES" "../../share/sgml/entities.ent">
|
|
%entities;
|
|
]>
|
|
|
|
<!-- The FreeBSD Spanish Documentation Project
|
|
Original Revision: r1.11 -->
|
|
|
|
<article lang='es'>
|
|
<title>Cómo elegir la versión apropriada de &os;</title>
|
|
|
|
<articleinfo>
|
|
<authorgroup>
|
|
<author>
|
|
<surname>El Proyecto de Documentación de &os;</surname>
|
|
</author>
|
|
</authorgroup>
|
|
|
|
<legalnotice id="trademarks" role="trademarks">
|
|
&tm-attrib.freebsd;
|
|
</legalnotice>
|
|
|
|
<copyright>
|
|
<year>2005</year>
|
|
<holder>El Proyecto de Documentación de &os;</holder>
|
|
</copyright>
|
|
|
|
<pubdate>$FreeBSD$</pubdate>
|
|
|
|
<releaseinfo>$FreeBSD$</releaseinfo>
|
|
|
|
<abstract>
|
|
<para>Así que ha decidido instalar &os;. ¡Bienvenido!
|
|
el propósito de este documento es ayudarle seleccionar la
|
|
versión apropriada.</para>
|
|
|
|
&trans.es.gabor;
|
|
|
|
</abstract>
|
|
</articleinfo>
|
|
|
|
<sect1 id="background">
|
|
<title>Introducción</title>
|
|
|
|
<para>Antes de decidir cuál de las versiones de &os; quiere
|
|
usar es importante que comprenda los conceptos relacionados con
|
|
el desarrollo y el proceso de Ingeniería de Releases
|
|
(<literal>RE</literal>).</para>
|
|
|
|
<para>&os; se desarrolla gracias a un gran grupo de gente,
|
|
casi siempre voluntarios. El código fuente del kernel, de las
|
|
utilidades y de las bibliotecas más
|
|
comúnes están en un <firstterm>sistema de
|
|
gestión de código</firstterm> del cual es posible
|
|
descargarlo en cualquier momento. Aparte de esto, existen versiones
|
|
(<literal>binarias</literal>) ya compiladas que se liberan
|
|
cada poco tiempo. Una de estas versiones binarias cuidadosamente
|
|
revisada será en su momento declarada
|
|
<firstterm>releases</firstterm>.</para>
|
|
|
|
<sect2 id="releases">
|
|
<title>Releases</title>
|
|
|
|
<para>El nombre de las <literal>releases</literal> contiene un
|
|
<firstterm>número mayor de release</firstterm> y un
|
|
<firstterm>número menor de release</firstterm>.</para>
|
|
|
|
<itemizedlist>
|
|
<listitem>
|
|
<para>El propósito de una release mayor es incluir
|
|
nuevas funciones. Es inevitable que, al añadir
|
|
nuevas funciones a &os; o al quitarlas, sea necesario algunas
|
|
veces perder la compatibilidad con versiones anteriores del
|
|
sistema operativo.</para>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para>El propósito de una release menor es ante todo
|
|
corregir errores y mejorar el rendimiento y la estabilidad.
|
|
Es importante mantener la compatibilidad entre releases menores
|
|
tanto cuando se trata de código como con los programas
|
|
ejecutables. Si se da la ocasión, se añaden nuevas
|
|
características a una release menor si estos principios
|
|
se mantienen.</para>
|
|
</listitem>
|
|
</itemizedlist>
|
|
|
|
<para>No obstante, tenga en cuenta que una <quote>release</quote>
|
|
es solamente una instantánea del árbol de
|
|
código en un momento dado, gracias a lo cual se le da
|
|
una etiqueta o <emphasis>tag</emphasis>. Por ejemplo, la
|
|
etiqueta que el grupo de ingeniería de releases dio a la
|
|
release 5.4 fue <literal>RELENG_5_4_0_RELEASE</literal>. El
|
|
desarrollo tiene lugar bajo la etiqueta
|
|
<literal>HEAD</literal>.</para>
|
|
</sect2>
|
|
|
|
<sect2 id="branches">
|
|
<title>Bifurcaciones</title>
|
|
|
|
<para>En el tiempo de sacar cada release, se crea una
|
|
<firstterm>rama</firstterm>, por ejemplo
|
|
<literal>RELENG_5_4</literal>. Aunque el código bajo
|
|
<literal>RELENG_5_4_0_RELEASE</literal> no cambien,
|
|
los que están bajo <literal>RELENG_5_4</literal>
|
|
sí, al aplicar cambios en <literal>HEAD</literal>
|
|
al corregir problemas de seguridad u otro tipo de fallo.</para>
|
|
</sect2>
|
|
|
|
<sect2 id="stable-vs-current">
|
|
<title><firstterm>STABLE</firstterm> y
|
|
<firstterm>CURRENT</firstterm></title>
|
|
|
|
<para>Durante la vida de cada release mayor una rama
|
|
individual puede convertirse en <literal>STABLE</literal>. Esto
|
|
indica que el Proyecto &os; cree que la rama ha
|
|
demostrado suficiente calidad para que la mayoría de los
|
|
usuarios puedan usarla. Las ramas que necesitan más
|
|
pruebas antes de que pueda usarlas cualquiera reciben el nombre
|
|
de <literal>CURRENT</literal>.</para>
|
|
|
|
<note><para>El Proyecto &os; no puede garantizar que el software
|
|
que se distribuye sea todo lo <emphasis>estable</emphasis>
|
|
que sea necesario para cualquier necesidad o uso. Es el usuario
|
|
quien tiene la última palabra sobre esto. Por favor,
|
|
tenga muy en cuenta que el proyecto lo forman voluntarios y no
|
|
puede ofrecer ningún tipo de garantía.</para></note>
|
|
</sect2>
|
|
|
|
<sect2 id="ports-vs-packages">
|
|
<title><firstterm>Ports</firstterm> y
|
|
<firstterm>packages</firstterm></title>
|
|
|
|
<para>Aparte de los ficheros que se distribuyen del modo ya descrito
|
|
antes, &os; permite el uso de miles de aplicaciones fruto del
|
|
trabajo de desarrolladores que no forman parte del proyecto.
|
|
Podemos citar como ejemplos sistemas de ventanas, navegadores web,
|
|
programas de correo electrónico, software ofimático,
|
|
etc.) El proyecto en sí no desarrolla estos programas,
|
|
solamente el <quote>framework</quote> que permite que éstos
|
|
puedan instalarse; este <quote>framework</quote> recibe el
|
|
nombre de <firstterm>Colección de Ports</firstterm>).
|
|
Se pueden instalar aplicaciones desde el código fuente si su
|
|
licencia permite este tipo de redistribución; es lo que en
|
|
&os; se llaman los <emphasis>ports</emphasis>)), o como software
|
|
compilado si está permitido distribuirlos como tal, en cuyo
|
|
caso reciben el nombre de <emphasis>packages</emphasis>.</para>
|
|
</sect2>
|
|
</sect1>
|
|
|
|
<sect1 id="past-schedules">
|
|
<title>El calendario de releases anteriores</title>
|
|
|
|
<para>Durante el desarrollo de la release 5.X de &os; hubo que aprender
|
|
en carne propia muchas lecciones que solamente pudieron verse con
|
|
posterioridad. Los objetivos de la serie 5.X fueron muy
|
|
ambiciosos. Veamos algunos:</para>
|
|
|
|
<itemizedlist>
|
|
<listitem>
|
|
<para>Ofrecer soporte para máquinas dotadas de
|
|
multiproceso simétrico (Symmetric MultiProcessing,
|
|
o SMP)</para>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para>Mejoras del rendimiento gracias a la adopción
|
|
de una nueva estrategia de gestión de recursos en el
|
|
kernel</para>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para>Añadir numerosas arquitecturas de procesador</para>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para>Introducción de un nuevo modelo de
|
|
<quote>threading</quote></para>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para>Introducción de un nuevo
|
|
<quote>scheduler</quote></para>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para>Añadir soporte de nuevas tecnologías como
|
|
la gestión de energía (especialmente importante en
|
|
máquinas portátiles), y sobre todo</para>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para>no declarar ninguna versión como
|
|
<literal>STABLE</literal> hasta que estas tareas no se
|
|
hubieran terminado</para>
|
|
</listitem>
|
|
</itemizedlist>
|
|
|
|
<para>Esto llevó al problema de que había varios
|
|
años de diferencia entre el momento en el que 4.X
|
|
se declaró <literal>STABLE</literal> y el momento en el que
|
|
5.X se llegó a <literal>STABLE</literal>. Esta circunstancia
|
|
tuvo diversos efectos no deseados:</para>
|
|
|
|
<itemizedlist>
|
|
<listitem>
|
|
<para>El número funciones cambiadas simultáneamente
|
|
hizo muy difícil aislar esos cambios para hacerlos
|
|
compatibles con las versiones anteriores a la creació de
|
|
la rama <literal>STABLE</literal>.</para>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para>Eso significó que los usuarios que necesitaban
|
|
imperiosamente una nueva función en particular
|
|
(por ejemplo el poder ejecutar &os; en hardware moderno)
|
|
estaban obligados a usar (por ejemplo) &os; 5.2.1 a pesar de
|
|
que oficialmente era una release de uso exclusivo de
|
|
desarrolladores, y sin tener en cuenta el hecho de que una
|
|
release <literal>CURRENT</literal> no cumplía sus
|
|
demandas.</para>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para>En los casos en los que se consiguió la compatibilidad
|
|
con versiones anteriores los desarrolladores se encontraron con otro
|
|
problema al intentar adaptar ciertas características a una
|
|
versión que ellos mismos hacía tiempo que no usaban
|
|
como su plataforma de desarrollo principal.</para>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para>El retraso también provocó que cuando 5.3 se
|
|
declaró nueva release <literal>STABLE</literal> la
|
|
cantidad acumulada de cambios hizo la actualización
|
|
complicada.</para>
|
|
</listitem>
|
|
</itemizedlist>
|
|
|
|
<para>A decir verdad, nadie estaba contento con el resultado.</para>
|
|
|
|
<para>Las lecciones que se aprendieron de todo esto fueron:</para>
|
|
|
|
<itemizedlist>
|
|
<listitem>
|
|
<para>Las nuevas releases mayores deben tener meno cambios
|
|
estructurales importantes y deben publicarse con mayor
|
|
frecuencia.</para>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para>Siempre que sea posible los cambios estructurales deben
|
|
aislarse unos de otros. Esto obliga a que parte del
|
|
desarrollo tengan lugar fuera del árbol principal
|
|
y que se integren solamente cuando no afecten a otros
|
|
procesos simultáneos de desarrollo.</para>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para>Las releases mayores deben tener fecha de salida
|
|
propia no dependiente de la fecha de entrega asignada
|
|
a un cambio estructural. Si un cambio estructural no
|
|
está listo a tiempo se incluirá desactivado
|
|
por omisión y será incluido en la siguiente
|
|
release.</para>
|
|
</listitem>
|
|
</itemizedlist>
|
|
|
|
<para>Al publicar grupos de cambios más pequeños y
|
|
de una forma más habitual se intenta también dedicar
|
|
menos tiempo y esfuerzo aplicando nuevas características de
|
|
<literal>HEAD</literal> a a la última versión
|
|
<literal>STABLE</literal> (y poder así usar dichas
|
|
nuevas características en más de una versión
|
|
mayor); aún más, al estar los cambios más
|
|
aislados el riesgo de provocar nuevos problemas de seguridad es
|
|
mucho menor.</para>
|
|
|
|
<para>Además, el concentrarse en una fecha y no en la
|
|
consecución de una característica lista para
|
|
integrarse en el sistema, es más fácil planificar
|
|
para el futuro tanto para los usuarios como a los desarrolladores
|
|
de aplicaciones ajenas al proyecto y, cómo no, para los
|
|
desarrolladores de &os;.</para>
|
|
|
|
<para>Estas razones (y no el intentar ir a la par de las versiones
|
|
mayores de otro sistema operativo) son el principal motivo del
|
|
cambio en el calendario de liberación de versiones de
|
|
&os;.</para>
|
|
</sect1>
|
|
|
|
<sect1 id="future-goals">
|
|
<title>Calendario de releases de aquí en adelante</title>
|
|
|
|
<para>Estos son los objetivos actuales del calendario del
|
|
Proyecto:</para>
|
|
|
|
<itemizedlist>
|
|
<listitem>
|
|
<para>Sacar uan release mayor cada 18 meses</para>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para>Sacar una release menor cada 4 meses</para>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para>Ofrecer paquetes compilados para la release menor más
|
|
reciente de cada release mayor</para>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para>Ofrecer actualizaciones de seguridad y otras correcciones de
|
|
fallos críticos para las versiones menores más
|
|
recientes de cada versión mayor (que reciben el nombre
|
|
de <firstterm>ramas de seguridad</firstterm>).</para>
|
|
</listitem>
|
|
</itemizedlist>
|
|
|
|
<para>Dado el gran número de combinaciones de versiones
|
|
instalables no es posible dar soporte a todas las releases.
|
|
Esto es, en parte, debido a la cantidad limitada de máquinas
|
|
de las que el Proyecto puede disponer, pero sobre todo a que
|
|
la cantidad de voluntarios disponibles es limitada y su tiempo
|
|
también.</para>
|
|
|
|
<para>Si quiere leer más sobre esto visite</para>
|
|
|
|
<variablelist>
|
|
<varlistentry>
|
|
<term><ulink url="&url.base;/releng/index.html#schedule"></ulink></term>
|
|
<listitem>
|
|
<para>Calendario de ingeniería de releases</para>
|
|
</listitem>
|
|
</varlistentry>
|
|
|
|
<varlistentry>
|
|
<term><ulink url="&url.base;/security/security.html#supported-branches"></ulink></term>
|
|
<listitem>
|
|
<para>Calendario de ramas de seguridad</para>
|
|
</listitem>
|
|
</varlistentry>
|
|
</variablelist>
|
|
|
|
<para>Estos documentos profundizan en los porqués de las
|
|
decisiones tomadas sobre las ramas soportadas y el ciclo de vida
|
|
de cada rama.</para>
|
|
</sect1>
|
|
|
|
<sect1 id="decision-points">
|
|
<title>?Cómo afectan estos factores a su decisión?</title>
|
|
|
|
<para>Los principales factores que influyen en su decisión de
|
|
qué versión instalar son, entre otros:</para>
|
|
|
|
<itemizedlist>
|
|
<listitem>
|
|
<para>?Qué grado de estabilidad necesita su
|
|
sistema?</para>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para>?Cuántos trabajo quiere dedicar a la
|
|
actualización?</para>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para>?Durante cuánto tiempo va a usar una
|
|
versión dada entre una actualización y la
|
|
que venga más adelante?</para>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para>?Cuánta importancia le da a la seguridad de su
|
|
sistema?</para>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para>?Instalará desde código fuente o
|
|
binarios?</para>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para>?Va a participar en el desarrollo de &os;?</para>
|
|
</listitem>
|
|
</itemizedlist>
|
|
|
|
<para>Aquí hay unas normas para ayudarle a tomar una
|
|
decisión:</para>
|
|
|
|
<itemizedlist>
|
|
<listitem>
|
|
<para>Si sus necesidades son a corto plazo y quiere disfrutar del
|
|
más alto grado posible de estabilidad (y no puede
|
|
dedicar muchos recursos a la actualización) probablemente
|
|
lo mejor sea instalar la release <literal>STABLE</literal>
|
|
más reciente y dejarla como está. Según
|
|
sean sus requisitos de seguridad puede o no aplicar los
|
|
parches de seguridad que vayan apareciendo.</para>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para>Si sus necesidades son a corto plazo y las nuevas
|
|
características o la seguridad son muy
|
|
importantes para usted (y está dispuesto a dedicar
|
|
tiempo a las actualizaciones) debería seguir la
|
|
rama <literal>STABLE</literal> más reciente.</para>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para>Si no va a poner la máquina en producción,
|
|
va a dedicar tiempo a depurar unos cuantos problemas y en
|
|
unos cuantos meses va a salir una nueva versión mayor,
|
|
puede instalar esa rama y ayudar al Proyecto haciendo pruebas
|
|
para hacer el sistema más estable y disponer de la
|
|
mejor release posible a medio y largo plazo.</para>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para>Sólamente si quiere instalar desde código
|
|
fuente y pasar tiempo depurando problemas del sistema base,
|
|
enviar informes de fallos y utilizar las listas de correo
|
|
dedicadas a esos fallos debe usar
|
|
<literal>HEAD</literal>.</para>
|
|
</listitem>
|
|
</itemizedlist>
|
|
</sect1>
|
|
|
|
<sect1 id="conclusion">
|
|
<title>Conclusión</title>
|
|
|
|
<para>Esperamos que este artículo haya servido de ayuda
|
|
para que comprender el modelo de desarrollo de &os; y
|
|
pueda decidir qué versión se ajusta más a sus
|
|
necesidades.</para>
|
|
</sect1>
|
|
</article>
|