単純なユーザーはLinuxカーネル開発に参加できますか？ なぜこれが必要で、何につながるのか

少し前、Habré- Brain Fuck Scheduler-でトピックが5分で公開されました。これは、Ubuntuの例を使用して、代替のスケジューラーをLinuxカーネルにインストールすることに関するものでした。 プランナーの作成者はCon Kolivasであり、しばらくの間、彼はカーネルのパッチのかなり有名な開発者でした。 しかし、その後彼は活動を停止しました。 この名前の後ろにどんな人が隠れているのか知りたいと思いました。 Kolivasは、彼の主な仕事において、プログラマーではなく、麻酔科医であることが判明しました。 これはさらに好奇心を刺激しました。 その結果、彼のインタビューから記事が見つかりましたが、2年前に、中心的な問題だけでなく、コンピューター業界全体の発展についても取り上げています。 この記事は私にとって非常に興味深く思えたので、翻訳したいと思いました。 私がカットしたものですが、本質は正しく述べられていると思います。

オリジナル- ここ



翻訳-カットの下

なぜ行ってしまったのですか。

カーネルハッカーのKon Kolivas氏によると、Linuxは企業のジャンクでいっぱいであり、これによりデスクトップシステムの役割が弱くなっています。Linuxカーネルの改善に数年間取り組んだ後、退職を発表しました。



Kon Kolivasは、Linuxをデスクトップオペレーティングシステムとして使用することに専心している著名なカーネルハッカーです。 しかし、なぜ彼はコア開発を放棄することに決めたのですか？

彼の活動の主なタイプは病院の麻酔科医の仕事であり、Linuxカーネルの開発は趣味であるため、「直接」情報を入手することは非常に困難です。

それにもかかわらず、Kon KolivasはLinuxカーネル開発の観点からよく知られた名前であり、これには十分な理由があります。 デスクトップシステム上のオペレーティングシステムのカーネルのパフォーマンスに焦点を当てたファンは大勢のファンを獲得し、カーネルのパッチ（-ckとしてマーク）はカーネル全体の開発に顕著な効果をもたらしました。 変更の一部はカーネルに直接含まれていましたが、他の開発者は他の開発者に影響を与え、今日までカーネルに引き続き変更を加えました。

インタビューでは、Kolivasが開発をやめた理由と、Linuxカーネルの将来についての彼の見解を示しています。



PCのイノベーションの死と、Kon ColivasがデスクトップLinuxシステムのパフォーマンスの問題に気づき始めた方法。



APC：どのようにしてカーネル開発に参加し始めましたか？ それに喜びを感じましたか？



実際、この質問の後には直接的な回答が必要です。 しかし、私には機会があるので、質問にもっと深く答えようとします。 そしてもし私が成功すれば、それはあなたが持つかもしれないすべての質問に対する答えになります。 これは、パソコンの歴史に関する私の見解です。

私の最初のコンピューターは24年前に登場しました。 その後、PCの歴史は始まったばかりであり、PCがどの方向に動くかは興味深いものでした。 誰もが来ることを予期していて、新しい開発を待っていました。

80年代の終わりは、パソコンの黄金時代でした。 多くの開発者がこの市場に来て、独自の機能を持つ独自のオペレーティングシステムである新しいコンポーネントを提供しました。 これは選択の機会を提供し、健全な競争をもたらしました。 当時、Amigaはユーザーと販売の面でオーストラリアを代表するコンピューターだったことを思い出すと興奮します。 その時点でコンピューターを持っていた人は誰でも、他の人とは違って、彼がどのようにコンピューターに出会ったか、そしてコンピューターが彼の家でどのように終わったかについて、自分の物語を語ることができました。 これらのエキサイティングな瞬間を追体験する試みは、しばしば失敗に終わったが、Amigaの場合はそうではなかった。 Amigaに関する私の見解は、その根本的なハードウェア設計は、開発者がプロ​​グラムを改善するための偉業であることです。 これは、最新のシステムには当てはまりません。

当時、IBM互換のパーソナルコンピューターは、テキストエディター用の厄介で高価な大規模なDOSマシンでした。 所有者は常にビデオとサウンドカードをアップグレードし、AmigaとAtariのコンピューターが本来持っていたレベルに到達しようとしています。

コンピューター開発を推進するハードウェアの優先順位は、マーケティングの不備、開発者のミス、およびその他の多くの問題が原因で失敗することがあります。 そして今、ソフトウェアは山の王になり、鉄は単にそれを一致させようとしています。

