【C】Poneytail(仮称)OSスレッド01【未踏】

**Be名無しさん** · NG

公式サイト:http://www.tirasweel.net/ponytail/
未踏について:http://www.ipa.go.jp/jinzai/esp/2004mito2/koubokekka.html
関連スレ:http://pc5.2ch.net/test/read.cgi/os/1093825736/l50

2004年度未踏ソフトウェア創造事業採択プロジェクト
テーマ:CLIを実装する次世代オペレーティングシステムの開発

C#でアプリを作成できるOS？ランタイムはMono譲り？未踏の血税で開発中！

**Be名無しさん** · 2005/09/17(土) 00:25:56

困ります八○さんとか

山○とかは、その代表格だな

**Be名無しさん** · 2005/09/17(土) 01:54:34

500万を趣味に使いました。

------終了------

**Be名無しさん** · 2005/09/17(土) 09:50:38

>>396 >>398はいかにもオープンソースの開発経験がない人がいいそうな理想論ですね。
OSSの使用経験はあるかもしれないけど、大規模なOSSの開発経験はないのでしょうね。

>「公開してるんなら責任持ってメンテしろ」なんてレベルのメールはほとんどありません。
ほとんどない＝少ないけどある

>もし来てもドキュメントよく読んでねとか、軽く返答する程度
再びうざい質問が来る

>来るメールは非常にレベルが高く、貴重なパッチが大半で
そのユーザ独自の特殊な環境で動くようにしたパッチ(変なCPU構成とか、変なビデオカードに対応した版)が来る。
他の人には全く役に立たないのがほとんど。

>ただし、実装が一段落した将来には、オープンソースの選択肢も良いものですよ
完成版をパクられて終わり

>それと後公開するなら、絶対に英語を主体に。
日本人でも欧米人でもパクりたい人がいるのは同じ。

以上、ご参考まで

**Be名無しさん** · 2005/09/17(土) 17:58:03

オープソンースにしなくっていいというのは、
プログラムを販売したい人とか幅広く優秀な人を集めたいからだろ。
完成もしないんじゃ話にならない。

**Be名無しさん** · 2005/09/17(土) 18:05:47

他のもあまりぱっとしないし、これくらいでいいんじゃない？
MSが似たようなの作ってるみたいだし、
MSのが完成したときに、あれと同じやつ先に作ったんだと自慢できるよ。

**Be名無しさん** · 2005/09/17(土) 22:14:03

初カキコ。

いいんじゃないの？coosの方向性はあれで。
ぶっちゃけオレはこのスレ始まった時から個人開発で有用性を証明するのは
大変なんじゃないかと懐疑的だった人だったが、
ＭＳよりも先にMSとは別の形でC#などのManagedな環境を用いた開発の有用性を
証明できたんだからそれはそれで価値があるはず。

オープンソース化しないから価値がない、価値が小さいってのは大きな間違いだと思う。
こーいうことばっかり言ってる人が多いからオープンソース界隈を
嫌ってしまう人もたくさんいるんじゃないかな。

まぁ国民の税金使ってるんだから、プログラミングについて全く知らない人に対しても
分かりやすい形での還元ってのはして欲しいかな。
オープンソース化はそーいう意味ではわかりやすいと思う。
ま、海外にパクられれば微妙だけどさ。。。

CLIについての技術視点からとか、C#でのOS開発で感じたメリット/デメリットとか、
そーいうのを文書化して公開してもらえると面白かったりするので期待してまふ。

**Be名無しさん** · 2005/09/17(土) 22:31:36

>>404
フリーソフトウェア/GPL派の折れも同意見。

**Be名無しさん** · 2005/09/18(日) 00:04:20

あ。
オープンソース云々の話が出てたからそれについて書いただけで満足してしまった。
まずいまずい。

「他のプロジェクトが批判されないのはおかしい」ってのは957氏の立場からは
言わないほうがいいのでは。
批判の矢面に立たされてる以上、「他の人だって・・・」的な子供のような批判の矛先の変え方は、
仮にそーいう意図がない場合でも、とても印象が悪いよ。
未踏プロジェクトの評価システムがまだまだ甘くて、
それぞれのプロジェクトについて評価・言及がなされていないものが多い、くらいにしておくべき。
そーしておかないと更なる批判を呼び起こしちゃう気がしまふ。

>> 405
私はGPLだけは嫌いなんだよなぁ・・・。
BSDLかPDSでいいじゃん、と思ってる人。

**Be名無しさん** · 2005/09/18(日) 11:38:45

>>401

なんか、OSSで失敗した経験でもあるのか？

>再びうざい質問が来る

これはOSSは関係ないでしょ。むしろドキュメント未整備が主要因。

>そのユーザ独自の特殊な環境で動くようにしたパッチ(変なCPU構成とか、変なビデオカードに対応した版)が来る。
>他の人には全く役に立たないのがほとんど。

Coosの事は知らんが、これはソフトウェア基盤の問題でしょ。

そんな糞ソフトを公開しているから、そんなパッチがくるんだよ。

ドライバ仕様を明確にして公開していれば、プラグイン感覚で
マージして終わりでしょ。

>完成版をパクられて終わり

現状のCoosに、それほどのアドバンテージがあるの？
個人での開発なんて、たかが知れている

Coosだって、他のOSS等を参考にしている訳だし
自分だけクローズってのもなぁ。

むしろOSSで公開して、開発のスピードを上げるべきでは？

**ITRON名無しさん** ◆4WD27e3i1o · 2005/09/18(日) 12:03:31

