移植性についての彼の引用によると、Linus Torvaldsは何を意味しましたか？
Andrew Tanenbaumとの議論 マイクロカーネルとモノリシックオペレーティングシステムアーキテクチャの比較 Linus Torvalds は、
移植性は、新しいプログラムを作成できない人向けです。
それはどういう意味ですか。
Linusが討論で書いているように、それはほっそりした舌で（つまり、あまり真剣に受け取られてはいけません）。
次に、移植性は良いことですが、トレードオフでもあることを説明します。移植性のないコードは、はるかに簡単です。つまり、コードを完全に移植可能にする代わりに、単純に十分に移植可能（ "移植可能なAPIに準拠"）し、移植する必要がある場合は、必要に応じてコードを書き直します。コードを完全に移植可能にすることは、時期尚早の最適化の一形態と見なすこともできます。
もちろん、あなたが新しいプログラムを書くことができず、元のプログラムに固執しなければならない場合、それは不可能です:)
各プログラムは、ハードウェアとそれが実行されるオペレーティングシステム用に特別に作成する必要があることを意味します。
彼が推進しているのは、複数のプラットフォームで実行できる汎用コードは、1つのプラットフォーム用に特別に作成されたコードよりも効率が低く、エラーが発生しやすいということです。ただし、このように開発する場合は、いくつかの異なるコード行を維持する必要があることを意味します。
Linuxが最初に作成されたとき、Linuxはi386 CPUでのみ利用可能な機能を使用していましたが、当時はかなり新しく高価でした。
これはまさにlinuxが行うことです。それは他のカーネルが行うように見える386機能のより大きなサブセットを使用するだけです。もちろん、これはカーネルを適切に移植不可能にしますが、/ much /のより単純な設計にもなります。許容できるトレードオフと、そもそもLinuxを可能にしたトレードオフ。
21世紀に入って、i386をユニークなものにする機能が完全に主流になり、Linuxの移植性が非常に高くなりました。
多くのJavaを実行し、何週間にもわたって「書き込み1回、どこでもデバッグ」現象を毎週経験した人として、私はこれに完全に関係することができます。
また、Javaはおそらく穏やかな例です。設計されていない言語/ツールキットのポータブルコードベースで、人々が何をしようとするのか想像すらできません。それ自体でポータブルです。
現在作業中ですが、モバイルデバイス向け製品のライトバージョンを作成する考えを調査しています。私はJ2MEとAndroid-可能な限り多くのコードベースを共有しようとします）のポータブルバージョンを実行する方法についていくつかの調査を行いました（明らかに、完全に「移植可能」にすることはできません「それ自体、それは同じような哲学です。それは悪夢です。
ええ、時々、与えられた仕事のために与えられたツールを使用することに関して考えることができる（そして実行できる）ことが本当に良い場合があります。つまり、1つの単一のモノリシックプラットフォーム/環境に対して自由に開発できます。そして、それぞれに別のクリーンなバージョンを書くだけです。
一部の人々は、移植性や標準などに従って、道徳的に優れている、またはその順序で何かと見なし/扱いますが、それは結局のところ経済学です。
移植可能なコードを書くことは、コードを移植可能にする努力の点でコストがかかり、（多くの場合）すべてのターゲットで利用できないいくつかの機能に先行します。
移植性のないコードは、新しいアーキテクチャに関心がある場合、またはその場合にコードを移植するための労力と、（多くの場合）元のターゲットで利用できない（または利用できなかった）いくつかの機能にコストがかかります。
そこにある大きな修飾子は、「いつ/新しいアーキテクチャを気にするか」です。移植可能なコードを書くには、少しまたはまったく努力をせずに新しい/異なるアーキテクチャでそのコードを使用できるという最終的な見返りのhopeで事前に努力が必要です。移植性のないコードを使用すると、特定のターゲットに本当に移植する必要があると（少なくとも合理的に）確信できるまで、移植への投資を遅らせることができます。
多くのターゲットに移植することを前もって確信している場合は、通常、長期的な移植コストを最小限に抑えるために前もって投資する価値があります。コードを移植する必要があるかどうか（または移植する場合でも）が不確かな場合、移植不可能なコードを作成すると、初期費用を最小限に抑え、コードを移植可能にするコストを遅らせたり、場合によっては完全に回避したりできます。
私が「ポータブル」と「非ポータブル」について話したことは、2つの間に明確な区分があったかのように注意することもまた価値があると思います。実際には、それは真実ではありません-移植性は、完全に移植性のない（例：アセンブリコード）から非常に移植性の高い（例：Info-Zip）まで、およびその間のあらゆる場所で実行される連続体です。
タネンバウムは、Linuxの大部分は、当時の最先端の386 CPUを活用するために非モジュール方式で記述されており、CPUの相互作用をコンポーネントにするのではなく、非常に簡単に交換できると主張しています。 Tanenbaumは基本的に、カーネルが非常にモノリシックで386 CPUに関連付けられているため、
- Linux自体を別のCPUプラットフォームに移植する（明らかに不正確、AMD64、PowerPCなど）
- Linux x86用に作成されたプログラムを別のCPUアーキテクチャに移植する（これも正しくない）
Linuxキャンプはいくつかの点を指摘しています。
- Linuxは、設計の一部としてマルチスレッドファイルシステムを提供します
- マイクロカーネルは、面白くて直感的ではありませんが、パフォーマンスはそれほど高くありません
- 移植可能なAPIの順守は、ブロッカーとは対照的に、移植性の問題をより多くするか、軽微にします。
移植可能なコードを記述したい場合は、移植可能なコードを記述する必要があります。
それはどういう意味ですか？
デザインは目的を反映する必要があります。たとえば、言語がCの場合、機能するために変更する必要があるコードの最小行数がわかるように設計します。これは多くの場合、表示を計算から分離することを意味します。これはとにかく優れた設計哲学（MVC）です。優れたコンパイラにアクセスできれば、ほとんどのCコードはどこでもコンパイルできます。それを活用して、できるだけ一般的になるように書いてください。
ところで、この回答はアプリケーションにのみ適用されます。 OSと組み込みは完全に別の動物です。
つまり、優れたプログラムを作成できる人は、ゼロから作業できるため、移植可能である必要はありません。
他のプログラム（移植性）を現在のプログラムに "インポート"する必要があるのは、あまり才能のないプログラマーです。
この文を「文字通り」に解釈します。
Linusの別の引用では、彼は次のように述べています。「C++はすべての間違った問題を解決しようとしています。C++ solvesはささいなことであり、真の深い問題を修正するのではなく、Cのほぼ純粋な構文拡張です」。
また、彼の経歴では、マイクロカーネルについて引用している「Just For Fun」ライナスは、複雑さ「n」の問題について、問題を「1/n」個の一意の部分に分割すると、そのようなシステムを開発する全体の複雑さは、 「n！」これ自体はそのようなことを試みないための十分な要因であり、そのような複雑なシステムから効率を引き出すことは非常に難しいでしょう。
これらの討論の間、Linuxは非常に新しく、主に386のみのOSであったという事実を考慮する必要があります。今日、Linusに尋ねると、彼は別の意見を持っていると思います。タネンバウムほど極端ではないかもしれませんが、彼は姫にうなずき、いくつかのことについては正しかったと言うでしょう。
Linusと他のカーネル開発者は、Linuxをポータブルにするために多くの苦労をしましたが、Linusが最初からポータブルにする必要があった場合、再び、Linuxは存在しなかったかもしれません。