特定の時点で、どのオペレーティングシステムが事実上の標準であるかは誰もが知っています。 そして、そのようなオペレーティングシステムで動作しないハードウェアの市場がないことは明らかです。 そのようなオペレーティングシステムが登場するとすぐに、他のオペレーティングシステム向けのハードウェアのメーカーは、それをサポートするプログラムの数が減るという事実に直面します。

これが発生すると、アイロンはオペレーティングシステムに関連するメンテナンス機能を実行し始めます。 この状況は1994年に発展し、今日まで有効です...さらに悪いことに、鉄の生産者はゆっくりとお互いを吸収しあい、ユーザーの選択を減らしています。 以前に起こったことのより高速で強力なバージョンがリリースされています。 その結果、より高速なプロセッサ、大量のRAM、ディスク容量、強力なビデオカードがオペレーティングシステムのサービスにのみ必要になる状況がありました。 革新的な鉄の開発だけが市場で認識されなくなりました。 それにお金はありません。 これには市場はありません。 コンピューターは退屈になりました。

Linuxに移りましょう。 私たちは皆、それが趣味として始まったことを知っています。 私たちは皆、彼が誰にも想像できないほど多くに成長したことを知っています。 現在、Linuxはオペレーティングシステムの市場で競争している非常に少数のプレーヤーの中で最も重要なものの1つであると言えます。一方、市場には事実上の標準があります-MS Windows（これは当然のことです）。 革新的なハードウェアの開発が依然としてオペレーティングシステムの開発とライバルの背後にある原動力である場合、Windowsにはそれほど多くのユーザー、開発者、そして最も重要なのは、現在の標準になる標準的な時間はありません。 この間、鉄はほとんど変化していません。 もちろん、PCは、Linuxが最初にロードされた1991年に使用可能だったものと比較して、想像を絶するほど強力になりました。 しかし、これは速度の向上の結果であり、機能や革新の結果ではありません。

それでは、PCの何が問題になっていますか？ PCは20年前にすべての観点から死んだと思います。 現在、PCはごみであり、近い将来、環境全体、情報の処理方法、および通信は同じままであることがわかっています。 インターネットはPCの地位を強化しました。

Linuxはパーソナルコンピューター用に作成されました。 コンピューターの使用に喜びと関心を求めている人にとって、事実上の標準であるオペレーティングシステムの存在は障害になりません。 私たちは、オペレーティングシステムを改善し、完全に制御し、パワーを持ちたいと考えています。 または、代替として、これは行動の自由によって達成できると考えています。 そして、Linuxを使用しています。 これがまさに私が彼とつながっていた理由であり、私は自宅のPCで何かを使用したかったのです。

ただし、PCはゴミです。 これはゴミです。 私たちにとって重要なアプリケーションのすべての領域で、すべてが過負荷になり、遅すぎます。 今日では、10年前にスーパーコンピューターと同等のパフォーマンスを備えたパーソナルコンピューターがあります。 10年前には、20年前のスーパーコンピューターと同等のパーソナルコンピューターがありました。 では、なぜすべてがそんなに遅いのでしょうか？ コンピューターが高速化する場合、なぜシステムを起動してアプリケーションを実行するのに以前よりも時間がかかるのですか？ いいえ、彼らが情報の純粋な処理（ビデオのデコードなど）で忙しいとき、彼らは素晴らしいです。 しかし、そうでなければ、今日のコンピューターは非常に遅いです。 10年前に比べて1000倍高速になり、すべてがゆっくりと動作します。

これに対して人々が私に与える通常の議論は、コンピューターは以前よりもはるかに多くのことをしているということです。 わかりましたが、1000倍速くなる代わりに10倍遅くなるため、10,000倍多くしなければなりません。 明らかに、彼らが行う10,000回、彼らは彼らが必要な場所ではなくどこかで行います。



APC：それでは、デスクトップシステムのLinuxパフォーマンスの問題が主な動機となっていますか？



はい まず、デスクトップ上のLinuxを改善することから始めました。「すべてのソフトウェアを制御できれば、動作を高速化できます」。 パフォーマンスを調整、最適化、および達成する方法が必要です。 Linuxで作業を始めたとき、ユーザー作業の分野で何かを改善する可能性は非常に限られていた。 彼はほとんどデスクトップで作業していませんでしたが、スピードアップを目的として何かを改善しようとすると、何も機能しませんでした。 Unixの遺産がそこにありました。 デスクトップ向けではないオペレーティングシステムを採用しましたが、このプロセスは苦痛でした。

