Linus Torvalds & Dirk Hohndel：Linux、Rust、メンテナー
このページのタイトル、字幕、要約、読書メモは保存済みの AI 翻訳です。誤りが含まれる場合があります。タイムスタンプは原文と同じです。原文の字幕を開き、元の動画と照合できます。
Linus TorvaldsとDirk Hohndelが、Linux 6.7のリリース、カーネルにおけるRust、高齢化するメンテナーと新しいメンテナーの供給源、そしてコーディングにおけるLLMについて語る。
文字起こしの出典: Vidleafによる自動音声認識(誤りを含む可能性があります)。AIによる句読点の付加はVidleafによるもの。読み上げテキストには名前の修正を反映済み。タイムスタンプのアンカーは保持されています。元の文字起こしは以下でご覧いただけます。
AI生成の要約
Linus TorvaldsとDirk Hohndelが、Linuxカーネルとそれを保守する人々について議論する。会話はLinux 6.7のリリースとRustの段階的な導入から始まり、その後、メンテナーの疲弊、後継者問題、ハードウェアベンダーとコミュニティの関係の変化について考察する。Torvaldsは、コードレビューにおける言語モデルの可能な用途と、間違いを見つける人間の必要性を天秤にかける。後半の議論では、オープンな協働と中立的な組織的拠点の価値が結びつけられる。これらは収録されたイベントで表明された見解であり、壮大な長期予測よりも漸進的なエンジニアリングを好むTorvaldsの姿勢を含む。
要点
- [5:41] Rustの導入は、カーネル開発における漸進的なプロセスとして議論されている。
- [15:21] メンテナーの後継と新しい貢献者の受け入れは、プロジェクトにとって依然として人的な課題である。
- [20:50] TorvaldsはコーディングとレビューにおけるAI支援を考慮しつつも、人間の判断の必要性を保持している。
トランスクリプトから生成。リンクされた箇所は元の動画と照合してください。2026-10-20にVidleafがレビュー。概要と要点は2026-10-21にVidleafがレビュー。
全体概要
このディスカッション形式のセッションでは、Linus TorvaldsがVerizonのDirk Hohndelと対談し、Linux 6.7のリリースとカーネルコミュニティ全体の話題を扱う。Linux 6.7 RC4は数日前にリリースされ、クリスマス／大晦日カーネルが予定されており、6.8のマージウィンドウはおそらく一、二週間遅れるだろう。6.7は退屈なリリースと評され、それは良いことであり、約十年かけて開発中の新しいファイルシステムの影響もあって、コミット数では史上最大になるかもしれない。Torvaldsは、Rustの導入は着実かつ静かに進んでおり、まだそれに依存するカーネル部分はないが、来年には一部の主要サブシステムが積極的に使い始め、Rustがカーネルの大きな部分を占めるまでには何年もかかると述べる。彼は自分を、人ではなくコードを管理する技術リードだと呼ぶ。商業環境とハードウェアサポートは20年の間に大きく改善し、企業が自社ハードウェア向けのドライバを書くようになったが、ドキュメントは依然として見つけにくいことがある。メンテナの疲労は未解決の繰り返し議題であり、メンテナには良いセンスと常時対応可能であることが求められ、メンテナのツリーの頂点は著しく高齢化しており、多くのメンテナが五年後には60代に近づく。AIについて、TorvaldsはLLMが書いたコードがプルリクエストとして提出されることを予想し、LLMがコードレビューや明らかな愚かなバグの発見に役立つことを望み、幻覚と、人間が問題を捕まえないままの自動化を心配する一方、AIは日々のニュースが示唆するほど革命的だとは見ていない。また彼はオープンデータの議論に関わることを断り、自分の側ではない領域は手放すことを好む。スピーカーは、カーネルに専念する著名なLinux Foundationの従業員と描写され、オープン性がいかに広く受け入れられるようになったかを振り返る。かつてなぜ、どうやって儲けるのかと尋ねられた質問はもはや出なくなり、オープンデータは誰もなぜと問わずに議論され、オープン性はある程度業界標準になった。彼は、企業間で大きなプログラミングやデータのプロジェクトを共有する最も簡単な方法は、広く共有できるライセンスでそれらをオープンにすることだと人々が当然視していると指摘する。Linux Foundationがオープンデータを行うのは素晴らしいが、それは自分がすることではないと述べ、人々が集まれる中立の場が重要だと語る。彼はLinux企業で働くことを拒み、一つの商業主体が特別な場になることを望まなかったため、Linux Foundationで働いている。方向性について、オープン性はオープンコードからオープンデータへ移り、次にどこへ行くかが問いだと述べ、自分は壮大な10年計画を発表するのではなく目の前の一歩を見る、歩みの遅いエンジニアだと自称する。技術において長期計画はあまりうまく機能しないと思うが、どこへ行きたいかの考えは必要であり、それでも一歩ずつだと語る。その後ホストは、来年日本に戻る際にOpen Source Summitをどこで開催すべきか尋ね、沖縄を提案する。ゲストは東京を楽しんでおり、妻と歩き回ってショッピングモールを訪れていると述べ、沖縄も良いと思うと答える。そしてホストが皆に感謝して締めくくる。
タイムスタンプ付きの章の要約
Linus Torvalds、Linux 6.7のリリース時期について
- [0:05] Dirk HohndelはVerizonのオープンソースプログラムオフィスの責任者である。
- [0:13] Linus TorvaldsはLinuxとGitの創作者として紹介される。
- [1:00] この形式を行うのは今回でどうやら23回目である。
- [1:07] Linusは公の場での講演を好まないため、事前に知らされていない質問を用いるディスカッション形式をとっている。
- [2:04] Linux 6.7 RC4が数日前にリリースされ、クリスマス／大晦日カーネルが登場する予定である。
- [2:31] Linusは約10週間ごとのリリースを目指している。
- [2:54] 今年はクリスマスがリリースの静かな期間に重なり、Linusにとって都合が良い。
- [3:19] 6.8の準備をしているメンテナーたちは、クリスマス後にマージウィンドウが開くため少し慌てているだろう。
- [3:39] マージウィンドウはおそらく一、二週間遅れるだろう。
Linux 6.7リリースに関する議論
- [3:44] クリスマスに働きたい人はいないため、タイミングを改善するために毎年リリースがスケジュールされている。
- [4:00] プロジェクトは15年以上にわたり非常に規則的なリリーススケジュールを維持している。
- [4:13] 6.7は退屈なリリースの一つになりつつあり、退屈であることは良いことだ。なぜなら興奮は通常大きなバグを意味するからである。
- [4:34] コミット数で数えると、6.7は史上最大のリリースになるかもしれない。
- [4:47] その理由は、約十年かけて開発されてきた新しいファイルシステムであり、多くの新しいコミットをもたらす。
- [5:05] 開発速度は横ばいではなく、依然として増加している。
- [5:14] カーネルサイズは増加傾向にあり、これは良い兆候だがメンテナーにとっては作業量が増えることを意味する。
カーネルにおけるRustとメンテナーの役割
- [5:41] Rustはカーネルに導入され、そのプロセスは比較的安定して静かに進んでいる。
- [5:55] 初期のRustインフラは昨年マージされ成長しているが、カーネルのどの部分もまだRustに実際に依存してはいない。
- [6:09] Rustは技術的に理にかなっていたが、彼にとってより重要だったのは、カーネルとして、また開発者として停滞しない必要性だった。
- [6:25] 彼は32年間カーネルに取り組んでおり、単一の同じものではないため興味深いままだ。
- [7:08] Rustは次の大きなものとして本当に台頭してきたわけではないが、来年にはいくつかの主要サブシステムが積極的に使い始めるだろう。
- [7:24] Rustがカーネルの大きな部分を占めるまでには何年もかかるだろう。
- [7:34] 彼は含めるにはあまりにひどいものは何か判断するためにRustコードを少し読んでいるが、自分ではRustコードを書かない。
- [7:56] カーネルは数千人に支えられており、各リリースに関わる人の約半数はパッチを一つ送るだけで、その多くは二度と現れない。
- [8:46] 彼はRustコードを管理する立場にはならない。それは彼の専門分野ではないからだ。
- [8:57] 彼は自分をマネージャーではなくテクニカルリードと呼ぶ。彼は人ではなくコードを管理し、日常業務はプログラミングではない。
商業環境とハードウェアサポートの改善
- [9:19] Jimは基調講演で、オープンソース開発者は時に意見が強く、自分の意見を表明すると指摘した。
- [9:40] 誰が彼のブラックリストに載っているかと尋ねられると、彼は会社名を挙げることを控えた。
- [9:55] 彼は20年前に会社に中指を立てたことでその写真が繰り返し出てくることになり、教訓を得たと語る。
- [10:15] 商業環境全体は過去20年間でずっと良くなった。
- [10:23] 以前はハードウェアのドキュメントを見つけるのが難しく、一部の企業は積極的に敵対的だったが、それはもはや真実ではない。
- [10:34] 今では企業が自社ハードウェア用のドライバを書き、ドキュメントは書くのが難しく、企業が癖やバグを文書化したくないかもしれないため見つけにくいことがある。
- [10:47] ハードウェアサポートは以前と比べてはるかに良い状況にある。
メンテナーの疲労とオープンソースの人間的側面
- [11:08] メンテナーの疲労とその役割がいかに消耗させるかは、何年もカーネルサミットで繰り返し取り上げられるテーマだ。
- [11:38] メンテナーを見つけるのは難しく、開発者を見つけるのはずっと簡単で、それは毎回のリリースで言及される。
- [11:55] メンテナーは何でもできるスーパー開発者である必要はなく、それは実際には真実ではない。
- [12:01] メンテナーは他人のコードを判断する良いセンスが必要で、その一部は生まれつきかもしれないが、多くは長年の練習で身につく。
- [12:39] メンテナーは常にそこにいるか、休暇に合わせてスケジュールを組む他のメンテナーを見つける必要がある。
- [13:23] まだ解決策はなく、メンテナーグループはそれぞれ異なる解決策を形成しており、問題の一つは人に対処するのは難しくコードは簡単だということだ。
- [13:49] 異なる目標を持ち、それぞれの領域を異なる方向に押し進めるメンテナーと協力するのは非常にストレスになることがある。
- [14:15] オープンソースはプログラミングだけではなく、その多くはコミュニケーションであり、同じ人がやる必要はない。
- [14:38] メンテナーは開発者の成果をプロジェクトに翻訳する必要があるかもしれない。それは必ずしも言語ではなく、文脈とコードの理由を意味する。
高齢化するカーネルメンテナーと後継者問題
- [15:21] メンテナーになりたい人にはトップへの余地がある。
- [15:37] ほとんどのサブメンテナーはGregのように髪がないか、まだ完全には白髪になっていない。
- [16:06] メンテナーツリーの頂点のリーダーシップは著しい高齢化が見られる。
- [16:14] 五年後には多くのメンテナが60代に入り始め、最初の何人かは70代に近づくだろう。
- [16:51] 約30人に限定されたメンテナサミットでは、少なくとも三人が30年以上関わっていた。
- [17:12] 彼らの継続的な存在はコミュニティに定着する人がいることを意味するが、それは諸刃の剣だ。
- [17:33] Rustのメンテナーは明らかに他のほとんどのメンテナーよりずっと若かった。
- [18:33] ドライバ側、特にGPU関係者は若い人を見つけるのがずっと容易で、伝統的に多くのメンテナーがそうやって育ってきた。
ソフトウェア開発におけるAIとLLM
コーディングとコードレビューにおけるAIについてのLinusの見解
- [19:42] AIはすでにコードを書く際の助けとして小規模に使われているかもしれない。
- [19:59] 自動化は常に人々のコード作成を助けてきたので、これは新しいことではない。
- [20:12] 彼はAIを毎日のニュースが言うほど革命的だとは見ていない。
- [20:50] 彼はLLMがコードレビューやサブシステムの維持、特に明らかな愚かなバグを見つけるのに役立つことを望んでいる。
- [21:33] コンパイラはすでに非常に明らかなバグについて警告するが、LLMは規則的に見えないパターンにフラグを立てることで、もう少し微妙なケースについて警告できるかもしれない。
- [22:01] 彼はLLMが「ステロイドを打った自動修正」をはるかに超えており、私たちがやっていることをより良くするのに役立つと考えている。
- [23:13] 彼はLLMが幻覚を見て作り話をすることを心配しており、人間がそばで捕まえることなく自動で物事を行うようになるほど怖くなると述べている。
- [23:37] 懸念はSF的な世界支配ではなく、私たちの生活やコードに影響を与える多くのバグである。
- [23:49] LLMがなくても毎日バグは起きており、私たちは自分たちだけでうまくやっているので、彼はあまり心配していない。
Linux Foundationにおけるオープン性とオープンデータ
- [24:16] 30年前、オープンソースはコードが未来を支配しているように感じられ、数十億ドル相当のコードが決定的な要素だった。
- [24:38] 今日ではコードよりもはるかに多くのデータが私たちの世界を支配しているように思われ、Google、Amazon、Appleが私たちについて知っていることを指している。
- [24:57] 彼はオープンデータの議論には関わらず、カーネル内でそうしているように、自分の側ではない領域は手放すことを好む。
- [25:37] 彼はLinux Foundationのより著名な従業員の一人だが、カーネルに専念している。
- [26:02] 彼はオープン性がはるかに広く受け入れられるようになったことを喜んでおり、30年前にはなぜ、どのようにして儲けるのかと人々が尋ねていたが、そんな質問はもはや出なくなったことを思い出している。
- [26:29] 誰もなぜと尋ねることなくオープンデータが議論されているという事実こそが本物であり、オープン性はある程度業界標準になっている。
- [26:43] プログラミングやデータの大きなプロジェクトを企業間で共有する必要がある場合、広く共有できるライセンスでオープンにするのが最も簡単な方法だと人々は当然のことと考えている。
- [27:16] Linux Foundationがオープンデータを行うのは素晴らしいが、それは彼自身が行うことではない。
- [27:37] 人々が集まれる中立な場所は重要であり、彼はLinux企業で働くことを拒否し、一つの商業組織が特別な場所になることを望まなかったためLinux Foundationで働いている。
長期計画よりも段階的な歩み
- [28:23] オープン性の方向性はオープンコードからオープンデータへと移り、次にどこへ向かうのかが問われている。
- [28:38] 話者は自分を、壮大な10年計画を発表するのではなく目の前の一歩を見る、こつこつ歩むエンジニアだと呼んでいる。
- [28:46] 彼は、ある人からのメールで楽しい小さなプロジェクトがほんの小さな趣味だと書かれていたことを引き合いに出し、それが自分の予測の下手さを証明していると述べている。
- [29:15] 彼は長期計画を持つことがうまく機能するとは思っておらず、政治では五年計画があまりうまくいかなかったことを挙げる。
- [29:25] 彼は長期計画は技術ではあまりうまくいかないが、どこへ行きたいかの考えは必要だと述べている。
- [29:35] 目の前を見なければ、あちこち手探りして山の頂上には決してたどり着けない。
- [29:45] 大きな旅を心に描いていても、それは一歩ずつの積み重ねであり、特に技術では一度の大きな飛躍で世界を変えることはできない。
Open Source Summit Japan 2025 会場の提案
Vidleafが確認した名前の修正
2026-10-20を確認しました。元のキャプションは以下で引き続きご覧いただけます。
[0:00] それでは次の対談スピーカーを紹介できることを嬉しく思います。ステージへお迎えください――Verizonのオープンソースプログラムオフィス責任者であり、LinuxとGitの創作者であるDirk Hohndelと、Linus Torvaldsです。拍手でお迎えください。では。
[0:31] ありがとう。おはようございます。皆さんが私たちに携帯電話を向けているのを見るのはとても面白いですね。私も携帯を取り出して皆さんの写真を撮りたいところですが、電話はあちらに置いてきました。私はDirk Hohndel、Verizonでオープンソースを担当しています。Jim Zemlinの言葉を借りれば、こちらは「もう一人の男」です。ええ、私はもう一人の男で、これまでにもこれをやってきました。Dirkによると、どうやら今回で23回目だそうです。
[1:04] この形式でやる理由は、私は公の場で話すのが好きではないからです。多くの皆さんもお分かりでしょうが、これは世界で一番楽しいことではありません。そこでDirkが事前に私の知らない質問を用意し、皆さんの前でより議論に近い形で進めるというこの形式を考え出しました。そのほうがずっと楽ですし、皆さんにとってもうまくいくことを願っています。ええ、たいていはうまくいきます。時々彼が私に「今どうすればいいんだ？」と思わせるような意表を突く質問を投げてきます。今回のはどれでしょうね。日本に戻ってこられてとても嬉しいです。数年ぶりですから。
[1:43] 残念ながら。昨夜は恒例の寿司ODをやり、ここに来るのはいつも良い。招いてくれて本当にありがとう。タイミングが変わった。以前は日本のカンファレンスは六月のようだった。だからクリスマス前にここにいるのは実際ちょっと楽しい。だからとても嬉しい。 - 天気にも恵まれたね。 - ええ、素晴らしかった。ではLinus、数日前にLinux 6.7 RC4をリリースした。
[2:16] そしてこれで面白いことの一つは、クリスマス／大晦日カーネルになるということだ。よくやった。良いタイミングだ。まあ、つまりリリースは…二か月半ごと、だいたい10週間を目指している。だからクリスマスが来るたびにこうなる。そしてマージウィンドウ、つまり私の忙しい時期がちょうどクリスマスの頃にあり、それが私のクリスマスを本当に台無しにする。あるいは静かな期間がある。
[2:54] 最後のいくつかのバグを見つけて修正しようとしているときです。そして今年、幸いなことに、私にとってクリスマスはリリースの最後の数週間が進行中で、大きな問題が起きていないことを確認するのを待つだけの静かな時期です。それは私にとって非常にうまく機能しますが、それはつまり、次のバージョンの準備をしている何人かのメンテナーや開発者たちが、6.8、クリスマスの後に私のマージウィンドウが開くことを知っているので、少しパニックになるということです。そして、その時に次のバージョンのためにすべてのものを準備しておくべきなのです。
[3:39] だからおそらく一、二週間遅らせるだろう。毎年そうしてタイミングをより良く合わせている。誰もクリスマスに働きたくないからね。ええ、では6.7で、何が興奮させる？何か目立つことは。うーん…実はここほぼ20年、いや20年ではなく15年以上、非常に規則的なリリーススケジュールを保っている。嬉しいことに6.7は退屈なリリースの一つになりそうだ。退屈は良い。 - 退屈は良い。 - 興奮が多すぎるのは良くない。興奮はたいてい大きなバグを意味するから。
[4:23] 6.7は… - Gのバグで、CKではない。 - ええ。ありがとう。ひどい。でも6.7は実は少し珍しい。コミット数だけを数えると、史上最大のリリースかもしれない。そして、その理由は実は約十年かけて開発されてきた新しいファイルシステムがあることだ。
[4:56] そのために多くの新しいコミットが入ってきています。しかし、興味深いのは、私たちが安定を保っているだけでなく、実際に開発速度をまだ上げていることです。そしてカーネルのサイズは増加する傾向にあり、それは良い兆候ですが、明らかに多くの作業が進行中であり、メンテナーが対処すべき作業がさらに多いことを意味します。ええ、リーナスが私のジョークを気に入らなかったことに加えて、同時通訳者に謝りたいです。これを日本語にどう翻訳するか全く分かりませんから。
[5:36] ここ数回のカーネルリリースで多く議論してきたことの一つは、カーネルへのRustの導入です。そして、それは比較的安定して静かに進んでいると思います。あなたの認識はどうですか？ - ええと、Rustはまだ、初期のインフラストラクチャが昨年マージされた段階です。成長していますが、まだRustに本当に依存しているカーネルの部分はありません。私にとってRustは、技術的に意味があることの一つでしたが、個人的にはさらに重要だったのは、カーネルとして、また開発者として停滞してはいけないということでした。
[6:22] ですから、私はいつも新しいことを試み、同じことをしてあまり心地よくならないことに興奮しています。つまり、私は今32年間カーネルに取り組んでいます。ええ、32年です。一つのことに取り組むには長い時間ですが、それでも興味深いのは、それが同じ一つのことではないからです。つまり、32年前のLinuxは明らかに今日のLinuxとは非常に異なっていました。私は実際に、新しいことをしたり、違うやり方でできる場所をよく探します。なぜなら、 rutに陥って「これはうまくいっている」と言うのはとても簡単だからです。
[7:06] そしてRustは、次の大きなものとしてまだ本当に現れていませんが、来年には実際に統合を始め、いくつかの主要なサブシステムが積極的に使い始めると思います。そういうものの一つです。カーネルの大きな部分になるまでには何年もかかるでしょう。確かにそうなりつつあります。- では、ご自身でRustコードを書いているのですか？Rustコードをレビューしているのですか？ - いや、違います。カーネルに含めるにはひどすぎるかどうかの判断をするために、Rustコードを少し読んだことはあります。しかし、認めざるを得ません、いいえ。
[7:54] つまり、大佐。私たちは文字通り数千人もの人々に依存しています。私たちのリリースごとに、千人もの人々が関わっており、しかもそれは同じ千人の人々ではありません。実際のところ、かなり頻繁に、いや、長い間、私たちの統計はおおよそ次のようなものでした。リリースごとに……関わっている人々の約半数はパッチを一つだけ送ってきます。そしてその多くは二度と現れません。彼らには自分が気にかけている小さな修正したいことがあったのかもしれず、本当のカーネルの人々ではなかったのです。彼らは別の理由でそれを見つけたのです。
[8:29] そして彼らは小さなパッチをカーネルに送りました。そしてそれ以上何かをする興味はありませんでした。しかしその後— 残りの半数は戻ってきます。そしてRustに関しては、私はRustカバーを管理する人にはなりません。それは私の専門分野ではありません。カーネルの他の多くの部分についても同様です。正直に言うと、私は最近プログラマーというよりも、自分をテクニカルリードと呼んでいます。なぜなら私はマネージャーではないからです。
[9:03] 私は人を管理せず、コードを管理します。だから自分をテクニカルリードと呼びます。私の日常業務はプログラミングではなく、他の人のコードをマージすることであり、Rustもその状態の一つになるでしょう。ええ、ジムは基調講演で、オープンソース開発者は時に意見が強く、時に意見を表明すると指摘しました。- すみません？ - あなたは過去に表現力豊かであるという評判がありましたが、最近はもちろんそうではありません。しかし、私が疑問に思っていることの一つは、現在あなたのいたずらリストに誰がいますか？可能性のある企業は… ああ、そこには行きません。
[9:46] 私はそこに行きました…挙手で示してもらえますか？彼はそこに行くべきでしょうか？いや、いや、いや。それは、あなたが…20年前にどこかの企業に中指を立てた類のことの一つです。そしてその写真は毎日のように出てきます。だから私は教訓を学びました。それは今でもあなたの画像を検索したときの一番の検索結果だと思います。それは今でも最初の子供ですね、はい。でも、正直に言うと、冗談を言っていますが、同時に、商業環境全体はこの20年間でずっと良くなりました。以前は、ハードウェアのドキュメントを見つけるのが難しい状況でした。
[10:27] そして一部の企業は積極的に敵対的でした。それはもう真実ではありません。つまり、今では自社のハードウェア用のドライバーを書く企業があり、ドキュメントを書くのは難しいので、ドキュメントを見つけるのが非常に難しいこともあります。そして多くの企業は必ずしも自社のハードウェアの癖やバグを文書化したいとは限りませんが、ハードウェアサポートに関しては私たちはとても良い立場にあります。
[10:57] 以前の状況と比べて。それで、変化する環境について話しました。Kernel Summitはほんの数週間前でした。そして、Kernel Summitで何年も非常に一般的な話題の一つは、メンテナーの疲労と、この役割がいかに消耗的でストレスフルかという全体的な問題です。私たちは状況を改善するために何をしているのでしょうか。それは個々のメンテナーだけでなく、Linuxエコシステムと、より大きなオープンソースエコシステムのためでもあると思います。
[11:35] つまり、これはずっと前から出てきていることだと言えます。メンテナーを見つけるのは難しいことが分かっています。開発者を見つけるのはずっと簡単です。私たちには多くの開発者がいます。すべてのリリースが言及されています。しかしメンテナーになるには、ええと、すべてをこなせるこの種のスーパー開発者でなければならないと考える人もいますが、それは実際には真実ではありません。しかしメンテナーになるには、他人のコードを判断できる一定の良いセンスが必要です。
[12:08] そしてその一部は…生まれつきかもしれませんが、多くはただ練習が必要なだけです。他人のコードを見て、これが良いアプローチか悪いアプローチかを簡単に見分けられるようになるには、通常は何年もやってきたことの問題です。だからメンテナーになり、仕事をうまくやるには、長い間やらなければなりません。そして私たちには多くの優れたメンテナーがいますが、もう一つの部分は、常にそこにいなければならないということです。
[12:42] ええと、あるいは一緒に働ける他のメンテナーを見つけて、休暇などの周りでスケジュールを組めるようにしなければなりません。私にとって、常にそこにいることは問題ではありません。なぜなら自分がやっていることを愛しているからです。私は数か月前に休暇中で、ノートパソコンを持って行きました。もしノートパソコンを持っていなかったら、とても退屈していたでしょう。なぜならそれが私のやることであり、長い間やってきたことだからです。
[13:17] しかし、それがすべての人にとっての人生ではないと私は認識しています。特にこれに人生の何年も費やさなければならない場合は。だから私たちにはこれに対する解決策がありません。私たちはさまざまな解決策について話し合ってきましたし、多くのメンテナーグループがさまざまな解決策を形成してきました。そして問題の一つは、人々は難しいということです。コードは簡単です。コードを書くには正しい答えと間違った答えがあります。人間関係は難しく、他の開発者と協力し、他のメンテナーと協力し、特に異なるものを扱い、異なる目標を持つメンテナーがいて、自分の領域を一方向に押し進めたいと思い、別の領域から別のメンテナーが来て別の方向に引っ張りたいと思う場合に協力することは難しいです。
[14:09] それは非常にストレスフルになり得ます。そして、多くの人がオープンソースはすべてプログラミングだと思っているようですが、そうでもあります。しかし…その多くはコミュニケーションでもあります。そしてそれは同じ人である必要はありません。多くの場合、あまり社交スキルのないプログラマーがいるのは良いことです。そういうことは起こりますよね？そして、翻訳する役割のメンテナーが必要になるかもしれません。翻訳と言っても、日本では、多くのオープンソースプログラムで言語の問題もあります。
[14:50] プロジェクトですが、翻訳と言うとき、必ずしも言語を意味しているわけではありません。文脈を意味しています。コードの理由です。ええと、そしてこれもまた、メンテナの仕事の一つで、開発者の成果物を受け取り、それをプロジェクトに翻訳するというもので、これまた…大変な仕事であり、ある種の人材を必要とします。そして、これほど多くのメンテナがいることは幸運です。もしメンテナになりたいなら、信じてください、トップには空きがあります。しかし、実はこれが次に話したかったことなのです。なぜなら、トップを見ると、サブメンテナのレベルにいる人々を見ると。
[15:37] 最近のほとんどの人は、グレッグのように髪がないか、それは厳しいですね。あるいは私たち二人のように、まだ完全には白髪になっていません。髪が完全に白髪になっていないと自分を騙す人もいます。それを受け入れた人もいます。しかし冗談はさておき、リーダーシップ、メンテナーツリーのトップと呼ばれる人々は、確かにそこでかなりの高齢化が見られます。明らかに時間が経つにつれてそれは起こらなければなりません。
[16:14] 五年先を見据えると、多くの人々が60に到達し始め、最初の人々は70に近づくでしょう。これはどこへ向かうとお考えですか？それは——ある程度は、持っていて嬉しい問題です。つまり、カーネルサミットは一ヶ月前でしたか、そんなところですよね？ - 三週間です。 - 三週間前。そして実際、私個人が「そう、私たちの多くが白髪になりつつある」という事実に反応した最初の年でした。
[16:44] ありがとうございます。しかし同時に、その理由の一部は本当に、メンテナーサミットは約30人程度に制限しようとしているからです。その30人のうち、少なくとも三人は30年以上前から関わっていました。つまり彼らはLinuxが存在し始めた最初の年からのようなものであり、彼らがまだ周りにいて、まだ活動的で、まだメンテナーサミットに来ているという事実は、そう、彼らが年を取り白髪が増えたということを意味しますが、同時に人々が実際に留まるコミュニティが私たちにあるということも意味します。
[17:20] しかしそれは諸刃の剣です。まったくその通りです。そして、それは…例えば、カーネルのRust側で私が気に入っていたことの一つは、明らかに他のほとんどのメンテナーよりずっと若いメンテナーが一人いたことです。それがRustのメンテナーでした。そして、カーネルの特定の領域はより多くの若者を引き寄せるということがはっきりと分かります。メンテナーサミットで、ファイルシステムの人々と、非常に慎重で堅実で、自分のコードが100%正しいことにとても深く気を配っている人々との間に明確な分断がありました。なぜなら、ファイルシステムにバグがあれば、ディスク上のデータが失われる可能性があるからです。
[18:13] つまり、こうした人々は自分自身を非常に真剣に受け止め、自分のコードを非常に真剣に受け止めています。そして一方で、ドライバーの人々はもう少し、まあ、いいでしょう。特にGPUの人々は何でもありという感じのようです。そしてお気づきかもしれませんが、ドライバー側では若者を見つけるのがずっと容易で、伝統的にそれが私たちが多くのメンテナーを育ててきた方法です。例えば、髪のないGregもそうですね。
[18:46] Greg、申し訳ありません。後で私を殴っても構いません。つまり、私の額は年々大きくなっていますから、何と言えばいいでしょうか。私もそう遠くありません。では全く話題を変えて、別のことを話しましょう。Jimが私たちに示したように、今日のプレゼンテーションで人工知能と大規模言語モデルについて話さずに済ませることはできません。私はよく、人工知能はステロイドを打ったオートコレクトだと言います。なぜなら、大規模言語モデルがやっていることは、あなたが使う可能性が最も高い次の単語を予測し、そこから外挿しているだけだからです。ですから、それほど知的ではありません。
[19:26] 明らかに、それが私たちの生活や私たちが生きる現実に与える影響は重大です。LLMが書いたコードがプルリクエストとしてあなたに提出されるのを見ると思いますか？きっとそうなると思います、はい。つまり、すでに起きているかもしれません。おそらくより小規模で、人々がコードを書く際の助けとしてより多く使っているかもしれませんが、それは…自動化が常に人々のコード執筆を助けてきたことは明らかです。つまり、これは何も新しいことではありません。そうです。
[20:07] もはやマシンコードではありません。アセンブラすら書きません。そして今、CからRustへと移行しています。ですから、私はこれを、AIについて毎日ニュースが語るほど革命的なものとは見ていません。それは明らかに私が取り組んでいる分野ではありません。私はまだ非常に低レベルなところにいます。私は低レベルのハードウェアの詳細が好きでカーネルに入り、だから今もそこにいるのです。しかし、あなたはこれが人々のコード執筆を助け、人々が始めるのを助け得ると期待していると言いました。
[20:42] しかし、先ほどの会話とコードレビューやメンテナンスに関する課題を振り返ると、大規模言語モデルがコードのレビューを助け、サブシステムのメンテナンスを助けるところまで来ると思いますか？そうなってほしい、そうなってほしいです。なぜなら、それは確かに私が彼らが本当に輝けると見ている分野の一つで、明らかな愚かなバグを見つけることができるからです。なぜなら、この部屋に実際にプログラマーは何人いますか？- たくさん。- かなりの数ですね。私が見るバグの多くは、他の人が書いたバグの多くは、微妙なバグではありません。その多くは、あなたが考えもしなかった愚かなバグで、それを見つけるのに高い知能は必要ありません。
[21:33] しかし警告を出してくれるツールがあること、つまり、明らかな、本当に明らかなものを警告するコンパイラはありますが、もう少し微妙なケースを警告してくれるLLMがあること、例えば「このパターンは通常のパターンとは違うように見えます。本当にこれが意図したことですか？」と言ってくれるかもしれません。そして答えは「いや、それは全く意図したことではありませんでした。明らかなバグを見つけてくれてありがとう」かもしれません。ですから、LLMは大きな…あなたが軽蔑的に呼ぶように…待ってください。
[22:10] ステロイドを打ったオートコレクト、そして私は実際に彼らはそれ以上だと思っています。そしてほとんどの人がどう働くかというと、私たちは皆ある程度、ステロイドを打ったオートコレクトなのです。そして私はそれを、私たちがやっていることをより良くするのを助けてくれるツールと見ています。しかし私はいつも楽観的でした。全体として…希望に満ちて。希望に満ちて、それがあなたが使った言葉でした。はい、はい。役に立ち、希望に満ち、謙虚に。希望に満ち、謙虚に、それが私のミドルネームです。
[22:41] しかし一方で、私はあまりに楽観的だったので、32年前には、誰よりも優れたカーネルを書けると考えるほど愚かでした。ですから、違いを生み出すには時には少し過度に楽観的である必要があります。あなたのレンズに対する私のアプローチは本当にこうでなければなりません。「これは素晴らしい。これは…」私はその楽観主義を見るのが大好きです。私は必ずしもそれを共有しているわけではありません。今、多くの人が私に同意しません。
[23:13] しかし、このすべてにおいて私が心配していることの一つは、ハルシネーションを見るということです。私たちは見ます…そしてそれはLLMの専門用語です。彼らは実際にハルシネーションを起こし、でっち上げるのです。そして、実際の人間がそれを捕まえることなく自動的に物事を行う立場に置かれるほど、これが怖くなります。SF的な意味で彼らが世界を支配するという意味で怖いのではなく、あまりに多くのバグが発生し、それが私たちの生活やコードに影響を与えるという意味で怖いのです。
[23:49] ええ、私はそれらなしで毎日起きるバグを目にしています。だから心配していないのかもしれません。私たちは自分たちだけでうまくやっていると思います。そして、AIの話題をこれ以上ないハイライトで締めくくれるとは思いません。そこから次に話したい話題に移りましょう。それはデータです。もちろん、これは実際AIと非常に関係があります。30年前にオープンソースを始めたとき、コードこそが未来を支配するものであり、協力する能力、つまりジムが説明したように、私たちが作り出した何十億ドル相当のコードが未来を決定づける要因だと感じていました。それは1990年代には確かに真実でした。
[24:38] 今日の私たちの生活を見ると、世界を支配しているのはコードよりもはるかにデータのように思えます。世界のGoogleやAmazonやAppleが私たちについて知っていること。では、オープンデータについての議論に参加されますか？つまり、革命を別の領域で繰り返すということですか？ - いや、いや、オープンソースで私が最も楽しんでいることの一つは、手を離して、自分の側でないことには気にしないでいられることです。
[25:11] つまり、それは... カーネルの中でもまさにそうで、私が個人的な労力を他の人よりもはるかに集中させる領域があります。そして、その側を維持する他の人たちに心配を任せます。ネットワーキングやドライバーなどです。そして、LFのすべてのプロジェクトでもまったく同じことが言えます。ええ... 私はLinux Foundationのより著名な従業員の一人かもしれません。
[25:43] しかし、私は自分をカーネルに留めています。 - それがLinux Foundationと名付けられています。 - はい、素晴らしい名前です。しかし、私はオープンソース、いやオープンソースでさえなくても、オープン性という概念がこれほど広く受け入れられるようになったことを楽しんでいます。そして特にそれを楽しんでいるのは、それがどうだったかを覚えているからです。30年前、私がこのプロジェクトを始めたとき、人々は私に「なぜ？」と尋ねました。そうですよね？そして人々は「でもどうやってお金を稼ぐの？」と言いました。
[26:20] そうです。そしてこれはかつて質問でしたが、もう決して出てきません。だから、私たちがオープンデータについて話していること自体、そして誰も「なぜそんなことをするの？」とさえ尋ねないこと。それが本当の核心だと思います。オープン性は、ある程度まで業界内の標準になったと思います。そして人々は、大きなプロジェクト、それがプログラミングであれデータであれ、持たなければならないとき、企業間で共有する必要があるほど大きくなってしまうと、ある程度当然のことと考えています。
[27:02] 共有する最も簡単な方法は、それをオープンにして、完全に広範な共有を可能にするライセンスを使うことです。そして、これはLFが行っていることの一つです。だから、LFがオープンデータを行っているという事実は素晴らしいことですが、それは私がやっていることだという意味ではありません。しかし、ジムの基調講演を振り返ると、Linux Foundationが焦点を当てていることの多くは、個人を超え、企業を超えて、社会として協力し物事を行うことだと思います。
[27:37] あまり誇張しすぎないようにしましょう。人々が集まって物事を行える中立な場所があることには、非常に大きな役割があります。 - ええ、つまり、これこそがまさに私がLinux Foundationで働いている理由です。なぜなら、私はLinux企業で働くことを決して拒否しているからです。なぜなら、一つの企業や一つの商業団体が特別な場所になる状況に陥りたくなかったからです。だから100%に同意します。中立な場所が必要です。そして... だからこそ、下のリンクに私の名前を載せたのです。
[28:15] ではオープンデータです。その先はどうなると思いますか——この開放性が向かう方向は。私たちはオープンコードからオープンデータへと進みました。これはどこへ向かうのでしょうか？どこが——？これは五年、10年の話です。そして私はいつも、私の答えはいつも同じです。私は地道なエンジニアです。目の前の一歩を見ます。10年後に世界がこうなるなどという大げさな発表はしません。 - この人のメールを覚えています。彼は「ねえ、この楽しい小さなプロジェクトを始めたんだ」と言っています。
[28:54] 「ただの小さな趣味です」 - ええ、つまり、それは私が予測するのがいかに下手かを証明しているようなものです——ええ、だからこそこの部屋に千人の人々がいるのです、あなたは計画がとても下手だから、でしょうね。ええ、今は実際、多くの人が時々、長期的な計画を持つことは素晴らしいと思っています。そして私はそれはうまくいかないと思います、政治ではうまくいきません。五年計画の話全体はその分野ではあまりうまくいきませんでしたし、技術でもあまりうまくいくとは思いません。どこへ行きたいかという考えはある程度持たなければなりません。
[29:33] しかし、目の前を見なければ... ただ... 手探りで進み、山の頂上に実際にたどり着くことは決してないでしょう？大きな旅を心に描いているかもしれませんが、それでも一歩ずつです。そしてこれは特に技術において真実で、世界を一つの大きな飛躍で変えることはできません。改善するためにすべての小さな一歩を踏み出す必要があります。あなたは技術者です。スライドを... そこにたどり着くまで... - ええ、そしてあなたは比較的近い未来で考えるのが好きなので、今日の会話の締めくくりとして挑戦を一つ出そうと思います。では、来年Open Source Summitが日本に戻ってくるとき、どこで開催すべきでしょう？私は沖縄を提案します。あなたはどうですか？ - ええ、それは... 私は実際に東京を楽しんでいます。妻と一緒にここに来ているので、私たちは...
[30:33] 歩き回って変わったショッピングモールに行ったりして、ここで楽しい時間を過ごしています。でも沖縄もいいと思いますよ。そしてその話で、皆さんありがとうございました。お会いできてよかったです。
英語の原文字幕を見る
[0:00] Now I'm pleased to introduce our next speaker for conversation. Please welcome--please welcome to the stage, Dirk Horndell, the head of the Open Source Program Office at Verizon and the creator of Linux and Git, Linus Tobos. Please welcome. Bye.
[0:31] Thank you. Good morning. It's so funny to see all these cell phones pointed at us. I want to take out my cell phone and take a picture of all of you, but I left my phone over there. I'm Dirk Hoendel, I run open source at Verizon, and to quote Jim Zemlin, this is that other guy. Yes. Yeah, I'm the other guy, and I've done this before, and we've done this. Dirk said this is apparently the 23rd time we've done it.
[1:04] And the reason we do it this way is I do not enjoy giving public talks. I'm sure a lot of you understand that it's not the most fun thing in the world, so we've come up with this format where Dirk prepares. questions that I don't know beforehand, and we have more of a discussion in front of you, and that makes me much comfortable and hopefully it works for you people too. Yeah, and usually it works well. And occasionally he throws me curveballs that make me go, what do I do now? So let's see which one this one is. So I'm thrilled to be back in Japan. It's been a few years.
[1:43] sadly. We did our traditional sushi OD last night and it's It's always good to be here. Thank you so much for for having us. The timing changed. It used to be that the Japan conferences were like in June. And so being here pre-Christmases are actually kind of fun. So I'm-- quite happy. - And we've been lucky with the weather too. - Yes, it's been gorgeous. So Linus, you released Linux 6.7 RC4 a couple of days ago.
[2:16] And one of the fun things that came out in this is that we are going to have a Christmas New Year's Eve kernel. Well done. Good timing. Well, I mean, we have releases every... two and a half months, I think 10 weeks is basically what I try to aim for. So this happens every time that Christmas comes around, and we have The merge window, which is my busy time, is right around Christmas, which really destroys Christmas for me. Or we have the quiet period.
[2:54] when we're just trying to find and fix the last few bugs. And this year, happily, Christmas for me is the quiet period when the last few weeks of the release are going on and we're just waiting to make sure that we have nothing big going on that is a show stopper. And that works really well for me, but it means that All the... some maintainers and developers who are now preparing for the next version, 6.8, They will -- they will be in a slight panic just because they know that after Christmas my merge window opens, and that's when they are supposed to have all their stuff ready for the next version.
[3:39] So we'll probably delay that by a week or two just because We do that every year to make the timing work out better because nobody wants to work over Christmas. Yeah, but so with 6.7, what's exciting? Anything that sticks out to you. Um... We've actually had for the last, almost 20--no, not 20 years but 15 plus years, we've had a very regular release schedule. I'm happy to say that 6.7 is-- turning out to be one of the boring releases. Boring is good. - Boring is good. - You don't want to have too much excitement, because excitement usually means big bugs.
[4:23] 6.7 is-- - Bugs with a G, not with a CK. - Yes. Yeah. Thank you. Horrible. But 6.7 is actually slightly unusual. I think it may be the biggest release we've ever had when you just count number of commits. And, uh, The reason for that is actually we have a new file system that has been in the works for like a decade.
[4:56] There's a lot of new commits coming in for that. But it's still interesting to see that Not only are we keeping steady, we are still actually increasing the development speed. and the Kernel sizes tend to be going up, which Which is a good sign, but it obviously also means that there's a lot more work going on and a lot more work for maintainers to deal with. Yeah, besides Linus not liking my joke, I want to apologize to the simultaneous translators, because I have no idea how you would translate this into Japanese.
[5:36] So one of the things we've talked a lot about over the last few kernel releases is the introduction of Rust into the kernel And I think it has been-- relatively steady and quiet. What's your perception? - Well, the rest still is at the point where we don't, we have, The initial infrastructure got merged last year. It's been growing, but we don't have any part of the kernel that really depends on Rust yet. To me, Rust was One of those things that A, made technical sense, but to me personally even more important was that We need to not stagnate as as a kernel and as developers.
[6:22] And so I am always-- excited by trying something new and not getting too comfortable doing the same thing. I mean, I've been working on the kernel now for 32 years. Yeah, 32 years. And that's a long time to work on one single thing, but it's still interesting because it's not the same single thing. I mean, Linux 32 years ago was very different from what Linux is today, obviously. I actually-- often look for things where where we can do new things and we can do things differently, because it's so easy to get stuck in a rut and say, "This is working just fine," right?
[7:06] and rust. has not really shown itself as the next great big thing, but I think during next year, we'll actually be starting to integrate and some even major subsystems that are starting to actively use it. So it's one of those things. It's going to take years before it's a big part of the kernel, It's certainly shaping up to be one of those. - So you're writing Rust code yourself? You're reviewing Rust code? - Oh no. I have been reading Rust code a bit just so that I can make some kind of judgment calls on when something is too horrendous to be included in the kernel. But I have to admit, no.
[7:54] I mean, the colonel We rely on literally thousands of people. Every single release we have, a thousand people involved, and they're not the same thousand people. Quite often we have people, in fact, for the longest time, we've had the statistics be roughly that every release... about half the people involved Send just one patch. And a lot of them never show up again. They may have something small they wanted to fix that they cared about, and they were not really colonel people. They found it for some other reason.
[8:29] and they sent their small, patch to the colonel. And they were never interested in doing anything more. But then-- The other half. keeps coming back. And when it comes to rust, I'm not going to be the one who manages the rust cover because that's not my expertise, as is true of so many other parts of the kernel. I'm honestly I'm less of a programmer these days than I am, I call myself a technical lead because I'm not a manager.
[9:03] I don't manage people, I manage code. So I call myself a technical lead. I'm not, my day-to-day work is not programming, it is merging other people's codes and Rust will be one of those states. Yeah, so Jim in his keynote pointed out that open source developers sometimes are opinionated. sometimes they express their opinions. - I'm sorry? - You have had in the past a reputation for being expressive and not lately of course, but one of the things that I've been wondering about, so Who is currently on your naughty list? Who are the companies that might... Oh, I'm not going there.
[9:46] I went there... Can we get a sign of hands? Should he go there? No, no, no. It's one of those things you... give some company the finger 20 years ago. And that picture keeps coming up every day. So I learned my lesson. I think it's still the number one search result when you look for images of you. I think that's still The first kid, yes. But I mean, to be honest, I mean, I joke, but at the same time, the whole commercial environment has gone so much better over the last 20 years. We used to be in the situation that it was, hard finding documentation for hardware.
[10:27] And some companies would be actively hostile. And that's just not true anymore. I mean, now We have companies that write drivers for their own hardware, and sometimes it's so hard to find documentation because writing documentation is hard. And a lot of companies don't necessarily want to document some of the quirks or bugs in their hardware, but we're in such a good position when it comes to hardware support.
[10:57] compared to where we used to be. So you talked about the changing environment. The Kernel Summit was just a few weeks ago. And one of the topics that has been very common at the Kernel Summit for many years is this overall question of maintainer fatigue and how draining and stressful this role is. what are we doing to improve the situation, which is not just for the individual maintainers but for the Linux ecosystem and for the larger open source ecosystem, I guess.
[11:35] So I mean, I seem-- say, I mean this has been an thing that has been coming up for the longest time. It turns out it's hard to find maintainers. It's much easier to find developers. We have a lot of developers. Every release is mentioned. But to be a maintainer, Um, Some people think that you have to be this kind of super developer that can do it all, but that's not actually true. But to be a maintainer, you have to have a certain amount of good taste to--you can judge other people's code.
[12:08] and Some of that-- maybe innate, but a lot of it is just it takes practice. to look at other people's code and easily be able to tell, is this a good approach or a bad approach? it's usually just a matter of having done it for many years. So to be a maintainer and be good at your job, you have to do it for a long time. And we do have a lot of great maintainers, but the other part of it is You have to be there all the time.
[12:42] uh or you have to find other maintainers that you can work with so that you schedule around your vacations and things like that. For me, being there all the time is not a problem because I love doing what I'm doing. I was on vacation. a couple of months ago and I had my laptop with me And if I didn't have... my laptop with me, I would have been so bored. Because it is what I do, and it is what I've been doing for a long time.
[13:17] But I realize that's not the life for everybody, especially when you have to put in years of your life into this. So we don't have a solution to this. we've been talking about different solutions and many of our maintainer groups have formed different solutions, and it turns out one of the issues is People are hard. Code is easy. To write code you have a right answer and you have a wrong answer. People relationships are hard and being able to work with other developers, work with other maintainers, and work, especially when you have maintainers that work on different things and they have different goals, and they want to push their area in one direction and another maintainer comes in from another area and wants to pull it in another direction.
[14:09] It can be very stressful and It's one of those things where A lot of people seem to think that open source is all about Programming? But... A lot of it is about communication too. And it doesn't need to be the same person. Quite often it's good to have, you have your programmer that does not have a lot of social skills. It happens, right? and then you may need to have a maintainer who's the one who translates, and I say translates not, I mean in Japan, We have the language issue too in many open source programs.
[14:50] project, but when I say translates, I don't necessarily mean language. I mean the context. the reason for the code. Um, And that's again one of those jobs of a maintainer to kind of take take the developer output and translate it into the project and again makes Makes four. a tough job and a certain kind of person. And we're lucky to... to have as many main tears as we do, If you want to be a maintainer, Trust me, there's room at the top. But this is actually where I wanted to go next. Because if you look at the top, if you look at the people at the sub-maintainer level.
[15:37] Most of them these days are either like Greg and have no hair. or they are, that's rough. Or they are like the two of us and they have It's not completely gray yet. Some people kid themselves that the hair isn't completely gray yet. Others have accepted that. But Kidding aside, the the leadership, what you call at the top of the maintainer tree, we are certainly seeing a significant aging there. Obviously as time goes by that has to happen.
[16:14] If I look five years into the future, and a lot of people will start hitting the 60s, and the first ones will approach the 70s. Where do you see this going? It's a--to some degree, it's a good problem to have. I mean, so the Kernel Summit was what-- a month ago, something like that? - Three weeks. - Three weeks ago. And it was actually the first year when I personally reacted to the fact that yes, a lot of us are going gray.
[16:44] Thank you. But at the same time, part of the reason really is The maintainer summit is we try to limit it to about 30 people or so. Of those 30 people, at least three of them had been around for more than 30 years. So they had been around since like, the first year of Linux existing, and the fact that they are still around and still active, and still end up coming to maintainer summits means that yes, they are older and grayer, but it also means that we actually have a community where people do stick around.
[17:20] But that's a double-edged sword. Absolutely. And it's... For example, one of the things I liked about the rust side of the kernel was that there was one maintainer who was clearly much younger than most of the maintainers, and that was the rust maintainer. And, and, uh, we can clearly see that certain areas in the kernel bring in more young people. We had a--in the maintainer--at the maintainer summit, we had this clear division between the file system people who were very careful and very staid and they cared deeply about their code being 100% correct because if you have a bug in a file system, the data on your disk may be gone.
[18:13] So these people take themselves very seriously and their code very seriously. And then you have the driver people who are A bit more, OK. Especially the GPU people seem to be like, anything goes. And you did notice that the-- On the driver's side, have a much easier time finding young people and that is traditionally how we've grown a lot of maintainers including I mean, Greg with no hair.
[18:46] I apologize, Greg. You can beat me up later. I mean, my forehead is getting larger every year, so what can I say? It's not far away from me. Let's switch gears completely and talk about something else. You cannot possibly give a presentation today as Jim proved to us. without talking about artificial intelligence and large language models. Um, I typically say artificial intelligence is autocorrect on steroids. because all a large language model does is it predicts what's the most likely next word that you're going to use and then it extrapolates from there. So, not really very intelligent.
[19:26] Obviously the impact that it has on our lives and on the reality we live in is significant. Do you think we will see LLM written code that is submitted to you as a pull request? I'm convinced it's going to happen, yes. I mean, and it may well be happening already, maybe on a smaller scale where people really use it more as a, as a help in writing code, but It's... it's clearly is something where Automation has always helped people write code. I mean, this is not anything new at Right.
[20:07] machine code anymore. We don't even write assembler. And now we're moving on from C to Rust. So I don't see this as something as revolutionary as all the news talk is every day about AI. It's not an area I obviously-- work with. I'm still very low level. I got into kernels because I love the low level hardware details and that's why I'm still there. But so you say you expect this can help people write code, this can help people get started.
[20:42] But then if we look at the previous conversation and the challenges around code reviews and maintaining, so do you think that large language models will get to the point that they can help us review code, that they can help maintain subsystems? I hope, I hope, because that's certainly one of the areas where which I see them really being able to shine, to find the obvious stupid bugs. Because, I mean, how many people here are actually programmers in this room? - A lot. - A fair number. A lot of the bugs Ivory right a lot of the bugs I see other people right? They're not like I subtle bugs. A lot of them are just the stupid bugs that you did not think about and you don't need to and his kind of higher intelligence to find them.
[21:33] But having tools that warn-- I mean, we have compilers that warn about the obvious, really obvious ones, but having LLMs that warn about slightly more subtle-- cases where where it may just say, This pattern does not look like the regular pattern. Are you sure this is what you mean? I and The answer may be, no, that was not at all what I meant. You found an obvious bug. Thank you very much. So I do think that LLMs are going to be a big -- you call them disparagingly -- Wait.
[22:10] autocorrects on steroids and I actually think that They're way more than that and how most people work is we all are. autocorrects on steroids to some degree. And I see that as a tool that can help us be better at what we do. But I've always been optimistic. The whole -- Hopeful. Hopeful was the word you had. Yes, yes. Helpful, hopeful and humble. Hopeful and humble, that's my middle name.
[22:41] But -- On the other hand, I mean, I have been so optimistic that 32 years ago, I was stupid enough to think that you can write a better kernel than anybody else. So you have to kind of be a bit-- bit too optimistic at times to make a difference. My approach to your lens really has to be in that, hey, This is wonderful. This is going to... I love seeing the optimism. I don't necessarily share it. Now a lot of people disagree with me.
[23:13] But one of the things that I worry about in all this is we see the hallucinations. We see... And that's a technical term for LLMs. They do hallucinate and they do make up stuff. And so the more they are being put into the position where they will automatically do things without an actual human being there to catch them. the more this becomes scary. not scary as in they will rule the world and not in the sci-fi sense, but in the so many bugs that will happen and that will affect our lives or our code.
[23:49] Well, I see the bugs that happen without them every day. So that may be why I'm not so worried. I think we're doing those just fine on our own. And I don't think I can end the AI topic on a better highlight. Let's go from there to my next. topic I wanted to talk about, which is data. Which is, of course, very related to AI, actually. 30 years ago when we started on open source, it felt like code was the thing that controlled the future and the ability to collaborate, to have this, as Jim described it, billions of dollars worth of code that we have created is the determining factor of the future. That was certainly true in the 1990s.
[24:38] If I look at our lives today, it seems it's far more data than controls our world. What the Googles and Amazons and Apples of the world know about us. So, do you get engaged in the discussions about open data? So-- repeating that revolution just in a different realm? - No, no, so one of the things I enjoy most about open source has always been that I can let go and not care about the things that are not my side.
[25:11] I mean, that's... That's been true very much inside the kernel too where there are AREAS. where I concentrate. my personal effort much more than others. And I let other people who maintain that side worry about. like networking, things like drivers. And the same is very much true of All the LF projects. Uh... I may be one of the more high profile employees of the Linux Foundation.
[25:43] But I keep myself into the kernel. - Which is named the Linux Foundation. - Yes, it's a great name. but I I enjoy the fact that open source and not even open source, the notion of openness has gotten so much more widely accepted. And I enjoy it particularly because I remember what he was. 30 years ago when I had started this project and people would ask me, Why? Right? And people would say, But how do you make money?
[26:20] Right. And this used to be a question and it never comes up anymore. So the fact that we are even talking about open data And nobody even asks, "Why would you do that?" I think that's the real, deal here. Openness has, I think, to some degree become the standard within the industry. And people kind of take for granted that when you have to have big projects, whether they are programming or data, and you end up having them so big that you need to share between companies.
[27:02] The easiest way to share is to just make it open and use a license that allows for completely wide sharing and I mean this is what one of the things LF does. So the fact that LF does open data is great, but that does not mean that it's a thing I do. But I think that if you reflect on Jim's keynote, A lot of what the Linux Foundation is focused on is that collaboration beyond the individual, beyond the company, to collaborate and do things as a society.
[27:37] trying to be too hyperbolic here. There is a very huge role in having that neutral place that people can come together and do things that-- - Well, I mean, this, that is literally why I'm working at Linux Foundation. because I refuse to ever work at a Linux company. because I did not want to be in the situation where one company or one commercial entity would be the special place. So I agree 100%. You need to have a neutral place. And-- That's why I gave my name to the links below.
[28:15] So open data. What do you think Beyond that will be-- the the direction this openness is taking. We went from open code to open data. Where are we going with this? Where is the--? This is the five year, 10 year thing. And I always, my answer is always the same thing. I'm a plodding engineer. I look at the step in front of me. I don't make grandiose announcements of, this is what the world will be 10 years from now. - I remember there's this email of this guy. He says, "Hey, I started this fun little project.
[28:54] "It's just a little hobby." - Well, I mean, that kind of proves how bad I am at predicting the-- Yes, this is why there are a thousand people in this room, because you're so bad at planning, I guess. Yes, now I actually think A lot of people sometimes think that having of long-term plan is great. And I don't think it works, it doesn't work in politics. The whole five-year planning thing did not work so well in that area and I don't think it really works in technology very much. You have to have kind of an idea of where you'd like to go.
[29:33] But if you don't look... Right in front of you, you will just... fumble around and you'll never actually get to that top of the mountain, right? You may have a great big journey in mind, but it's still one step at a time. And that is particularly true in technology where you can't just change the world in one big leap. You have to take all the small steps to to improve. You are technical. slide until you get-- Well, and since you like to think in relative near-term future, So I figure I'll give you a challenge for for the end of our conversation today. So when the Open Source Summit comes back to Japan next year, Where should it be? I'm suggesting Okinawa. How about you? Well, that would... I mean, I actually enjoy Tokyo. I'm here with my wife, so we've been...
[30:33] walking around and doing odd shopping malls, and have been having a good time here. But Okinawa sounds good to me too. And on that note, thank you, everyone. Good to see you.
Vidleafワークベンチで開く
トランスクリプトを検索し、行を選択し、タイムスタンプ付きの引用をコピーし、翻訳します。
帰属
「基調講演：Linus Torvalds、Linux & Gitの創始者、Dirk Hohndelとの対談」The Linux Foundation（https://www.youtube.com/@linuxfoundationorg）による、CC BY 3.0（https://creativecommons.org/licenses/by/3.0/）の下でライセンスされています。ソース動画：https://www.youtube.com/watch?v=OvuEYtkOH88。このページは動画のテキスト書き起こしであり、段落区切りとタイムスタンプが追加されています。制作者はVidleafと提携しておらず、Vidleafを推奨していません。VidleafはAIによる句読点とAI生成の要約を追加しました。元の文言はこのページで引き続き利用可能です。読解テキストには、Vidleafによるソースで検証された名前の修正も含まれています。
あなたは制作者または権利者ですか？訂正や削除をリクエストする：copyright@vidleaf.app（これらのページについてを参照）。
最終更新