Was meinte Linus Torvalds mit seinem Zitat über Portabilität? [geschlossen]

In einer Debatte mit Andrew Tanenbaum über die Architektur von Mikrokernen und monolithischen Betriebssystemen sagte Linus Torvalds :

Portabilität ist für Leute, die keine neuen Programme schreiben können.

Was meinte er damit?

Wie Linus in der Debatte schreibt, ist es mit der Zunge in der Wange (dh nicht zu ernst genommen werden).

Dann erklärt er weiter, dass Portabilität zwar eine gute Sache ist, aber auch ein Kompromiss. nicht portierbarer Code kann viel einfacher sein. Das heißt, anstatt den Code perfekt portierbar zu machen, machen Sie ihn einfach und portierbar genug ("halten Sie sich an eine portable API"), und wenn er portiert werden muss, schreiben Sie ihn nach Bedarf neu. Die perfekte Portierung von Code kann auch als eine Form der vorzeitigen Optimierung angesehen werden - oft mehr schaden als nützen.

Das ist natürlich nicht möglich, wenn Sie keine neuen Programme schreiben können und sich an das Original halten müssen :)

Ich denke, es bedeutet, dass jedes Programm speziell für die Hardware und das Betriebssystem geschrieben werden sollte, auf dem es ausgeführt wird.

Ich denke, was ihn antreibt, ist, dass Universalcode, der auf mehreren Plattformen ausgeführt werden kann, weniger effizient oder fehleranfälliger ist als Code, der speziell für eine Plattform geschrieben und auf diese zugeschnitten ist. Dies bedeutet jedoch, dass Sie bei einer solchen Entwicklung mehrere verschiedene Codezeilen pflegen müssen.

Als Linux zum ersten Mal geschrieben wurde, verwendete es Funktionen, die nur auf der i386-CPU verfügbar waren, die zu dieser Zeit noch relativ neu und teuer war.

Genau das macht Linux: Es verwendet nur einen größeren Teil der 386-Funktionen, als es andere Kernel zu tun scheinen. Natürlich macht dies den eigentlichen Kernel nicht portierbar, aber es macht auch ein / viel / einfacheres Design möglich. Ein akzeptabler Kompromiss, der Linux überhaupt erst möglich gemacht hat.

Als wir in das 21. Jahrhundert gingen, wurden die Funktionen, die den i386 einzigartig machten, zum Mainstream, wodurch Linux sehr portabel wurde.

Als jemand, der viel mit Java zu tun hat und jahrelang das Phänomen "Einmal schreiben, überall debuggen" auf wöchentlicher Basis erlebt hat, kann ich mich voll darauf beziehen.

Und Java ist wahrscheinlich ein mildes Beispiel. Ich kann mir gar nicht vorstellen, was Leute durchmachen, die versuchen, eine tragbare Codebasis in einer Sprache / einem Toolkit zu verwenden, die / das nicht einmal für sich selbst tragbar war.

Im Moment untersuchen wir die Idee, eine Lite-Version eines unserer Produkte für mobile Geräte zu schreiben. Ich habe einige Nachforschungen angestellt, wie man eine portable Version davon sowohl für J2ME als auch für Android machen kann - die versucht, so viel von der Codebasis wie möglich zu teilen (kann natürlich nicht per se "portabel" sein, aber es ist eine ähnliche Philosophie ). Es ist ein Albtraum.

Also ja, manchmal ist es wirklich gut, in der Lage zu sein, in Bezug auf die Verwendung der gegebenen Werkzeuge für den gegebenen Job zu denken (und zu tun). dh sich frei gegen eine einzelne monolithische Plattform / Umgebung entwickeln. Und schreiben Sie einfach separate, saubere Versionen für jede.

Obwohl manche Menschen die Portabilität, die Einhaltung von Standards usw. als moralisch überlegen oder als etwas in dieser Reihenfolge ansehen / betrachten, läuft es wirklich auf die Wirtschaftlichkeit hinaus.

Das Schreiben von portablem Code ist mit einem hohen Aufwand verbunden, um den Code portabel zu machen und (häufig) auf einige Funktionen zu verzichten, die nicht für alle Ziele verfügbar sind.

Nicht portierbarer Code verursacht einen erheblichen Aufwand beim Portieren des Codes, wenn / wenn Sie sich für eine neue Architektur interessieren und (oft) auf einige Funktionen verzichten, die auf dem ursprünglichen Ziel nicht verfügbar sind (oder waren).

Das große Kriterium ist "wann / ob Sie sich für eine neue Architektur interessieren". Das Schreiben von portablem Code erfordert von vornherein Anstrengungen in der Hoffnung, dass sich die Verwendung dieses Codes für neue / andere Architekturen mit geringem oder gar keinem Aufwand auszahlt. Mit nicht portierbarem Code können Sie die Investition in die Portierung verzögern, bis Sie (zumindest vernünftigerweise) sicher sind, dass Sie wirklich auf ein bestimmtes Ziel portieren müssen.

