アカウント名:
パスワード:
僕としては目的に添って必用なものと不要なものをきちんと取捨選択する事により、無駄を省いたシンプルで軽いOSを目指して欲しいな。
この頃たまに思うのですが、うん百MB費やしたWindowsと、FDに収まるDOSのビジュアルシェル。ユーザーがプログラムを起動したりファイルを編集したりするにおいて、どれだけ本質的な違いがあるのだろうか、とか。
「その高性能は本当に必要か?」という事を考え直す契機のひとつとして、こういうハンドメイドOSもあっていいのでは無いかとも思います。
理由全体を読んでみると、作者がi386のことを知ったのは1992年前後でしょう。奇しくもこの年は、KhannaがSunOS 5.0におけるリアルタイムスケジューリングの論文 [nec.com]を発表した年です。その直後に作者も似たようなことを考えているわけですが、それを実現する能力の違いがアイデアの新規性を動くものの新規性に変えることができるか否かの分かれ目になっているという印象を受けます。実装の人手が足りないと、あっと言う間にアイデアは古くなってしまいますからね。
そうなると、OSを手作りする必要に迫られた場合、果たして自分が使いやすい材料を手にしているのかというのを真っ先に考えなければならなくなります。私はMIPSやSPARCの存在を知った上でi386のpagingを少し勉強したのですが、はっきりいってあのpaging architecureは使いたくありません。page table directoryのように機能が多過ぎて、それらを使うべきかどうかの判断を数多く迫られてしまうのです。これではムダな労力なしにOSを作るというのは難しいことです。
上述のpaging architectureなども含めて、i386を選んだことが本当に正しかったのか、OS作りを少しでも楽にしてくれるものだったのか、考え直しているのも手かも知れませんね。そもそもOSってのは自己完結した構造をきちんと持っているわけで、決してプロセッサのドライバとしてOSを書いているわけじゃないのですから。プロセッサのいいなりになるOS開発というのはきっかけにこそなっても、自分が作りたい、あるいは与えられた要求を満たすOSを作ることにはならないでしょう。
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
ソースを見ろ -- ある4桁UID
OSASKの新規性について (スコア:0, 興味深い)
において述べられている 新規性は、残念ながら新規ではないです。
まず、「OSASKのタスク管理」についてですが、
これは、単なる最も簡単なリアルタイムスケジューリングです。
遅くとも1989年にはSystem V Release 4で実現されています。
また、現行のほとんどのいわゆる汎用カーネル
(SVR4系,BSD系,NT系,Linuxなどなどなど)で実現されています。
次に「OSASKの仮想記憶」についてですが、
ここで述べられているファイルキャッシュと仮想記憶機構の統合は、
遅くとも1988年にはSunOS 4.0で実現されています。
また、現行のほとんどのカーネル(SVR4系,BSD系,NT系?,Linux)は
既にこのように実装されています(実装が汚いものもありますが…) 。
唯一、タスクセーブの機能が
現行のよく使われているOSにはなさそうな機能と考えられますが、
既に1980年代から、 プロセスマイグレーションやモバイルエージェントの分野において、
多くの研究が行われています。
Re:OSASKの新規性について (スコア:1, すばらしい洞察)
僕としては目的に添って必用なものと不要なものをきちんと取捨選択する事により、無駄を省いたシンプルで軽いOSを目指して欲しいな。
この頃たまに思うのですが、うん百MB費やしたWindowsと、FDに収まるDOSのビジュアルシェル。ユーザーがプログラムを起動したりファイルを編集したりするにおいて、どれだけ本質的な違いがあるのだろうか、とか。
「その高性能は本当に必要か?」という事を考え直す契機のひとつとして、こういうハンドメイドOSもあっていいのでは無いかとも思います。
Re:OSASKの新規性について (スコア:0, フレームのもと)
Re:OSASKの新規性について (スコア:0)
#161637に対するコメントとして、話がずれている、という指摘なら同意できるのだけど。
CPUのためのOSにあらず、OSのためのCPU (スコア:1, 興味深い)
理由全体を読んでみると、作者がi386のことを知ったのは1992年前後でしょう。奇しくもこの年は、KhannaがSunOS 5.0におけるリアルタイムスケジューリングの論文 [nec.com]を発表した年です。その直後に作者も似たようなことを考えているわけですが、それを実現する能力の違いがアイデアの新規性を動くものの新規性に変えることができるか否かの分かれ目になっているという印象を受けます。実装の人手が足りないと、あっと言う間にアイデアは古くなってしまいますからね。
そうなると、OSを手作りする必要に迫られた場合、果たして自分が使いやすい材料を手にしているのかというのを真っ先に考えなければならなくなります。私はMIPSやSPARCの存在を知った上でi386のpagingを少し勉強したのですが、はっきりいってあのpaging architecureは使いたくありません。page table directoryのように機能が多過ぎて、それらを使うべきかどうかの判断を数多く迫られてしまうのです。これではムダな労力なしにOSを作るというのは難しいことです。
上述のpaging architectureなども含めて、i386を選んだことが本当に正しかったのか、OS作りを少しでも楽にしてくれるものだったのか、考え直しているのも手かも知れませんね。そもそもOSってのは自己完結した構造をきちんと持っているわけで、決してプロセッサのドライバとしてOSを書いているわけじゃないのですから。プロセッサのいいなりになるOS開発というのはきっかけにこそなっても、自分が作りたい、あるいは与えられた要求を満たすOSを作ることにはならないでしょう。
Re:OSASKの新規性について (スコア:0)
>遅くとも1988年にはSunOS 4.0で実現されています。
>また、現行のほとんどのカーネル(SVR4系,BSD系,NT系?,Linux)は
>既にこのように実装されています(実装が汚いものもありますが…) 。
OSASKにおいては多分
・空きメモリ用量は(接続されているHDDの総容量)-(既に確立したファイルが使用している容量)に等し
Re:OSASKの新規性について (スコア:0)
これだけだったら、普通のSWAP方式でもそうなんでは? いずれにせよ、高速に同時に利用できるメモリは、物理メモリ の容量に制限されると思う。
>malloc すると必ずHDD上の使用されていない領域にファイルとして割り当てられ、プロセス終了時に開放しなければ、以後も通常ファイルとして使用できる。
大規模なプログラムだと、free()する時間が馬鹿にならないので、 個別に解放せずに終了するテクニックがある。 もし、fre