Dave Cutlerが語るWindows［動画］
(youtube.com)- Dave Cutlerは、RSX-11、VMS、Windows NTを経てAzureやXboxへと続く経験をもとに、Windows NTの設計背景とMicrosoftの開発文化を振り返る
- Windows NTは当初からポータブルなオペレーティングシステムと複数の実行環境のサポートを目標としており、Windows 3.1が6か月で1,600万本売れたことで、OS/2ではなくWindowsが中心環境になった
- 初期のNTはi860、MIPS、x86、Alpha、PowerPCなど複数のアーキテクチャと、HAL、オブジェクトマネージャ、カーネル／ドライバ構造を扱っており、中核構造のかなりの部分はWindows 11にも残っている
- VMSはリリース時点で既知のバグ0件を目標としており、NT開発チームはFriday WHIMで組織の結束を保ったが、NT、Cairo、Longhorn、XPのセキュリティ対応では、スケジュール、品質、コードベースの分岐が大きな負担になった
- Cutlerは、バグ修正、テスト、品質確保、不要な機能を入れない節度を、優れたソフトウェアチームの核心的な姿勢だと見ている
Windows NT以前のオペレーティングシステムでの経歴
- Dave CutlerはDuPontでリアルタイムシステムとコンピュータシミュレーションに触れた後、問題解決の道具よりもコンピュータそのものに強い興味を持つようになった
- Scott Paperのフォーム製造工程をGPSS 3でシミュレーションするプロジェクトで、カードのエラーとデバッグを経験した
- エラーを減らすためにFortranプログラムを書き、その後IBM 7044のアセンブリまで学び、コンピュータ内部の動作への関心を広げた
- DuPontのリアルタイムシステムグループでは、Instronの引張試験データを自動解析するプログラムを書いた
- データ収集プログラムはリアルタイムで動作し、1ミリ秒または100ミリ秒単位でデータを読む方式だった
- その後、Univac 1107のオペレーティングシステムExec IIの作業を担当し、オペレーティングシステム開発に本格的に入った
- 毎日午後5時にオペレーターを退出させた後、2時間にわたって実験コードとテストを走らせた
- デバッガがほとんどない環境で、スイッチとhalt instructionを使ってデバッグした
DEC時代：RSX、VMS、コンパイラ、PRISM
- Digital Equipment Corporationでは当初OS/45のために雇われたが、すぐにRSX-11Cの作業を担当した
- 当時のPDP-11の16ビットアドレス空間は、Cutlerから見ると大きな制約だった
- RSX-11Cは小さなシステムで、当時の基準でも機能が限られていたと評価している
- VMS開発は、VAXハードウェアとPDP-11互換実行レイヤーを活用してブートストラップされた
- VAXにはPDP-11モードがあり、Application Migration ExecutiveというレイヤーでRSX-11Mユーティリティを実行した
- Files-11ファイルシステムもVMSとして再実装し、互換性を維持した
- 開発初期には、ハードウェアエミュレータ上でスケジューリングやメモリ管理などの中核作業を進めた
- VMSはセルフホスティングを品質確保の手段とした
- Proto 3で十分安定して実行できるようになると、開発チームはそのシステム上で直接作業した
- システムがbug checkを出すと、数人がマシンの前に行ってデバッガで原因を探し、修正後に再度ブートする形で進められた
- VMSはリリース時点で「既知のバグ0件」だったと振り返っている
- これは「バグがなかった」という意味ではなく、リリース時点で把握していたバグをすべて直そうとしたという意味である
- 最後の瞬間にもディスクドライバのrace conditionを修正した
- VMSの後は、PL/IコンパイラとCコンパイラのバックエンド、コードジェネレータ、最適化、レジスタ割り当てにも関わった
- PL/IのフロントエンドはBostonの会社から購入し、バックエンドはVAXで開発した
- 一部のフロントエンド作業はMITのMulticsで行い、データをテープで移した
- DEC Westでは、VelonというリアルタイムシステムとMicroVAXプロジェクトに参加した
- Velonはユーザーモードドライバ、メッセージ指向構造、マルチスレッディング、マルチプロセッサといったアイデアを実験したシステムだった
- MicroVAX 1ではCutlerがマイクロコード全体を書いた
- PRISMプロジェクトはDECによるRISCアーキテクチャの試みであり、取り消しの翌日にCutlerは会社を辞めることを決めた
- PRISMには32ビット版と64ビット版のアーキテクチャがあり、Micahという野心的なソフトウェアシステムも進行中だった
- PRISM中止後はサーバー会社を起業しようとしたが、Microsoftと接触したことで方向が変わった
Microsoft入社とWindows NT設計
- Microsoft入社はBill Gatesとの会話後も確定的ではなかったが、Steve BallmerとDenny’sで朝食を取った後、すぐに決まった
- Cutlerは、BallmerがMicrosoft入社を説得した中心人物だったと見ている
- NTの初期目標はポータブルなオペレーティングシステムと複数の実行環境のサポートだった
- 当時の対象環境はOS/2で、POSIXも重要な候補だった
- システムの中核が基本サービスを提供し、その上に複数の環境を載せる構想から始まった
- WindowsがNTの中心環境になったきっかけは、Windows 3.1の成功だった
- Windows 3.1は6か月で1,600万本売れ、Bill Gatesは新しいシステムの主環境がWindowsになると判断した
- NT開発はOS/2上で行われることもあったが、チームは早くNT自体でセルフホスティングしたいと考えていた
- NTという名前は「New Technology」を意味する
- i860のコード名N10とNTの間に曖昧なつながりはあったかもしれないが、CutlerはNTをNew Technologyと見ている
- マーケティング側は「新技術」という名前が購入をためらわせる可能性があるとして反対したが、CutlerがNTという名前を押し通した
- NTの最初のバージョンは複数のCPUアーキテクチャをサポートした
- x86、MIPS R3000/R4000、Alphaが挙げられている
- PowerPCはNT 3.5またはDaytonaの時期に入ってきたが、CutlerはPowerPCビルドとハードウェアの競争力は高くなかったと評価している
- NTのHALは本来、ハードウェア抽象化レイヤーを超えてベンダー抽象化レイヤーに近かった
- 初期には別DLLとして構成し、ベンダーがHALを提供できるようにした
- Cutlerは後になって、HALをオペレーティングシステムの一部のようにビルドするほうがよかっただろうと見ている
- NTカーネルとHALにはアセンブリは多くなかった
- 性能上必要な一部の頻繁な演算には、アセンブリやintrinsicが必要だった
- x64ではinline assemblyの代わりにintrinsicを使う方向を選んだ
NT開発文化、Cairo、Longhorn、XPセキュリティ
- NTチームは急速に大きくなる組織をまとめるため、毎週金曜日にWHIMを開いた
- WHIMはWeekly Integration Meetingの略だった
- 初期にはマネージャーたちがSafewayでビールとチップスを買ってきてハードウェアラボで開き、後にはより大きな場所とケータリングへ拡大した
- Cutlerは、NT開発が人々をひたすら酷使していただけという描写は事実ではなく、毎週緊張を解く機会を作ろうとしていたと見ている
- NT 3.5以降、Windows 95のUIをNTへ持ち込む流れとCairoプロジェクトが並行して進んだ
- Tuckwilaは一種のバックアップ版NT 4.0のように維持され、毎日のビルドでTuckwilaは安定して出てきたが、Cairoは頻繁に壊れた
- Cairoの機能は次第に外され、Cutlerが記憶している主な移植結果はファイルサーバーソフトウェアとKerberos程度だった
- NT 4.0は非常に人気のあるバージョンとして残り、Cutlerは今でもNT 4.0を使っている人に会ったことがある
- NT 3.1のスケジュールはVMSよりも長くかかった
- VMSは約20人規模の非常に優れたチームで2年で作ったという
- NTはより多くのことをしなければならず、i860を捨ててMIPS、x86、Alphaなど複数のアーキテクチャを追加したことで範囲が広がった
- LonghornからVistaへ至る過程では、コードベースの分離が大きな問題になった
- Windows 2000以降、サーバーとワークステーションのコードベースが分かれ、サーバー側はセキュリティ問題を多く修正する一方で、コンシューマー側はビルドと実行が不安定になった
- XPは大成功したがバグが多く、その後セキュリティ問題が大きくなったことで、XPのバグ修正に多くの労力が費やされた
- CutlerのグループはXP関連のセキュリティバグを約5,000件修正した
- AMDのx64拡張は、Microsoft社内で重要な転換点になった
- AMDは32ビットアプリケーションを高速に実行できる、より侵襲性の低い64ビット拡張のアイデアを提示した
- Cutlerはサーバーコードベースを基に64ビットワークステーションとサーバーを作ることにし、これは会社が最初から正式承認したプロジェクトではなかった
- AMDシステムが到着するとCDから初回ブートし、64ビットシステムはそのままブートして動作した
- microsoft.comは64ビットサーバーを約1週間試験した後に移行し、32ビットシステムよりはるかに安定していたと評価された
- Longhornは最終的にx64コードベースへ移行し、そのコードベースが現在まで続いている
Windows内部構造と現在まで残っているコード
- Windows 11にもNT 3.5時代の中核機能と構造が多く残っている
- カーネルコード、メモリ管理構造、プロセス構造、オブジェクトマネージャなどの中核は引き継がれている
- 元のコードがコード全体に占める割合は下がり続けているが、同じ機能を果たす中核構造はかなり残っている
- CutlerはNTのオブジェクトマネージャを、優れたコードベースである重要な理由として挙げている
- Unixの「すべてはファイル」という方式とは異なり、NTでは新しいオブジェクト型記述子を作り、オブジェクトマネージャに統合して新しいオペレーティングシステムオブジェクトを追加できる
- オブジェクトは同期やアクセス制御のような機能を提供できる
- handle tableは性能上重要な部分であるため、何度も書き直された
- handle translationは実際の性能問題だった
- Cutlerの業務用システムには約60個のプロセス、数百個のスレッド、15万個のhandleが開かれている状態だという例を挙げている
- Task Managerのサイズ増加は、コード肥大化の例として言及されている
- もともとTask Managerは85KBにコンパイルされていたが、現在は4MBだという
- 現在はCPU、ネットワーク、ディスクなど、より多くの情報を表示するが、Cutlerは増加幅に見合うほど機能が増えたとは見ていない
- グラフィックドライバをユーザーモードからカーネルモードへ移した判断は性能上必要だったが、成長痛も大きかった
- Cutlerは当初、カーネルモードへの移行に反対した
- ユーザーモードとカーネルモードでは同期モデルが異なり、単純なコード移動ではなく、16ビットデータ構造とprimitiveも負担になった
- その後、信頼性は大幅に向上したが、一時期はベンダー製グラフィックドライバの問題が多かった
Azure、Xbox、xCloud
- Cutlerはx64システムを出荷した後、fcib問題に落胆してMicrosoftを辞めると言い、Steve Ballmerの勧めで休暇を取った後、2005年11月に復帰した
- fcibはchecked-in binaryを意味し、ソースの代わりにバイナリをチェックインするグループのためにポーティングが難しかった
- その後、Azure初期プロジェクトに参加した
- Ray Ozzieが、複数のクラウドベースサービスに共通インフラがない問題を見て、プロジェクトを開始させた
- 初期Azureは、アプリケーション配布、設定制御、バージョン管理、再起動、課金、クラウドファイルシステムのようなプラットフォームインフラを目標とした
- AWSが提供したものはインフラ中心であり、Microsoftは当初プラットフォームサービスを売ろうとしていたと説明している
- Azure初期のハイパーバイザーは、Connectix買収で入ってきた技術を基に作られた
- ConnectixはVirtual PCとVirtual Server製品を持っており、ハイパーバイザー開発も初期段階で進行中だった
- その後、XboxハイパーバイザーはAzureのRed Dogハイパーバイザーから来た
- Xboxは3つのVM構造で動作する
- host systemはすべてのデバイスを所有し、VM間通信のtraffic copの役割を担う
- presentation VMはウィンドウマネージャと表示システムを担当し、常時実行される
- game VMはゲームごとに開始・停止され、ゲームはOSと一緒にパッケージ化される
- ゲームがOSと一緒にパッケージ化される構造は、後方互換性に有利である
- ゲーム開発者はGDKのOSと一緒にゲームをパッケージ化し、実行時に該当VMも一緒に起動される
- オペレーティングシステムの変更で既存ゲームが壊れることを避けられる
- ただし、機能を既存ゲームに入れる必要がある場合は、universal game OSのような回避策が必要だった
- Xboxのpause/resumeは、VMの保存と復元の方式で動作する
- ゲームのロードにはギガバイト単位のデータが関わるため時間がかかる
- pause/resumeはVM状態を保存し、後で復元する機能である
- 現在の作業として、xCloudコンソールのアイドル時間を活用するLinux VMとグラフィックスタックが言及されている
- xCloudはXboxコンソールをラックに再パッケージ化してデータセンターに入れ、リモートアクセスを提供する構造である
- コンソールはsingle tenantなので一度に1人が使い、アイドル時間が発生する
- Microsoft専用の機械学習ワークロードを未使用時間に走らせる計画のため、Linux VM、Xboxハイパーバイザー、グラフィックスタックに取り組んでいる
品質、チーム運営、開発哲学
- Cutlerは「成功する人は、失敗する人が拒むことをする」という言葉をソフトウェアチームにも当てはめている
- コードを書いたのだからテストはしないという態度、スケジュールが残っているのに午後5時に退勤する態度、自分のバグを直したがらない態度を問題視している
- 必要なことを自分で行い、成功へ持っていく姿勢を重視している
- 「Thinker-doer」を高く評価している
- Brooksの言葉を引用し、考えるだけの人は多いが実際に実行する人は少なく、その両方をする人はさらに少ないという
- アーキテクトも目標と制約を満たす実際の結果を作らなければならないと見ている
- 「入れなければ取り除く必要もない」という文句をUniversity of Washingtonの研究室の壁に入れたいと考えていた
- 不要な機能を入れない節度を強調する言葉として使っている
- 初期の開発環境ではデバッグツールが貧弱で、最初からミスを減らす姿勢が重要だった
- 昔はlogic analyzerやoscilloscopeまで動員しなければならない場合があった
- 今日のツールは小さなミスを減らす機能が多くなったが、品質へのプレッシャーは昔とは違うと見ている
- マルチタスクは可能だが、最高の生産性は単一作業への集中から生まれると見ている
- context switchには時間がかかるためである
- ただし、他の人が詰まっている問題を手助けしたり、バグを直したりする形での作業切り替えは行うと説明している
1件のコメント
Hacker News のコメント
インタビュアーの Dave Plummer も、それ自体がとても興味深い人物です。特に https://www.youtube.com/watch?v=JlZe2JwrJqM や https://www.youtube.com/watch?v=b0zxIfJJLAY のようなレトロコーディング動画がよかったです
動画も面白く、BGM と RGB ライティングがクリスマスの雰囲気を出しています。Microsoft についても、私が慣れ親しんでいたイメージとはまったく違って見せてくれましたし、Redmond の奇妙な点を認めつつも、自分の仕事や同僚、Microsoft について温かく語っています
ただ、このチャンネルを見ると YouTube のアルゴリズムが何か発動して、レコメンドフィードが ADHD 動画であふれます。おそらく自閉症と ADHD 関連の動画のせいだと思いますが、私が見たのはコーディングと Microsoft の歴史動画だけだ、ということくらいは YouTube が気づける程度には賢くあるべきではないかと思います
ただ、こういうことは言いたくありませんが、Microsoft/Windows 以外の話題について彼が言うことは、かなり割り引いて聞くべきです。特に下のコメント [1] 以降はなおさらです
最近、広告ブロッカーをオフにするよう強制した件も、目を開かされる出来事でした。YouTube 広告は本当に最悪で、実際の人間がそれに反応していると考えると気まずくなるほどです。YouTube は良いユーザー体験を提供しようとするふりすら諦めたように見えます
それでも、この Dave Cutler インタビューのような素晴らしいものを見るには、泥の中を少し漁る価値はあります
冗談ではなく、「半分」という表現もかなり正確です。何かが壊れたのか、YouTube がレコメンドエンジンに大規模言語モデルをつないだように見えます
きれいに編集された動画よりも、即興で話している姿を見るほうがよかったです
そのたった 1 本の動画の後、おすすめが癌の話、終末期の人たち、あらゆる病気の話でいっぱいになりました。その動画はその人の普段のコンテンツともまったく関係がなく、そうしたおすすめ動画は一つも見ていないのに、ずっと押し寄せてきます
まだこの動画は見ていないが、数年前に Showstopper[1] を読んだので期待している
20代前半で、いつも働かなければならないと思っていた頃に特に印象に残ったのは、Dave が休暇を毎回きちんと、議論の余地なく必ず取っていたというくだりだった
Microsoft を好きではないとしても、24時間ずっとすり減らされているわけではない、非常に有能で適格な人を初めてちゃんと見た例だったのかもしれない
こう書くこと自体まだ奇妙に感じるが、「苦労すればするほど徳がある」というような、田舎や小売業の文化から続く考え方だった
今でもきちんと休むのは難しく、X や Y のほうが重要だという理由で先延ばしにしがちだ。それでも Dave の視点を思い出すと、休息と X をうまくやることは二者択一ではないという良いリマインダーになる
[1]: https://www.amazon.com/Show-Stopper-Breakneck-Generation-Mic...
「安息日を覚えて、これを聖なるものとせよ……六日の間は働いて、あなたのすべての仕事をしなければならない。しかし七日目は、あなたの神、主の安息日である……」
https://en.wikipedia.org/wiki/Protestant_work_ethic
https://www.biblegateway.com/passage/?search=Exodus%2020&ver...
従業員が「鼻を砥石に押しつけて」「背骨が曲がるほど」働くほど会社の利益は増えるが、より多くの給料を払う必要はない。健康が十分に壊れて働けなくなれば、入れ替えればいいだけだ
夜遅くに書いた返信なので荒くて申し訳ないが、ここの人たちはどうせ直感的に分かっていると思う
その後バーンアウトし、今では休むことと、実際の緊急事態を除いて8時間勤務日を守ることは、個人的な責任であるだけでなく、専門職としての責任でもあると考えている。バーンアウトのリスクを下げてくれるし、バーンアウトは文字どおり誰にとっても悪いからだ
WinNT 3.1 開発の最終盤に、誰かがブルースクリーンを表示する スクリーンセーバーを作ったという投稿を読んだ。たぶん Usenet だったかもしれない
それまでスクリーンセーバーを作ったことはなかったが、Microsoft 内部のネットワークドライバのバグのせいで、自分の WinNT 開発マシンを安定してブルースクリーンにすることができた
そこで Windows のスクリーンセーバー作成ドキュメントを読み、自分のブルースクリーンに表示された値を書き留めて、最初で最後の Windows スクリーンセーバーを適当に作った
面白半分で Windows NT グループに自作したものを知らせるメールを送り、数週間後、NT ビルドグループが Dave Cutler にいたずらを仕掛けることにした
彼らは私のブルースクリーン・スクリーンセーバーをビルドサーバーの1台にインストールし、マウスとキーボードも抜いておいて待った
Dave Cutler が最新の NT ビルド状況を見に来て、モニターをつけ、ブルースクリーンを見た。マウスを動かしても何の反応もなく、キーボードを叩いても何の反応もなかった
そして予想外のことが起きた。彼は手を伸ばしてビルドサーバーの電源ボタンを押し、再起動してしまった。NOOOOOOOOOOOOOOOOOOOOO
そのいたずらの余波や結末は、結局聞くことがなかった。大いなる力には大いなる責任が伴う
私もそれをインストールしていたし、近くに座っていた同僚数人も同じものをインストールしていた
CTO が早朝の会議のために訪問して、すべての画面にそれが出ているのを見て、ウイルスの拡散かソフトウェアのバグだと思い、少しパニックになった
数週間前に誰かが勧めていた本「Showstopper!: The Breakneck Race to Create Windows NT and the Next Generation at Microsoft」を、ここでも推薦する
まだ読んでいる途中だが本当に面白く、その歴史に自分も関わっていたらよかったのにと思う。特に、まったく新しい OS をドッグフーディングしたという部分がそうだ。ただし私の時期より数年早かった
その本のおかげで、実際よりずっと詳しい人のように聞こえたし、数日前よりその分野全体にずっとワクワクしていた
オファーはもらったが、結局その仕事は引き受けなかった
関連して、これもある: https://blog.codinghorror.com/showstopper/
興味深かったのは、Xbox ハイパーバイザーがデスクトップ側で作られたものではなく Azure ベースであること、そして Xbox ゲームがデバイス上の単一のオペレーティングシステムに依存するのではなく、オペレーティングシステムと一緒にパッケージ化されていて、コンテナにもう少し近いという点だった。
Dave は、アイドル状態の Xbox Cloud Gaming デバイスで機械学習ワークロードを実行できるようにする仕事もしていると言っていた。Azure と Xbox の間にこうしたアーキテクチャ上のつながりがあるとは、まったく考えたことがなかった。
たとえばゲームの実行ファイルは実際にはゲームディスク上で暗号化されており、実行中の実際のバイナリをダンプすることすらほぼ不可能だ。RAM も暗号化されている。
また、現代の TPM が CPU の中に入るようになった理由の一つは、人々が Xbox でやったように TPM バスをスニッフィングできないようにするためだった。
Windows カーネルチームで働いていたが、DC について私がいちばん好きな話は、彼が Itanium アーキテクチャをあまりにも嫌っていて、実質的に x64 の実現を後押ししたというものだ。
AMD と一緒に仕事をしながら、自分のコーナーオフィスでひたすらコードを書き続け、その仕事を実質的に推し進めた。
「複数の、場合によっては可変ビット長の命令を1ワードに束ね、コンパイラ作者に最適な命令束を見つけさせれば、実装が単純になってより速くできる」という発想だが、コンパイラがその最適な束を見つけられなければ、x86 のような従来型の設計よりむしろ遅くなる。
Intel 内部のかなり高い立場の誰かが、このアイデアを本当に気に入っていたに違いない。主要なマイクロプロセッサ企業としての Intel の歴史を通じて三度試み、三度失敗したのだから。
当時は AMD64 は「同じものをさらに増やす」だけで、よい考えだとは見られていなかった。それでも、RISC 革命を事実上葬った寄せ集めを取り除くのに Dave が貢献したのは、よい仕事だった。
いつか自分も余暇にそれくらい印象的なものを作れたらいいと思う。
残念ながら Microsoft にとって、その戦利品は x86-64 上の Linux が持っていった。
私のソフトウェアエンジニアリングのキャリアで最も決定的だった瞬間の一つは、6〜7年前に流出した NT ソースコードを読みながら Showstopper[1] も一緒に読んだときだった。
NT の流出版が特に魅力的だったのは、作者履歴がすべて含まれていて、Dave Cutler が正確にどのファイルに手を入れたのかを見られたからだ。本では、カーネルモジュールにページング可能なセクションができた経緯なども詳しく扱っており、それ自体も興味深い。
本には Cutler が入ってきて特定のアセンブリルーチンを書き直す場面が出てくるが、実際のソースコードでそのルーチンが正確に何だったのかを見ることができる。
Cutler のコードは本当に美しい C コードだったし、今でもきっとそうだろう。私が NT スタイルの C コードを書くやり方に大きな影響を与えた。
[1]: https://www.amazon.com/Show-Stopper-Breakneck-Generation-Mic...
Computer History Museum の David Cutler オーラルヒストリー・インタビューも非常によい。
Part 1: https://youtu.be/29RkHH-psrY
Part 2: https://youtu.be/SVgSLud50ss
新インタビューのいくつかの断片は見たが、今のところ新しく聞いた内容があるのかは確信が持てない。
2人のDaveの発言を振り返ると、完成させてリリースすることにはものすごく注意を払っている一方で、長期計画や実際のセキュリティ戦略についての話はほとんどない。
すべてが商業的プレッシャーの中で、肉挽き機からソーセージをひねり出し、失敗を許容可能なレベルまで下げるという話になっている。
業界全体として状況が良くならず、正しい方向へ舵を切らないのも驚きではない。いつかは capability ベースのセキュリティに到達すると思っていたが、今ではそのほとんど無価値ないとこであるアプリケーション権限フラグに永遠に閉じ込められそうに思える。
将来が心配だ。
VPからSVPへ、SVPからCEOへ昇進する正当化材料になるような、良い四半期や数年があれば十分なのだ。前の役割で行った近視眼的な選択のせいで、3年後に新しい役割へ移った人を責めて罰することはない。
だからといってCutlerがそういう経営陣だという意味ではない。ただ、彼が上からのリリース圧力と売上の流れを維持する圧力を明らかに受けていたということだ。インタビューの序盤で彼が話しているように、彼はバグを載せたまま出荷することを本当に嫌っており、業界のソフトウェアエンジニアの品質に大きく失望していて、プログラム／プロジェクトマネージャーがすべてのバグをまれなコーナーケースのように扱うことも非常に嫌っている。この3点すべてに同意する。
私が上げるバグの大半も「コーナーケース」として扱われるが、私はその問題を毎日踏んでおり、データベースには重複 issue がいくつもあるか、私のバグがより早い報告の重複として再び処理される。
この業界で数十年、すべてBig Techで過ごして見てきたが、エンジニアや一次マネージャーがリリース前のバグ修正を推し、より頻繁なバグ修正アップデートを求めても、結局同じ種類の圧力に屈しない会社はまだ見たことがない。
大きなセールスポイントだったが、ほとんどのユーザーにはあまり響かなかった。実際、多くの人が「なぜ自分にこれが必要なのか」と感じ、「一般ユーザー」向けのOSではないように見せてしまっていた。
1990年代初頭のセキュリティ概念、つまり何がセキュリティを生み、誰にどれだけ関係するのかは、今日の期待や最新水準とは合わない。
きちんと作るには少し時間がかかるかもしれない。その間に、半焼けで、現状維持を強化する退行的な単一ランタイムベースの代替案が勝たないことを願う。
[0]: https://github.com/bytecodealliance/wasmtime/blob/main/docs/...
これこそ、ソフトウェアが私たちに「貢献した」最大の経済的産物かもしれない。「お金はいただきますが、何も約束しませんよ、カモさん！」というような拘束力のある契約のことだ。
むしろ市場に2番手で出ると罰せられる。
これを全部聞くのが楽しみだ。
その人物や彼の勤務先企業に対する感情とは関係なく、CutlerはOpenVMSとWindows NTでの仕事を通じて非常に影響力のあるソフトウェアエンジニアだった。Bell Labsの人々、Stallman、Linus、Stroustrupのような人物ほど頻繁には語られていないと思う。