てくてくのろし

blogger のダッシュボードに、いつのまにか「統計」などというタグが。 しらないうちにロギング機能付けてくれてたのね。

3G のパフォーマンス向上が謳われてるようだが、、、 ちょっとどきどきしながらただいまアップグレード中。

『ゆうちょ銀障害の原因判明　ＩＢＭ製ＨＤＤに欠陥』 詳細は こちら 障害を起こしている HDD が稼働系側にフェイルオーバーした、ということなのだろうか？ ファームウェアのバグ、ということになるのかな。 HDD にしても、サーバ本体にしても、冗長構成というのは、考え始めるとキリがない。 それに、いくらシステムを冗長化しても、それは「障害発生率をゼロパーセントに限りなく近づける」効果はあっても、障害発生が完全になることは、ない。 ただ、冗長化することの目的にはもう一つ、「復旧時間の短縮」という大事な側面がある。 今回の障害に際して、その面での利便性が発揮されたかどうか、記事からは判らないけれども。 いずれにしても現地で頑張っているエンジニア諸氏、および火消し役で奔走したであろうメーカー管理職の方の心中お察しします。。

公開された模様。 セキュリティに関するアップデートが主らしい。 情報源は こちら アップデート中に本体の再起動が実行されたせいなのか、4.0.1 の「SMS/MMS 起動が重い問題」は解決しているように見えるが、果たして・・・

ときどき、iPhone でメールを開こうとすると本文部分が見えなくなることがあったのだけれど、Apple の公式見解としては こういうこと らしい。 いわく、 解決方法 これは、ISO-2022-JP 文字セットを使う (コンピュータベースの) メールアプリケーションから送信され、かつ、ファイルが添付されたメールメッセージを受信すると発生します。この問題が発生した場合は、以下の手順を実行します。 送信者に、添付ファイルのあるメールを送信する際には Unicode 文字セット (UTF-8) を使うように依頼します。 だそうな。 あほー！ Apple の、こういうところが、昔から嫌い。　 ダサいだのなんだの言われながらも、ユーザの要望を愚直に具現化してきた Microsoft の方が、会社の体質としてはまだましな部分がある。

要するに、以下のアプリが調子悪い： SMS/MMS（起動、および送信完了が遅い） カレンダー（起動後、「今日」にポインタされるまでに時間がかかる。動作上は、起動直後に全てのカレンダーデータを舐めているようなのだが、それが重そうに見える） メール（たまにメール本文がまったく表示されない。画像などの、これまでは問題がなかった添付が開けないことがある） これらは、たぶん OS のアップデートというよりもアプリの個別アップデートで対応可？ あとは OS 全体の問題だと思うこと： 何かのアプリを起動中、急にボリュームレベルが表示されてそのままアプリが落ちる 何もしなくても、ごくまれに OS ごと落ちる 早急に対応して欲しい。

Apple の Main Stage、とても素晴らしいソフトウェアだとは思うのだけれど、いかんせん、すぐ落ちる。 ライブ中に落ちたらと思うと、、、怖、、 ダンプを吐いて落ちてくれるのでまだ良いような気はするが、、、

結局のところ、iOS のマイナーアップグレード（アンテナの表示方法改善）では誤魔化しきることができなかった、ということなのだろうか？ iPhone 4ケース無償提供プログラム、日本でもスタート

iPhone OS の マニュアル に以下の記載があった。 iPhoneが自動的に日付と時刻をアップデートするかどうかを設定する：「一般」＞「日付と時刻」と選択して、「自動設定」のオン／オフを切り替えます。 iPhoneの時刻が自動的にアップデートされるように設定している場合は、モバイルネットワーク経由で正しい時刻が取得され、今いる場所の時間帯に合わせて時刻がアップデートされます。 ご加入のキャリアによっては、一部の地域でネットワーク時間合わせに対応していないことがあります。旅行中は、iPhoneの時刻が現地時間に自動的に設定されないことがあります。 日付と時刻を手動で設定する：「一般」＞「日付と時刻」と選択して、「自動設定」をオフにします。「時間帯」をタップして、その時間帯に含まれる主要都市の名前を入力します。「日付と時刻」に戻るボタンをタップしてから、「日付と時刻を設定」をタップして日付と時刻を入力します。 ええと、全体的に意味不明です。。Apple らしいなぁ。 どこにも ntp と書かれていないので、同期のロジックがなんなのか分からない。 それに、キャリアがどうだとか、関係あるの？

ここ数日で、iTunes や Safari、iPhone OS がそれぞれアップデートされた。 いろいろあるけど、ぼくが個人的にこれは便利になった、と思ったことをいくつか挙げると・・ Safariについては、「新規ページを常に tab で開く」機能が正式にサポートされた。 いままでは環境変数をいじる（home ディレクトリ内の某ドットファイルに設定を書き込む）必要があって、そんなマニアックなことをしなくちゃいけないくらい珍しい機能なのだろうかと思っていた（苦笑） iPhone OS 4.0 については、やっとというか時刻同期が行えるようになった模様。 ただし、これほんとかどうかよーわからん。 「設定」＞＞「一般」＞＞ 「日付と時刻」 の中に「自動設定」というメニューが増えているのみで、いったい、何を、どう、自動設定するのか具体的に記されていない。 任意の ntp サーバを指定できるようなインターフェースは用意されていないし、自動設定するタイミングなども、いったいぜんたいどうなっているのかまったく不明。 そもそも、ntp による同期なのかさえわからん。 次期のマイナーアップデートでこの辺りの細かいところは改善するんだろうか。