Wenn Sie sich im Vorfeld sicher sind, dass Sie viele Ziele portieren werden, lohnt es sich normalerweise, im Vorfeld in die Minimierung der langfristigen Portierungskosten zu investieren. Wenn Sie sich weniger sicher sind, wie viel (oder sogar ob) Sie den Code portieren müssen, können Sie durch das Schreiben von nicht portierbarem Code die Vorlaufkosten minimieren, die Kosten für die Portierung des Codes verzögern oder möglicherweise sogar ganz vermeiden.

Ich denke, es ist auch erwähnenswert, dass ich von "tragbar" und "nicht tragbar" gesprochen habe, als ob es eine klare Trennung zwischen den beiden gäbe. In Wirklichkeit stimmt das nicht - Portabilität ist ein Kontinuum, das von vollständig nicht portierbar (z. B. Assembler-Code) bis extrem portierbar (z. B. Info-zip) und überall dazwischen reicht.

Tanenbaum weist darauf hin, dass ein Großteil von Linux nicht modular geschrieben ist, um die derzeitige 386-CPU zu nutzen, anstatt die CPU-Interaktion zu einer Komponente zu machen und damit sehr einfach auszutauschen. Tanenbaum glaubt im Wesentlichen, dass die Tatsache, dass der Kernel so monolithisch und an 386 CPU gebunden ist, es sehr schwierig macht,

• Linux selbst auf eine andere CPU-Plattform portieren (offensichtlich falsch, AMD64, PowerPC usw.)
• Port Programme, die für Linux x86 geschrieben wurden, auf eine andere CPU Architektur (auch falsch)

Das Linux-Camp macht mehrere Punkte, unter denen:

• Linux bietet als Teil des Designs ein Multithread-Dateisystem an
• Mikrokernel sind zwar interessant und intuitiv, aber nicht sehr performant
• Durch die Einhaltung portabler APIs wird das Portabilitätsproblem im Gegensatz zu einem Blocker zum Problem.

Wenn Sie portablen Code schreiben möchten, müssen Sie portablen Code schreiben.

Was meine ich damit

Das Design muss den Zweck widerspiegeln. Wenn die Sprache beispielsweise C ist, entwerfen Sie sie so, dass sich die Mindestanzahl der Codezeilen ändern muss, damit sie funktioniert. Dies würde oft bedeuten, das Display von der Berechnung zu trennen, was ohnehin eine gute Designphilosophie (MVC) ist. Der meiste C-Code kann überall kompiliert werden, vorausgesetzt, Sie haben Zugriff auf einen guten Compiler. Nutzen Sie das und schreiben Sie so viel wie möglich, um generisch zu sein.

Übrigens gilt diese Antwort nur für Bewerbungen. OS und Embedded sind ein ganz anderes Tier.

Interpretieren Sie diese Aussage "wörtlich" so, wie sie ist.

In einem anderen Zitat von Linus sagte er: "C ++ versucht, alle falschen Probleme zu lösen. Die Dinge, die C ++ löst, sind triviale Dinge, fast rein syntaktische Erweiterungen von C, anstatt ein echtes tiefes Problem zu beheben."

Auch in seiner Biografie, "Just For Fun", sagte Linus unter Bezugnahme auf Mikrokerne, dass für ein Problem mit Komplexität "n", wenn Sie das Problem in "1 / n" eindeutige Teile unterteilen, die Gesamtkomplexität der Entwicklung eines solchen Systems wäre sei 'n!' Dies selbst ist ein Faktor, der ausreicht, um so etwas nicht zu versuchen, und es wäre sehr schwierig, die Effizienz eines solch komplexen Systems zu ermitteln.

Man muss berücksichtigen, dass Linux während dieser Debatten sehr neu war und größtenteils nur ein 386-Betriebssystem war. Ich denke, wenn Sie heute Linus fragen würden, hätte er eine andere Meinung. Vielleicht nicht ganz so extrem wie Tannenbaums, aber er wird wahrscheinlich ein Nickerchen machen und sagen, dass er in einigen Dingen Recht hatte.

Linus und die anderen Kernel-Entwickler haben große Anstrengungen unternommen, um Linux portabel zu machen. Andererseits hätte Linux möglicherweise nie existiert, wenn Linus es zunächst portabel hätte machen müssen.

Das bedeutet, dass Leute, die gute Programme schreiben können, keine tragbaren Dinge benötigen, da sie von Grund auf neu arbeiten können.

Es sind weniger begabte Programmierer, die andere Programme (Portabilität) in das aktuelle "importieren" möchten.