【C】Poneytail(仮称)OSスレッド01【未踏】
なにはともあれ、注目していただけるのは嬉しいことです。
反論というわけではないですが、一応コメント。
>みんなでいじる
CooSの場合、みんなでいじるとしてもそれはC#の部分にしたいので、
C#を動かすことを頑張っている現状ではあまり考えていません。
>放置には自由なライセンスを／ライセンスが強すぎ
放置するときに考えますが、放置するときにCooSがValuableであればオープンにするかもしれません。
現状のライセンスは強く僕の権利を留保する形になっていますが、当面は変える気もありません。
CooSをダウンロードして試してみるのに不都合がある、というのなら速攻変えますが、今は別に問題ないからです。
基本的に個人の趣味なので、みんなのために公開しろ、って論調はぴんときません。
CooSを公共の福祉に役立てることは本望ですが、CooSの開発を譲り渡すのには抵抗があります。
オープンにすればCooSコミュニティの中で"王様"になれるかもしれませんが、さっぱり興味がありません。
これは幼稚な動機かもしれませんが、OSの開発では重要だと思います。
長くモチベーションを維持することが最優先で、短期的利益と引き換えに飽きてしまうのが一番ダメじゃないかなあ。
それと税金投入だからオープンの話がありますが、ありゃナンセンスです。
申請の際にわざわざ「オープン条項」のないPMを選びましたし・・・。
お金を理由にオープン化させたいなら追加で払ってください。
１０年くらい生活できるだけもらって新たに作り直しますｗ
んで、MYCOMにメールしてみた。 追加。放置の話は「いつか」であって、「あと何年」という意味はないので念のため。いまは放置する気ないよん。 まつもとさんの意見は、放り投げるつもりであるという誤解に基づいているように読めますけど、違うかな。
誤解に基づく意見に何を反論しても、何ら生産的ではないような気がします。
「苦言たれる前に、ウラ取りはしようね」と優しく微笑みかければ十分じゃないですか?
まつもとさんより偉い紙がゴロゴロいる微笑ましいスレはここですか？ >>361
ちょっとひっぱり過ぎかもしれませんね。
件は誤解というのは了解していますが、
それにしてもオープン化の要求が理不尽だったのでコメントしておこうかな、、、と。
あとはライセンスについて意見を書いたことがなかったのでついでに。
まあこの話はとりあえずここまでにしますか～。まったりが一番だね。 別に開発が継続されていれば本人も誤解だったと気づくというだけの話。 まつもとさんに文句言える偉い人がこのスレにはいっぱいいるようで（笑） >もちろん誰にも見向きもされない可能性はありますが、
>そうでない可能性をあらかじめ否定するのももったいない。
ソースを公開しても誰にも見向きもされない段階らしい。
ソース公開しておいても、バイナリ落として使う人ばっかりで、
中身いじる人は天然記念物並みに貴重でつよ。
つーかソースだけ転がしておいて、使いたけりゃ自分でビルドしてねなんて書いておくと、
まず誰も使ってくれないからなあ…
ソースの公開が見向きされるように今まで通り頑張りまつ。
＃というか一部は公開してんだけどな・・・。 Matzはモルモンの宣教師として神を説いているよ（マジ >>370
ここでうだうだ苦言をたれるより、ITRON名無しさん氏が言われているように、
一度Matz氏へつっこみを入れてきたらどうだろうか？
お互いに一方的な発言を行っても、説得力にかけるように思う。 いやいや、またーり、またーり。
Matzにっきに追記も入ったことだし。
ここへのリンクもコメントに張られたみたいだし。
これ以上責めてもメリットは無いと思うよ。 >>372
激しく同感。でも>>373ということもあり自制してたというのがホントのところです。
さらに感情的に言えば、向こうに"召喚される"というのはとても納得できない。
実際のところ、追記の「～という情報あり」という他人事みたいな表現に顕著なように、
まつもとさんの日記は日記以上ではないようなので、日記に正しさを求めるのは野暮かなーと。
MYCOMの記事は訂正されましたし、あとは放っておこうと思います。 公共の金が使われたのだから、
公共の役に立つ形で終わらせて欲しいというのは、割と普通の意識でしょう。
作者もそういう形で役立つことを望んでるみたいですし (>>359)
Matz は熱心な OpenSource 布教者で噛み付き癖があるから、
不正確な記事と感性の違いが起因して、あんなことを言ったのでしょう。
実用度が低い状態で投げるなら、利益を還元する一例として OSS 化は悪くないから。
つーのが顛末か。
正直、税金を使われた側としては、
> 申請の際にわざわざ「オープン条項」のないPMを選びましたし
というのは理解したが、還元されないなら、かなり馬鹿馬鹿しいな。
習得したスキルが、今後変わった形で公共に益することになったとしてもだ。
せめて、還元する努力くらい見せて欲しいといったところ。オープンソースに拘る必要なないから。
でなきゃ、個人のオナニー代に使われただけじゃん。 そろそろまとまりそうですね。
>>377
はい、全面的に、特に
>還元されないなら、かなり馬鹿馬鹿しいな。
ということについても、完全に同意です。
しかし、このことは申請以前から分かっていたことです。
僕は簡潔明瞭なのが好きなので「個人の趣味」と言い切っていますが、
美辞麗句を用いたところで、立ち上げから1年のOSが社会に還元できるようになるわけがない。
それを誤魔化すために安易に「普及のために今後も努力」なんて言い切る方が無責任だと僕は思うのです。
これは採択審査のときにも明確に説明しています。
このスレッドの初期にも同様の議論があり、
そんときは「まあ面白いからやるだけやれば？」という感じの結論だったかな。
ただ、「実用にならないのが当たり前」ということを免罪符にするのは心苦しいので、
当初からサイトを（まあ元税金から）取得・運営し、インターネットでの情報公開に努めていました。
特にこのような完全に開かれ場で、開発者自身が明確に返答しているのは珍しいと思います。
そしてこれが、私が思いついた、社会への現時点で可能な還元の方法です。
続きます。 うーん、続けられなかった。
未踏スレでCooS叩かれてますね。ちとかなしぃ。
HyperEst*の方は（すでに述べていますが）僕も凄いと思ったので、自然な流れだと思います。
で、よく分からないし、問題だと思うのは、その他大勢の雲隠れプロジェクトがまったく批判されないことです。
僕は未踏に対してかなり正直に接したと思うのですが、その結果が批判の矢面に立たされることで、
雲隠れした方にはなんの批判も、コメントすら取り上げられない。これはまつもとさんの件でも明らかです。
＃CooSに対する批判が嫌だ、むかつく、という意味ではないことをぜひ理解してください。
これでは、ゲームの理論を持ち出すまでもなく、
メディアに取り上げる価値もないくらいに適当にお茶を濁してさっさととんずらするのが一番利口です。
この問題は往々にして各プロジェクトへの文句になりがちですが、
各々の開発者が悪いとするよりも、未踏のシステムが抱える問題として議論するべきです。
そして僕は、各プロジェクトは"強制的"に、"不特定多数"の批判を受けられるような窓口を用意するべきだと思います。
＃んでCooSでは批判"も"受けるためにココがある。
最後に。
たしかに未踏はシステム的にまだ弱いと思いますが、
一番の問題はIPAがそれを是正する力がいまいちないような・・・。
IPAって未踏への批判とかってどうやって認識してるんですかね。
いじょう。 開発者さん、
きっと、オープンソース推進派からの理不尽な要求とかいぱーい来るだろうけど、
絶対に貴重な成果をオープンソースにしてはいけないよ。
応援してます。頑張れ。 déjà vu
NWSOS公開当時を見ているようだ・・・ >>379
>で、よく分からないし、問題だと思うのは、その他大勢の雲隠れプロジェクトがまったく批判されないことです。
は、全く批判されないというよりも、全体に対して批判的なのでそう見えているだけなのではないでしょうか。
また、適当にお茶を濁してとんずらするのが一番利口というのははたしてそうでしょうか？
民間企業でもいくら資金をつぎ込んでも成果の上がらないプロジェクトを抱えており、そういうプロジェクトは腐るほどあるというのはみなさん知っていると思います。
それに、数百万という資金の上、1年程度の期間では成果を上げるのは難しいのも知っていると思います。
そういう立場を理解した上で未踏に批判的なのは、プロジェクトが暗い部屋の中で生まれて外に出ずにそのまま死んでゆくという絵が見えるからではないでしょうか。
闇から闇へ、そういうい行動をとっている人に次の機会があるとは思えません。
未踏につぎ込んだ資金を回収してほしい、そう望んでいる人は少数派であり、多くの人が未踏に期待している事は「優秀な人材を発掘してほしい」「新しいアイデアを見せてほしい」等、明るい未来を夢見させて欲しい、そういうものだと私は思っています。
成果物の直接的な社会への還元は最初から期待していません。
そもそも「未踏」というテーマに挑んでいるのですから、失敗したとしても次に繋がる種を感じさせてくれるなら批判も少ないでしょう。
現状の批判は、未踏事業のプロジェクト全体があまりに不透明すぎ、内容に対して批判もできない事へだと思います。
税金が投入されているのですから、情報公開で社会に還元して成功の手助けや失敗の防止に役立てる。そういうのはあってもいいのではないでしょうか。
趣味だろうが事業だろうが、無駄に税金が使われるというのは避けて頂きたいです。
批判を受け入れる窓口をIPXが用意して全体を整えていくという意見は私も賛成です。
ですが、それが始まるのを待つのではなく、まずは各々が行動に出て欲しいです。学校ではないのですから。
外部とコミュニケーションをとっておられる957さんに対して的外れな意見が多いですが以上です。長文失礼しました。
CooSには期待しています。では。 オープンソースにするのはいつでもできるが、
一度オープンになったものは再びクローズにはできない。
オープンソースにすると、ソフトウェアの資産価値はゼロ以下に下がり、
それはもはや資産ではなく負債になる。
私も応援しています。
957さん、せっかく作り上げた貴重な知的財産をオープンソースにしないでね。 >>379
> たしかに未踏はシステム的にまだ弱いと思いますが、
それでも初年度頃に比べれば細かいところではずいぶん詰めが進んだと
思います。あの頃は完全に手探りでした。
実質の開発期間もとんでもなく短かったですし。
>>382
> 闇から闇へ、そういうい行動をとっている人に
まあビジネスの世界ではそうですけれどね。アカデミックの場合は割と雲隠れが許されます。
学生さんの場合は、就職でリセット効きますしね。(957氏のことじゃないですよ念のため)
> 未踏につぎ込んだ資金を回収してほしい、そう望んでいる人は少数派
今年からIPAは「事業化情報交換会」という採択事業のビジネスサポートを始めています。
OSS事業の採択者にもお誘いが来るのですが、未踏採択者にも来ます。
ビジネスまでの距離が遠いからこその未踏事業だと思うのですが…。
この辺りは当のIPA自身も苦悩しているのでは。
>>383
> オープンソースにすると、ソフトウェアの資産価値はゼロ以下
んなこたぁないです。 >> オープンソースにすると、ソフトウェアの資産価値はゼロ以下
>んなこたぁないです。
いいえ、OSSは間違いなく負債です。
OSSといえども知財であることは間違いありませんが、それを持っていてもお金は入りません。
逆に、著作者であるというだけで無理やりサポートさせられます。
外人からは意味不明かつ失礼な要求メールが次々と送られてきます。
日本人からの要求を無視すると２ｃｈで叩かれ、評判の悪い噂を流されます。
みんなで開発を手伝っていいものを作ろう・・・など妄想もいいところです。
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とは別の形で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で公開しろと主張する奴に限って、コードを１行も書かないんだろうなあ。
自分で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
さすがにムリぽｗ
>>462
それは可能だと思います。もちろんOS+.NETなのですぐに実現できるわけではないですが…。 >>463
おめ。名前だけで特にメリットが無いのがあれだが。
暇なので展示を見に行くかのう。
>>463
レスどうもです。
やはり.NETのアプリケーションを動かせる段階というのは
その他OSの基本的な機能が実装されてからになるのでしょうか？
.NET Frameworkのアプリを動かすだけなら
現時点ではqemuに別のWindowsOSを入れてそこに.NET Frameworkランタイムを入れて
.NET Framework製アプリケーションを動かしたほうが現実的でしょうか？ > とりあえずもう晒されるのは勘弁してほしいなぁ。
引きこもるか、晒されるか、どちらかしか道は無い。
未踏採択者は定期的に近況報告を求められるので、
引きこもるほうが難しい。
資料作ってない～。ひー。
>>464
ありが㌧。
スーパーも恥ずかしいし、クリ"エータ"も恥ずかしいです…。
展示は特にしない予定なんだけど、ダメ？
ここ一ヶ月は何も進んでないしなあ。忙しすぎ。
>>465
CooSでは.NETが基本レイヤなので、むしろ「基本的な機能」が.NET関係だと言えます。
実用的な解であれば、おっしゃるとおりWindowsか、強いていえばLinux+Monoだと思います。
>>466
また色々言われたらめんどーって思ってます。。。
つーかスーパー（ｒｙ）になっちゃったからもう未踏応募できない～。かなしー。 まだほとんど出来てないのに、スーパークリエータで応募出来ないのか。
どういう制度だよ。 人材発掘が目的だとすればスーパーなひとの再採用は不要だと思いますが、
スーパークリエータのがノンスーパーよりも権利を制限されるってのはどう考えても謎ですね。 スーパーになった奴は、希望すれば自動で継続とかにすればいいのに。 未踏の後は次世代があります、って話じゃないの?
確か去年か一昨年、そういう例あったよね。
次世代で目処がつければマッチングファンドとか。
って、釣られておいてなんですが、そろそろ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的ネタにはなるかもしれないけどｗ
>>480
そーなのかなぁ。
確かにCになると富豪的スタイルになっている感は否めない。
それにくわえて、手を抜いた部分をコンパイラが仕上げている感じもある。
ま、CローダはOS勉強する人に役に立つかなあと言うのも目的です。
アセンブラが王道なんだろうけど、やっぱアルゴリズムは理解しにくいので。 JITの応用でPreJIT(AOT)もできることを示す意味があるかと コード書きに夢中になってレセプション行きそびれたorz。
タダ飯食いながら957に粘着しようとおもっていたのだが。
C#やJavaでAOTという選択肢はスジが悪い(速度もメモリ効率も
あんまし上がらない)というのは、巷で割と良く言われていること
なのでわん。
そうじゃねーぞと言える何かがないと、頑張るだけの意味ないよね。
まあネタだっていうなら、それはそれでありか。 ぶっちゃけOSをネタから引き上げるのが一番難しいから、
意味のあるなしで言えばOS作りほど筋が悪いことはないかと。 誤解を招きそうなので補足。
Coosに水を差すつもりは毛頭ありません。
現実的な意味を取り沙汰するのに違和感を感じただけっす。
技術的探究心は大いに結構、それこそ未踏の精神では。 >>481
未踏は少数派ですからな。漏れの時は2000-2003合同でそれなり関係者がいたが。
昨日はIPAのえらい人に捕まってあんまし食えんかった。しくしく…
>>484-485
漏れはブートローダーなんて枝葉な部分に労力を割くのは
もったいないと考えとるので、ネタ扱いした訳ですよ。
実験としてはまあおもろいけど、実用性が？だし。
という意味ではCで書くつーのは正しい道だと思いますよ。
ただサイズの問題があるので、そのへん考慮しないとねえということで。
しかし、ブートローダーを枝葉とか言ってるとそっち方面の人に怒られそうな
気がするな。
>>486
ブートローダーに拘ってるわけじゃないですよ。
ブートローダーを何で書こうがOS自体の機能が増えるわけでなし。
>>480
＞x86なコードに落とす手間を考えると、それほどメリットないべ。
AOTの確立自体がメリットだと考えています。
原理的にはCooSに限らずx86汎用で使えるわけですし。
（ブートローダーをAOTで書いたら汎用という意味ではないので念のため）
AOTよりHotSpotみたいにJITを極めた方が有利というのは、
技術的な難しさと天秤に掛けると絵に描いた餅かと。 >>484
> 意味のあるなしで言えば
現時点でのCooSをOSと呼ぶには、ちょっとした躊躇いが漏れはあるんだけど、どうよ。
現時点のCooSってOSっていうよりもプリミティブな言語マシンに見えるのな。
だからまあOS云々と反論されても？な気分。
せめてポリシーを持った実行コンテキストの管理はしてくれるくらいにならないとと
思う訳で、それを除けて枝葉に走るのはどんなもんかなー、とかとか。
以下 >>486 と同様。
> OS作りほど筋が悪いことはないかと。
はっはっは。そりゃまーそりゃそうだわな。
一応OSとか言われているものに関わっている自分が笑っちゃイカンか。
>>487
> AOTよりHotSpotみたいにJITを極めた方が有利というのは、
> 技術的な難しさと天秤に掛けると絵に描いた餅かと。
んー? Javaでは HotSpot世代までいかなくてもAOTとJITの差は瞭然だった記憶があるんだけど。
静的に決定しないものが結構あるからね、Javaの場合は。C#の場合は何か違うのかな。 >>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コンパイラは蚊帳の外であまり参考にならないかも。 >>489
MINIX3ｷﾀね
次はいよいよ大本命HURD1か？ >>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が本命なのかぁ。 >>492
えーとごめんなさい。性能論争は望んでいません。
興味があったのは、CooSのために開発された技術を応用して、
実際に使えるのは何かということだけですので。
MSIL関連のサードパーティー技術で、
自分から見て欲しいと思えるのはAOTだっていう話なので、
AOTが欲しい局面では性能が半分でもAOTが欲しいわけなんですよ。
たとえ実装が不完全で運用に制限があっても
ソースを直してでもAOTにしたい案件は多いので。
.NET Frameworkのインスコを客に拒否されたりしたら
今は泣く泣くMFCに戻るしかないって結構ありましたので。 >>494
知らん。隣のオバサン的無責任さで想像すると、こんなことは言えるのかも
しれない。
まだJITがこなれていないってことなのかもしれない。
確かJavaからの移植だったはずなので、多次元配列ではなくてジャグ配列を使っているはず。このことでC#の実力を反映できていないのかもしれない。
CLR(CLIもか?)では配列型はCLRが動的に生成するという仕様だったはず。
その辺りに起因して配列操作の性能でCLRはJavaVMよりオーバヘッドが
あるのかもしれない。
今評価すると、また違った数値になるだろうね。もう3年も前の資料だから。
ぐは、驚愕の事実を確認。
どうやらVS.NETに「Windows以外禁止条項」はない。
つまりVCのライブラリが含まれていても問題ないってこと。
＃EULAのあの一文はなんなんだろう。。。
サポートに聞いたので間違いありません。
二カ所に聞いたけど、最初の人は「お客様のご自由にどうぞ」と言ってた。
次のサポートの人は、「禁止されてはいないが、
そもそもサポート外なので許諾されているとは言えない」らしい。
ということは、あとは実行ファイルに取り込まれているライブラリのコード断片がどう影響するかだけど、
「Windows用アプリを特別視して許諾する」という条項がないからWinアプリと同じだと見なせて、
MSがWinアプリにライブラリ断片を理由に成果物に制限を掛けることはできないだろう。
ということで、
作った基礎ルーチンが無駄に。。。orzorzorz
もっと早く聞いておけば良かった…。
これでVC++でも作りやすくなるね。 ttp://channel9.msdn.com/Showpost.aspx?postid=141858 >>501
うぉ。貼り付けさんくすです。
ちと研究活動で忙しいので、見たら感想でも書きますね。 お久しぶりです。
あけましておめでとうございます。
最近はJITコンパイル周りをいろいろやってたんですが、面白くないのに道のりだけは長くて。。。
あとは論文書きと修論書きと、開発そのものはあんまり・・・です。
あとあと、ついでにVS.NET2005への移行を進めていたり。これも大変そうです。
まあ何かあればこちらに書き込もうとは思ってます。
このスレが無事（？）なのも皆様のおかげですし、本年もなにとぞよろしくお願いいたします。
２００６年元旦 Ｋさんがなにやらよさげなものを書かれたときにアレですが、
修士論文がようやくできたので公開することにしました。
http://www.coos.jp/articles/thesis.pdf
まぁ絶対評価ではぜんぜん納得できていませんが、
状況とかを振り返れば結構書けた方かなと思います。
＃そもそもＯＳが完成してないのに論文を完成と思うわけがない。
ちと恥ずかしいですが、興味のある方は読んでみてください。
あと、２／１６に大阪の学会で発表をします。（トップからリンク有り。）
アカデミック縛りがあるのでＯＳ開発という視点では？かもしれませんが
こちらもついでに報告しておきます。ただ、学会員じゃないとお金掛かるので
C/Pについては言及を避けたいと思います（＾＾； >>507
修論乙。
一応、うちの研究室もOS風味なので、
行く人がいればどんな話だったか聞いておきたい。 >>509
（論文・修論で開発進まず、）あんまり変わってない上に
どうも学術主眼に話をするのは苦手なので、
あんまりクオリティ高くないかも…。
期待しないで来ていただければ嬉しいです。
>>510
各章の扉ページに無意味な絵がある論文は珍しいと思います（笑） 発表終わった
「機械語どうすんだ」って突っ込まれた～
パワポは戻ったら公開します >>516,517
お恥ずかしい限りですが全然進んでません。
就職準備に加えワークショップへの参加で時間全部つぶれてます。
＃まだ公開されてないみたいなので名言はしませんが。
もうここ数ヶ月同じネタで発表し続けているので、いい加減開発に戻りたいです…。 近況報告。
3/22-25で北京で開かれるMicrosoft Research AsiaのTheme Workshop 2006というのに出てきます。
３０分の持ち時間で研究報告。内容的には前回の研究会からあまり変わってません。
MSRA-TW06: http://research.microsoft.com/asia/ur/workshop06/
でも明後日くらいに出発なのにまだspeakersもpresentationsも"Will provide later!"って…。
予定では２４日の午後のはずなんですが。行って何もなかったらどうしよう。
英語とかも超下手なのでもういっぱいいっぱいです。
つか街中で英語すら通じなかったらどうしよう。。。 安心していいよ．北京は空港も町中もろくに英語通じないから． >>520
ﾏｼﾞｽｶorz
>>521
MSに発表というよりはMS主催の研究会で発表が正しいです。
ただ、同じ参加者としてMS関係者もたくさんいるので、
そういう意味では「MSに発表」というのもそれほど間違いではないかも。 ついさっき終了。もう骨って感じでした
原稿つきって緊張するもんなんですね。汗だくです。
とりあえずステージでかっっっ！
http://www.coos.jp/stage.jpg
これは初日のなんですが、今日もステージは一緒。
ただ、観客が少ないのを予想してか席が全部机付きになって、
人も減ってました。（写真のProbert博士はある意味メインゲスト。）
とりあえず眠たいけど寝ても仕方ないのでまた戻ろう。
ではまたﾉｼ とりあえずWindows Formsが使えればシェルつくったる 今どの辺ですか？そろそろ使えますか？
GUIありの推奨動作環境はどれくらいですか？ そろそろ会社生活に慣れてきたので開発再開してるとこです。
C#2.0などで規格が新しくなっているのでそれへの対応をしてます。
＃それに対応しないとVS2005とか使えないし。。。
昨年度の後半にしたかったけど、学会やらで後回しにしちゃった分ですね。 Javaを意識した構造に作り替えたところです
Javaも考慮することで分離が良くなるかなあ、と。
だいたい出来たのでいまC#で（また）インタープリタ作ってるところ
ジェネリクスとかどうなるんだろうなあ、と思っています
ただ、FF3がちょっとやばいｗ メインマシンにドットネット入れたくないからサブマシンにドットネットアプリ専用OSとして入れたいな
まあそういう表現も間違ってはいないのですが、
別にvirtualにするわけではないです。 Windows上の.NET VM上の.NETアプリ
が
COOS上の.NETアプリ
と直で動くってこと？
早く使わせろー 途中で投げ出さないでこのペースで行ってくれれば
すごくいい感じに >>542
あーWikiは死んでると思います
どうもホスティングいまいちだったので解約しました
WWWは生きてるはず～
>>546
たまに進めてるんですが、やっぱり毎日数時間みたいなのは無理ですね。。。 .NETアプリ、入力フォーム部分はWindowsの部品を使っているんだと思ってたけど
Windowsなしでも動くんだ。 お久しぶりです。
最近はホント時間取れてないです。申し訳ない。
やっぱり仕事終わったあとは複雑なことは無理ですね。。。
ただずっとこのままなのは寂しいので、社会人二年目からはよく考えたいです。
とりあえず現状報告でした。 勤め人が片手間で開発するのは厳しいですよ、
技術を理解してくれる所に移って、昼間動けるようになるのが理想ですが、
日本だとそういう物好きな会社は少ないので、難しい所ですな。
>>557
真実かは分からないですが、一年目ってスケジューリングしにくくて余計に時間がないっす。
でも非常に近い分野に従事してるし、いまのとこで知見を広げるのも悪くないと思ってます。
>>558
一応CooSで得た経験が役に立ちまくっているので、超間接的に社会に貢献…じゃダメかな～ｗ 来てないと思いますが。
30日本以来あんましみかけないねえ。
>>559
Linuxカーネル関係ですかね。
この手の経験ってかなり限られた分野でしか役に立たないので、
良い所に就職したなぁと思いますよ。 >>563
英語苦手ｗ
>>564-565
ご期待に添えていなくて申し訳ない・・・
最近はSmalltalkとかSqueakの方針にしたほうが良いのかなあとも思ったり。
なんつーか.NET Frameworkの発展が速すぎて、着いていく限界を感じますね。。。 >>566
MSへ転職して、Singularity ver2 を開発すれば全ては解決 >>568
やー、Singuarityは
"Singularity Version 1.0 is complete. We're moving our
research forward to the development of Singularity V2.0."
らしいですからねえ。こんな研究を着々とやれちゃうのがすごい。 発展早いか？
CLRは実質2.0でしばらくとまりそうだし、
MSILの仕様も変わってないだろ。
むしろ.NETは発展がなすぎて将来性がないって言う印象だが >>569
おっしゃる通りCLRの規格はジェネリクスの大きな変更以降止まっている感じがします。
ただ、代わりにクラスライブラリの規模がでかくなってて、現状の開発方法でそれをキャッチアップできるのか・・・。
>>570-571
仕事と平行してやれてるってすごいと思います。
最近2ch系OSがしずかになってしまって、ちょっともったいないですね。 まあ、まともな社会人ならこれくらい出来ないとまずいだろう。
風呂敷広げない所は好感が持てますな。
自分の技術力が把握できてるからだろうけど。
まぁまともな社会人なら趣味でOS開発する時間なんてないだろう。
>>572
クラスライブラリはMonoを使用するでなかったの？ >>576
Monoもいくらかの部分がLinux依存なので、動的にパッチしてます。
最近まったく手を入れてないんで、中身どうなっているんだろう・・・ 最近は
・JITコンパイラの開発 → 下のと合わせてやる
・リフレクションの整備 → ジェネリクスの仕様に合わせて拡張中
ですねぇ。
自分でいうのもなんなんですが、やってることがOSっぽくなくて辛い。。。 ライブラリは、Silverlightに照準を合わせれば？
そうすれば、.NETより規模が小さい。
Moonlightとかあるし。 辛いって感じるような作業は、やらなくていいよ。
やりたいことやったほうが、楽しくできるでしょ。 すいみません完全に見過ごしてました。。。
九月末に引っ越しまして、一時ネット隔離されてたもんで。
>>580
Silverlightの中までよく知らないんですが、
ライブラリはサブセットなんですかね？？
>>581
そうですね。
実は最初に言った引っ越しで通勤時間が短くなりまして、前より開発が進むようになってます。
やっぱり仕事して脳内キャッシュからパージされちゃうと、元に戻すまでに一定コスト掛かるんですねえ。
いままでは「前回の自分にリストアする」だけでいっぱいいっぱいだったので、それに比べると全然よいです。
以前に書いてるかもしれませんが、最近もずっとジェネリクスのインプリではまりにはまってます。
.NETの内部構造と、リフレクションにどう見せるか、というのの摺り合わせが上手くいかず。。。
脳内キャッシュの容量が足りないようなので、どうやって開発したらいいかと考えながらぼちぼちやってるところです。 >>583
小物しか作る時間ないんですよね。
・・という理由もあり、なによりMS-ResearchのSingularityが
ソースコード公開しちゃったしなーってのもあります。
あれと純粋に差別化を図るのは厳しいorz
いっそのこと旗を降ろしたほうがいいかもしれんのだけど、
うーん、勝手ながらOS以外で気分転換したいってのが正直なところです。 ひげはホント成長していくよな
エンジニアって感じだ >>585-586
いちいち他所でゴミの話題を出すな >>584
Singularity改良すればいいじゃん。 CooSとInfernoってスタンスが似てる気がするなぁ テレビは見たい番組だけを録画してから見るから
もう10年以上全くと言っていい程CMを見ていない これってC#で出来てるの？
んじゃVB.NETでOS作れたりもするのかな？ ∧＿∧
（ ・∀・） | | ｶﾞｯ
と ） | |
Ｙ /ノ 人
/ ） < >__Λ∩
＿/し' ／／. Ｖ｀Д´）/ ←>>193
（＿フ彡 / 誰でも簡単にネットで稼げる方法など
参考までに、
⇒ 『半藤のブブイウイウレレ』 というサイトで見ることができます。
グーグル検索⇒『半藤のブブイウイウレレ』
3X3L7V87K8 ☆ 私たち日本人の、日本国憲法を改正しましょう。現在、
衆議員と参議院の両院で、改憲議員が３分の２を超えております。
『憲法改正国民投票法』、でググってみてください。国会の発議は
すでに可能です。平和は勝ち取るものです。お願い致します。☆☆ 
