【C】Poneytail(仮称)OSスレッド01【未踏】
>>379
> たしかに未踏はシステム的にまだ弱いと思いますが、
それでも初年度頃に比べれば細かいところではずいぶん詰めが進んだと
思います。あの頃は完全に手探りでした。
実質の開発期間もとんでもなく短かったですし。
>>382
> 闇から闇へ、そういうい行動をとっている人に
まあビジネスの世界ではそうですけれどね。アカデミックの場合は割と雲隠れが許されます。
学生さんの場合は、就職でリセット効きますしね。(957氏のことじゃないですよ念のため)
> 未踏につぎ込んだ資金を回収してほしい、そう望んでいる人は少数派
今年からIPAは「事業化情報交換会」という採択事業のビジネスサポートを始めています。
OSS事業の採択者にもお誘いが来るのですが、未踏採択者にも来ます。
ビジネスまでの距離が遠いからこその未踏事業だと思うのですが…。
この辺りは当のIPA自身も苦悩しているのでは。
>>383
> オープンソースにすると、ソフトウェアの資産価値はゼロ以下
んなこたぁないです。 >> オープンソースにすると、ソフトウェアの資産価値はゼロ以下
>んなこたぁないです。
いいえ、OSSは間違いなく負債です。
OSSといえども知財であることは間違いありませんが、それを持っていてもお金は入りません。
逆に、著作者であるというだけで無理やりサポートさせられます。
外人からは意味不明かつ失礼な要求メールが次々と送られてきます。
日本人からの要求を無視すると2chで叩かれ、評判の悪い噂を流されます。
みんなで開発を手伝っていいものを作ろう・・・など妄想もいいところです。
OSSでは、完全に放棄でもしないかぎり強制労働させられてしまいます。
これを負債といわずに何と言えばいいでしょう。
クローズにしておけばユーザからの失礼な要求が来たときにも安全に断ることができます。
少なくともマイナスにはなりません。 >>385
> いいえ、OSSは間違いなく負債です。
"間違いなく"なんて言っちゃったりして怖ぃなぁもぅ。
またーり、またーり。
負債になるか資産になるかを決めるのは商材ではなく商才、なんてナ。
>>385
クローズドソースでもオープンソースでも変な要求を無視すればいいことになんら変わりは無い ライセンスの話は宗教も絡んでキリがないっつーか、
どこまでいっても観客全員の賛同は得られないもんなんで、ほどほどにやっとけばいい。
中身で頑張っとくれ。 税金の分だけ社会に還元しろって意味じゃない?
利益が出る形にして、還元するのはなかなか大変。
そういう意味じゃ、一番簡単なのはオープンソースだよね?
OSとして必要な機能のうち
実装済み
未実装
なものを大まかに教えて欲しいんだけど。
>>390
「還元」の種類による。
文科省系の事業ならまだしも、未踏は経産省系だから
直接的には事業化の際の税収、間接的には日本の技術者育成と産業振興が目的。
決してオープンソース支援ではない。
もちろんオープンにするのは決して悪い選択じゃないが、
放置して海外で利用されるだけだと国益としては×。
(もちろん開発を継続するのが一番なんだが) 議論があるのはいいことですね。期間終わってからこうなるとは思ってなかったですが(笑
>>382
未踏は責任と評価の方式が違うから独特の価値観が求められると思うのですが、
開発者の大半は学会と同じようなノリで行っていますし、それを認める雰囲気があります。
それは>>384さんがちょこっと触れている(学術は雲隠れして良い)に繋がる気もします。
>>384
ビジネス化要求は、未踏の知名度を上げたいかららしいです。有名にならないと未踏に予算が付かないって。
だから短期間で有名になりそうなら、ちょっと面白くなくても取るらしいけど。。。
飲み会で「OSなんてメディアには取り上げられないでしょ?」って言われました。
未踏システムは発展途上なんですよね。でもうーん、、なんというか手の打ち方がお役所的のような。。。
来年あたり「未踏プロジェクト評価基盤の開発」で申請しようかしら(笑) つか誰かすればいいのにね。
>>384-392 except 391
誰かが、"責任を持って"、CooSをオープンソースとして開発してくれるならいいけどねー。
現状のオープンソースはノーリターンの責任と義務がもれなく付いてきそう。
さらに書けば、公開したら公開したで、「公開してるんなら責任持ってメンテしろ」なんて。。。
ああ面倒ですね。
まーCooSは生誕一周年なわけです。
僕は去年はOSど素人だったわけで、CLIも去年から勉強した。
「OSS化すれば漏れが実用にする!」などという方は、自分で作っちゃった方がいいと思います。 >>391
実装して特徴的なもの。
・CLR、つまりランタイム
・C#で書かれたデバイスドライバ
欠けていて批判されそうなもの。
・ガベコレ
・スレッド
ちなみに成果発表会でちゃんと「できなかったよゴメン」って言ってまつ。
なんでやんなかったかったていうと、いずれもインタープリタでやるのがきついから。
未踏じゃなけりゃ手を付けていたけど、期間内で半端に手を付けてもなんにもなんないので止めた。
いまはインタープリタから脱却して、上を書けるようにする作業がメイン。
#最近は放置した学校の仕事で一杯一杯ですが・・・。 >>385
いかにも、オープンソースの経験が無い妄想野郎の発言
>>386
オープンソースで公開するのと、コードの変更権限は
別途に管理できますよ。
「公開してるんなら責任持ってメンテしろ」 なんてレベルの
メールはほとんどありません。 もし来てもドキュメントよ
く読んでねとか、軽く返答する程度
来るメールは非常にレベルが高く、貴重な パッチが大半で
本当に頭が下がる思いです。
957さんが、オープンソースにするのであれば Linuxの
開発モデルのよーに、CVSのコミット権やパッチ適用等の
ソース変更権限は本人のみで 管理するのが良いのではないでしょうか?
まだまだ基本設計やコードのリファクタリングを したい気持ちは判りますし、
クローズドも個人の プロジェクトとしては良い選択肢ではあります。
ただし、実装が一段落した将来には、オープン ソースの選択肢も良いものですよ
それと後公開するなら、絶対に英語を主体に。 日本人からの貢献は、
母数的にもほとんど ゼロに近いですから。
以上、ご参考まで
>>392
そうぱくりたいんだよ。
ブート直後からC++みたいだし、
OSのベースにするには申し分ない。 >>385
もう一言いっておけば
あんたはプログラミングの楽しさを知らない人種。
そんな輩がオープンソースを語るからおかしくなる。
プログラミングは自己表現の一つだよ。その延長線に
オープンソースがあるだけ
オープンソースから話を進めるのは、プログラミングの
楽しさを知らない証拠だよな 500万を趣味に使いました。
------終了------ >>396>>398はいかにもオープンソースの開発経験がない人がいいそうな理想論ですね。
OSSの使用経験はあるかもしれないけど、大規模なOSSの開発経験はないのでしょうね。
>「公開してるんなら責任持ってメンテしろ」 なんてレベルのメールはほとんどありません。
ほとんどない=少ないけどある
>もし来てもドキュメントよく読んでねとか、軽く返答する程度
再びうざい質問が来る
>来るメールは非常にレベルが高く、貴重な パッチが大半で
そのユーザ独自の特殊な環境で動くようにしたパッチ(変なCPU構成とか、変なビデオカードに対応した版)が来る。
他の人には全く役に立たないのがほとんど。
>ただし、実装が一段落した将来には、オープンソースの選択肢も良いものですよ
完成版をパクられて終わり
>それと後公開するなら、絶対に英語を主体に。
日本人でも欧米人でもパクりたい人がいるのは同じ。
以上、ご参考まで
オープソンースにしなくっていいというのは、
プログラムを販売したい人とか幅広く優秀な人を集めたいからだろ。
完成もしないんじゃ話にならない。 他のもあまりぱっとしないし、これくらいでいいんじゃない?
MSが似たようなの作ってるみたいだし、
MSのが完成したときに、あれと同じやつ先に作ったんだと自慢できるよ。 初カキコ。
いいんじゃないの?coosの方向性はあれで。
ぶっちゃけオレはこのスレ始まった時から個人開発で有用性を証明するのは
大変なんじゃないかと懐疑的だった人だったが、
MSよりも先にMSとは別の形でC#などのManagedな環境を用いた開発の有用性を
証明できたんだからそれはそれで価値があるはず。
オープンソース化しないから価値がない、価値が小さいってのは大きな間違いだと思う。
こーいうことばっかり言ってる人が多いからオープンソース界隈を
嫌ってしまう人もたくさんいるんじゃないかな。
まぁ国民の税金使ってるんだから、プログラミングについて全く知らない人に対しても
分かりやすい形での還元ってのはして欲しいかな。
オープンソース化はそーいう意味ではわかりやすいと思う。
ま、海外にパクられれば微妙だけどさ。。。
CLIについての技術視点からとか、C#でのOS開発で感じたメリット/デメリットとか、
そーいうのを文書化して公開してもらえると面白かったりするので期待してまふ。
>>404
フリーソフトウェア/GPL派の折れも同意見。 あ。
オープンソース云々の話が出てたからそれについて書いただけで満足してしまった。
まずいまずい。
「他のプロジェクトが批判されないのはおかしい」ってのは957氏の立場からは
言わないほうがいいのでは。
批判の矢面に立たされてる以上、「他の人だって・・・」的な子供のような批判の矛先の変え方は、
仮にそーいう意図がない場合でも、とても印象が悪いよ。
未踏プロジェクトの評価システムがまだまだ甘くて、
それぞれのプロジェクトについて評価・言及がなされていないものが多い、くらいにしておくべき。
そーしておかないと更なる批判を呼び起こしちゃう気がしまふ。
>> 405
私はGPLだけは嫌いなんだよなぁ・・・。
BSDLかPDSでいいじゃん、と思ってる人。
>>401
なんか、OSSで失敗した経験でもあるのか?
>再びうざい質問が来る
これはOSSは関係ないでしょ。むしろドキュメント未整備が主要因。
>そのユーザ独自の特殊な環境で動くようにしたパッチ(変なCPU構成とか、変なビデオカードに対応した版)が来る。
>他の人には全く役に立たないのがほとんど。
Coosの事は知らんが、これはソフトウェア基盤の問題でしょ。
そんな糞ソフトを公開しているから、そんなパッチがくるんだよ。
ドライバ仕様を明確にして公開していれば、プラグイン感覚で
マージして終わりでしょ。
>完成版をパクられて終わり
現状のCoosに、それほどのアドバンテージがあるの?
個人での開発なんて、たかが知れている
Coosだって、他のOSS等を参考にしている訳だし
自分だけクローズってのもなぁ。
むしろOSSで公開して、開発のスピードを上げるべきでは? OSSにすべきかどうかっていうのは、>>394でもう答えが半ば出てるような気がするんだけど。
OSS化を提案する>>407は、責任もって開発に参加する用意があるってことなのかな。 >>407のようにOSSで公開しろと主張する奴に限って、コードを1行も書かないんだろうなあ。
自分でOSSのプロジェクトを立ち上げてみりゃ、OSSの理想が机上の空論だってことはすぐにわかる。
>むしろドキュメント未整備が主要因。
第一に、ドキュメントをきちんと書いても、まず読まれない。
嘘だと思うなら、407がやってみなよ
そもそもOSSのソフトウェアって、「タダで転がっているもの」というイメージが強いんだよね。
要するに、道端の石ころと同じなわけ。
面白そうだから拾ってみて、ちょっといじって、ざっとコードを眺めて、
すぐにポイされる。
せっかくの成果がゴミのように扱われるんだよ。
これじゃあ作者はうかばれない。
OSSならみんなが知恵を出し合って改良発展させてくれる、って407は本気で信じてるのかな?
>むしろOSSで公開して、開発のスピードを上げるべきでは?
なんで、OSSで公開すると開発のスピードがあがるの?激しく疑問。 ふーむ。
僕がまとめていいものやら困りますが、CooSについてはまとめますか。
んで、まとめますが、なかなかレス量が多いのでちょっとメモ書き。
賛成・推進
>>396-398 >>407
反対・留保
>>401-405 >>408 >>410
まーどっちにしろ、オープンソース自体の一般的な善悪を判断することは適切ではないですかね。
それと>>406さん
ご意見参考になります。
開発者が批判をしない 現状はどうなのかなと思うので、僕は敢えて批判をしているのですが、
確かに立場としては慎重に行動するべきですね。気をつけたいと思います。
と書こうとしたら、間違って途中で書き込みしてしまいました。 結論から述べると、CooSをオープンソースにするようなリスクは取れそうにもないなあと思ったり。
いちばん怖いのが>>407において失敗の原因が「ソフトウェアが未熟だ」と括られていることです。
僕には「オープンソースとして失敗しないように開発を続ければ、絶対にOSS化は成功する」と読める。
#これは別に407さんの発言だけで判断しているのではなくて、
#OSS賛美の裏にあるリスクがよく現れていると思って引用しただけです。
それともう一つは、現在このスレッドは「いつものPoneytailスレ」ではないことです。
普段からCooSを支えていただいた人に加え、未踏スレからも人が来ている(気がする)。
新しく人が増えていることは嬉しいですが、でも今の流れを定常状態としてはなかなか受け取れません。
もうちょっと落ち着いたら考えよう、ということです。
CooSへのOSS化の要望はいくらでも歓迎?しますが、もうちょいクールダウンしませう。
それと未踏スレが消えて続きをココでって感じですね。
別にいいんだけど、僕としてはどこからが一般論なのか判断しにくいです・・・。 とりあえずソース公開を特別視して身構えてることは分かった。
そんな相手を説得しても無駄なのはみんなK対Lで身に染みてるよね。 評価すべきはソフトそのもの。
成果物で語れば良い。
良いものか否か。
ただそれだけ。
ソース公開かどうかなんて無問題。
ここは公開するソースを書いたことない椰子がいるんじゃないのか?
自分で書いてみればソース公開への躊躇の理由くらいわかるだろう。
見たこともない映画や、遊んだこともないゲームを批判する椰子と同じ。
自分の身をもって知ったものでないことに説得力はない。
当然だがソースを公開するかどうかなんて作者の自由。
公開による知名度等への貢献・儚いフィードバックへの期待と
知的財産価値の低下分を天秤にかけて、個々の価値観で決めれば良いこと。
漏れの場合、過去にソース公開したものへのフィードバックは、
アプリ側の要望ばかりだった。
少なくとも漏れのソースは公開した価値なかったな。
誰も見ないようなソースは公開しても公開しなくても大差ない。
公開しなくても誰も欲しがらないし、公開しても誰も見ないからだ。
つまりソース公開・非公開の両面に言えることなので、
どちらか一方が正しいという類の結論には結び付かない。
だから結局、自分が作ったものを自分でどう思ってるか、
というだけの問題に行き着く。
ある意味、誰かに拾ってもらえればと子猫を橋の下に捨てるのに似ている。 同意。どっちも正しいとおもう。
どうでも良いことかもしれんが、
日本人って日本語化以外にそれほど興味ないのか?
とおもうことが良くある。
コア部分の開発を助けないから、海外の人に
相手にされないことが多い。
日本人の漏れが見ていても魅力感じないだろうと
おもうのだから、まあ当然だろう。
せめて多言語化すれば良いのだろうが、なぜか日本語化をしたがる。
もちろん例外はあるし、OS板ではコア部分を書くのが好きな
例外的な人が多いが。
>>421
漏れのソースは、この板の大半の人が
知っているような、あるソフトの一部として使われている。
ただそれは漏れのプラスにはならなかった。
残念ながら。
>>423
他の人のプラスになればそれでいいってのが共産主義者。 Win/Winなんて滅多にないよ。
Win/Loseすらあまりないし、これは感じ悪い。
大抵はLose/Lose。
だから次善の策がLose/Winなわけだ。 >>424
だな。
まあ漏れは相当の時間を割く以上、何らかの
リターンを望んでいたのだろうな。
>>424
共産主義者というのは言い過ぎ。
そこそこの出来だけど売るほどのものでもない、ってときに、
放置しておいても腐るだけだし需要がゼロではないみたいだから、
ということで消極的に所有権を取り下げるくらいではないかと。
Irvineなんかこれだよね。
後継者なしでソース公開自体に意味がないというのは後出しジャンケンなわけで。
もっともオプソ=善だと妄信しているような輩もいるのだけど。 オープンソースうんぬんはこれで終了にしよう
話をリセットして技術的なことを話そう
957氏はOSを開発しててどういうところに苦労しましたか?
具体例とかあるとありがたい
#こんな振りしかできなくて情けない GPL以外のソフトは糞だからGPLを採用するべきだと思う >>414
反対・留保っていうか、>>420と同様、作者の自由だと思っている。
個人的には商売ネタとしてのオープンソースに可能性を感じていて奨めたいところだけれど、そう思わない人がいてもおかしくないし、界隈全体のリスクヘッジを考えると自分と違う思想の人がいるほうが都合がよい。自分の直感が正しいとは限らないからね。
それはさておき、全実行コンテキストで単一のメモリ空間を共有するっていうのは、割と"従来のOS"でも散見されるような。…なんていうのはこの板には似合わない話題か。すんまそん。
>>431
うん。メモリアクセスに対して保護無しならいくらでもあるね。MMUがなきゃそうするしかないし。
保護も行っている例で一応実用になっているものなら、JavaOSやμITRON PX仕様があるよね。
ほかにもあるような気がするけど、ちゃんと調べてないや。
ここは空気嫁る人が多いインターネッツですね(笑
>>428
設計で失敗してるのは、OSを開発していながら、ついついOSの存在を仮定してしまうところですかねえ。
特にC#なんかで書いていると、下位レイヤは隠蔽されているという立場が自然なわけで、
僕の頭の容量からしても Console.Write と打ちながらインタープリタの挙動までは正確にイメージしきれない。
上位レイヤを作っている自分と下位レイヤ担当の自分が意思疎通に失敗すると結構痛いミスになりました。
>>430-432
保護する必要がない、ってのがポイントです。
JavaOSはどーなのかなあ。思想は一緒だし。
jNodeを久しぶりに見たら結構活発ですしね。
新規性のなさについては、ごもっともです。
ただ、uITRONのように制約による単純化なのか、
洗練による単純化なのかというところは、見た目は同じでも大きい気がします。
これは僕はもっと大きい規模でもそうだと思っていて、たとえば、現時点でCooSを分岐して開発したとする。(どっちもOSSにしたとする。)
そうしたら、元は同じなのに、数年したら違うモノになってて、その違いは思想とか文化によるんじゃないかと思う。
僕はこの傾向はすべてのソフトウェアの中でOSが一番顕著だと考えているので、だから見た目よりも動機とか目的に拘ってる気は自分でもします。
んで、もとにもどると、だからアーキテクチャがすでにあるからっていうのはピンと来ないんだけど、
学会とかだとそれだとダメなんだろうなあ。修論でもダメかなあとちょっと頭が痛いです。 >ここは空気嫁る人が多いインターネッツですね(笑
後ろ向きことは、話したくないよね
ただ、オープンソースへの反応は過剰すぎない?
その根底にはソースを見られたくないことへの拒否感で
表向きには「サポート面倒」「パクリやだ」だけれでも
本当のところは「自分も大いにパクリました」「ソースが汚い」って
低レベルな話な気がする
当人は開発を続けるつもりだろうけど、本家マイクロソフトの
.NET Compact Frameworkに対しての優位性があるとも
思えないし、クローズにしても商用展開は難しいの一言でしょう
まぁ、当人も気がついているでしょうけど、趣味レベルが
望む望まないに関わらずの終着駅じゃないかなぁ
それなら、本当にOSのコアな部分の開発を手伝ってくれそうな人や、
一部のアプリを書いてくれそうな人だけに限定して、
NDAの元でソースを見せる、というソースコード開示方式にしたらどう? MSのshared source方式だね。何から何までMSの(ry >>434
確かに厳しいね。二番煎じのレベル
にも達していないのでは?
既に各デバイスプラットフォームに
多数のパートナー(英語リンク)が
参入/商品化していて
デバイス プラットフォーム
http://www.microsoft.com/japan/windows/embedded/devices/default.asp
現状でもサポートされるデバイスドライバが
多数存在している状況のWindowsCE.NETには
勝ち目はないかも
デバイスドライバ
http://www.microsoft.com/japan/windows/embedded/ce.net/evaluation/hardware/drivers.asp
957さんは、どういう方向性で進める
つもりなの?
> ただ、uITRONのように制約による単純化なのか、
よくわからない。解説きぼん。
> んで、もとにもどると、だからアーキテクチャがすでにあるからっていうのはピンと来ないんだけど、
> 学会とかだとそれだとダメなんだろうなあ。修論でもダメかなあとちょっと頭が痛いです。
新規性が無かったからといって何かを言うつもりはないんだけれどね。
アカデミックを意識している一方で先行研究との比較がが不十分なのは、
結構致命的かなと思うんだ。 とりあえずOSSとCooSに関わる話は>>416で総括とします。
要点は「議論はいいけど現時点で判断するべきではない」です。
#ついでに言えばOSS汎論はそろそろスレ違いっすね
>>437
たぶん余計に批判されそうな…。
まあ公開しようかなーと思ったらココに試案でも投げますので、
具体的な議論はそのときでいいと思うです。
>>439
勝ち負けの話であれば、客観的には「負け」を前提にしてかまいませんよ。
.NETの.NETのための.NETによるOSを作りたいです。
>>440
もし違ってたら指摘してください。uITRONは組み込みですよね?
ですからPCみたいに「ちょっと遅くなってもCPUに頑張ってもらえ」という姿勢ではない。
一方CLI/Javaのコード検証というのは結構たいへんな処理です。ついでにJITも。
これらを組み込みシステムで実現するのはなかなか厳しいと思いますが、
「実行時保護が不要」というためにはコード検証が不可欠です。
ですから、
PCの場合は、ソフトウェアによるコード検証が実装されたために要らなくなった保護機能で、
組み込みでは、アーキテクチャの複雑さを抑えるために機能を絞られた保護機能 だと思う。
これらは「保護がない」という点では同じですが、+コード検証が可能か否かでだいぶ事情が異なると思います。
アカデミックについては了解です。学会出せそうなら注意します。 >>441
議論上のつまらないテクニックだけど、安易にPCと組込みを対立軸にしないほうがいいかもしれないよ。最近組込み領域は広がる一方なので。古くはJavaOSの派生としてのJBlend、最近なら.NET Compact Frameworkなんて組込み向けだよね。
それに、最近のクリティカルソフトウェアの文脈では、適用分野をきつく規定するのって流行りではないみたい。
以上脱線。本題の保護に関する事情については、また後で。 >>441 さて本題。ttp://www.coos.jp/introduction/architecture.aspx を参照しながら。
以前例示したとおり、JavaOSとμITRON PX仕様は全実行コンテキストが単一のアドレス空間を共有している。
「(そのようなOSが存在するかは知りませんが。)」とはもう書けないね。
この2つのうち、μITRON PX仕様のメモリ管理は、MMUのアクセスコントロールを利用したもので、CooSとは方針が異なる。
それは認めるんだけれど、この方針のどこに「必ず制約が出てきてしまう」のか説明がない。
説明しきれていないものを特徴に挙げるのは、ちょっとキツいんじゃないかな。
ITRONだから噛み付いているわけじゃないよ。
PX仕様と同じ方式を採用しているOSが、他にもあるような気がする。
IPCのコストを下げるために、とか、マイクロカーネル屋がやりそうな手口じゃない?
視点を変えてJavaOS方面から考えてみる。
CooSは、OSであると同時に特定言語を軸とした仮想計算機の側面もあると思う(違う?)。
CLIの場合は、一応言語独立なのだけれど、分類上は汎用OSというよりは、Smalltalk環境やLISPマシンの方向に近いのではないかと。
これらの仮想計算機の場合は、実行コンテキストごとにMMUで保護するほうが稀なんじゃないかと思うんだけど、どうだろう。
そんなこんなで特徴として挙げている項目は、特徴たりえていないのではないかという気がする。
むしろ「CooSの面白さ」で挙げた項目のほうが、特徴なんじゃないかな、とかとか。 >>441
.NETの.NETのための.NETによるOSを作りたいですって
自分の趣味のための税金によるOSの勉強をしたいって
はっきり言ってもいいとおもうけどな
>>443
確かに、CooSの特徴って、単なる制限による仕様って
ぐらいにしか思えないね
>>434,>>439,>>443で、新規性も将来性もないような
書き方されているけど、モチベーションは維持でき
てますか?
>>444
おっとっと、>>443では「Webページで書いてある特徴は特徴じゃないかも」とは書いたけれど、将来性が無いとは書いてないよ。明日の事なんて誰もわからない。
新規性は、どうだろ。メモリモデルに新規性はないかもとは書いたけれど、全体としては、まだ判断つかないかもね。
新規性自身が要るかどうかわからない。初期のLinuxなんて開発プロセス以外に何も新規性がなかったわけだし今だって古くさいと後ろ指さされているし。 拝啓ちょっと大学の後期が始まりつつある関係でみょーに忙しく、まとまったレスはもうちょい先になりそうです。敬具 気のせいかもしれないが、公式HPで公開されてるソースっていつの間にか少し増えてる?
C#もC++も全然わからないから、眺めてるだけなんだけど たまに手を入れたりしているので増えたりしてますよ〜。 もう日曜か…orz
>>443,444
結局のところ、個々の技術的には、大した新規性は無いのは間違いないです。
仮想マシン、メモリモデル、中間言語、リフレクション、コード検証…。
OSアーキテクチャはどうしてもCPUに縛られますから、本質的な多様さはありませんし。
それをふまえて、CooSの特徴(というよりはCLIのすごさ)ってのは、それらを動作可能な形で実際にまとめ上げた、の一点に尽きると思います。
で、たぶんこれが本当のCooSの特徴なんですが、これって説明しにくいんですよね。
「どんなOS?」っていう問いに答えるには、思想的なものではなく、技術的なものがあった方が答えやすい。
だから書いてあるのがメモリモデルやらなんやら、というわけです。
>CLIの場合は、一応言語独立なのだけれど、分類上は汎用OSというよりは、Smalltalk環境やLISPマシンの方向に近いのではないかと。
SmalltalkやLISPマシンについてはあまりよく知らないのですが、近いといえば近いし、遠いと言えば遠い、、、かな。
SmalltalkマシンとかはSmalltalkありきですよね。CLIは普及した言語ありきだった。
Smalltalkは未来予想図としては良かったんだけど、"次の一歩"としてはCLIの方がいい。
だから、究極の環境としてはMMUは無くなって当たり前に見えるけれど、現実にはMMUが存在していて、
じゃあ現実にこれからMMUを無くすためにどうすればいいかってことになると、CLIとCooSってことにならないかな・・・。
#思いつくまま書いてるので分かりにくいかもしれない
>新規性も将来性もないような書き方されているけど、モチベーションは維持できてますか?
最近忙しくて触ってないけど、たぶんそのうち「開発させろー」とか言い始めるので大丈夫ですよ〜。 > 動作可能な形で実際にまとめ上げた
同意。だからこそ今の技術解説だと曲解されないかなという気が。
ちなみに、技術よりも思想の差異を示したほうが記事にしてもらいやすい。マスコミ対策の瑣末なテクニック。
あんまり思想に傾きすぎるのも、TRON界隈みたいな状態を呼びそうだけど…バランスバランス。
> CLIは普及した言語ありき
必ずしも同意できない。VB.NETなんて、もとのVBに対してかなり大きな変更を強いたし。
(CLIが強いた制約とは別に「このどさくさに紛れて」と言語設計者が考えたものも、あるいはあるかもしれないけれど)
まあそれぞれの言語に対して工数最小の移行パスを用意できた。そのバランス感覚は大したものだ、とは思う。 > CLIは普及した言語ありき
これはどちらかと言うと、Windowsアプリがかけるっていうのが大きいんじゃないの?
VS見たいなIDEで、アプリを書く環境がある。 単一アドレスのOSは研究レベルなら結構ある。
ttp://www.cs.washington.edu/homes/levy/opal/
ttp://www.cse.unsw.edu.au/~disy/Mungi/
など。
coosの特徴は「CLIのネイティブ実装」に尽きるような気がする。
なので将来のことはわからないけれど、今はCLIをもっと
前面に押し出すべきだと思う。 > 単一アドレスのOSは研究レベルなら結構ある。
ざっと読んだけど、やっぱしIPC絡みなのね。誰でも一度は考えそうだよな。
相変わらず調べてないけど、Embeddedの切り口でもきっと研究例はあると思うんだよね。
メモリの仮想化しちゃうとヤワなデバッガでは対応できなくなるケースがあるから。
> 今はCLIをもっと
言語Cの環境区分に倣って、フリースタンディングCLI環境と呼んでみたりとか?
まあ確かにそういう訴求の仕方が正しいと思う。 >452
>coosの特徴は「CLIのネイティブ実装」に尽きるような気がする
???? 意味分からん。CLI 実装はネイティブなんて必要条件でしょ
下記のページを参考に独自性を見つけるってはどう?
Microsoft シェアード ソース CLI 実装
http://www.microsoft.com/japan/msdn/net/sscli/mssharsourcecli.asp >>454
それ見ちゃうとNDAにひっかかるだろ。 >454
ネイティブってのは下位のレイヤーを必要としないという意味にとってください。
> Windowsアプリがかけるっていうのが
書けない。CLR相当まで拡張すれば話は別だけど。
IDEの大部分を流用できるというのは確かにメリットだね。
"大部分"と書いたのは、ウイザードがCLRにべったりのコードを吐く可能性があるから。
そういえば去年も9月の中旬に未踏申請したあと非常に忙しかった気がする。。。
>>452
そうですね。実際には、CLIっていう現実解を選んだことが大きいと思います。
ただ、CLIを前面に押し出したとしても、普通の人はそれで何が起こるか分からないのではないかなあ。
んで、まずアーキテクチャ的な説明か、セキュリティみたいなエンドユーザ側からの説明が必要になって、
そのあとにようやくCLIを選んだことの意味っていうふうになるんじゃないかなぁ。
ま、とりあえず、サイトのドキュメントが未整備なのは良くありませんね。。。
>>457
CLI規格はCLRも含むので、一応ドットネット向けなら動かせるはずです。
絶対動かせないのはP/Invokeとかで明らかに依存してるやつ。
あとCLRがライブラリという意味なら、たしかにSystem.Windowsの移植はしてないので足りないですね。 > 絶対動かせないのはP/Invokeとかで明らかに依存してるやつ。
VBから流れてきた人々は、Declare使うよね、ふつう。
.NET向けなら動くっていうのはわかるんだけど、Windowsアプリが
書けるっていうのは、ちょっと言いすぎじゃないかな。 うーん、そもそも"Windows"アプリでは言葉の定義としてOS依存なわけですから、
エミュレーションをしないCooSでは動かないですね。 なんか、理解はできないけどすごく読み応えのあるスレですね。
そんな中、こんなことを聞くのは気が引けるのですが、
このCooSは.NET FrameworkのVM(のような感じ?)として使えますか?現段階ではなくても
たとえばQemu上のCooSの中に.NET Frameworkでできたアプリケーションを動かしたいと思っています。
.NET Framework製アプリ専用のお砂場みたいな・・・
たぶん今日あたりプレスリリースかな。
おかげさまで「スーパークリエータ」らしいです。
感想とかはリリースを待ってからで。
とりあえずもう晒されるのは勘弁してほしいなぁ。
>>461
さすがにムリぽw
>>462
それは可能だと思います。もちろんOS+.NETなのですぐに実現できるわけではないですが…。 >>463
おめ。名前だけで特にメリットが無いのがあれだが。
暇なので展示を見に行くかのう。
>>463
レスどうもです。
やはり.NETのアプリケーションを動かせる段階というのは
その他OSの基本的な機能が実装されてからになるのでしょうか?
.NET Frameworkのアプリを動かすだけなら
現時点ではqemuに別のWindowsOSを入れてそこに.NET Frameworkランタイムを入れて
.NET Framework製アプリケーションを動かしたほうが現実的でしょうか? > とりあえずもう晒されるのは勘弁してほしいなぁ。
引きこもるか、晒されるか、どちらかしか道は無い。
未踏採択者は定期的に近況報告を求められるので、
引きこもるほうが難しい。
資料作ってない〜。ひー。
>>464
ありがd。
スーパーも恥ずかしいし、クリ"エータ"も恥ずかしいです…。
展示は特にしない予定なんだけど、ダメ?
ここ一ヶ月は何も進んでないしなあ。忙しすぎ。
>>465
CooSでは.NETが基本レイヤなので、むしろ「基本的な機能」が.NET関係だと言えます。
実用的な解であれば、おっしゃるとおりWindowsか、強いていえばLinux+Monoだと思います。
>>466
また色々言われたらめんどーって思ってます。。。
つーかスーパー(ry)になっちゃったからもう未踏応募できない〜。かなしー。 まだほとんど出来てないのに、スーパークリエータで応募出来ないのか。
どういう制度だよ。 人材発掘が目的だとすればスーパーなひとの再採用は不要だと思いますが、
スーパークリエータのがノンスーパーよりも権利を制限されるってのはどう考えても謎ですね。 スーパーになった奴は、希望すれば自動で継続とかにすればいいのに。 未踏の後は次世代があります、って話じゃないの?
確か去年か一昨年、そういう例あったよね。
次世代で目処がつければマッチングファンドとか。
って、釣られておいてなんですが、そろそろCooSの話に戻しませんか?
>>467
漏れは飯を食うのが主目的なのでどうでもいいんだけど、
未踏で成果発表できる所はIPAXくらいなので、出れるなら出た方がいいと思う。
>>471
それは法人格が厳しいですな。
未踏のアンケートにそう書いて送ったけど、どうにもならんしなあ。
> それは法人格が厳しいですな。
んなもん印紙税数万円と2週間の時間がありゃできますがな。実質工数は数日だし。半年もすりゃ会社法も改正でさらに作りやすくなるし、むしろ最近の連中は恵まれていると思うぞ。
ま、会社に勤めているとしがらみ障壁がいろいろあって踏ん切りつかないっていうのなら、判らんでもないけどね。
悩んだんだけど、当日はプレゼンもブースも出さないことにしました。
現状で出しても仕方ないし、それならビジネスにできる人に譲った方が良いかなってのが主な理由。
んで、ひさしぶりに次にやることというか。
次はJIT系だと決めてるんだけど、ちょっと前からバグがバグバグ出てきて、このままだと破綻する予感〜と思っていました。
なのでまずはNUnitを導入して、それなりにテスト駆動に移行しながらやっていこうかなと思います。
時間的見通しは難しいけど、未踏で〆切がなくなったので、品質志向(理想志向?)に戻ってもいいかなーと。
今週来週くらいで再開したい。。。 突然ですが、ブートローダをCで書いてみました。
前々からアセンブラは分からん…と思っていたので。
したらサイズが増える増える。2nd loaderが3KB近越え。
やっぱりアセンブラでちまちま書いた方が小さいねえ。
まー見やすいのでこれで行くけど〜。
http://www.coos.jp/src/viewer.aspx?path=coos/bootloader/
ディスク上では bpb.asm + 1stboot.c + 3rdboot.asm + 2ndboot.c という感じで並ぶけど、
実行は bpb -> 1st -> 2nd -> 3rd です。 >>478
Monaみたいに2ndをC#で書かないの? >>478
どういうコードが生成されるか意識して書けば、それなりに小さくできるよ。
いわゆる高級アセンブラな使いかた。
>>479
x86なコードに落とす手間を考えると、それほどメリットないべ。
ネタとしては面白いけど。
授与式でした。レセプションには偉い人来すぎ。
「未踏打ち上げー」みたいなノリを想像してたのでびびりましたよ。
>>479
ぶっちゃけCのが自然だと思います。CooS的ネタにはなるかもしれないけどw
>>480
そーなのかなぁ。
確かにCになると富豪的スタイルになっている感は否めない。
それにくわえて、手を抜いた部分をコンパイラが仕上げている感じもある。
ま、CローダはOS勉強する人に役に立つかなあと言うのも目的です。
アセンブラが王道なんだろうけど、やっぱアルゴリズムは理解しにくいので。 JITの応用でPreJIT(AOT)もできることを示す意味があるかと コード書きに夢中になってレセプション行きそびれたorz。
タダ飯食いながら957に粘着しようとおもっていたのだが。
C#やJavaでAOTという選択肢はスジが悪い(速度もメモリ効率も
あんまし上がらない)というのは、巷で割と良く言われていること
なのでわん。
そうじゃねーぞと言える何かがないと、頑張るだけの意味ないよね。
まあネタだっていうなら、それはそれでありか。