Debian GNU / NetBSD 34
ストーリー by Oliver
可能だから僕らはそれに挑む 部門より
可能だから僕らはそれに挑む 部門より
Anonymous Coward曰く、"Daemonnewsに載っていたのですが、あのDebianがNetBSDに移植されるようです。ホームページはここ。userlandがGNUになるようで、BSDな人でない人もNetBSDに移りやすくなるかも。これからはBSDでもdeb形式のファイルを日常的に使うようになるのでしょう?"
ユーザ空間が同一ならば用途と趣味で好みのカーネルが選べる。いい世界だ。でも、トピック選択に迷うぞ。
Debian NetBSD != BSDシステム (スコア:2, 参考になる)
個人的にはこっちに期待しますが...
Debian NetBSD [sourceforge.net]のWhy Debian NetBSD? [sourceforge.net]によると、
とあるので、NetBSDへのdebパッケージの移植というよりは、
NetBSDのカーネルをGNU/Linux的な世界に持ってきた
と判断した方がいいかも知れません。
むしろ、Oliver氏のコメントにあるように
が目的だと思います。
semanticsの組み合わせ問題 (スコア:2, 参考になる)
選択肢の広さをそのまま長所と信じてしまう人がよくいます。しかし、ことkernelの問題になった場合、特にuserlandから見たkernelのsemanticsが従来よりも狭い方向に変わってしまうといろいろ問題を引き起こします。
例えば、NetBSDのsetgid(2)は、effective gidにはsetgidできないという制約を持っています。これはSolarisなどよりも厳しい制約です。したがって、permissionが2555なものを実行する場合にsetgid(2)が機能しない場合があります(わたしはsendmail 8.12でハマった)。
deviceに対するsemanticsと違い、userlandに対するsemanticsはkernelだけでは完結しません。そこをよく注意しておかないと、現実には動かないkernelとuserlandの組合せを大量に作っただけで終わってしまう恐れがあります。
他にもいろいろ (スコア:1)
Open Packages [openpackages.org] (BSD 系) や，OpenPKG [openpkg.org] (RPM 系) というのもあるみたいですね．
Re:他にもいろいろ (スコア:1)
進めているようです。誰か使ったことある人はいませんか?
# それとも現状では使いものになるレベルではない?
Re:他にもいろいろ (スコア:0)
カーネルの自由 (スコア:1, 参考になる)
逆にBSD的LinuxがSlackwareって言われることがあるけど、
glibcだしユーザーランドまで完全BSDってわけじゃないよね。
> ユーザ空間が同一ならば用途と趣味で好みのカーネルが選べる。いい世界だ。
私は興味本位もあるのですがよく Hurd を使います。
Debian GNU/Hurd が出て apt-get できるようになってから
Hurd の使い勝手が桁違いに向上しました。
# Debian GNU/Linux よりも Hurd の方をよく使う。:-)
既存の BSD や Linux に食傷気味の人にはお勧めです！
Re:カーネルの自由 (スコア:1)
#だからDebian GNU/NetBSDとなっていないのか?
Re:カーネルの自由 (スコア:1)
FreeBSDのccはgccだし、awkはgawkだし、binutilsもGNU謹製。
これ以外にもGNUのものと置き換えられているコマンドは多いし、「コマンドのオプションがGNU likeになっている」なんてのまで入れれば、 (きちんと比率を計算したわけじゃないけど)かなりの部分を占めているように思う。
Linuxほどではないにしろ、FreeBSDもGNUの成果物なしには「システム」と呼べないようになっている気もしますが。
#「FreeBSDも」じゃなくて、"UNIX Like"と呼ばれるシステム全般に言える話だな、こりゃ。
パッケージ管理が便利になる(?) (スコア:1)
ナニゲに {Free,Open,Net}BSDの Ports って、自分で Makefileをなどをいじることによって、自分の好みに応じた状態のソフトウェアをインストールできるというような楽しみや利便性があって、それはそれで非常にいいことだとは思う。 こんどは Debian のパッケージ管理の方針が取り入れられるとなると、アップデートしそこなっているパッケージのアップデートが半ば自動的におこなえるとか、その辺がありがたく思える。
本当はBSD の中心的なディストリビューションの部分が rpm またはそれ以上のパッケージ管理のシステムの元で管理が行えれば私的には嬉しいんだけど、自分の頭のなかで考ええてみてもケッコー難しい感じです。
ただただ私的に BSD で気に入らないのが /{etc,bin,sbin,usr/{sbin,bin,lib,share}} あたりのファイルが単に tar とか pax とかでインストールされて、 あとは放置プレイされていることなのです。ライブラリの依存性とか、ファイルの md5sum とか、設定ファイルの保存とかをしっかり管理して欲しいかなと思っていたりはします。
依存性の循環を真正面から解いて欲しい (スコア:2, 興味深い)
パッケージの自動管理は聞こえは魅力的です。しかし、パッケージ間の依存性に閉路ができてしまった場合の問題をあまりにnegletしすぎています。
例えば、Cyrus SASLはその認証用データベースとしてLDAPを利用することができます。したがって、OpenLDAPに依存させることができます。一方、OpenLDAPはその認証手段としてCyrus SASLを用いることができます。もしここでOpenLDAPをCyrus SASLに依存させた場合、依存性を両方とも満たすようにパッケージをmakeして欲しいわけです。ですが、これを実現したシステムはわたしが聞く限り存在しません。
本質的に同じ問題が、クラスタ計算機のconfigurationでも生じます。掘り出せばいくつかの手法が出てくるので応用して欲しいところです。が、それを全然やってくれないのでどうしても「パッケージ管理システム == toy system」というイメージになってしまいます。
Re:依存性の循環を真正面から解いて欲しい (スコア:1)
言わんとするところはわかりますけど。
つーのは極論の類に思えますね。楽に適用できる部分はパッケージで楽して、パッケージでうまく管理できないとこは自分でmakeして/usr/localに放り込んでおけば実用上何の問題もないので。toyでも何でも、便利で楽できるならそれでよし。聞こえだけじゃなく、日常の管理の上でもとっても魅力的です。ただ、魅力的だからといって、それで全てを解決しようとは思わない。ただ、どうせいずれも必要なものなら、ややこしい依存なんぞすっとばして、全部まとめた自前のパッケージ作っちゃうかもしれませんね。
Re:依存性の循環を真正面から解いて欲しい (スコア:1)
ところで、
>依存性を両方とも満たすようにパッケージをmake
これってもしかしてjavaのやりかたが参考になるんでしょうか?
「依存性」という概念に依存(^^;する度合を減らしてあるという面とか、
コンパイル手順がmakeの考えかたとは違うとか、
動的リンクしかしないとか(これは解決にならぬなあ)、
ヒントが幾つかあるように思います。
もしかして、C+makeという世界自体が色々破綻をきたしてるっていうこと
なんじゃないか、と思ってたりします(が、そういう理解で合っているでしょうか?)
Re:依存性の循環を真正面から解いて欲しい (スコア:1)
cyrus-sasl-openldap depends openldap-cyrus-sasl
とか別パッケージ同士にすれば駄目です? そういう話ではない?
どっちかというと依存関係の閉路と言うよりはバリエーションの増加によるパッケージメンテナの管理コストの増大が
問題になるだけではないかと。あとポリシーで問題になる可能性はあるかな。
toy system だと思うかどうかはその人次第ですね。私はパッケージ無いと面倒で死にますけど。
現実には必要な機能があるかないかで使うかどうかを判断するだけなので、neglect と言うか
使うメリットでメリットを天秤にかけるだけだと思ってます。
package化の真の目的 (スコア:1)
あの... それって思いっきり閉路ができてるんですけど。正しくは
ではないですか?
一部のpackageはこのような命名規則で問題を回避しているように見えます(ほかにはlocalized softwareなど)。しかし、今度はopenldap-cyrus-saslとopenldapを同時にインストールした場合に問題が生じます。複数のpackageが同じ名前のfileを参照してしまいます。全てのfileが同一内容ならばreference count、全て異なるならばhash値などで管理できます。しかし、現実には中身が同じfileもあれば異なるfileもあります。そのような情報はどこに記述するんでしょうか? 個々のpackage? それはそれでやりたがる人がいるかどうか...
実際、わたしはpackageを導入することのメリットに本質的な疑問を感じています。というのは、PC-Unixのように(自分でmakeするような)packageが存在しないSolarisの方が実際には管理が楽になってしまっているのです。最初に述べた、依存性の閉路を作る可能性のあるsoftwareはたいていautoconfを利用しています。したがって、config.status(皆さん使ってますよね?)に残った前回のconfigurationを必要な依存性に応じて再定義すれば、後はmakeの順序を考えるだけで問題が解けてしまいます。最初の例ならば、例えば
となるわけです。packageがこれを機械的に導出し、しかるべき手順をとってくれればpackage数が減らせてpackage管理者が助かりますし、ユーザも自分の指定した機能をどおりにmakeできるのでうれしいわけです。逆にそれができないならば、make順序の制約が不必要に狭すぎるpackageを使うのはかえって損になってしまいます。
Re:package化の真の目的 (スコア:1)
Re:package化の真の目的 (スコア:1)
パッケージの依存関係をインストール時に両パッケージ解決すればいいですよね。同時に両パッケージを持ってきて、インストール時に依存関係が互いに解消していることを確認しつつ一つのプロセス内で処理すれば済むと思います。Debian だとどう処理してましたっけ? こういう閉路は負荷でしたでしょうか? > 識者
deb でも rpm でも普通は conflicts を定義します(fooがfoo-barと conflict する場合には foo が入っていて foo-bar をinstallするとfooは先に削除される)し、deb の場合は異なるパッケージが同じファイルを上書き・削除する場合にはエラーないし警告になります。
Solaris ってパッケージが存在すると思うんですけど。
Sunfreeware.com(jp site) [sut.ac.jp]
など。お世辞にも優れたパッケージシステムとは思えませんが、そもそも pkgadd コマンドが存在しますよね。
そもそもパッケージで管理するのが楽かどうかはやりたいこととパッケージの形態に寄る問題であって、make だけで解決するのはインストール時はともかく、remove や upgrade の際に共有しているライブラリを不用意に削除したり上書きしたりする危険性から逃れられません。
Re:依存性の循環を真正面から解いて欲しい (スコア:0)
パッケージAとBのどちらを先にいれようとしても、依存エラーになる、と。
でも、同時にインストールすれば、たすきがけ依存を解消してくれます。
Re:依存性の循環を真正面から解いて欲しい (スコア:0)
例えば、パッケージ間の依存性の問題などよりも OS としてずっと本質的で深刻なはずのデッドロックの検出と解除に関して、よくあるUnix系のシステムはたいして賢いことはしませんよね？たいてい Ostrich algorithm だと思います。そういう問題
Re:依存性の循環を真正面から解いて欲しい (スコア:1)
それは問題の性質が違います。OSに置けるdeadlock問題は、本来あってはならない問題です。すなわち、debugが終われば忘れることができます。それに対し、packageの問題は、それを解かなければやりたいことができません。複雑な依存性を正しくとり扱うことを抜きにしては、packageそのものが作れなくなってしまうんです。その点では、むしろdatabaseのdeadlock問題に近い本質を持っています。
そのdatabaseの方では、lock protocolによる解決を行って初めて実用になりました。案外packageでも思わぬところに解が転がっているという期待はありますが...
Re:依存性の循環を真正面から解いて欲しい (スコア:0)
えーと、そう言う話しじゃないんですが。複数のユーザプロセスが有限の共有資源に同時にアクセスしようとするときに意図的にタイミングをはかると、いとも簡単にデッドロックを起こすことができますよね。資源の管理を行うべき OS としてはこれはゆゆしき事態なので、そのような状態に陥ったプロセスがあれば速やかに検出し、どちらかのプロセスがにぎっている資源を強制的に解放させてデッドロックを取り除くのが理想です。そうしないと、遅かれ早かれその資源を使いたい他のプロセスにまで影響が及びますから(というようなことは AST などを見れば必ず書いてあると思いま
Re:依存性の循環を真正面から解いて欲しい (スコア:1)
あの... そのような事態は、例えばuser threadによるmultithreaddingでも生じませんか? したがって、kernelの問題の場合厄介なのは、
にとどまらず、deadlockなどの問題があちこちで分散して生じる恐れがあるということにあります(もっともkernelを不可分な1つの要素としてしかとらえない人が結構いてわたしは困っているのだが)。それに比べれば、packageの場合は管理機構1個所で問題を解決できる可能性があります。もっと問題が簡単なはずなのに何もしていないのが、toy systemの由縁です。
Re:依存性の循環を真正面から解いて欲しい (スコア:1)
補足。kernelの場合、問題を解くために与えられる時間や空間が極端に少ないという問題もあります。kernel stackの8KBさえ、実行単位の設計によってはお荷物になります(だからこそMach 3.0のcontinuationなどが考えられた)。それに比べて、user processであればGB単位の空間があります。また、kernelはuser processをいつでもpreemptできるため、時間がかかる処理を簡単に実装できます。
こうなると、kernelとuser processでは問題の解き方も変わってきますし、解ける範囲も変わってきます。逆にいえば、同じ範囲の問題が解けてもある場合にはおもちゃにすぎず、別の場合には十分実用になるのです。
Re:依存性の循環を真正面から解いて欲しい (スコア:0)
生じますよ。それはユーザープロセス内部の事情であって、カーネルの問題ではありません。もちろん、現行のマルチスレッドライブラリの設計方針が、たまたま(というより当然のことながら)カーネルと同じ設計方針、ostrich algorithm を採用しているだけのことです。
だからといって現実的に解決できない問題ではありません。現にメインフレームの OS ではデッドロックを自動的に検出して、回復する
Re:依存性の循環を真正面から解いて欲しい (スコア:0)
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 が言い訳として使われるのを気持ち悪く
感じる(でも多くの場合そ
Re:パッケージ管理が便利になる(?) (スコア:2, 参考になる)
>ただただ私的に BSD で気に入らないのが /{etc,bin,sbin,usr/{sbin,bin,lib,share}} あたりのファイルが単に tar とか pax とかでインストールされて、 あとは放置プレイされていることなのです。
うーん, このあたりは*BSDではベースシステム(この概念はLinux distributionには無いですね)なので, cvsupでソースを更新してmake world(慎重にするならmake buildworld, kernel再作成, make install worldですが)とmergemasterで一式まとめて足並みそろえてメンテナンスできるので, それほど問題には感じていません. この点むしろ*BSDの方がソース指向なのかもしれません. 特に更新で問題が発生した場合にCVSと組み合わせて, 一定の位置まで戻すことが比較的簡単にできるのは大きいように思えます.
ただ, FreeBSD等でもベースシステムのバイナリパッチの必要性は認識されていて現在開発中です. もっとも, 実際に戻し機能付きのバイナリパッチパッケージシステム(HP-UXです)を使った経験では, 前バージョンのモジュールを保存しておく領域がかなり必要になって, パーティション切りの計画が狂ってしまったことが何回か有りますので痛しかゆしというところでしょうか.
Re:パッケージ管理が便利になる(?) (スコア:1, 参考になる)
NetBSDには、ベースシステムもpackage化する予定はあるらしいです。予定はあるのですが、まだ一般のユーザーには実装の進み具合とかほとんど分からないです。
Re:パッケージ管理が便利になる(?) (スコア:1)
NetBSDのpkgsrcだと、make update できちんとアップデートをしてくれたり、lintpkgsrc -i でインストールされてるpkgsrcのバージョンが最新かどうかを調べてくれたりして、それなりに便利です。また、使ってないから伝聞の範囲ですが、FreeBSD の portupdate(だっけ)も相当強力なパッケージ管理をしてくれるようです。
俺はNetBSDとDebianの両方を日常使っているので、Debian/NetBSDはまさにまさに待望していたものではあるんだけどね。一応素のNetBSDにもそれなりのものはあるってことで。
Debianって？ (スコア:0)
パッケージ形式？ 何なんでしょう？
Re:Debianって？ (スコア:1)
Re:Debianって？ (スコア:1)
Re:Debianって？ (スコア:0)
もしくは、UNIX互換の文化です。
でもまぁ (スコア:0)
目標にしてる一方で、
Debian の連中は「どんな OS でも deb を動かす」を
目標にしてるので、この点でよく似てはいますな。
ただ、ハタから見てて、NetBSD の連中が割と
「動いたからもういい」
状態になりがちなのと同じくらいには、Debian の連中も
「動いたからもういい」
な傾向があるように見えるなぁ。
過去には Debian/FreeBSD もあったよなぁ。
あれも、動いた途端に放置されてたような。
したがって、過度な期待は禁物。
そもそも、NetBSD にももともとすばらしい
パッケージシステムがあるし、-current では既に syspkg が
動いてる。この辺のツールの整備とかが完了すれば、
base system の live update だって可能になるでしょう。