Rust en Linux: una herramienta poderosa (¿pero cómo logramos el equilibrio adecuado?)

El acalorado debate sobre la inclusión de Rust en el núcleo de Linux ha estado en curso durante bastante tiempo en la comunidad de hackers. La mayoría de nosotros reconocemos tanto el revuelo como las dudas al respecto. Hasta ahora, la mayoría de las discusiones se han centrado en cuestiones inmediatas, como los beneficios de seguridad de Rust y los desafíos de integrarlo en el ecosistema existente basado en C. Ahora que Linus Torvalds está de acuerdo con esta idea , Rust ya ha comenzado a abrirse camino en el código fuente de nuestro amado sistema operativo.

Por lo tanto, la verdadera pregunta no es si se debe usar Rust en el núcleo de Linux, sino cómo hacerlo . Después de todo, Rust no es solo otro lenguaje de programación; también es una filosofía de diseño en toda regla. No es una actualización de C con menos errores de corrupción de memoria, sino un sistema de escritura de código que fuerza un conjunto de reglas estrictas, evitando así muchos errores potenciales. Creo que este es el aspecto clave que debemos tener en cuenta al integrar Rust en el núcleo de Linux.

Mantenerse eficiente y adaptable

Según una investigación sobre ambidextría organizacional , los proyectos de gran escala como Linux deben participar continuamente en dos tipos de actividades para seguir siendo adaptables, relevantes y exitosos:

1. Explotación: Eficiencia, refinamiento y ejecución. En Linux, esto se refiere a actividades como optimizar funciones, corregir errores y abordar inquietudes de usuarios existentes.
2. Exploración: experimentación, toma de riesgos e innovación. Estas actividades permiten que proyectos como Linux desarrollen enfoques novedosos, se adapten a tecnologías disruptivas y satisfagan las expectativas cambiantes de los usuarios.

Las investigaciones también muestran que las actividades de explotación orientadas al corto plazo tienden a desplazar a las actividades de exploración orientadas al largo plazo . Esto es como querer aprender una nueva habilidad o trabajar en un proyecto no convencional, pero siempre priorizar las tareas diarias. Lo mismo se aplica a los proyectos grandes como Linux: si se centran demasiado en la eficiencia a corto plazo, corren el riesgo de volverse obsoletos a largo plazo. El mundo sigue cambiando mientras que el proyecto sigue siendo el mismo, lo que hace que sus ofertas sean cada vez más irrelevantes para las necesidades cambiantes de los usuarios.

Encontrar el equilibrio adecuado

Por un lado, la adopción de Rust es un experimento muy poco convencional que puede considerarse como una actividad de exploración para Linux. Desde esta perspectiva, la inclusión de Rust está bien fundada. Sin embargo, por otro lado, a diferencia de C, que acoge con los brazos abiertos todo tipo de locuras y comportamientos indefinidos, lo que lo convierte en el lenguaje de referencia para el hacking de bajo nivel, Rust tiene una burocracia interna que impone una determinada forma estructurada de escribir código. En cierto sentido, Rust funciona como un lenguaje de programación y un sistema de gestión de procesos, similar a metodologías como Six Sigma. Una forma específica y estructurada de escribir código puede ciertamente ayudar a agilizar los procesos y mejorar los resultados a corto plazo, como las vulnerabilidades de seguridad y los problemas de fiabilidad. Sin embargo, al igual que en los casos de otros sistemas de gestión de procesos , esta rigidez también introduce riesgos para la agilidad y la adaptabilidad a largo plazo.

Por lo tanto, los méritos de Rust en la optimización de procesos y su mayor seguridad brillarían particularmente en los componentes del núcleo donde la adaptabilidad a largo plazo es menos crítica. Por ejemplo, los controladores de dispositivos interactúan directamente con entradas externas y son componentes de alto riesgo en términos de seguridad y confiabilidad de la memoria. Por lo tanto, tiene sentido escribirlos con Rust. También tienden a tener una vida útil relativamente más corta, ya que los dispositivos nuevos reemplazan con frecuencia a los antiguos. En otras palabras, la preocupación de que la metodología Rust pueda reducir la exploración, o la posibilidad de que eventualmente queramos alejarnos de Rust debido a cambios en las filosofías de escritura de código se vuelve menos relevante. Cuando un controlador de dispositivo se desarrolla con Rust, generalmente es más seguro y confiable, y otros componentes no se construyen sobre este código. Como resultado, no obliga a nadie a una forma particular de escribir código en unas pocas décadas.

Por el contrario, los componentes básicos del núcleo, como el planificador, deben seguir adaptándose para adaptarse a los desafíos futuros y a los nuevos paradigmas. El uso de Rust en estas áreas podría introducir rigideces que dificulten la exploración y conduzcan a la obsolescencia. Piénselo de esta manera: el código futuro debe basarse en los componentes que se están construyendo hoy y, cuando finalmente una filosofía diferente de escritura de software resulte más ventajosa en el futuro, el código C altamente flexible generalmente se puede cambiar de manera incremental hasta que se transforme en el nuevo enfoque (renovación estratégica incremental). Por el contrario, Rust insiste en su propia forma de escribir código, por lo que es probable que esto provoque un dilema de continuar desarrollando con el enfoque antiguo o escribirlo desde cero. Teniendo en cuenta que el software libre siempre ha tenido dificultades para encontrar una cantidad suficiente de voluntarios calificados y regulares, así como una cantidad suficiente de financiación regular, la mejora incremental siempre es mucho más fácil que decidir emprender un proyecto importante como descartar un componente y escribir desde cero. Por lo tanto, cualquier lenguaje que insista en una forma particular de escribir código puede convertirse en un lastre en el futuro, obligando a Linux a continuar con una forma más antigua de escribir código y a perder su posición de vanguardia.

En resumen, propongo una estrategia híbrida en la que se utiliza Rust más para componentes de corto plazo donde la seguridad es crucial, mientras que C (el lenguaje más ágil que no es específico del hardware) se prioriza para componentes de largo plazo para mantener la flexibilidad para paradigmas y enfoques futuros.