Dellユーザーやめました
メモリエラーで全く起動しなくなったのが2週間前。2〜3年のつもりがたった半年の命でした。そのまま放置してあったのだけど、先月末、ついに組み直しました。
Cel-2.8G/1GB にケースやらなにやら買い直しで約43k円。おまけに再インストールが必要でしたとさ。
鯖缶になりました(1)
マジメに数えたら相当な台数らしいのだが、さしあたり重要なのが１台。
- Linux 2.2.18
- Webサーバとして運用
こいつのお守りを完全に任されてしまった模様。「Linux使ってます」なんて言わなきゃ良かったのか？（笑）
そんなにわか管理者でもさすがにヤバイと思ったのは、
という状況で、これはイカンと。（※これまで数年、誰も気付かなかった／わからなかったらしい）
特に最後のはマズイので、別の用事で来ていた業者に聞いたら「試しに再起動してみましょうか」となって、案の定、二度と立ち上がらず。皆で必死に（知恵を出し合って）ディスク交換→再インストールして、ここからがようやく出番。
出来る限り最新のパッケージに入れ替え（rpm系なのが唯一の救い）、Web更新作業専用のユーザを作り（rootは使わないと宣言）、ローカルでログインするなと念を押し（「login:」で放置）、SSH,FTP,HTTPだけ使えるようにしてホッと一息。
しかし、如何せん古すぎる。しかも、ディストリごと入れ替えとか、そういうことをしてはいけないらしい。さて、これからどうするか。。。
NiftermやAircraftのメールデータをThunderbirdへインポート
http://normal.way-nifty.com/software/のNifty Mail to Eudora Mail Rev7をWindows2000で使ってみたメモ。
- niftoeud.lzhを解凍。
- NifToEud.exeを実行し、何もせずに閉じる。
- NifToEud.exeのあるディレクトリにNifToEud.INIが出来るので、これを以下のように編集して保存。
- [Data]
- NameEdit= → NameEdit=[名前（日本語可）]：送信済みメールの送信者名などに用いられる
- NifIdEdit=ABC12345 → NifIdEdit=[NiftyのID（英数字８文字）]：インポート後の
フォルダ名などFrom:に用いられる - NiftermEdit=C:\NIFTERM\MAIL\*.TXT → NiftermEdit=[インポート元メールデータ（テキストファイル）のフルパス]：自分で探す。ファイル名がインポート後のフォルダ名
- EudoraEdit=C:\EUDORA → EudoraEdit=[インポート先ディレクトリのフルパス]：NifToEud.exeのあるディレクトリにしておくのが無難か
- 再びNifToEud.exeを実行し、内容を確認しながらボタンを押していく。ファイル・ディレクトリの設定に間違いがあったら、一旦閉じて、NifToEud.INIを直接編集してからやり直す。
- 変換終了。
- Thunderbirdのツール(T)設定とデータのインポート(I)からメールボックス → Eudora → EudoraEdit=のディレクトリを指定 → ・・・
- インポート終了。
NIFTY MANAGER時代のメールも別に保存してあったはずだが、さて、どうするか。いや、そもそもどこに保存してあるのか。。。
追記
検証部分に関しては、自分の不注意によるマシントラブルのせいもあって、100%の自信があるわけではない。きちんと時間をかけて、手順を踏んでやりたかったのだが、このハナシを引きずり続けるわけにもいかないので、一応「まとめ」とする。
偉い人・詳しい人・多くの人に追試をして欲しいし、user_pref("plugin.expose_full_path", false);を広めたいのだが、さて、どうしたらいいものやら。ブログだからってTrackbackを打ちまくればspamだし。。。
id:SHK:20060304にも書いたが、これがバグだとか脆弱性だとか言うのではなく、自己責任だからこそ何でもホイホイ信用しちゃいけないんだ、ということ。
Firefox光速化とIE Tabについての検証とまとめ
※いきなりこのエントリに飛んできた方は、id:SHK:20060304とid:SHK:20060305#1141484610を参照してもらえるとハナシが早くなるでしょう。
1. user_pref("plugin.expose_full_path", true);は高速化／光速化にほとんど影響しないのではないか
この設定については、Firefox高速化Tipsとして、Firefox Tuning • mozillaZine ForumsやFirefoxを光速に至らしめ、さらばIE | textocean（※リンク先は「はてなブックマーク」）で紹介されているものである。また、前者の和訳解説付きとも言えるのがWo die Liebe dich findet |である。Firefox 1.0.xが浸透しつつある頃、多くのサイトやブログにおいて、「黙ってuser.jsにコピペ」状態で紹介・引用され、その効果に驚く声があちこちに見られる。もちろん、1.5.0.xとなった現在でも、これらの設定は相当の効果をもたらしているものと思われる。
前出の解説によれば、plugin.expose_full_pathはプラグインの完全な位置（フルパス）を示すかどうかを設定するものであり、デフォルトはfalse。「その他いろいろ役立つ設定(Useful Miscellanous Preferences)」の一つとして紹介されている。ただそれだけの機能であるにもかかわらず、高速化Tipsに含まれているのには、何か理由があるのだろうか？*1簡単に検証してみた*2。
検証方法は、plugin.expose_full_pathのtrue/falseを切り替えながら、numion.com - でいろいろなサイトを見て回ったり、ローカルに落としたTest rendering timeを読み込む、というものである。結果、有意な差は得られなかった。用いたマシンは以下の通りであり、すべて同じ回線（Ｂフレッツ-マンション）にルータ-ハブ経由で接続されている。それぞれの細かな違いは省略する。*3
- P4-2G/1024MB/Win2k/Firefox 1.5.0.1
- P3-933/512MB/Win98/Firefox 1.5.0.1
- Cel-600/256MB/Win2k/Firefox 1.5.0.1(tete)
- Cel-650@325/256MB/Vine Linux 3.2/Firefox 1.5.0.1(Vine)
2. user_pref("plugin.expose_full_path", true);はトラシューにのみ用いられるべきである
繰り返しになるが、plugin.expose_full_pathはプラグインの完全な位置（フルパス）を示すかどうかを設定するものであり、デフォルトはfalseである。2chのFirefox関連スレッドやもじら組のMozilla-gumi Forumなどにも登場しており、プラグイン周りのトラブル（FlashとかQTとかShockwaveとかJavaあたりが上手く動かないとき）にあたって、これをtrueにしてabout:pluginsを参照するのが第一段階とされている。Windows系におけるプラグインの位置は、（後述を除き）\Program Files\Mozilla Firefox\pluginsがほとんどであると思われる。しかし、Unix系におけるプラグインの位置は、~/.mozilla以下である。トラブル解決のために一時的にtrueとすることが必要な場合もあるが、about:pluginsと同様の方法*4で、インターネット上ののWebページにおいてもこれを取得・参照することが可能であることに注意しなければならない。*5
よって、悪意のある何者かに利用されないとも限らないので、トラブルが解決したら、すみやかにfalseに戻すべきであると考える。
3. IE Tabのような拡張(Extension)はプラグイン(Plugin)と連動して動作することを明記してほしい
拡張とプラグインがごっちゃになってる人／ごっちゃにしてる人のハナシは置いておく。IE Tabが登場・紹介されたときには「こんなことまでできるXULってスゲー！」と感心したものだが、今回の件で、言われてみればなるほど、プラグインとセットで機能していたことがわかった。ならば、私が知らない／使っていない拡張においても、こうした形式のものがあることが予想できる。
.xpiによってプラグインがインストールされることには何の問題もないし、プラグインの位置がプロファイルの中であることも問題無いはずである*6。しかし、それをインストール前やインストール中に知る術がなかった。自己責任とは言え、せめて、ietab.mozdev.orgのどこかにそれとわかる記述があれば納得できるのだが。
*1:高速回線-ハイスペックマシン用／低速回線-非力マシン用で記述の違いアリ
*2:ホントは細かく検証したかったのだが、メインマシンのトラブルで･･･
*3:本当は、すっぴん状態を用意して、きちんと検証しないといけないのだが
*4:javascriptを用いて
*5:参考リンク - アクセス情報【使用中のIPアドレス確認】 の下の方
