Qu'est-ce que Linus Torvalds a voulu dire par sa citation sur la portabilité? [fermé]

Dans un débat avec Andrew Tanenbaum sur l'architecture du système d'exploitation microkernel et monolithique, Linus Torvalds a déclaré:

La portabilité est destinée aux personnes qui ne peuvent pas écrire de nouveaux programmes.

Que voulait-il dire par là?

Comme Linus écrit dans le débat, c'est avec la langue dans la joue (à ne pas prendre trop au sérieux).

Il explique ensuite que, si la portabilité est une bonne chose, elle représente également un compromis. Le code non transférable peut être beaucoup plus simple. C'est-à-dire qu'au lieu de rendre le code parfaitement portable, il suffit de le rendre suffisamment simple et portable ("adhérer à une API portable"), puis de le réécrire si nécessaire en cas de portage. Rendre le code parfaitement portable peut également être perçu comme une forme d'optimisation prématurée - souvent plus dommageable que bénéfique.

Bien sûr, ce n’est pas possible si vous ne pouvez pas écrire de nouveaux programmes et devez vous en tenir à l’original :)

Je pense que cela signifie que chaque programme doit être écrit spécifiquement pour le matériel et le système d'exploitation sur lesquels il s'exécute.

Je pense que ce qu’il conduit, c’est que le code à usage général pouvant fonctionner sur plusieurs plates-formes est moins efficace ou plus sujet aux erreurs que le code écrit spécifiquement pour une plate-forme et adapté à elle. Cela signifie toutefois que lorsque vous développez de la sorte, vous devez gérer plusieurs lignes de code différentes.

À l'époque de la première écriture de Linux, Linux utilisait des fonctionnalités disponibles uniquement sur le processeur i386, relativement nouveau et coûteux à l'époque.

C’est exactement ce que fait Linux: il utilise un plus grand sous-ensemble de fonctionnalités que les autres noyaux. Bien sûr, cela rend le noyau inportable, mais cela permet également une conception beaucoup plus simple. Un compromis acceptable, et qui a rendu Linux possible en premier lieu.

À l'aube du XXIe siècle, les fonctionnalités qui ont rendu l'i386 unique sont devenues totalement courantes, permettant ainsi à Linux de devenir très portable.

En tant que personne qui a beaucoup utilisé Java et expérimenté le phénomène "écrire une fois, déboguer partout" toutes les semaines, je peux tout à fait comprendre.

Et Java est probablement un exemple peu grave. Je ne peux même pas commencer à imaginer ce que vivent les personnes qui essaient de créer une base de code portable dans un langage / une boîte à outils qui n'a même pas été conçue pour être portable en soi.