OSSにすべきかどうかっていうのは、>>394でもう答えが半ば出てるような気がするんだけど。
OSS化を提案する>>407は、責任もって開発に参加する用意があるってことなのかな。

**Be名無しさん** · 2005/09/18(日) 12:05:12

消えろ空気固定

**Be名無しさん** · 2005/09/18(日) 12:54:57

>>407のようにOSSで公開しろと主張する奴に限って、コードを１行も書かないんだろうなあ。
自分でOSSのプロジェクトを立ち上げてみりゃ、OSSの理想が机上の空論だってことはすぐにわかる。

>むしろドキュメント未整備が主要因。
第一に、ドキュメントをきちんと書いても、まず読まれない。
嘘だと思うなら、407がやってみなよ

そもそもOSSのソフトウェアって、「タダで転がっているもの」というイメージが強いんだよね。
要するに、道端の石ころと同じなわけ。
面白そうだから拾ってみて、ちょっといじって、ざっとコードを眺めて、
すぐにポイされる。
せっかくの成果がゴミのように扱われるんだよ。
これじゃあ作者はうかばれない。

OSSならみんなが知恵を出し合って改良発展させてくれる、って407は本気で信じてるのかな？

>むしろOSSで公開して、開発のスピードを上げるべきでは？
なんで、OSSで公開すると開発のスピードがあがるの？激しく疑問。

**Be名無しさん** · 2005/09/18(日) 13:39:24

言いたいことは分かるがここでやるな

**Be名無しさん** · 2005/09/18(日) 13:44:35

Lと同類ってことでFA

**Be名無しさん** · 2005/09/18(日) 13:48:40

Lﾀﾝスレがなくなって名無しで乙

**957** ◆KhjEefLZMk · 2005/09/18(日) 14:18:33

ふーむ。
僕がまとめていいものやら困りますが、CooSについてはまとめますか。
んで、まとめますが、なかなかレス量が多いのでちょっとメモ書き。

賛成・推進
>>396-398 >>407
反対・留保
>>401-405 >>408 >>410

まーどっちにしろ、オープンソース自体の一般的な善悪を判断することは適切ではないですかね。

それと>>406さん
ご意見参考になります。
開発者が批判をしない

**957** ◆KhjEefLZMk · 2005/09/18(日) 14:20:15

現状はどうなのかなと思うので、僕は敢えて批判をしているのですが、
確かに立場としては慎重に行動するべきですね。気をつけたいと思います。

と書こうとしたら、間違って途中で書き込みしてしまいました。

**957** ◆KhjEefLZMk · 2005/09/18(日) 15:02:18

結論から述べると、CooSをオープンソースにするようなリスクは取れそうにもないなあと思ったり。

いちばん怖いのが>>407において失敗の原因が「ソフトウェアが未熟だ」と括られていることです。
僕には「オープンソースとして失敗しないように開発を続ければ、絶対にOSS化は成功する」と読める。
＃これは別に407さんの発言だけで判断しているのではなくて、
＃OSS賛美の裏にあるリスクがよく現れていると思って引用しただけです。

それともう一つは、現在このスレッドは「いつものPoneytailスレ」ではないことです。
普段からCooSを支えていただいた人に加え、未踏スレからも人が来ている（気がする）。
新しく人が増えていることは嬉しいですが、でも今の流れを定常状態としてはなかなか受け取れません。
もうちょっと落ち着いたら考えよう、ということです。

CooSへのOSS化の要望はいくらでも歓迎？しますが、もうちょいクールダウンしませう。
それと未踏スレが消えて続きをココでって感じですね。
別にいいんだけど、僕としてはどこからが一般論なのか判断しにくいです・・・。

**Be名無しさん** · 2005/09/18(日) 15:17:32

GPL希望

**Be名無しさん** · 2005/09/18(日) 15:42:18

>>417
論外

**Be名無しさん** · 2005/09/18(日) 21:08:56

とりあえずソース公開を特別視して身構えてることは分かった。
そんな相手を説得しても無駄なのはみんなK対Lで身に染みてるよね。

**Be名無しさん** · 2005/09/18(日) 22:48:55

評価すべきはソフトそのもの。
成果物で語れば良い。
良いものか否か。
ただそれだけ。
ソース公開かどうかなんて無問題。

ここは公開するソースを書いたことない椰子がいるんじゃないのか？
自分で書いてみればソース公開への躊躇の理由くらいわかるだろう。
見たこともない映画や、遊んだこともないゲームを批判する椰子と同じ。
自分の身をもって知ったものでないことに説得力はない。

当然だがソースを公開するかどうかなんて作者の自由。
公開による知名度等への貢献・儚いフィードバックへの期待と
知的財産価値の低下分を天秤にかけて、個々の価値観で決めれば良いこと。

漏れの場合、過去にソース公開したものへのフィードバックは、
アプリ側の要望ばかりだった。
少なくとも漏れのソースは公開した価値なかったな。

**Be名無しさん** · 2005/09/18(日) 23:07:26

誰も見ないようなソースは公開しても公開しなくても大差ない。
公開しなくても誰も欲しがらないし、公開しても誰も見ないからだ。
つまりソース公開・非公開の両面に言えることなので、
どちらか一方が正しいという類の結論には結び付かない。
だから結局、自分が作ったものを自分でどう思ってるか、
というだけの問題に行き着く。
ある意味、誰かに拾ってもらえればと子猫を橋の下に捨てるのに似ている。

