LinuxParty

Hace treinta años, Linus Torvalds era un estudiante de 21 años en la Universidad de Helsinki cuando lanzó por primera vez el Kernel de Linux. Su anuncio comenzó , "Estoy haciendo un sistema operativo (gratuito) (solo un hobby, no será grande y profesional ...)". Tres décadas después, las 500 mejores supercomputadoras ejecutan Linux , al igual que más del 70% de todos los teléfonos inteligentes. Linux es claramente grande y profesional.

Durante tres décadas, Linus Torvalds ha liderado el desarrollo del kernel de Linux, inspirando a muchos otros desarrolladores y proyectos de código abierto. En 2005, Linus también creó Git para ayudar a administrar el proceso de desarrollo del kernel, y desde entonces se ha convertido en el sistema de control de versiones más popular, en el que confían innumerables proyectos de código abierto y propietarios.

La siguiente entrevista continúa nuestra serie con Open Source Leaders . Linus Torvalds respondió a nuestras preguntas por correo electrónico, reflexionando sobre lo que ha aprendido a lo largo de los años liderando un gran proyecto de código abierto. En esta primera parte, nos enfocamos en el desarrollo del kernel de Linux y Git. " [Linux] fue un proyecto personal que no surgió de un gran sueño de crear un nuevo sistema operativo ", explica Linus, " sino que, literalmente, creció un poco al azar cuando inicialmente solo trataba de aprender los entresijos de mi nuevo Hardware de PC " .

Con respecto a la creación de Git y luego entregárselo a Junio ​​Hamano para mejorarlo y mantenerlo, Linus señaló: " No quiero afirmar que la programación sea un arte, porque en realidad se trata principalmente de 'buena ingeniería'. Soy un gran creyente en Thomas Edison de 'uno por ciento de inspiración y un noventa y nueve por ciento de transpiración' mantra: es casi todo sobre los pequeños detalles y lo cotidiano ronco-trabajo, pero no. es que la 'inspiración' parte de vez en cuando, esa cosa 'buen gusto' que está a punto más que simplemente resolver algún problema, resolviéndolo limpia y bien y sí, incluso bellamente. Y Junio ​​tenía ese 'buen gusto' " .

Siga leyendo para conocer la primera en una entrevista de dos partes. Vuelve la semana que viene para ver la segunda parte, donde Linus explora las lecciones y los conocimientos adquiridos durante tres décadas al frente del kernel de Linux.

Desarrollo del kernel de Linux

Jeremy Andrews: Linux está en todas partes y ha sido una inspiración para todo el mundo del código abierto. Por supuesto, no siempre fue así. Lanzó el kernel de Linux en 1991 con una modesta publicación de Usenet en comp.os.minix. Una década después, escribiste un libro interesante y personal titulado " Sólo por diversión: la historia de un revolucionario accidental " que explora gran parte de esa historia. ¡Este año, en agosto, Linux celebrará su 30 aniversario! ¡Eso es increíble, felicitaciones! ¿En qué momento de este viaje se dio cuenta de lo que había hecho, que Linux era mucho más que "solo un pasatiempo"?

Linus Torvalds: Esto puede sonar un poco ridículo, pero en realidad sucedió muy temprano. Ya a finales del '91 (y ciertamente a principios del '92) Linux ya se había vuelto mucho más grande de lo que esperaba.

Y sí, considerando que en ese momento, probablemente solo había unos pocos cientos de usuarios (e incluso los "usuarios" pueden ser demasiado fuertes, la gente estaba jugando con eso), probablemente suene extraño considerando cómo Linux luego terminó creciendo mucho más. Pero en muchos aspectos para mí, personalmente, el gran punto de inflexión fue cuando me di cuenta de que otras personas realmente lo estaban usando y estaban interesadas en él, y comenzó a tener vida propia. La gente empezó a enviar parches y el sistema estaba empezando a hacer mucho más de lo que había imaginado inicialmente.

Creo que X11 fue portado a Linux alguna vez en abril '92 (no tome mi palabra para las fechas - es un loong hace tiempo), y que fue otro gran paso en el que de repente había una interfaz gráfica de usuario y un conjunto nuevo de capacidades.

Para poner todo esto en perspectiva, realmente no comencé con grandes planes de altas expectativas. Fue un proyecto personal que no surgió de un gran sueño de crear un nuevo sistema operativo, sino que, literalmente, surgió al azar de mí inicialmente, solo tratando de aprender los entresijos de mi nuevo hardware de PC.

Entonces, cuando lancé la primera versión, fue más un "vistazo a lo que hice", y seguro, esperaba que otros lo encontraran interesante, pero no era un sistema operativo realmente serio y utilizable. Fue más una prueba de concepto, y solo un proyecto personal en el que había trabajado durante varios meses en ese momento.

Y pasar de ese "proyecto personal" a ser algo donde otros lo usaban, enviaban comentarios (e informes de errores) y parches ocasionales, ese fue el gran cambio para mí.

Solo para dar un ejemplo de algo realmente fundamental: la licencia de copyright original era algo así como "puedes distribuir esto en forma de código fuente, pero no por dinero".

Eso se debía a que para mí uno de los problemas había sido literalmente que unix comercial era caro (bueno, para un estudiante pobre que gastó todo su dinero en la nueva PC), por lo que para mí una cosa muy importante fue que el código fuente estar disponible (para que la gente pudiera jugar con él), y quería que estuviera abierto a personas como yo que simplemente no podían permitirse las alternativas.

Y cambié la licencia a finales del '91 (o tal vez muy temprano en el '92) a la GPLv2 porque había gente que quería distribuirla en disquetes a grupos de usuarios locales de Unix, pero querían al menos recuperar los costes de los disquetes y sus tiempo de copia. Y me di cuenta de que obviamente era completamente razonable, y que lo importante no era la parte "sin dinero", sino la parte de "la fuente debe estar abiertamente disponible".

