Em qualquer sistema interdependente, existem basicamente duas opções. Abstração e integração. (De propósito, não estou usando termos técnicos). Com o Abstraction, você está dizendo que quando você faz uma chamada para uma API que, embora o código por trás da API possa mudar, o resultado será sempre o mesmo. Por exemplo, quando ligamos para fs.open()nós, não nos importamos se é uma unidade de rede, um SSD ou um disco rígido, sempre teremos um descritor de arquivo aberto com o qual podemos fazer coisas. Com a "integração", o objetivo é fornecer a "melhor" maneira de fazer uma coisa, mesmo que a maneira mude. Por exemplo, abrir um arquivo pode ser diferente para um compartilhamento de rede e para um arquivo em disco. Ambas as formas são usadas amplamente na área de trabalho moderna do Linux.
Do ponto de vista dos desenvolvedores, é uma questão de "funciona com qualquer versão" ou "funciona com uma versão específica". Um ótimo exemplo disso é o OpenGL. A maioria dos jogos está configurada para funcionar com uma versão específica do OpenGL. Não importa se você está compilando a partir do código-fonte. Se o jogo foi escrito para usar o OpenGL 1.1 e você está tentando executá-lo no 3.x, não vai se divertir. Do outro lado do espectro, espera-se que algumas ligações funcionem, não importa o quê. Por exemplo, quero ligar fs.open()Não quero me importar com a versão do kernel em que estou. Eu só quero um descritor de arquivo.
Existem benefícios para cada caminho. A integração fornece recursos "mais recentes" ao custo da compatibilidade com versões anteriores. Enquanto a abstração fornece estabilidade em relação às chamadas "mais recentes". Embora seja importante notar que é uma questão de prioridade, não de possibilidade.
Do ponto de vista comunitário, sem uma razão realmente boa, a abstração é sempre melhor em um sistema complexo. Por exemplo, imagine se fs.open()funcionasse de maneira diferente, dependendo da versão do kernel. Então, uma biblioteca de interação simples do sistema de arquivos precisaria manter várias centenas de métodos diferentes de "arquivo aberto" (ou blocos provavelmente). Quando uma nova versão do kernel foi lançada, você não seria capaz de "atualizar", teria que testar cada software usado. O kernel 6.2.2 (falso) pode apenas quebrar o seu editor de texto.
Para alguns exemplos do mundo real, o OSX tende a não se importar com a quebra do espaço do usuário. Eles visam "integração" sobre "abstração" com mais frequência. E a cada atualização importante do sistema operacional, as coisas acontecem. Isso não quer dizer que uma maneira seja melhor que a outra. É uma decisão de escolha e design.
Mais importante ainda, o ecossistema Linux é repleto de projetos incríveis de código aberto, onde pessoas ou grupos trabalham no projeto em seu tempo livre ou porque a ferramenta é útil. Com isso em mente, no momento em que deixa de ser divertido e passa a ser uma PIA, esses desenvolvedores irão para outro lugar.
Por exemplo, enviei um patch para BuildNotify.py. Não porque sou altruísta, mas porque uso a ferramenta e queria um recurso. Foi fácil, então aqui, tem um patch. Se fosse complicado ou complicado, eu não usaria BuildNotify.pye encontraria outra coisa. Se toda vez que uma atualização do kernel fosse lançada, meu editor de texto falhasse, eu usaria apenas um sistema operacional diferente. Minhas contribuições para a comunidade (por menores que sejam) não continuariam ou existiriam, e assim por diante.
Portanto, a decisão de design foi tomada para abstrair as chamadas do sistema, para que, quando eu fizer fs.open(), funcione. Isso significa manter fs.openmuito tempo depois de fs.open2()ganhar popularidade.
Historicamente, esse é o objetivo dos sistemas POSIX em geral. "Aqui estão um conjunto de chamadas e valores de retorno esperados, você descobre o meio". Novamente por motivos de portabilidade. Por que Linus escolhe usar essa metodologia é interno ao cérebro dele, e você teria que pedir que ele soubesse exatamente o porquê. No entanto, se fosse eu, escolheria a abstração ao invés da integração em um sistema complexo.