UPSメーカの APC 社から定期的に送られてくる小冊子のタイトルは、「Uptime」という。 なるほど。 uptime というと、UNIX ではまさにアップタイム（起動時間）を調べるコマンドだ。 例えばこんな感じ。 Ex) Linux の場合 $ uptime 11:06:15 up 32 days, 18:08, 2 users, load average: 0.00, 0.00, 0.00 上記の例では、uptime を実行したマシンの連続稼働時間が 32日と 18時間であることがわかる。 ほぼデファクトと言ってよいくらい、UPS といえば APC である。 ほかにもいろいろなメーカの製品はあれど、よく見かける、ラックにマウントされているのはだいたい APC 製だ。 停電・瞬断が発生しても、UPS がきちんとしていれば uptime はそれだけ順調に伸ばすことができる。 「APC の UPS を導入していれば、電源の問題が原因となるサーバ停止の心配はありません」 小冊子の命名は、そんな思いが込められたのだろうか。 ところで、以前管理していた某金融系の HP-UX サーバの場合、定期的な自動ブートがジョブに組み込まれていた。 UNIXマシンを定期的に再起動させるなんて、Windows と一緒にするなよ、、、と言いたいところではあったが、「定期的に再起動させても問題がないということが大事」という言い分には、それなりに理にかなう部分もあると思った。 いまどきのファイルシステムはほぼ Journaling が採用されているし、よほどのことが無い限り inode が狂うなんてこともないだろう。 それでも、一年に一度くらい、再起動中に fsck が走ることがあるにはある。 不意なサーバ停止によって損害が発生するような金融系などの場合、こうした転ばぬ先の杖は必要なのだ。 ちなみに、その某金融系サーバが設置されていたデータセンターは、建物自体が巨大なUPSであったため、ラック内には APC 製品はおろか、そもそも UPS 機器は存在していなかった。

Time Machine のバックアップルールは、 過去 24 時間の 1 時間ごとのバックアップ 過去 1 ヶ月の 1 日ごとのバックアップ 過去のすべての月の 1 週間ごとのバックアップ となっている。 1時間ごとのバックアップを 24時間ごと繰り返し、 1日ごとのバックアップを1ヶ月繰り返し、 1週間ごとのバックアップを毎月繰り返す。 ちょっと贅沢な HDD の使い方ではあるが、一般ユーザとしては、ひと月以上前の状態に戻したい、などという特殊なリカバリは必要なく、とりあえず問題が起こったら、問題が発生していなかった直近の状態に戻せればいい訳で、その目的からして理にかなったスケジューリングだと思う。 ところで、DAW で Mac の内蔵 HDD へのレコーディング作業をしているとき、Time Machine は必ず OFF にした方が良い。 DAW アプリケーションのプロセスが HDD の I/O をコントロールしている裏で、Time Machine プロセスも同じ領域を同時に Read したらどうなるか。 当然のことながら、HDD のシークが二ついっぺんに実行されてしまうために、双方の Read に多少の遅延が発生する。 Read 遅延のスパンが延びれば延びるほど、アプリケーション側では HDD への書き込み用バッファの保持に負荷がかかり、エラーの原因となる。 作業中のリアルタイムバックアップ、という考え方は、例えば HDD が RAID 化されていたりすれば実現可能だが、Time Capsule などの外付け HDD に対して上記のようなスケジューリングによるバックアップを行う場合、HDD への書き込み頻度が高くなるようなアプリケーションを実行する際は注意した方が良い。

散歩する時など、予め キョリ測 を使って歩こうとしているコースの距離や消費カロリーなどを控えておくと、ただの散歩が数倍楽しくなる。 そのキョリ測が、最近 iPhone にも対応したようだ。 電池の消費が気になるのでまだちゃんと使っていないけれど、いろいろ便利そう。

「矢印記号」が、z キーと vi のカーソル移動キーとの組み合わせでタイプできる。 z h で ← z j で ↓ z k で ↑ z l で →

Fedora11 への Xen 有効化手順（Jan/2010 時点） 前提 Fedora11インストール時、「仮想化」オプションは導入 しない こと 最低でも HDD 100GB 以上、Memory 4GB 以上は搭載しておくこと 手順 # yum -y install gmp-static # yum -y install python-virtinst # yum -y install gitk dev86 vnc-server bridge-utils # cd /usr/src # hg clone http://xenbits.xensource.com/xen-3.4-testing.hg # cd xen-3.4-testing.hg # vi Config.mk ==> VTPM_TOOLS ?= n を VTPM_TOOLS ?= y に修正 # make xen # make install-xen # make tools # make install-tools # cd /usr/src/kernels # git clone git://git.kernel.org/pub/scm/linux/kernel/git/jeremy/xen.git linux-2.6-xen # cd linux-2.6-xen # git checkout origin/xen-tip/master -b xen-tip/master # make menuconfig ==> 下記注#1 # make # make modules_install install # vi /etc/grub.conf ==>下記注#2 # vi /etc/fstab ==>下記注#3 # reboot 注#1 以下が必須 CONFIG_XEN=y CONFIG_XEN_MAX_DOMAIN_MEMORY=8 CONFIG_XEN_SAVE_RESTORE=y CONFIG_XEN_DEBUG_FS=y CONFIG_XEN_DOM0_PCI=y CONFIG_XEN_DOM0=y CONFIG_XEN_PRIVILEGED_GUEST=y CONFI...