2007年9月17日月曜日

久しぶりに秋葉原に行ったら、すっかり変化してた

久しぶりといっても、9月4日にハードディスクを買いに行ったり、8月19日にCDを買いに行ったりしてたみたいですけど、そのあと、ソフマップの再編があったんですね。


200709161



新しいビルを建てて、なにやら変わるってのは知ってたのですが、ヤマギワソフトまでまとめて再編するとは、つい先日まで、ぜんぜん認識してませんでした。



さよなら、ヤマギワソフトのポイントカード・・・



200709160



ヤマギワソフトがソフマップ傘下になったのって、もう何年も前のことですが、別にどうっていう変化もなく、そのままでした。



あっと、ポイントカードが1度変わりましたっけ。別にソフマップカードに統合されるわけでもなかったのに。今回の再編で、旧ポイントカードは、ソフマップカードに統合されてしまうとのことです。ポイントを移すこともできますが、私は、旧カードに残っていたポイントを全部使い切ってしまいました。500ポイント単位でしか使えない、というシバリはありませんでした。



200709162



ソフマップも、何度か経営危機があり、今では、ビックカメラの傘下となってしまいましたが、結局、ソフマップのポイントカードは、ビックカメラのポイントカードへは統合されないのですね、残念。以前、統合は非常に難しい、という話を、ソフマップだかビックだかのエラい人がしてたような気がします。



今まで、複数の店舗で同じ商品を扱っていたり、かなり無駄なことをやってたような印象がありましたが、今回、ソフマップと、ヤマギワソフトをまとめてシャッフルしてから、きれいに並べなおした、ってかんじになり、店舗ごとに役割分担され、わかりやすく・・・したかったのでしょうが、私は、もう何だかわかんなくなりました(笑)。あれは、どこで売ってるんだよ~?!みたいに。



今日、買いたいCDがあったのですが、どこで売ってるんだよ?!ってかんじで、うろうろしてしまいました。結局、旧ヤマギワソフトっぽい品揃えの店は、あのでっかいヤマギワソフトのビル(火事になったとこ)の向かいがわの、黄色い建物のところにまとめられてしまった?感じです。1階にあったアレ系のCDは、2階と3階に移ってしまったようです(洋楽、クラッシック系は、見当たらなかった・・・どこへ?!)。最初、3階もあるとは知らず、無くなっちゃったのか!?と不安になりました。昔の3階って、普通の人は踏み入れては行けない領域じゃありませんでしたっけ?



でも、あの店舗は、狭いし、いづれ、切り捨てられてしまうのではないかと・・・?





ラオックスのThe Computer館は、完全閉店売り尽くしセール中。



200709163



一応、記念のために中を覗いてみましたが(笑)、さびしい雰囲気で一杯、あまり長居したくない感じになりました。欲しい商品も無かったし・・・



以前、ここのトイレは何度も利用させてもらいました。お世話になりました。ちなみに、ここ最近は、ヨドバシに行ってました。





あと、こっちは知らなかったのですが、石丸電気も「創業以来最大級の大変身のため閉店処分」とのことです。





200709164



閉店セールをやってるのは4店舗で、SOFT1は含まれてないですね。



200709165



そうか、石丸電気は、今は、エディオングループに入ってたんだ。



おや、「ツクモeX.カード・石丸アイアイカード/ポイント相互使用サービス終了のご案内」ってのが出てるけど、そもそも、相互使用できるなんて知らなかった。





という感じで、9月になったとたん、秋葉原では、大変化が始まってたんですね。







オマケ



ザ・コン以前のラオックスの広告。





200709166



200709167



(2007/9/26)
9月20日に閉店しちゃったんですね。この記事が、いろんな思いも込められて、いいかんじでした。

三浦優子のIT業界通信
時代を背負ったラオックス ザ・コンピュータ館が閉じた日














ところで、あの建物の写真を撮ろうとして、うまく構図がとれる場所がなくて弱りました。
こんな感じになっちゃうんです。



200709261



ニュースサイトの記事の写真も、おんなじかんじで、斜め下からの構図が多いようです。別に気にしてないだけ?





(2007/10/9 追記)
私は知らなかったのですが、昔、ヤマギワテクニカという大きなパソコンショップがあったそうです。住所では、現在、ドンキホーテがあるところあたり。もしかすると、「アニメイト」か、「とらのあな」のところかも。今あるドンキホーテは、以前は、ラオックスのアソビットシティで、その前は、TZONEミナミで、そのときに新しいビルとして建てられたんだったと思います。




200710096




200710097




(2010/03/25 おまけ)

「I/O」 1984年5月号 (工学社)の「関東マイコンファンの買い物ガイド ~ あきはばら地図」