**Be名無しさん** · 2005/09/18(日) 23:15:39

同意。どっちも正しいとおもう。

どうでも良いことかもしれんが、
日本人って日本語化以外にそれほど興味ないのか？
とおもうことが良くある。
コア部分の開発を助けないから、海外の人に
相手にされないことが多い。
日本人の漏れが見ていても魅力感じないだろうと
おもうのだから、まあ当然だろう。
せめて多言語化すれば良いのだろうが、なぜか日本語化をしたがる。

もちろん例外はあるし、OS板ではコア部分を書くのが好きな
例外的な人が多いが。

**420** · 2005/09/18(日) 23:24:25

>>421
漏れのソースは、この板の大半の人が
知っているような、あるソフトの一部として使われている。
ただそれは漏れのプラスにはならなかった。
残念ながら。

**Be名無しさん** · 2005/09/18(日) 23:27:56

>>423
他の人のプラスになればそれでいいってのが共産主義者。

**Be名無しさん** · 2005/09/18(日) 23:31:37

Win/Winなんて滅多にないよ。
Win/Loseすらあまりないし、これは感じ悪い。
大抵はLose/Lose。
だから次善の策がLose/Winなわけだ。

**Be名無しさん** · 2005/09/18(日) 23:31:51

>>424
だな。
まあ漏れは相当の時間を割く以上、何らかの
リターンを望んでいたのだろうな。

**Be名無しさん** · 2005/09/18(日) 23:40:10

>>424
共産主義者というのは言い過ぎ。
そこそこの出来だけど売るほどのものでもない、ってときに、
放置しておいても腐るだけだし需要がゼロではないみたいだから、
ということで消極的に所有権を取り下げるくらいではないかと。
Irvineなんかこれだよね。
後継者なしでソース公開自体に意味がないというのは後出しジャンケンなわけで。
もっともオプソ＝善だと妄信しているような輩もいるのだけど。

**Be名無しさん** · 2005/09/18(日) 23:59:06

ｵｰﾌﾟﾝｿｰｽうんぬんはこれで終了にしよう
話をﾘｾｯﾄして技術的なことを話そう

957氏はOSを開発しててどういうところに苦労しましたか？
具体例とかあるとありがたい
#こんな振りしかできなくて情けない

**Be名無しさん** · 2005/09/19(月) 00:00:21

GPL以外のソフトは糞だからGPLを採用するべきだと思う

**ITRON名無しさん** ◆4WD27e3i1o · 2005/09/19(月) 00:14:42

>>414
反対・留保っていうか、>>420と同様、作者の自由だと思っている。
個人的には商売ネタとしてのオープンソースに可能性を感じていて奨めたいところだけれど、そう思わない人がいてもおかしくないし、界隈全体のリスクヘッジを考えると自分と違う思想の人がいるほうが都合がよい。自分の直感が正しいとは限らないからね。

それはさておき、全実行コンテキストで単一のメモリ空間を共有するっていうのは、割と"従来のOS"でも散見されるような。…なんていうのはこの板には似合わない話題か。すんまそん。

**Be名無しさん** · 2005/09/19(月) 00:31:04

共有するだけでなく保護されないと駄目だよ。

**ITRON名無しさん** ◆4WD27e3i1o · 2005/09/19(月) 00:49:16

>>431
うん。メモリアクセスに対して保護無しならいくらでもあるね。MMUがなきゃそうするしかないし。
保護も行っている例で一応実用になっているものなら、JavaOSやμITRON PX仕様があるよね。
ほかにもあるような気がするけど、ちゃんと調べてないや。

**957** ◆KhjEefLZMk · 2005/09/19(月) 01:49:37

ここは空気嫁る人が多いインターネッツですね（笑

>>428
設計で失敗してるのは、OSを開発していながら、ついついOSの存在を仮定してしまうところですかねえ。
特にC#なんかで書いていると、下位レイヤは隠蔽されているという立場が自然なわけで、
僕の頭の容量からしても Console.Write と打ちながらインタープリタの挙動までは正確にイメージしきれない。
上位レイヤを作っている自分と下位レイヤ担当の自分が意思疎通に失敗すると結構痛いミスになりました。

>>430-432
保護する必要がない、ってのがポイントです。
JavaOSはどーなのかなあ。思想は一緒だし。
jNodeを久しぶりに見たら結構活発ですしね。

新規性のなさについては、ごもっともです。
ただ、uITRONのように制約による単純化なのか、
洗練による単純化なのかというところは、見た目は同じでも大きい気がします。

これは僕はもっと大きい規模でもそうだと思っていて、たとえば、現時点でCooSを分岐して開発したとする。（どっちもOSSにしたとする。）
そうしたら、元は同じなのに、数年したら違うモノになってて、その違いは思想とか文化によるんじゃないかと思う。
僕はこの傾向はすべてのソフトウェアの中でOSが一番顕著だと考えているので、だから見た目よりも動機とか目的に拘ってる気は自分でもします。

んで、もとにもどると、だからアーキテクチャがすでにあるからっていうのはピンと来ないんだけど、
学会とかだとそれだとダメなんだろうなあ。修論でもダメかなあとちょっと頭が痛いです。

**Be名無しさん** · 2005/09/19(月) 03:33:41

>ここは空気嫁る人が多いインターネッツですね（笑

後ろ向きことは、話したくないよね

ただ、オープンソースへの反応は過剰すぎない？

