FreeBSDを語れ Part21

**名無しさん＠お腹いっぱい。** · 2008/08/15(金) 15:37:54

FreeBSDについて語るスレです。

The FreeBSD Project
http://www.freebsd.org/ja/

前スレ：FreeBSDを語る #20
http://pc11.2ch.net/test/read.cgi/unix/1209628424/

**名無しさん＠お腹いっぱい。** · 2008/11/25(火) 22:12:59

オレも、彼女ができるまでは童貞だった。
結婚してからも、妻と、元彼女と、元々彼女と、今のセフレ以外は童貞だ。

**名無しさん＠お腹いっぱい。** · 2008/11/25(火) 22:15:17

思い出に残るセックス

**名無しさん＠お腹いっぱい。** · 2008/11/26(水) 01:58:32

確かに俺もセックスした相手以外は童貞だな。

**名無しさん＠お腹いっぱい。** · 2008/11/26(水) 11:49:03

ZFSってちょっと速いだけでリスクが高すぎるんじゃないのか?
その処理分メモリードライブ(古い言葉遣い)を作って
いるところにシンボリックリンクをはって定期的か明示的に反映するとかの方が
いいと思う。(オリジナルはリネーム)
大量メモリーもってないからやってないけどportsのビルドとか顕著じゃないのかな

**名無しさん＠お腹いっぱい。** · 2008/11/26(水) 12:41:49

>>456
ZFSはExperimentalだし動かなくとも仕方ない。

**名無しさん＠お腹いっぱい。** · 2008/11/26(水) 13:11:00

おい
てっきりイブの夜に～スレだと思って
ZFSとか何こいつらスレ違いやってんの？とか書くところだったわｗ

**名無しさん＠お腹いっぱい。** · 2008/11/26(水) 18:08:33

RELENG_6_4_0_RELEASE登場！

**名無しさん＠お腹いっぱい。** · 2008/11/26(水) 18:11:15

7.1もやっとブランチ用意されたね。

**名無しさん＠お腹いっぱい。** · 2008/11/26(水) 18:18:38

メモリ、1GBあたり1000円切ってるのかよ……

**名無しさん＠お腹いっぱい。** · 2008/11/26(水) 19:49:53

11月に違いはなかったか。

**名無しさん＠お腹いっぱい。** · 2008/11/26(水) 21:19:43

>>456
むしろ遅いという話が多い気がするぜ

もうdat落ちしてるZFSスレで散々語られていた気がするけど

**名無しさん＠お腹いっぱい。** · 2008/11/26(水) 23:06:44

速いんじゃなく堅牢性・柔軟性・管理性を
求めるものだろ > ZFS

**名無しさん＠お腹いっぱい。** · 2008/11/27(木) 01:52:42

ZFS って VM と filesystem が中途半端に融合している感じがしてどうもねぇ。。
VM だけ、FS だけ的な使い方が出来ればいいんだけど

**名無しさん＠お腹いっぱい。** · 2008/11/27(木) 09:15:31

>465
確かに従来の FS のイメージではそう思うかもしれないし
私もそう感じないわけでもない

でもそこをきれいに切り分けしようとしすぎるのも
いけないんじゃないかとも思うようになった

たとえば RAID とかの冗長性は必ずしも volume manager 的レベルで
実現されるべきではなく、file system レベルで行われた方が
効率的(存在するファイルの分だけやればいいとか)な面もあるし
現在の分かれ方も歴史的に当時はその分け方がきれいだったという
以上の意味はないんじゃないかな。
たとえば ZFS は VM 相当のレベルでの RAID 機能を提供しているけど
copies=1or2or3 で RAID1 的機能を FS レベルでも提供可能になってる。
どうせなら RAID5/6 的な copies+ 機能も
あってもいいんじゃないかと思ったり。

今後 ZFS やその他ライバル群(HAMMERとか?)が興隆してくると
もしかすると新たな切目とかができるのかもしれないけど

**名無しさん＠お腹いっぱい。** · 2008/11/27(木) 18:34:33

まだ何もファイルを置いてないのに、RAID構築時に全部コピーするとか
一度ZFS使っちゃうとそんな時代には戻りたくないよ

**名無しさん＠お腹いっぱい。** · 2008/11/27(木) 23:38:27

もうカーネルメモリ不足でいきなりpanicする*バグ*は直ったん？

チューニング次第とか言うけど、絶対安全なラインが引けない以上、
バグと言うべきだと思う。