徐々に、カーネルの変更が速度の向上につながることに気付きました。 変更はそれほど大きなものではありませんでしたが、負荷がかかったときのプロセッサの動作など、わずかに顕著な変化を伴いました。 最初に公開したパッチには、独自のコードが含まれておらず、2.4.18カーネル用のものでした。 2002年2月のどこかでした。コンピューターサイエンスを勉強したことがないので、Cコードが何であるかさえ知りませんでした。 このため、2.6カーネルが開発中になるまで、私はその場にとどまりました。 私は彼女の進歩を追いました、そして正直になります-私はぞっとしました！ 私が尊敬したカーネル開発者は、普通のユーザーには絶対に必要のないある種の企業ジャンクに取り組みました。

そして最悪なのは、1024個のプロセッサと1000個のハードドライブを搭載したマシンでLinuxを目にするのが好きなのですが、カーネルに含まれるこのような機会がデスクトップのパフォーマンスを損なう可能性があるという考えを嫌います。

量的指標が私たちが知っているすべてであり、生産性を測定しているなら、本当に、それはこれまで以上に優れています。 しかし、オーディオプレーヤーを起動すると、音が途切れます。 どもり！ 私たちの悪魔はメガヘルツを知っていますが、音声を正常に再生できませんか？

または、大きなファイルのディスクへの書き込みを開始すると、その時点でカーソルのみが移動し、デスクトップ上の他のものはすべて無効になり、ウィンドウは1分間更新されません。

私は泣く準備ができたと感じました。

バグレポートを送信したことを覚えています。ある開発者が、4ギガバイトのメモリを搭載した4プロセッサコンピューターで問題を再現できなかったと答えました。 そして、平均的なユーザーが4年前にどのようなハードウェアを使用していたかを考えてください。

すべての開発者は、デスクトップシステムとは関係のないことをしています。 彼らはすべて、一般ユーザーの問題を気にしない大企業の従業員です。 彼らが気にするのは、データベースベンチマークで得られたパフォーマンスの1％の余分な割合です。

Linuxが勝ちました。 私たちはサーバーおよびデータベース市場で大きな競争相手であり、すべての大企業がLinuxの世話をしています。 開発者に資金が流れ、顧客が必要とする分野のシステムパフォーマンスが向上します。

ユーザーが失われました。 Linuxが最初に開発された通常のデスクトップコンピューターは、あまりにも離れたままでした。 パフォーマンスは、普通のユーザーが理解する形式では、もはやありません。 さらに悪いことに、何かを証明するために測定することさえできません。 パフォーマンスを改善する機会を見つけた唯一の場所はカーネルです。 その開発も、ユーザーの利益とは反対の方向に動き始めました。



APC：そして、コア開発者に彼らの努力を一般ユーザーのニーズに集中させるよう説得するために何をしましたか？



Linuxのパフォーマンスの問題を表す数値を取得するために、ベンチマークを開発することにしました。 私が作成した最初のベンチマークは、使用するのが非常に難しく、結果を解釈するのが困難でした。 しかし、少なくとも私は試しました。 助けた。 彼の証言の結果としていくつかの変更が行われ、それらは主にディスクサブシステムの動作に関連していました。 しかし、パフォーマンススケジューラの問題に再び直面しました。

以前のカーネル用のパッチを作成した経験があり、皮肉なことに、それらはスケジューラと正確に接続されていました。 プログラミングを学んだことはありませんでしたが、目の前のコードは次第に意味に満ち始めました。

私が考えていることを人々に伝えるのをやめました。コードのどの特定のセクションが問題なのか。 苦情、非難、指示の後、私は自分でコードを掘り始め、すべてを自分でやるようにしようと決めました。

いくつかの失敗した実験の後、私は助けたコードを書き始めました...本当に助けました。 判明したように、人々はそれに注意を払い、私のコードはカーネルに含まれていました。 スケジューラが対話型アプリケーションを実行する方法は好きではありませんでしたが、少なくともデスクトップでは機能していました。

スケジューラの基本的なメカニズムに満足していないため、最初からすべてをやり直すことにし、「-ck」パッチの第2世代が誕生しました。 今回は、ほぼ完全に自分のコードで構成されていました。 実際、これはカーネル用にコードを書き始めた経緯です。

この道をたどると、多くの一般ユーザーに役立つコードを書いていることがわかりましたが、改善を測定する方法がありませんでした。 プラセボ効果には常に要素があり、エンドユーザーが改善の有無を判断するのは非常に困難です。