Resultado final: la gente no solo lo distribuyó en las reuniones de los grupos de usuarios de Unix, sino que las primeras distribuciones de disquetes como SLS y Slackware ocurrieron en meses.

En comparación con esos cambios iniciales realmente fundamentales, todo lo demás fue "incremental". Claro, algunos de los incrementales fueron bastante grandes (IBM se incorporó, Oracle DB se trasladó, Red Hat IPO, Android se hizo grande en los teléfonos, etc.), pero aún eran menos revolucionarios personalmente que esa inicial "gente que ni siquiera conozco están usando Linux ''.

JA: ¿Alguna vez te arrepientes de tu elección de licencia o de cuánto dinero han ganado otras personas y empresas con algo que creaste?

LT: Por supuesto que no.

Primero que nada, lo estoy haciendo bastante bien. No soy increíblemente rico, pero soy un ingeniero de software bien pagado, haciendo lo que me gusta hacer, en mi propio horario. No me duele.

Pero igualmente importante, estoy 100% convencido de que la licencia ha sido una gran parte del éxito de Linux (y Git, para el caso). Creo que todos los involucrados terminan siendo mucho más felices cuando saben que todos tienen los mismos derechos y nadie es especial en lo que respecta a las licencias.

Hay un buen número de estos proyectos de "licencia dual" en los que el propietario original conserva una licencia comercial ("puede usar esto en su producto patentado si nos paga tarifas de licencia") y, por otro lado, el proyecto también está disponible bajo algo como la GPL para casos de código abierto.

Y creo que es realmente difícil construir una comunidad alrededor de ese tipo de situación, porque el lado del código abierto siempre sabe que es de "segunda clase". Además, conlleva una gran cantidad de trámites para la concesión de licencias para que la fiesta especial siempre conserve sus derechos especiales. Por lo que agrega mucha fricción al proyecto.

Y, por otro lado, he visto muchos proyectos de código abierto con licencia BSD (o MIT o similar) que simplemente se fragmentan cuando se vuelven lo suficientemente grandes como para ser comercialmente importantes, y las empresas involucradas inevitablemente deciden convertir sus propias partes en propietarias.

Así que creo que la GPLv2 es prácticamente el equilibrio perfecto de "todo el mundo trabaja bajo las mismas reglas", y aún requiere que la gente retribuya a la comunidad ("ojo por ojo"). Y todos saben que todas las demás personas involucradas están sujetas a las mismas reglas, por lo que todo es muy equitativo y justo.

Por supuesto, otra parte de eso es que también obtienes lo que pones. Claro, puedes intentar "costarte" en el proyecto y ser solo un usuario, y eso está bien. Pero si lo hace, tampoco tiene control sobre el proyecto. Eso también puede estar perfectamente bien, si realmente solo necesita un sistema operativo básico, y Linux ya hace todo lo que desea. Pero si tiene requisitos especiales, la única forma de afectar realmente el proyecto es participando.

Esto mantiene a todos honestos. Incluyéndome a mí. Cualquiera puede bifurcar el proyecto y seguir su propio camino y decir "adiós Linus, me hago cargo del mantenimiento de mi versión de Linux". Soy "especial" sólo porque, y siempre y cuando, la gente confíe en mí para hacer un buen trabajo. Y así es exactamente como debería ser.

Que "cualquiera puede mantener su propia versión" preocupaba a algunas personas acerca de la GPLv2, pero realmente creo que es una fortaleza, no una debilidad. De forma algo poco intuitiva, creo que es en realidad lo que ha provocado que Linux evite la fragmentación: todo el mundo puede hacer su propia bifurcación del proyecto, y eso está bien. De hecho, ese fue uno de los principios básicos de diseño de "Git": cada clon del repositorio es su propia bifurcación, y la gente (y las empresas) que se bifurcan su propia versión es la forma en que realmente se realiza todo el desarrollo.

Por lo tanto, la bifurcación no es un problema, siempre que luego pueda fusionar las partes buenas. Y ahí es donde entra en juego la GPLv2. El derecho a bifurcar y hacer lo tuyo es importante, pero la otra cara de la moneda es igualmente importante: el derecho a volver a unirse cuando se haya demostrado que una bifurcación tiene éxito.

Otro problema es que realmente desea tener las herramientas para respaldar ese flujo de trabajo, pero también debe tener la mentalidad para respaldarlo. Un gran impedimento para volver a unirse a las bifurcaciones no es solo la concesión de licencias, sino también la "mala sangre". Si la bifurcación comienza por razones muy antagónicas, puede ser muy difícil fusionar las dos bifurcaciones, no por razones técnicas o de licencia, sino porque la bifurcación era muy irritante. Una vez más, creo que Linux ha evitado eso principalmente porque siempre hemos visto la bifurcación de las cosas como algo natural, y luego también es muy natural intentar fusionar nuevamente cuando algún trabajo ha demostrado ser exitoso.

Así que esta respuesta salió disparada por la tangente, pero creo que es importante; no me arrepiento mucho de la elección de la licencia, porque realmente creo que la GPLv2 es una gran parte de por qué Linux ha tenido éxito.

El dinero realmente no es un gran motivador. No une a la gente. Tener un proyecto común y sentir realmente que realmente puedes ser un socio pleno en ese proyecto, eso motiva a la gente, creo.

JA: En estos días, cuando la gente publica código fuente bajo la GPLv2, generalmente lo hace gracias a Linux. ¿Cómo encontró la licencia y cuánto tiempo y esfuerzo dedicó a revisar otras licencias existentes?

LT: En aquel entonces, la gente todavía tenía grandes guerras sobre BSD vs GPL (creo que en parte impulsada por cómo rms realmente tiene una habilidad para enojar a la gente), así que había visto algunas de las discusiones sobre licencias solo a través de varios grupos de noticias de Usenet estaba leyendo (cosas como comp.arch, comp.os.minixetc.).