その根底にはソースを見られたくないことへの拒否感で
表向きには「サポート面倒」「パクリやだ」だけれでも
本当のところは「自分も大いにパクリました」「ソースが汚い」って
低レベルな話な気がする

当人は開発を続けるつもりだろうけど、本家マイクロソフトの
.NET Compact Frameworkに対しての優位性があるとも
思えないし、クローズにしても商用展開は難しいの一言でしょう

まぁ、当人も気がついているでしょうけど、趣味レベルが
望む望まないに関わらずの終着駅じゃないかなぁ

**Be名無しさん** · 2005/09/19(月) 04:26:59

>>434
おめーが過剰すぎ。

**Be名無しさん** · 2005/09/19(月) 08:57:28

句点の無い人の割にはまともなこと言ってるな

**Be名無しさん** · 2005/09/19(月) 09:03:54

それなら、本当にOSのコアな部分の開発を手伝ってくれそうな人や、
一部のアプリを書いてくれそうな人だけに限定して、
NDAの元でソースを見せる、というソースコード開示方式にしたらどう？

**Be名無しさん** · 2005/09/19(月) 09:12:33

MSのshared source方式だね。何から何までMSの(ry

**Be名無しさん** · 2005/09/19(月) 09:43:33

>>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さんは、どういう方向性で進める
つもりなの？

**ITRON名無しさん** ◆4WD27e3i1o · 2005/09/19(月) 10:47:31

> ただ、uITRONのように制約による単純化なのか、

よくわからない。解説きぼん。

> んで、もとにもどると、だからアーキテクチャがすでにあるからっていうのはピンと来ないんだけど、
> 学会とかだとそれだとダメなんだろうなあ。修論でもダメかなあとちょっと頭が痛いです。

新規性が無かったからといって何かを言うつもりはないんだけれどね。
アカデミックを意識している一方で先行研究との比較がが不十分なのは、
結構致命的かなと思うんだ。

**957** ◆KhjEefLZMk · 2005/09/19(月) 14:47:22

とりあえずOSSとCooSに関わる話は>>416で総括とします。
要点は「議論はいいけど現時点で判断するべきではない」です。
＃ついでに言えばOSS汎論はそろそろスレ違いっすね

>>437
たぶん余計に批判されそうな…。
まあ公開しようかなーと思ったらココに試案でも投げますので、
具体的な議論はそのときでいいと思うです。

>>439
勝ち負けの話であれば、客観的には「負け」を前提にしてかまいませんよ。
.NETの.NETのための.NETによるOSを作りたいです。

>>440
もし違ってたら指摘してください。uITRONは組み込みですよね？
ですからPCみたいに「ちょっと遅くなってもCPUに頑張ってもらえ」という姿勢ではない。

一方CLI/Javaのコード検証というのは結構たいへんな処理です。ついでにJITも。
これらを組み込みシステムで実現するのはなかなか厳しいと思いますが、
「実行時保護が不要」というためにはコード検証が不可欠です。

ですから、
PCの場合は、ソフトウェアによるコード検証が実装されたために要らなくなった保護機能で、
組み込みでは、アーキテクチャの複雑さを抑えるために機能を絞られた保護機能　だと思う。
これらは「保護がない」という点では同じですが、＋コード検証が可能か否かでだいぶ事情が異なると思います。

アカデミックについては了解です。学会出せそうなら注意します。

**ITRON名無しさん** ◆4WD27e3i1o · 2005/09/19(月) 15:42:54

>>441
議論上のつまらないテクニックだけど、安易にPCと組込みを対立軸にしないほうがいいかもしれないよ。最近組込み領域は広がる一方なので。古くはJavaOSの派生としてのJBlend、最近なら.NET Compact Frameworkなんて組込み向けだよね。
それに、最近のクリティカルソフトウェアの文脈では、適用分野をきつく規定するのって流行りではないみたい。
以上脱線。本題の保護に関する事情については、また後で。

**ITRON名無しさん** ◆4WD27e3i1o · 2005/09/19(月) 19:06:23

>>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の面白さ」で挙げた項目のほうが、特徴なんじゃないかな、とかとか。

**Be名無しさん** · 2005/09/22(木) 23:49:24

>>441

.NETの.NETのための.NETによるOSを作りたいですって

自分の趣味のための税金によるOSの勉強をしたいって
はっきり言ってもいいとおもうけどな

>>443

確かに、CooSの特徴って、単なる制限による仕様って
ぐらいにしか思えないね

>>434,>>439,>>443で、新規性も将来性もないような
書き方されているけど、モチベーションは維持でき
てますか？

**ITRON名無しさん** ◆4WD27e3i1o · 2005/09/23(金) 00:04:30

>>444
おっとっと、>>443では「Webページで書いてある特徴は特徴じゃないかも」とは書いたけれど、将来性が無いとは書いてないよ。明日の事なんて誰もわからない。

新規性は、どうだろ。メモリモデルに新規性はないかもとは書いたけれど、全体としては、まだ判断つかないかもね。
新規性自身が要るかどうかわからない。初期のLinuxなんて開発プロセス以外に何も新規性がなかったわけだし今だって古くさいと後ろ指さされているし。

**957** ◆KhjEefLZMk · 2005/09/23(金) 01:31:31

拝啓ちょっと大学の後期が始まりつつある関係でみょーに忙しく、まとまったレスはもうちょい先になりそうです。敬具

**Be名無しさん** · 2005/09/23(金) 12:06:48

気のせいかもしれないが、公式HPで公開されてるソースっていつの間にか少し増えてる？
C#もC++も全然わからないから、眺めてるだけなんだけど

**957** ◆KhjEefLZMk · 2005/09/24(土) 00:57:15

たまに手を入れたりしているので増えたりしてますよ～。

**957** ◆KhjEefLZMk · 2005/09/25(日) 16:44:59

もう日曜か…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ってことにならないかな・・・。
＃思いつくまま書いてるので分かりにくいかもしれない

>新規性も将来性もないような書き方されているけど、モチベーションは維持できてますか？

最近忙しくて触ってないけど、たぶんそのうち「開発させろー」とか言い始めるので大丈夫ですよ～。

**ITRON名無しさん** ◆4WD27e3i1o · 2005/09/25(日) 17:10:39

> 動作可能な形で実際にまとめ上げた

同意。だからこそ今の技術解説だと曲解されないかなという気が。
ちなみに、技術よりも思想の差異を示したほうが記事にしてもらいやすい。マスコミ対策の瑣末なテクニック。
あんまり思想に傾きすぎるのも、TRON界隈みたいな状態を呼びそうだけど…バランスバランス。

> CLIは普及した言語ありき

必ずしも同意できない。VB.NETなんて、もとのVBに対してかなり大きな変更を強いたし。
(CLIが強いた制約とは別に「このどさくさに紛れて」と言語設計者が考えたものも、あるいはあるかもしれないけれど)
まあそれぞれの言語に対して工数最小の移行パスを用意できた。そのバランス感覚は大したものだ、とは思う。

**Be名無しさん** · 2005/09/25(日) 19:05:33

> CLIは普及した言語ありき

これはどちらかと言うと、Windowsアプリがかけるっていうのが大きいんじゃないの？
VS見たいなIDEで、アプリを書く環境がある。

**Be名無しさん** · 2005/09/28(水) 20:57:21

単一アドレスのOSは研究レベルなら結構ある。
ttp://www.cs.washington.edu/homes/levy/opal/
ttp://www.cse.unsw.edu.au/~disy/Mungi/
など。

coosの特徴は「CLIのネイティブ実装」に尽きるような気がする。
なので将来のことはわからないけれど、今はCLIをもっと
前面に押し出すべきだと思う。

**ITRON名無しさん** ◆4WD27e3i1o · 2005/09/28(水) 23:45:15

> 単一アドレスのOSは研究レベルなら結構ある。

ざっと読んだけど、やっぱしIPC絡みなのね。誰でも一度は考えそうだよな。
相変わらず調べてないけど、Embeddedの切り口でもきっと研究例はあると思うんだよね。
メモリの仮想化しちゃうとヤワなデバッガでは対応できなくなるケースがあるから。

> 今はCLIをもっと

言語Cの環境区分に倣って、フリースタンディングCLI環境と呼んでみたりとか?
まあ確かにそういう訴求の仕方が正しいと思う。

**Be名無しさん** · 2005/09/29(木) 10:22:29

>452
>coosの特徴は「CLIのネイティブ実装」に尽きるような気がする

???? 意味分からん。CLI 実装はネイティブなんて必要条件でしょ

下記のページを参考に独自性を見つけるってはどう？

Microsoft シェアードソース CLI 実装
http://www.microsoft.com/japan/msdn/net/sscli/mssharsourcecli.asp

**Be名無しさん** · 2005/09/29(木) 12:10:51

>>454
それ見ちゃうとNDAにひっかかるだろ。

**452** · 2005/09/29(木) 19:56:47

>454
ネイティブってのは下位のレイヤーを必要としないという意味にとってください。

**ITRON名無しさん** ◆4WD27e3i1o · 2005/09/30(金) 10:14:40

> Windowsアプリがかけるっていうのが

書けない。CLR相当まで拡張すれば話は別だけど。

IDEの大部分を流用できるというのは確かにメリットだね。
"大部分"と書いたのは、ウイザードがCLRにべったりのコードを吐く可能性があるから。

**957** ◆KhjEefLZMk · 2005/10/03(月) 12:44:55

そういえば去年も9月の中旬に未踏申請したあと非常に忙しかった気がする。。。

>>452
そうですね。実際には、CLIっていう現実解を選んだことが大きいと思います。
ただ、CLIを前面に押し出したとしても、普通の人はそれで何が起こるか分からないのではないかなあ。
んで、まずアーキテクチャ的な説明か、セキュリティみたいなエンドユーザ側からの説明が必要になって、
そのあとにようやくCLIを選んだことの意味っていうふうになるんじゃないかなぁ。

ま、とりあえず、サイトのドキュメントが未整備なのは良くありませんね。。。

>>457
CLI規格はCLRも含むので、一応ドットネット向けなら動かせるはずです。
絶対動かせないのはP/Invokeとかで明らかに依存してるやつ。
あとCLRがライブラリという意味なら、たしかにSystem.Windowsの移植はしてないので足りないですね。

**ITRON名無しさん** ◆4WD27e3i1o · 2005/10/03(月) 19:41:17

> 絶対動かせないのはP/Invokeとかで明らかに依存してるやつ。

VBから流れてきた人々は、Declare使うよね、ふつう。
.NET向けなら動くっていうのはわかるんだけど、Windowsアプリが
書けるっていうのは、ちょっと言いすぎじゃないかな。

**957** ◆KhjEefLZMk · 2005/10/03(月) 20:44:22

うーん、そもそも"Windows"アプリでは言葉の定義としてOS依存なわけですから、
エミュレーションをしないCooSでは動かないですね。

**Be名無しさん** · 2005/10/04(火) 00:40:52

Windowsとバイナリ互換

**Be名無しさん** · 2005/10/07(金) 01:41:05

なんか、理解はできないけどすごく読み応えのあるスレですね。
そんな中、こんなことを聞くのは気が引けるのですが、
このCooSは.NET FrameworkのVM（のような感じ？）として使えますか？現段階ではなくても

たとえばQemu上のCooSの中に.NET Frameworkでできたアプリケーションを動かしたいと思っています。
.NET Framework製アプリ専用のお砂場みたいな・・・

**957** ◆KhjEefLZMk · 2005/10/07(金) 06:53:34

たぶん今日あたりプレスリリースかな。
おかげさまで「スーパークリエータ」らしいです。
感想とかはリリースを待ってからで。
とりあえずもう晒されるのは勘弁してほしいなぁ。

>>461
さすがにムリぽｗ

>>462
それは可能だと思います。もちろんOS+.NETなのですぐに実現できるわけではないですが…。

**Be名無しさん** · 2005/10/07(金) 10:08:30

>>463
おめ。名前だけで特にメリットが無いのがあれだが。

暇なので展示を見に行くかのう。

**462** · 2005/10/07(金) 18:22:25

>>463
レスどうもです。
やはり.NETのアプリケーションを動かせる段階というのは
その他OSの基本的な機能が実装されてからになるのでしょうか？

.NET Frameworkのアプリを動かすだけなら
現時点ではqemuに別のWindowsOSを入れてそこに.NET Frameworkランタイムを入れて
.NET Framework製アプリケーションを動かしたほうが現実的でしょうか？

**ITRON名無しさん** ◆4WD27e3i1o · 2005/10/08(土) 11:27:01

> とりあえずもう晒されるのは勘弁してほしいなぁ。

引きこもるか、晒されるか、どちらかしか道は無い。
未踏採択者は定期的に近況報告を求められるので、
引きこもるほうが難しい。

**957** ◆KhjEefLZMk · 2005/10/08(土) 23:09:38

資料作ってない～。ひー。

>>464
ありが㌧。
スーパーも恥ずかしいし、クリ"エータ"も恥ずかしいです…。

展示は特にしない予定なんだけど、ダメ？
ここ一ヶ月は何も進んでないしなあ。忙しすぎ。

>>465
CooSでは.NETが基本レイヤなので、むしろ「基本的な機能」が.NET関係だと言えます。
実用的な解であれば、おっしゃるとおりWindowsか、強いていえばLinux+Monoだと思います。

>>466
また色々言われたらめんどーって思ってます。。。

つーかスーパー（ｒｙ）になっちゃったからもう未踏応募できない～。かなしー。

**Be名無しさん** · 2005/10/09(日) 15:19:20

まだほとんど出来てないのに、スーパークリエータで応募出来ないのか。
どういう制度だよ。

**957** ◆KhjEefLZMk · 2005/10/09(日) 16:34:07

人材発掘が目的だとすればスーパーなひとの再採用は不要だと思いますが、
スーパークリエータのがノンスーパーよりも権利を制限されるってのはどう考えても謎ですね。

**Be名無しさん** · 2005/10/09(日) 17:32:27

スーパーになった奴は、希望すれば自動で継続とかにすればいいのに。

**ITRON名無しさん** ◆4WD27e3i1o · 2005/10/09(日) 18:16:14

未踏の後は次世代があります、って話じゃないの?
確か去年か一昨年、そういう例あったよね。
次世代で目処がつければマッチングファンドとか。

って、釣られておいてなんですが、そろそろCooSの話に戻しませんか？

**Be名無しさん** · 2005/10/09(日) 20:22:23

話題ないし

**464** · 2005/10/09(日) 23:55:06

>>467
漏れは飯を食うのが主目的なのでどうでもいいんだけど、
未踏で成果発表できる所はIPAXくらいなので、出れるなら出た方がいいと思う。

>>471
それは法人格が厳しいですな。
未踏のアンケートにそう書いて送ったけど、どうにもならんしなあ。

**ITRON名無しさん** ◆4WD27e3i1o · 2005/10/10(月) 00:54:19

> それは法人格が厳しいですな。

んなもん印紙税数万円と2週間の時間がありゃできますがな。実質工数は数日だし。半年もすりゃ会社法も改正でさらに作りやすくなるし、むしろ最近の連中は恵まれていると思うぞ。

ま、会社に勤めているとしがらみ障壁がいろいろあって踏ん切りつかないっていうのなら、判らんでもないけどね。

**Be名無しさん** · 2005/10/10(月) 12:56:19

この段階で会社作って応募するなんて無理だろ

**957** ◆KhjEefLZMk · 2005/10/12(水) 01:24:07

悩んだんだけど、当日はプレゼンもブースも出さないことにしました。
現状で出しても仕方ないし、それならビジネスにできる人に譲った方が良いかなってのが主な理由。

んで、ひさしぶりに次にやることというか。

次はJIT系だと決めてるんだけど、ちょっと前からバグがバグバグ出てきて、このままだと破綻する予感～と思っていました。
なのでまずはNUnitを導入して、それなりにテスト駆動に移行しながらやっていこうかなと思います。
時間的見通しは難しいけど、未踏で〆切がなくなったので、品質志向（理想志向？）に戻ってもいいかなーと。
今週来週くらいで再開したい。。。

**957** ◆KhjEefLZMk · 2005/10/12(水) 18:11:53

プレスリリースｷﾀｰ。

2004年度第２回未踏ソフトウェア創造事業　開発成果＆PMの評価：
http://www.ipa.go.jp/jinzai/esp/2004mito2/kaihatuseika.html

**957** ◆KhjEefLZMk · 2005/10/24(月) 10:26:00

突然ですが、ブートローダを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 です。

**Be名無しさん** · 2005/10/24(月) 19:49:51

>>478
Monaみたいに2ndをC#で書かないの？

**Be名無しさん** · 2005/10/24(月) 21:48:33

>>478
どういうコードが生成されるか意識して書けば、それなりに小さくできるよ。
いわゆる高級アセンブラな使いかた。

>>479
x86なコードに落とす手間を考えると、それほどメリットないべ。
ネタとしては面白いけど。

**957** ◆KhjEefLZMk · 2005/10/25(火) 00:04:57

授与式でした。レセプションには偉い人来すぎ。
「未踏打ち上げー」みたいなノリを想像してたのでびびりましたよ。

>>479
ぶっちゃけCのが自然だと思います。CooS的ネタにはなるかもしれないけどｗ

>>480
そーなのかなぁ。
確かにCになると富豪的スタイルになっている感は否めない。
それにくわえて、手を抜いた部分をコンパイラが仕上げている感じもある。

ま、CローダはOS勉強する人に役に立つかなあと言うのも目的です。
アセンブラが王道なんだろうけど、やっぱアルゴリズムは理解しにくいので。

**Be名無しさん** · 2005/10/25(火) 06:02:35

JITの応用でPreJIT(AOT)もできることを示す意味があるかと

**ITRON名無しさん** ◆4WD27e3i1o · 2005/10/25(火) 10:17:17

コード書きに夢中になってレセプション行きそびれたorz。
タダ飯食いながら957に粘着しようとおもっていたのだが。

C#やJavaでAOTという選択肢はスジが悪い(速度もメモリ効率も
あんまし上がらない)というのは、巷で割と良く言われていること
なのでわん。
そうじゃねーぞと言える何かがないと、頑張るだけの意味ないよね。
まあネタだっていうなら、それはそれでありか。