それにもかかわらず、私自身はこのプラセボ効果に抵抗しようとしましたが、私のサイトがすでに100万ヒットに近いという事実は、人々も違いを見ていることを示しています。



APC：公式カーネルにはどのコードが含まれていましたか？



私のパッチを聞いた当時を振り返ると、実際には私のカーネルのほとんどは公式カーネルに含まれていませんでしたが、これは他の人々の開発への関心を喚起しました。 ほとんどの場合、私のコードは、対話性、公平性、SMPユーザーの公平性、ハイパースレッドの公平性などのプロパティの改善という点でスケジューラに触れました。 また、仮想メモリサブシステム、遅延呼び出し、I / Oスケジューリング、ランダムなバグ修正など、さまざまな分野で小さな変更が多数ありました。

私の最後のパッチは、私の意見では、主な問題がデスクトップユーザーに隠れている領域に関連しています。 そして、私の試みにもかかわらず、これらの問題は毎年ますます大きくなっています。 しかし、彼らはプロの開発者の注目を集めていません。 これらの問題は、カーネル開発者のメーリングリストの人々から苦情が寄せられるほど問題が明らかになった場合にのみ対処されます。



APC：開発への参加に対して支払われた価格はいくらですか？



頭でビジネスに没頭していたとき、私は夜眠れず、別の問題を解決することを考えました。 しかし、それは私の仕事と家庭生活に影響を与える可能性があります。 カーネルの開発に参加するためにこれらのものを犠牲にしないように非常に一生懸命努力しましたが、たまにそれを非常に遠くに押し出したのです。 私は自分がやったことを後悔していないと思うが、今は開発に「縛られ」ているので、人生のその期間には有利だ。



APC：これは、開発者のキーボードと「-ck」パッチセットの放棄につながった主な要因でした。



これは私が言いたい質問の1つです-「尋ねられるたびにコインを受け取れないのは残念です」

ほとんどの人と同じように、私は開発に参加することを奨励した3つの理由がありましたが、これは私の通常のキャリアと人生には関係ありませんでした。

最初の理由は楽しいです。 私はいつもコンピューターマニアで、コンピューターの前で何時間も過ごすのが好きでした... そして、あなたの情熱である何かをすることに時間を費やすことは、喜びの明らかな源です。

2つ目は知的テストです。 カーネルでやるべきだと思ったことがありましたが、これを行う必要があるとは思わなかった人もいました。 特に「高度なプログラミング」の分野では、私は彼らに立ち向かい、私がやったことのないことをしたかったのです。 オペレーティングシステムの開発について多くのことを学び、対応する学部のほとんどの学生が非常に退屈だと考えるコンピューターサイエンスの基礎に精通しました。

これはすべて私にとって新しいものでした。 しかし、私はオペレーティングシステムの研究にはほとんど関与しませんでした。 Linuxには多くの革新がありますが、既存の問題を解決した方法には適用されません。 すべての研究は、ソフトウェアとハ​​ードウェアの対立の間にすでに実施されています。 多くの人が「正直なプランナー」を発明したと主張して私を非難しました。 しかし、率直に言って、私はこれを主張したことはありません。

既存の鉄とコアに関連して、私がしたことはすべて知られていました。 しかし、問題とその解決策が長い間知られていた時代に、ハードウェアとソフトウェアの原則に違いがあり、そのため問題が現れました。 私の革新は、既存のアイデアの具体化にのみありました。 学業成績は現実の世界では適用されない傾向があります。 一方、純粋なハッキングは、現時点では問題を迅速に解決できるとしても、長期的には壊滅的です。 ハッキングと長年の学術研究を無視しないことの適切なバランスを見つけることが必要です。



APC：このバランスを見つけましたか？



いや しかし、これは私が達成しようとしたものです。 できるカーネル開発者は数人しかいないと思います。 しかし、純粋に人間の動機に基づいて、そのコードの1つが「正しい」コードではなく、どのコードが決定を始めたら、それを認識することは不可能になると思います。

さて、3番目の理由は自我です。 自分の世話をするものを修正すると、私と同じくらい世話をする人が大勢いることがわかりました。 この理由は、私がカーネルハッカーであると主張する通常のユーザーだったからです。 そして、同じ普通のユーザーに影響を与える変更を加えた場合、これは多くの人々を心配させました。有名な開発者の1人をよく覚えています。彼は私の「ファン」について冗談を言って、どうすれば観客をそんなに誘惑できるのかと尋ねました。彼はおそらくカーネルに1,000倍のコード行を提供し、私には「フォロワー」がいました。