Pero las dos razones principales probablemente fueron simplemente gcc, que fue fundamental para poner en marcha Linux, ya que necesitaba absolutamente un compilador de C, y Lars Wirzenius ("Lasu"), que era el otro estudiante de informática de habla sueca en la Universidad de mi año (el sueco es una minoría bastante pequeña en Finlandia).

Lasu estaba mucho más interesado en las discusiones sobre licencias, etc. que yo.

Para mí, la elección de la GPLv2 no fue un gran problema político, se debió principalmente al hecho de que mi licencia original había sido tan ad-hoc y necesitaba una actualización, y me sentí en deuda con gcc, y la GPLv2 coincidía con mi "tienes para devolver "las expectativas de la fuente".

Entonces, en lugar de inventar otra licencia (o simplemente editar la original; simplemente eliminar la cláusula "sin dinero puede cambiar de manos" podría haber sido una opción), quería elegir una que la gente ya conocía y había tenido algunos abogados involucrados. .

JA: ¿Cómo es tu día típico? ¿Cuánto se gasta en escribir código, en comparación con revisar código, en comparación con leer y escribir correos electrónicos? ¿Y cómo equilibra la vida personal y el trabajo en el kernel de Linux?

LT: Escribo muy poco código en estos días, y no lo he hecho durante mucho tiempo. Y cuando escribo código, la situación más común es que hay alguna discusión sobre algún problema en particular, y hago cambios y los envío como un parche principalmente como una explicación de una solución sugerida.

En otras palabras, la mayor parte del código que escribo es más un "mira, ¿qué tal si lo hacemos de esta manera?" Donde el parche es un ejemplo muy concreto. Es fácil empantanarse en una discusión teórica de alto nivel sobre cómo resolver algo, y encuentro que la mejor manera de describir una solución es a menudo simplemente escribir el fragmento de código, tal vez no todo, y simplemente hacerlo muy concreto de esa manera.

Porque todo mi trabajo real se dedica a leer y escribir correos electrónicos. Se trata principalmente de comunicación, no de codificación. De hecho, considero que este tipo de comunicación con periodistas y bloggers tecnología, etc., para, literalmente, ser parte de mi día de trabajo - puede obtener una prioridad menor que las discusiones técnicas reales, pero sí pasar una buena cantidad de tiempo en este tipo de cosas también.

Y sí, también dedico tiempo a revisiones de código, pero honestamente, para cuando recibo una solicitud de extracción, en general, el código en cuestión ya debería haber sido revisado por varias personas. Entonces, aunque todavía miro los parches, en realidad tiendo a mirar más las explicaciones y la historia de cómo me llegó el parche. Y con las personas con las que he trabajado más tiempo, ni siquiera hago eso: son los mantenedores de su subsistema, no estoy allí para microgestionar su trabajo.

Muy a menudo, mi trabajo principal es "estar allí", ser el punto de recolección y ser la persona que administra y hace cumplir las liberaciones. En otras palabras, mi trabajo generalmente se trata más del proceso de mantenimiento que del código de bajo nivel.

JA: ¿Cómo es tu entorno de trabajo? Por ejemplo, ¿prefiere una habitación oscura sin distracciones o una habitación con vistas? ¿Suele trabajar en silencio o mientras escucha música? ¿Qué tipo de hardware usas normalmente? ¿Revisa el código vien una terminal o con un IDE elegante? Y, ¿tiene una distribución de Linux preferida para este trabajo?

LT: Mi habitación no es exactamente "oscura", pero tengo las persianas de la ventana al lado de mi escritorio cerradas, porque no quiero luz solar brillante (no es que sea necesariamente muy común en esta época del año en Oregon;) . Así que no hay vistas, solo un escritorio (desordenado), con dos monitores 4k y una potente computadora de escritorio debajo del escritorio . Y un par de computadoras portátiles para probar y para cuando estoy de viaje.

Y quiero trabajar en silencio. Solía ​​odiar el tic-tac de las unidades de disco mecánicas, felizmente relegado durante mucho tiempo a la basura, ya que he usado exclusivamente SSD durante más de una década, y los ruidosos ventiladores de la CPU también son inaceptables.

Y todo se hace en una terminal tradicional, aunque yo no uso 'vi'. Yo uso esta abominación llamada "micro-emacs", que no tiene absolutamente nada que ver con GNU emacs excepto que algunas de las combinaciones de teclas son similares. Me acostumbré en la Universidad de Helsinki cuando era un niño pequeño, y no he podido dejar de hacerlo, aunque sospecho que pronto tendré que hacerlo. Hackeé (un muy limitado) soporte utf-8 para él hace unos años, pero realmente está mostrando su edad, y muestra todos los signos de haber sido escrito en los 80 y la versión que uso era una bifurcación que no mantenido desde mediados de los 90.

La Universidad de Helsinki lo usó porque funcionaba en DOS, VAX / VMS y Unix, por lo que me lo presentaron. Y ahora mis dedos están codificados para ello. Realmente necesito cambiar a algo que realmente se mantenga y haga utf-8 correctamente. Probablemente 'nano'. Pero mi trozo de basura histórica pirateado funciona apenas lo suficientemente bien como para que nunca me haya visto realmente obligado a enseñar nuevos trucos a mis viejos dedos.

Entonces, mi entorno de escritorio es bastante simple: varios terminales de texto abiertos y un navegador web con correo electrónico (y varias otras pestañas, principalmente sitios de noticias y tecnología). Quiero tener una buena cantidad de espacio en el escritorio, porque estoy acostumbrado a tener ventanas de terminal bastante grandes (100x40 es mi tamaño inicial predeterminado), y tengo varios terminales abiertos uno al lado del otro. De ahí los monitores duales de 4k.

