C/C++でゼロから構築！ARM,x86,RISC-V対応の自作OS SkiftOSが衝撃の完成度！

コードは本当によく書かれてて、すごく分かりやすくてモダンだね、お見事！ところで、さっきコンパイルしたアプリがなんでmacOSで動くの？

フレームワークにはOS抽象化レイヤーがあって、SDLを使ってウィンドウとユーザー入力を処理してるんだ。

普段の仕事があるデベロッパーが、どうやったらこんなプロジェクトを作れる時間なんて作れるの？9時から5時まで仕事してたら無理だと思うんだけど。

無理だよ！ほとんどは、俺の人生でほとんど社会生活がなかった時期に書いたんだよ ’^^

とにかく、おめでとう！これは本当にすごいことだよ！ :)

俺も同じこと思ってたよ。

セキュリティに関してどんなアイデアを持ってるの？アプリはメモリやハードウェアにフルアクセスできるの？パーミッションシステムはあるのかな？マイクロカーネルがどう機能するか、あまり詳しくなくてごめんね。

アプリはメモリやハードウェアに好き勝手アクセスできないんだ。カーネルが許可したものだけ見えるようにしてる。ドライバはユーザー空間にあって、アプリは「ケーパビリティ」っていうハンドル経由でやり取りするんだ。許可がないと何もできない、しっかりアクセス制御されてるってことだね。

ファイルシステムのアクセス権はどうなってるの？どのアプリでもユーザーの全ファイルにフルアクセスできるの？それとも、そのアプリ専用のファイルだけ？

アプリケーションはそれぞれ独自のネームスペースを持つよ。ユーザーファイルへのアクセスは、ディレクトリやファイルごとに権限が与えられた場合だけ。つまり、細かくアクセスを制御できるってことだね。

このアプローチ、すごくいいね！OSの公式サイトのトップページで紹介すべきだよ。

面白いね。ありがとう。

これ、マジでクール！作った人、おめでとう！どこかにビデオデモとかある？まさかブラウザエンジンまで自作したなんて、本当に驚いたよ！

ビデオデモ、あったら最高だろうな。

ウェブサイトに写真と並んで、カルーセル形式で埋め込むのがいいんじゃないかな。

これ、初めての作品じゃないよね…コードを徹底的に見てみたよ。lib-sdl、impl-efi、co_return、co_await、try、構成可能なクラスを見つけた。自分のコードがこの優雅さに比べるとぐちゃぐちゃに見えるよ。モジュールも完璧！

このプロジェクトのオーナー、素晴らしいね！よくやったよ。これぞモダンC++（モジュール採用）で、さらに改良されてる。GCとかQoL改善も入ってるし、co_try、.unwrap()、asyncなんかを見るとRustの影響も感じるな。今後の計画はどう考えてる？

めちゃくちゃすごいね！GPUはサポートしてるの？それともUIは全部CPUレンダリング？すごく綺麗だよ。

CPUレンダリングだよ。GPU対応は今後の計画に入ってるよ。

ありがとう！もっと多くのGPOSが必要だよね。現状の主要3つに縛られすぎてたよ。もっと良いものを作る余地はたくさんあると思うよ。[misaligned incentives?]

ちょっと話は逸れるけど、よく知らないから教えて欲しいんだけど、OS開発でマイクロカーネルアプローチを選ぶメリットとデメリットって、直感的にどういう感じなの？

最近の商業OSはほぼハイブリッドアーキテクチャなんだ。サブシステムは、パフォーマンス的に問題なくて時間があればカーネルからユーザー空間へ移されることが多いよ。戻ることは稀だけどね。マイクロカーネルっていう言葉は学術的なもので、OSデザイナーは昔から安定性や開発速度のためにコードをユーザー空間で動かすのが良いって知ってるんだ。結局、この概念をどこまで突き詰めるかの問題だね。MicrosoftもAppleもAndroidも、GUIやファイルシステムの一部をユーザー空間に移してきた歴史があるよ。