**Be名無しさん** · 2005/10/25(火) 16:22:04

ぶっちゃけOSをネタから引き上げるのが一番難しいから、
意味のあるなしで言えばOS作りほど筋が悪いことはないかと。

**484** · 2005/10/25(火) 16:25:43

誤解を招きそうなので補足。
Coosに水を差すつもりは毛頭ありません。
現実的な意味を取り沙汰するのに違和感を感じただけっす。
技術的探究心は大いに結構、それこそ未踏の精神では。

**480** · 2005/10/25(火) 17:03:01

>>481
未踏は少数派ですからな。漏れの時は2000-2003合同でそれなり関係者がいたが。
昨日はIPAのえらい人に捕まってあんまし食えんかった。しくしく…

>>484-485
漏れはブートローダーなんて枝葉な部分に労力を割くのは
もったいないと考えとるので、ネタ扱いした訳ですよ。
実験としてはまあおもろいけど、実用性が？だし。

という意味ではCで書くつーのは正しい道だと思いますよ。
ただサイズの問題があるので、そのへん考慮しないとねえということで。

しかし、ブートローダーを枝葉とか言ってるとそっち方面の人に怒られそうな
気がするな。

**484** · 2005/10/25(火) 18:06:21

>>486
ブートローダーに拘ってるわけじゃないですよ。
ブートローダーを何で書こうがOS自体の機能が増えるわけでなし。

