DragonFly BSD 1.4.0リリース

KENN曰く、"DragonFly BSD 1.4.0がリリースされた。リリースノートにはpkgsrcやCitrusといったNetBSDの成果物の取り込みを含む多数の変更点が記載されている。

# FreeBSDのportsシステムは、1.4.0ではサポートされない。

独自実装のNTPDなども興味深い。ISOイメージ(ちなみにファイルサイズは81MBほど)の入手先はリリースノートに示されている。Bittorrentのtrackerも用意されている。
なお、既にいくつかのErrataが公表されているので、インストールしてみようという人はあらかじめ確認した方が良いだろう。

過去のストーリー

• DragonFly BSD 1.2.0リリース
• DragonFly BSD 1.0 リリース

"

dntpd

[deleted user (19654)]

おお、dntpd すごそうですね!

commits List 2005-04 [dragonflybsd.org]:

OpenNTPD はそもそも、あんまり精密に時刻を同期させるような仕組みではない。 Joerg が頑張ってハックしてくれているけど、まだまだ大変みたいだ。 その労を念頭に置きながら書いてみたら、一日で少なくとも xntpd と同じ程度 (つまり OpenNTPD よりだいぶまし) なアルゴリズムができた。 まだいろいろあるけど、最も厄介なところはできたよ。 時刻を同期させるだけだから単純かと思うけど、面倒なんだね。

users List 2005-11 [dragonflybsd.org]:

OpenNTPD は、はっきり言って使えないね。バグとかじゃなくて、 アルゴリズムが悪い。ただ適当に時刻を修正するだけであって、 統計を使ってドリフトを埋めたりしていないんだ。これじゃあ、 もともと誤差が少ない状況でしか動作しない。 dntpd なら、ノイズを除いてきちんと計算した データから、しっかりオフセットとドリフトを出して修正するぜ。

みたいな感じかな?

Re:dntpd

[deleted user (19654)]

ただ、OpenBSD 陣営の名誉のために言っておくと、確かに
OpenNTPD は簡易なもの [openntpd.org]として設計されています。
あまり精密さを求めたり本格的な NTP サーバにするというのではなく、
「面倒だからだれも NTP を使わない」という状況を正すための、
そしてそれだけのためのものなのです。

Re:dntpd

[tyuu (9154)]

> 「面倒だからだれも NTP を使わない」という状況を正すための

最近、「面倒だからだれも NTP を使わない」
というサーバにお目にかかりました。
10 分違っていて log の解析時に思考が停止しました。

時間精度が低いと、ロードバランサー配下のサーバ log 調査時、労力が高くなります。
# ntpd が動いてなかったのは問題外ですが

OpenNTPD が簡易なものであり、
dntpd がちゃんとした物であるなら
secure であると診断してもらって
OpenBSD に取り込んで欲しいです。
# もちろん Free, Net にも。

# xntpd のフォローは無いんですかね？

Re:dntpd

[shojin (28072)]

取り敢えず、下記で公開されているソースコードを
使って、FreeBSDでコンパイルできることは確認しましたが
sysctlにkern.basetimeが無いので実行は出来ないです。

そこで、これとSYSCTLマクロ宣言や扱いが似ている
kern.boottimeを使うようにしてお茶を濁すと実行は
できますが、果たしてこれで良いのか...
(FreeBSDのkern.boottimeが入り組んでて訳わからんもんで)

http://www.dragonflybsd.org/cgi-bin/cvsweb.cgi/src/usr.sbin/dntpd/ [dragonflybsd.org]

Re:dntpd

[deleted user (19654)]

boottime はブートした時刻なので変化しませんが、
dntpd は kern.basetime を何度も取得して差を出したり
しているみたいです (client.c の lin_regress あたり?)。

clock_gettime(CLOCK_MONOTONIC, &ts); とかに
書き換えたほうが意図に合っているのかなあ。

Re:dntpd

[Anonymous Coward]

私も FreeBSD 上で試してます。

sysntp_getbasetime の中身を gettimeofday(tvp, NULL); にして、dntpd -d -f dntpd.conf としてデバッグモードで起動して確認した所、slope の値が、-1.000004 とかみたいな値になっていました。

kern.basetime の代わりに、kern.boottime を使うパターンだと、slope は、大体 0.00005 とかあたりで安定。

恐らく後者の方が動作がより近いと思うので、kern.basetime は基本的にはいつも変わらない数値なのだけど、別のユーティリティが書き換える可能性があるって事なのかな。dntpd のソース群の中にはkern.basetime を書き換えるような動作は見られないし。

しかし、lin_regressのslopeを求める式をみてもよくわかりません。例えば、(info->lin_count * info->lin_sumxy - info->lin_sumx * info->lin_sumy) とか、(info-lin_count - 1) * info_lin_sumxy じゃ駄目なのかとか。

Re:dntpd

[Anonymous Coward]

#863433 [srad.jp]のACです。

今までためしにkern.basetimeをboottimeに書き換える方法でntpサーバーを一つだけ指定して動かしてみたところ、誤差がはげしくなっていました。10秒以上ずれていました。

FreeBSDのxntpdやntpdateのソースと比べて確認してみないといけないか。

Re:dntpd

[deleted user (19654)]

