Linus Torvaldsは、移植性についての引用で何を意味しましたか？[閉まっている]

でアンドリュー・タネンバウムとの議論モノリシックオペレーティング・システム・アーキテクチャ対マイクロカーネルの上に、Linus Torvalds氏は、言いました

移植性は、新しいプログラムを作成できない人向けです。

彼はどういう意味ですか？

Linusが議論の中で書いているように、それは頬に舌を使っている（つまり、あまり真剣に受け止められない）。

次に、移植性は良いことですが、トレードオフでもあると説明します。移植性のないコードははるかに簡単です。つまり、コードを完全に移植可能にするのではなく、単純かつ十分に移植可能（「移植可能な APIに準拠」）にし、移植する必要がある場合は、必要に応じて書き換えます。コードを完全に移植可能にすることは、時期尚早な最適化の一形態と見なすこともできます。

もちろん、新しいプログラムを書くことができず、元のプログラムに固執しなければならない場合、それは不可能です:)

つまり、各プログラムは、それが実行されるハードウェアとオペレーティングシステム専用に作成されるべきだと思います。

彼が推進しているのは、複数のプラットフォームで実行できる汎用コードは、1つのプラットフォーム用に特別に作成されたコードよりも効率が悪いか、エラーが発生しやすいと思うからです。ただし、このように開発する場合は、いくつかの異なるコード行を維持する必要があります。

Linuxが最初に書かれたときは、i386 CPUでのみ利用可能な機能を使用していましたが、これは当時かなり新しく高価でした。

それはまさにLinuxが行うことです。他のカーネルが行うように見えるよりも、386の機能の大きなサブセットを使用するだけです。もちろん、これによりカーネルの適切な移植性は失われますが、/ much /より簡単な設計にもなります。許容できるトレードオフであり、そもそもLinuxを可能にしたものです。

21世紀に入って、i386をユニークなものにする機能が完全に主流になり、Linuxが非常に移植可能になりました。

多くのJavaを実行し、「ライトワンス、どこでもデバッグ」現象を何年にもわたって毎週経験している人として、私はこれに完全に関連することができます。

そして、Javaはおそらく穏やかな例です。言語/ツールキットの移植可能なコードベースで、それ自体は移植可能にさえ設計されていなかった人々が、何をしようとしているか想像することさえできません。

現在、私たちは、モバイルデバイス向けの製品の1つのライトバージョンを作成するアイデアを調査しています。J2MEとAndroidの両方で移植可能なバージョンを作成する方法についていくつか調査しました-コードベースを可能な限り共有しようとします（明らかに、完全に「ポータブル」にすることはできませんが、それは同様の哲学です） ）。悪夢です。

ええ、時には、与えられた仕事に与えられたツールを使用するという観点で考えることができるのは本当に良いことです。すなわち、1つの単一のモノリシックプラットフォーム/環境に対して自由に開発できます。そして、それぞれに別々のクリーンなバージョンを書くだけです。

一部の人々は、ポータビリティ、標準に従うなどを道徳的に優れている、またはその順序の何かと見なしますが、それは実際に経済学です。

移植可能なコードを書くことは、コードを移植可能にするための努力の点でコストがかかり、（多くの場合）すべてのターゲットで利用できないいくつかの機能を先取りします。

移植性のないコードには、新しいアーキテクチャに関心がある場合/場合にコードを移植するための労力、および（多くの場合）元のターゲットでは利用できない（または利用できなかった）いくつかの機能について、コストがかかります。

そこにある大きな修飾子は「いつ/新しいアーキテクチャを気にするか」です。移植性のあるコードを書くには、新しい/異なるアーキテクチャでそのコードをほとんどまたはまったく労力なしで使用できるという最終的な見返りを期待して、事前の努力が必要です。移植性のないコードを使用すると、特定のターゲットに移植する必要があると（少なくとも合理的に）確信するまで、移植への投資を遅らせることができます。

多くのターゲットに移植することを事前に確信している場合、通常、長期的な移植コストを最小限に抑えるために事前投資する価値があります。コードを移植する必要があるかどうか（または場合でも）が不確実な場合は、移植性のないコードを記述すると、初期コストを最小限に抑えることができ、コードを移植可能にするコストを遅らせるか、場合によっては完全に回避できます。

また、「ポータブル」と「非ポータブル」について、両者の間に明確な境界があるかのように話したことにも注目する価値があると思います。現実にはそうではありません。移植性は完全に移植性のないもの（アセンブリコードなど）から非常に移植性のあるもの（Info-zipなど）まで、そしてその中間のあらゆる場所で実行されます。

Tanenbaumは、CPUの相互作用をコンポーネントにして、非常に簡単に交換できるのではなく、当時の最先端の386 CPUを活用するために、Linuxの多くが非モジュール方式で記述されていることを指摘しています。Tanenbaumは基本的に、カーネルが非常にモノリシックであり、386 CPUに関連付けられているという事実により、

• Linux自体を別のCPUプラットフォームに移植します（明らかに不正、AMD64、PowerPCなど）
• Linux x86用に作成されたプログラムを別のCPUアーキテクチャに移植する（これも正しくありません）

Linuxキャンプにはいくつかのポイントがあります。

• Linuxは、設計の一部としてマルチスレッドファイルシステムを提供しています
• マイクロカーネルは、面白くて直感的ではありませんが、あまりパフォーマンスがありません
• 移植性のあるAPIの順守により、ブロッカーとは対照的に、移植性の問題がさらに大きくなるか、ささいな問題になります。

移植可能なコードを作成する場合は、移植可能なコードを作成する必要があります。

それはどういう意味ですか？

設計は目的を反映する必要があります。たとえば、言語がCの場合、動作するためにコードの最小行数を変更する必要があるように設計します。これは、多くの場合、ディスプレイを計算から分離することを意味します。これは、とにかく優れた設計哲学（MVC）です。優れたコンパイラにアクセスできれば、ほとんどのCコードはどこでもコンパイルできます。それを活用し、できるだけ多くのことを書いてジェネリックにします。

ところで、この回答はアプリケーションにのみ適用されます。OSと組み込みは完全に別の動物です。

この文を「文字通り」そのまま解釈します。

Linusの別の引用では、「C ++はすべての間違った問題を解決しようとしています。C++が解決するのは些細なことで、真の深い問題を修正するのではなく、ほとんど純粋にCの構文拡張です」。

また、彼の伝記では、マイクロカーネルについて引用している「Just For Fun」ライナスは、問題を「1 / n」個の部分に分割すると、複雑さ「n」の問題について述べた。 「n！」これ自体は、そのようなことを試みないほど十分な要因であり、そのような複雑なシステムから効率を引き出すことは非常に難しいでしょう。

これらの議論の間、Linuxは非常に新しく、大部分が386のみのOSであったという事実を考慮する必要があります。もしあなたが今日Linusに尋ねたら、彼は別の意見を持つだろうと思う。たぶんタンネンバウムほど極端ではないかもしれないが、彼はおそらく姫にうなずき、彼はいくつかのことについて正しかったと言うだろう。

Linusと他のカーネル開発者は、Linuxを移植可能にするために多くの苦労を経験しましたが、Linusを最初から移植可能にしなければならなかったとしても、Linuxは存在しなかったかもしれません。

つまり、優れたプログラムを作成できる人は、一から作業することができるため、移植性のあるものを必要としません。

他のプログラム（移植性）を現在のプログラムに「インポート」したいプログラマーはあまり才能がありません。