FreeBSDを語れ Part21

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/ 435 名前：名無しさん＠お腹いっぱい。 mailto:sage [2008/11/24(月) 17:18:37 ] >>433 正しくないな、魔法が使えるのは思春期の女の子と 三十路を過ぎた童貞ニートだけだ。 436 名前：名無しさん＠お腹いっぱい。 mailto:sage [2008/11/24(月) 17:20:10 ] ぢゃ、俺、上級魔法使いじゃん。 437 名前：名無しさん＠お腹いっぱい。 mailto:sage [2008/11/24(月) 17:51:51 ] クラスアップ可能なのは女の子だけ 童貞には極初歩の入門魔術しかつかえん 438 名前：名無しさん＠お腹いっぱい。 mailto:sage [2008/11/24(月) 18:56:57 ] どういう魔術なのか興味津々 439 名前：名無しさん＠お腹いっぱい。 mailto:sage [2008/11/24(月) 19:21:34 ] 手を使わないでオナヌー出来るようになります。 440 名前：名無しさん＠お腹いっぱい。 mailto:sage [2008/11/24(月) 20:38:13 ] お前らなんでそんなに童貞なの？ 441 名前：名無しさん＠お腹いっぱい。 mailto:sage [2008/11/25(火) 00:29:45 ] FreeBSDって権利に問題なくてもパッケージにならないのが多いから いっそのことベクターかなんかに野良パッケージをアップしちゃうのも手かもと思った。 442 名前：名無しさん＠お腹いっぱい。 mailto:sage [2008/11/25(火) 06:05:36 ] いいアイデアですね。是非やってほしいです。 443 名前：名無しさん＠お腹いっぱい。 mailto:sage [2008/11/25(火) 09:24:38 ] >441 いくつかメンテナしてる感覚からすると... 深く考えずに send-pr すると 深く考えずに採用してくれるような気もするけど 444 名前：名無しさん＠お腹いっぱい。 mailto:sage [2008/11/25(火) 10:22:52 ] ezjailって何で未だにデフォルトパスのsrc.confしか通らないの？ 有志がpatch出してるとはいえ、あまり要望つーか需要無いのかな ホスト側構築時は普通に指定できるから、デフォパスの物はjail専用にして host側構築時には別途host用のやつを用意してみんな運用してるの？ 445 名前：名無しさん＠お腹いっぱい。 mailto:sage [2008/11/25(火) 11:15:07 ] ezjailの開発者に直接要望出してるの？ ちなみに、開発MLあたりになげないと、PRは見てないっぽい。 446 名前：名無しさん＠お腹いっぱい。 mailto:sage [2008/11/25(火) 11:25:35 ] >>443 send-prは障害報告なんだし 宣伝の仕方とかいちいちいっていいものかわからん。 ベクターにはUNIX系のカテゴリーがあってそこがすかすか FreeBSD自体日本でも歴史もあるのに「至急アップデートしてください」のfirefoxすら バイナリーがでまわらずPC-BSDくらいしかそれをやらないのは 依存度によってビルドが異なってくる雪だるま状態のportが多いせいだと思う。 それと案外と6,7,8で互換性ないからとかもあるのかも FreeBSDなまるっこい鬼キャラのゲームをFreeBSDとWin用に作って portsにじみーなユーティリィティをいくつかアップした段階で 自分がいいと思ったゲームとかそれを インストールすることでベーシックなライブラリーの更新ができれば 便利だと思った訳だ。 それに現実問題として安定版リリースなのにパッケージが最新版にならないしね、 それとこのパターンだとCPU別最適化版とか改良版とか複数の人がアップするという形もありだよね そういうものは本家のソースにも反映されると思うし アップする人は多分一言ある人だろうから ノーハウも含めて新規にFreeBSDをはじめる人にとって有用な情報が手に入りやすくなるし Web上でキーワードとして探索される。 そういう流れをつくりたいわけ。 447 名前：名無しさん＠お腹いっぱい。 mailto:sage [2008/11/25(火) 12:50:19 ] >>445 thx MLに投げるしかないのか 448 名前：名無しさん＠お腹いっぱい。 mailto:sage [2008/11/25(火) 21:56:12 ] >>440 UNIXユーザーは、結婚するまで童貞というのが世界共通の常識だ。 449 名前：名無しさん＠お腹いっぱい。 mailto:sage [2008/11/25(火) 22:05:41 ] 結婚してからも妻以外童貞だぞ。 450 名前：名無しさん＠お腹いっぱい。 mailto:sage [2008/11/25(火) 22:06:29 ] その点は非常識でもいいのでわ？ 451 名前：名無しさん＠お腹いっぱい。 mailto:sage [2008/11/25(火) 22:07:05 ] >>449 それは童貞とは言いません。 452 名前：名無しさん＠お腹いっぱい。 mailto:sage [2008/11/25(火) 22:11:34 ] ZFSってカーネルのディスクキャッシュみたいなのに全然載ってくれないみたい…。 パッチ<lists.freebsd.org/pipermail/freebsd-hackers/2008-June/024804.html>当てて カーネルメモリを3.5GBまで増やした。全く負荷がかかってない状況でddとかcat使ってみた感じだと 2.8GBぐらいまで一度読んだファイルはメモリに残ってる感じなんだけど、 実際にWebサーバーに使用してみると、300MB程度のファイルへの大量アクセスで HDDのアクセスランプがつきっぱなし… 453 名前：名無しさん＠お腹いっぱい。 mailto:sage [2008/11/25(火) 22:12:59 ] オレも、彼女ができるまでは童貞だった。 結婚してからも、妻と、元彼女と、元々彼女と、今のセフレ以外は童貞だ。 454 名前：名無しさん＠お腹いっぱい。 mailto:sage [2008/11/25(火) 22:15:17 ] 思い出に残るセックス 455 名前：名無しさん＠お腹いっぱい。 mailto:sage [2008/11/26(水) 01:58:32 ] 確かに俺もセックスした相手以外は童貞だな。 456 名前：名無しさん＠お腹いっぱい。 mailto:sage [2008/11/26(水) 11:49:03 ] ZFSってちょっと速いだけでリスクが高すぎるんじゃないのか? その処理分メモリードライブ(古い言葉遣い)を作って いるところにシンボリックリンクをはって定期的か明示的に反映するとかの方が いいと思う。(オリジナルはリネーム) 大量メモリーもってないからやってないけどportsのビルドとか顕著じゃないのかな 457 名前：名無しさん＠お腹いっぱい。 mailto:sage [2008/11/26(水) 12:41:49 ] >>456 ZFSはExperimentalだし動かなくとも仕方ない。 458 名前：名無しさん＠お腹いっぱい。 mailto:sage [2008/11/26(水) 13:11:00 ] おい てっきりイブの夜に〜スレだと思って ZFSとか何こいつらスレ違いやってんの？とか書くところだったわｗ 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　|｡|　| ｒ-､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 ] ワロッシュｗ 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 ] 謎ｗ 520 名前：名無しさん＠お腹いっぱい。 mailto:sage [2008/11/30(日) 23:56:42 ] time_t が 32bit だと 計算の途中でおかしくなることもあるだろｗ 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 来年２月に名前を変えて出します。 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は？

---

---

[ 続きを読む ] / [ 携帯版 ]

read.cgi ver5.27 [feat.BBS2 +1.6] / e.0.2 (02/09/03) / eucaly.net products.
担当:undef