>>480
＞x86なコードに落とす手間を考えると、それほどメリットないべ。
AOTの確立自体がメリットだと考えています。
原理的にはCooSに限らずx86汎用で使えるわけですし。
（ブートローダーをAOTで書いたら汎用という意味ではないので念のため）

AOTよりHotSpotみたいにJITを極めた方が有利というのは、
技術的な難しさと天秤に掛けると絵に描いた餅かと。

**ITRON名無しさん** ◆4WD27e3i1o · 2005/10/25(火) 21:05:39

>>484
> 意味のあるなしで言えば

現時点でのCooSをOSと呼ぶには、ちょっとした躊躇いが漏れはあるんだけど、どうよ。
現時点のCooSってOSっていうよりもプリミティブな言語マシンに見えるのな。
だからまあOS云々と反論されても？な気分。
せめてポリシーを持った実行コンテキストの管理はしてくれるくらいにならないとと
思う訳で、それを除けて枝葉に走るのはどんなもんかなー、とかとか。
以下 >>486 と同様。

> OS作りほど筋が悪いことはないかと。

はっはっは。そりゃまーそりゃそうだわな。
一応OSとか言われているものに関わっている自分が笑っちゃイカンか。

>>487
> AOTよりHotSpotみたいにJITを極めた方が有利というのは、
> 技術的な難しさと天秤に掛けると絵に描いた餅かと。