しかし、私がユーザーを惹きつけたのは、私が気にかけていることに取り組んだからです。私を開発させたのは、-ckパッチのユーザーから受け取った「ありがとう」だけです。

しかし、カーネルでの作業を停止させた原因についての質問にはまだ答えていません。なぜそれをしたのかを説明することは、私がやめた理由を説明するのに役立つと思います。

インテリジェントなテスト-はい、まだありました。

楽しい、楽しい？いいえ、消えました。私が去るというメールで送られた私の声明の中で、私はこの点に少し触れました。私のパッチはもともと私自身の実験用でした。しかし、変更がより広範になると、改善はより深刻になり、より顕著になりました。これにより、カーネルのコアバージョンに含まれる時期が問われるようになります。そのような質問が多ければ多いほど、メインの開発に参加するために、カーネルにコードを含める問題に触れたくないという回答が少なくなりました。カーネル開発者のメーリングリストに例としてパッチのいくつかを投稿したことがあります。これは、カーネルにコードを含めることに関して、さらに大きな関心と疑問を引き起こしました。最後に、私は疲れてしなければならなかった。



APC：あなたにとって「最後のストロー」は何でしたか？



受け取ったカーネルにコードを含めることの主な失敗は、スケジューラに関するものでした。彼は完全ではありませんでしたが、双方向性ははるかに優れていました。私がそれに取り組み続けたとき、主要なメンテナーの焦点はプランナーから他の問題に移りました。そして、Alan Mortonが私のコードを含めることを拒否した理由は、カーネルで修正する必要のある緊急の質問とエラーがあったためです。本当にそうだった。しかし、カーネルには常に対応するサブシステムが多数あり、それらのサブシステムに欠陥が発見されています。しかし、デスクトップの問題に関連する改善よりも、絶え間ない書き換えが重要ですよね？

しかし、主な問題は、デスクトップで作業するとき、私のスケジューラがはるかに優れていることを証明する明確な方法がなかったことです。ユーザーメッセージだけでは不十分でした。ベンチマークはありませんでした。そして、証明できないこととユーザーの申し立ては、メンテナーの主観性を怒らせただけです。私は再びベンチマークを書き込もうとしました。前のものよりも優れていましたが、数字のチェーンのみに基づいてスケジューラの利点を証明することはほとんど不可能です。

William Lee Irwinの助けを借りて、カーネルにモジュールとして接続できるスケジューラーを公開しました。これにより、ブート時に使用するスケジューラーを選択できます。これは、現在のカーネルで使用されているプラ​​ガブルI / Oスケジューラに非常に似ています。しかし、これはLinusとIngo（プランナーのマネージャー）によって拒否されました。なぜなら、カーネルにはできるだけ良いスケジューラが1つだけあるべきだと信じていたからです。

開発されたPlugshedの目的は、スケジューラをカーネルコードに確実に統合することでした。これがどれほど正しいかはわかりませんが、多くの人がこの方法を続けています。

その後、スワッププリフェッチ機能の作業が開始されました。私はそれを改善するために多くの時間を費やしました。それらは18か月前にカーネルに含まれていましたが、それ以来、私はそれに取り組んでいます。

アンドリューは、この機能が有用であるとは考えず、マイナスの結果を引き起こす可能性があると考えていました。しかし、過去9か月間、バグの報告やそれによるパフォーマンスの低下についての苦情はありませんでした。これがどのように機能するかを示すベンチマークを作成しました。しかし、Linusから「はい、でも本当に役立ちますか？」と尋ねられました。まあ、少なくとも彼らはカーネルから関数をスローしませんでした。

次に、Staircase Deadline CPUスケジューラについて説明します。最初は、階段CPUの派生物として作業を開始しました。しかし、すぐに気づいたのですが、優れた双方向性を提供し、「誠実さ」の問題を解決することさえ可能です。なぜなら、対話性の向上はしばしば「誠実さ」の悪化の原因だからです。まあ、正直さは、多数のユーザーがいるサーバーとシステムにとって最も重要です。

多くのユーザーがスケジューラをメインコードに「プッシュ」するリクエストを送信しました。これは多くの欠点を修正したためです。それまでの間、コードを改善し、いくつかのバグを修正しました。

- … , , . , , .

, . Staircase Deadline. .