Uso Fedora en todas mis máquinas, no porque sea necesariamente "preferido", sino porque es a lo que estoy acostumbrado. No me importa mucho la distribución; para mí, es principalmente una forma de instalar Linux en una máquina y configurar todas mis herramientas, de modo que luego pueda reemplazar el kernel y trabajar en eso.

JA: La lista de correo del kernel de Linux es donde el desarrollo del kernel ocurre públicamente y tiene un tráfico extremadamente alto. ¿Cómo se mantiene al día con tanto correo electrónico? ¿Ha explorado otras soluciones de colaboración y comunicación fuera de una lista de correo, o hay algo en una lista de correo simple que es perfecta para lo que hace?

LT: Oh, no leo la lista de correo del kernel directamente, y no lo he hecho en años. Es demasiado.

No, el punto de la lista de correo del kernel es que básicamente se copia en todas las discusiones (bueno, una de las listas de correo del kernel lo hace, hay muchas) y luego la lista lkml tradicional es la alternativa para cuando no hay ' t alguna lista más específica). Y de esa manera, cuando se trae una nueva persona a la discusión, pueden ver el historial y los antecedentes al mirar la lista de correo del kernel.

Entonces, lo que solía hacer era estar suscrito a la lista, pero tener todo el correo electrónico de lkml en el que no estaba escrito personalmente se archivase automáticamente, por lo que no lo vería de forma predeterminada. Pero luego, cuando me llegaba un problema, toda esa discusión aparecía, porque estaba allí en mi correo electrónico, pero no en mi bandeja de entrada hasta que se necesitaba.

En estos días, de hecho uso la funcionalidad lore.kernel.org en su lugar, porque funciona muy bien y tenemos algunas otras herramientas construidas a su alrededor. Entonces, en lugar de archivarlo automáticamente en mis propios archivos de correo, las discusiones terminan siendo visibles de esa manera. Pero el flujo de trabajo básico es conceptualmente el mismo.

Todavía recibo una buena cantidad de correos electrónicos, obviamente, pero en muchos sentidos ha ido mejorando a lo largo de los años, en lugar de empeorar. Una gran parte de eso es Git y lo bien que funciona el flujo de lanzamiento del kernel: solíamos tener muchos más problemas con el flujo de código y las herramientas. La situación de mi correo electrónico en realidad era mucho peor allá por el cambio de siglo, cuando todavía tratábamos con enormes bombas de parche y teníamos serios problemas de escalabilidad en el flujo de desarrollo.

Y el modelo de lista de correo (con herramientas a su alrededor) realmente funciona muy bien. Eso no quiere decir que la gente no use otros medios de comunicación además del correo electrónico (tanto de persona a persona como de listas de correo): hay personas que disfrutan de varias configuraciones de chat en tiempo real (IRC es el tradicional). Y aunque eso nunca ha sido lo mío, claramente es lo que a algunas personas les gusta usar para la lluvia de ideas. Pero ese modelo de "lista de correo como archivo" funciona muy bien, y funciona perfectamente junto con todo "enviar parches entre desarrolladores como correos electrónicos" y "enviar informes de problemas como correos electrónicos".

Por lo tanto, el correo electrónico sigue siendo el principal canal de comunicación y facilita la discusión de problemas técnicos, con parches integrados en el mismo medio. Y funciona en diferentes zonas horarias, lo cual es muy importante cuando todo el mundo está tan disperso geográficamente.

JA: Seguí de cerca el desarrollo del kernel durante aproximadamente una década, escribí en blogs sobre él en KernelTrap y escribí sobre nuevas características a medida que evolucionaban . Me detuve en el momento en que se lanzó el kernel 3.0, que había seguido a 8 años de versiones 2.6.x. ¿Es posible resumir algunas de las cosas más interesantes que han sucedido en el kernel desde la versión 3.0?

LT: Je. Eso fue hace tanto tiempo que ni siquiera podía empezar a resumir las cosas. Ha pasado una década desde la versión 3.0 y hemos tenido muchos cambios técnicos en esa década. ARM ha crecido y ARM64 se ha convertido en una de nuestras arquitecturas principales. Muchos, muchos controladores nuevos y nuevas funciones básicas.

En todo caso, lo interesante de la última década es cómo hemos mantenido el modelo de desarrollo real realmente fluido, y qué no ha cambiado.

Hemos pasado por muchos esquemas de números de versión diferentes a lo largo de las décadas, hemos tenido diferentes modelos de desarrollo, pero la versión 3.0 fue de hecho la que finalizó el modelo que hemos usado desde entonces. En cierto modo hizo oficial todo "las versiones se basan en el tiempo, los números de versión son solo números y no tienen dependencias de funciones".

Comenzamos todas las versiones basadas en el tiempo con una ventana de combinación en los días 2.6.x, por lo que esa parte no era nueva. Pero 3.0 fue cuando los últimos vestigios de "el número tiene significado" fueron arrojados por la borda.

Teníamos el esquema de numeración aleatoria (principalmente antes de 1.0), teníamos todo el modelo de "números menores impares significa kernel de desarrollo, incluso significa kernel de producción estable", y luego en 2.6.x comenzamos a hacer la versión basada en el tiempo modelo. Pero la gente todavía tenía esa pregunta de "qué se necesita para aumentar el número mayor". Y 3.0 hizo oficial que incluso el número de versión principal no tiene significado, y que intentaremos mantener los números fáciles de manejar y no dejar que crezcan demasiado.

Entonces, durante la última década, hemos realizado cambios absolutamente enormes (Git hace que sea fácil mostrar algunas estadísticas en números: alrededor de tres cuartos de millón de confirmaciones de más de 17 mil personas). Pero el modelo de desarrollo en sí ha sido bastante fluido y estable.

