1 名前:名無しさん@お腹いっぱい。 [2008/08/15(金) 15:37:54 ] FreeBSDについて語るスレです。 The FreeBSD Project www.freebsd.org/ja/ 前スレ:FreeBSDを語る #20 pc11.2ch.net/test/read.cgi/unix/1209628424/
459 名前:名無しさん@お腹いっぱい。 mailto:sage [2008/11/26(水) 18:08:33 ] RELENG_6_4_0_RELEASE登場!
460 名前:名無しさん@お腹いっぱい。 mailto:sage [2008/11/26(水) 18:11:15 ] 7.1もやっとブランチ用意されたね。
461 名前:名無しさん@お腹いっぱい。 mailto:sage [2008/11/26(水) 18:18:38 ] メモリ、1GBあたり1000円切ってるのかよ……
462 名前:名無しさん@お腹いっぱい。 mailto:sage [2008/11/26(水) 19:49:53 ] 11月に違いはなかったか。
463 名前:名無しさん@お腹いっぱい。 mailto:sage [2008/11/26(水) 21:19:43 ] >>456 むしろ遅いという話が多い気がするぜ もうdat落ちしてるZFSスレで散々語られていた気がするけど
464 名前:名無しさん@お腹いっぱい。 mailto:sage [2008/11/26(水) 23:06:44 ] 速いんじゃなく堅牢性・柔軟性・管理性を 求めるものだろ > ZFS
465 名前:名無しさん@お腹いっぱい。 mailto:sage [2008/11/27(木) 01:52:42 ] ZFS って VM と filesystem が中途半端に融合している感じがしてどうもねぇ。。 VM だけ、FS だけ的な使い方が出来ればいいんだけど
466 名前:名無しさん@お腹いっぱい。 mailto:sage [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とか?)が興隆してくると もしかすると新たな切目とかができるのかもしれないけど
467 名前:名無しさん@お腹いっぱい。 mailto:sage [2008/11/27(木) 18:34:33 ] まだ何もファイルを置いてないのに、RAID構築時に全部コピーするとか 一度ZFS使っちゃうとそんな時代には戻りたくないよ
468 名前:名無しさん@お腹いっぱい。 mailto:sage [2008/11/27(木) 23:38:27 ] もうカーネルメモリ不足でいきなりpanicする*バグ*は直ったん? チューニング次第とか言うけど、絶対安全なラインが引けない以上、 バグと言うべきだと思う。
469 名前:名無しさん@お腹いっぱい。 mailto:sage [2008/11/27(木) 23:43:39 ] >>468 具体的にどんなことするとpanicするの?
470 名前:名無しさん@お腹いっぱい。 mailto:sage [2008/11/27(木) 23:47:44 ] カーネルパニックは、遭遇することないけれど、 デッドロックのバグは、たまにあるな(´・ω・`)
471 名前:名無しさん@お腹いっぱい。 mailto:sage [2008/11/28(金) 00:03:30 ] ZFSあたりでもろメモリ足りなくなってパニックになる人多発してたから 直ってないんじゃね?
472 名前:名無しさん@お腹いっぱい。 mailto:sage [2008/11/28(金) 09:44:44 ] gjournalってGEOMのだから、ファイルシステムのジャーナルじゃなくてデバイス丸ごとのジャーナルだよね? なんでnewfsやtunefsでgjournalを有効にする必要があるの?
473 名前:名無しさん@お腹いっぱい。 mailto:sage [2008/11/28(金) 09:49:17 ] ジャーナル領域が少ないとpanicするgjournalもバグだよな FreeBSDっていい加減だ
474 名前:名無しさん@お腹いっぱい。 mailto:sage [2008/11/28(金) 11:27:28 ] 安全が確保できる量を現実的な範囲で見積れるなら、バグでなく チューニングパラメータと言って良いけど、それができないならバグ。
475 名前:名無しさん@お腹いっぱい。 mailto:sage [2008/11/28(金) 13:24:36 ] gihyo.jp/admin/clip/01/fdt/200811/20 > failure modes > 以前は書き込み要求が失敗した場合にはシステムはパニックしていましたが, > 今回パニックモード(panic)以外にもディスクが現れるのを待つモードと (wait), > 書き込み要求をブロックして可能であれば読み込み要求だけを処理する > モード(continue)が追加されました。 ってのはメモリ不足話じゃないから違うのかな? 確か ZFS の メモリ不足問題 は amd64 ではあまり問題なくて i386 は(元の ZFS コードが 32bit 環境を もうほとんど考慮していないから)無理っぽいって 話だと思ったけど amd64 でも×なんだっけ?
476 名前:名無しさん@お腹いっぱい。 mailto:sage [2008/11/28(金) 13:43:50 ] 何も考えずUFS2にしとけって
477 名前:名無しさん@お腹いっぱい。 mailto:sage [2008/11/28(金) 15:54:45 ] それで済むなら最初から ZFS の話なんてしないのさ
478 名前:名無しさん@お腹いっぱい。 mailto:sage [2008/11/28(金) 16:27:30 ] >>476 は老人 >>477 は若者
479 名前:名無しさん@お腹いっぱい。 mailto:sage [2008/11/28(金) 16:33:29 ] 6.4-RELEASE
480 名前:名無しさん@お腹いっぱい。 mailto:sage [2008/11/28(金) 18:18:15 ] UFS2のタイムスタンプを2050年にする方法がわからん まさかごみEXT3同様2038年問題があることもないと思うけれど touchとかで32bitしか設定できずしょぼん。
481 名前:名無しさん@お腹いっぱい。 mailto:sage [2008/11/28(金) 19:20:55 ] 何だ未来人か?
482 名前:名無しさん@お腹いっぱい。 mailto:sage [2008/11/28(金) 23:14:01 ] 時間がらみのテストとかしてんじゃないのか?
483 名前:名無しさん@お腹いっぱい。 mailto:sage [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 www.FreeBSD.org/releases/ - always consult the ERRATA section for your release first as it's updated frequently.
484 名前:名無しさん@お腹いっぱい。 mailto:hage [2008/11/29(土) 00:58:10 ] >>483 / ̄\ | | \_/ | /  ̄  ̄ \ / \ / \ / ⌒ ⌒ \ | (__人__) | 褒美としてオプーナを買う権利をやる \ ` ⌒´ / ☆ /ヽ、--ー、__,-‐´ \─/ / > ヽ▼●▼<\ ||ー、. / ヽ、 \ i |。| |/ ヽ (ニ、`ヽ. .l ヽ l |。| | r-、y `ニ ノ \ l | |ー─ |  ̄ l `~ヽ_ノ____ / ̄ ̄ ̄ ̄ヽ-'ヽ--' / オプーナ /| .| ̄ ̄ ̄ ̄ ̄ ̄|/| | ̄ ̄ ̄ ̄ ̄ ̄|/| ______ / ̄オプーナ/|  ̄|__」/_オープナ /| ̄|__,」___ /| | ̄ ̄ ̄ ̄ ̄|/オプーナ ̄/ ̄ ̄ ̄ ̄|/ オープナ /| / .| | ̄ ̄ ̄ ̄ ̄| ̄ ̄ ̄ ̄ ̄|/l ̄ ̄ ̄ ̄| ̄ ̄ ̄ ̄ ̄|/| / | ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄|
485 名前:名無しさん@お腹いっぱい。 mailto:sage [2008/11/29(土) 02:25:55 ] OpoonaBSD
486 名前:名無しさん@お腹いっぱい。 [2008/11/29(土) 04:21:57 ] 大きなバージョンアップをせずに、ちょっとずつ修正し続けてるLinuxと違って FreeBSDはちゃんと段階踏んで開発してるから、変なバグの入り込む余地が少なくていいね 最初からこっち勉強すればよかった
487 名前:名無しさん@お腹いっぱい。 mailto:sage [2008/11/29(土) 04:31:24 ] 両方勉強するのがいいよ。片方だけだとどうしても視点が偏る。
488 名前:名無しさん@お腹いっぱい。 mailto:sage [2008/11/29(土) 11:18:04 ] >>482 時間指定したファイルを用意しておいて それを読んで状況判断して作業するテストの下準備 例えばportのビルドも作業終了をファイルでフラグにしている。
489 名前:名無しさん@お腹いっぱい。 mailto:sage [2008/11/29(土) 13:13:19 ] struct stat の st_mtime を sizeof したら 4 だし、無理じゃね?
490 名前:名無しさん@お腹いっぱい。 mailto:sage [2008/11/29(土) 16:36:11 ] 6.4R出たことだし、7.1は一旦キャンセルしてports凍結の完全解除してくりゃれ
491 名前:名無しさん@お腹いっぱい。 mailto:sage [2008/11/29(土) 16:46:14 ] >>489 AMD64だとtime_tは8だぞ
492 名前:名無しさん@お腹いっぱい。 mailto:sage [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日に設定できたぜ
493 名前:名無しさん@お腹いっぱい。 mailto:sage [2008/11/29(土) 16:53:34 ] >>491 64bitってことですね、 悪いけれどAMD64でtouchでファイルの日付ちょっと変えてみて ファイルシステム自体がintかそうでないかたしかめてくれませんかねぇ。 とりあえず2038年にして元にもどすとか でできるならば32bit版でもtouchではだめでもCとかで操作できるはず それにしても別にディスクアクセスなんてバイトオーダーなんだから 4byteでも5byteでも8byteでもかまわないのに...
494 名前:492 mailto:sage [2008/11/29(土) 17:14:50 ] 2050年にしてから戻すのも問題ないようだ。 ドラえもんの生まれた年でも、9999年でも問題ない。 touchはそのインターフェース上10000年問題を抱えてるが、 きっとプログラム書けば292277026596年までいけるんだろう。 ちなみに 7 STABLE (今年の10月ぐらいの)
495 名前:名無しさん@お腹いっぱい。 mailto:sage [2008/11/29(土) 17:16:43 ] i386だと time_t が4バイトだから、 utime(2) も stat(2) も、 APIとして64ビットのファイル日時設定・取得ができない。 デバイスを直接いじるなら別だろうけど。
496 名前:名無しさん@お腹いっぱい。 mailto:sage [2008/11/29(土) 17:41:01 ] 488 = 493 ダス 493カキコしたときに>>492 でてなかったのでちょっと493の内容がおかしい 要するにUFS2としては時間フィールドは64bitで i386用時間関数が現時点でtime_t型依存でtouchもできないってことですね、 ファイルシステム自体が対応しているならまぁあせることはないか。 別に32bitOSが64bit扱えないはずもないのでちょっと調べてみる。 つーか変な機能よりこういうところとっとと関数を64bit化してほしいけど 互換性を考慮しているのかな?
497 名前:名無しさん@お腹いっぱい。 mailto:sage [2008/11/29(土) 22:30:35 ] 64bit化よりも、AMD64使えってスタンスなんじゃね?
498 名前:名無しさん@お腹いっぱい。 mailto:sage [2008/11/29(土) 22:38:19 ] API変えちまったら、バイナリ全部死亡だから、洒落にならん。 i386→amd64と同じ手間かけるなら、amd64に行けということだな。
499 名前:名無しさん@お腹いっぱい。 mailto:sage [2008/11/30(日) 04:48:23 ] >>490 そやね、もしZFSがらみだと相当遅れるだろうし。
500 名前:名無しさん@お腹いっぱい。 mailto:sage [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のアレは直ったみたいだ。
501 名前:名無しさん@お腹いっぱい。 mailto:sage [2008/11/30(日) 11:42:03 ] i386で64bit化しても上位がedxにのるだけだからかわらんだろう。 バイナリ全部死亡とかいうけれどバージョン変わったらどうせそうだし 2008年段階で対応していない事自体おかしい。 まぁとりあえずファイルシステムは対応しているので ツール作ればどうにかなりそうですなぁ。 言語は使い方しだいで問題ないので環境変数とかで「basetime」をもつのが 無難な方法かな?
502 名前:名無しさん@お腹いっぱい。 mailto:sage [2008/11/30(日) 11:54:19 ] >>500 その日付のバージョンはダメなり
503 名前:名無しさん@お腹いっぱい。 mailto:sage [2008/11/30(日) 12:19:02 ] >>501 バージョン変わったくらいなら古いバイナリ動くだろ。 ライブラリのバージョンが問題なだけで、 システムコールのAPIがなくなるわけじゃない。 > ツール作ればどうにかなりそうですなぁ。 そんなので済むように見えないけど。 システムコールわかってなさそう。
504 名前:名無しさん@お腹いっぱい。 mailto:sage [2008/11/30(日) 12:27:25 ] amd64使えばいいじゃない
505 名前:名無しさん@お腹いっぱい。 mailto:sage [2008/11/30(日) 12:42:08 ] バイナリ互換は従来のエントリをold_statとか互換APIに割り当てればOK.
506 名前:名無しさん@お腹いっぱい。 mailto:sage [2008/11/30(日) 14:05:00 ] >>503 「表示」の整合性なんて全然問題ないだろう。 FreeBSD自体が未対応ならツールで対応するしかない。 実際表示なんて0-138を 1900-2038にしているだけだろ。 言語系がユリウス歴とか実数型、レコード型なんだから タイムスタンプや現時刻取り入れ時に補正一発入れればいいだけ システムコールをいじったっていいけれど 極めて簡単なレベルで整合性が取れるってことだ。
507 名前:名無しさん@お腹いっぱい。 mailto:sage [2008/11/30(日) 14:18:56 ] >>506 > 実際表示なんて0-138を 1900-2038にしているだけだろ。 何を言っているのか理解できない。
508 名前:名無しさん@お腹いっぱい。 mailto:sage [2008/11/30(日) 14:34:18 ] >>504 AMD64しか使えないOSですか? 10年たったらAMD128でしょう。i386は残る。 とりあえず専用コマンド作って2038年の次は2039年になった。 単に下位リミットつけて加算してから代入するだけ perlとかでもDateTimeを使うより速い。 素直にデータベースとか圧縮ファイルにすればもっと楽だと思う。 例えばzip書庫(無圧縮)であれば問題なく2050年にできる。 ベースタイム方式は標準コールでの表示は1920年とかになるけれど ちょっとずつ置換すれば実害ない。 UFS2のタイムスタンプが31bit以上でよめるようになったら それを一括修正するのは簡単だしアーカイブ形式での移行でもいいや。
509 名前:名無しさん@お腹いっぱい。 mailto:sage [2008/11/30(日) 14:53:12 ] >>507 perlでtimeから変換してみ
510 名前:名無しさん@お腹いっぱい。 mailto:sage [2008/11/30(日) 15:00:20 ] 俺もますますわからん。 time って何だ? 何に変換するんだ? そもそもなぜに perl?
511 名前:名無しさん@お腹いっぱい。 [2008/11/30(日) 15:43:33 ] 2038年問題に危機を感じるような人が2008年時点でi386使ってるほうがおかしい
512 名前:名無しさん@お腹いっぱい。 mailto:sage [2008/11/30(日) 17:02:42 ] ワロッシュw
513 名前:名無しさん@お腹いっぱい。 mailto:sage [2008/11/30(日) 20:09:33 ] 世間のサーバーでi386がたくさんる現実無視してFreeBSDでなにすんの? 発言内容からして1970年とか1900年の意味もわからなそう。 別に知らなくてもいいけれどリミットはあまりにも近いから 「拡大」ではなくて閾値対策が必要。それとNTPも perlであれば管理できないPCでも表記の日付を制御できるって発想はないのかな。 とりあえずUFS2にダイレクトにアクセスするツールもほしいところだけれど ちょっと勉強不足なんで目先の対応をしてみたわけさ。 設定とかファイル一覧とか比較とかちょっとしたフィルター入れるだけで実用上は問題がでない。 でも多分longintをlongWordにすれば目先インターフェースでの補正もいらないかんじかな。 なんやかんやでファイルの時間の幅が広いものはZipで管理する方が 互換性も高く楽だというのが分かる人への結論
514 名前:名無しさん@お腹いっぱい。 mailto:sage [2008/11/30(日) 20:16:42 ] だんだん壊れてきてるな
515 名前:名無しさん@お腹いっぱい。 mailto:sage [2008/11/30(日) 20:28:04 ] > 1900年の意味 > 閾値対策が必要 > それとNTPも > 表記の日付を制御できる > longintをlongWordにすれば > 目先インターフェース > ファイルの時間の幅が広いものはZipで管理 さっぱりわからん。
516 名前:名無しさん@お腹いっぱい。 mailto:sage [2008/11/30(日) 20:45:38 ] またヤツが来たか…
517 名前:名無しさん@お腹いっぱい。 mailto:sage [2008/11/30(日) 21:48:29 ] >>515 > さっぱりわからん。 つまりZIPでくれ、って事じゃね?
518 名前:名無しさん@お腹いっぱい。 mailto:sage [2008/11/30(日) 22:57:23 ] >>513 tanasinn?
519 名前:名無しさん@お腹いっぱい。 mailto:sage [2008/11/30(日) 23:44:45 ] 謎w
520 名前:名無しさん@お腹いっぱい。 mailto:sage [2008/11/30(日) 23:56:42 ] time_t が 32bit だと 計算の途中でおかしくなることもあるだろw
521 名前:名無しさん@お腹いっぱい。 mailto:sage [2008/12/01(月) 00:25:12 ] 何のどういう計算?
522 名前:名無しさん@お腹いっぱい。 mailto:sage [2008/12/01(月) 01:28:08 ] >>494 それは宇宙が滅びてる年
523 名前:名無しさん@お腹いっぱい。 mailto:sage [2008/12/01(月) 03:19:59 ] やっとこさ、6.4 RELEASEが出たね。
524 名前:名無しさん@お腹いっぱい。 mailto:sage [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に戻した。
525 名前:名無しさん@お腹いっぱい。 mailto:sage [2008/12/01(月) 15:04:55 ] 7.1まだ?待ってるんですけど。
526 名前:名無しさん@お腹いっぱい。 mailto:sage [2008/12/01(月) 17:22:44 ] >>524 emulationMLによると大地さんも話題にしてた あのパッチはうまく行きそうだが、バカンス中なので もうちょっとまっててねーbyげらるど とかいうことになってるっぽいけど。
527 名前:名無しさん@お腹いっぱい。 mailto:sage [2008/12/01(月) 17:57:02 ] 10.0が出たら本気出す
528 名前:名無しさん@お腹いっぱい。 mailto:sage [2008/12/02(火) 00:37:09 ] NetBSDはsoftdep消しちゃったんだ 早いねぇ
529 名前:名無しさん@お腹いっぱい。 mailto:sage [2008/12/02(火) 00:57:45 ] >>528 半年前から決まっていたようなものだから早いという感じはしないな。
530 名前:名無しさん@お腹いっぱい。 [2008/12/02(火) 13:01:56 ] >>525 来年2月に名前を変えて出します。
531 名前:名無しさん@お腹いっぱい。 mailto:sage [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とかそういうのにちょいと スクリプトかぶせればいいというわけ
532 名前:名無しさん@お腹いっぱい。 mailto:sage [2008/12/02(火) 14:50:09 ] 8系が見えていると安定している7.0から7.1には移りづらい気がする。
533 名前:名無しさん@お腹いっぱい。 mailto:sage [2008/12/02(火) 15:11:53 ] 64bit time_tにしたらtime_tがらみのシステムコール番号新しくすりゃいいんじゃね? 古いやつはCOMPAT_xxx入れないと有効にならないとか
534 名前:名無しさん@お腹いっぱい。 mailto:sage [2008/12/02(火) 20:00:37 ] 構造体に対するアクセスの問題なのでシステムコールはあんまり関係ないんだけれど mktimeとかそういう部分が引っかかるだけ、あとアプリ関連個別 通常時呼ぶのは秒単位の時間ではなくてミリ単位のクロックと CPUベースのクロックでCPUベースのクロックはマルチコアだとうまく動作しない。 それらも32bitと64bitは単にレジスタにのっけるだけで幅の差だから コンパチとかではなくて同じ仕様の別CPU対応ということになる。
535 名前:名無しさん@お腹いっぱい。 mailto:sage [2008/12/02(火) 20:10:42 ] そもそもi386前提で話をしてるのがおかしい。 sparc64は?
536 名前:名無しさん@お腹いっぱい。 mailto:sage [2008/12/02(火) 20:17:39 ] 1970年にはFreeBSDはなかったのでLongWord対応でよいじゃあないの。と ±10年設定できれば大抵はすむだろうからこれは「FreeBSDを語る」 以外の何者でもない。 不正ファイルやシステムクロックやNTPの障害の影響を受けないことに意味がある。 touch2とstat2とかで未来の日付を扱えることに安堵感を感じることに意義がある。
537 名前:名無しさん@お腹いっぱい。 [2008/12/02(火) 20:37:03 ] >>534 何言ってるの
538 名前:名無しさん@お腹いっぱい。 mailto:sage [2008/12/02(火) 20:46:11 ] 俺には >>531 , >>536 も何を言っているかわからない。
539 名前:名無しさん@お腹いっぱい。 mailto:sage [2008/12/02(火) 21:09:40 ] 意味不明文章作成スクリプトが襲来しているだけですので スルーで。
540 名前:名無しさん@お腹いっぱい。 mailto:sage [2008/12/02(火) 21:16:20 ] なかなか優秀なスクリプトだな。
541 名前:名無しさん@お腹いっぱい。 mailto:sage [2008/12/02(火) 21:44:48 ] ブログを開設してパッチを貼るくらいには賢くなってくれないと。
542 名前:名無しさん@お腹いっぱい。 mailto:sage [2008/12/02(火) 22:31:20 ] www.jp.freebsd.org/ って、もう更新しないんですか?
543 名前:名無しさん@お腹いっぱい。 mailto:sage [2008/12/02(火) 22:37:05 ] >>535 こちらへどうぞ。 pc11.2ch.net/test/read.cgi/unix/1096032708/
544 名前:名無しさん@お腹いっぱい。 mailto:sage [2008/12/02(火) 22:42:32 ] 7.1予定通り来年二月のようだな
545 名前:名無しさん@お腹いっぱい。 mailto:sage [2008/12/02(火) 22:44:54 ] そうだな、順調に行って四月にはお目にかかれそうだ
546 名前:名無しさん@お腹いっぱい。 mailto:sage [2008/12/03(水) 00:01:51 ] 来年は 8.0 (June 2009)が来る予定になっているんだぞ!
547 名前:名無しさん@お腹いっぱい。 mailto:sage [2008/12/03(水) 00:14:22 ] 8-currentも順調に進んでいるんだから 7.1Rのスケジュールがいくら順調だからって >>546 の懸念は杞憂だとおもうよ。 ちゃんと8.0Rも来年いっぱいまで掛からずに 出てくれるさ。
548 名前:名無しさん@お腹いっぱい。 mailto:sage [2008/12/03(水) 00:44:18 ] 俺の予想だと8.0Rは2010年春だな
549 名前:名無しさん@お腹いっぱい。 mailto:sage [2008/12/03(水) 00:51:44 ] それじゃあスケジュールどおりじゃないか
550 名前:名無しさん@お腹いっぱい。 mailto:sage [2008/12/03(水) 06:30:08 ] だからあらゆる意味でスケジュール通りw
551 名前:名無しさん@お腹いっぱい。 mailto:sage [2008/12/03(水) 08:10:13 ] 予定通りだ、問題ない(w
552 名前:名無しさん@お腹いっぱい。 mailto:sage [2008/12/03(水) 09:05:11 ] ZFS新版は早く実用的に試したいから RELENG_8 が早く登場するといいなぁ…
553 名前:名無しさん@お腹いっぱい。 [2008/12/03(水) 09:41:51 ] img.2ch.net/ico/anime_onini03.gif Windowsのシェアが初の90%割れ、IEも70%切る−米Net Applications調べ インターネットモニタリング・調査の米Net Applicationsは12月1日(米国時間)、 2008年11月度のOSおよびWebブラウザのシェアを発表した。 OSではWindowsが 89.92%と初めて90%台を下回った。WebブラウザもInternet Explorer(IE)が69.77%と、70%を切った。 Webに接続した人が利用しているOS、Webブラウザを調べたもの。 Windowsは10月度の90.46%から0.84ポイントの減少となる。 前年同期(2007年11月)は92.42%で、その後91%台に、 今年8月には90%台に下がり、少しずつシェアを減らしてきた。 これに対し、米AppleのMacの11月度シェアは8.87%で、前月の8.21%から伸ばした。 Linuxも0.71%から0.83%に増加した。特にMacは、前年同期の6.8%から、 2007年12月には7%台に入り、さらに9月に8%台となるなどWindowsのシェアを侵食しながら増加している。 Appleは、iPhoneも好調で、0.1%台のシェアで推移した後、 iPhone 3G発売の翌月となる2008年8月に、一気に0.3%台に跳ね上がった。11月は0.37%だった。 MicrosoftはWebブラウザでもシェアを落としている。IEのシェアは、 2007年初めには80%近くあったが、2007年末には 76%台に下がり、 2008年2月に75%を切った。一方、オープンソースのFirefox(Mozilla Foundation)は11月、 20.78%を記録して初めて20%台に突入した。AppleのSafari、米GoogleのChromeも11月、 シェアを増やし、それぞれ7.13%、0.83%となっている。 2008/12/03 08:59 enterprise.watch.impress.co.jp/cda/foreign/2008/12/03/14440.html FreeBSDは?
554 名前:名無しさん@お腹いっぱい。 mailto:sage [2008/12/03(水) 10:46:46 ] >>526 -emulationを読んでおおまかに把握した。パッチを当てた1.1.9でInvalid Addressが出なくなった。 このパッチはまだcommitされていないのでports-currentでも駄目なのは駄目のまま。 選択肢はふたつ、 (1) 1.1.7に戻してgeraldのvacation明けを待つ (2) -emulationを読んでパッチを当てた1.1.9を入れる >>502 は結局何を言ってるのかわからない。
555 名前:名無しさん@お腹いっぱい。 mailto:sage [2008/12/03(水) 14:25:30 ] >>553 一瞬「Windowsのシェアの90%が割れOS」なのかと思たよ。>>Windowsのシェアが初の90%割れ
556 名前:名無しさん@お腹いっぱい。 [2008/12/03(水) 18:50:32 ] >>554 コメントの日付以降に出された1.1.9がだめだったってこと 一見うまく動いてもメモリー関連なので起動しない状況が解決しただけで ほんとに正しいといっていのかわからない。 FreeBSD版のテストがほとんどされていないのは明らか 最大の需要はfirefox+Flashだと思うけれど どちらも身勝手ソフトで悪意のある人ならなんとでもできるわけで 基本ソフトなのでソースを読めない人がちょいとパッチをあてて動かすのは 趣味の範疇 したがって(2)は選択肢には入らない。 パッチを当てることがだめというんじゃなくて まずどうして1.1.7でよくて今回だめになったのか そもそもどうしてそういう変更が必要だったのかちゃんと考えろってこと wineは規模が大きいんだし公式なリリースを待って安定版を使うがよろし あるいは特定のバージョンのwineからFreeBSD特化版を作るというのもあり
557 名前:名無しさん@お腹いっぱい。 mailto:sage [2008/12/03(水) 22:10:59 ] >>556 壮大な主張をしているのは想像できるが到底無理かつ無意味なことを言ってるように思える。 wineは動かすこと自体が趣味の範疇だろう。 動いたすっげー、動かねーがっかり、それ以上のものじゃない。 この10年で本当に見違えるほどに優秀になった。ここまで来るとは到底思えなかった。それでもなお、 実行するだけでerrだのfixmeだのstarting debuggerだのが読めないくらいスクロールするようなモンを 趣味以上のことに使うのは俺には無理。 wineのFreeBSD用コードなんてgerald他2,3人しか手をつけていないと公言されているのに 公式リリースを待ったところで同じコードが入ってくるだけのことだよな。 だからそんなもん待たない。これで動く、と投稿された1行のパッチも躊躇なく試す。 まあそんなわけだから、コードの意味を考えろとか、安定版を待てだとかいうパラグラフ毎に 正反対の主張を展開されても俺は困るし、君の主張は無意味だと思う。説教は鏡に向かって存分に やってくれ。
558 名前:名無しさん@お腹いっぱい。 mailto:sage [2008/12/04(木) 01:02:40 ] >>557 よくわかった。ソープ行って童貞卒業してこい。
559 名前:名無しさん@お腹いっぱい。 mailto:sage [2008/12/04(木) 01:32:31 ] >>558 北方先生おつ