20100324akiba




 



2007年9月16日日曜日

爆発しちゃまずいのでは?!

以前から、言葉の使い方で、ちょっと引っかかっていたCM。



かつてはけっこう有名だった某家電量販チェーン(今は、経営再建中?)のCMで、共感できるところもあって、少しだけ笑えるところもあるのですが・・・
(これの前のCMは、客をバカにしてるのか?って感じがして、かなり嫌な印象を受けていたので、それに比べて、より好印象になってるかも)



20070915



買ってくれた人へのサポートが充実してる、という意味を強調するために、

サポート爆発

と表現してるのでしょうが、個人的には、どっちかというと、この言葉からは

顧客からサポート依頼が殺到して、サポート担当者は、処理しきれなくなってしまい、もう手に負えない状態。
つまり、サポート担当者が爆発状態

っていう状況を想像してしまいます。



爆発って、たとえば、部屋の掃除をずっとしていなくて、あまりにも散らかっているために、部屋が爆発、と表現するなど、ネガティブなイメージが強いのですけど、こんな風に感じるのは私だけでしょうか。





2007年9月14日金曜日

(FreeBSD) ja-ng-1.4.4_1にアップデートしたら、画面表示がおかしくなった

私は、古い人間なので、ngというテキストエディタを10数年、愛用しています。古い人間だったら、viじゃないのか、って話もありますが、そこは、まあ、人の好みです。

viなんてのは、しょせん、できそこないです

とまで、おおっぴらには言いませんが(笑・・・ viの作者自ら、そういうことを言ってたみたいですけど。viよりも、もっとまともなエディタを完成させたところ、ディスククラッシュか何かでソースコードをすべて失い、気力もうせた、とかいう有名な話)。



大学の計算機実習で、実習テキストに説明されていた、viを使わされたのですが、3分も経たないうちに

これはダメだ

と見切りをつけて、nemacsと入力してました(笑)。viの、Escapeキーを押してモード切替しなければならない、ってのがまったく受け入れられませんでした。



あのころ、テキストエディタといえば、PC-9801のMS-DOS上で動くMIFESだけしか知りませんでした。その後すぐ、MIFESから、VZ派となりまして、今でもWindowsでは、WZです。



その後、nemacsは重たい、ということで(ワークステーションの処理速度と、ログインユーザー数などから、そういうことになってしまう時代でした)、日本語も使える軽いテキストエディタとして、ngに出会いました。その前に、uemacs?マイクロemacs?そんなのを一瞬使ったこともあったかも。



その後、nemacs時代がけっこう続いた後、mule、そして、xemacs時代が長く続き、最近、xemacsも、もうだめかな、っていう気もしてきているので、emacsに戻る準備をしています。



ngを愛用してるといっても、/etc/や/usr/local/etc/以下にある設定ファイルをちょこちょこっと書き換える程度のために使うだけです。それでも、この軽さは、手放せません。VZ派ならわかる、テキストエディタは軽いに限る、ってことでしょうか。昔は、ngでも重かったりしたんですけどね。9600bpsのシリアル端末で使ったりもしてたし。





さて、そのngなんですが、FreeBSDのports/japanese/ngにあるやつを、portupgradeしたら、ja-ng-1.4.4_1 というのになったのですが、なんだか、よくわかりませんが、画面表示がおかしくなりました。

kterm
の中で「ng ファイル名」とやって実行すると、



200709131



ファイルの先頭部分しか表示されず、途中から下の方が、表示されません。
control+Lを連打すると、少しだけ表示内容が増えるのですが、基本的にはダメ。

xterm
の中で同じことをやると、



200709132



もっと下の方まで表示されたのですが、1行、表示されてません。



ウインドウサイズをもっと小さくすれば、下まで表示されるようです。



環境変数で、TERM=ktermや、TERM=xtermになっていて、TERMCAPは無し。



なんだこれは、困ったぞ!ということになったのですが・・・japanese/ng-develにしたら、正しく表示されるようになりました。ja-ng-1.5.b1 です。



あーもー、japanese/ng-develでいいや・・・



ng-1.5って、けっこう手が加えられているみたいです。



残念ながら、古いコードは、新しいOSでもそもまま動く、とはいえないのですね。terminal関係って、ナニなところがあるみたいですし。



そういや、以前、Solarisで、pkgsrcのngをビルドしたら、うまくいかなかったっけ。



2007年9月13日木曜日

ネットワークベースのバックアップソフト「Bacula」に深刻なバグ ~ バージョン2.0.x以降は、最新の2.2.3へアップグレードせよ、とのこと