Y ese no siempre ha sido el caso. Las dos primeras décadas de desarrollo del kernel estuvieron llenas de cambios bastante dolorosos en el modelo de desarrollo. Esta última década ha sido mucho más predecible en cuanto a lanzamientos.

JA: A partir de ahora, la última versión es 5.12-rc5. ¿Qué tan estandarizado está el proceso de publicación? Por ejemplo, ¿qué tipo de cambios se realizan en un -rc1, frente a un -rc2 y así sucesivamente? ¿Y en qué momento decides que un lanzamiento determinado está listo para ser lanzado oficialmente? ¿Qué sucede si se equivoca y se encuentra una gran regresión después de la versión final, y con qué frecuencia sucede esto? ¿Cómo ha evolucionado este proceso a lo largo de los años?

LT: Así que aludí a esto antes: el proceso en sí es realmente bastante estándar y se ha mantenido así durante la última década. Pasó por varios trastornos antes de eso, pero en realidad ha sido casi como un reloj desde 3.0 (y de hecho, unos años antes de eso, el cambio a Git en muchos sentidos fue el comienzo del proceso moderno, y tomó un tiempo antes de eso. todo el mundo se acostumbró).

Así que hemos tenido esta cadencia de "dos semanas de ventana de fusión" seguida de aproximadamente 6-8 candidatos de lanzamiento semanal antes del lanzamiento final durante casi 15 años, creo.

Y las reglas siempre han sido las mismas, aunque no siempre se han aplicado de forma estricta: la ventana de combinación es para código nuevo que supuestamente está "probado y listo", y luego los dos meses siguientes son para correcciones y para hacer seguro que todos los problemas se han solucionado. Lo que no siempre sucede, ya veces ese código supuestamente "listo" se desactiva o se revierte por completo antes del lanzamiento.

Y luego se repite, por lo que tenemos un lanzamiento aproximadamente cada 10 semanas más o menos.

Y el criterio de publicación es que me sienta lo suficientemente seguro, lo que obviamente a su vez se basa en los tipos de informes de problemas que todavía están llegando. Si alguna área todavía muestra problemas al final del juego de rc, soy bastante agresivo para revertir las cosas y diciendo "nos ocuparemos de esto en una versión posterior una vez que lo hayamos descubierto por completo", pero en general es bastante raro que sea necesario.

¿Siempre funciona? No. Una vez que se lanza el kernel, y particularmente una vez que una distribución lo adquiere, obtienes nuevos usuarios, obtienes personas que no lo probaron durante el desarrollo que encuentran cosas que no funcionaron y que no detectamos durante el rc serie. Eso es bastante inevitable. Es parte de la razón por la que tenemos todos los árboles del "kernel estable", que continúan agregando correcciones después del lanzamiento. Y algunos núcleos estables se mantienen durante más tiempo que otros y se denominan núcleos LTS ("Soporte a largo plazo").

Todo esto se ha mantenido bastante sin cambios en los últimos diez años, aunque terminamos teniendo mucha más automatización en su lugar. La automatización de las pruebas del kernel es difícil en general, en parte porque gran parte del kernel son controladores que obviamente dependen de la disponibilidad del hardware, pero hay varias granjas que realizan pruebas de arranque y de rendimiento, y realizan varias pruebas de carga aleatorias. Y eso ha mejorado mucho a lo largo de los años.

JA: En noviembre pasado, se dijo que estaba impresionado por los nuevos chips ARM64 de Apple que se encuentran en algunas de sus nuevas computadoras. ¿Está siguiendo el esfuerzo de desarrollo para admitirlos con Linux? Veo que el trabajo se fusionó con el siguiente . ¿Es probable que Linux se inicie en el hardware MacBook de Apple tan pronto como el próximo kernel 5.13? ¿Es probable que sea uno de los primeros en adoptar? ¿Cuál es el significado de ARM64?

LT: Lo estoy revisando muy de vez en cuando, pero aún son los primeros días. Como puede observar, el soporte inicial probablemente se fusionará con 5.13, pero debe darse cuenta de que eso es solo el comienzo y no hace que el hardware de Apple sea útil con Linux todavía.

No es la parte arm64 la que termina siendo el problema, sino todos los controladores del hardware que lo rodea (el SSD y la GPU en particular). El trabajo inicial hasta ahora hace funcionar algunas de las cosas realmente de bajo nivel, pero no da como resultado nada útil fuera de la habilitación temprana del hardware. Tomará algún tiempo para que sea una opción real para que la gente la pruebe.

Pero no es solo el hardware de Apple lo que ha mejorado: la infraestructura para arm64 en general ha crecido mucho y los núcleos han pasado de ser "Meh" a ser mucho más competitivos en el espacio del servidor. El espacio del servidor arm64 era bastante triste no hace mucho tiempo, pero los procesadores Graviton2 y Altra de Ampere de Amazon, ambos basados ​​en la IP ARM Neoverse muy mejorada, son mucho mejores que las ofertas de hace unos años.

He estado esperando tener una máquina ARM utilizable durante más de una década y aún no está allí, pero claramente está mucho más cerca de lo que solía estar.

De hecho, supongo que podría decir que he querido una máquina ARM durante mucho más tiempo; cuando era adolescente, la máquina que realmente quería era una Acorn Archimedes, pero la disponibilidad y el precio me hicieron elegir una Sinclair. QL (procesador M68008) y luego, obviamente, unos años más tarde, una PC i386.

Así que se ha estado gestando durante décadas, pero todavía no han estado ampliamente disponibles y no son competitivos en precio / rendimiento como computadoras para mí. Un día. Ojalá en un futuro no muy lejano.

JA: ¿Hay algo en el kernel que no sea óptimo, pero que requiera una reescritura completa para abordarlo correctamente? En otras palabras, el kernel tiene 30 años y el conocimiento, los lenguajes y el hardware han cambiado mucho en estos 30 años: si lo reescribiera desde cero ahora, ¿qué cambiaría?

