  |
はてなキーワード: 流儀とは
ファーウェイが初の独自OSパソコン キーボード部分も全面有機EL
https://www.nikkei.com/article/DGXZQOGM198JT0Z10C25A5000000/
もし現代に0からOSを作成する場合、これらのOSの技術的負債や欠点を教訓として設計するならどのようなものが考えられますか？
| 観点 | Linux で顕著 | Windows で顕著 | 共通課題 |
|---|---|---|---|
| カーネル構造 | 巨大モノリシック ＋ 常に ABI が流動的（外部モジュール苦労） | 歴史的にモノリシックに近く高密度・複雑 | 信頼境界が広く、脆弱性が権限昇格に直結 |
| 安全性 | Unix-型「ユーザー/グループ + SUID」が限界 | ACL/SID が複雑化・分散 | “一発 root/SYSTEM” を許すモデル |
| ドライバ | OSS/ベンダ混在・署名不足・上流統合が負担 | 内部 API 長期固定の重荷、古い HW サポートが尾を引く | カーネル空間に巨大コード |
| 更新 | ディストロごとに仕組み相違、再起動依存 | 累積パッチ巨大・Reboot 必須 | 取替え可能性 ≈ 可用性低下 |
| ユーザー空間 | バイナリ互換よりソース互換優先で「壊れやすい」 | DLL Hell / COM 登録 Hell | グローバル名前空間汚染 |
| 設定管理 | /etc + 点在 config → 形式・権限バラバラ | Registry 巨大モノリス → 腐敗 | アトミックではない変更が多発 |
| 開発プロセス | メーリングリスト文化でレビューボトルネック | 閉鎖的で古いコード維持不可避 | 純粋なモジュール性が欠如 |
マイクロカーネル（あるいは hybrid microkernel）＋ ユーザー空間ドライバ。
カーネル定義の “secure capability” ハンドルのみを他プロセスへ授与。
seL4 や Fuchsia の Zircon が示す「検証可能サイズ」を目標に。
| 観点 | デメリット | 旧 OS が採用しなかった背景 |
|---|---|---|
| 性能 | コンテキストスイッチと IPC が頻発し、90 年代 CPU では大きなオーバーヘッド。 | ハードウェア性能が不足し、リアルタイム性やスループットを優先した結果、モノリシック構造に。 |
| 実装コスト | OS サービスが分散し、デバッグやトレーシングが煩雑。 | 完全分離を行うツールチェーン／デバッガが未成熟だった。 |
| ドライバ移植 | ユーザー空間化で ABI は安定するが、低レイテンシ要求デバイス（GPU など）の処理が難しい。 | 当時は “音声が途切れる” 程度でも市場競争力を失うためカーネル内に残す決断。 |
Rust や Zig のような safe systems 言語。
C 部分は必要最低限に隔離し、unsafe 領域は形式検証 / fuzz 前提。
| デメリット | 背景 |
|---|---|
| ランタイム負荷 言語ランタイムを最小に削る必要があり、一部 unsafe が不可避。 | 70〜90 年代は C 以外に bare-metal 向け安全言語が事実上存在せず。 |
| コンパイラ信頼性 コンパイラ自身の欠陥がカーネル欠陥に直結。 | “自己ホスト” 安全言語を実機に載せる環境が不足。 |
| 学習コスト OSS/商用エコシステムが C 前提で巨大。 | ドライバサンプル・書籍・人材が C/C++ に集中していた。 |
外部インタフェース（syscall, driver ABI）は長期安定。
その裏で内部サービスは gRPC/FlatBuffers 相当の IDL で世代管理し交換可能。
| デメリット | 背景 |
|---|---|
| 進化速度の拘束 ユーザ空間から見える syscall を変えにくい。 | MS-DOS 互換・Unix 互換という既存ソフト資産が最重視された。 |
| バイナリサイズ肥大 旧世代 ABI を残すため “脂肪” がたまる。 | ストレージ単価が高く「後方互換より容量削減」が優先された時期が長い。 |
アプリは原則 container-like sandbox（Wasmtime, OCI など）で実行。
ファイルシステムは per-app の仮想 Namespaces、権限委譲は capability passing。
| デメリット | 背景 |
|---|---|
| 複雑な権限委譲 ファイルダイアログすら Capability 伝搬を要し、開発者負担。 | “単一 PC＝単一ユーザー” が前提で、砂箱の必要性が薄かった。 |
| 互換レイヤ 既存ネイティブアプリを仮想化するとパフォーマンス低下。 | RoM の小規模ゲームですら速度が死活問題だった 80～90 年代。 |
A/B partition や OSTree 型 “全イメージ” 交換。
任意時点へ atomic rollback；カーネル更新も Live-patchable。
| デメリット | 背景 |
|---|---|
| ストレージ消費 OS イメージを常時二重に保持。組み込みでは致命的。 | HDD が高価・遅い、SSD がない時代には非現実的。 |
| アップデート粒度 小パッチ配布より帯域を食う。 | ダイヤルアップ回線や CD リリースが主流で “差分パッチ” が合理的だった。 |
systemd-や Kubernetes-風の “状態 = 宣言” を1か所に。
| デメリット | 背景 |
|---|---|
| 学習曲線 既存の `vim /etc/xxx.conf` 流儀や regedit から大きく変わる。 | 管理者層が “設定＝テキスト or レジストリ” に慣れ切っていた。 |
| 複雑なマイグレーション 全サービスが同時に対応しないと一貫性が壊れる。 | OSS は分散開発で統一仕様を打ち立てる強権がなかった。 |
ベンダーは署名した “driver capsule” をリリースするだけ。
| デメリット | 背景 |
|---|---|
| パフォーマンス JIT / interpreter を挟むぶんネイティブより遅い。 | 当時 JIT 技術が未成熟で、リアルタイム I/O を捌けなかった。 |
| ハード依存 API DMA や割込みの抽象化が難しく、結局 “逃げ” でネイティブ部が残る。 | 旧 OS ではベンダがアセンブリ最適化で差別化していた。 |
ユーザー空間 API は async/await; カーネルはメッセージ転送中心。
NUMA・GPU・FPGA などヘテロ資源を first-class に。
| デメリット | 背景 |
|---|---|
| コード複雑化 async/await で “状態機械” を書けないとデッドロックを誘発。 | 90 年代はシングルコア前提で同期 API が単純・高速だった。 |
| デバッグ困難 スタックトレースが非同期に飛び、ツールチェーンが未整備。 | OS デバッガ/プロファイラがプリエンプティブスレッド中心に設計されていた。 |
Capability + Labels (MAC) + Hardware root-of-trust (TPM, DICE) を統合。
| デメリット | 背景 |
|---|---|
| ポリシー設計負担 SELinux でも “設定が難し過ぎて結局無効化” が多発。 | 当時はネット接続率が低く、ローカル攻撃ベクトルのリスク認識が薄かった。 |
| 互換問題 古いアプリが過剰特権を要求し、制御を有効にすると動かない。 | 商用ソフト対応を優先し無効化せざるを得なかった。 |
すべての公式バイナリは reproducible build エビデンスと SBOM 付与。
脆弱性スキャンと revocation を OS レイヤが自動化。
| デメリット | 背景 |
|---|---|
| ビルドパイプライン整備コスト 全パッケージを byte-identical に再現するにはツール統制が必要。 | オープンソース文化自体が黎明期で、ビルド環境を標準化する動機も手段も希薄。 |
| 秘密ロジック公開の葛藤 一部ベンダはソースハッシュ公開を嫌がる。 | IP 保護が優先され、署名のみ・SBOM なしがデファクトだった。 |
User Apps (Wasm / OCI Sandboxes) ------------------------------------- │ Capabilities ▼ Services ──▶ Driver Svcs(user-space) (Pkg, GUI, FS) ------------------------------------- │ syscalls = message send / recv (stable ABI) ▼ Microkernel ~100 kLoC, memory-safe (sched, vm) ------------------------------------- │ Secure IPC (SMC / VTL) ▼ Hypervisor(optional, for legacy guests / composable sandboxes)
Legacy Compatibility は Type-2 ハイパーバイザで提供し、歴史的 API を隔離。
UI Stack もユーザー空間サービスとしてホットリロード可。
Policy Engine で JSON/YAML 宣言→バイトコードへ compile、ランタイム適用。
| 教訓 | 新 OS プロジェクトでの対策 |
|---|---|
| Linux: 大規模パッチはレビューパンクする | GitHub PR + 公式 LTS gatekeeper、CLA & コーディング規約を機械検証 |
| Windows: Close-source で内部知識が属人化 | 100% open-design、Spec⇄Impl 双方向ドキュメント、自動生成 |
| 両者: “一社主導 vs 実質無政府” の二極端 | 財団モデル (Rust, Cloud Native) で技術運営と商用版の両輪 |
これらを先天的に組み込むことで、Linux/Windows が数十年かけて抱えた技術的負債（巨大特権領域・ABI拘束・設定の散逸・更新の非原子性 etc.）を回避しながら、クラウド・エッジ・IoT・AI アクセラレータ が混在する 2020-30年代以降の計算環境に即した OS が実現できます。
国家プロジェクトれべるだわ
流石にちょっと進展に怖くなった。今まで数学的な演習問題を解かせてきてバカ丸出し（タダで試せる汎用AIの範囲）だったが、gemini 2.0 Flash Think(experimental)とかいうの試して心胆寒くなった。gemini1.5であんだけ低能晒していたのに...。gemini1.5の時はソーカル事件で槍玉にあげられたポモの人たちの劣化バージョンのような解答よこしてた（論理性0で、キーワードいじって答えになるっぽい式並べただけ）のに、2.0 Flash Think(experimental)になるとちゃんと自分の提案を検証する（gemini1.5ではしない、copilot、ChatGPTも。grokは検証するのだが無限ループに入って無料限界越え）のみならずこちらからは「思考による努力」と思わせる言葉を吐きながら数分の長きにわたって（人間とは違うので数秒で新しい案出して検討する）「努力」した。残念ながらこちらの助け舟を最後まで理解できないで正答には至らずギブアップ（嘘答え潰していくとちゃんとギブアップするのね）して終わったが、応答の文面からは「理解しようとする」「努力」っぽいものは明らかに見えた。（こちらの出したヒントを一般論から推測して正しいだろうと見做し、そこから頑張ろうと表明してた。前バージョンだと連続関数は時には不連続になる（定義域同じで、同じ関数ですよ？）みたいな意味不明な強がりで「正解」出してた）
これまでの、ネットその他に答転がってなければもうダメです、ではなさそう。grokとこれ以外は明白な感じで勉強できたことを論理性関係なく結んで答え提示してただけなんだが近い将来はどうなるか？
PS1 出したのは絵解きでいいなら幼稚園児でもできる問題（3次元中の2次元曲面なら）を4次元中の3次元に単純拡張した。ただし今のAIはお絵かきは得意なようなんで数式の答えを要求した。
PS2 gemini2.0（以下ry）においても勉強できることはなんでもまずは暗記的勉強してることが垣間見えることもあった。（もちろん人間だってある本で意味わからなかったら別の本にあたってとりあえず読むので必須の行為ではある）gemini2.0君ったら突如こっちが指定したD(t,s)、U(t)みたいな記法じゃなくてγ(t)とか書きやがる。確かに教科書でπ_1(X,x_0)の代表元をγ(t)って書く流儀見るよね、と微笑ましかった。ほんのちょっと前までは本質を理解していない、キーワードを意味ありげにつなぐガリ勉君しかいなかったが、近い将来どこまで伸びるか？（本音はチンケなプライドのためにも伸びて欲しくない）
運を操ってるのは胴元のヨースターだよね？
その運をこちらに向けない、つまりフェアな勝負を提供していない
これに対する抗議として牛歩をする
同卓したやつらは俺にキレるんじゃなくフェアな勝負を提供してないヨースターに怒りのこぶしを挙げろよ
俺は当然の権利として牛歩をする。麻雀は相手の嫌がることをやるのが正解。イラついて途中で退席したらしめたもの
振り込んだから牛歩、とすると、その相手に対する攻撃になってしまう。そういうことをやりたいわけではないので、開幕即牛歩
逆に溜めロンはしない。ロンの時はすんなり上がる。また、俺が溜めロンされたとしても、それは織り込んでいる。相手は俺を懲らしめようと思ってそうするんだろうが、そもそも最初からそういう次元でやってない。
これが俺の流儀
上から順番に
フレームワークはRails、インフラはAWS ECS、チケットには納期を定めず、コミュニケーションは非同期…… 不動産SaaSのマルチプロダクト展開のため全てに筋を通すスタートアップ「Facilo」の流儀 ←タイアップ広告
エンジニアにとって唯一無二の挑戦環境がある──プラットフォーマーとして新たな成長フェーズに進むRAKSULグループの技術組織 ←タイアップ広告
休みは多く、成果も多く。リクルートのエンジニアに学ぶ「働き方とパフォーマンスを結びつけるエッセンス」 ←タイアップ広告
ミドルエンジニアの「基礎体力」を養いたい。リクルートグループのニジボックスが研修プログラムに込めた熱き思い ←タイアップ広告
ここが面白いよ、リクルートのデータ組織。ユーザーの“背中を押す”ようなレコメンドの設計手法に、ばんくしさんが迫る！ ←タイアップ広告
【必読】エンジニアの「具体と抽象」を往復する学びのヒント！ 定番フロントエンド技術から資格・数学・英語・ビジネスまで、新たな学びはUdemyの講座から！ ←タイアップ広告
2024年「はてなブックマーク年間ランキング」トップ100 ←独自記事
奢られチャンスが発生したときにあなたはなんと言うだろうか？これを読んでいるおまえには覚えて帰ってほしい。「悪いので少しでも出します」、これだけは言ってはいけない。言わないお前はここで帰っていい。
なぜなのか？何もわかってないお前には教えてやるが、奢ると宣言した人間はそれだけの金を払う覚悟かできて「奢るよ」と言っているのである。つまり、お前が遠慮すると振り上げた拳を下ろす場所がなくなってしまう。剥き出した牙をどう収めればいいのか、人類はその答えを未だ知らない。
もし遠慮したいのであれば、「えっ、本当にいいんですか？」と聞け。当然「気にしなくていいよ」と返ってくるが、それでいい。お前が考えるべきなのは、いかに気持ちよく金を払ってもらうかであって支出を減らすことではない。
奢られチャンスというと与えられている気分になると思うが、奢る側にも得るものがあるということを忘れずに感謝の気持ちを持って素直に奢られて欲しい。
今この文章は、ジャンクで買ったThinkPad X250で書いている。5000円だ。キーボードはガタガタで、一部のキーは反応しない。でも、それで困るか？いや、困らん。なぜなら、ThinkPadは修理できるからだ。
お前たちがありがたがってるiPhoneはどうだ？バッテリーがヘタったら修理費1万超え、ストレージが足りなくなったら買い替え。画面が割れたら修理に2万、下手すりゃ5万。そもそも、裏蓋すら開けられない時点で、お前たちのiPhoneはただの「使い捨てガジェット」だ。
それでも、お前たちは毎年のように最新のiPhoneを買う。「みんなが持ってるから」「なんとなく新しいのがほしいから」「買い替え時だから」。それ、お前たちの意思か？考えた末の選択か？
iPhoneを買うことは、みんなが飼っているから、という理由で芝犬を飼うようなものだ。 みんなが持ってるから安心、みんなが使ってるから問題ない、だから自分も。そこにあるのは思考停止だけだ。スマホは道具のはずなのに、お前たちはそれを選ぶことすら、周りに流されている。
ThinkPadは違う。キーボードが壊れたら？交換できる。バッテリーが死んだら？換装できる。SSDやRAMが足りなきゃ？増設できる。iPhoneのように「寿命が来たら買い替え」なんて思考は存在しない。自分で直し、強化し、最適な環境を作る。これこそが、ThinkPadを使う者の流儀だ。
しかも、コストの話をしようか？お前たちが持ってるiPhone、15万、20万。それでやることは？Twitter、YouTube、インスタ、メルカリ。それなら最新iPhoneを買う金で、40台のThinkPadが買えるぞ？ 40台あったら、スペアを20台持っても、さらに20台は砦を築けるぞ？
ThinkPadは、ただのノートPCじゃない。直せる道具、拡張できるツール、そして作業をするためのマシンだ。
iPhoneは違う。お前たちは、ただ画面をスワイプし、情報を消費し、広告を見せられ、気づけば時間を溶かしているだけ。
お前たちはどっちを選ぶ？
『新サクラ大戦』および『新サクラ大戦 the Animation』のオープニングテーマ
斎藤P：
「これは、1996年にセガのゲームから2000年にアニメになったということで、有名な広井王子さんの作品で、主人公が横山智佐さんが演じていらっしゃる。」
田中公平：
「これね、ゲームを具体化することになりましてね、広井王子さんから『こんなゲームを作りたい』という企画書が来たんですよ。
じゃあ、ちょっと主題歌を作ろうっていう話になったんですけど、今度はセガが、具体化をなかなかしてくれなくなってきたんですよ。」
斎藤P：
「なるほど。」
田中公平：
「なんか『え、大正時代って何？』みたいな、『女の子がロボットで戦う、これで売れるの？』みたいな話で。」
斎藤P：
「あー、なるほどね。」
田中公平：
「ということで、じゃあ広井さんと先に主題歌とエンディングを作っちまおうってことで、それで主題歌とエンディングを作ったんですよ。」
斎藤P：
「ゲームより先に、曲が先にできたということですね。」
田中公平：
「そうそう。サクラ大戦はそれからずっと、そういう流儀になっていくんですけどもね。」
斎藤P：
「なるほど。」
田中公平：
「それで出来た2曲「花咲く乙女」という曲と「ゲキテイ」ですけど、
それをセガの幹部に聴かせたら、全員それで『あーなるほど！』って納得して、きっちり接着剤になった」
斎藤P：
田中公平：
「そう。だから、『百聞は一見にしかず』じゃなくて、『一見は百聞にしかず』と私はいつも言ってるんですけど、そういう力が『ゲキテイ』にあったようですね。」
【参考リンク】
