Mona ver.0.1.5 リリース 66
ストーリー by Oliver
目指せ、Hurdより前に完成 部門より
目指せ、Hurdより前に完成 部門より
Anonymous Coward曰く、"2ちゃんねるのOSを作ろうスレッドでひげぽん氏を中心に開発が進められているMonaのver.0.1.5がリリースされた。(リリースノート, スペック, ダウンロード)
Monaは従来のOSの枠組みにとらわれない新しいOSを目指して2年前から開発されている。その大半は地道なカーネルの実装に費やされたため地味な印象があったが、今回のリリースで念願のユーザーモードアプリケーションが作成できるようになった。リリースに含まれるフロッピーイメージにはメガデモやオセロなどが収録されている。"
"Monaは主にC++で記述されているが、ひげぽん氏はOS作成に着手するまでアセンブリやC/C++の経験はほとんどなかった。2年間でこれだけのものに仕上がったというのだから驚きである。もちろんそれは2ちゃんねるでのアドバイスが大きな助けになっており、2ちゃんねるをうまく利用したバザールモデルとして注目に値する。
将来的にはマイクロカーネルを目指しており、プロセス間のメッセージングによって動作するモデルを追求している。現時点でマウスやキーボードがサービス（デーモン）として提供されている。
実機でフロッピーブートさせることの繁雑さを避けるためエミュレータを重視しており、ひげぽん氏自らBochs, Virtual PC, VMwareで徹底的に動作を検証しているのも心強い。
まだまだ検証に不十分な点が多いため、MonaBBSのMonaOS開発板にある動作・不具合報告スレッド(直リンク不可)への報告にご協力をお願いしたい。"
ひげぽん氏の人格 (スコア:3, すばらしい洞察)
Monaがここまできたのはひげぽん氏の人格によるところも大きいと思います。
普通の人だったら2ちゃんねるのあのものすごい荒らしには耐えられないでしょう。
これからも頑張ってほしいものです。影ながら応援しています。
開発人数・・・？ (スコア:1, 興味深い)
BeOSと一緒の道を歩むんだろうか。
ポイントはアプリでしょう。ゲーム業界と一緒でソフトウェア・キラーコンテンツが無いと
ハード自体も売れないしOS自体も成長しないと思うんですが。
重たいOSにはなってほしくないと願います。
ん？ (スコア:0, フレームのもと)
素朴な疑問
Re:ん？ (スコア:4, すばらしい洞察)
知識とか経験とか楽しみの方が重要ですな。
Re:ん？ (スコア:2, すばらしい洞察)
新キャッチコピー (スコア:2, おもしろおかしい)
Re:ん？ (スコア:1, すばらしい洞察)
他コメントにも書かれてるけど、このOSって、作ること自体を楽しんでるわけでしょ？「使えるOS」を目指してたLinuxをこの場で比喩に出すのはイマイチな気がするし、時代背景を考えれば、使うことにしか興味のない人にとっては「GUI無いのぉ？」っていう反応があってもおかしくないと思うよ。
Re:ん？ (スコア:0)
素朴な疑問・・・
Re:ん？ (スコア:0)
「素朴」という言葉を使って、素朴を演出する方が
発想がいやらしいとも思いますしね。
解説を (スコア:1)
「こいつはここがスゲーんだ！」
というポイントが見えてこないんだけど、
どのへんがスゴイのか、解説お願いします、エラい人。
--------------------
/* SHADOWFIRE */
Re:解説を (スコア:3, すばらしい洞察)
ＯＳなんて (スコア:2, すばらしい洞察)
Re:解説を (スコア:2, すばらしい洞察)
Re:解説を (スコア:1, おもしろおかしい)
数日あれば全体を把握できそうな感じで手が出しやすそう・・・てか手をだしてぇ～
でもこれに手をだすと卒業できない・・・就職も決まらない。。。
なぜだか昔「はじめて読む486」を読んだ時のわくわく感がありますね。
Re:解説を (スコア:1, おもしろおかしい)
・処理に時間が掛かっている時に「中の人も大変なんです」とメッセージを表示する。
・ブラウザーがデフォルトでギコナビ
・ポップアップウィンドゥにＨサイトへの広告がついている。
・ＡＩが文章チェックを行っているので、誤字にうるさい。
・そのくせ「力」と「カ」などわざと誤変換する。
・愛着が湧いて使用しつづけていると、ある日突然閉鎖（アンインストール）している。
Mona搭載・・・ (スコア:1)
・Mona搭載PC
・Mona搭載モバイル
・Mona搭載ケイタイ
・Mona搭載PSX
＃搭載する意味があるのか分からないがID
Re:Mona搭載・・・ (スコア:3, 参考になる)
Monaは基本的にC++で開発されているので、携帯等のプアな環境には向きません。
もっとも、最近の携帯は数世代前のPDAよりも強力になってきてますが。
Re:Mona搭載・・・ (スコア:2, おもしろおかしい)
Re:Mona搭載・・・ (スコア:1)
Re:Mona搭載・・・ (スコア:2)
# そういやOpenGL/ESなんてのもあるな。
trueOne
Re:Mona搭載・・・ (スコア:2, 参考になる)
・templateの使用
コンパイラにもよると思いますが、基本的に使われうる型の組み合わせの分だけ同じようなコードが生成されるのであっという間にサイズが肥大化する傾向があります。
・例外処理機構の使用
try文の中では、例外発生時にスタック等を巻き戻すのに備えてある種のチェックコードのようなものが埋め込まれて多少実行効率が落ちる、のかな？(ちょっと自信なし)
あとはまあ、いろんな処理をクラスにラップすることで見通しはよくなるが、コードのサイズでちょっと損をするという場合は往々にしてあるように思います。
Re:Mona搭載・・・ (スコア:1)
＞・例外処理機構の使用
もうふたつほど、
・クラスでオブジェクトを渡す際に値渡しでなく参照を用いる。int１個をただ渡すだけとかまで参照にしなくてもいいんですけど、ふだんから気をつけてないとクラスのメンバーが実は数百バイトとかになってるのを平気で値渡しで書いてくる人もおられますので。
・constやstaticにすべきところは面倒でも省略しない。
このふたつがいいかげんだとすぐ肥大化します。また逆にきちんと守っているだけで劇的にコードは小さく速くなります。デバッグモードでビルドした時にはコードおよびメモリ使用量の差は歴然です。
templateについては、その中身をよく理解してから使わないと巨大になったり非効率だったりしますね。特にイテレータ関連だと、配列を直で扱うクラスで１枚ラッピングした方が良かったりしますし。もちろんあくまで時と場合によりますのでtemplateはすべてダメとか言うわけではありません。
＃C++やJavaで True,False用途でtry,catch使う人がいますが、お願いだから勘弁して！ソースが見にくいだけでなく、アセンブラレベルでも追いにくい～！！
Re:Mona搭載・・・ (スコア:1)
これってまともなC++プログラマには常識かと思ってたんですがそうでもないんでしょうか。というかC++に限らずCでもでかい構造体の値渡しは褒められたもんではないですよね。
Re:Mona搭載・・・ (スコア:1)
これがまあ利点でもあり欠点でもあるでしょうね
O(n)表記のように抽象的なレベルの見通しは良くなるが、定数項の重さが見えにくくなる。
コンストラクタ・デストラクタ・コピー・オペレータオーバーロード等々暗黙にコードが入るので、
明示的に関数呼び出しを書くのに比べて呼び出しコストを意識しなくなりがち
Cだと暗黙にコードが入るのは構造体の代入（と関数への構造体値渡し・返し）くらいだが
C++だと気をつけるところが増える。
（Cでも気をつけるべきところは気をつけんと効率が落ちるのは他の人が述べているが）
あと、一般的なスタイル的に
Cでは（記述がめんどくさいがゆえに？）メモリの動的確保は極力さける、
C++では（記述が簡単なゆえに？）多用する、といった傾向があるような
C++で実行・メモリ効率を意識しながら貧乏くさく書けばプアな環境でもいけるだろうし
Cでも富豪的に書けばだめだろ。
Re:Mona搭載・・・ (スコア:1)
だって楽ですから。面倒な部分もないわけじゃないですが。
＃ だからかみ合わないんじゃないですかね
＞また、一般的にtemplateでサイズ肥大化するのはinlineによる影響が大きいです。
inlineは指定を無視可能ですがマクロは強制的に展開されるのでC++の方がコンパクトになりますね（嘘）
テンプレートは発想がもともと富豪的なものですし、バイナリサイズに至ってはほとんど眼中にないと言っていいと思います。
＞ちなみに携帯電話の世界ではBREW等、C++による開発が 盛んに行なわれていますし、
BREWも組み込み系っぽい香りのする自称C++コンパイラですね。
（例外は起こさないように書けるとしても）STLが使えないC++なんて何かbetter-C以上のメリットがあるんでしょうか？
ひょっとして携帯でJavaが動くと言って、OOなプログラムが書かれているとでも思っていますか？
（今のところ）組み込みはやっぱり組み込みじゃないかと思う今日この頃です。
普通のC++を使える人は、組み込み環境でC++がサポートされているからといって組み込みのエンジニアになれるわけではありませんし、組み込みでC++のコンパイラを使っていたからといって普通のC++が書けるわけではないです。
＃ 普通のC++がちゃんと書ける人ならそのうち書けるようになるでしょうが…
僕なりの結論は
普通のC++だとコードサイズは大きくなり、実行速度もやや落ちる（書き方次第ではすごく落ちる）。
組み込みのコンパイラは大体ダメダメ（吐くコード以前に解釈に問題がある）。
Re:Mona搭載・・・ (スコア:1)
このインタビュー [vector.co.jp]に答えがあるかも。:-)
Re:Mona搭載・・・ (スコア:0)
Re:Mona搭載・・・ (スコア:1)
と言っていますし。
以下私見。
実行環境(バイナリサイズ、メモリ量)の他にもコンパイラ側の問題もあるような気がします。
C++はコンパイラを作るのが大変なので(Cすらまともなコンパイラのない環境が多いのに…)サポートするのは無理。templateなんて言わずもがな。割とメジャーと思われるPalmでもまともにSTLが使えるような環境ではありません…。
Re:Mona搭載・・・ (スコア:1)
そう言ってカトラー氏はC++のコードをCで書き直したとか。
初代NT開発時の逸話ですから、当時とはコンパイラの最適化周り等
事情は多分に異なるでしょうが、一般PCでは気にならないことも
プアな環境では大きく響いてくることはお分かりかと思います。
私の主観ではありますが、まだ資源の限られた状況で気ままに
走らせられるとは思いません。
Re:Mona搭載・・・ (スコア:3, 参考になる)
しかし、かつて同じようにCのバイナリはあまりにも効率が悪く使いものにならないとMC68000で大量のアセンブラコードが書かれた事がありましたが、今では「gccの吐く68000コードはあまりにも効率が良く人間がいじる余地がない」という声を聞きますよね。また、かつてBe-OSは当時の環境 (今のPDAよりプアだったように思います) で高いパフォーマンスを見せていたように記憶しています。
コンパイラと設計次第だったりはしませんかね。いや、「使っちゃいけないC++の重要な機能」なんてのがあれば本質的な弱点なのでしょうけど…。
Re:Mona搭載・・・ (スコア:1, 参考になる)
例えば C でサイズの大きい構造体を call by value の引数にして関数呼出しすると、スタックに大きいデータを積む関係で、実行速度は遅くなりますよね。
C で書く場合には、ほんの幾つかの点に気をつけてれば上の例のような状況を避けて実行速度の速いコードを書けるのですが、C++ で書くと、このへんの見通しが極端に悪くなるので、かなり大変なんですよ。
C++ を使って、ちゃんとカプセル化して、実行速度の速いコードを書けるってかなりの上級者ではないかな。
同じように実行速度が必要なGUIの場合はクラスライブラリ化した方がメリットがあるから、頑張って高速化したけど、OSの場合はそこまでやるメリットがあるかどうかもポイントなんじゃないですかね。
Re:Mona搭載・・・ (スコア:1)
納得しました。高パフォーマンスは可能だけどそれなりの労力が必要って事ですね。ありがとうございます。
Re:Mona搭載・・・ (スコア:0)
・クラスメソッドで名前空間がすっきり
・関数のオーバーロードにより、同機能のAPIは同名の関数で呼び出せる
ぐらいのベターCとして使えば、
Cと比べて効率は落ちず、しかも、読みやすいものになるんじゃないかと思うんですがどう
Re:Mona搭載・・・ (スコア:0)
携帯電話用のOSであるSymbianOSはC++で書かれている [symbian.com]のだが。
どうせなら (スコア:1)
ネコ型ロボット（青？）に搭載されたときは「ギコ」バージョンと呼ばれる。
解説求む (スコア:1)
というのは具体的にどこに現れているのでしょうか？
> 新しい技術に基づいてマイクロカーネルのOSを作成
とも書いてあるけど、単にマイクロカーネルと言うだけでは ありふれているし。どういう新規技術を導入した のか興味があります。 以前bitに、マイクロカーネルのIPCのオーバーヘッドを モノリシックのシステムコールのオーバーヘッドより軽くする 手法についての記事が載ったことがあったけど、それと 関係有る？
Re:解説求む (スコア:3, 興味深い)
>
> というのは具体的にどこに現れているのでしょうか？
他OSとの互換性(POSIXなど)を気にしていないという点です。
裏を返せば初心者が自分の好きなように遊んでいるだけですが。
> > 新しい技術に基づいてマイクロカーネルのOSを作成
> とも書いてあるけど、単にマイクロカーネルと言うだけではありふれているし。どういう新規技術を導入したのか興味があります。
そうだったらいいな、という理想です。実際に何か目新しい技術があるかと言えば、ありません。現時点ではマイクロカーネルですらありません。
> 以前bitに、マイクロカーネルのIPCのオーバーヘッドをモノリシックのシステムコールのオーバーヘッドより軽くする手法についての記事が載ったことがあったけど、それと関係有る？
現時点では動作させるのに精一杯という状態で、チューニングのことはほとんど考えられていません。FDドライバすら最適化されていない状態です。
もともと好奇心でOSを作りたくなったというだけで、革新的な何かを実装するためにやっているプロジェクトではないです。
Re:解説求む (スコア:2, 参考になる)
ちなみに、Linuxもそもそもは「もともと好奇心でOSを作りたくなったというだけで、革新的な何かを実装するためにやっているプロジェクトではない」というものでした。ただ、実用を目指してPOSIX互換を前提にしていたのがmonaとの大きな違いですね。
とはいえ、この手の小さなOSというのは、学習用途には非常にいいと思います。いきなり*BSDやLinuxではいまや肥大化しすぎていますし、かつてのこの手の用途の王道だったMINIXは、いまやフリーになったとはいえいまさら感が漂っていますし。
で、「革新的なOSがいじりたいんだ」っていう人はPlan9あたりをいじりましょう。
＃マイクロカーネル云々な人はL4 Hurdという手もあるな。
Re:解説求む (スコア:1)
好奇心を持つ方を募集中です;-)
Minix 2.0.4 mid development expert-only snapshot
http://minix1.hampshire.edu/news/README204.html [hampshire.edu]
http://osdev-j.osdn.jp/?MINIX [osdn.jp]
＃体力不足のコメンター(CVSリポジトリもどうぞ)
Re:解説求む (スコア:1)
メモリやプロセスの保護管理機能は無いのだろうか？
教えて詳しい人プリーズ
Re:解説求む (スコア:0)
ユーザーライブラリ (スコア:1)
QtからX依存の部分を切り離したもので、Unicode扱えるQStringクラスとかそれはまぁ色々なものが着いて来るんですが。
#暇になったらやってみよっかなぁ。
Re:ユーザーライブラリ (スコア:1)
ごっそり無いような気がしますが、誤読でしょうか？
UIとかの部分が無いと、純粋にコンパイラでコンパイルできるかどうか
というだけの問題になっちゃったりするんで、
「乗らんかな」という興味の対象には、なりにくいかも、と
ふと思ったのですが。
＃まあFileアクセスとかも充分にOSアーキテクチャ依存なテーマだけど。
それにしても、そっか。
C++で独自アーキテクチャなOSってことは、
libc(ってんだったよね)とも無縁なわけですね。
＃従来(?)と全然違うアーキテクチャのGUIを構築したい今日このごろなのでG7
＃Widgetが「Displayに」描画するんじゃなく、
＃Widgetが「親Widgetに」描画するっていうモデル。
＃イベントも「親Widgetから」渡されるってモデル。
＃Widgetの親子関係(親子間のデータのやりとり)だけで出来るだけ全ての事柄が動くようなモデル。
＃そうすれば「GUI版のExpect」や「マルチマウス」も無理なく対応できるはずなので…
Re:ユーザーライブラリ (スコア:1)
ただ便利なクラスが色々有るので動いたらよいかなと。
これが動くとKHTMLなんかも動いたりしますので。(もちろん描画部分だけはMona用に実装しなければいけませんが、HTML、CSS、Javascriptの解析部分等はTinyQtに含まれているクラスのみで動くので)
「乗る」というとちょっと誤解が有りますね。すいませんでした。
Re:ユーザーライブラリ (スコア:0)
> ごっそり無いような気がしますが、誤読でしょうか？
2chのスレの281 [2ch.net]のことですか？
それであれば誤読です。
X上のBochsでMonaを動かそうとしたときの話です。
MonaでXを動かそうとしているわけではありません。
> UIとかの部分が無いと、純粋にコンパイラでコンパイルできるかどうか
> というだけの問題になっちゃったりするんで、
> 「乗らんかな」という興味の対象には、なりにくいかも、と
> ふと思ったのですが。
何をコンパイラでコンパイルするのですか？
> C++で独自アーキテクチャなOSってことは、
> libc(ってんだったよね)とも無縁なわけですね。
基本
Re:ユーザーライブラリ (スコア:1)
>何をコンパイラでコンパイルするのですか？
他の方が書いてくださいましたが、TinyQtのほうの話でしたので、
コンパイルの対象もTinyQtです。
あ。サイトを見たところ、名称が違いますね。 TinyQ。最後のtは要らない。
＃何が削除されてることを意味するんだろうか？(^^;
>基本的にはそうなのですが、最低限のlibcは実装しようとしている [osdn.jp]ようです。
なるほど。
ところで蛇足、相変わらずよく判ってないんですが(^^;プロセス起動はforkとは違うやりかた、ですよね？ [osdn.jp]
(だったら)わーい。
Re:ユーザーライブラリ (スコア:1)
>固定委譲にどんな意味があるのでしょうか？
時間軸については「固定」したいわけではないです。
つまりWidgetの生成後の、(Widgetの親子関係の)付け替えは、幾らでも許すっていう奴。
ここらへんはSqueakとかと同じ(ですよね)。
Squeakの場合、マウスポインタすら1つのWidgetで、
DragDropのDrag開始は対象Widgetが「元の親からマウスポインタWidgetに乗り換えた」という形で表現されてるそうで、
従来のGUIと比べての余りのシンプルさに唖然としてしまった次第。
これからはせめてこれくらいは出来ないと駄目ですね。
あと、ビジュアルと委譲関係を一致させる(そういう意味では固定ですね)っていう発想をしていますが、
それは「わかりやすさ」を狙ったせいです。
というのは、ビジュアルプログラミング(^^;とかの方向性をやりたいんで。
ユーザ(しばしばトーシロ)でも、弄れば弄ったなりのモノになる、という感じの。
なので、良くも悪くも見たまんまに動く(orしばしば動かない(藁))といいなぁと。Program自体のWYSIWYG化。
触ったことないけどIntelligentPadとかが似た方向性なのかなあ？？？
効率とかはあまり優先したくありません。
ちょうど動作効率より記述効率のScript言語が最近元気なように、
GUIも記述(変更)のしやすさを優先するほうに倒しても良い時期じゃないかと。
＃他人が作った(Swingの)ソフトで「どのWidgetがProgramの何処に」通じているのかを探るのが物凄くシンドくて参ったので、G7
あと、ビジュアルと一致した委譲はあくまで「主な委譲先」の話です。
面倒な手段(=とりあえず思い描いているのは古典的なProgramming)を使えば
それ以外の委譲も出来ないわけじゃない、くらいの世界を考えました。
で、使いたくない人は使わなければいい、と。
ただ、主な委譲だけで記述できる範囲は、それなりに広くできるといいなぁとは勿論思っています。
そういう意味で「できるだけ」です。
>しかしWinFXでは任意のオブジェクトに委譲できるようなモデルに移行するので、
ああ。WinFXって、次世代Windows(ってのか)の事なんですね。
ええと。「動的委譲」というのが実際どういうものなのかは知らないんですが、
こういう話だと、どれくらいすれ違って(^^;いるんでしょうか？
＃そこはかとなくググってみましたが旨く発見できず。
ただ、OSとかが用意するWidgetの仕組みは、もうどうでもいいような気がしています。
というのは、自在な委譲を極めようと思ったら今でも既に簡単に出来るわけでして、
つまり我々がプログラミングすればいいんです(^^;。ええと、こういう問題でしょうか？
一緒になるかどうか判りませんが、古い体験でいえば、VC++とDelphiの差を連想しました。
つまり、WindowsのWidgetに対する「巧妙なラッパー」としてDelphiのオブジェクト群は設計されてて、
生Widgetの色々な使いにくさを隠蔽してくれる、っていうアレ。
(ちなみに、逆にDelphiで腹が立ったのは、単なる「Line」のWidgetすら無かったという点。)
で、一方、なまじ自在な委譲をやってくれると、今度は
他人(に限りませんが)のプログラムが「読みにくい」という問題が生じるような
気がしています。
あまり上手じゃないやりかたで、自由度ばかり増えてしまったので、
いわば「GUIスパゲティ」「イベント委譲スパゲティ」に陥っているんじゃないかと。
それを解決する道の1つとして、今のところ個人的には、
「何処に何が(何と何が)繋がっているか」が、もろに「見える」という
プログラミングスタイルが実現されると、良いんじゃないか？と思っているところなんです。
＃このGUIモデルのほかに「配線モデル」も考えてます。
＃ただ、よりスパゲティになりにくい(笑)のは、線よりも面かなーと。
ただ、自由度は落ちますね。そういう意味では高機能にはしにくいかも。
Re:ユーザーライブラリ (スコア:0)
libstdc++はどうしたのかな？ (スコア:1)
＃だから普通のOSはカーネル内はＣ言語
その辺はどうやって乗り越えたのかな？
早くSCOに訴えられるようになると良いね。 (スコア:0)