LT: De hecho, hemos sido muy buenos incluso en reescribir las cosas por completo si es necesario, por lo que cualquier cosa que hubiera sido un desastre absoluto se ha reescrito hace mucho tiempo.

Claro, tenemos una buena cantidad de capas de "compatibilidad", pero generalmente no son horribles. Y no está claro si incluso esas capas de compatibilidad desaparecerían realmente si se reescribieran desde cero; se trata de compatibilidad con versiones anteriores de archivos binarios más antiguos (y, a menudo, compatibilidad con arquitecturas más antiguas, por ejemplo, ejecutar aplicaciones x86 de 32 bits en x86-64). Dado que considero que la compatibilidad con versiones anteriores es muy importante, me gustaría mantenerlos incluso en una reescritura.

Entonces, obviamente, hay muchas cosas que "no son óptimas" en el sentido de que cualquier cosa puede mejorarse, pero por la forma en que formula la pregunta, tengo que decir que no, no hay nada allí que desprecie. Hay controladores heredados por los que nadie se preocupará lo suficiente como para limpiarlos, por lo que pueden hacer cosas feas, pero una parte clave de eso es que "a nadie le importa lo suficiente". No ha sido un problema, y ​​cuando se convierte en un problema, tendemos a eliminar de manera bastante activa el verdadero soporte heredado que no podemos encontrar a nadie que se preocupe. Así que nos hemos deshecho de muchos controladores a lo largo de los años, y nos hemos deshecho de todo el soporte de arquitectura cuando ya no tiene ningún sentido mantenerlo.

No, la única razón principal para una "reescritura" sería si termina teniendo algún caso de uso en el que toda la estructura ya no tenga sentido. El escenario más probable sería un pequeño sistema integrado que simplemente no quiere todo lo que ofrece Linux, y tiene una huella de hardware tan pequeña que simplemente quiere algo más pequeño y simple de lo que Linux se ha convertido a lo largo de los años.

Porque Linux ha crecido mucho. Incluso el hardware pequeño (piense en teléfonos móviles, etc.) hoy en día es mucho más capaz que la máquina original en la que se desarrolló Linux.

JA: ¿Qué hay de reescribir al menos partes con Rust, un lenguaje que fue diseñado específicamente para el desempeño y la seguridad? ¿Hay margen de mejora de esta forma? ¿Crees que alguna vez es posible que otro lenguaje como Rust reemplace a C en el kernel?

LT: Ya veremos. No creo que Rust se haga cargo del núcleo central, pero hacer controladores individuales (y tal vez subsistemas de controladores completos) no parece del todo improbable. Quizás también los sistemas de archivos. Por lo tanto, no se trata de "reemplazar C", sino de "aumentar nuestro código C donde tenga sentido".

Por supuesto, los controladores en particular son aproximadamente la mitad del código del kernel real, por lo que hay mucho espacio para eso, pero no creo que nadie esté realmente esperando reescribir los controladores existentes en Rust al por mayor, más bien un "algunas personas lo harán nuevos controladores en Rust, y un par de controladores podrían reescribirse donde tenga sentido ".

Pero en este momento eso es más un "la gente lo está probando y jugando con él" en lugar de algo más que eso. Es fácil señalar las ventajas, pero ciertamente también hay complejidades, por lo que estoy adoptando un enfoque de esperar y ver si las ventajas prometidas realmente funcionan.

JA: ¿Hay alguna parte específica del kernel de la que esté personalmente más orgulloso?

LT: Las partes destacadas a las que tiendo a señalar son la capa VFS ("sistema de archivos virtual") (y la búsqueda de nombre de ruta en particular) y nuestro código de máquina virtual. Lo primero porque Linux solo hace algunas de esas cosas fundamentales (buscar un nombre de archivo es realmente una operación central en un sistema operativo) mucho mejor que cualquier otra cosa que exista. Y esto último principalmente porque admitimos más de 20 arquitecturas, y todavía lo hacemos con una capa de VM en gran parte unificada, lo que creo que es bastante impresionante.

Pero al mismo tiempo, esto es en gran parte una función de "qué parte del kernel le importa". El kernel es lo suficientemente grande como para que diferentes desarrolladores (y diferentes usuarios) simplemente tengan diferentes opiniones sobre lo que más importa. Algunas personas piensan que la programación es la parte más emocionante del kernel. A otros les gusta el meollo de los controladores de dispositivos (y tenemos muchos de ellos). Personalmente, tiendo a estar más involucrado en las áreas de VM y VFS, por lo que, naturalmente, las señalo.

JA: Encontré esta descripción de la búsqueda de nombre de ruta y es más compleja de lo que esperaba. ¿Qué hace que la implementación de Linux sea mucho mejor que lo que se hace en otros sistemas operativos? ¿Y a qué te refieres con "mejor"?

LT: La búsqueda de nombre de ruta es algo tan común y fundamental que la mayoría de las personas fuera de los desarrolladores del kernel ni siquiera lo consideran un problema: simplemente abren archivos y lo dan todo por sentado.

Pero en realidad es bastante complicado hacerlo realmente bien. Exactamente porque absolutamente todo realiza búsquedas de nombres de ruta todo el tiempo, es enormemente crítico para el rendimiento y es una de esas áreas en las que también desea escalar bien en entornos SMP, y tiene mucha complejidad en el bloqueo. Y usted no quiere hacer ningún IO, por lo que el almacenamiento en caché es muy importante. De hecho, la búsqueda de nombre de ruta es tan importante que no puede dejarla en el sistema de archivos de bajo nivel, porque tenemos más de 20 sistemas de archivos diferentes, y hacer que cada uno de ellos haga su propio almacenamiento en caché y su propio bloqueo sería un completo desastre.

