Dans tous les systèmes interdépendants, il existe essentiellement deux choix. Abstraction et intégration. (Je n'utilise pas volontairement des termes techniques) Avec Abstraction, vous dites que lorsque vous appelez une API, le résultat sera toujours le même, même si le code derrière l'API peut changer. Par exemple, lorsque nous appelons fs.open(), peu importe qu'il s'agisse d'un lecteur réseau, d'un SSD ou d'un disque dur, nous obtiendrons toujours un descripteur de fichier ouvert avec lequel nous pourrons travailler. Avec "intégration", l’objectif est de fournir le "meilleur" moyen de faire une chose, même si la façon de le faire change. Par exemple, l'ouverture d'un fichier peut être différente pour un partage réseau et pour un fichier sur disque. Les deux méthodes sont assez utilisées dans le bureau Linux moderne.
Du point de vue des développeurs, il s’agit de "fonctionne avec n’importe quelle version" ou "fonctionne avec une version spécifique". OpenGL est un bon exemple de cela. La plupart des jeux sont configurés pour fonctionner avec une version spécifique d'OpenGL. Peu importe si vous compilez à partir des sources. Si le jeu a été écrit pour utiliser OpenGL 1.1 et que vous essayez de le faire tourner sous 3.x, vous n’allez pas passer un bon moment. À l’autre bout du spectre, certains appels devraient fonctionner de toute façon. Par exemple, je veux appeler fs.open()je ne veux pas me soucier de la version de mon noyau. Je veux juste un descripteur de fichier.
Il y a des avantages dans chaque sens. L'intégration fournit des fonctionnalités "plus récentes" au détriment de la compatibilité ascendante. Tandis que l’abstraction offre une stabilité par rapport aux appels "plus récents". Bien qu'il soit important de noter que c'est une question de priorité, pas de possibilité.
D'un point de vue commun, sans une très bonne raison, l'abstraction est toujours préférable dans un système complexe. Par exemple, imaginez si vous fs.open()travaillez différemment selon la version du noyau. Ensuite, une simple bibliothèque d’interaction avec le système de fichiers doit gérer plusieurs centaines de méthodes de "fichiers ouverts" (ou de blocs). Quand une nouvelle version du noyau est sortie, vous ne pouvez pas "mettre à jour", vous devez tester chaque logiciel que vous utilisez. Le noyau 6.2.2 (faux) peut juste casser votre éditeur de texte.
Pour certains exemples concrets, OSX a tendance à ne pas se soucier de casser l’espace utilisateur. Ils visent plus fréquemment «l'intégration» à «l'abstraction». Et à chaque mise à jour majeure du système d'exploitation, les choses se cassent. Cela ne veut pas dire qu'une façon est meilleure que l'autre. C'est un choix et une décision de conception.
Plus important encore, l'écosystème Linux regorge de projets Open Source impressionnants, dans lesquels des personnes ou des groupes travaillent sur le projet pendant leur temps libre ou parce que l'outil est utile. En gardant cela à l’esprit, à la seconde où cela cesse d’être amusant et commence à être une PIA, ces développeurs iront ailleurs.
Par exemple, j'ai soumis un correctif à BuildNotify.py. Non pas parce que je suis altruiste, mais parce que j'utilise l'outil et que je voulais une fonctionnalité. C'était facile, alors voici un patch. Si c'était compliqué ou lourd, je ne l'utiliserais pas BuildNotify.pyet je trouverais autre chose. Si chaque fois qu'une mise à jour du noyau était publiée, mon éditeur de texte tombait en panne, j'utiliserais simplement un système d'exploitation différent. Mes contributions à la communauté (si petites soient-elles) ne continueraient pas ou n'existeraient pas, etc.
Ainsi, la conception a été prise pour des appels système abstraits, de sorte que lorsque je le fais, fs.open()cela fonctionne. Cela signifie maintenir fs.openlongtemps après avoir fs.open2()gagné en popularité.
Historiquement, c'est l'objectif des systèmes POSIX en général. "Voici un ensemble d'appels et les valeurs de retour attendues, vous déterminez le milieu." Encore une fois pour des raisons de portabilité. Pourquoi Linus a choisi d'utiliser cette méthodologie est interne à son cerveau, et vous devrez lui demander de savoir exactement pourquoi. Si c’était moi cependant, je choisirais l’abstraction sur l’intégration sur un système complexe.