なんでTTY-PTY機能がLinuxカーネルからユーザー空間に移されないのか教えてくれない？Plan 9は昔からやってたのに。テキストだけの操作を楽しんでるユーザーが、なんで未だに古い『ラインディシプリン』やANSI制御シーケンスとか、TERMINFOデータベースに頼ってるのかも理解できないんだ。昔のパフォーマンスのために導入された無駄が、現代の技術で簡単に作り直せるのに残ってるのはおかしいでしょ？なんで1960年代、70年代の専用端末をエミュレートし続けてるの？ネットワークも速いし、RAMも安いから、カーソルアドレッシングなんて不要で、毎回画面全体を再送すればいいはずだよ。通信プロトコルも、今となっては理由もないのにステートフルなのはおかしいと思うんだ。

プログラマーの時間は貴重だし、レガシーコードに手を出したがる人は少ないから、多くのものがカーネルに残ってるんだ。カーネルからコードを出すのは、新しい問題を解決できる明確な仕様がないと、逆に遅くなったり、メリットがなかったりするよ。例えば、コアなファイルシステムをユーザー空間に移してクラッシュしたら、全部のプロセスが巻き添えになるでしょ？結局パニックして再起動するのと変わらないなら、カーネル内に置いとく方がいいんだ。GNU Hurdみたいにセキュリティの問題も生む可能性があるしね。だから最初はモノリシックにして、準備ができたら切り出すのが良いんだよ。Linuxはカーネルとユーザー空間が独立してるから、機能移動も難しいしね。ターミナルを改善したいなら、コードの移動じゃなくて新しいプロトコルを作るべきだよ。

『ファイルシステムプロセスがクラッシュしたら全プロセスがクラッシュして再起動するのと変わらない』って言ってたけど、必ずしもそうじゃないと思うんだ。設計次第では、各FSプロセスがマウントポイントやFSタイプごとにリクエストを処理できるし、それだけで安定性は上がるでしょ。それに、接続が切れても、サーバーがハンドル情報をカーネルに保存しておけば、プロセスが再開した時に復旧できるはずだよ。乗り越えられない問題じゃないと思うな。

たしかに、それは全部解決できるね。FUSEもその例だよ。俺ならプロトコルをステートレスにしてfdの状態をクライアントに持たせるな。要は、OS設計者はトレードオフを理解した上で、限られた予算の中でどう時間を配分するか決めるんだ。クラッシュバグは有限だからね。複雑な再設計で少しだけ失敗を減らすか、バグ修正に時間を使うか。コードが複雑でサードパーティ製なら、FUSEやグラフィックドライバみたいに外に出す価値はある。でも、コアなファイルシステムみたいに小さくて安定しててパフォーマンス重視ならカーネル内に残すのが合理的だ。ブラウザもマイクロカーネル的だけど、何を分割するかは慎重だよ。マイクロカーネルって概念は、エンジニアリングのトレードオフを無視して全部ユーザー空間に置けって言うだけで、具体的なメリットを語らないから、今はほとんど使われない学術的なものなんだ。

『クラッシュバグは有限だから、再設計よりバグ修正』って言うけど、その有限ってすごく大きい数になることもあるよ。安定性を高める再設計の方が絶対良いに決まってるでしょ。そうじゃないなら、ユーザーモードのコードだって『メモリ保護なんて不要』って話になるよ。CloudStrikeのバグ覚えてる？あのドライバーがユーザーモードだったら、システムは動き続けてエラーを報告できたはずだよ。ブートループになるより、ずっとマシでしょ。

OSのコードはユーザーアプリより安定してるし、更新もゆっくりだね。ブラウザみたいな一部のユーザー空間アプリはマイクロカーネルだけど、多くのアプリは毎週更新されて不安定さも許容されがちだよ。

もう一回言うね。カーネルからコードを出すのは大変で、バグを直す方が早いこともあるんだ。でもAVスキャナーやGPUドライバーみたいにバグが次々出るやつは、カーネル外に出す方がいいんだよ。CrowdStrikeの多くはカーネルモードで動いてないし、MicrosoftもAVの一部をカーネル外に出すべきだったかもね。AVはどこにでも潜り込むから、Microsoftが排除するのは技術的じゃなく独禁法の問題になりそうだ。

DEC VTターミナルのプロトコルがANSI X3.64標準なせいで、この問題は解決も最新化もされてないんだと思うよ。詳しくはこれ見てね
https://en.m.wikipedia.org/wiki/ANSI_escape_code

組み込み用の簡単なCPUボードだと、グラフィックがないやつもあるから、シリアルポート経由でターミナルとかターミナルエミュレータを使って操作しなきゃいけないんだ。

