Top /
議論 / Monaは初志を忘れていないだろうか2006
Monaは初志を忘れていないだろうか2006 †
- uIPの移植に始まるネットワーク対応の流れの中でjunjunnさんがご指摘くださった点を議論しましょう。コミュニティからこちらに移動しました。
コメントはありません。 コメント/議論/Monaは初志を忘れていないだろうか2006?
- なぜか同じコメントが３つ挿入されてしまいました。すみません。。 -- ななしB?
- ひげぽんさん、IME（要素研究？）やネットワークプロトコルよりも、正の遺産を作りあげることに目を向けていきましょう。昔OSとしてつくりあげる部分（セオリー）と２１世紀にOSとしてつくりあげる部分が、必ずしも一致しなくてもぜんぜんOKかと思いますよ？情報がこれだけ乱立している世の中になったわけだから、検索情報の埋め込みを前提・必須としたファイルシステムと標準APLフォーマットを広義のOS機能としてまずは実現すべきかと。開発の知識がないので、はがゆいですが、OS自体がこれまでと違う発想に向かうことを願っています。 -- ななしB?
- ありがとうございます。僕もはやくネットワーク対応をひと段落してあたらしいことがやりたいです -- ひげぽん
- junjunnさんご理解ありがとうございました。これからもよろしくお願いします。 -- ひげぽん
- ひげぽん氏のスタンスが確認できてよかったです。
少なくともカーネルは100％ピュア、その他も利便としての移植性以外ではMonaオリジナルの方向で進む方針と言うのなら私も同じです。
それですみませんがuIP＆httpdの件につきましては発言を撤回させてください。
将来的には純度の為にNineBird（またはYamami氏のmones系列でも。Monaオリジナルと言える物なら何でもいいです）で置き換えるべきと思うのは変わらぬ本意ですが、もし私がNineBirdの開発継続に乗り出したとしても細かい物も含めれば相当な数のプロトコルのインプリメントにいつ終わるともわからないネットワークのコード書きに延々とMona全体を停滞させるのはよくないと思いました。
と、言うのも今はIME作ってます。分野的には形態素解析と呼ばれ、仕様的には「ひらがなchar*」を入力にとりそれを分析し一番可能性の高い「漢字交じりchar*」を出力するルーチンですが。
そっちがさすが手強く手間取りそうで今NineBirdに手が回せない状況です。（´へ｀;
こっちがいつ実用として使えるレベルになるか正直まるで見通し立たなく（数週間〜数ヶ月〜数年）
NineBird開発を再開できるめども立ちませんので暫定措置としてですがuIP＆httpd路線はどうぞ継続してください。
IMEが終わったらNineBirdに戻って開発を再開します。
uIPを越えるような物を目指して作りますのでそれが出来たら置き換えてもらえれば万事OKかと。(^^;-- junjunn
- 失礼しました。忘れてました。例外もあるという事ですね。 -- ひげぽん
- 「カーネルに自前実装でないものは基本的に入れない」とのことですが、mallocは例外ですか？ --
【OSを作ろうpart13 Mona専用】
238 名前： ひげぽん ◆Ngzcp/NZpA 投稿日： 2005/08/15(月) 23:50:05
メモリ管理
http://d.hatena.ne.jp/higepon/20050802/1122990649で書いた機能の設計。
monapi側で利用している例の優秀mallocの仕組みをプロセスのリニアアドレス管理に使えないだろうか?
と考えています。
いけそうな予感。
246 名前： ひげぽん ◆Ngzcp/NZpA 投稿日： 2005/08/16(火) 23:12:49
とりあえずカーネル側に例のメモリ割り当てロジックを移植しました。
- 詳細教えていただけないでしょうか。CVSアクセス権を持っている方ですか?呼びかける際の名前などもあわせて教えてください -- ひげぽん
- スレでの発言を引用しただけの通りすがりの者です。詳細は知りません。 --
- ＞ななしAさん
ご意見ありがとうございます。
対外アピールとのバランスなどとても参考になりました。
＞junjunnさん
まずはご理解くださってありがとうございます。
またjunjunnさんが気持ちよく開発に参加できる体制が整っていなくて申し訳ありません。
Monaは私がプロジェクトマスターとなっていると思うので私なりの結論を書かせていただきます。
結論がとても不愉快で、とても開発に手を出しづらいというような極端な不快感を覚えたらぜひつっこんでください。
(下のほうで書いたものに対しての補足です。)
■Monaの純度と基準
Monaの純度に関しては私の中に以下のような基準があります。
・カーネルに自前実装でないものは基本的に入れない
・カーネルからユーザー側に追い出せるものはある程度、移植の可能性を否定しない
・同程度の信頼性ならば 自前実装 >> 移植 という価値観
・開発者が触れるAPI設計にオリジナル設計の可能性を常に考える(例:monapi2)
・ユーザーが触れるUIにオリジナルの設計の可能性を常に考える(例:BayGUI,MonaForms,Windmill)
■置き換えについて
置き換え可能性については歓迎です。
NineBirdがuIPと交換可能になるのは大歓迎です。
■バランス
自前実装・移植の件もそうですが、その都度バランスを見て判断しようと思っています。
このあたりはある程度、私の価値観で決まってしまうものかもしれません。
ひげぽん
- 今回の件は理解しました。
確かにIP/TCPは仕様が固定されているのでOSによって違いが出しにくいと言うのは理解できます。だから全部手作業で0から書いても既存のソースを移植をしても結果的には変わらないのも理解できます。
ただ結果的には同じ事になれど書き手によってはソースに上手下手・スピード・メンテナンス性など違いは確かに出る物で
外側だけではなくそんな内部の品質への仕事もあるのでは・・・と私は思います。
私もNineBirdを書いている時に正直「ドライバもTCP/IPも仕様書通りに作るだけでつまんね・・・」
なんて思っていましたがあえて動くまでやり込んだのも
自分なら既存の.cコードなどよりも内部をうまく整理できると思ったからです。
そしてそこそこ納得できる物は得られたと思います。
もちろん納期など時と場合によっては私みたいに偏屈に拘るよりも手軽な方法で済ます事も必要だとは重々承知していますが。
私としてはNineBirdが無駄になるのが悔しいわけではありません。横から勝手に始めた事ですし勉強にもなりました。
一番気になっているのはOSとしての純度の問題です。外部ソースを持ち込む以上1％でも混じりが入ると
Monaは純粋なMonaプロジェクト・メンバーの成果とは言えなくなってしまいます。考えようによってはBSD（仮にそう呼ぶ）、その他の派生とも言えてしまいます。
将来的にMonaが大きくなり認知され有名になっても、「ああでもMonaのネットワークはBSDのコードをコピペして使ってるから。サーバー機能はHTTPDの移植だよ。」
なんて事になったら「あれ、じゃあ他の部分も他のOSやアプリのコピペ？Linuxディストリビューションの一種なのね。」
みたいに思われても仕方がないのでは・・・と言うことです。
独自に作っても既存の移植でも結果的に同じ物ができるんだから無駄じゃんって話かも知れませんが
そもそもネットワークがやりたいんなら既存のOSでアプリを作ればいいんです。
でもあえてその無駄とわかっている事をなぜか0から作って
自分たちの手だけでOSを完成させちゃう無駄な大バカにこそプロジェクトの本質と意義があるのでは・・・と私は思います。
移植したとしてもそこで動いているのはBSDや他人のプログラムであってMonaじゃありません。
「私たちが作りました」と胸を張って言えるOSにしたい。
その為にはネットワークドライバのような根幹が外部ソース丸ごとおんぶにだっこじゃ
まるで格好つかないのでは・・・と言うのが反対の理由です。
考え方の問題ですのでこれ以上の議論は無意味なのですが・・・
私としては少なくとも本家コアに関しては外部移植は避け
Monaのオリジナルコードに徹するべきだと思います。
でも感情論も無意味ですので・・・実際に行動で示すとしてもし私でいいのならば可能な限り、
HTTPDは今すぐは難しいにしてもクライエントとしてuIPをリプレースするぐらいは
NineBirdの多少の改良ですぐいけると思います。
その後時間をかけてサーバー機能を実装してゆくと言うのはどうでしょうか・・
（その場合はuIP、HTTPDの移植発表は取り下げて貰う事になってしまいますが）
移植なら今すぐにも動くのはわかってるのにわざわざ独自コードに拘って遅らせるのは私の個人的な我が儘以外の何物でもないってのは承知していますが。 -- junjunn
- 意見も出揃ったようですのでjunjunnさんのご意見待ちなかんじでしょうか＞ALL -- ひげぽん
- 失礼かと思いますが部外者の意見を述べさせていただきます。完全に部外者としての勝手な意見ですので、事実誤認などありましたらご容赦願います。 -- ななしA
- NineBirdとuIP
- 第三者としての推測ですが：時系列的に見ると、NineBirdのソース公開後にuIPの移植に着手されているわけで、junjunn氏が内心穏やかでないというのはお察しします。なぜわざわざ外部からライセンスを自由にできないコードを引っ張って来るのかと・・・。
- ですが経過をよく見ると、ひげぽん氏がmones2に着手する前にuIPを移植するべきかどうかという葛藤があり、当初は自前実装を選択したという事実があります。UDPまで実装した後、余興でuIPを突っついていたら、意外と簡単に移植できそうなので勢いでやってしまった、というように見えます。もしそうであれば、NineBirdよりもuIPを選択したという意識はまったくないはずです。
- 複数の実装が存在するというのは悪いことばかりではありません。問題が発生したときに比較することができるというメリットがあります。たとえばHTTPで50KB以上のデータが受信できないという問題はuIPでも再現したため、QEMUの問題だということが再確認できたように思います。
- 自前実装こそがアイデンティティーという立場と、手っ取り早く機能を増やすという立場を折衷させると、とりあえず移植でも何でもいいので使えるようにして、自前実装の部品で置き換えていくという戦略になるのではないでしょうか（詳細は後述）。
- 置き換えの際に移植物と自前実装をブロック部品のように簡単に交換できるようにしておけば、デバッグやベンチマークなどの比較目的で有用です。今回のケースではNineBirdとuIPを任意に交換できるようにしておいて、外部からは同じように扱えるというようなイメージです。これは唯一の実装に拘らずに多様性を容認するという立場です。これを突き詰めるとGAとかになりそうですが、もちろんそこまでは考えていません。
- 部外者にとっての魅力
- 評論家：内部実装やライセンスに関心がある。使い込んだりはしない。
- ユーザー：そのOSでどんなことができるかということしか関心がない。内部実装やライセンスは気にしない。
- アプリ開発者：自分の知っている技術だけですぐに取り組めると分かれば、余興で何か作ってみようかという気になりやすい。まったく新しいことを１から勉強するというのは敬遠されがち（理念はいいんだけどね〜etc）。また自分が日常的に使うものでなければ、作っても作りっぱなしでメンテされることはなくなってしまう。これは動機付けが需要ではなく好奇心だから。
- OS開発者：この手の人は自分でOSを作ることに関心があるので、他人のコードまで細かく観察したりはあまりしない。設計概念レベルで見るべきものがある・ないを判断する。
- 対外的なアピール
- 対象はユーザーとアプリ開発者。
- ユーザーは表面的なデザインやアプリの使い勝手に関心があります。そのためにはアプリ開発者を引き込んで作り込む必要があります。
- アプリ開発者にとって重要なのは、どんなものがどんな方法で作れるかです。内部実装がどうなっているかはあまり気にしませんし、自分でそのレイヤに手を出そうとまではあまり考えません。コア開発者と線引きする必要があります。オープンソースだから垣根はないというのはただの理想論です。
- 何を優先するべきか
- 前述のようにアプリが充実しないとユーザーは見向きもしてくれませんから、まずはみんなでアプリを充実させないとお話になりません。従ってアプリ開発者を念頭に置くという前提で話を進めます。
- アプリ開発者は何ができるかに関心がありますが、自分で新機能の実装に手を出したりまではしません。ですから最適化や純血化（自前実装）は後回しにして、とにかく機能を増やすことを優先します。ハリボテでもとりあえず動いているように見せないと、いつまで経っても人は集まって来ないでしょう。
- もちろんやっつけ仕事の後でそれを成熟させる作業をするのは当然ですが、最初から完璧を狙ってじっくり作りこむことを優先していては対外的なアピールがなく、「何も進展していない」という印象を与えてしまって戦略的にマイナスです。
- 独自性について
- 目新しい概念があれば興味を惹かれますが、汎用性のない完全に独自の概念は勉強意欲を著しく削ぐものです。逆に萌えるという人はむしろ例外です。それでも敢えてまったく新しい概念を作るのであれば、汎用性を持たせないと受け入れてもらえないでしょう。
- 普通のアプリ開発者はミドルウェアより下のレイヤはあまり気にしません。ミドルウェアレベルの独自性であれば、最初からマルチプラットフォーム展開を前提にしないと、興味を持っても手を出すまで行く人はほとんどいないでしょう。これを実行に移したのがOpenStepやJavaです。Windowsオンリーの開発者が自作アプリをLinuxやMacにも対応させる場合とりあえずJavaで作ってみるというケースがありますが、それと同じでミドルウェアの魅力で引き付けておまけみたいにMona対応に持ち込むという戦略です。この場合Monaと関係なくミドルウェアとしての魅力が問われることになります。
- つまりアプリ開発者へのアピールを最優先すると、OSよりもミドルウェアの比重が大きくなってしまうことは避けられないわけです。しかもミドルウェアはマルチプラットフォームかどうかが重要になりますから、純粋にMonaだけをターゲットにした開発ではなくなってしまいます。これを許容できるかどうかが一つの線引きとなるでしょう。
| 選択肢 | メリット | デメリット |
| 許容する | 外の人へのアピール増 | 中の人への負担増 |
| 許容しない | 中の人への負担減 | 外の人へのアピール減 |
- 移植は異物として純血化を重視するにしても、外部へのアピールと両立させるには、手っ取り早く移植でもいいから機能を増やして、後から自前実装に置き換えていくのが現実的な落とし所ではないでしょうか。自前実装に時間が掛かっても機能自体の提供が遅れるという事態は避けられます。事情がどうあれ提供が遅れると、第三者の目には開発が停止しているように見えます。これは事実です。
- 以上、乱文乱筆、大変失礼いたしました。 -- ななしA
- junjunnさん、ご意見ありがとうございます。これは大事なことなのできちんと議論したいですね。
まず私が思っている前提を列挙します。
- 過去のしがらみに囚われないOSという思想は今も変わりません。私自身がlibcに積極的に取り組まないのもそのような理由によります。
- 移植が大部分を占めるようなOSは本意ではありません。
では今回のネットワーク対応の件はどうかというと、以下のトライと思考の流れがありました
- ひげぽんがネットワーク知識がないために勉強したい
- 先行実装のmones(TCP開発部分で一時停止中）を勉強していくことでネットワーク知識を身につけよう
- mones2を実装していく中で、ネットワークの実装は初めにプロトコルの仕様ありきであることを強く感じるようになりました。
- それはイコール、Monaとして他のOSとの違いを出せるところではないと思うようになりました。違いを出すとすればもう少し上のレイヤーでしょう。（たとえばクラスタ化とか、ネットワーク用のAPIとか)
- また仕様ありきで、堅牢な先行実装がある中で、あえてひげぽん自身が、仕様どおり・堅牢に実装するのは時間がもったいないと判断しました。
- また移植話の対象となっているNICのドライバも同様で、NICの仕様ありきで実装されるもので、OSによって違いの出せるところではないと考えました。
- ということなので、理想としてはプロトコルスタック・NICドライバの移植の方針に賛成してくださる方に任せることなのですが。今までの現状を見ていると、それはかなり無理のあることで、結局私がやる必要があるのではと強く感じています。
- 結局ひげぽんが手を出すのであれば、移植と全自前実装にどちらにMonaにとってのメリットが高いかとの判断になり、前者を今のところ考えています。
- なので可能な限り短い時間で移植によりネットワーク実装の「他のOSと違いが出しづらいところ」を済ませてしまい、Mona色を出せるようなところに手をつけたいというのが正直なところです。
つまり今回のネットワーク対応が特別に移植向きなだけで、初志は忘れてないです。
これはひげぽんの力不足も関係していると思っていまして、ネットワークの知識がバリバリあり、マネジメント力があれば、適切な指示だしを誰かにして上記作業をやってもらうことも可能だと思うのですがそこが出来ないのが現状です。
以上です。これは、ひげぽんの独善的な考えの可能性があるので、ぜひ更にご意見をお聞かせください。junjunnさん -- ひげぽん
- すいません不適切な内容になるかも知れませんがちょっとプロジェクトの方向について書かせてください。
最近のuIPの移植や、それにこの先予定されている数々の移植の予定を見て個人的にちょっと色々気になる所があるかな・・って思っています。
それはライセンスの事でもあり、もう一つは開発思想に関する複雑な問題なのですがどこまでがMonaの成果になるのかなって感じで・・・
究極的にはお手軽だからとあれもこれもと全部引っ張って来て移植してしまうと
それって結局は他のOSで使われているコードのコピペクローンになってしまい結局MonaはどこにあってMonaは何を成し遂げたの？って人に聞かれた時に正直どう答えていいのか迷う事になってしまうと思います・・・
BSDタイプのライセンスはどうやってもソースから外せない以上
Monaの心臓部（のソースの一部）にMona開発者でも変えようがない外部ライセンスが永久に埋め込まれる事になるのも気分的にスッキリしない物があります。
全てを0から造り上げるなんてのは甘っちょろい理想論。
現実問題としては移植した方が速くて安定でエンド開発者もみんなハッピーってのはよくわかっていますので全面反対しているわけではありませんが・・・
ただ可能ならば、Mona開発者の誰かが自力で成し遂げれる事ならコピペ移植より困難な選択でもそっちのオリジナルコードを追って完成させる方がOS作成プロジェクトとしての「意義」はあるんじゃないかな・・・と思います。
過去のしがらみに囚われない洗練された新設計OSを目指していたMonaの初志思想と最近は違う方向に向かってる感じがしないでもなかったですので
この場を借りて私の考えを申し上げさせてもらいました。
以上は私個人の考え方ですのでひげぽん氏に押しつけようとか言うつもりはありません。
ただMonaOSの存在意義と方向性について一考してもらえれば幸いです。 -- junjunn