んー? Javaでは HotSpot世代までいかなくてもAOTとJITの差は瞭然だった記憶があるんだけど。
静的に決定しないものが結構あるからね、Javaの場合は。C#の場合は何か違うのかな。

**484** · 2005/10/25(火) 22:03:33

>>488
＞現時点のCooSってOSっていうよりもプリミティブな言語マシンに見えるのな。
＞だからまあOS云々と反論されても？な気分。
自分としてはMSIL処理系として見ていたので、
汎用的に利用価値があるとなると真っ先にAOTが思い浮かんだのです。

＞せめてポリシーを持った実行コンテキストの管理はしてくれるくらいにならないとと
＞思う訳で、それを除けて枝葉に走るのはどんなもんかなー、とかとか。
言語マシンとしてみればAOTは枝葉ですかね。
MSIL処理系としてみればAOTは本命だと思ったのですが。

＞んー? Javaでは HotSpot世代までいかなくてもAOTとJITの差は瞭然だった記憶があるんだけど。
＞静的に決定しないものが結構あるからね、Javaの場合は。C#の場合は何か違うのかな。
Java特有の動的さというのはC/C++に対しての型付けのことでしょうか？
クラスローダの実装が最適化されていないと起動が遅くなったりはするでしょうけど、
実行時の決定的な性能差として影響するというのは聞いたことがなかったです。
HotSpotが実行時に取得する情報というのはプロファイリングなので
型付けの動的さとは全然関係ないしJava特有でも何でもないですね。