Entonces, una de las cosas principales que hace la capa VFS es realmente manejar todo el bloqueo y almacenamiento en caché de los componentes del nombre de ruta, y manejar toda la serialización y el cruce del punto de montaje, y hacerlo todo con algoritmos en su mayoría sin bloqueo ( RCU ), pero también con algunas cosas realmente ingeniosas como cerraduras (el bloqueo "lockref" del kernel de Linux es un "spinlock con recuento de referencias" muy especial que fue diseñado literalmente para el almacenamiento en caché de dcache, y es básicamente un recuento de referencias de bloqueo especializado que puede hacer la elisión de bloqueo para ciertas situaciones comunes).

Resultado final: los sistemas de archivos de bajo nivel aún necesitan realizar la búsqueda real de las cosas que no están almacenadas en caché, pero no necesitan preocuparse por el almacenamiento en caché y todas las reglas de coherencia y las reglas de atomicidad que acompañan a las búsquedas de nombres de ruta. El VFS se encarga de todo eso por ellos.

Y todo supera todo lo que ha hecho cualquier otro sistema operativo, mientras que básicamente se escala perfectamente incluso en máquinas con miles de CPU. Y lo hace incluso cuando todas esas máquinas terminan tocando los mismos directorios (porque cosas como el directorio raíz o el directorio de inicio de un proyecto son cosas que incluso las aplicaciones con muchos subprocesos tocan al mismo tiempo, y que no se distribuyen a cualquier tipo de comportamiento por subproceso).

Así que no es solo "mejor", es "Mejor" con una 'B' mayúscula. Nada más por ahí viene incluso cerca . El dcache de Linux es simplemente una clase propia.

JA: El año pasado ha sido difícil en todo el mundo. ¿Cómo ha afectado la pandemia de COVID-19 al proceso de desarrollo del kernel?

LT: De hecho, ha tenido un efecto mínimo, debido a cómo siempre trabajamos. El correo electrónico realmente termina siendo una herramienta maravillosa, y no confiamos en las reuniones cara a cara.

Sí, afectó la cumbre anual del kernel el año pasado (y este año todavía está en el aire), y la mayoría de las conferencias se cancelaron o se volvieron virtuales. Y las personas que antes trabajaban en oficinas, en su mayoría, comenzaron a trabajar desde casa (pero muchos de los mantenedores del núcleo del núcleo ya lo hacían). Así que cambiaron muchas cosas a su alrededor, pero el desarrollo central en sí funcionó exactamente como antes.

Y obviamente afectó a todas nuestras vidas de otras maneras, solo las ramificaciones sociales en general. Pero en general, siendo un desarrollador de kernel que ya interactuaba con la gente casi en su totalidad por correo electrónico, probablemente fuimos algunos de los menos afectados.

Sistema de control de versiones distribuido de Git

JA: Linux es solo una de sus contribuciones omnipresentes al código abierto. En 2005 también creó Git, el sistema de control de código fuente distribuido extremadamente popular. Migró rápidamente el árbol de fuentes del kernel de Linux desde el Bitkeeper propietario al Git de código abierto recién creado, y en el mismo año entregó el mantenimiento a Junio ​​Hamano . Hay mucha historia fascinante allí, ¿qué te llevó a ceder el liderazgo en este proyecto tan rápidamente y cómo encontraste y seleccionaste a Junio?

LT: Entonces, hay dos partes en esta respuesta.

La primera parte es que mucho me hice no quiero crear un nuevo sistema de control de código fuente. Linux fue creado porque encuentro fascinante la interfaz de bajo nivel entre hardware y software; es básicamente una labor de amor e interés personal. Por el contrario, Git se creó por necesidad: no porque me pareciera interesante el control de fuentes, sino porque despreciaba absolutamente la mayoría de los sistemas de control de fuentes, y el que encontré más aceptable y que realmente había funcionado bastante bien en el modelo de desarrollo de Linux ( BitKeeper) se había vuelto insostenible.

Resultado final: he estado haciendo Linux durante más de 30 años ( aún faltan unos meses para el aniversario de la primera versión , pero ya había empezado en lo que se convertiría en Linux hace 30 años), y lo he mantenido todo hora. ¿Pero Git? Nunca pensé que realmente quisiera mantenerlo a largo plazo. Me encanta usarlo y, obviamente, creo que es el mejor SCM que existe en gran medida, pero no es mi pasión e interés fundamentales, si ves lo que estoy tratando de decir.

Así que siempre quise que alguien más me mantuviera el SCM; de hecho, hubiera sido más feliz si no hubiera tenido que escribir uno en primer lugar.

Ese es el trasfondo.

En cuanto a Junio, en realidad fue una de las primeras personas que llegó como desarrolladores de Git. Su primer cambio se produjo pocos días después de que hice pública la primera (y muy aproximada) versión de Git. Así que Junio ​​ha existido desde el comienzo de Git.

Pero no es como si le hubiera entregado el proyecto a la primera persona al azar en aparecer. Mantuve Git durante unos meses, y lo que me hizo preguntarle a Junio ​​si quería ser el mantenedor es esa noción muy difícil de describir de "buen gusto". Realmente no tengo una mejor descripción para ello: la programación se trata de resolver problemas técnicos, pero también es importante cómo los resuelves y cómo piensas sobre ellos, y es una de esas cosas que comienzas a reconocer con el tiempo: ciertas personas tenga ese "buen gusto" y elija la solución "correcta".

No quiero afirmar que la programación sea un arte, porque en realidad se trata principalmente de "buena ingeniería". Soy un gran creyente en el mantra de Thomas Edison "uno por ciento de inspiración y noventa y nueve por ciento de transpiración": se trata casi de los pequeños detalles y del trabajo cotidiano. Pero no es que de vez en cuando parte "inspiración", esa cosa "buen gusto" que es algo más que la solución de algunos problemas - la solución de forma limpia y bien y sí, incluso muy bien.

