パスワードを忘れた? アカウント作成
この議論は賞味期限が切れたので、アーカイブ化されています。 新たにコメントを付けることはできません。

Debian GNU / NetBSD」記事へのコメント

  • ナニゲに {Free,Open,Net}BSDの Ports って、自分で Makefileをなどをいじることによって、自分の好みに応じた状態のソフトウェアをインストールできるというような楽しみや利便性があって、それはそれで非常にいいことだとは思う。 こんどは Debian のパッケージ管理の方針が取り入れられるとなると、アップデートしそこなっているパッケージのアップデートが半ば自動的におこなえるとか、その辺がありがたく思える。

    本当はBSD の中心的なディストリビューションの部分が rpm またはそれ以上のパッケージ管理のシステムの元で管理が行えれば私

    • パッケージの自動管理は聞こえは魅力的です。しかし、パッケージ間の依存性に閉路ができてしまった場合の問題をあまりにnegletしすぎています。

      例えば、Cyrus SASLはその認証用データベースとしてLDAPを利用することができます。したがって、OpenLDAPに依存させることができます。一方、OpenLDAPはその認証手段としてCyrus SASLを用いることができます。もしここでOpenLDAPをCyrus SASLに依存させた場合、依存性を両方とも満たすようにパッケージをmakeして欲しいわけです

      • あんまり難しすぎる問題は、真正面から解決しようとせずに、「それほど頻繁には起きないケースだから無視する」と決め込むなり、ユーザーが手で解決する、というのが古くからのUnix流のスタイルだと思うんです。

        例えば、パッケージ間の依存性の問題などよりも OS としてずっと本質的で深刻なはずのデッドロックの検出と解除に関して、よくあるUnix系のシステムはたいして賢いことはしませんよね?たいてい Ostrich algorithm だと思います。そういう問題
        • 例えば、パッケージ間の依存性の問題などよりも OS としてずっと本質的で深刻なはずのデッドロックの検出と解除に関して、よくあるUnix系のシステムはたいして賢いことはしませんよね?たいてい Ostrich algorithm だと思います。

          それは問題の性質が違います。OSに置けるdeadlock問題は、本来あってはならない問題です。すなわち、debugが終われば忘れることができます。それに対し、packageの問題は、それを解かなければやりたいことができません。複雑な依存性を

          • それは問題の性質が違います。

            えーと、そう言う話しじゃないんですが。複数のユーザプロセスが有限の共有資源に同時にアクセスしようとするときに意図的にタイミングをはかると、いとも簡単にデッドロックを起こすことができますよね。資源の管理を行うべき OS としてはこれはゆゆしき事態なので、そのような状態に陥ったプロセスがあれば速やかに検出し、どちらかのプロセスがにぎっている資源を強制的に解放させてデッドロックを取り除くのが理想です。そうしないと、遅かれ早かれその資源を使いたい他のプロセスにまで影響が及びますから(というようなことは AST などを見れば必ず書いてあると思いま

            • 資源の管理を行うべき OS としてはこれはゆゆしき事態なので、

              あの... そのような事態は、例えばuser threadによるmultithreaddingでも生じませんか? したがって、kernelの問題の場合厄介なのは、

              カーネルがそういうことをしないので、

              にとどまらず、deadlockなどの問題があちこちで分散して生じる恐れがあるということにあります(もっともkern

一つのことを行い、またそれをうまくやるプログラムを書け -- Malcolm Douglas McIlroy

処理中...