何か資料がないと話が発散するだけなので適当に探してみました。
ttp://www.shudo.net/article/Fedora-Core-Expert-200507-GCJ/#performance
商用のAOTコンパイラは蚊帳の外であまり参考にならないかも。

**Be名無しさん** · 2005/10/25(火) 22:48:25

>>489
MINIX3ｷﾀね
次はいよいよ大本命HURD1か？

**Be名無しさん** · 2005/10/25(火) 22:48:59

誤爆ｽﾏｿ

**ITRON名無しさん** ◆4WD27e3i1o · 2005/10/26(水) 18:03:52

>>489
首藤さんの資料ね。
ちょっと古いけど、こっちのほうがCooSスレでは参考になるかも。
http://www.shudo.net/publications/NASDA-200212/ の
http://www.shudo.net/publications/NASDA-200212/slide15.png
http://www.shudo.net/publications/NASDA-200212/slide16.png
辺り。処理系の詳細は説明はないもののC#のデータが入ってるから。

このプレゼンのときに首藤さんも前置きしてましたけれど、
これLinPackだから、AOTが異様に善戦してますね。
聴講者の大多数がシミュレーション屋さんだったので、
これはこれで数値の取り方として悪くはないけど。

> クラスローダの実装が最適化されていないと起動が遅く

言語やVMの問題っていうよりは、プログラミングスタイルというか。
レイヤの分割で Class.forName() を良く使うので、どんなにコアを
AOTで最適化かけても、どうしてもどこかの層がインタプリタ動作に
なって律速orzという。クラスローダがオンデマンドコンパイルとか
考えれば考えるほど、JITのほうがいいじゃんという結論に向かって
いっちゃうという。泥臭い実運用上の話ですよ。
どこで聞いたのだっけかな? JTRON界隈か、JavaOS界隈か。
Googleに聞いてみたけど、5年以上前の話はさすがにもう残ってないみたい。

MSILではAOTが本命なのかぁ。

**484** · 2005/10/26(水) 18:38:46

>>492
えーとごめんなさい。性能論争は望んでいません。
興味があったのは、CooSのために開発された技術を応用して、
実際に使えるのは何かということだけですので。

MSIL関連のサードパーティー技術で、
自分から見て欲しいと思えるのはAOTだっていう話なので、
AOTが欲しい局面では性能が半分でもAOTが欲しいわけなんですよ。
たとえ実装が不完全で運用に制限があっても
ソースを直してでもAOTにしたい案件は多いので。

.NET Frameworkのインスコを客に拒否されたりしたら
今は泣く泣くMFCに戻るしかないって結構ありましたので。

**Be名無しさん** · 2005/10/26(水) 21:49:56

>>492
なんでC#こんなに遅いの？

**ITRON名無しさん** ◆4WD27e3i1o · 2005/10/26(水) 22:16:44

>>494
知らん。隣のオバサン的無責任さで想像すると、こんなことは言えるのかも
しれない。

まだJITがこなれていないってことなのかもしれない。
確かJavaからの移植だったはずなので、多次元配列ではなくてジャグ配列を使っているはず。このことでC#の実力を反映できていないのかもしれない。
CLR(CLIもか?)では配列型はCLRが動的に生成するという仕様だったはず。
その辺りに起因して配列操作の性能でCLRはJavaVMよりオーバヘッドが
あるのかもしれない。

今評価すると、また違った数値になるだろうね。もう3年も前の資料だから。

**Be名無しさん** · 2005/11/06(日) 15:08:22

**957** ◆KhjEefLZMk · 2005/11/14(月) 15:35:37

ぐは、驚愕の事実を確認。

どうやらVS.NETに「Windows以外禁止条項」はない。
つまりVCのライブラリが含まれていても問題ないってこと。
＃EULAのあの一文はなんなんだろう。。。

サポートに聞いたので間違いありません。
二カ所に聞いたけど、最初の人は「お客様のご自由にどうぞ」と言ってた。
次のサポートの人は、「禁止されてはいないが、
そもそもサポート外なので許諾されているとは言えない」らしい。

ということは、あとは実行ファイルに取り込まれているライブラリのコード断片がどう影響するかだけど、
「Windows用アプリを特別視して許諾する」という条項がないからWinアプリと同じだと見なせて、
MSがWinアプリにライブラリ断片を理由に成果物に制限を掛けることはできないだろう。

ということで、
作った基礎ルーチンが無駄に。。。orzorzorz
もっと早く聞いておけば良かった…。

これでVC++でも作りやすくなるね。

**Be名無しさん** · 2005/11/14(月) 23:12:16

よかったじゃん