Y Junio ​​tenía ese "buen gusto".

Y cada vez que aparece Git, trato de recordar que debo dejarlo muy claro: es posible que haya comenzado y diseñado las ideas centrales en Git, pero a menudo obtengo demasiado crédito por esa parte. Han pasado más de 15 años, y realmente solo estuve involucrado con Git en ese primer año. Junio ​​ha sido un mantenedor ejemplar, y él es quien ha hecho de Git lo que es hoy.

Por cierto, todo esto del "buen gusto" y encontrar personas que lo tengan y confiar en ellos, no se trata solo de Git. También es en gran medida la historia de Linux. A diferencia de Git, Linux es, obviamente, un proyecto que todavía no mantengo activa, pero muy parecido a Git, también es un proyecto con un montón de otras personas involucradas, y creo que uno de los grandes éxitos de Linux es tener, literalmente, cientos de mantenedores de la vuelta, todo con ese "buen gusto" difícil de definir, y todas las personas que mantienen partes del núcleo.

JA: ¿Alguna vez le ha dado el control a un mantenedor para luego determinar que fue una decisión equivocada?

LT: Nuestra estructura de mantenimiento nunca ha sido tan en blanco y negro e inflexible como para que eso haya sido un problema. De hecho, no es como si hiciéramos que el control de mantenimiento sea algo muy documentado: tenemos un archivo MAINTAINERS, pero eso es para que pueda encontrar a las personas adecuadas, no es realmente una señal de propiedad exclusiva.

Entonces, todo "quién es dueño de qué" es más una pauta fluida, y un "esta persona es activa y está haciendo un buen trabajo" que algunos "oops, ahora le dimos la propiedad a esa persona y luego la cagó".

Y es fluido también en el sentido de que tal vez usted sea el responsable de mantenimiento de un subsistema, pero si hay algo que necesita de otro subsistema, a menudo puede cruzar fronteras. Por lo general, es algo de lo que la gente habla mucho antes de hacerlo, por supuesto, pero el punto es que sucede y no es una regla del tipo " solo se supone que debes tocar ese archivo".

De hecho, esto está algo relacionado con la discusión anterior sobre la licencia, y otro ejemplo de cómo uno de los principios de diseño de "Git" era que "todos tienen su propio árbol, y ningún árbol es técnicamente especial".

Debido a que una gran cantidad de otros proyectos han utilizado herramientas - como CVS o SVN - que, fundamentalmente, no hacen que algunas personas especiales, y que hace fundamentalmente tener una "propiedad" que va junto con él. En el mundo BSD, lo llaman el "bit de confirmación": darle a un mantenedor el "bit de confirmación" significa que ahora se le permite comprometerse con el repositorio central (o al menos partes de él).

Siempre detesté ese modelo, porque inevitablemente da como resultado la política y el modelo de desarrollo de la "camarilla", donde algunas personas son especiales e implícitamente confiables. Y el problema no es ni siquiera la parte de "confianza implícita"; en realidad, la otra cara de la moneda es que no se confía en otras personas y, por definición, son forasteros y tienen que pasar por uno de los guardianes.

Nuevamente, en Git ese tipo de situación no existe. Todos somos iguales. Cualquiera puede hacer un clon, hacer su propio desarrollo, y si hacen un buen trabajo, pueden volver a fusionarse (y si hacen un trabajo sobresaliente, se convierten en mantenedores y terminan siendo los que se fusionan en sus árboles; ).

Por lo tanto, no es necesario otorgar privilegios especiales a las personas, no es necesario ese "bit de compromiso". Y eso también significa que evita las políticas que lo rodean y no necesita confiar implícitamente en las personas. Si terminan haciendo un mal trabajo, o más comúnmente, simplemente terminan desvaneciéndose y encontrando otro interés, no se fusionan y tampoco se interponen en el camino de otras personas que tienen nuevas ideas frescas.

JA: ¿Alguna vez te impresionan las nuevas funciones de Git y se convierten en parte de tu flujo de trabajo? ¿Hay funciones que aún le gustaría que se agreguen?

LT: Obviamente, mis casos de uso fueron los primeros en cumplirse, por lo que para mí rara vez se trata de nuevas características.

A lo largo de los años, Git ciertamente ha mejorado, y algo de eso también se ha notado en mi flujo de trabajo. Por ejemplo, Git siempre ha sido bastante rápido (después de todo, era uno de mis objetivos de diseño), pero mucho de esto se hizo originalmente como script de shell en algunos programas auxiliares centrales. A lo largo de los años, la mayor parte de ese script de shell ha desaparecido, y eso significa que puedo aplicar bombas de parche de Andrew Morton incluso más rápido de lo que podía originalmente. Lo cual es muy gratificante, ya que en realidad fue uno de los primeros puntos de referencia que utilicé para las pruebas de rendimiento.

Así que Git siempre ha sido bueno para mí, pero ha mejorado.

Las grandes mejoras se han centrado en cuánto mejor se ha vuelto su uso como "usuario habitual". Mucho de eso ha sido gente aprendiendo el flujo de trabajo de Git y simplemente acostumbrándose a él ( es muy diferente de CVS y otras cosas a las que la gente solía estar acostumbrada), pero mucho de eso es que Git mismo se ha vuelto mucho más agradable usar.

Conclusión, primera parte

En la segunda parte de esta entrevista, Linus habla sobre lo que ha aprendido al gestionar un gran proyecto de código abierto. Ofrece mucha información y consejos a los mantenedores sobre lo que ha encontrado que funciona mejor para él y cómo evita el agotamiento. También habla sobre la Fundación Linux y lo que hace cuando no se concentra en desarrollar el kernel de Linux.

Fuente y original en Inglés: Tag 1 consulting.