Baculaは、ネットワーク上でクライアント・サーバ方式で動作するバックアップソフトで、何台ものコンピュータのファイルのバックアップを、全自動で、効率的に採ることができます。



私も、だいたい1年前から使い続けているのですが、とってもお世話になっています。一度、操作ミスで、PostgreSQLのデータ全部をふっとばしたときなど、バックアップがあってよかったと、感謝、感謝、でした。



似たような機能を提供する商用ソフトもあわせて使っているのですが、その値段が、もう、なんだこりゃ?!っていうくらいするのに、Baculaは機能面では遜色なく(ユーザーインターフェイスに難あり、という人もいますが、個人的には十分だと判断してます)、それなのに無料で使える。寄付を募っているので、なんかの協力したいとは思いますが。





FreeBSDで、portupgradeコマンドでいろんなソフトウェアをアップグレードしているときに、

おや、ここ数日で、Baculaが連続してバージョンアップしてない?!

と気がつきました。いったい何があったんだろう?と思って、BaculaのWebサイトを見たら、最新バージョンの2.2.3で深刻なバグ(Serious Bug)を修正したとのこと。

・・・そもそも、バージョンが変わって何が変更されているかも確認せずに、portupgradeでバージョンアップしちゃう私も悪くて、いーかげんなわけですが、まあそれはさておき・・・
 (いいのか?!それで)

その深刻なバグというのは、バックアップしたファイルをリストア(バックアップから取り出して復旧させる)できなくなることがある、という不具合だそうです。怖いですねぇ。



詳しい情報は、ここに出てました。Bug #935と呼ばれています。





Bacula-announceメーリングリストのアーカイブが、ここで見られます。





これは、必ず発生するバグではなくて、いくつもの条件が重なったときだけ発生するもので、だからこそ、これまで見つからなかったんだと思われます。バージョン2.2.3へアップグレードしたら、念のため、フルバックアップを実行するように、とのことです。





一応、bug-935.txtを少しだけ読んでみたので、Bug #935についての技術的な詳細を、要約してメモっておきます。



Bug #935の症状は、リストアしたとき、バックアップから取り出せないファイルが多数ある、というもの。



(1) バグが発生するのは、複数のバックアップ・ジョブを同時実行しているときだけ。しかも、ストレージ・デーモン(storage daemon)が、新しいボリュームへ切り替えようとしたときだけ発生する。つまり、複数のジョブが同じボリュームへ書き込んでいて、別の新ボリュームへまたがって書き込まれるときだけ。



(2) ハードディスクにボリュームを作っているときだけ、このバグが観測された。テープの場合は、観測されていない。



(3) ある特定のタイミングでは、おそらく、テープの場合でも発生する可能性はある。



(4) この不具合がおきるのはタイミング依存で、複数のクライアントが存在するとき。しかし、1つのクライアントで、複数のバックアップ・ジョブを同時実行しているなら、同様に発生するはず。



(5) 調査しているときにわかったが、クライアントの動作がのろいとき(インクリメンタル・バックアップをしているとき)に、この不具合が発生する確率が高い。



(6) このバグは、バージョン2.0.xと、2.2.xに存在する。



(7) バージョン1.3.8でも存在すると思われるが、再現できなかった。発生するかどうかは、タイミング依存であり、テスト環境ではfile daemonのバージョンが2.2.2だったせいで、再現できなかったのかもしれない。



(8) データは正しくボリュームへ書き込まれている。ただ、間違ったインデックス(JobMedia)が、データベースに書き込まれてしまっている。ボリュームが切り替わるときのJobMediaに、古いほうのボリュームではなく、新しいほうのボリュームが入っている。詳しくは後述。



(9) この不具合を回避するためには、複数のジョブが同時実行されないようにするか、複数のジョブが同時実行しているときに、新しいへボリュームへまたがらないようにすればよい。つまり、使用中のボリュームのサイズが十分大きくなってきたら、手動で、ボリュームにfullだとマークすればよい。



(10) 複数のジョブを同時実行していない場合は、このバグの影響を受けない。



(11) 複数のジョブを同時実行していて、テープに書き込んでいる場合で、ジョブが、別のテープにまたがるときに、このバグが発生する確率はそれなりにあると思われる。



(12) 複数のジョブを同時実行していて、ディスクに書き込んでいる場合で、ジョブが、別のテープにまたがるときに、このバグが発生する確率は、かなり高いと思われる。



(13) このバグはStorage daemonにのみ存在するので、クライアント(file daemon)をアップデートする必要はない。しかし、storage daemonをアップデートしたら、directorもアップデートすることを推奨する。



===============================



