【C】Poneytail(仮称)OSスレッド01【未踏】
とりあえずソース公開を特別視して身構えてることは分かった。
そんな相手を説得しても無駄なのはみんな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という選択肢はスジが悪い(速度もメモリ効率も
あんまし上がらない)というのは、巷で割と良く言われていること
なのでわん。
そうじゃねーぞと言える何かがないと、頑張るだけの意味ないよね。
まあネタだっていうなら、それはそれでありか。 ぶっちゃけ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への移行を進めていたり。これも大変そうです。
まあ何かあればこちらに書き込もうとは思ってます。
このスレが無事(?)なのも皆様のおかげですし、本年もなにとぞよろしくお願いいたします。
2006年元旦 Kさんがなにやらよさげなものを書かれたときにアレですが、
修士論文がようやくできたので公開することにしました。
http://www.coos.jp/articles/thesis.pdf
まぁ絶対評価ではぜんぜん納得できていませんが、
状況とかを振り返れば結構書けた方かなと思います。
#そもそもOSが完成してないのに論文を完成と思うわけがない。
ちと恥ずかしいですが、興味のある方は読んでみてください。
あと、2/16に大阪の学会で発表をします。(トップからリンク有り。)
アカデミック縛りがあるのでOS開発という視点では?かもしれませんが
こちらもついでに報告しておきます。ただ、学会員じゃないとお金掛かるので
C/Pについては言及を避けたいと思います(^^; >>507
修論乙。
一応、うちの研究室もOS風味なので、
行く人がいればどんな話だったか聞いておきたい。 >>509
(論文・修論で開発進まず、)あんまり変わってない上に
どうも学術主眼に話をするのは苦手なので、
あんまりクオリティ高くないかも…。
期待しないで来ていただければ嬉しいです。
>>510
各章の扉ページに無意味な絵がある論文は珍しいと思います(笑) 発表終わった
「機械語どうすんだ」って突っ込まれた〜
パワポは戻ったら公開します >>516,517
お恥ずかしい限りですが全然進んでません。
就職準備に加えワークショップへの参加で時間全部つぶれてます。
#まだ公開されてないみたいなので名言はしませんが。
もうここ数ヶ月同じネタで発表し続けているので、いい加減開発に戻りたいです…。 近況報告。
3/22-25で北京で開かれるMicrosoft Research AsiaのTheme Workshop 2006というのに出てきます。
30分の持ち時間で研究報告。内容的には前回の研究会からあまり変わってません。
MSRA-TW06: http://research.microsoft.com/asia/ur/workshop06/
でも明後日くらいに出発なのにまだspeakersもpresentationsも"Will provide later!"って…。
予定では24日の午後のはずなんですが。行って何もなかったらどうしよう。
英語とかも超下手なのでもういっぱいいっぱいです。
つか街中で英語すら通じなかったらどうしよう。。。 安心していいよ.北京は空港も町中もろくに英語通じないから. >>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がちょっとやばいw メインマシンにドットネット入れたくないからサブマシンにドットネットアプリ専用OSとして入れたいな
まあそういう表現も間違ってはいないのですが、
別にvirtualにするわけではないです。 Windows上の.NET VM上の.NETアプリ
が
COOS上の.NETアプリ
と直で動くってこと?
早く使わせろー 途中で投げ出さないでこのペースで行ってくれれば
すごくいい感じに >>542
あーWikiは死んでると思います
どうもホスティングいまいちだったので解約しました
WWWは生きてるはず〜
>>546
たまに進めてるんですが、やっぱり毎日数時間みたいなのは無理ですね。。。 .NETアプリ、入力フォーム部分はWindowsの部品を使っているんだと思ってたけど
Windowsなしでも動くんだ。 お久しぶりです。
最近はホント時間取れてないです。申し訳ない。
やっぱり仕事終わったあとは複雑なことは無理ですね。。。
ただずっとこのままなのは寂しいので、社会人二年目からはよく考えたいです。
とりあえず現状報告でした。 勤め人が片手間で開発するのは厳しいですよ、
技術を理解してくれる所に移って、昼間動けるようになるのが理想ですが、
日本だとそういう物好きな会社は少ないので、難しい所ですな。
>>557
真実かは分からないですが、一年目ってスケジューリングしにくくて余計に時間がないっす。
でも非常に近い分野に従事してるし、いまのとこで知見を広げるのも悪くないと思ってます。
>>558
一応CooSで得た経験が役に立ちまくっているので、超間接的に社会に貢献…じゃダメかな〜w 来てないと思いますが。
30日本以来あんましみかけないねえ。
>>559
Linuxカーネル関係ですかね。
この手の経験ってかなり限られた分野でしか役に立たないので、
良い所に就職したなぁと思いますよ。 >>563
英語苦手w
>>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作れたりもするのかな? ∧_∧
( ・∀・) | | ガッ
と ) | |
Y /ノ 人
/ ) < >__Λ∩
_/し' //. V`Д´)/ ←>>193
(_フ彡 / 誰でも簡単にネットで稼げる方法など
参考までに、
⇒ 『半藤のブブイウイウレレ』 というサイトで見ることができます。
グーグル検索⇒『半藤のブブイウイウレレ』
3X3L7V87K8 ☆ 私たち日本人の、日本国憲法を改正しましょう。現在、
衆議員と参議院の両院で、改憲議員が3分の2を超えております。
『憲法改正国民投票法』、でググってみてください。国会の発議は
すでに可能です。平和は勝ち取るものです。お願い致します。☆☆