LI=1 VN=4 Mode=4 St=1 orig=3439756798.000315 2009/01/01 08:59:58.000315 recv=3439756798.000414 2009/01/01 08:59:58.000414 trans=3439756798.000559 2009/01/01 08:59:58.000559 dest=3439756798.000607 2009/01/01 08:59:58.000607 o = 0.000025272 d = 0.000146866 LI=1 VN=4 Mode=4 St=1 orig=3439756798.201441 2009/01/01 08:59:58.201441 recv=3439756798.201455 2009/01/01 08:59:58.201455 trans=3439756798.201500 2009/01/01 08:59:58.201500 dest=3439756798.201528 2009/01/01 08:59:58.201528 o = -0.000006914 d = 0.000042439 LI=1 VN=4 Mode=4 St=1 orig=3439756798.402402 2009/01/01 08:59:58.402402 recv=3439756798.402422 2009/01/01 08:59:58.402422 trans=3439756798.402471 2009/01/01 08:59:58.402471 dest=3439756798.402499 2009/01/01 08:59:58.402499 o = -0.000004053 d = 0.000048161 LI=1 VN=4 Mode=4 St=1 orig=3439756798.603365 2009/01/01 08:59:58.603365 recv=3439756798.603377 2009/01/01 08:59:58.603377 trans=3439756798.603415 2009/01/01 08:59:58.603415 dest=3439756798.603442 2009/01/01 08:59:58.603442 o = -0.000007629 d = 0.000039101 LI=1 VN=4 Mode=4 St=1 orig=3439756798.804326 2009/01/01 08:59:58.804326 recv=3439756798.804337 2009/01/01 08:59:58.804337 trans=3439756798.804373 2009/01/01 08:59:58.804373 dest=3439756798.804400 2009/01/01 08:59:58.804400 o = -0.000008106 d = 0.000038147 LI=1 VN=4 Mode=4 St=1 orig=3439756799.005303 2009/01/01 08:59:59.005303 recv=3439756799.005395 2009/01/01 08:59:59.005395 trans=3439756799.005514 2009/01/01 08:59:59.005514 dest=3439756799.005555 2009/01/01 08:59:59.005555 o = 0.000025511 d = 0.000133038 LI=1 VN=4 Mode=4 St=1 orig=3439756799.206258 2009/01/01 08:59:59.206258 recv=3439756799.206271 2009/01/01 08:59:59.206271 trans=3439756799.206376 2009/01/01 08:59:59.206376 dest=3439756799.206407 2009/01/01 08:59:59.206407 o = -0.000008821 d = 0.000044346 LI=1 VN=4 Mode=4 St=1 orig=3439756799.407216 2009/01/01 08:59:59.407216 recv=3439756799.407231 2009/01/01 08:59:59.407231 trans=3439756799.407271 2009/01/01 08:59:59.407271 dest=3439756799.407298 2009/01/01 08:59:59.407298 o = -0.000006199 d = 0.000041962 LI=1 VN=4 Mode=4 St=1 orig=3439756799.608179 2009/01/01 08:59:59.608179 recv=3439756799.608191 2009/01/01 08:59:59.608191 trans=3439756799.608227 2009/01/01 08:59:59.608227 dest=3439756799.608254 2009/01/01 08:59:59.608254 o = -0.000007629 d = 0.000039101 LI=1 VN=4 Mode=4 St=1 orig=3439756799.809143 2009/01/01 08:59:59.809143 recv=3439756799.809154 2009/01/01 08:59:59.809154 trans=3439756799.809189 2009/01/01 08:59:59.809189 dest=3439756799.809216 2009/01/01 08:59:59.809216 o = -0.000008106 d = 0.000038147 LI=0 VN=4 Mode=4 St=1 orig=3439756799.010121 2009/01/01 08:59:59.010121 recv=3439756799.010214 2009/01/01 08:59:59.010214 trans=3439756799.010325 2009/01/01 08:59:59.010325 dest=3439756799.010366 2009/01/01 08:59:59.010366 o = 0.000025988 d = 0.000133991 LI=0 VN=4 Mode=4 St=1 orig=3439756799.211078 2009/01/01 08:59:59.211078 recv=3439756799.211093 2009/01/01 08:59:59.211093 trans=3439756799.211210 2009/01/01 08:59:59.211210 dest=3439756799.211242 2009/01/01 08:59:59.211242 o = -0.000008821 d = 0.000047207 LI=0 VN=4 Mode=4 St=1 orig=3439756799.412035 2009/01/01 08:59:59.412035 recv=3439756799.412048 2009/01/01 08:59:59.412048 trans=3439756799.412089 2009/01/01 08:59:59.412089 dest=3439756799.412116 2009/01/01 08:59:59.412116 o = -0.000007153 d = 0.000040054 LI=0 VN=4 Mode=4 St=1 orig=3439756799.612997 2009/01/01 08:59:59.612997 recv=3439756799.613009 2009/01/01 08:59:59.613009 trans=3439756799.613047 2009/01/01 08:59:59.613047 dest=3439756799.613074 2009/01/01 08:59:59.613074 o = -0.000007391 d = 0.000038624 LI=0 VN=4 Mode=4 St=1 orig=3439756799.813961 2009/01/01 08:59:59.813961 recv=3439756799.813972 2009/01/01 08:59:59.813972 trans=3439756799.814006 2009/01/01 08:59:59.814006 dest=3439756799.814033 2009/01/01 08:59:59.814033 o = -0.000008106 d = 0.000038147 LI=0 VN=4 Mode=4 St=1 orig=3439756800.014939 2009/01/01 09:00:00.014939 recv=3439756800.015040 2009/01/01 09:00:00.015040 trans=3439756800.015175 2009/01/01 09:00:00.015175 dest=3439756800.015218 2009/01/01 09:00:00.015218 o = 0.000029087 d = 0.000144005 LI=0 VN=4 Mode=4 St=1 orig=3439756800.215902 2009/01/01 09:00:00.215902 recv=3439756800.215992 2009/01/01 09:00:00.215992 trans=3439756800.216094 2009/01/01 09:00:00.216094 dest=3439756800.216135 2009/01/01 09:00:00.216135 o = 0.000024557 d = 0.000131130 LI=0 VN=4 Mode=4 St=1 orig=3439756800.416851 2009/01/01 09:00:00.416851 recv=3439756800.416867 2009/01/01 09:00:00.416867 trans=3439756800.416919 2009/01/01 09:00:00.416919 dest=3439756800.416947 2009/01/01 09:00:00.416947 o = -0.000005960 d = 0.000043392 LI=0 VN=4 Mode=4 St=1 orig=3439756800.617874 2009/01/01 09:00:00.617874 recv=3439756800.617977 2009/01/01 09:00:00.617977 trans=3439756800.622060 2009/01/01 09:00:00.622060 dest=3439756800.622220 2009/01/01 09:00:00.622220 o = -0.000028610 d = 0.000263214 LI=0 VN=4 Mode=4 St=1 orig=3439756800.822790 2009/01/01 09:00:00.822790 recv=3439756800.822881 2009/01/01 09:00:00.822881 trans=3439756800.823042 2009/01/01 09:00:00.823042 dest=3439756800.823085 2009/01/01 09:00:00.823085 o = 0.000024080 d = 0.000133991recv に注目すると、NTP time 3439756799 (2009/01/01 08:59:59 JST) を二回繰り返したことがわかる。 これは 事前確認した通り の動作である。 表にすると下のようになり、誤報が 1 秒分だけあったことになる。
あるべきNTP time 実際のNTP time
2009/01/01 08:59:59 3439756799 LI=01 3439756799 LI=01
2009/01/01 08:59:60 3439756800 LI=01 3439756799 LI=00 誤報
2009/01/01 09:00:00 3439756800 LI=00 3439756800 LI=00
まあまあ合格と言えるだろう。
うるう秒自体が廃止になる可能性もあるので、
次回の実施があるかどうか不明ながら、
いつでも来やがれかかって来い!!
てな心境である。
ntpd-4.2.5p149 を使った stratum-2 の ntpd も同様の動作であった。
従来から使用している、 JUPITER GPS をリファレンスクロックにした ntpd 群 (232C の信号をパラレルでバス接続している 4 台) のうち、 ntpd-4.2.5p149 に変えた 3 台は、やはり同様の動作であった。 ntpd-4.2.0 のままの 1 台は、 前回 同様 11 分に渡って誤報を続けた後、1 秒時計を戻した。
Jan 1 09:11:42 xxx ntpd[33220]: time reset -1.000002 s
ちなみに
mfeed
nict
も動作検証する予定だったのだが、
mfeed の方はうちのクライアントプログラムがバグってて誤爆。
nict の方は操作ミスで誤爆。
いずれも検証できなかった。
mfeed に関しては
2006 年に検証した
ので、あの時よりまずくなっているとは考えにくい。
nict の方は全く不明。
検証した情報があれば御教示頂ければ幸いである。
$GPRMC,235957,A,xx.xx,N,xx.xx,E,000.0,220.1,311208,007.4,W*6C $GPRMC,235958,A,xx.xx,N,xx.xx,E,000.0,220.1,311208,007.4,W*61 $GPRMC,235959,A,xx.xx,N,xx.xx,E,000.0,220.1,311208,007.4,W*60 $GPRMC,000000,A,xx.xx,N,xx.xx,E,000.0,220.1,010109,007.4,W*60 $GPRMC,000000,A,xx.xx,N,xx.xx,E,000.0,220.1,010109,007.4,W*6F $GPRMC,000001,A,xx.xx,N,xx.xx,E,000.0,220.1,010109,007.4,W*6E $GPRMC,000002,A,xx.xx,N,xx.xx,E,000.0,220.1,010109,007.4,W*6D $GPRMC,000003,A,xx.xx,N,xx.xx,E,000.0,220.1,010109,007.4,W*632008/12/31 23:59:60 UTC を返すべきところを、2009/01/01 00:00:00 を返した (2009/01/01 00:00:00 を 2 回繰り返した)。 まあギリギリ合格点かな。
:1108 3865 wsec 345597 GtoU 14.000000005 A/V=1 GPS/UTC=1 2009/01/01 08:59:57 :1108 3866 wsec 345598 GtoU 14.000000005 A/V=1 GPS/UTC=1 2009/01/01 08:59:58 :1108 3867 wsec 345599 GtoU 14.000000005 A/V=1 GPS/UTC=1 2009/01/01 08:59:59 :1108 3868 wsec 345600 GtoU 14.000000005 A/V=1 GPS/UTC=1 2009/01/01 09:00:00 :1108 3869 wsec 345601 GtoU 14.000000005 A/V=1 GPS/UTC=1 2009/01/01 09:00:01 :1108 3870 wsec 0 GtoU 0.000000000 A/V=0 GPS/UTC=1 2008/12/28 09:00:00 :1108 3871 wsec 345602 GtoU 15.000000005 A/V=1 GPS/UTC=1 2009/01/01 09:00:02 :1108 3872 wsec 345603 GtoU 15.000000005 A/V=1 GPS/UTC=1 2009/01/01 09:00:03前回 同様、うるう秒挿入後 2 秒目に、A/V が 0 になった。 その瞬間 UTC-GPS が一旦 0 秒になり、 14秒→ 0秒→ 15秒と動いた。 「週始めからの秒数」は 345601秒→ 0秒→ 345602秒と動いた。 GPS/UTC はずっと U のままだった。 時刻の誤報は 3 秒間である。 前回も 2 秒で済んだので、 ジュピターはうるう秒実施後 2〜3 秒で正常に戻ると考えて良いのかもしれない。
WBT-300 の出力は以下の通り。 RMC, GGA, GSV(0.25Hz) を 10Hz 出力のうち RMC のみ抜粋。 (これは 2008/12/31 16:54:08 UTC に記録を開始したので、 止まらずにうるう秒をとらえることができたが、 もしかしたら GM-48UB 同様長期運用は無理かもしれない。)
$GPRMC,235958.200,A,xx.xx,N,xx.xx,E,0.00,226.07,311208,,,D*60 $GPRMC,235958.400,A,xx.xx,N,xx.xx,E,0.11,226.07,311208,,,D*66 $GPRMC,235958.600,A,xx.xx,N,xx.xx,E,0.09,226.07,311208,,,D*6D $GPRMC,235958.800,A,xx.xx,N,xx.xx,E,0.00,226.07,311208,,,D*6A $GPRMC,235959.000,A,xx.xx,N,xx.xx,E,0.00,226.07,311208,,,D*63 $GPRMC,235959.200,A,xx.xx,N,xx.xx,E,0.00,226.07,311208,,,D*61 $GPRMC,235959.400,A,xx.xx,N,xx.xx,E,0.00,226.07,311208,,,D*67 $GPRMC,235959.600,A,xx.xx,N,xx.xx,E,0.10,226.07,311208,,,D*64 $GPRMC,235959.800,A,xx.xx,N,xx.xx,E,0.12,226.07,311208,,,D*68 $GPRMC,235960.000,A,xx.xx,N,xx.xx,E,0.00,226.07,311208,,,D*69 $GPRMC,235960.200,A,xx.xx,N,xx.xx,E,0.00,226.07,311208,,,D*6B $GPRMC,235960.400,A,xx.xx,N,xx.xx,E,0.15,226.07,311208,,,D*69 $GPRMC,235959.600,A,xx.xx,N,xx.xx,E,0.10,226.07,010109,,,D*64 $GPRMC,235959.800,A,xx.xx,N,xx.xx,E,0.00,226.07,010109,,,D*6B $GPRMC,000000.000,A,xx.xx,N,xx.xx,E,0.13,226.07,010109,,,D*60 $GPRMC,000000.200,A,xx.xx,N,xx.xx,E,0.13,226.07,010109,,,D*62 $GPRMC,000000.400,A,xx.xx,N,xx.xx,E,0.00,226.07,010109,,,D*66 $GPRMC,000000.600,A,xx.xx,N,xx.xx,E,0.00,226.07,010109,,,D*64 $GPRMC,000000.800,A,xx.xx,N,xx.xx,E,0.00,226.07,010109,,,D*6A $GPRMC,000001.000,A,xx.xx,N,xx.xx,E,0.00,226.07,010109,,,D*63 $GPRMC,000001.200,A,xx.xx,N,xx.xx,E,0.00,226.07,010109,,,D*61 $GPRMC,000001.400,A,xx.xx,N,xx.xx,E,0.00,226.07,010109,,,D*67 $GPRMC,000001.600,A,xx.xx,N,xx.xx,E,0.00,226.07,010109,,,D*65なんとも奇妙な出力である。 まず予備知識として、 元々 u-blox ANTARIS4 には日付変更のバグがある。 これは毎日 23:59:59.500 〜 23:59:59.900 UTC の 0.5 秒間、 年月日が翌日を示すというものである。 つまり
2008/12/30 23:59:59.3 2008/12/30 23:59:59.4 2008/12/31 23:59:59.5 ここで日付が変わってしまう! 2008/12/31 23:59:59.6 2008/12/31 23:59:59.72007/06/07 には既にバグ発見の報告がある。
おそらくは連続秒数から日付を算出する段階で、 端数の秒を本来切り捨てるべきところを、 誤って四捨五入しているのだろうと、容易に想像ができる。 ちなみに u-blox の正式回答は
which is a kind of bug. Please use Antaris4 receiver by keeping this in mind.ということである。和訳: ん〜〜バグみたいだねえ。留意して使ってね!!
それを踏まえてログを見ると、 うるう秒挿入に対して 2008/12/31 23:59:60.000 を出力したのは上出来! だが 2008/12/31 23:59:60.600 を出力すべきところで、 なぜか 2009/01/01 23:59:59.600 を出力。 つまり年月日は先走る一方で、時分秒は逆戻りしてしまったのだ。 年月日が先走るのは四捨五入したためだが、 時分秒が戻るのは、 2009/01/01 00:00:00 に端数の -0.4 秒を加算して 23:59:59.600 にしてしまった模様。 なんとも驚きである。
BC-337 の出力は以下の通り。 RMC, GGA, GSV 等の出力から RMC のみ抜粋。
$GPRMC,235944.000,A,xx.xx,N,xx.xx,E,0.05,319.16,311208,,*0C $GPRMC,235945.000,A,xx.xx,N,xx.xx,E,0.04,303.73,311208,,*05 $GPRMC,235946.000,A,xx.xx,N,xx.xx,E,0.05,316.58,311208,,*0A $GPRMC,235946.000,A,xx.xx,N,xx.xx,E,0.03,291.48,311208,,*03 $GPRMC,235947.000,A,xx.xx,N,xx.xx,E,0.03,287.13,311208,,*0B $GPRMC,235948.000,A,xx.xx,N,xx.xx,E,0.02,294.62,311208,,*01 $GPRMC,235949.000,A,xx.xx,N,xx.xx,E,0.02,287.64,311208,,*04当初 23:59:59 付近に注目していたので気づかなかったが、 23:59:46 を 2 回出力した。 これは UTC 基準でなく GPS time (UTC - 14 秒)基準で 23:59:59 の後にうるう秒挿入を行ったものと考えられる。 ま、バグだわな。
総括すると、
SNPでは59秒が2回出力されるという結果でした。
少し古い機種ですが Globalsat BT-359 は 23:59:46 を2回出力しました。 BT-Q1000X, i-Blue747A+, BT-Q1300, M-241, i-Blue821, BT-Q1000, i-Blue747 は 23:59:59 を2回出力しています。HI-408BTは59秒を2回,GT-730F(L)は60秒を出力しました。
GP-730F(L)(canmore,SkyTraq Venus 5) 生NMEA:235959.817-235960.817-000000.817
HI-408BTは23:59:59を2回出力しました。 それに対しGT-730F(L)は23:59:60を出力しました。
GM-316(SiRF GSC3f/LPx 7989)についてまとめ。 235945.000,31,12,2008 を挿入、 175945.000,01,01,2009 を削除、 000000.000,02,01,2009 を挿入。
UNICLOCKのお姉さんたちは、初のうるう秒を、戸惑いもせずに普通に踊ってました。
23:59:45 とか 23:59:46 を繰り返すコアが見受けられるが(SiRF 系?)、 これは UTC 基準でなく GPS time (UTC - 14 秒)基準でうるう秒挿入を行ったものと考えられる。
いろいろなコアがあるのね。
参考になりました。
情報を公開してくださった方々に感謝致します。
元日は家族揃って初詣に行った。 その後 FKD に行こうとしたら大渋滞。
2 日は MOVIX のカップルデーなので、 お姉ちゃんとパパで「映画!たまごっち うちゅーいちハッピーな物語!?」を見た。 結構楽しめた。 緑の巨人伝 に比べたら遥かにまとも。
4 日は妹としらさぎ公園へ。
ローラー滑り台とトンネル滑り台が気に入ったらしい。
本題の前に、そもそも残量計はどのような仕組みなのだろうか?? 自動車のガソリンタンク内のガソリンの残量はどのように測定しているのでしょうか? によると、フロートによる液位センサが多いらしい。 ほー、それなら安心だ。 あり得ないと思うが万一重量ベースだったりすると、 比重の違うハイオクとレギュラーで係数が変わっちゃうので面倒だからね。
まず、フィット(GE6)の仕様として、タンク容量は 42L。 警告灯は残量 7L 前後で点灯。 故障診断コネクタから出て来るデータは 0〜105% と仮定している。 105% 以上給油しても値はサチる。 0% 以下はなったことないから不明。
残量は 16% で給油開始。 増える残量計表示を見ながら、 25%, 50%, 75%, 100%, 105% でいちいち給油を止めて給油量を携帯電話で撮影。 (さぞ怪しい客に見えただろう。) 途中でトラブル発生。 給油に時間をかけすぎたため、一旦打ち切られてしまったのだ (一回の給油は 5 分以内という規定がある)。 そんなわけで、88% を境に給油し直しとなった。 んでは測定結果。
|
|
そこで、口いっぱいを 42L で 110% と仮定し(根拠なし)、 過去の残量・給油量から 1% あたりの燃料量を平均計算すると、0.346868[L/%] となる。 そのグラフが緑の直線で、
お姉ちゃんの第二世代の携帯電話が、2010 年で使用できなくなるということで、
新しいのを買いに行った。
パパとしては東芝の 831T にしたかったのだが、
お姉ちゃんは 830T がいいと言うのでそれにした。
月々の支払が 3000 円ですってよ奥様!!
妹は言葉をいろいろ話すようになった。
お腹がすくと、爪先立ちでテーブルの上を覗いて
「ごわ、ごわ(ごはん、ごはん)」
と催促し続けるようになった。
お姉ちゃんと県立博物館のスズメバチ展を見に行った。
展示室 2 の小さい部屋に展示してあった。
各種スズメバチの標本がすげーの。
何百というスズメバチが、綺麗に標本化されている。
オオスズメバチは圧倒的!!
博物館のレストランで食事。
お姉ちゃんはハンバーグステーキランチ、パパはてんぷらうどん。
おいしゅうございました。
このレストランから二階の中庭が見えるんだけど、
夏になるとなんと野生のタヌキが数頭現れるらしい。
秋になるとぱたっと来なくなり、また翌年夏にやってくるとのこと。
へーーーー。
お姉ちゃんと妹としらさぎ公園に行った。
まあどうしてもパパは妹に付きっ切りになっちゃうので、
お姉ちゃんは妹と遊びながら時々一人で遊んだりしてた。
お姉ちゃんは時々
「パパもママも妹ばっかり。うち妹になりたい」
と不平を言う。
パパには弟がいるので、
その気持ちはとってもよくわかってしまうのだ。
お姉ちゃんと妹と散歩に行った。
お姉ちゃんは自転車でさーっと走っていってしまう。
妹は三輪車でパパがガラガラと押していくのだが、追いつくわけもない。
「あーーっ」
とお姉ちゃんに向かって叫んだりしていた。
パパには兄がいるので、付いて行きたくても追いつけない、
その気持ちもとってもよくわかってしまうのだ。
妹にシャンプーしていると、まねして自分の頭をくりくりする。
パパが自分を洗っていると、泡を手に取って、
ちっちゃい手で一生懸命パパの背中をくりくりしてくれる。
妹は眠くなるとお気に入りのタオルを持ちママの手を引いて和室に連れて行く。
そんで和室のスライドドアを閉めて、
「ばばー」(ばいばーい)
と言ってからママと寝る。
夜中に起きて、
なぜか勝手に隣の部屋に行って泣いてたりする。
ママが
「ママこっちだよ。タオタオ(タオル)もこっちだよ」
というと泣きながら戻って来くるらしい。
その時にドアを閉め忘れたりすると、
気づいて泣きながらドアを閉めに行って戻ってくるらしい。
みかんが大好きで、玄関のみかん箱から勝手に持ってきては
「はいどーぞ(剥いて)」
と手渡す。
都合で取り上げたりすると泣き崩れて息が止まっちゃう。
ママによると、「ぞうさん」の歌を聴くと一緒に歌うらしい。
US-CERT による 正しい方法 は
REGEDIT4
[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\IniFileMapping\Autorun.inf]
@="@SYS:DoesNotExist"
HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Explorer\MountPoints2を削除。
閉店セールやってたと思ったオリオン通りのミキは、
その後も営業してたみたいだけど、
今度はどうなるのかしら???
算数とか科学とかならまあほとんどの質問には答えられるのだが、
社会となるとパパはダメダメなので、
「うーーん?? 知らない」
と答えざるを得ないことが多い。
社会もっと勉強しとくんだった〜〜〜。
地球儀を見ながら
「中国に行きたい」
「韓国に行きたい」
「カナダに行きたい」
などと夢を膨らませている。
お姉ちゃんとドライブ中、国道の電光掲示板によると、
今年に入って県内の交通事故死者が 12 人らしい。
まあ
1 月 2 日にいきなり 3 人死亡事故
とかあったからねえ。
飲酒運転での自爆で、車はベンツでめちゃくちゃに大破したってな話をしたら、
「うち、なんだか車がかわいそうになった」
「そうだねえ、せっかくドイツから来たのにねえ」
「日本はどんな国かなあって?」
「うんうん」
どうも琴線に触れちゃったらしく、いきなり泣き出して、
「ベンツがかわいそう!!
日本に来るの楽しみにしてたのに!!
せっかくドイツから来たのに!!
なんで飲酒運転なんてするの?!?
パパ、なんで!?!?
わ〜〜〜〜〜〜〜!!」
海外に夢膨らませている自分と重なったのだろうか?
泣きじゃくるお姉ちゃんが見に行きたいと言うので、事故現場まで行って来た。
妹に
「ただいま〜」
と挨拶すると、
「おかえりー」
とお辞儀して迎えてくれるのだが、
妹と外出して、帰宅して
「ただいまー」
と言うと、妹はパパにだっこされたまま
「おかえりー」
と言うのだった。
自分で、何か難しい事をやり遂げたとき、
「じょ〜じゅ〜〜(上手)」 パチパチパチ(拍手する)
と、自分で自分を褒めることがある。
ときどき、パパの事も褒めてくれることがある。
ファーストインプレッション
bugbird さんから
冬の方が燃費が良くなる
との指摘を頂いたのだが、
俺様ボンクラだから理屈が分からない。
妹は、ビー玉を、トーマス自転車の篭から別の篭へと移す遊びが大好き。
そのビー玉が泥にまみれてるんで、室内用にビー玉ひと袋と、
プラスチックのざるを二つ買った。
ものすごく気に入って、ビー玉をあっちからこっちへ、
こっちからあっちへと移して遊んでいた。
そのうち口に入れ始めたので、
これは誤飲しそうだということで、
代わりに少し大きめの丸いサイコロを買った。
ザルが気に入ったらしく、
どこに行くにも持って行くらしい。
年越しそば。
喜多方ばあちゃんの手打ち。
つなぎなしの十割りそば。
ごちそうさまでした。
Honda Cars でもらったアシモブランケット。
理系ママのつれづれ日記
経由で
はざまの庵
から、「箸袋でDNA」。
妹がアイスクリームのおまけスプーンで、
先日のビー玉をすくおうとしている。
なかなかうまくすくえるはずもなく、
ビー玉が落ちるたびに
「あれー」
「あれー」
と言っている。
機嫌がよかったのか、ブチ切れもせずに繰り返しているので、
ちょっと手伝いして、すくわせてみた。
何度か繰り返すうちに、コツを覚えたらしく、
一人でもすくえるようになった。
ヨカッタネ!!
それと関係あるのか知らないが、 主に 64.57.246.146 から(たまに 67.192.144.0 とか 76.9.16.171 とかから) NS? . な query が一秒ごとに届いている。
このソース IP address は多分詐称されていて、 これに応答して DNS ルートサーバーのリストを返してしまうと、 数オクテットのクエリーに対して数百オクテットのリプライが発生し、 詐称されたホストへと送られる。 つまりネットワークストリームの増幅器(amplifier)として機能することになる。 世界中に存在するそういう増幅器に対して、継続的なクエリーを出すことで、 犠牲者(IP address 詐称されたホスト)に膨大なトラフィックが集中する。 これが DNS サーバを使った、 再帰検索に依らない新型 DDoS (Distribued Denial of Service) 攻撃の仕組み。
さて、手もとの 1 台の named(8) が bind 9.3.5 というバージョンで (他の named はみんな手で入れた bind 9.5 系だったのに、 こいつだけは何故か ports/dns/bind から入れた)、 いつの反応がよろしくない。 ". IN NS" に対し root servers リストを返してしまっているのだ。 結果として amplifier として働くことになってしまった。 イタタタタ。 もちろん再帰検索は禁止してある。
対処方法は bind 9.5 系にバージョンアップすること。 ports/dns/bind95 を入れて対策終り。 NS? . に対して refused を返すようになった (ログには './NS/IN' denied と残る)。 これで多い日も安心。 再帰検索禁止しているからと言って油断したらダメだね。
テストサイトもあるので、確認してみよう。
というわけで
bind9 設定
改訂。
# dd if=/dev/zero of=/dev/kmem dd: /dev/kmem: Bad address 1+0 records in 0+0 records out 0 bytes transferred in 0.000042 secs (0 bytes/sec)あら? 無事でしたよ??
# dd if=/dev/zero of=/dev/mem即死。 やっちまった。
授業で自分の名前の由来とか発表するらしい。
おお〜〜〜……あの子やあの子も!?!?
パパもその授業を聞いてみたいぞ。
是非。
「わかった?」
と聞くと、
「はーい」
と答えていた妹。
だが最近は
「もぉぉ〜っ」
と口答えするようになってしまったのだ。
それでママが一生懸命誉めてようやく
「はい」
と言うように戻った。
「大きな古時計」を聴くと、
「♪今はもう動かない」
のところで
「もぉぉ〜っ!!」
と怒るのであった。
妹はとうとう取っ手付きのドアも開けるようになってしまった。
お姉ちゃんの部屋には魅惑の品がいっぱいあるので、
なんとか侵入を防がねば……
タオル生地の糸をピーーーーッと引っ張って、 その糸くずを丸めてマリモみたいにするのが大好きである。 問題はそのマリモを鼻の穴に入れてしまうことだ。 年末、入った糸くずが取り出せなくなり耳鼻科に行った。 ほっとくと中で腐敗してえらい匂いになり、 また気管に入るとおおごとになるらしい。
その耳鼻科であちこち動き回っていたのだが、
全面ガラスの自動ドアに向かってトトトトっとかけて行ったと思ったら、
N口君
よろしく、ドアに鼻から激突!!
ガラスに気づかなかったらしい。
ひっくり返って大泣きしてしまった!!