さいきん OpenNTPD に Dragonfly っぽいアルゴリズムが取り込まれたようです。
最新のsnapshot [iij.ad.jp] をお試しください。

adjusting clock frequency by xxxx to xxxxppm

というログが出てきていたら良いようです。
私はいま更新したばっかりなので、あと数日したら違いが出てくるのかなぁーと期待しています。

なお、 ntpd だけじゃなくて kernel も最新じゃないとダメです。
adjfreq というシステムコールが必要なんですね。

man adjfreq してみたら

HISTORY
     The adjfreq() function call first appeared in OpenBSD 4.0.

って出てきました。

Re:dntpd

[Anonymous Coward]

きちんと統計を取っても、ＰＣの設置場所の温度が昼夜間で変動する様だと(水晶発信器自体がつられて変動するので)意味無い様な…。

Re:dntpd

[Anonymous Coward]

その場合、統計手法の意味はないかもしれませんね。たしかに。
しかしそんな環境では単に統計手法がキャンセルされるだけでしょうから、
dntpdに切り替えてはいけない理由にはなりませんね。
単にOpenNTPDと同じ程度の精度になるだけ。

Re:dntpd

[deleted user (19654)]

＞OpenNTPD が簡易なものであり、
＞dntpd がちゃんとした物であるなら
＞secure であると診断してもらって
＞OpenBSD に取り込んで欲しいです。

OpenBSD の場合は sys/kernel/kernel_time.c が
あまりにも違うので、そのままでは無理みたいですね。
ユーザランドだけでうまくできるなら
いつの間にか入っていたりするかもしれませんが。(^^;

Re:dntpd

[Anonymous Coward]

どんなアルゴリズムなのか見てみたいのだけど、DragonFly BSDってCVS公開してないの？お手軽にdntpdのソースだけ見られたらうれしいのだけど。

Re:dntpd

[Anonymous Coward]

事故レス。発見。これか [dragonflybsd.org]。allbsd.orgのはこれ [allbsd.org]ですね。client.cか。

Re:dntpd

[akky-i (3905)]

allbsd.org辺りを見ると幸せになれる、かも。

ports と pkgsrc の違い

[tyuu (9154)]

> # FreeBSDのportsシステムは、1.4.0ではサポートされない。

具体的にどこが違うのか良くわかってないんですが、
pkgsrc の長所・短所がまとまっている所ありませんか ?

生駒日記 [smalltown.ne.jp] さんにたどりついたのですが Vine/Kondara/Gentoo を知らないので、
ピンと来ませんでした。

使ってみると、OpenBSD の ports はどちらかというと運用面では Gentoo の portage に近い気がする。
パッケージをいったん仮想ルートディレクトリにインストールしてパッケージングしてから本体にインストールする、
というところも portage に似ている。
FreeBSD の ports は package 作るだけでもいったんシステムにインストールしないといけないのが困る。

FreeBSD と NetBSD と OpenBSD の違いは Red Hat と Vine と Kondara くらいの違いかと思っていたら、
Slackware と Debian と Gentoo くらいの違いはあるように考え直した。

Re:ports と pkgsrc の違い

[apt (28270)]

Red HatとVineとKondaraの違いというのは、どれもパッケージマネージャとしてrpmを使っているけれども、
その外に被さっている管理ツールがup2date, apt-rpm, mph-rpmと異なっているという点を指しているのでは。

それに対して、SlackwareとDebianとGentooの違いというのは、そもそもパッケージマネージャが全然違う
(pkgtool, dpkg, portage)という点を指しているのでしょう。

Re:ports と pkgsrc の違い

[Anonymous Coward]

パッケージマネージャの違いは大きいですけど，指摘されているのはそれだけじゃないのでは？
リンク先の記述では，インストーラも意識しているようですし，それ以外のニュアンスも含めた
指摘かと思いました．

えーと，おちゃらけ度とか？

Re:ports と pkgsrc の違い

[Anonymous Coward]

最大の長所は、NetBSD以外のプラットフォームに対応していることだと思います。
DragonFlyへの対応も、基本的な部分はごく簡単に完了したようです。
DragonFly以外にもSolaris、Mac OS X、AIX、IRIXでも使えます。

短所は、binary packageの提供が不足していること、
クロスコンパイルができないこと、
OpenBSD Portsのようにstaged installation（一旦仮想ルートにインストール）ができないこと、など。

Re:ports と pkgsrc の違い

[urandom (26447)]

> クロスコンパイルができないこと、
それって、結構たいへんそうな。

> OpenBSD Portsのようにstaged installation（一旦仮想ルートにインストール）ができないこと、など。
代わりに pkg_comp を使う手はあります。本ちゃんインストールしないでバイナリ・パッケージを作成したり、
違うリリース(正確には古い)のNetBSD用のバイナリ・パッケージを作成したり、といったことができます。

お約束。

[KENN (3839)]

bsd-family-tree [freebsd.org]も更新された模様。

期待できます。

[Anonymous Coward]

ちゃくちゃくと進歩してますね～。

国際化

[Anonymous Coward]

rune と citrus の違いってどこかにまとまっていないですかね。

Re:国際化

[KENN (3839)]

ぐぐって見ただけですが、itojun氏がUSENIXで発表した資料 [usenix.org](スライドはこちら [itojun.org])辺りはどうですか？