**名無しさん＠お腹いっぱい。** · 2008/11/27(木) 23:43:39

>>468
具体的にどんなことするとpanicするの？

**名無しさん＠お腹いっぱい。** · 2008/11/27(木) 23:47:44

カーネルパニックは、遭遇することないけれど、
デッドロックのバグは、たまにあるな(´･ω･`)

**名無しさん＠お腹いっぱい。** · 2008/11/28(金) 00:03:30

ZFSあたりでもろメモリ足りなくなってパニックになる人多発してたから
直ってないんじゃね？

**名無しさん＠お腹いっぱい。** · 2008/11/28(金) 09:44:44

gjournalってGEOMのだから、ファイルシステムのジャーナルじゃなくてデバイス丸ごとのジャーナルだよね？
なんでnewfsやtunefsでgjournalを有効にする必要があるの？

**名無しさん＠お腹いっぱい。** · 2008/11/28(金) 09:49:17

ジャーナル領域が少ないとpanicするgjournalもバグだよな
FreeBSDっていい加減だ

**名無しさん＠お腹いっぱい。** · 2008/11/28(金) 11:27:28

安全が確保できる量を現実的な範囲で見積れるなら、バグでなく
チューニングパラメータと言って良いけど、それができないならバグ。

**名無しさん＠お腹いっぱい。** · 2008/11/28(金) 13:24:36

http://gihyo.jp/admin/clip/01/fdt/200811/20
> failure modes
> 以前は書き込み要求が失敗した場合にはシステムはパニックしていましたが，
> 今回パニックモード（panic）以外にもディスクが現れるのを待つモードと (wait)，
> 書き込み要求をブロックして可能であれば読み込み要求だけを処理する
> モード(continue)が追加されました。

ってのはメモリ不足話じゃないから違うのかな?

確か ZFS のメモリ不足問題は amd64 ではあまり問題なくて
i386 は(元の ZFS コードが 32bit 環境を
もうほとんど考慮していないから)無理っぽいって
話だと思ったけど amd64 でも×なんだっけ?

**名無しさん＠お腹いっぱい。** · 2008/11/28(金) 13:43:50

何も考えずUFS2にしとけって

**名無しさん＠お腹いっぱい。** · 2008/11/28(金) 15:54:45

それで済むなら最初から ZFS の話なんてしないのさ

**名無しさん＠お腹いっぱい。** · 2008/11/28(金) 16:27:30

>>476は老人
>>477は若者

**名無しさん＠お腹いっぱい。** · 2008/11/28(金) 16:33:29

6.4-RELEASE

**名無しさん＠お腹いっぱい。** · 2008/11/28(金) 18:18:15

UFS2のタイムスタンプを2050年にする方法がわからん
まさかごみEXT3同様2038年問題があることもないと思うけれど
touchとかで32bitしか設定できずしょぼん。

**名無しさん＠お腹いっぱい。** · 2008/11/28(金) 19:20:55

何だ未来人か？

**名無しさん＠お腹いっぱい。** · 2008/11/28(金) 23:14:01

時間がらみのテストとかしてんじゃないのか？

**名無しさん＠お腹いっぱい。** · 2008/11/28(金) 23:33:29

>>479
Copyright (c) 1980, 1983, 1986, 1988, 1990, 1991, 1993, 1994
The Regents of the University of California. All rights reserved.

FreeBSD 6.4-RELEASE (opoona) #6: Fri Nov 28 15:43:25 JST 2008

Welcome to FreeBSD!

Before seeking technical support, please use the following resources:

o Security advisories and updated errata information for all releases are
at http://www.FreeBSD.org/releases/ - always consult the ERRATA section
for your release first as it's updated frequently.

**名無しさん＠お腹いっぱい。** · 2008/11/29(土) 00:58:10

>>483

　　　　　　　　／￣＼
　　　　　　　　|　　　　|
　　　　　　　　＼＿／
　　　　　　　　　　|
　　　　　　／￣￣　＼
　　　　　／　　＼　／　　＼
　　　／　　 ⌒　　　⌒ 　　＼　　　　　　
　　　 |　　　　（__人__）　　　　|　　　　　　褒美としてオプーナを買う権利をやる
　　　＼　　　｀ ⌒´　　　　／　　　☆
　　　　/ヽ､--ー､＿＿,-‐´　＼─／
　　／　> 　　ヽ▼●▼<＼　　||ｰ､.
　 / ヽ､　　　＼ i　|｡|　|/　ヽ　(ニ､｀ヽ.
　.l　　　ヽ　　　 l　|｡|　| ｒ-､y　｀ﾆ　ﾉ＼
　l　　　　 |　　　|ー─ | ￣ l 　　｀~ヽ＿ノ＿＿＿_
　　　　／￣￣￣￣ヽ-'ヽ--'　　／　オプーナ　／|
　　　.|￣￣￣￣￣￣|／|　　　 |￣￣￣￣￣￣|／| ＿＿＿＿＿＿
／￣オプーナ／|　￣|__」／_オープナ　　／|￣|__,」＿＿_　　　　／|
|￣￣￣￣￣|／オプーナ￣／￣￣￣￣|／オープナ／|　　／　.|
|￣￣￣￣￣|￣￣￣￣￣|／l￣￣￣￣|￣￣￣￣￣|／|　／
|￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣|

**名無しさん＠お腹いっぱい。** · 2008/11/29(土) 02:25:55

OpoonaBSD

**名無しさん＠お腹いっぱい。** · 2008/11/29(土) 04:21:57

大きなバージョンアップをせずに、ちょっとずつ修正し続けてるLinuxと違って
FreeBSDはちゃんと段階踏んで開発してるから、変なバグの入り込む余地が少なくていいね
最初からこっち勉強すればよかった

**名無しさん＠お腹いっぱい。** · 2008/11/29(土) 04:31:24

両方勉強するのがいいよ。片方だけだとどうしても視点が偏る。

**名無しさん＠お腹いっぱい。** · 2008/11/29(土) 11:18:04

>>482
時間指定したファイルを用意しておいて
それを読んで状況判断して作業するテストの下準備

例えばportのビルドも作業終了をファイルでフラグにしている。

**名無しさん＠お腹いっぱい。** · 2008/11/29(土) 13:13:19

struct stat の st_mtime を sizeof したら 4 だし、無理じゃね？

**名無しさん＠お腹いっぱい。** · 2008/11/29(土) 16:36:11

6.4R出たことだし、7.1は一旦キャンセルしてports凍結の完全解除してくりゃれ

**名無しさん＠お腹いっぱい。** · 2008/11/29(土) 16:46:14

>>489
AMD64だとtime_tは8だぞ

**名無しさん＠お腹いっぱい。** · 2008/11/29(土) 16:53:18

/tmp% mount
/dev/ad4s1a.journal on / (ufs, asynchronous, local, gjournal)
devfs on /dev (devfs, local)
/tmp% touch -t 205010101010 foo
/tmp% ls -l test
-rw-r--r-- 1 tester wheel 0 10 10 2050 foo

というかAMD64ならUFS2？で何の問題もなく2050年10月10日に設定できたぜ

**名無しさん＠お腹いっぱい。** · 2008/11/29(土) 16:53:34

>>491 64bitってことですね、
悪いけれどAMD64でtouchでファイルの日付ちょっと変えてみて
ファイルシステム自体がintかそうでないかたしかめてくれませんかねぇ。
とりあえず2038年にして元にもどすとか
でできるならば32bit版でもtouchではだめでもCとかで操作できるはず
それにしても別にディスクアクセスなんてバイトオーダーなんだから
4byteでも5byteでも8byteでもかまわないのに...

**492** · 2008/11/29(土) 17:14:50

2050年にしてから戻すのも問題ないようだ。
ドラえもんの生まれた年でも、9999年でも問題ない。
touchはそのインターフェース上10000年問題を抱えてるが、
きっとプログラム書けば292277026596年までいけるんだろう。

ちなみに 7 STABLE (今年の10月ぐらいの)

**名無しさん＠お腹いっぱい。** · 2008/11/29(土) 17:16:43

i386だと time_t が4バイトだから、
utime(2) も stat(2) も、
APIとして64ビットのファイル日時設定・取得ができない。
デバイスを直接いじるなら別だろうけど。

**名無しさん＠お腹いっぱい。** · 2008/11/29(土) 17:41:01

488 = 493 ダス
493カキコしたときに>>492でてなかったのでちょっと493の内容がおかしい

要するにUFS2としては時間フィールドは64bitで
i386用時間関数が現時点でtime_t型依存でtouchもできないってことですね、
ファイルシステム自体が対応しているならまぁあせることはないか。
別に32bitOSが64bit扱えないはずもないのでちょっと調べてみる。
つーか変な機能よりこういうところとっとと関数を64bit化してほしいけど
互換性を考慮しているのかな?

**名無しさん＠お腹いっぱい。** · 2008/11/29(土) 22:30:35

64bit化よりも、AMD64使えってスタンスなんじゃね？

**名無しさん＠お腹いっぱい。** · 2008/11/29(土) 22:38:19

API変えちまったら、バイナリ全部死亡だから、洒落にならん。
i386→amd64と同じ手間かけるなら、amd64に行けということだな。

**名無しさん＠お腹いっぱい。** · 2008/11/30(日) 04:48:23

>>490
そやね、もしZFSがらみだと相当遅れるだろうし。

**名無しさん＠お腹いっぱい。** · 2008/11/30(日) 09:53:29

gerald 2008-11-23 20:53:10 UTC
Update to Wine 1.1.9. Among others, this includes the following changes:
--
It also fixes the "Invalid address" issue reported by some users, at least
according to my testing.
wineのアレは直ったみたいだ。

**名無しさん＠お腹いっぱい。** · 2008/11/30(日) 11:42:03

i386で64bit化しても上位がedxにのるだけだからかわらんだろう。
バイナリ全部死亡とかいうけれどバージョン変わったらどうせそうだし
2008年段階で対応していない事自体おかしい。

まぁとりあえずファイルシステムは対応しているので
ツール作ればどうにかなりそうですなぁ。
言語は使い方しだいで問題ないので環境変数とかで「basetime」をもつのが
無難な方法かな?

**名無しさん＠お腹いっぱい。** · 2008/11/30(日) 11:54:19

>>500 その日付のバージョンはダメなり

**名無しさん＠お腹いっぱい。** · 2008/11/30(日) 12:19:02

>>501
バージョン変わったくらいなら古いバイナリ動くだろ。
ライブラリのバージョンが問題なだけで、
システムコールのAPIがなくなるわけじゃない。

> ツール作ればどうにかなりそうですなぁ。
そんなので済むように見えないけど。
システムコールわかってなさそう。

**名無しさん＠お腹いっぱい。** · 2008/11/30(日) 12:27:25

amd64使えばいいじゃない

**名無しさん＠お腹いっぱい。** · 2008/11/30(日) 12:42:08

バイナリ互換は従来のエントリをold_statとか互換APIに割り当てればOK.

**名無しさん＠お腹いっぱい。** · 2008/11/30(日) 14:05:00

>>503
「表示」の整合性なんて全然問題ないだろう。
FreeBSD自体が未対応ならツールで対応するしかない。
実際表示なんて0-138を 1900-2038にしているだけだろ。
言語系がユリウス歴とか実数型、レコード型なんだから
タイムスタンプや現時刻取り入れ時に補正一発入れればいいだけ
システムコールをいじったっていいけれど
極めて簡単なレベルで整合性が取れるってことだ。

**名無しさん＠お腹いっぱい。** · 2008/11/30(日) 14:18:56

>>506
> 実際表示なんて0-138を 1900-2038にしているだけだろ。
何を言っているのか理解できない。

**名無しさん＠お腹いっぱい。** · 2008/11/30(日) 14:34:18

>>504 AMD64しか使えないOSですか?
10年たったらAMD128でしょう。i386は残る。

とりあえず専用コマンド作って2038年の次は2039年になった。
単に下位リミットつけて加算してから代入するだけ
perlとかでもDateTimeを使うより速い。
素直にデータベースとか圧縮ファイルにすればもっと楽だと思う。
例えばzip書庫(無圧縮)であれば問題なく2050年にできる。
ベースタイム方式は標準コールでの表示は1920年とかになるけれど
ちょっとずつ置換すれば実害ない。
UFS2のタイムスタンプが31bit以上でよめるようになったら
それを一括修正するのは簡単だしアーカイブ形式での移行でもいいや。

**名無しさん＠お腹いっぱい。** · 2008/11/30(日) 14:53:12

>>507 perlでtimeから変換してみ

**名無しさん＠お腹いっぱい。** · 2008/11/30(日) 15:00:20

俺もますますわからん。

time って何だ？
何に変換するんだ？
そもそもなぜに perl？

**名無しさん＠お腹いっぱい。** · 2008/11/30(日) 15:43:33

2038年問題に危機を感じるような人が2008年時点でi386使ってるほうがおかしい

**名無しさん＠お腹いっぱい。** · 2008/11/30(日) 17:02:42

ワロッシュｗ

**名無しさん＠お腹いっぱい。** · 2008/11/30(日) 20:09:33

世間のサーバーでi386がたくさんる現実無視してFreeBSDでなにすんの?
発言内容からして1970年とか1900年の意味もわからなそう。
別に知らなくてもいいけれどリミットはあまりにも近いから
「拡大」ではなくて閾値対策が必要。それとNTPも

perlであれば管理できないPCでも表記の日付を制御できるって発想はないのかな。

とりあえずUFS2にダイレクトにアクセスするツールもほしいところだけれど
ちょっと勉強不足なんで目先の対応をしてみたわけさ。
設定とかファイル一覧とか比較とかちょっとしたフィルター入れるだけで実用上は問題がでない。

でも多分longintをlongWordにすれば目先インターフェースでの補正もいらないかんじかな。

なんやかんやでファイルの時間の幅が広いものはZipで管理する方が
互換性も高く楽だというのが分かる人への結論

**名無しさん＠お腹いっぱい。** · 2008/11/30(日) 20:16:42

だんだん壊れてきてるな

**名無しさん＠お腹いっぱい。** · 2008/11/30(日) 20:28:04

> 1900年の意味
> 閾値対策が必要
> それとNTPも
> 表記の日付を制御できる
> longintをlongWordにすれば
> 目先インターフェース
> ファイルの時間の幅が広いものはZipで管理

さっぱりわからん。

**名無しさん＠お腹いっぱい。** · 2008/11/30(日) 20:45:38

またヤツが来たか…

**名無しさん＠お腹いっぱい。** · 2008/11/30(日) 21:48:29

>>515
> さっぱりわからん。
つまりZIPでくれ、って事じゃね?

**名無しさん＠お腹いっぱい。** · 2008/11/30(日) 22:57:23

>>513
tanasinn?

**名無しさん＠お腹いっぱい。** · 2008/11/30(日) 23:44:45

謎ｗ

**名無しさん＠お腹いっぱい。** · 2008/11/30(日) 23:56:42

time_t が 32bit だと
計算の途中でおかしくなることもあるだろｗ

**名無しさん＠お腹いっぱい。** · 2008/12/01(月) 00:25:12

何のどういう計算？

**名無しさん＠お腹いっぱい。** · 2008/12/01(月) 01:28:08

>>494
それは宇宙が滅びてる年

**名無しさん＠お腹いっぱい。** · 2008/12/01(月) 03:19:59

やっとこさ、6.4 RELEASEが出たね。

**名無しさん＠お腹いっぱい。** · 2008/12/01(月) 11:10:33

>>502
gerald 2008-11-24 06:45:20 UTC
Add libXrender as another dependency. Among others this should improve
the appearance of Firefox.
ならOKってこと? うちではこれでも駄目だった。また1.1.7,1に戻した。

**名無しさん＠お腹いっぱい。** · 2008/12/01(月) 15:04:55

7.1まだ？待ってるんですけど。

**名無しさん＠お腹いっぱい。** · 2008/12/01(月) 17:22:44

>>524
emulationMLによると大地さんも話題にしてた
あのパッチはうまく行きそうだが、バカンス中なので
もうちょっとまっててねーbyげらるど
とかいうことになってるっぽいけど。

**名無しさん＠お腹いっぱい。** · 2008/12/01(月) 17:57:02

10.0が出たら本気出す

**名無しさん＠お腹いっぱい。** · 2008/12/02(火) 00:37:09

NetBSDはsoftdep消しちゃったんだ
早いねぇ

**名無しさん＠お腹いっぱい。** · 2008/12/02(火) 00:57:45

>>528
半年前から決まっていたようなものだから早いという感じはしないな。

**名無しさん＠お腹いっぱい。** · 2008/12/02(火) 13:01:56

>>525
来年２月に名前を変えて出します。

**名無しさん＠お腹いっぱい。** · 2008/12/02(火) 14:45:15

>>520 1970/1/1 を 0 それ以前がマイナスとしているのが現在のファイルタイム(stat)
マイナスを扱わないのが現時刻(NTP)など
これをまずつまりUNIX時間　0秒のユリウス時間として環境変数に定義して
次に32bit値をLongIntとして取るかLongWordとして取るかのベクター値を環境変数にもたせる。
標準関数はLongIntとしている。現時点で1970年以前を変換するが
実質OSが1970年以前を扱えないのでLongWordとして扱う。
2038年を越えたら任意のタイミングで1970+2^32秒後を新しいベース時間にしてLongIntにすればいい。
そうすることで64bit化したときも互換性がでる。

ファイル内部の値は今までとかわりがないから
ユーザーインターフェース系のstatとかtouch,findとかそういうのにちょいと
スクリプトかぶせればいいというわけ

**名無しさん＠お腹いっぱい。** · 2008/12/02(火) 14:50:09

8系が見えていると安定している7.0から7.1には移りづらい気がする。

**名無しさん＠お腹いっぱい。** · 2008/12/02(火) 15:11:53

64bit time_tにしたらtime_tがらみのシステムコール番号新しくすりゃいいんじゃね？
古いやつはCOMPAT_xxx入れないと有効にならないとか

**名無しさん＠お腹いっぱい。** · 2008/12/02(火) 20:00:37

構造体に対するアクセスの問題なのでシステムコールはあんまり関係ないんだけれど
mktimeとかそういう部分が引っかかるだけ、あとアプリ関連個別
通常時呼ぶのは秒単位の時間ではなくてミリ単位のクロックと
CPUベースのクロックでCPUベースのクロックはマルチコアだとうまく動作しない。
それらも32bitと64bitは単にレジスタにのっけるだけで幅の差だから
コンパチとかではなくて同じ仕様の別CPU対応ということになる。

**名無しさん＠お腹いっぱい。** · 2008/12/02(火) 20:10:42

そもそもi386前提で話をしてるのがおかしい。
sparc64は？

**名無しさん＠お腹いっぱい。** · 2008/12/02(火) 20:17:39

1970年にはFreeBSDはなかったのでLongWord対応でよいじゃあないの。と
±10年設定できれば大抵はすむだろうからこれは「FreeBSDを語る」
以外の何者でもない。
不正ファイルやシステムクロックやNTPの障害の影響を受けないことに意味がある。
touch2とstat2とかで未来の日付を扱えることに安堵感を感じることに意義がある。

**名無しさん＠お腹いっぱい。** · 2008/12/02(火) 20:37:03

>>534
何言ってるの

**名無しさん＠お腹いっぱい。** · 2008/12/02(火) 20:46:11

俺には >>531, >>536 も何を言っているかわからない。

**名無しさん＠お腹いっぱい。** · 2008/12/02(火) 21:09:40

意味不明文章作成スクリプトが襲来しているだけですので
スルーで。

**名無しさん＠お腹いっぱい。** · 2008/12/02(火) 21:16:20

なかなか優秀なスクリプトだな。

**名無しさん＠お腹いっぱい。** · 2008/12/02(火) 21:44:48

ブログを開設してパッチを貼るくらいには賢くなってくれないと。

**名無しさん＠お腹いっぱい。** · 2008/12/02(火) 22:31:20

http://www.jp.freebsd.org/　って、もう更新しないんですか？

**名無しさん＠お腹いっぱい。** · 2008/12/02(火) 22:37:05

>>535
こちらへどうぞ。
http://pc11.2ch.net/test/read.cgi/unix/1096032708/

**名無しさん＠お腹いっぱい。** · 2008/12/02(火) 22:42:32

7.1予定通り来年二月のようだな

**名無しさん＠お腹いっぱい。** · 2008/12/02(火) 22:44:54

そうだな、順調に行って四月にはお目にかかれそうだ

**名無しさん＠お腹いっぱい。** · 2008/12/03(水) 00:01:51

来年は 8.0 (June 2009)が来る予定になっているんだぞ!

**名無しさん＠お腹いっぱい。** · 2008/12/03(水) 00:14:22

8-currentも順調に進んでいるんだから
7.1Rのスケジュールがいくら順調だからって
>>546の懸念は杞憂だとおもうよ。
ちゃんと8.0Rも来年いっぱいまで掛からずに
出てくれるさ。

**名無しさん＠お腹いっぱい。** · 2008/12/03(水) 00:44:18

俺の予想だと8.0Rは2010年春だな

**名無しさん＠お腹いっぱい。** · 2008/12/03(水) 00:51:44

それじゃあスケジュールどおりじゃないか

**名無しさん＠お腹いっぱい。** · 2008/12/03(水) 06:30:08

だからあらゆる意味でスケジュール通りｗ

**名無しさん＠お腹いっぱい。** · 2008/12/03(水) 08:10:13

予定通りだ、問題ない(w

**名無しさん＠お腹いっぱい。** · 2008/12/03(水) 09:05:11

ZFS新版は早く実用的に試したいから
RELENG_8 が早く登場するといいなぁ…