LinuxParty

BILBAO, España: En la  Open Source Summit Europe , Jonathan Corbet, desarrollador del kernel de Linux y editor ejecutivo de Linux Weekly News , habló con todos sobre las novedades del Kernel de Linux y hacia dónde se dirige a partir de ahora. 

Aquí hay un cambio importante que se avecina: el soporte a largo plazo (LTS) para los kernels de Linux se reducirá de seis a dos años.

Actualmente, hay seis kernels LTS de Linux  : 6.1, 5.15, 5.10, 5.4, 4.19 y 4.14. Según el proceso hasta la fecha, la versión 4.14 se implementaría en enero de 2024 y se agregaría otro kernel. Sin embargo, en el futuro, cuando el kernel 4.14 y los dos siguientes dejen de funcionar, no serán reemplazados.

¿Por qué? Sencillo, explicó Corbet: "Realmente no tiene sentido mantenerlo durante tanto tiempo porque la gente no los usa". Estoy de acuerdo. Si bien estoy seguro de que alguien todavía está ejecutando 4.14 en un sistema Linux de producción, no puede haber muchos. 

Otra razón, y un problema mucho mayor que simplemente mantener LTS, según Corbet, es que los encargados del mantenimiento del código Linux se están agotando. No es que los desarrolladores sean un problema. Los últimos lanzamientos de Linux han involucrado un promedio de más de 2.000 programadores, incluidos unos 200 nuevos desarrolladores que se incorporaron, trabajando en cada lanzamiento. Sin embargo, los mantenedores (las personas que verifican el código para ver si encaja y funciona correctamente) son otra cuestión.

Los mantenedores enfrentan numerosos obstáculos para realizar su trabajo. Obstáculo uno: a muchos mantenedores no se les paga por mantener. Mantienen código además de sus trabajos diarios. Además de eso, enfrentan demandas cada vez mayores de su tiempo, debido a la falta de personal y al uso de fuzzers para encontrar errores. Si bien los fuzzers son útiles, también descubren demasiados errores menores, cada uno de los cuales debe ser examinado y luego descartado por los encargados de mantenimiento.

¿El resultado? Para citar a Josef Bacik, desarrollador y mantenedor del sistema de archivos del kernel de Linux: "Los mantenedores se están agotando [porque] los mantenedores no escalan". Darrick Wong, otro mantenedor senior del kernel de Linux, añadió: "Esto no puede soportarse. Necesitamos ayuda".

¿Cómo pueden obtener ayuda? Bueno, por un lado, Corbet sugiere que los mantenedores hablen con sus empleadores sobre cómo pagarles por su trabajo de mantenimiento. Como observó Wong, "la mayoría de mis amigos trabajan para pequeñas empresas, organizaciones sin fines de lucro y gobiernos locales. Informan de los mismos problemas de exceso de trabajo, miedo generalizado e ira, y luchan por comprender y adaptarse a las nuevas ideas que observo aquí. Ven "La conexión directa entre la falta de ingresos y recursos de su organización. No entienden por qué diablos nos pasa lo mismo a mí y a mis asociados de proximidad en el lugar de trabajo cuando todos trabajamos para empresas que ganan cientos de miles de millones de dólares".

Buena pregunta. Las empresas deben darse cuenta de que necesitan retribuir a Linux si quieren seguir cosechando sus beneficios.

Un problema relacionado:  Linux ahora está adoptando Rust como experimento. Si bien son buenas noticias en muchos sentidos (Rust elimina clases enteras de errores a los que es vulnerable el lenguaje principal de Linux, C), también plantea problemas para los mantenedores. Después de todo, si un mantenedor ha pasado 30 años trabajando en C, pedirle que se convierta en un experto en Rust es una gran tarea. 

Además, Rust sigue evolucionando. Se necesitan muchos parches de Rust para que el lenguaje funcione correctamente en un nivel profundo en Linux. Eso también significa que necesita mucho código adhesivo para que Rust y Linux funcionen bien juntos. 

Luego hay algunos desarrolladores del kernel de Linux a quienes no les gusta Rust. Como dijo alguien: "Posiblemente hay algunas partes [de Linux] bien diseñadas y escritas que no han sufrido problemas de seguridad de memoria en muchos años. Es insultante presentar esto como una mejora con respecto a lo logrado por quienes hicieron todo este arduo trabajo. "

