えーと、そう言う話しじゃないんですが。複数のユーザプロセスが有限の共有資源に同時にアクセスしようとするときに意図的にタイミングをはかると、いとも簡単にデッドロックを起こすことができますよね。資源の管理を行うべき OS としてはこれはゆゆしき事態なので、そのような状態に陥ったプロセスがあれば速やかに検出し、どちらかのプロセスがにぎっている資源を強制的に解放させてデッドロックを取り除くのが理想です。そうしないと、遅かれ早かれその資源を使いたい他のプロセスにまで影響が及びますから(というようなことは AST などを見れば必ず書いてあると思いま
だからといって現実的に解決できない問題ではありません。現にメインフレームの OS ではデッドロックを自動的に検出して、回復する機能を持つものがあるようですし。つまり制約の厳しいカーネルでこれを解決するのは困難だ、という主張にはちょっと無理があるわけですね。まあ大型だからできるのだ、Unixレベルでは無理なのだ、と言えるかもしれませんが。
そしてあなたの説によれば、後者の方針を選択をしたカーネルは toy system ではないけれども、同じ選択をしたパッケージングシステムは toy system だ、ということなのです。しかしパッケージングシステムにとっても実際には依存性の問題が常に出てくるわけではなく、仮に問題になったとしても安易で汚い解決方法があるわけですから、循環問題を真正面から解かないという選択は十分納得できる、というよりむしろソフトウェアの設計上良いセンスだと私は思います。ベストではないでしょうけれど。
どうも OS の基礎的な理論にお詳しくないようなので、一度 AST や "Operating System Concepts" など学部用の標準的な教科書を読まれた上で、The Rise of "Worse is Better" といった有名な文書に目を通されることをお勧めします("New Jersey approach" といったキーワードでたぐれると思います)。
パッケージ管理が便利になる(?) (スコア:1)
ナニゲに {Free,Open,Net}BSDの Ports って、自分で Makefileをなどをいじることによって、自分の好みに応じた状態のソフトウェアをインストールできるというような楽しみや利便性があって、それはそれで非常にいいことだとは思う。 こんどは Debian のパッケージ管理の方針が取り入れられるとなると、アップデートしそこなっているパッケージのアップデートが半ば自動的におこなえるとか、その辺がありがたく思える。
本当はBSD の中心的なディストリビューションの部分が rpm またはそれ以上のパッケージ管理のシステムの元で管理が行えれば私
依存性の循環を真正面から解いて欲しい (スコア:2, 興味深い)
パッケージの自動管理は聞こえは魅力的です。しかし、パッケージ間の依存性に閉路ができてしまった場合の問題をあまりにnegletしすぎています。
例えば、Cyrus SASLはその認証用データベースとしてLDAPを利用することができます。したがって、OpenLDAPに依存させることができます。一方、OpenLDAPはその認証手段としてCyrus SASLを用いることができます。もしここでOpenLDAPをCyrus SASLに依存させた場合、依存性を両方とも満たすようにパッケージをmakeして欲しいわけです
Re:依存性の循環を真正面から解いて欲しい (スコア:0)
例えば、パッケージ間の依存性の問題などよりも OS としてずっと本質的で深刻なはずのデッドロックの検出と解除に関して、よくあるUnix系のシステムはたいして賢いことはしませんよね?たいてい Ostrich algorithm だと思います。そういう問題
Re:依存性の循環を真正面から解いて欲しい (スコア:1)
それは問題の性質が違います。OSに置けるdeadlock問題は、本来あってはならない問題です。すなわち、debugが終われば忘れることができます。それに対し、packageの問題は、それを解かなければやりたいことができません。複雑な依存性を
Re:依存性の循環を真正面から解いて欲しい (スコア:0)
えーと、そう言う話しじゃないんですが。複数のユーザプロセスが有限の共有資源に同時にアクセスしようとするときに意図的にタイミングをはかると、いとも簡単にデッドロックを起こすことができますよね。資源の管理を行うべき OS としてはこれはゆゆしき事態なので、そのような状態に陥ったプロセスがあれば速やかに検出し、どちらかのプロセスがにぎっている資源を強制的に解放させてデッドロックを取り除くのが理想です。そうしないと、遅かれ早かれその資源を使いたい他のプロセスにまで影響が及びますから(というようなことは AST などを見れば必ず書いてあると思いま
Re:依存性の循環を真正面から解いて欲しい (スコア:1)
あの... そのような事態は、例えばuser threadによるmultithreaddingでも生じませんか? したがって、kernelの問題の場合厄介なのは、
にとどまらず、deadlockなどの問題があちこちで分散して生じる恐れがあるということにあります(もっともkern
Re:依存性の循環を真正面から解いて欲しい (スコア:0)
結局は、生真面目に解決しようとして複雑なシステムを作り上げてしまうか、適当で現実的なところで妥協してコンパクトで使い勝手もほどよいものにするか、という設計方針の選択になるわけです。
そしてあなたの説によれば、後者の方針を選択をしたカーネルは toy system ではないけれども、同じ選択をしたパッケージングシステムは toy system だ、ということなのです。しかしパッケージングシステムにとっても実際には依存性の問題が常に出てくるわけではなく、仮に問題になったとしても安易で汚い解決方法があるわけですから、循環問題を真正面から解かないという選択は十分納得できる、というよりむしろソフトウェアの設計上良いセンスだと私は思います。ベストではないでしょうけれど。
どうも OS の基礎的な理論にお詳しくないようなので、一度 AST や "Operating System Concepts" など学部用の標準的な教科書を読まれた上で、The Rise of "Worse is Better" といった有名な文書に目を通されることをお勧めします("New Jersey approach" といったキーワードでたぐれると思います)。
Re:依存性の循環を真正面から解いて欲しい (スコア:1)
うーん、これは結局需要があるかという問題にもなってしまう(そしてわたしの場合はたまたまそうなった)のかなぁ... なんかこれ以上議論を続けても得るものがなさそうなので、しばらく棚上げにした方がいいかも。
systematicに勉強したことがないのは事実です。ですが、わたしは日本のPC-Unixの世界で、古い本をいまだに振りまわし、もはや現代の需要に見合わないような理論を信じて疑わない人達がひとたび世界へ出た途端に無残に失敗してしまうという惨状を目のあたりにしています。理論があくまで現実の抽象化であることを忘れ、現実に起きることをよく観察しようとしない人達が残念ながら日本では幅を利かせているんです(OS自体が輸入技術なので半分は仕方ないにしても)。
わたしは、このままでは現実の需要に見合ったものを作ることはできないと考えました。まずは問題となっている現象を観察することから始めなければならない、理論はあくまで後付けに徹する。それを2年ほどやってみた結果、実績も出すことができました(in-core vnodeが不足した場合にname cacheからvnodeを回収し、opened file数のscalabilityを改善。大元に反映済)。理論にしがみつく人達とは全く逆の結果を得たわけです。
OSは自然が作るものではなく、あくまで人間の需要のために作るものです。需要を抜きにして理論を語ってみても、「何に使うの?」という質問が返ってくるだけで世の中の役には立ちません。
Re:依存性の循環を真正面から解いて欲しい (スコア:0)
brake-handle 氏が何者なのか想像がついてる私としては、
とてもそんなことは言えないな。
Worse is Better くらい、
知ってるうえでああいう意見を言ってると思うんだがなぁ。
私も、Worse is Better が言い訳として使われるのを気持ち悪く
感じる(でも多くの場合そ