Anonymous Coward曰く、"1FDのGUI搭載国産OSである、おなじみOSASKがLinuxでコンパイル可能になった。
従来も簡単なアプリケーションのコンパイルはできたが、OS本体のビルドに成功したのは今回が初めて。現在はRed Hat Linuxでコンパイルしたnaskが、うまく動作しないという不具合報告があるが、それ以外は問題なく動いているようだ。
コンパイルには、askaやnask,naskcnv0などの各種開発ツールが必要。開発ツールのインストール方法も、Wikiに書かれている。"
メモリレスアーキテクチャって何？ (スコア:2)
web等を見ても、
勢いがあるのは良くわかったのですが、内容が？？？なのです。
作者の主張としては、
メモリレスアーキテクチャを採用しているので
OS側のメモリ管理機構が不要、だからシンプルにOSが実装できる。
シンプルに実装されたOSだから、高速に動くのだ！
というような話だったと思うのですが
本当にメモリ管理をまったく行っていないのですかねぇ。
DOSのころにあったオーバレイ機能のような
いわゆる仮想記憶の低レベルな実装との違いが、
よく解らないのです。
どなたか詳細をご存知の方いらっしゃいますか？
Re:メモリレスアーキテクチャって何？ (スコア:1)
もしこのOSがシンプルに実装されたから高速という
考えをもとに作られているとすれば、いづれ破たんしそうな予感がします。
たとえばRISCチップも昔はシンプルで高速がもてはやされましたが、
互換性のため旧インストラクションセットをサポートすることで
徐々にシンプルさが失われ、複雑なものになっていったと思います。
同様に既存のOSも最初はシンプルで高速だったわけですが、
次第に複雑になってしまっているか、互換性を犠牲にしてアーキテクチャを
作り替えざるを得ない状態になっているかのどちらかだと思います。
Re:メモリレスアーキテクチャって何？ (スコア:0)
これは読んだ？
Re:メモリレスアーキテクチャって何？ (スコア:0)
「もうちょっと OS の勉強をしたほうがいいんじゃないかなこの人」
という印象を受けた記憶が。
温故知新なのではなくて、何も知らないところから
スタートしてるという印象が強いんですよね。
言葉は新しいのだけど、コンセプトは別に新しくもなく、
世の中ではすでに捨てられたような技術が散見されますよね。
別の人が書いてた URL を今ざっと読んだけど、
「メモリレス」と謳
Re:メモリレスアーキテクチャって何？ (スコア:0)
・実装メモリ量は増え続ける
・ファイル管理は信頼性が重要視される
という方が今後の流れだと思っているので。
#HDDに16MとかキャッシュRAMが乗っている時代だし
#ファイルIOがネックの時代は終わったと思ってるAC
#(パーソナルユースでは)
Re:メモリレスアーキテクチャって何？ (スコア:0)
でも普段ガベージコレクションのある言語しか使ってないので実はどうでもいいかも。
メモリに名前がついてる? ディレクトリ構造がある? セキュリティー管理ができる? オブジェ
おおっ (スコア:2, 参考になる)
まず、「みんなエミュレーションすれば何だって動くよね」という
むちゃくちゃな発想が素晴らしい。
これは、わかってはいても、なかなか実行できないことですよ。
なにしろその実装には「物凄い体力」が必要ですから。
ASKAというアセンブラを積極的に使っているのも面白いです。
「これで効率追求できるっしょ」ということだと思うのだけど、
これはコンパクトなコードが吐けるだけでも、結構いけそう。
キャッシュに収まれば、肥大したOSどもには決して見えない領域が見えるんじゃないかな。
ただ、エミュレータ部分が大きくなってしまった場合、エミュレータで動かす
アプリケーションの実行時はOSASKカーネル＋エミュレータの重さが
加わった上でアプリケーションを稼働させることになるわけで、
下手をするとOSASKのメリットは激減するという罠もあると。
このへんをどう解決するのか、手腕の見せ所だと思います。
それでも、いつでもどこでもスナップショットが取れるってのはおいしいですね。
デバッグもはかどりそうだし。
メモリレスのアーキテクチャってのは、
要するに「メインメモリはデータキャッシュにすぎん」って意味かな。
64Bitリニアに空間を扱えるOSの研究では、そのポインタの指せる巨大な
アドレス範囲を活かして、OSからファイルシステムから、
ネットワークのむこうのファイルまで、
すべてを巨大な仮想メモリにマッピングしてしまう方式が、
以前から考えられていたと思います。
これを本気でやろうとしてるんでしょう。
これまでの、32Bitより狭い空間ではかなり無理がありそうですが、
何テラバイトものデータを普通にポイントして利用する時代になれば、この概念は生きてきます。
なにしろ、無駄なデータコピーが少なくなる。よって効率も稼げます。
…そうやって考えると、かなり有望な素質のあるOSだと思いますよ。
Re:おおっ(極端な実装の一つとして) (スコア:0)
> まず、「みんなエミュレーションすれば何だって動くよね」という
> むちゃくちゃな発想が素晴らしい。
> これは、わかってはいても、なかなか実行できないことですよ。
> なにしろそ
さらっとサイトを眺めましたが… (スコア:1, すばらしい洞察)
興味をそそらないといえばウソだ．大ウソだ．なんたって目の前の現実から逃避するにはうってつけじゃないか…
はっ？！わたしはいま何を…だめだだめだ
…いやいや，自分に関係なさそうなものでも普段から何気なくチェックしておけば，思わぬ知見がだね…
… … …
だめです．プチ現実逃避の対象としてはヘビーすぎます．やっぱりもっと設計概念の説明とか FAQ とか充実してください～
「理解したけりゃそっちがすこしは努力しなっ」ってことですか？
確かに時々とんちんかんな質問にあって気分を害するかもしれませんが，「自分の仕事・成果を理解してもらう努力」って大切じゃないですか？ それが従来のものとは異なれば異なるほど．
厚かましいお願いですかね…
# 長文でごめんなさい
Re:さらっとサイトを眺めましたが… (スコア:2, 参考になる)
メモリの使い方とかディスクの使い方はおもしろいとは思うかな
今のメモリ豊富なマシンが相手だと実用的かどうかはちょっと疑問だけど
Re:さらっとサイトを眺めましたが… (スコア:1)
スワップ領域ををあらかじめリザーブする動作は、初期の仮想記憶実装でよく行なわれていたけど効率が悪い (メモリ/ディスクのコスト差) からメモリ＋ファイルに移行したのだし、バッファとキャッシュ (メモリイメージ) の統合なんて、実装されて 10年以上はたつものでしょう (FreeBSD だと 1.1.x あたり [発表は 386BSD の patch] で実装されていた - 元アイデアは SunOS の実装あたりから...起源はもっと古いでしょう)。
まあ、世の中には思い付きを実行にできてしまうパワーに溢れた人がいます。そういう人は、パワーを先人の肩の上から発揮するとより効率的とは思いますが、そうしたら Linux のようなものも登場しなかった理由で、結局好きなアプローチで試みればいいんだろうな。
の
Re:さらっとサイトを眺めましたが… (スコア:0)
「へー、面白いことを考える人がいるなー」と思ったのですが
そのころから殆ど進んでいませんね>OSASK
それよりも、「MenuetOS」の方が現実的でいいなーとずっと眺めてます。
ある意味、OSASKとは対極にあるようなOSですが...
MenuetOS [menuetos.org]
マンパワーの配分法 (スコア:0)
どちらに力を割り振るかは難しい問題ですよね。
集団作業だと考えれば当然ドキュメント整備なのですが、
得てしてパワープログラマーはドキュメントを書くのが苦手な人も多く。
それに、コードを書かせてなんぼの人にドキュメントを書かせるのも
もったいなかったりもしますし。
川合さんはとてつもなくパワープログラマーなので、
ドキュメントやユーザーサポートだけで時間を潰させるのはもったいない。
Re:マンパワーの配分法 (スコア:0)
> 開発とドキュメント整備の割合のコツを語ってもらいたいものです。
コード:ドキュメント:テスト = 1:1:1
> 得てしてパワープログラマーはドキュメントを書くのが苦手な人も多く。
それはパワープログラマーではない。
なにがしたいんだか (スコア:0)
>
>コード:ドキュメント:テスト = 1:1:1
有り得ない。
>> 得てしてパワープログラマーはドキュメントを書くのが苦手な人も多く。
>
>それはパワープログラマーではない。
いや、パワープログラマーだ。
Re:なにがしたいんだか (スコア:1)
>有り得ない。
>>それはパワープログラマーではない。
>いや、パワープログラマーだ。
あんたら、理由を語れ、理由を^^;;
合意できないのはわかったからさ。
どうなんだろ (スコア:0)
あたりがパワープログラマかなとか。
いちいちドキュメントを書かなくても頭の中で整理できちゃて、
それをコードに落とせるって
Re:どうなんだろ (スコア:1)
自然言語という冗長であいまいで表現力に乏しいもので説明するというのは、それを翻訳する重労働が伴うのでやりたいないというのは良く判るというか ...
の
Re:どうなんだろ (スコア:0)
「パワープログラマー」でどういう人物を思い描くか、 ということはあるだろうけど。(「本物のプログラマ」Melとかね)。
「ソースコードを見ればわかる」っていうのは、十分に抽象度の 高い言語で書いているか、よっぽど入出力条件が自明な場合だけ 通用する話で。特に、入出力や例外についての暗黙の仮定とか、 想定しているコンポーネントの組み合せとかは、コードに 素直に出て
エミュレーションOSの勝算は...？ (スコア:1)
Wineの完成度がなかなか高まらないのを見てるとOSASKも無理なんじゃないかと思うんですが、勝算はあるんでしょうか。
速度だって、OSASKホームページでは速くなる可能性もあるようなことが書いてありますが、VirtualPCなど、ビデオ描画にGPUが使えない点がボトルネックになって高速化できない例が色々とあるのに...
開発なさっている方はこういった前例を凌ぐ技術を持ってやっていらっしゃるのか、その辺の説明がホームページに載っていないようでしたが、どうなんでしょうか。
Re:エミュレーションOSの勝算は...？ (スコア:0)
あんたは川合さんの足元にもおよばないんだからわけのわからんこというなよ。
Re:エミュレーションOSの勝算は...？ (スコア:0)
Re:エミュレーションOSの勝算は...？ (スコア:0)
今の所VESA使ってるみたいですよ。
次は (スコア:0)
いや (スコア:0)
メンゴ、知らんわ (スコア:0)
TCP/IPスタックの実装予定は？ (スコア:0)
いろいろ出来ることが広がるはずなのですが……。
たしか、各社のチップに対応したドライバを書くのが
川合さん一人でやるには時間がかかりすぎるという話だったと記憶していますが、
せめてintelと蟹さんあたりに対応してくれればずいぶん使える人は増えるはず。
というわけで、誰かほんのちょっとした時間を利用して
TCP/IPスタックを実装してくれないかなぁ、と
他力本願になってみるテスト。
Re:TCP/IPスタックの実装予定は？ (スコア:0)
ふつープロトコルスタックとイーサネットチップのデバイスドライバは
分離できる話でしょ。
Re:TCP/IPスタックの実装予定は？ (スコア:0)
無理してでもGNU、C LibraryやQTライブラリを移植したAtheOS [atheos.cx]の例もあるし、
ある程度スタートアップに既存の開発環境が使えるよう整備する必要はあるでしょうな。
現状ではHDDアクセス可能になるのも年末まで待てとか…ううむ。
windowsやLinuxと比べてるけど (スコア:0)
Re:はぁはぁ (スコア:0)
川合堂ライセンス（´_ゝ｀） (スコア:0)
川合さんは絶対的な神様です。
くれぐれも失礼のないようにどうかおねがいします。
Re:Wikiの効能 (スコア:1)
スペース、CGI、ML等)との違いを理解していればいるほど
Wikiはメリットになると思います。そうでなければデメ
リットを被ると思います。
近くリリースされるだろう PukiWiki 1.4 をお勧めします。
ただWikiWikiWebに自身に関する一般的な情報が含まれて
いないため、参考書(WikiWay)を手元に置かれるべきだと
思います。参加者にWikiのコンセプトを説明するためにも
役に立つことでしょう。
PHPやPukiWikiが難しければYukiWiki(dbtype=YukiWikiDB)
をお勧めします。WikiWikiWebのコンセプトを学ばれたい
のであれば、特にこちらをお勧めします。
# osdev-j.osdn.jp/?Wiki
Re:Wikiの効能 (スコア:0)
えぇ、このスレッドはそれでいいかと。
このストーリー全体そうでしたら困りますが。