Aun así, Corbet cree que el punto de decisión (si Rust se convierte en una parte principal del núcleo) llegará pronto. Ese día llegará, señaló, "cuando fusionemos la primera característica de la que dependen los usuarios".

Ese día está cerca: tres nuevas e importantes adiciones basadas en Rust al código del kernel de Linux están en camino, dijo Corbet. Se trata de una implementación de PuzzleFS , un servidor de sistema de archivos Plan9 de lectura/escritura; y, el que ocupará los titulares más importantes, el controlador de GPU Apple M1. De hecho, los primeros controladores Linux OpenGL ES 3.1 ya están disponibles para las GPU de las familias M1 y M2 de Apple y llegaron a finales de agosto de 2023. Con un trabajo como este en marcha, Corbett se sorprendería mucho si Rust no lo hiciera de forma permanente. en Linux.

Otro tema en las noticias últimamente es cómo los ajustes de Red Hat a su licencia Red Hat Enterprise Linux (RHEL) han provocado que Oracle, SUSE y CIQ fork RHEL con la Open Enterprise Linux Association (OpenELA) . Dejando de lado las complicaciones comerciales y de licencia que llevaron a esta pelea, también existen preocupaciones sobre el kernel de Linux. 

Estas preocupaciones giran en torno a la pregunta: ¿Qué kernel debería utilizar para su distribución de Linux? Hay dos opciones reales: 1) Ejecutar el último kernel estable o 2) Ejecutar un kernel antiguo más correcciones respaldadas. Esto último es lo que tienden a hacer Red Hat y otros distribuidores empresariales de Linux. 

Esto último también da lugar a núcleos específicos del proveedor. Y si bien esto ofrece estabilidad, distancia a estas distribuciones del soporte de la comunidad y las hace dependientes de proveedores específicos. Es esta última consecuencia, que primero causó que AlmaLinux y Rocky Linux comenzaran sus propias versiones de CentOS  (el clon RHEL gratuito de Red Hat) después de que Red Hat cerrara CentOS en favor de CentOS Stream  , la que desató el fuego entre Red Hat y OpenELA. Lo que OpenELA quiere es un clon de RHEL, que utiliza el kernel parcheado más antiguo de RHEL. Estén atentos a más novedades a medida que este conflicto continúa ardiendo.

Por otro lado, señaló Corbet, Android "ha estado presionando mucho hacia esta imagen genérica del kernel y la ha estado basando en actualizaciones estables. Esto se debe a que han descubierto que esto ayuda a mejorar la seguridad de Android. Han descubierto que la gran mayoría de las funciones de seguridad Los problemas se revelan en el kernel e incluso se solucionan en los kernels de Android antes de que se revelen porque ya se incorporaron antes de que nadie supiera que en realidad eran errores relacionados con la seguridad".

Ésa es otra cuestión más de la que los desarrolladores del kernel de Linux son dolorosamente conscientes. Como explicó Corbet:

"Uno de los aspectos interesantes del desarrollo del kernel es que casi cualquier cosa puede ser un error de seguridad. Y no se sabe realmente si lo es hasta que alguien encuentra una manera de explotarlo de alguna manera. Así que se introducen un montón de correcciones y se solucionan". No están marcados como correcciones de seguridad. No porque la comunidad del kernel esté tratando de ocultar correcciones de seguridad. Quiero decir, a veces hay un poco de astucia que ocurre allí y que personalmente no me gusta. Pero la mayoría de las veces, realmente "Es sólo que nadie sabe que este error es un error de seguridad. Sólo más tarde alguien se da cuenta. Por lo tanto, la única manera de protegerse contra este tipo de errores es implementar todas las correcciones".

Es por eso que Corbet, y cualquiera que realmente conozca Linux, recomienda que si está creando una distribución de Linux, siempre incluya todos los parches. Para kernels más antiguos, como 4.14, eso puede ser hasta 26,799 confirmaciones. Pero, si intenta elegir qué parches usar, seguramente abrirá las puertas a agujeros de seguridad.

Finalmente, Corbet señaló que Scott McNealy, ex director ejecutivo de Sun durante mucho tiempo, dijo una vez: "El código abierto es libre como un cachorro es libre". McNealy tenía razón. Usar código abierto y Linux es fácil. Pagar por la capacitación que necesita para no ensuciar el piso de la cocina, eso es más difícil.