システム・PC

弱り目に祟り目

青森帰ってきました。飛行機から眺めた金星がきれいでしたよ。

で、自宅で作業用しようとしたんですが　PCがBIOSすらうつらない・・・

故障・・・ぐふっ。

まぁ、念のためまたマザーを眺めてみましたが、予想にたがわず、またもっこりコンデンサが原因。型番はGA-6IEML。

DSC06631.JPG

もっこりは何度目かもうわからないけど、さすがにこれだけ「もっこり」→「糸冬」を繰り返すともう慣れましたわ。

このマザーとCPUは廃棄決定。我が家はマザーボードの墓場と化しております。

ウィルスその後

まずはjackさんのコメントにコメントをw

NODは会社で５ライセンスを取っているので、いつでも入れられる状態になっていて、このウィルスに関連する中国語の情報サイトを見ると、NODでは一応検出できるらしいというのが書いてあったので、ぐぐーっと入れてみたい欲望が高まりました。

てなわけで、ノートン削除後、NODを入れたんですがNODも起動しない。EXEが確かにあるのに起動しないということは、どうもレジストリを書き換えられたっぽいです。orz

そういわれてみれば、ノートンをアンインストールしてもあれ程しつこくでるWindowsXPのセキュリティ警告もでません。

で、とりあえず昨日の１１時の時点での復元ポイントが残っていたので、そこにレジストリを戻し、なんとか起動するように。

このウィルス作ったやつはコロスーーーーーーーーーーーーーーー

と、いうわけで、とりあえず再インストールですかね。ということでセコセコバックアップをとっている次第。

この糞忙しいときに、ムキーーーー

qcrwwxc.exe

タイトルのウィルスに感染しましたわ。
その作業でてんやわんや。

この名前で検索しても中国語のサイトしかヒットしないので、かなり新しいウィルスの模様。おそらくトロイの木馬タイプ。

アルバイトの面接で、中国人の留学生の方が作ったという作品を見るため持参したUSBメモリを入れたら即座に感染しました。

感染すると、画面上にWindowが表示されまくり、何も作業ができなくなります。そのときたまたまネットにつないで無かったからそうなったのであって、ひょっとして繋いでいたら何かを送信していたかもしれません。

ただ、ファイルが書き換えられた可能性もあるので、その点がちょっと不安。

ちなみに感染後ノートンが起動しなくなりました。南無

私が調べたところ、感染すると、 D：の下に mpqoisq.exeが作られ、またａｕｔｏｒｕｎ．ｉｎｆが作成されたようです。 mpqoisq.exeが C:\windows\system32\qcrwwxc.exe C:\windows\system32\dnebdil.exe を呼び出す模様。この二つのexeファイルは削除してもまたmpqoisq.exeで生成されます。当然隠しファイルになっているので、普通の状態では見れない。 とりあえずこのウィルスが何をするのかは、これから偉い人が調査するでしょうが、削除としては １) mpqoisq.exe autorun.infの削除 2) qcrwwxc.exe dnebdil.exeの削除 3) msconfigで２)のプログラムが起動時に実行されないようにする の３点。 削除は、なぜかExploerから削除できないので、DOSコマンドから行いました。久しぶりにDOSコマンドを思い出しましたよ。 システムファイル、隠し属性がついているので削除は次のようにしてやりました。 >cd \windows\system32 >attrib -H -S qcrwwxc.exe >del qcrwwxc.exe 他のファイルも同じ。 なんかもう散々でしたわ。この対応で丸々半日費した。 これを気にノートンに見切りを付けよう。NODに乗り換え。

結論から言えば

XML関連の業務をいろいろやってるんですが結論から言えば

「デフォルトのネームスペースは使用するな」

XPATHとかXSLTとかもろもろやり始めるとそういう結論になりました。

でも、もうデフォルトネームスペースがんがんつかっちゃったので手遅れ。orz

ISO23001の規格作ったやつを　その２

またまた魂の叫び。

24時間ほど問い詰めたい。

この規格理解して実装システムを作れるやつなんて世界に何人もいないんじゃないかなぁ？漠然と理解するだけでも、そんなに沢山人はいないと思う。（←いまこのへん）

例えば、XMLの技術に関しても、

XML Schema
XPath
Namespace

などを理解しているのは最低条件。もちろん実装する人は実装の仕方も知ってなければならない。

さらに、複雑難解なXMLの更新のアルゴリズムの記述を理解する必要があって、そのアルゴリズムの難解な符号化を理解する必要がある。

そこにはオートマトンのような情報工学の大学を出ないと習わないような知識が当然であるかのように記述されてる。フルに実装するなら、Compressの圧縮アルゴリズムも知ってる必要がある。

もちろん規格書は全文英語。

これを全て実装したら・・・そうだなぁ・・・数千万は頂きたい。そうじゃないと割りあわん。こっちだって技術の安売りはできんわい。これより安くしたいなら安くできるところを探してくれぃ。

