  |
はてなキーワード:ユーザーランドとは
さて、まずは事の経緯から。
娘が中学生になり、第一子の息子が中学生になった時と同様、パソコンを買い与えることになりました。ここまでは良いです。私も了承しています。
何故なら夫はプログラマー、情報技術者であり、私はそこまで詳しくはありませんが、相応の資格や会社での立場を持っているようです。生活に困らない程度には稼いで下さっているので、その点は本当に感謝しています。
しかし今回の娘のパソコン導入を巡って、私たち夫婦は喧嘩になりました。夫は「娘に買い与えるパソコンのOSはFreeBSDにする」と言うのです。
実は息子のパソコンのOSもFreeBSDで、我が家にあるパソコンはすべて中身がFreeBSDです。その理由が夫の言葉を借りるなら「俺はFreeBSDが好きなんだ」。意味がわかりませ……いや、意味はわかります。言葉の意味はわかります。なぜそうするのかがわからないということです。
一方、娘が欲しいと言ったのはMacBook Air。デザインも可愛くてお洒落、デザイナーさんも使っているし、はてなーにも愛されています。ところが夫は言います。「いや一般目線でWindowsへ行きたいって言うならまだしもMacって意味わからなくないか？」と疑問の表情を隠さないんです。
そこで私は、ついに反撃に出ました。
「ねぇ、macOSってNeXTSTEP由来で、Darwinの中にはFreeBSDのコードも結構入ってるんでしょ？」
すると夫、ピタッと黙りました。
そうです。macOSのカーネルXNUはMachが中核で、そこにBSD層とIOKitを載せたハイブリッドで、そのBSD層には、FreeBSD由来のネットワークスタックやVFS、POSIXシステムコール実装が使われています。ユーザーランドに至っては、libcや各種UNIXツールなど、かなりの部分がFreeBSD由来だったような気がします。
「macOSはFreeBSD“ベース”ではないのは分かってるよ？Machが土台で、完全なBSDカーネルじゃない。でもさ、DarwinってFreeBSD 5.x頃のコードを大量に取り込んでるよね？重要な部分でしっかり使われてるよね？」
「それに、あなたがいつも言ってるじゃない。『Unix系なら出来ることに大差はない』って。macOSも立派なUnix認証OSだし、POSIX準拠だし、BSDユーザーランドだし、『FreeBSDの思想が入っていない』とは言えないよね？」
もう一息です。
夫は必死に反論します。「いや、カーネルの中核はMachだから」「同期は取れてないし」「割合で言えばBSD部分は全部じゃない」。
私は頷きます。「うん、知ってる。全部じゃない。でも重要な部分で使われているけど、全体の基盤ではないって話でしょ？」
新築や家電では私の意見を聞いてくれるのに、何故かパソコンだけは譲らないんです。
でも今回は違います。あなたの大好きなFreeBSD、もうMacの中に一部は住んでます。
頼みの息子も「言うほど不便じゃない。まぁ動かないSteamのゲームがたまにあるけどSwitchゲー動かないみたいなもんだし慣れたわ別ゲーやりゃ良いし」とそっけない感じ。そもそもこの子は小学生の頃からSwitchで遊んでて、この子にとってゲーム機もFreeBSDなんです！味方として頼りにならない！
別にMacBook Airで良いと思いませんか？FreeBSDそのままなんて使ってる人見たこと無いじゃないですか！そんなにFreeBSDそのものであることが大事ですか！？Machの上でBSD層が動き、FreeBSD由来のユーザーランドを使うUnixならよくないですか？？？どうやったら夫を倒せますか教えて下さい！！！！！
何かあったらすぐにWindowsくんが悪い！っていうのやめない？
2025年6月のWindows UpdateでPCが起動しなくなるメーカー一覧。原因はBIOS破損でほぼ確定。復旧方法は ［Update 3］ |ニッチなPCゲーマーの環境構築Z
この問題の原因は、セキュリティ更新でのSecure BootDBXへの更新内容が大きくて、それを食ったマザボちゃんがハングアップしちゃったって事象なの。
だからWindowsくんは不用意ではあったけど、仕様に沿った対応をしてただけで、そんなに大きなミスはしてないんだよ！
悪く言わないであげてほしいな。
これだけだとオタクくん分からないかもしれないから、ちょっと詳しく説明するね！
Secure Boot には、「Secure BootDBX」っていう仕組みがあって、これは既知の脆弱性を突かれた古いブートローダーやバイナリの署名を「ブロックリスト」に追加して、起動を防ぐものなんだ。
これはセキュリティの観点から定期的に更新されてるんだけど、今回のWindows Update では、そのDBX が 24KB くらいある大きなファイルになってたの。
Secure Boot の仕様上、DBX のサイズに明確な上限は定められてないから、Windows くんはその前提で普通に更新処理を組んでたんだけど……
でも実は、マザーボード側（特に一部のOEM製品）では、UEFI の NVRAM領域に制限があって、DBX を 8KB くらいまでしか受け取れない設計になってることがあるの。
さらに問題なのは、そういう「想定より大きなDBXファイル」が来たときの処理が甘くて、エラーとして処理できずにUEFI がハングアップしちゃうケースが出てきたってこと。
私もこの辺の QA はやったことあるけど、そんな異常系のテストなんて、正直した記憶ないな……💦だから、起きちゃったんじゃないかなーって何となく想像できるんだよね。
それに、Secure Boot のキーやリスト（PK,KEK,DB,DBX）は、UEFI の NVRAM に格納されてて、これはOS 上からも管理できるようになってるんだ。
だからDBX の更新って、BIOS を書き換えるような危ない処理じゃなくて、ユーザーランドから比較的安全にできるものなのね。
そんな操作でUEFI がBrick しちゃうなんて、さすがにWindows くんも想定外だったんじゃないかな……責められないなあって思うよ。
今回不具合が集中してるのが、Fujitsu とかGIGABYTE、マウスコンピューターみたいな一部のメーカーに偏ってるのも、たぶんそのUEFI実装側の制限が関係してるんだと思う。
無い。C言語（＋＋含む）の開発能力で開発競争をしていては、開発が間に合わない。
その言語を介して、おそらくLLVMを通してネイティブへのダイレクトなコンパイルになると思われるからOSの壁はわりと超えやすい。
その関係上、OSに要求される機能はRTOS程度の機能になるだろうが、RTOSその物は余程の性能でない限りLinuxでもユーザーランドとドライバで解決可能。
それに、よく要求されれる機能はLinuxにパッチ当てても可能。
結果論として、OSその物の高機能化勝負にはならない。勝負になるのはOSのエミュレーターというか開発環境。
より開発しやすい環境を整えたほうが勝つ。正確には、自動車が要求する水準までのサービスの開発とテストを高速化して支える技術。カバレッジとかね。
OSその物は限られた天才が作るだろうが、その天才の質は日米共に大差は付かない。もしくは買ってきても構わない。
問題は、その下に必要な大量の普通のプログラマーと、そのプログラマーが作ったものを天才が書いたものと遜色ない品質まで持ち上げるシステム。
要するに、日本刀ではなく、火炎放射器やマシンガンのように普通の兵隊をどこまで強化できるか？という競争になる。
ただしまぁそれは、今の自動車メーカーが考えているようなものではないから、そこの開発装置の競争でGoogleにボロ負けするだろ。