~~~この後、バグについての詳しい解説が書いてあるのですが、長くて、ややっこしいし、難しいので、省略します。興味があれば、bug-935.txtを読んでみてください。バグが発生したときのログメッセージなども示しています。



斜め読みした限りでは、マルチスレッドなプログラムで、グローバル変数の更新を適切に行っていなかった、というバグらしくて、ある特定のタイミングによっては、望ましくない順序で、グローバル変数の更新が行われて、おかしな(矛盾した)結果になってしまう、みたいなもののようです。



並列動作するプログラムを作ったことのある人なら、誰でも経験しそうな、あぁ~いかにもありがち!!っていうバグっぽいですね。



■ 過去記事



(あまり関係ないけど、Baculaについて少し触れています)





2007年9月12日水曜日

2007・08・XX・XX・XX

TVのCMで、たまに見かけるたびに思うのですが・・・



200709111

2007・08・XX・XX・XX

というのは、やっぱり、2007年8月のいつか、ということじゃないのでしょうか?





200709112



もうそろそろ、9月半ばにさしかかってますけど、Soonって、いつなんでしょうか?



今日の日付で、特別損失がどうのこうのというプレスリリースが出てたりしますが、関係ないですよね。ね? ね?



べ、べつに、CMを、待ってるわけじゃないんだからねっ!





ひょっとして、このCMが2007年8月から流れ始めた、という意味だったりします?



てっきり、8月XX日から、新しいCMが流れます、という意味と思っていたんですけど。







昔、春休みとか夏休みにやってたアニメはおもしろかったと思う。




(2007-09-12)
首相辞任、時期首相はマンガ大好きのあの人?ってなことから、ブロッコリーの株価も上がったみたいですね・・・ きっといろいろな思惑があるんでしょうね・・・

CMの制作を発注したけど、支払いが滞って、受け渡しが停止されてしまって、いつまでたってもComing soonになってると邪推してたんですが、仮にそうだとしたら、なんか進展あるのかも?! べ、べつに期待なんかしてないですけど。



(2007-09-13)
株価。そうなると思った。



2007年9月11日火曜日

(FreeBSD) ddコマンドでパーティションまるごと高速コピー・・・しようとして、ちょっとハマった

どうやらハードディスクが壊れているらしいので、新しいハードディスクを買ってきました



Windowsを新規インストールする時間と手間が惜しいので、FreeBSDのddコマンドで、ハードディスクのパーティションをまるごとコピーすることにしました。初心者には、あんまりお勧めできない方法なんですが。



Windowsの場合、というかどのOSでも普通はそうなんですけど、OSとして使用中のパーティションの内容(Windowsなら、Cドライブなど)を、別ディスクに正確にコピーすることはできません(昔、Macintoshでは、当たり前のようにできたんですけど・・・)。



別の起動ディスクでブートさせて、コピーする場合でも、ブートローダがきちんとコピーできない場合があったり、それに、ファイル単位でコピーするので、ランダムアクセスに近い挙動をするので、それなりに時間がかかります。



一方、ddでセクタ単位でコピーする場合は、シーケンシャルアクセスになるので、データ転送速度は、ドライブの限界までだせるので、短時間でコピー作業が完了します。



ただし、ddでコピーする場合の欠点としては、もしもコピー元ディスクに不良セクタ(bad sector)があるときは、どのファイルが壊れたのかわからないままコピーされる、という、なんだかなぁ~、な結果になります。壊れてるんだから仕方ないですが。



作業手順としては、だいたいこんな感じでしょうか。



  1. コピー先の新HDDに、コピー元とまったく同じ大きさのパーティションを切る


  2. ddで、パーティションをまるごとコピーする


  3. コピー先の新HDDのMBRにブートローダをインストールする。

・・・という感じですが、なんだか、今回、いろいろとはまったので、失敗したことのメモを残しておきます。あんまり参考にならない話です。


● sysinstallコマンドでパーティションを切ろうとしたら、うまくいかなかった。なぜ?



sysinstallを実行して、Configureを選択、Fdiskを選択します。そして、コピー先の、新しいディスクを選択。



200709101


いつもそうなんですが、ジオメトリが変だから無視してそれっぽい値を使うよ、といわれます。とりあえず今は、まあいいや、と思うことにします。



200709102


おっと、その前に、あらかじめ、コピー元のディスクのパーティションを、fdiskコマンドで調べておきます。「fdisk ディスク名」、たとえば、「fdisk ad0」とかで、表示されます。



200709103



1つめのパーティションサイズは、32772537セクタでした。



そこで、sysinstallのFDISK Partition Editorで、このセクタ数、32772537を入力してやります。



200709104