以上魂の叫びでした。

またもっこりコンデンサが原因か

飛んだサーバのMBをじっくり眺めてみた。すると

NEC_0001.JPG

ギャワーーーーコンデンサがもっこりしている。

今回の悪役はNRSYの1000μFの電解コンデンサ。

ぐぐったら一発ヒットでした。やられた。

ご参考

2005年07月12日(火)PCシボンヌ
2005年07月13日(水)もっこりコンデンサが原因か・・
2005年07月14日(木)詳細調査
2005年07月14日(木)Socket478

マイコンＢＡＳＩＣマガジン創刊号に乗せたゲーム

に載せたやつ。

風化が激しいんでデジタル化してみました。（ってコピーしただけですが）

1ページ目
2ページ目

いまさらながら打ち込みしたい人は是非どうぞ～。（さすがにいないか）

機種はベーシックマスターＬｖ２という日立製のマイコンです。ＣＰＵは６８００。（当然６８０００ではない）。メモリは確か１６Ｋくらいではなかったかと記憶しています。

当時私は確か中学生で、ラジオの製作の愛読者でした。で、そのラ製付録にマイコンＢＡＳＩＣマガジンなる冊子がありまして、それに奮起されて投稿した記憶があります。

たぶんＢＡＳＩＣマガジン初のマシン語プログラムのはず。創刊号ですから当然と言えば当然なんですが、ラ製時代にもそういった記事はなかったんじゃないかなー（うろ覚え）

なおプログラムですが、今となっては書いた自分もよーわかりません。

が、記憶をたどると・・

マシン語はアセンブラなんてないので、全部コード表をみながらの手打ちです。こういう作り方だと最初に紙にかかないと破綻するのでノートを真っ黒に汚していろいろ書いていた記憶があります。とくに相対ジャンプ命令などは指をおりながら一つ一つ計算して・・・今じゃ考えられませんね。

また、隕石が多数出るのですが、直接コードをタイプしていく構成にするとループとか配列の扱いが実に難しいのです。そこで、私がとった手法は隕石の数分だけマシン語コードを動的に生成してそこにジャンプするというものです。

プログラムがプログラムを生成して実行するわけですね。昔はこういったテックニックがよく使われていましたが、最近じゃ使う必要もないくらい開発環境も動作環境も高性能になってしまいましたねぇ・・

原稿料は1万円だったかな？もう覚えてないや。

しかし、めんどくさいのでかなり手を抜いている・・とか中学生のころからあんま変わってませんな。性格。流石ワシ。

xemacs-mule

ここ数年愛用してるんですが、妙なバグを発見。とある文字列をUnicodeに変換するとき正しく変換しないようです。

utf-16-beで保存

fe ff 30 e2 30 e6 00 0a

utf-16-leで保存

ff fe 30 e2 30 e6 00 0a

なぜこんな誰にでもわかりそうなバグが取れていないのか・・・不思議。

svnでcommitしてもメールが届かないことが・・

昨日の設定で完了とおもいきや、稀にcommitメールが飛ばないことが判明。

手動でスクリプトを動かしたりして調査したところ、どうも複数のディレクトリに渡ってcommitしたときに正規表現として好ましくない文字がディレクトリにあるとバグるという如何にもなバグをハッケン。多分最新バージョンだと直ってるんだろうな。

というわけで該当箇所をさくっと修正。

今度こそOKか？

svnでcommitしたらメールを送る

いろいろ調べてみました。

svnでは誰かがcommitするとレポジトリの下にある　post-commitスクリプトが実行されるというのがsvnの仕様っぽいので、ここにメールを送る仕組みをいれるようです。

雛形で最初っから　commit-email.plというのがあるのでそれを実行すれば設定完了・・・なわけですが、どうにも日本語のコミットメッセージが文字化けします。

しかもJavaみたいに？文字が大量に出るという。Java準拠のバグ（？）とすれば、これはUTF-8にするときに対応コードがないのでへくってるということになるんでしょうね。

svnでは確かにlocaleが正しく設定されていないと文字コードエラーみたいなのが出ます。svnはコミットメッセージ等は多分ユニコードで管理してるんでしょう。（ちゃんと調べたわけではないですが）

で、それをUTF-8に戻すことができないんだから、LANGの設定を ja_JP.UTF-8にすれば完了じゃんとおもたら・・・

svnのレポジトリを管理しているPCがFreeBSD4.9。なもんで、ja_JP.UTF-8がありませぬ。 しょうがないので、 ja_JP.eucJPで動かすことにしました。 content-Typeは　text/plain; charset=euc-jpで あんま美しくないですが、とりあえずこれでメールはちゃんと飛ぶようです。 ついでいうとソースのコメントはEUCで書かれてるんでこれはこれで好都合だったり。