汎用OSならそうかもね。でもNintendo 3DS OSとかSwitch OSは専用のマイクロカーネルベースで、数億台のデバイスに搭載されてるよ。DMA-330 CoreLink DMAの扱い方次第だけど、これもそうとカウントできるかもね。

マイクロカーネルは考え方はきれいだし安全だけど、実際はユニカーネルよりだいたい遅いんだ。

Gernot Heiserは最後の点については絶対反対するだろうねD

これはチャンスだね！まっさらな設計なんだから、階層型ファイルシステムなんて捨ててRDBMSに置き換えるべきだよ。

うん、RDBMSは良さそうだね。具体的な実装はこれから考えなきゃ。

記事ができたら読みたいなぁ。データベースみたいなストレージシステムを備えたホビーOSを作りたいんだけど、デザインでめっちゃ悩んでて動けないんだ。

すごいプロジェクトだね！SerenityOSみたいに、次のCCC CTFでSkiftOSが見られるのが楽しみだよ！[0] https://2019.ctf.link/internal/challenge/1fef0346-a1de-4aa4-…

かなり大変な作業だったろうね。カスタムビルドシステムを作ったのは驚きだけど、C++のビルドシステムの状態を考えると責められないな。
あと、なんでOS開発者ってブラウザを作りたがるんだろう？ブラウザってOSにほとんど依存しないんじゃないの？UIはめっちゃ良い感じ！

ブラウザはただのアプリケーション実行環境だよ ;)

SkiftOSすごいね。これって、早期リタイアした後に趣味でしかできないと思ってた計画とそっくりなんだ。まさかサイドプロジェクトでここまでできるとは想像してなかったよ。

きれいなUI以外に何があるの？ネットワークサポート、サウンド、どんなファイルシステムに対応してる？マルチユーザーは？アプリケーションの分離はどうなってるの？こういう情報がサイトのどこかに表示されてるといいんだけどな。

これはマイクロカーネルベースのOSだよ。僕にとっては学習と楽しむためのサイドプロジェクトって感じ。NixOSの/storeみたいなのを実装してるんだ。ハードウェア、ネットワーキング、サウンド、ファイルシステムはまだ超ベーシックな状態。これまでの作業は、ほとんどフレームワークといくつかのサンプルアプリ、あとブラウザに注力してるよ。

うーん…もっと幅広いハードウェアのサポートはどうなるの？SkiftOSがマイクロカーネルだってことを考えると、他のOS（Linuxとか）のフリーなドライバーを移植したり適応させたりするのって、どれくらい難しいんだろう？ :)

オフトピックでごめん。PalmSourceとかがBeOSのコードをオープンソースにしない理由が分からないよ。ライセンスの意地で20年前のコードを持ち続けても何の得にもならないのに。VCコミュニティが善意を語る割に、これって一番簡単なことじゃん？会社が倒産したら、未完成の権利は投資家に渡して、他のスタートアップのためにオープンソースにするっていう資金調達時の条項を作っておけば、もっと素晴らしいものが何度も生まれてたはずなのにね。愚痴終わり！

OSみたいな大規模なものをオープンソース化するのは金がかかるんだよ。権利関係の調査も必要だし、経営陣から見たら金をドブに捨てるみたいに見えるんだってさ。

それってstrawmanだよ。Be Inc.からACCESS Co.まで所有者が何回も変わったけど、その度にデューデリジェンスはしてたはずじゃん？一部のモジュールだけでもBSD-3とかMITにすれば意図が伝わるのにさ。VCってこの20年、そんなことしたことないよね。結局、金儲けが目的なんだよ。

めっちゃ良さそうじゃん。ブックマークしといたわ。macOSでまだビルドできてないけど、カスタムGCCをビルドしなくていいなら大歓迎だよ。

すごい！AIでコードをどれくらい書いたのか気になるな。

Copilotを早くから使ってたけど、だんだん使わなくなったな。AIアシスタント、エディタから全部消したよ。IDEへの統合って気が散るし邪魔だし、コーディングが楽しいから、楽しいとこまで自動化する必要なくなくない？

こういうプロジェクトは本当にどれも美しくて素晴らしいね。おめでとう。

めっちゃクール！6年間も作り続けてるなんてすごいね！

とても素敵だね。

美しいね。

くそ、これマジで良いじゃん。The Registerの人がこれ見てくれるといいな。