- 1968年のNATO Software Engineering conferenceで生まれた「software crisis」という表現は以前ほど使われなくなったが、ソフトウェアの複雑性と抽象化が生み出した負担は今も残っている
- Edsger Dijkstraは1972年のTuring Award講演で、ハードウェア性能と複雑性が急激に増大した一方で、それを扱うための組織的手法は追いついていないと見ていた
- パーソナルコンピューティングの商業化と短いリリースサイクルは、ユーザーが道具を十分に習得する前に、より大きな容量を求めるようにし、「abstract it away」が基本的な反応になった
- 入れ子になった抽象化レイヤーは性能コストと歪んだメンタルモデルを生み、グラフィックスやサウンドのような機械の基本機能にアクセスしにくくする
- 解決策は過去の制約されたプラットフォームへ戻ることではなく、抽象化レイヤーを減らし、レイヤー間の情報を保持して、ツール利用者に主導権を取り戻させることにある
1968年の問題意識はまだ終わっていない
- 1968年の最初のNATO Software Engineering conferenceで「software crisis」という用語が生まれた
- これらの会議は、自動計算機のプログラミング慣行を整理し体系化しようとした初期の試みの一つだった
- 1969年7月16日にApollo 11ミッションが打ち上げられ、同年10月には最後のNATO Software Engineering conferenceが開かれた
- Edsger Dijkstraは1972年のTuring Award講演で、危機の原因を強力になった機械と、それを受け止める組織的手法の不在に見いだした
- 「機械がなかったとき、プログラミングは問題ではなく、非力なコンピューターが数台あるときは軽い問題であり、巨大なコンピューターが現れるとプログラミングも巨大な問題になった」という趣旨の発言を残している
- 今日のプログラミング実践では、「software crisis」という表現はあまり登場しない
- 新しい言語や組織的手法の発展、過去の問題との時間的距離によって、業界はある程度解決したという安堵感を抱くようになった
- しかしその安堵感は、本当の快適さというよりも、敗北と受容に近い状態として残っている
抽象化がユーザーの主導権を遠ざける
- 初期コンピューティングと隣接分野の発展は、抽象化の塔を積み上げること自体に直接コストがかかる機械や環境の中で起きた
- 制約を迂回できないときには、ハードウェアのアップグレードが後に続く成長サイクルがあった
- 実際には、現在の制約を十分に理解する前に、より大きな容量を求めるようになっていた
- パーソナルコンピューティングの商業化以後、機器を売る企業は、ユーザーが製品を完全に習得するまで待たず、成長サイクルはさらに速くなった
- 速いハードウェアのリリースサイクルとともに、「abstract it away」が基本的な思考様式になった
- 気に入らない詳細を制御可能な構造の中へ押し込めば、ある程度の独立性は得られるが、性能コストが伴う
- 複数レイヤーの抽象化と情報隠蔽は、ソフトウェア構築の問題をより高い層へ移し替える
- それらのレイヤーは、コンピューター利用に必要なソフトウェアと、生活を動かすソフトウェアの中に統合されている
- より広いソフトウェア産業は、リリースサイクルと資本の影響力を加速させ、個人開発者が容易にアクセスできる余地を弱めた
- ソフトウェア危機は開発者だけの問題ではなく、ソフトウェア利用者にも及んでいる
- 利用者は、作者が許可した機能の外ではほとんど制御権を持たない
- ソフトウェアを作ることも使うことも、どちらも人間の活動であるという点が見えにくくなっている
戻るべき場所は過去ではなく浅いレイヤー
- 提案される解決策は、より制約の多いプラットフォームへ戻ることではない
- 許容される抽象化レイヤーの数を制限すべきである
- レイヤー間の情報保持が必要である
- プログラミングモデル、ユーザーインターフェース、基盤ハードウェアは浅く、組み合わせ可能でなければならない
- Handmade、Permacomputing、レトロコンピューティングコミュニティのような動きは、ソフトウェア危機への認識を高める流れにつながっている
1件のコメント
Hacker Newsの意見
こんにちは、筆者です。この記事でよく誤解される点を整理しておくことが重要だと思うので、まとめます。反対しているのは抽象化そのものではなく、無制限に適用することです
より制約の強いプラットフォームへ戻ろうという解決策でもありませんし、ユーザーに「我慢してもっと技術的になれ」と求める主張でもありません。ソフトウェア危機を理解する鍵は、「プラットフォーム熟練度」と「成長／リリースサイクル」の曲線です。過去40年以上、いくつかの分野を除けばこれらの曲線は開いていき、近かった時期には解決できませんでしたが、次善のタイミングは今です
この記事がクリックベイトだという反応もありますが、これは私のログの最初の記事であり、開発者として置かれている状況についての考えを書いたものです。似たような感覚はさまざまなコミュニティ、とりわけ一部のカウンターカルチャー系コミュニティでも、いろいろな形で見られます。問題解決の一部を示したいので、「どうやるのか見せる」という続編も書くつもりです。一人でやっていることなので、時間と余裕をいただければと思います
ソフトウェアを作る人が何百万人もいる以上、この問題を完全に直すことはできません。その一部とは意見が合わざるを得ませんし、全員が筆者と同じくらい熟達できるわけでもありません。だからこの記事は結局、「許容できる抽象化」の基準を今より高くすべきだ、という主張として読めます
大きく語るのは簡単ですが、実際に「抽象化されすぎている」と見なす特定の領域をのぞいてみると、謙虚になる可能性が高いでしょう。そうした「過剰な抽象化」にもたいていはかなりもっともな理由があり、その領域のエンジニアたちも抽象化の状況がごちゃごちゃしているとは感じていますが、必要だったり、直すのが現実的でなかったりすると考えています
たとえば多くのソフトウェアは、広く使われている中間的な抽象化の上に、良い抽象化を重ねて作られています。Kubernetes が Linux、コンテナランタイム、従来型の制御プレーン／設定レイヤー／データプレーン構造の上に載っているようなものです。このロジックをすべて新しいオペレーティングシステムに直接実装することもできますが、ユーザーの互換性問題が生じます。作ることはできてもユーザーがいないかもしれず、そうなると避けようとしていた悪い抽象化を再実装しなければなりません。しかもそのような解決策は実装の難易度がはるかに高い。私は Kubernetes の設計が嫌いなのでこの問題を解きたいのですが、「正しいやり方」でやることが難しすぎる、あるいは高すぎるために、価値がなくなってしまう結果だと見ています
この分野に入ってきた時期や背景によっては、前の世代の抽象化がすでに受け入れられた慣行として組み込まれている可能性がかなりあります。たとえば、かつては汎用ファイルシステムを備えたオペレーティングシステムを使うことが当然の前提になりました
今語られている問題は、現在この分野に入るときに直面する難しさに近いと思います。使われているすべての抽象化を細かく理解しなければ貢献できないと仮定すると、求められる前提知識は相当なものです。圧倒されることはありますが、より深く理解できるようになるまでは抽象化を受け入れるという道もあります
0 - https://en.wikipedia.org/wiki/Clarke's_three_laws
ただし、この状況が変わらない理由は明らかに経済的なものだと思います。悪いソフトウェアのほうが安いという意味ではありません。しかし手を抜けば、個人や組織は今コストを節約でき、より大きなコストは後になって組織自身、顧客、社会全体が背負うことになるため、安くて悪い慣行には強いインセンティブがあります。さらにソフトウェアには他の工学分野の基準を適用しにくいため、特定の標準や品質のソフトウェアを求める契約や規制を作ることも難しいのです
想像できる唯一の解決策は、同じ技術でより安くより良いソフトウェアを作れるようにしつつ、同時により安くより悪いソフトウェアは作れないようにする技術革命でしょう
あまりに多くのプラットフォームにあまりに多くのソフトウェアがあり、地形があまりに断片化しているため、一般論を述べるのは困難です。揺らいで崩れるプロジェクトもあれば、うまく動いているプロジェクトもあります
ユーザーに敵対的なソフトウェアもありますが、それは設計意図です。その背後にはシニシズムと強欲があります。プログラマーが何をしているのか分かっていないからではなく、指示された通りにやっているからです
ユーザー自身もそれを助長しています。良いソフトウェアを作っても関心を示さず、ユーザーは良いソフトウェアではない別のものを求めます。良いソフトウェアを望むユーザー1人は、そうでないユーザー50人の犠牲になります。大衆市場向けソフトウェアは、今や大衆文化です
当時のWordが現在のバージョンと比べて大きく劣っていたわけでもありません。それなのに今のWindowsとOfficeは、動作するだけでも50〜100GBのディスクが必要です。何を得るために1000倍になったのでしょうか
完全に狂った話ですが、私たちはただ受け流しています。現代のシステムはディスク、RAM、CPUが5000〜10000倍ほど増え、家庭用インターネットは初期のモデムより文字通り100万倍速くなっています
この記事は、ソフトウェア危機が実際に存在する、あるいは重大な問題であるという前提に立っています。危機の要素として、予算超過、スケジュール超過、非効率、低品質、要件未達、管理不能なプロジェクト、保守しにくいコード、未納品などを挙げています。
しかしここで「ソフトウェア」という言葉を抜くと、こうした問題のうち一つ以上を経験しない人間の活動がどれほどあるでしょうか。逆に、実際にはかなり優れたソフトウェアも数多くあります。私たちは失敗や欠陥ばかりを見ようとし、成功については、改善が続いていても当然の基準線のように無視します。
コンピュータの電源ボタンを押してデスクトップにたどり着くまでに、すでに何百もの抽象化を通過しています。そのデスクトップだけを見ても、私たちが一日中やり取りする機械の中で最も複雑なものです。こうしたことが世界中で一日に何十億回も起き、たいていは問題なく動いています。これもごく小さな例にすぎません。
ただし、この種の記事の本当の動機はそうした項目ではなく、すべてが手に負えないように感じられることにあるのだと思います。経験豊富なプログラマーなら、その圧倒される感覚と、やるべきこととのバランスを取らなければなりません。ここに至るまで時間はかかりましたが、重要だと信じています。すべてが完全に整理されることはなく、その事実を受け入れなければなりません。
ソフトウェアには、性能とメモリの制約を除けば、そうした限界はほとんどありません。しかもそのどちらも十分に余裕があるため、ゴミを際限なく継ぎ足してやり過ごせてしまいます。私たちは皆、「これ、いったいどうやって動いているんだ？」と思ったり口にしたりした瞬間があります。ユーザーが誤った境界条件を踏むまでは、下にあるコードがどれほど危ういのかは分かりません。
「電源を切って入れ直してみましたか」がその証拠です。ソフトウェアシステムは、あまりに微妙で理解しがたい悪い状態に入り込み、すべてを消して最初から立ち上げ直す以外に解決策がないことがよくあります。通話を受けたあとも次の電話やメッセージが来るまでスマホが振動し続けたり、Webアプリで一部が100%読み込まれずオプションが消えたり、Bluetoothペアリングが不安定だったりするようなものです。
コミュニケーションは理解を伝播させ、その不足を修正する方法であり、理解はどんな仕事であれ成功の基礎です。理解がなければ、先の症状の一つ以上が現れます。理解があっても現れることはありますが、少なくとも成功へ向かう道筋はできます。
私の経験では、ソフトウェア工学業界の問題の大半は人の問題です。技術でも、技術そのものでも、プロセスでもありません。だからこそ、コミュニケーションと理解が成功に不可欠なのです。
工学系企業や自動車会社のリーダー層の経歴を見ると、部品・コンポーネント・製品設計や生産設備の運営で、段階的により大きな責任を担ってきたことが分かります。CEOも依然として技術知識を重視し、非技術系の人材も少なくともそう見せようとはします
一方で、アジャイルソフトウェア開発では、技術力はたいてい最下層で途切れます。スクラムチームにはソフトウェアを作る人たちがいて、それで終わりです。スクラムマスターや多くのビジネスアナリストは、コードをたくさん書いた経験がない可能性が高く、階層上で最初の実質的な上司は秘書・管理業務が大半なので、コードをほとんど見ません
要点は、ソフトウェア開発がチケットの大きさ単位で行われるため、自分が作り保守している抽象化レイヤーの数を哲学的に考えにくい、というだけではありません。ソフトウェア開発者には意思決定の場に席すらありません。スクラムマスターに世話をされ、コードレビューで妥協し、チケットの外を考えるなという圧力を受け、技術力をリーダーシップへ持ち込む昇進経路もたいていありません
そのため、「ソフトウェア危機」を訴えようとする動きは、文章末尾の表現のように、Handmade、Permacomputing、レトロコンピューティングといった趣味の領域にとどまる可能性が高そうです。Hollywood がソフトウェア／IT 関係者を絶えず屈辱的に描く一方で、医師や弁護士には際限なく主役を与え、複雑な専門用語を面白い物語に織り込んでいることにも、ある程度責任があると思います。こちら側では本当に不可能なのでしょうか？ 近いうちに脚本作成 AI が何かやってくれるかもしれません
ソフトウェア開発は、一日中コンピュータと厳密に対話する仕事です。すでに解決済みの平凡なことを新しいアプリケーションで解いたり、技術的背景がなければ把握することすら難しい問題を扱ったりします。20年以上趣味でプログラミングしてきた開発者である私でも、仕事の大半は退屈で気が狂いそうです。非開発者に説明しようとも思いません。会計と同じくらい面白くなく、むしろ別の話からもっと役に立つ情報を得られる人が多いでしょう
私が働いた中で最もアジャイルにどっぷり浸かっていた会社は、ジュニアとシニアを交換可能な歯車のように扱っていました。違いがあるとすれば、シニアはスプリントごとにより多くのポイントを処理しなければならない、ということだけでした。チケットの範囲外を考えるなという積極的な抑制があり、うつむいて黙っていろという雰囲気でした
ただし問題が2つあります。彼らは実装の細部に深く入り込めず、複雑性を生み出すと報われるという歪んだインセンティブにも縛られています。もちろんそれに対抗する人もいますが、そういう人は昇進する可能性が低いです。自分の下の人数を減らしたり、自分の役割をなくしたりしても報われません
開発者が実際の要件のうちチケットサイズ単位のものだけを扱う理由を短く言えば、あまりにも愚かだからです。全体を頭の中に収められず、理解できません。苛立たしく聞こえますか？ その通りです。本当に理解するのが難しいのです。すみません
この記事は抽象化を悪のように描いていますが、ある水準以上の能力を持つ人間が作るソフトウェアを作るには、避けられない道具です
Rich Hickey が「初心者のジャグラーはボールを2、3個扱えるが、世界最高のジャグラーでもおそらく9個ほどが限界だ。人間の能力に桁違いの差はなく、すぐ天井に達する」という趣旨のことを言ったことがあります。その限界を超えるには、抽象化するしかありません
もちろん特定の事例では、悪い抽象化や多すぎる抽象化があり得ますし、筆者が怒っている点もそこだと思います。ですが、その区別は重要です
「もはやソフトウェアを作るのは簡単ではなく、何も説明書付きでは来ない」という部分は明らかに間違っています。ソフトウェア制作はかつてないほど簡単になり、ドキュメントもより整っています
複雑な全体を理解するのに、必ずしも間接化が必要なわけではありません。複雑性を扱うには、絡み合ったものをほどき、各部分を独立して理解できるようにしなければなりません。間接化で複雑性を隠すと、私たちが推論すべき対象と私たちとの間に距離が生まれます
抽象化はユーザーにとっては良いものです。開発者であれそうでなかれ、細部を気にしなくて済むからです。しかし、それを作る仕事を簡単にしてくれるわけではありません
「今やソフトウェアを作るのは簡単ではない」という言葉とは違い、適切な作業に合った適切なツールを知っていれば非常に簡単です。ただ、そうしたツールに関する情報が抑え込まれていて、ほとんど耳に入ってきません
大多数が考える技術ツールのエコシステムと実際の姿は大きく異なります。私たちが知っているツールのほとんどはひどいものです。万能の解決策のように見せようとしますが、実際には何に対してもそれほど優れていません。それでも最も人気のあるツールです。記事が示唆しているように、資本の影響力のためだと思います
たとえば今使っているツールで、ログイン、アクセス制御、スキーマ検証、複雑なフィルタービューを備えた比較的複雑なマーケットプレイスアプリを、ブラウザだけで、ソフトウェアを一切ダウンロードせず、サーバーレスで3時間でゼロから作る動画を撮りました。アプリ全体はHTMLマークアップ700行未満とJavaScript 12行です。再生回数は10回ほどでした
陰謀論的なtwistとは違い、現代のツールはこれまでになく柔軟で使いやすいものです。欠点はありますが、数十年前の開発者が経験しなければならなかったことに比べれば何でもありません。あなたのツールを覆い隠そうとする巨大な陰謀などありません
私はノーコード/ローコードと、どこでも実行できるツールを強く信じています。ただし、私の意味することがあなたの考えているものとは違うかもしれません。いずれにせよ、作ったことは認めます
動画を見始めて最初に浮かんだ疑問はこうです。Codespacesとは何ですか？セキュリティはどうなっていますか？最終的なアプリはどこで実行されますか？自分のハードウェアで動かせますか？クラウドアクセスなしで動かせますか？どのクラウドですか？来週、来月、来年、10年後にも残っているのでしょうか？もちろん、標本一つにあまりこだわらないでください
ノーコード/ローコードの状況はデスクトップパブリッシングに例えられます。DTPにはCI/CDパイプラインがありません。印刷を押せばいいのです。完全に統合された環境です。一方で、文字通りあらゆる「継続的インテグレーション」環境は、必死に叫びすぎて自分自身を食いつぶしているように見えます。どこかには色分解、余白設定、フォント取り込み、PostScriptヘッダーライブラリやLaTeX生成のためのツールがあるのでしょうが、ほとんどの人は見もしなければ使いもしません。どこかにはCMYKよりはるかに多様な顔料で、自然光の下でだけ鮮明な多版印刷をしている人もいるでしょうが、大多数はスマートフォンのひどいスナップ写真しか見ないので、意味を感じません
これは創作者だけの問題ではありません。消費者は何が可能なのかを知らず、可能性の全範囲を明らかにする装置も持っていません。消費者向けデバイスは、多くの閉鎖的エコシステム上の理由と、ありふれた不注意・無知のために、その範囲を積極的に損なっています
数年前、レンタカーでCadillacを受け取ったのですが、現代のCadillacは絶対に買いませんし、できれば運転も避けます。ワイパーを制御できず、コンソール画面は私が道路を見ていないとして、最も目立つ警告を何度も表示しました。おそらく眼鏡をかけていることを把握できなかったのでしょう。見知らぬ道路の高速交通の中だったので実際には画面を見ず、同乗者に「その点滅している画面、一体何て言ってるの？」と聞きました。よくやった、Cadillac
浅く、組み合わせ可能な構造は、UNIX ツールを使うと誰もが経験するものです
GUI はここで破綻します。GUI は互いに組み合わせ可能な形でやり取りしない、文字どおりの島です
GUI とシェルパイプラインのアイデアを混ぜる実験を、guish というツールで行っています
https://github.com/williamcotton/guish
似たツールや、組み合わせ可能な GUI のアプローチを知っている人がいるか気になります
https://hisham.hm/userland/
https://arcan-fe.com/2021/04/12/introducing-pipeworld/
http://conal.net/papers/Eros/
私もこれに関連するアイデアに取り組んでいて、表面的にはあなたのものに似て見えるかもしれません。ただ、emacs でこれがどう動いているのかを見てみることを勧めます。深く見たわけではありませんが、あなたのアプローチはそれほど「組み合わせ可能」には見えません
もし知らなければ、これもインスピレーションになるかもしれません: https://gtoolkit.com/ Smalltalk 環境で、emacs のように文字どおりすべてがプログラム可能ですが、ほぼ逆方向です。GUI はコマンドの結果ではなく、言語そのものです
しかし、より大きな問題は GUI ではありません。GUI も問題ではありますが、抽象化スタックの最上部にあるしかないため、問題がさらに連鎖して組み合わさることはありません。興味深いことに、大きすぎる問題なので、かえってもはや問題ではなくなります
今日の巨大な象は分散システムです
ただ、GUI は昔から弱点でした。UI が良いかどうかには「グローバルな」考慮が多く、モジュール的な性質ではないからだと思います
個人的には、UI はもっとありつつ、自動化は維持してほしいです。シェルで入力したものをファイルに保存して後で再実行し、修正して再実行し、コマンドをコピーして友人にメールで送れる、あの性質のことです
背景を補足すると、私は何年も前からシェルをゼロから作っていて、GUI 向けの headless mode があります。ほかの人が作った実際のデモもありますが、今は誰も作業していない状態です
スクリーンショット:
https://www.oilshell.org/blog/2023/12/screencasts.html#headl...
https://www.oilshell.org/blog/tags.html?tag=headless#headles...
さらに多くのリンクはここにあります - https://github.com/oilshell/oil/wiki/Interactive-Shell - Xiki のような興味深い休止中のプロジェクトもあります
ターミナルから分離された互換シェルや、そのような新しいシェルが必要なら、メールか https://oilshell.zulipchat.com で知らせてください
基本的には、headless プロトコルをテストして改善点を教えてくれる人が必要です。ターミナルを「持って」いるが、ターミナル「そのものではない」シェル GUI を作るべきだと考えています。あなたが作っているものとも関係がありそうです
今は主に新しい YSH 言語に取り組んでいますが、GUI の作業も復活させたいです。私は UI プログラマーとしての経験があまり多くないので、別の視点があるとありがたいです
そして ggplot が好きなので、それを含めている点がうれしいです。実際、ggplot こそシェルにグラフィックスがあればよかったのにと思うところです
最後の「もっと良くできる。その方法を見せよう」という文は、単なる クリックベイト用の導入部のように見えます
「これらのモデルが現実を反映することは非常にまれだ。反映していれば幸運な偶然で、そうでなければ災厄だ」という言葉は、私の経験とは異なります
たいていの場合、市場に出ているソフトウェアの大半は致命的ではありません。肥大化した出来の悪いWebアプリの多くは、一日中無駄に大量のリソースを吸い上げ、あちこちで不規則なバグを露呈しながらも、ユーザーが期待したことをひどい出来で実行することはあります。そこまではその通りです
しかし、ペースメーカーや宇宙ロケットを扱うソフトウェアほど致命的ではありません。ほとんどのソフトウェアは、めちゃくちゃでも構わないのです。大半のプロジェクトは人間の気まぐれに関わるもので、品質不足の最悪の結果も少しの苛立ちであって、惨事や死につながるわけではないからです
それに、ほとんどのソフトウェア開発者がシリコンバレー式の金銭的インセンティブの中で働いているわけでも、自分が情熱を持って作りたいプロジェクトで生計を立てているわけでもないでしょう。市場に出回るソフトウェアの大半は、外生的なひどい報酬構造を通じて作られます。そうした過程の産物が、ゴミ以外の何になると期待しているのでしょうか
私は抜けた階段が本当に嫌いです
私たちは自分たちが作ったソフトウェアの実際の利用から非常に遠く離れていて、開発プロセスに情報を与える短い形式の実行可能なシグナルしか経験していません。新規ユーザーと体を入れ替えられない限り、この「千の切り傷による死」の実際の苦痛をきちんと感じるのは難しいのです
私はプログラミングを一つの職能と見ており、私たちにはソフトウェア品質を制御する力があると考えています。ただ、金銭的であれそうでなかれ、私たちに目を背けさせるインセンティブがあるのです
ソフトウェア危機は存在しないと思います。世界中の何百万人ものプログラマーが、ある程度有用なプログラムを作っており、トースターまで含めて、ほぼすべてのものが十分にうまくソフトウェアを動かしています。コミュニティは、5歳の子どもから祖父母まで誰もがアクセスできるプログラムも作りました。ここにどんな危機があるのでしょうか
しかし、プロジェクト管理の危機はあります。これはソフトウェアに限ったことではなく、計画する人と届ける人が離れてしまった問題です。そして私たちは、その隔たりを埋められていないようです。AgileやScrumなどは、「グル」たちが私たち全員を愚か者扱いするこの隔たりの指標であり、私たちもより良いものを生み出せていません
ソフトウェア開発の商品化も、この混乱に寄与しています。参入しやすい分野という特性上、あらゆるレベルの人がさまざまな成功率で参加できます。良し悪しの問題ではなく、現象の本質です。食品業界にMichelin星付きレストランとMacDonaldsの両方があり、どちらにも消費者がいるのと大きく変わりません。だからといってレストラン危機とは言いません
そのせいでトースターの寿命は短くなります。昔は10年使えるトースターがあったかもしれません。今では、悪いソフトウェアと、おそらく強制されたWiFiやBluetooth接続のせいで、供給元がアップデートをやめれば2年後にはゴミになります。そもそもアップデートがなかった可能性もあります。直接見えなかったり、今の過剰消費と終わりのない新製品購入のせいで、危機が常に目に見えるわけではないだけです
トースターが2年後に止まっても、私たちはそれでいいと思い、なぜそうなるのか気にしない、あるいは知らないかもしれません。しかし、Miraiボットネットの一部だったかもしれません https://www.cloudflare.com/learning/ddos/glossary/mirai-botn...
トースターはもっと単純なチップを使っているので、おそらく違ったでしょうが、誰に分かるでしょうか
ちなみに私のDualitのトースターはソフトウェアを実行していません
「私たちは入れ子になった抽象化レイヤーを積み上げ、複数のレベルで情報を隠す方法を発展させた。ソフトウェア構築の問題を、そびえ立つ階層群へと変えてしまった」というくだりは、漏れのある抽象化とバベルの塔を思い起こさせます
https://www.joelonsoftware.com/2002/11/11/the-law-of-leaky-a...
https://en.wikipedia.org/wiki/Tower_of_Babel
https://en.wikipedia.org/wiki/Hierarchy
https://en.wikipedia.org/wiki/Abstraction
https://en.wikipedia.org/wiki/Abstraction_(computer_science)
互いに比較してみる価値があります