En cualquier sistema interdependiente hay básicamente dos opciones. Abstracción e integración. (A propósito no estoy usando términos técnicos). Con Abstracción, estás diciendo que cuando haces una llamada a una API que, si bien el código detrás de la API puede cambiar, el resultado siempre será el mismo. Por ejemplo, cuando llamamos fs.open()no nos importa si se trata de una unidad de red, un SSD o un disco duro, siempre obtendremos un descriptor de archivo abierto con el que podamos hacer cosas. Con la "integración", el objetivo es proporcionar la "mejor" forma de hacer algo, incluso si la forma cambia. Por ejemplo, abrir un archivo puede ser diferente para un recurso compartido de red que para un archivo en el disco. Ambas formas se usan ampliamente en el escritorio moderno de Linux.
Desde el punto de vista de los desarrolladores, se trata de "funciona con cualquier versión" o "funciona con una versión específica". Un gran ejemplo de esto es OpenGL. La mayoría de los juegos están configurados para funcionar con una versión específica de OpenGL. No importa si estás compilando desde la fuente. Si el juego fue escrito para usar OpenGL 1.1 y estás intentando que se ejecute en 3.x, no lo vas a pasar bien. En el otro extremo del espectro, se espera que algunas llamadas funcionen sin importar qué. Por ejemplo, quiero llamar fs.open()No quiero importarme en qué versión del kernel estoy. Solo quiero un descriptor de archivo.
Hay beneficios en cada sentido. La integración proporciona características "más nuevas" a costa de la compatibilidad con versiones anteriores. Mientras que la abstracción proporciona estabilidad sobre las llamadas "más nuevas". Aunque es importante tener en cuenta que es una cuestión de prioridad, no de posibilidad.
Desde un punto de vista comunitario, sin una muy buena razón, la abstracción siempre es mejor en un sistema complejo. Por ejemplo, imagine si fs.open()funcionó de manera diferente dependiendo de la versión del kernel. Entonces, una simple biblioteca de interacción del sistema de archivos necesitaría mantener varios cientos de métodos diferentes de "archivo abierto" (o bloques probablemente). Cuando salió una nueva versión del kernel, no podría "actualizarse", tendría que probar cada pieza de software que utilizó. Kernel 6.2.2 (falso) puede simplemente romper su editor de texto.
Para algunos ejemplos del mundo real, OSX tiende a no preocuparse por romper el espacio del usuario. Apuntan a la "integración" sobre la "abstracción" con mayor frecuencia. Y en cada actualización importante del sistema operativo, las cosas se rompen. Eso no quiere decir que una forma es mejor que la otra. Es una decisión de elección y diseño.
Lo más importante es que el ecosistema de Linux está lleno de increíbles proyectos de código abierto, donde las personas o grupos trabajan en el proyecto en su tiempo libre, o porque la herramienta es útil. Con eso en mente, en el momento en que deja de ser divertido y comienza a ser un PIA, esos desarrolladores irán a otro lugar.
Por ejemplo, envié un parche a BuildNotify.py. No porque sea altruista, sino porque uso la herramienta y quería una función. Fue fácil, así que aquí tienes un parche. Si fuera complicado o engorroso, no lo usaría BuildNotify.pyy encontraría algo más. Si cada vez que salía una actualización del núcleo, mi editor de texto se rompía, simplemente usaría un sistema operativo diferente. Mis contribuciones a la comunidad (por pequeñas que sean) no continuarían ni existirían, y así sucesivamente.
Entonces, la decisión de diseño se tomó para abstraer las llamadas al sistema, de modo que cuando lo hago fs.open(), simplemente funciona. Eso significa mantener fs.openmucho tiempo después de fs.open2()ganar popularidad.
Históricamente, este es el objetivo de los sistemas POSIX en general. "Aquí hay un conjunto de llamadas y valores de retorno esperados, usted se da cuenta del medio". De nuevo por razones de portabilidad. El motivo por el cual Linus elige usar esa metodología es interno de su cerebro, y usted tendría que pedirle que sepa exactamente por qué. Sin embargo, si fuera yo, elegiría la abstracción sobre la integración en un sistema complejo.