El modelo de lanzamiento estable del kernel de Linux comenzó en 2005, cuando se determinó que que el modelo de desarrollo de kernel existente (una versión nueva cada 2 o 3 meses) se no satisfacía las necesidades de la mayoría de los usuarios. Los usuarios querían que se realizaran correcciones de errores durante esos 2 o 3. y a las distribuciones de Linux les resultaba difícil mantener los kernels actualizados. sin comentarios de la comunidad de kernel. En general, los intentos de mantener kernels individuales seguros y con las últimas correcciones de errores era una tarea grande y confusa esfuerzo de muchas personas diferentes.
Las versiones estables de kernel se basan directamente en Linus Torvalds. lanzamientos y son se publican aproximadamente cada semana, según diversos factores externos (época del año, parches disponibles, carga de trabajo del encargado de mantenimiento, etcétera). La numeración del establo versiones comienza con el número de la versión de kernel y una cantidad adicional se agrega al final. Por ejemplo, Linus lanza el kernel 4.4. entonces las versiones de kernel estables basadas en este kernel están numeradas 4.4.1, 4.4.2, 4.4.3, etc. Esta secuencia generalmente se acorta con el número 4.4.y cuando en referencia a un árbol de versiones de kernel estable. Cada árbol de versión de kernel estable mantenido por un solo desarrollador de kernel, quien es responsable de elegir la los parches necesarios para el lanzamiento y la administración del proceso de revisión/lanzamiento.
Los kernels estables se mantienen durante el transcurso del ciclo de desarrollo actual. Después de que Linus lanza un nuevo kernel, el árbol de versiones estables anterior se y los usuarios deben pasar al kernel más reciente.
Kernels estables a largo plazo
Después de un año de este nuevo proceso de lanzamiento estable, se determinó que diferentes usuarios de Linux querían que un kernel fuera compatible con más de un unos meses. En respuesta, la versión de kernel con asistencia a largo plazo (LTS) se con el primer kernel LTS (2.6.16), lanzado en 2006. A partir de entonces, un nuevo El kernel de LTS se seleccionó una vez al año, y la comunidad del kernel mantiene que kernel por un mínimo de 2 años.
Al momento de la redacción de este documento, los kernels de LTS son los kernels 4.4.y, 4.9.y, 4.14.y y Versiones 4.19.y, 5.4.y y 5.10.y Todas las semanas se lanza un nuevo kernel. Debido a las necesidades de algunos usuarios y distribuciones, se introducen algunos kernels más antiguos y que los desarrolladores de kernel en un ciclo de lanzamiento más lento. Información sobre todos los kernels estables a largo plazo, quién está a cargo de ellos y durante cuánto tiempo se encuentran en la kernel.org de versiones.
El kernel de LTS lanza en promedio entre 6 y 8 parches aceptados por día, mientras que la carga normal y las versiones estables de kernel contienen entre 10 y 15 parches por día. La cantidad de parches varía por versión según el tiempo actual del desarrollo correspondiente versión de kernel y otras variables externas. Cuanto más antiguo sea un kernel de LTS, se aplican menos parches, ya que muchas correcciones de errores recientes no son relevantes para kernels más antiguos. Sin embargo, cuanto más antiguo sea un kernel, más difícil será implementar portabilidad a versiones anteriores del kernel los cambios necesarios que se deben aplicar debido a los cambios en la base de código. De esta manera, si bien puede haber un menor número de parches generales aplicado, el esfuerzo involucradas en el mantenimiento de un kernel LTS es superior a mantener la normalidad kernel estable.
Reglas de parches de kernel estables
Se mantuvieron las reglas sobre lo que se puede agregar a una versión de kernel estable casi idénticos desde su introducción y se resumen a continuación:
- Obviamente, debe ser correcto y estar probado.
- No debe tener más de 100 líneas.
- Se debe corregir solo un aspecto.
- Debes corregir algún problema que se haya informado.
- Puede ser un nuevo ID de dispositivo o novedad para el hardware, pero no puede agregar nuevos atributos funcionalidad.
- Ya se debe combinar con los de Linus Torvalds de imágenes.
La última regla: "Ya se debe combinar con Linus Torvalds". árbol", evita a la comunidad de kernel para que no pierdan correcciones. La comunidad nunca quiere una solución en una versión de kernel estable que aún no esté en Linus Torvalds árbol, así que que quienes actualicen nunca verán una regresión. Esto evita que muchas problemas que otros proyectos que mantienen una rama estable y de desarrollo pueden tener.
Actualizaciones del kernel
La comunidad del kernel de Linux prometió a sus usuarios que no debían actualizar nunca rompe algo que funciona en una versión anterior. Que prometedor sigue vigente en la actualidad. Las regresiones sí ocurren, pero esas son las más los errores de prioridad y se corrigen con rapidez, o el cambio que causó la del kernel de Linux se revierte con rapidez.
Esta promesa se aplica tanto a las actualizaciones de kernel estables incrementales como a así como las principales actualizaciones que ocurren cada tres meses. Sin embargo, el la comunidad de kernel solo puede hacer esta promesa para el código que se fusiona en el Árbol del kernel de Linux. Cualquier código que se fusione en el kernel de un dispositivo que no esté en las versiones de kernel.org son desconocidas las interacciones con él nunca se pueden planificar ni considerar.
Los dispositivos basados en Linux que tienen grandes conjuntos de parches pueden tener grandes problemas cuando a kernels más nuevos debido a la gran cantidad de cambios entre cada lanzamiento (de 10 a 14,000 cambios por versión). Los conjuntos de parches de SoC son conocidos tener problemas con la actualización a kernels más nuevos debido a su gran tamaño y su tamaño Modificación del código de kernel específico de la arquitectura y, a veces, principal. Como Como resultado, la mayoría de los proveedores de SoC están empezando a estandarizar el uso de las versiones LTS para sus dispositivos, lo que les permite recibir actualizaciones de errores y seguridad directamente desde la comunidad del kernel de Linux.
Seguridad
Cuando se hacen versiones de kernel, la comunidad de kernel de Linux casi nunca declara cambios específicos como correcciones de seguridad. Esto se debe al problema básico de la dificultad para determinar si una corrección de errores es una corrección de seguridad o no en ese momento de la creación. Además, muchas correcciones de errores solo están relacionadas con la seguridad después de mucho tiempo, por lo que la comunidad de kernel siempre recomienda y realizaremos todas las correcciones de errores publicadas.
Cuando los problemas de seguridad se informan a la comunidad de kernel, se corrigen como lo antes posible y se envía públicamente al árbol de desarrollo y al versiones estables. Como se describió anteriormente, los cambios casi nunca se describen como una "corrección de seguridad", sino que se parece a cualquier otra corrección de errores del kernel. Este es para que las partes afectadas puedan actualizar sus sistemas antes de la el informante del problema lo anuncia.
Para obtener detalles sobre cómo informar errores de seguridad a la comunidad de kernel para obtener y solucionarlos lo antes posible, consulta Errores de seguridad en la Guía del usuario y del administrador del kernel de Linux, en www.kernel.org
Debido a que el equipo de kernel no anuncia los errores de seguridad al público, CVE Los números de problemas relacionados con el kernel de Linux suelen publicarse semanas, meses y años después de que la solución se combinó con el modelo estable y de desarrollo, ramas.
Mantén un sistema seguro
Cuando se implementa un dispositivo que usa Linux, recomendamos que El fabricante toma las actualizaciones del kernel de LTS y las envía a sus usuarios. después de una prueba adecuada muestra que la actualización funciona bien. Este cambio tiene varias ventajas, por ejemplo:
- Los desarrolladores de kernel revisaron las versiones en su conjunto, no en piezas individuales.
- Es difícil determinar qué parches solucionan el problema de "seguridad" problemas y cuáles no. Casi todas las versiones LTS contienen al menos un solución de seguridad y muchas aún son “desconocidas”.
- Si las pruebas muestran un problema, la comunidad de desarrolladores de kernel reacciona. rápido para resolver el problema.
- Los intentos de filtrar solo los cambios que ejecutas dan como resultado un kernel. que es imposible de combinar correctamente con versiones ascendentes en el futuro.