アカウント名:
パスワード:
>まず、portsがばかでかいこと。
portsもNetBSDのpkgsrcも、この点では、
ディスクやメモリのいっぱいあるマシンでバイナリ・パッケージを作成
リソースの限られたマシンでは造ったバイナリ・パッケージをpkg_add(8)
何も/usr/portsを抱え込む必要はありません。
NetBSDの方では「場合によっては再インストールしなくては」っていうのはありませんな。安全で簡単なアップデートかどうかという点に考慮の余地はあるかもしれませんが。
再インストールに近いことが必要なのは、
実行形式が変わったとき; a.out → ELF
ファイルシステムを変えたいとき; FFS → FFS2
このような面では半年に1度、libcの共有ライブラリのmajorバージョンまでとっとと変えるOpenBSDは移行に辛いかもしれません。
>しかし、make worldにしても、
これもリソースの十分なマシンでリリースやカーネルを作成して、それをリソースの限られたマシンで展開する方法を取ればラクチンです。
=====元記述====== まず、portsがばかでかいこと。/usr/portsが300M以上になってしまって、ディスクの小さなシステムではまずportsを利用する事自体が難しくなってます。 =================
これは間違いです。確かにportsを全て入れるとなると指摘の通りですが、個別のportsをfetchコマンドで取得して展開する事もできます。(私は貧弱なネットワーク環境で使っているので、頻繁にそんな手法を使っています) cvswebでtarballとしてまとまっているものが入手できます。
=====元記述====== それからアップグレードが自在ではないことですね。場合によっては再
160GBのHDDが1万円しない時代に300Mででかすぎって…
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
192.168.0.1は、私が使っている IPアドレスですので勝手に使わないでください --- ある通りすがり
FreeBSD (スコア:2, 興味深い)
特にmargemasterが気に入ってますね。アップグレード時に既存の設定ファイルと新しい設定ファイルのdiffを表示するだけの機能ならdebianにもあるのですが、それを差分ごとに新旧どちらの記述を採択するか選んで行けるというのは驚きでした。とても便利ですね。
不満な点もいくつかあります。
まず、portsがばかでかいこと。/usr/portsが300M以上になってしまって、ディスクの小さなシステムではまずportsを利用する事自体が難しくなってます。
それからアップグレードが自在ではないことですね。場合によっては再インストールしなくてはアップグレードができないというのは、負担がかなり大きいと思います。make worldで済めばありがたいのですが。
しかし、make worldにしても、計算力の小さなシステムでは負荷が高く、場合によってはサービスを停止しなくてはなりません。ある程度の規模になれば、コンパイル用のマシンを1台用意して/usr/srcなどをnfsマウントして、make installworldだけで済ませることも可能ではあるのですが。この点も積極的に利用するのが難しいなと感じています。
数ヶ月前にバイナリベースのアップグレードの枠組が作られてるという話も聞いたので、それが利用できるようになれば、不満の半分は解消するのでしょうかね。
Re:FreeBSD (スコア:1)
カーネルなどの再構築をしているとダメとか条件は色々あるようですが。
Re:FreeBSD and NetBSD (スコア:1)
>まず、portsがばかでかいこと。
portsもNetBSDのpkgsrcも、この点では、
ディスクやメモリのいっぱいあるマシンでバイナリ・パッケージを作成
リソースの限られたマシンでは造ったバイナリ・パッケージをpkg_add(8)
何も/usr/portsを抱え込む必要はありません。
NetBSDの方では「場合によっては再インストールしなくては」っていうのはありませんな。安全で簡単なアップデートかどうかという点に考慮の余地はあるかもしれませんが。
再インストールに近いことが必要なのは、
実行形式が変わったとき; a.out → ELF
ファイルシステムを変えたいとき; FFS → FFS2
このような面では半年に1度、libcの共有ライブラリのmajorバージョンまでとっとと変えるOpenBSDは移行に辛いかもしれません。
>しかし、make worldにしても、
これもリソースの十分なマシンでリリースやカーネルを作成して、それをリソースの限られたマシンで展開する方法を取ればラクチンです。
Re:FreeBSD and NetBSD (スコア:1)
>ディスクやメモリのいっぱいあるマシンでバイナリ・パッケージを作成
>リソースの限られたマシンでは造ったバイナリ・パッケージをpkg_add(8)
>何も/usr/portsを抱え込む必要はありません
NetBSDはソースツリーをクロスコンパイルするのは簡単ですが。
pkgsrcをクロスコンパイルする仕組みはなかったと思いますよ。
distccを使えばコンパイルの大半は肩代わりしてくれますけど、configureとかminiperlやemacsのdumpみたいな処理はターゲットがないとできませんし。
実際あるなら教えてください。すごく使いたいです。
Re:FreeBSD and NetBSD (スコア:1)
毛頭ありません。
pkgsrcの方面ではクロスコンパイルを目標にしてる開発者もいた気がしますが、本当に
できるかどうかはわかりません。
あったら欲しい気がする反面、pkgsrcを作るのがたいへんになったりしたら、正直嫌だなぁ。
Re:FreeBSD and NetBSD (スコア:0)
リソースの少ないマシンなら、portsの殆んどは不必要と思われますので、
適当に削除しておいて、 /usr/sup/refuseに ports/(要らないカテゴリ)
を記述すれば、cvsupで更新されなくなります。
# refuseにはコメントは書けないそうです。
Re:FreeBSD (スコア:1)
/ad10をnewfsしてports-allをcvsupしてdu -sk /ad10した出力の違いはこんな感じ。
blocksize 16384/fragsize 2048(default)
250852 /ad10
blocksize 8192/fragsize 1024
174248 /ad10
ports専用にするかはさておき、細かいファイル置き場用パーティションを用意するのがお薦めです。
Re:FreeBSD (スコア:0)
=====元記述======
まず、portsがばかでかいこと。/usr/portsが300M以上になってしまって、ディスクの小さなシステムではまずportsを利用する事自体が難しくなってます。
=================
これは間違いです。確かにportsを全て入れるとなると指摘の通りですが、個別のportsをfetchコマンドで取得して展開する事もできます。(私は貧弱なネットワーク環境で使っているので、頻繁にそんな手法を使っています)
cvswebでtarballとしてまとまっているものが入手できます。
=====元記述======
それからアップグレードが自在ではないことですね。場合によっては再
Re:FreeBSD (スコア:0)
160GBのHDDが1万円しない時代に300Mででかすぎって…
Re:FreeBSD (スコア:0)