En ce moment au travail, nous étudions l’idée d’écrire une version allégée de l’un de nos produits pour appareils mobiles. J'ai fait quelques recherches sur la façon de créer une version portable de J2ME et d'Android - qui tente de partager autant de code-base que possible (évidemment, il ne peut pas être entièrement "portable", mais c'est une philosophie similaire. ) C'est un cauchemar.

Alors oui, parfois, il est bon de pouvoir penser (et faire) en termes d'utilisation des outils donnés pour le travail donné. C'est-à-dire se développant librement contre une seule plate-forme / environnement monolithique. Et juste d'écrire des versions distinctes et propres pour chacun.

Bien que certaines personnes considèrent / traitent la portabilité, le respect des normes, etc., comme moralement supérieure, ou quelque chose du même ordre, cela revient en réalité à des considérations économiques.

L'écriture de code portable a un coût en termes d'effort pour le rendre portable, et (souvent) renonce à certaines fonctionnalités qui ne sont pas disponibles sur toutes les cibles.

Le code non portable a un coût en termes d'effort de transfert du code lorsque vous vous souciez d'une nouvelle architecture et (souvent) de renoncer à certaines fonctionnalités qui ne sont pas (ou n'étaient) pas disponibles sur la cible d'origine.

Le gros qualificatif est "quand / si vous vous souciez d'une nouvelle architecture". L'écriture de code portable nécessite des efforts immédiats dans l' espoir d'un gain éventuel de pouvoir utiliser ce code sur des architectures nouvelles / différentes avec peu d'effort, voire aucun effort. Le code non portable vous permet de retarder cet investissement dans le portage jusqu'à ce que vous soyez (au moins raisonnablement) certain que vous devez vraiment porter le portage vers une cible particulière.

Si, dès le départ, vous êtes certain de cibler un grand nombre d'objectifs, il vaut généralement la peine d'investir dès le départ pour réduire les coûts de portage à long terme. Si vous n'êtes pas certain de la quantité (ou même de la nécessité) du portage du code, écrire du code non portable permet de minimiser les coûts initiaux, de retarder voire d'éviter complètement le coût de la transférabilité du code.

Je pense qu'il est également intéressant de noter que j'ai parlé de "portable" et de "non-portable" comme s'il y avait une division nette entre les deux. En réalité, ce n'est pas vrai - la portabilité est un continuum allant de non totalement portable (code d'assemblage, par exemple) à extrêmement portable (par exemple, Info-zip) et partout entre les deux.

Tanenbaum souligne qu'une grande partie de Linux est écrite de manière non modulaire pour exploiter le processeur 386, à la pointe de la technologie à l'époque, au lieu de faire de l'interaction du processeur un composant et donc très facilement échangeable. Tanenbaum croit essentiellement que le fait que le noyau soit si monolithique et lié au processeur 386 rend très difficile la

• Port Linux lui-même sur une autre plate-forme de CPU (évidemment incorrect, AMD64, PowerPC, etc.)
• Programmes de port écrits pour Linux x86 sur une autre architecture de processeur (également incorrect)

Le camp Linux a plusieurs points parmi lesquels:

• Linux propose un système de fichiers multithread dans le cadre de la conception
• Le micro-noyau, bien qu'intéressant et intuitif, n'est pas très performant
• L'adhésion à l'API portable rend le problème de la portabilité plus ou moins difficile, par opposition à un bloqueur.

Si vous voulez écrire du code portable, vous devez écrire du code portable.

Qu'est-ce que je veux dire par là?

La conception doit refléter le but. Si le langage est C, par exemple, concevez-le de sorte que le nombre minimum de lignes de code doit être modifié pour que cela fonctionne. Cela voudrait souvent dire séparer l’affichage du calcul, ce qui est quand même une bonne philosophie de conception (MVC). La plupart du code C peut être compilé n'importe où, à condition que vous ayez accès à un bon compilateur. Tirez parti de cela et écrivez autant que vous le pouvez pour être générique.

BTW, cette réponse ne s'appliquera qu'aux applications. OS et intégré sont un autre animal entièrement.

Interprétez cette déclaration "littéralement" telle qu'elle est.

Dans une autre citation de Linus, il a déclaré: "Le C ++ tente de résoudre tous les faux problèmes. Les choses que C ++ résout sont des choses triviales, des extensions presque purement syntaxiques du C plutôt que de résoudre un problème vraiment profond".

Toujours dans sa biographie, "Just For Fun" linus, citant à propos de micro-noyaux, a déclaré que, pour un problème de complexité, il est impossible de diviser le problème en parties uniques "1 / n". soyez 'n!' cela en soi est un facteur suffisant pour ne pas tenter cela, et il serait très difficile d'extraire l'efficacité d'un système aussi complexe.

Il faut prendre en compte le fait que, lors de ces débats, Linux était très nouveau et était en grande partie un système d'exploitation uniquement. Je pense que si vous demandiez à Linus aujourd'hui, il aurait un avis différent. Peut-être pas aussi extrême que Tannenbaums, mais il va probablement hocher la tête et dire qu'il avait raison sur certaines choses.

Linus et les autres développeurs du noyau ont eu beaucoup de mal à rendre Linux portable, mais encore une fois, Linux n’aurait peut-être jamais existé si Linus avait dû le rendre portable pour commencer.

Cela signifie que les personnes qui peuvent écrire de bons programmes n'ont pas besoin que les choses soient portables, car elles peuvent travailler à partir de zéro.

Ce sont les programmeurs moins doués qui veulent "importer" d'autres programmes (portabilité) dans le programme actuel.