つづいてパーティションタイプを指定しますが、コピー元のタイプが7だったので、7を指定します。



200709105


これで新たにパーティションが作成されるのですが(実際には、まだディスクに書き込まれていない)、なぜか、サイズが32756472になっていて、さっき指定したサイズとは違っています。



200709106


昔からのUnixユーザーなら、すぐに、「ははぁ~ん、シリンダ境界にあわせて、パーティションサイズを自動的に調整したんだな」とか思うんでしょうが、

32756472 / 63 / 255 = 2038.9960784313

・・・割り切れないじゃないですか。ぜんぜんシリンダ境界になってません。



ちなみに、

32756472 / 63 = 519944

なので、トラックあたりのセクタ数でなら割り切れるんですが、それなら、

32772537 / 63 = 520199

でもあるので、もともと入力した数も割り切れます。これ、何なんでしょうね?



いまどきのHDDの場合、トラックごとにセクタ数が違ってたりするらしいので、シリンダ境界に合わせるのは、たぶん、あまり意味ないと思います。だいたい、ヘッド数が255なわけないですし。



ということで、sysinstallを使うのはあきらめて、fdiskコマンドで、全部、数値を手入力して、まったく同じサイズのパーティションを作ってやりました。



ようするに、「fdisk -i ad0」とかやって、ちまちまと、全部の数値を、コピー元パーティションとまったく同じになるように、入力してやりました。



sysinstallがうまく使えなかった件は、ちょっと悔しいです。今度、sysinstallのソースでも眺めてみようか。


● ddでコピーしたのに、なぜか正常にコピーされなかった



基本的に、ddでコピーするときは



dd if=コピー元パーティション of=コピー先パーティション bs=ブロックサイズ



みたいな書式で指定するようになっていて、ブロックサイズは、本当は512(バイト)なんですが、大きめの値を指定すると、データ転送速度が上がるので、今回の場合、1Mバイトとして、



dd if=/dev/ad10s1 of=/dev/ad14s1 bs=1m



みたいにやってみたのですが、これは、今回の場合、ダメでした。



なぜなら、コピー元に不良セクタがある場合、ddコマンドは、読み出しエラーが起きた時点で、コピーを終了してしまうから、パーティションの内容の途中までしかコピーしてくれません。



200709107


そういうときは、ddに、convオプションを指定します。



conv=noerrorと指定すると、読み出しエラーがあっても処理を継続するようになります。ただし、読み出しエラーがあった箇所をすっとばして書き込むので、コピー先で、だんだんと、セクタの位置がずれていってしまいます。こういうときは、conv=noerror,syncと指定します。



えーと、以前、こんなのを書いたことがあって、その中で、ddでパーティション丸ごとコピーする話も入れておいたのですが・・・

magicrescueで壊れたHDDからデータだけ救出【最終手段】


今回、これが、なぜか、うまくいきませんでした。どういうわけか、途中から、セクタがずれていってしまうのです。



ちなみに、セクタのずれがないかどうかは、ddに、iseekオプションを指定して、適当な位置を無作為に指定して(ずれていないことを確認するだけなら、パーティションのおしまいのほうを選んで、同じデータか確認すれば、基本的にはいいはず)、ちまちまと調べてみました。きっと、もっとうまく方法はあるんでしょうけど。



コピー元のデータを確認
   dd if=/dev/ad10s4 bs=1m iseek=90000 count=1 | hd | head



コピー先のデータを確認
  dd if=/dev/ad14s4 bs=1m iseek=90000 count=1 | hd | head



てゆうなことを繰り返しながら、試行錯誤しているうちに気がついたんですが、bs=1mではなくて、bs=16kとか、もっと小さい値を指定すれば、ずれなくなりました。え~?!って感じですが、なんか、そうなりました。



bs=512なら、たぶん一番正確にコピーされるとは思うのですが、データ転送速度が1MBytes/sec程度しかでなくて、あまりにも遅すぎて、お話にならないので、やめておきました。



bsを大きくしていけば、最大で、40MBytes/sec以上でてました。「iostat 1」コマンドで確認できます。



200709108



しかし、セクタのずれる現象が気になったし、bs=16kにしても30MBtes/sec程度だったので、よしとすることにしました。



なぜずれちゃうんでしょうか? bsで指定したサイズ内でだけ、ずれてたのでしょうかね? どうも、そうとは思えなかったんですが。まあいいや。


● ブートローダは、個人的に気に入ってるMBMを入れた



これはとくにトラブルもなく、うまくいきました。



なにはともあれ、これで、やっとWindowsのCドライブの内容を、そっくりそのままコピーできて、新しいHDDでブートすることに成功しました。