Windows、何度目かのインストール

何度も何度もトラブルが生じてはやり直しているWindowsのインストールだが、今回は元々ダメになっていたシステムを潰してバックアップに使ったため、改めてインストールを行う必要があった。

毎回、インストールすると異常なトラブルに見舞われる。例えば、シャットダウンできない、Windows Updateの構成に失敗する、ファイルの操作に対して異常に長く待たされる、などだ。どの時点でトラブルが発生しているのか、慎重に見極める必要があった。

基本的なインストール手順はさんざん繰り返した通りで、シングルドライブ構成にした上でUEFIでブートすれば良い。事前にblastしておく。ブートしたら、ASRock提供のCDを使ってドライバインストールを行う。何度も再起動するが、完了が表示されるまで粘り強く待つ。停止したように見えることもある。

完了したところでWindows Updateを適用して、正常に動作することを確認する。問題なかった。

念の為ここでバックアップをとっておく。結構複雑だ。sdc1より手前のsdcと、sdc1, sdc2はddによるバックアップ。難しいのはsdc1より手前で、3TBあるためfdiskで扱えないが、parted -lではブロックサイズが表示されない。そのため、gpartedを使って確認し、sudo dd if=/dev/sdc bs=512 count=2047 > ~/archive/raid/HDD/fm2+killer/141125-windisk0.imgとした。

Windowsシステムドライブであるsdc3については、ntfscloneの--save-imageオプションを使うことで、早く、小さくできる。

さて、ミニマル構成で音楽制作環境となるWindowsだが、それでもかなり多くのソフトウェアをインストールしなければならない。

  • PeaZip
  • UnEditor
  • Cyberfox
  • Launchy
  • HinaFilemaster
  • GeekUninstall
  • Google日本語入力
  • XnView
  • Sleipnir
  • AMD Driver/HQFD
  • As/R

そしてappearanceを理由に次もインストール

  • mactype
  • UxTheme Multi Pactcher

しかしAMDドライバーのインストール中にブラックアウトし、待っても回復しない(!)。もっと待てばいいのかもしれないが、さすがに信号もきれて応答もないので、強制電源断。システム回復をしようとしたが、とりあえず正常に動いているようだし、ドライバは更新されていたのでそのままにしてみる。

構成意図についてだが、仕事上使うと思われる言語入力、画像閲覧、ウェブブラウザのソフトウェア、迅速にアクセスするためのソフトウェア、そしてインストールなどメンテナンス作業に必要なアーカイバとアンインストーラ、という内容だ。

PeaZipはサポート形式が多く、ひとつ入れておくのに最も有力な選択肢ではないだろうか。Linuxではコマンドで処理してしまうが、Windowsにおいてはこれが最も良いと思っている。

ウェブブラウザは一種類では色々不安がある。Sleipnirは別にそれほど使いやすいわけではないが、現在はBlinkを使うようになっており、Blink/Geckoをフォローする上でのチョイスだ。別にsleipnirでなく、Opera betaでもいいのだが。

画像についてはプラグインなしで多くの形式をサポートし、比較的軽量で必要な機能があることを重視した。信頼性も高い。

エディタはUnEditorは以前からのお気に入りであり、もう長い間使い続けている。そして、これを上回るWindowsのエディタにはまだ出会っていない。

ファイラはいまいちだ。しかし、HinaFilemasterのほうがAs/Rよりはマシなので、とりあえずこれといった感じか。As/Rの操作性が改善されると良いのだが。Ctrl/Shiftによる選択ができないのがあまりにもダメすぎる。

MacTypeのプロファイルはWin7、CyberFoxのテーマはLavaFox、VisualStyleはU-7imate Final Version for Windows 7とした。このビジュアルスタイルはインストーラ付きだが、isoアーカイブにしているなど、扱いは意外と厄介。PeaZIPの威力が確認できる。

なお、ドライブの暗号化を検討していたのだが、UEFI+GPT構成の暗号化が可能なのは、BitLockerか、商用ソフトウェアだけのようだ。現状、どちらも新規の出費なしには利用できない。

そして、U-7imateが正しく適用されなかったので、アンインストールしたら起動しなくなった。

すべてのドライブを書き戻して(!)再構成。まずAMD HQFDだが、一晩放置しても信号は落ちたままだった。次にU-7imate。VisualStyleだけでなく、パッチャーやユーティリティもあり、アイコンやスタートボタンも変更される。これに任せるのが良いようだ。これでうまく機能した。

カーソルについてはtronnixを採用。壁紙は、

また、フォントについては源柔フォント、源真フォント、Rounded M+、Noto Sans Japanese、Rictyを持ち込んだ。動画編集もする可能性があるため、今後より多くを持ち込むかもしれない。

そしてNI Audio 4 DJ, TASCAM US-366のドライバーをインストールし、SONAR X3 PRODUCER一式, Audacity, Aimpをインストールする。これでおおよそ旧来のシステムとなる。KOMPLETE ULTIMATEとFL STUDIOとCUBASE 6 LEがあったりするが、別に今でなくてもいいだろう。音楽制作に本腰を入れて取り組める状況ではないし、システムが安定稼働するかどうかを見極めてから、と思う。

ちなみに、XGWorks 4.0のインストールも試みたが、インストーラ自体が起動しなかった。調べてみると、http://www.tonoko.info/2010/09/09/2342/。やる人いるんだなぁ…という感じだ。

インターネットは既に死んでいる

私はインターネットは1992年(商用インターネット開始より以前)からやっている。自宅インターネットは2000年からで、それ以降は本格的にやってきた。また、単に部分的に使うというよりも、文化・人事的側面に強い関心を持ち、それに関わってきた。

しばらく触れない間もあったが、それでもネットがどう移り変わってきたのか、どういう文化が形成されていたかということは知っている。そこで、現状について定点観測的見地から述べたい。主張が入っているし、多分に主観的な批判を含むことをご了承頂きたい。

まず重要になるのは、インターネットとはそもそも何か、ということだ。軍事目的であり、今も米軍の支配下にある、という陰謀説的神話を持ち出したがる人は多く、この都市伝説は未だに広く信じられているが、これは事実ではない。そもそも出発点からして、軍事目的とは言えなかった。きっかけはスプートニクであり、ソ連に対抗するためであったが、政治目的と軍事目的と科学者と科学好きが混沌を繰り広げた結果、the Internetプロジェクトは早々にARPAのすみっこにあるだけの「居候」へと追いやられている。結局、研究をはじめるためのきっかけと環境整備を国が(政治または軍事を目的として)やった、というだけのことになった。

origin達の考える「インターネット」はまとめると次のようなものだ。

  • 自由
  • より民主的
  • 対等
  • 政治・国家に対して独立

だからインターネットは非常にUNIX的であり、またHacker的なものだ。もともと、Origin達はhacerであり、さらにthe Internetが発展する過程では多くのUNIXサイトがつながっていくことでネットワークが形成されてきた。つまり、インターネット文化の根底はUNIX文化でありhacker文化だと言って差し支えない。

インターネットの中で重要なのは何か?といえば、結局のところこれらがひとつのことを指していることからも分かるだろう。個人が主体性を持ち、すべてが対等である自由だ。何かを決定する「偉い人」などなく、マイノリティが差別されることもない、そういう世界の構築だった。事実、インターネットの規格であるRFC(近年はRFCが新しいインターネット技術の標準となる例は聞かないが)は誰でも投稿はできるし、合意が形成されれば採用される。NWGは、寝ることも忘れてしまう科学者たちが、肩書やしがらみに関係なく、自分の好きなことを大いに語り、議論をかわし、そして合意が得られたものは形になる、というものだった。

もともとインターネットは「一般のもの」ではない。アメリカで商用インターネットが始まったのは1992年、日本では1993年だ。この時にようやく「金を払えばインターネットに接続できる」時代がやってきた。それまでは大学、研究者、インフラを構成しているサイトによって成り立っていた。ちなみに、大学ではインターネットよりもUSENETが先行していた。今や公共ネットワーク=インターネットだが、もとよりそうだったわけではなく、もっと色々あった。しかしいずれにせよ、当時コンピュータネットワーキングをやっているというのは、技術者でもなければ好き者(エッジユーザー)に決まっていたので、その文化はかなりの共通性が見られたのは言うまでもない。

つまり、Real Worldにおける地位や立場、あるいは権力や国家といった上下や強制とは無縁の、独立した民主的な世界(ここで「民主的」というあたりがアメリカ的だと思う。ただし、実際は共和主義に近い)が、地理とは別の世界を構築することで実現できる、そんなひとつのユートピアだった。科学者的な夢想でもある。

だが、近年は極めて政治や司法の介入、制御をしたがる。根本的に地理で区切られるReal Worldとは構造が違うにもかかわらず、同じことを無理矢理にあてはめようとしている。それだけでもインターネットは死んだといえるのだが、それだけでなく人々が現実における立場や地位や権力を振りかざしたがるようになり、ネットの独立性を尊重しなくなったことによっても死んでいる。

the Internetは今や全くおもしろくない。かつての居心地の良い、侵害されない空間とは異なる。Real Worldにおける侵害、迫害がそのまま持ち込まれ、例えば貧乏で地位もないという人が対等な条件で勝負できる環境であってインターネットは、既にそのReal Worldにおけるディスアドバンテージを継承することを強要するものとなっている。

私が「インターネットの様子がおかしい」と言い出したのは2002年だが、やはり急速に死に向かっていたことを確かめざるを得ない。

そうしたこととは別に感じるのが3点

  • よそよそしくなった
  • 民度が下がった
  • リテラシーが下がった

最後のリテラシーが下がった、ということについては、コモディティ化と同一の現象であると考えていいだろう。分からないから調べる、分からないから考えるでなく、わかろうとも思わないし、自分の都合のいいように理解し、それと異なるものは排除する、という傾向はコモディティ化にともなって浅識なカジュアル層が増えることによって避けられないことだ。the Internetやその文化について知らないという問題よりも、そもそも頭を使わないという問題があるが(例えば、インターネットが公共の場である、ということを一切無視し、自分の知り合いでない人に見られることに対してキレたりする、などだ)、それは必ずしもコモディティ化が理由ではない。だが、敷居が下がって、思考を持たない人で入ってくれるようになってしまったというのはあるだろう。人々が「考えなくなった」というのはインターネットとは別の次元で感じるが。

しかし、前2つは理解しがたい。1つ目について、「事件が多いから」などと言いたがる人は多そうだが、それはあまり関係ない。チャットやSNSでも「暇」「暇つぶし」という言葉ばかり並び、会話することに対して極めて消極的だ。以前は、インターネット上では多くの人々が会話に対して貪欲だった。ビジュアルがない分、相手の人間性に食い込もうとするのが普通だったし、人間性から入る分、パソ婚の持続性は高かった。だが、現在は極めて淡白であり、会話する意思自体が希薄だ。「事件があるからインターネットをコニュニケーションツールとして使っているにも関わらずコミュニケーションを求めない」というのは理由になっていないので成立しない。例えば、Twitterは一方的な発信であり、内容もspam率(内容のない発言)が高い。「Twitterに慣れたのが原因だ」という言い方もできる事象だが、実際はそのような精神性に対してTwitterの希薄さ、一方的である部分というのがマッチしたから流行ったということではないかと思う。Twitterのコミュニケーションはチャットと比べ著しく密度が低い。ちなみに、SNSはコミュニティ系のものほとんどマイルール的儀礼の押し付け合いしかみられない。これは、Mixiの当初からあったことなので、もはやSNSの宿命なのかもしれないが。

もちろん、ひとつの見方として、Mixiが流行りだして世の若いOLさんもカフェでおしゃれなランチを食べながらMixiをするのがオシャレ、というようなよくわからない風潮になり、そそもインターネットが何でどう使うのかという意識がないまま使い出した(そういう人はチャット全盛よりもあとの時代に入ってきた人なので、意識がないまま使っていたとしても、それは発信ではなく一方的に受け取るだけだったろう)ということも問題なのかもしれない。インターネットでコミュニケーションをとる意思があるわけではないのだが、皆やっているからという理由でコミュニケーションツールを使うために、実のあるコミュニケーションにならない、というわけだ。

だが、これは答えをくれない憶測だ。なぜならば、LINEは多くの場合ある程度の目的意識を持って使われるのだが、LINEのログで出ているものをみても、多くの場合希薄だ。もちろん、Twitterなどのように「ほとんどの場合内容がない」ということはないし、現在のチャットのように「たいてい会話も成立していない」ということもないのだが、それでもかなり双方向性が乏しいと感じる。以前のチャットならばもっとがっつくようにコミュニケーションを求めていた。結局のところ、人々は積極的かつ濃密なコミュニケーションを求めなくなった、という精神性に答えを求めざるをえない。

民度が下がった、ということについては、以前はインターネットで罵詈雑言を並べ立てるようなことはなかったし、差別的な発言というのもあまり見なかった。もともとキャラクタベースのコミュニケーションで、語られることの何が真実か検証することはまずできないという中だったので、差別のしようがなく、そのためにUSENETであれコンピュータネットワークコミュニケーションに慣れると差別しなくなる、というのがあったため差別意識の低下という現象が見られたというのはあるのだが、ともかく(対等であるために馴れ馴れしいというのは別として)基本的には礼儀正しかった。けなす言葉もまず見なかったし、そのようなことをするにしても、嫌味を言うなど遠回しな方法が使われることが多かった。2ちゃんねるはかなり異質で例外的な存在だった。だが、現在はYouTubeのコメント欄にせよ、Twitterにせよ、とにかく差別的・排除的な罵詈雑言が並ぶ。自分こそ絶対善で、異物は排除されるべしという発言があまりにも多いし、死ね、一生刑務所に閉じ込めておけ、といった人のことをまるで考えない排除の言葉が並ぶ。そのための威力行使も度々みられるようになったし、排除する、叩く口実がある相手を見つけると嬉々として人格や人権を否定して大勢で騒ぎ立てるのが当たり前になっている。複数のケースにおいて騒いでいる人が同一という可能性は多いにあるが、それでも一部の少数の人だけとは考えられないだろう。今はそれほど対象となるものは少なくない。かつては人格攻撃は最も恥ずべき行為として指弾されていたのだが、今はたしなめる言葉もまず聞かれない。

これに関しても、例えば2ちゃんねるがコモディティ化したことそのような文化にネチズンがなれ、そのような生態を持ったのだ…と解説することはできるが、これもやはりそうではないだろう。なぜなら、ネットだけでの現象でもないからだ。やはり、これも精神性に対して答えを求めざるをえない。

そして不思議なのは、変化の過程においても度々言及してきた通り、「同じ空間における定点観測」のみならず「同じ人物に対する観測」においてもその傾向が顕著に見られる、ということだ。その場合、通常は何かに染まったとかんがえるべきで、それが広く見られる以上はネット空間のような(あるいはもう少し限定して「Twitterの普及」のような)普及しているツール、環境の変化である、とかんがえるべきだが、それでは卵が先か鶏が先かという問題になってしまう。私がわからないものとしてはTVがあるが(私はTVを持っていない)、たとえTVの業界や関係者がそうした傾向を持ったのだとしても、それは人がやることなのであり、なぜその人たちがそのように染まったか?という点を問題にすればやはり同様である。

「なぜ」という部分は推測はできるが確定はできないのだが、ともかく随分と息苦しく殺伐とした世の中になったものだと思う。かつては例えReal Worldが腐っても、インターネットには私達が作る理想郷(未完成)があり、そしてそれはReal Worldを変える力を持っていたが、今やすっかりReal Worldに侵略され、滅ぼされ、占領されてしまった。

私達が知るインターネットは既にない。今インターネットと呼ばれているものは、Real Worldで地位や権利をもった人々が侵略し、占領した世界だ。

ある場所を見ると、かつてそこにいた人々はいなくなっている。彼らがどこに行ったのかはわからない。だが、そこでのコミュニケーションが嫌になって離れたということは想像に難くない。今はインターネットなしでは生活できないはずだが、コミュニケーションは避けているということだろうか。

心ある人々はどこへ行ったのだろう。

Manjaro LinuxのKDEルック問題

Manjaro 0.8.9 XFceだが、XFceが少々不安定になってきたので、KDEを使えるようにしようとした。pacman -S kde-metaで一式入るが、使ってみるとおかしな部分がある。というのは、UIがstyleを反映せず、昔のWindowsのような外観をしているのだ。これについては少々悩んだが、qtconfig-qt4を用いてstyleを設定することで解決した。

しかし、gtkアプリに関してはそのままだ。設定ファイルの場所は分かっているが、有効なオプションが分からない。検索すると試験運用中なLinux備忘録にgtk-chthemeを使うと良いとある。これはcommunityで提供されているので、これを使って設定すれば良い。

また、KDEの場合conkyの設定に一工夫必要。これはArch wikiのConky項目に従えば良い。

今日になってfcitx-mozc-utのアップデートがきているが、trunk svnのクローンに失敗してビルドできない。

PureDocの自動update timestamp

先日、PureDocで自動last-updateを入力するコードをいれたが、これでは生成時に元ドキュメントをいじるため、mtimeが変化してしまう。たとえ、mtimeをチェックするようにしても、「mtimeが変わっているから」変更すると、書き込むほうが遅いためやはり毎回mtimeが変更されupdateされたことになってしまう。

色々試したのだが、結局はlast-updateがメタYAMLにない場合のみ設定する、ということにした。変更した時は手動で削除してくださいね、という仕様。全自動とはならなくなったが、恐らくこれが最も無難な方法だろう。

begin
if docstr =~ /^##--.*$/ && $' =~ /^##--.*$/
yax = $`.each_line.map {|i| i.sub(/^# /, "") }.join
header_meta = YAML.load(yax) || Hash.new

# Set since timestamp if a document generation is first time. (And update Last update time stamp.)
if ! argv_first.empty? and
( ! header_meta.key?("last-update") )
( ! header_meta.key?("since") )

File.open(argv_first, "r+") do |f|
content = f.read

# Set since Time object if since is not set.
if ! header_meta.key?("since")
since = Time.now
header_meta["since"] = since
end

content.sub!(/^##--.*?^##--.*?$/m) do
el = $&.each_line.to_a # Get header texts.

el.insert(1, "# since : #{since.strftime '%Y-%m-%d %H:%M:%S %:z'}\n") if since # Add since if since is not exist.
# Update last update time if last-upadte is not set or last-update is older than mtime.
if ! header_meta.key? "last-update"
el.insert(1, "# last-update : #{File.mtime(argv_first).strftime '%Y-%m-%d %H:%M:%S %:z'}\n") # Add last update timestamp
end
el.to_s
end or next

f.seek(0)
f.truncate(0)
f.write( content )

end

end

DOC.meta = header_meta
end
rescue
DOC.meta = {}
end

btrfs, その他Manjaroのセッティング

btrfs

先日のトラブルを乗り越えてbtrfsの作業を完了。

今回は開いている/dev/sdb1をまずaddし、そして/dev/sdd2をdelete、/dev/sddをblastして/dev/sdd1をadd、というように繰り返していき、これまで/dev/sdd2, /dev/sde2, /dev/sdf2という構成だったところを、/dev/sdb1, /dev/sdd1, /dev/sde1, /dev/sdf1という構成に変更した。これにより、2TBx3だった3TB RAID1ボリュームは、3TBx4の6TB RAID1ボリュームへと倍増した。この増強により、データ格納もだいぶ安心できる状態になったと言っていいだろう。なお、このあとさらにbtrfs filesystem balance /homeしたあと、念の為btrfs scrub start /homeしておいた。

balanceをwatch -n 15 btrfs filesystem show /homeしているとかなりおもしろいことがわかる。バラバラにバランスをとるように移動していくのだが、100GBあたりでsdbとsdd、sdeとsdfの容量が同じになり、sdbとsddが同時に減少、sdeとsdfが同時に増加する。つまり、奇数の不均一な容量のディスクが使われている状況では、どこにどうデータがはいっているかというのは入り乱れているのだが、4台でバランスすると、sdbとsdd、sdeとsdfをそれぞれミラーした構成にしたことになる。btrfsはそのようにする必要はないが、可能ならそうしようとする、ということだろう。

LVMの場合、リバランスはできないし、ZFSでも容量が一定でない奇数のディスクをミラーする、ということ自体ができない。このミラーリングの器用さはbtrfsの大きな魅力だ。対障害性も結構高い。ただ、機能面で安定しない部分があるようだ。普通に使う分には十分安定していると思うが、何かの操作で障害が起きる場合がある。現状、まだバックアップはしておいたほうがよさそうだ。クラウドストレージのほうがいいかもしれないが、TB単位のデータをバックアップすると転送に時間がかかりすぎるだろう。ちなみに、当家のFTTH回線の速度は、下りで300kbps、上りは50kbps程度である。ナロードバンドというやつだ。しかも、何時間も接続できなかったりする。

Claws mail or Sylpheed

Sylpheedから派生したClaws Mailだが、見た目かなり似ている。何が違うのかよくわからなかったりする。

もともとはClaws Mailは外部MDAについて新規フォルダを検索すれば自動でサマリを更新してくれたのだが、設定をいじってもフォルダはみつけるがメッセージをみつけない(設定をいじらないとフォルダもみつけない)だが、再構築すると時間がかかるし、しかもClaws Mailは再構築するとフォルダを最後にもっていってしまい、ローカルフォルダが他にもあるとデフォルトのsentやdraftフォルダは最初にあるものが使われてしまう。

そこでSylpheedを使ってみたのだが、「次へ」でうまく拾ってくれなかったり、フォルダを移動する時の確認を消せない、そもそも新規フォルダを探すことができない、など結構不便。

機能の違いは、設定メニューがまるで違うことから感じるところもある。細かなところだが、色々違う。好みによるだろうが、Claws MailのほうがSylpheedよりも用意されている可能性が高いので、Claws Mailを使っているほうが移行性が高いのかな、という気はする。

MIDI on Manjaro/Arch Linux

結局一番簡単なのは、Timidity++とTimidity++ Freepatsをインストールする。そして/etc/timidity++/timidity.cfg

dir /usr/share/timidity/freepats
source /etc/timidity++/freepats/freepats.cfg

あとはtimidity -iAするか、systemctl start timidity.serviceして、aplaymidi –port 128:0 fileするなり、もしくはtimidity -in fileするなり、あるいはtimidity -igするなりで演奏できる。

Fluidsynth+FluidR3も試したが、かなりノイズが乗る上に、音源の質もあまりよくない。Freepatsはそれなりに聞ける。これはほぼArch Linux wikiのままだ。

FluidR3の音はひどいが、AURにはTitaniumとUnisonも存在。どちらかというと、Unisonのほうが音が良いが、相性は楽曲によるので一概には言えない。TitaniumまたはUnisonならば、曲によってはFreepatsよりもよさそうだ。

XFce4 on Manjaro Linux

カーソルが正常に表示されるようになったことについてだが、おそらくはXFce Theme Managerを使うとXFce起動時にXFceのX設定を読み込むため、一度画面がリセットされる。これによってカーソルが正常に表示されるようになったのだろあ。

ちなみに、カーソルテーマはLCD-Toxicにしている。3次元的である上に透過色で、しかも3D的に滑らかなアニメーションを見せる、こんなことできたんだというようなカーソルテーマだ。

Conky

Conkyを導入しセットアップ。ネットからとってきた.conkyrcをベースにカスタムしてみた。

フォントはMgen+ 2cp, Garnet, Dejevu Sans Mono, Promenadeを要求するので注意されたい。

## General
background yes
disable_auto_reload true
update_interval 5.0
#update_interval_on_battery 10.0
total_run_times 0
double_buffer yes
text_buffer_size 8192

## Window
## Window
own_window yes
#own_window_type desktop
#own_window_colour black
#own_window_argb_visual true
#own_window_argb_value 100
own_window_type override
own_window_transparent yes
gap_x 1550
gap_y 20
minimum_size 350 5
maximum_width 350

## Behavior
alignment top_right
use_spacer none
format_human_readable yes
short_units no
show_graph_range no
show_graph_scale no
draw_graph_borders no
cpu_avg_samples 2
net_avg_samples 2
diskio_avg_samples 2
top_cpu_separate false
top_name_width 25
no_buffers no

## Text/Font Settings
override_utf8_locale yes
use_xft yes
xftfont Garnet:size=8
xftalpha 1.0
uppercase no

## Border/Shade/Outline
draw_borders no
#border_width 1
#stippled_borders 8
draw_shades no
default_shade_color black
draw_outline yes
default_outline_color 40b0ff

## Color
default_color white
# Title
color1 0f3074
# Bar
color2 2d56ab
# Top Title
color3 0f3074
# Top 1
color4 fbff8a
#color5
#color6
#color7
#color8
#color9

## Template
# CPU Graph
template0 ${cpugraph cpu\1 \2,\3 40b0ff 2d56ab 100 -t}${offset -\3} CPU\1: ${cpu cpu\1}%
# CPU Top <indent1> <indent2> <indent3> <indent4>
template1 ${top name \1}${goto \2}${top pid \1}${goto \3}${top cpu \1}${goto \4}${top mem \1}${goto \5}${top io_perc \1}
# Memory Top <indent1> <indent2> <indent3> <indent4>
template2 ${top_mem name \1}${goto \2}${top_mem pid \1}${goto \3}${top_mem mem_vsize \1}${goto \4}${top_mem mem_res \1}${goto \5}${top_mem mem \1}
# Disk I/O Graph
template3 ${diskiograph_\2 \1 \3,\4 40b0ff 2d56ab 10000 -t}${offset -\4} /dev/\1 \2: ${diskio_\2 \1}
# Disk I/O Top <indent1> <indent2> <indent3> <indent4>
template4 ${top_io name \1}${goto \2}${top_io pid \1}${goto \3}${top_io io_read \1}${goto \4}${top_io io_write \1}${goto \5}${top_io io_perc \1}
# Network Graph <ethN>
template5 ${\2speedgraph \1 \3,\4 40b0ff 2d56ab 1000 -t}${offset -\4} \1 \2: ${\2speed \1}
# Disk Bar template6 \1 ${goto 55} ${fs_used \2}/${fs_size \2} ${goto 150} ${color2} ${fs_bar 6 \2}
# Load Average Graph
template7 ${loadgraph \1,\2 40b0ff 2d56ab 4 -t}${offset -\2} Load Average: ${loadavg}${alignr}Processes: ${running_processes}/${processes}
# Top 5 <template num> <indent1> <indent2> <indent3> <indent4>
template8 ${color4} ${template\1 1 \2 \3 \4 \5}\n${color} ${template\1 2 \2 \3 \4 \5}\n${color} ${template\1 3 \2 \3 \4 \5}\n${color} ${template\1 4 \2 \3 \4 \5}\n${color} ${template\1 5 \2 \3 \4 \5}

TEXT
${color1}${font Promenade:style=Regular:size=9}System ${font}${hr}
${color } ${nodename} – ${sysname} ${kernel} on ${machine}
${color } Uptime: ${uptime}
${color1}${font Promenade:style=Regular:size=9}${voffset 3}Processor ${font}${hr}
#${color } CPU ${freq_g 0}GHz: ${color2}${cpubar cpu0}
${color } CPU ${freq_g 1}GHz: ${color2}${cpubar cpu1}
${color } CPU ${freq_g 2}GHz: ${color2}${cpubar cpu2}
${color } CPU ${freq_g 3}GHz: ${color2}${cpubar cpu3}
${color } CPU ${freq_g 4}GHz: ${color2}${cpubar cpu4}
${color }${template0 0 20 325}${voffset -5}
${color }${template7 20 325}${voffset -5}
${color3} Command${goto 150}PID${goto 200}%CPU${goto 250}%MEM${goto 300}%I/O
${color }${template8 1 150 200 250 300}
${color1}${font Promenade:style=Regular:size=9}${voffset 3}Memory ${font}${hr}
${color } RAM: ${mem}/${memmax} – ${memperc}%${goto 190}${color2}${membar}
${color } Swap: ${swap}/${swapmax} – ${swapperc}%${goto 190}${color2}${swapbar}
${color } B/C: ${buffers}/${cached}
${color3} Command${goto 150}PID${goto 200}VIRT${goto 250}RES${goto 300}%MEM
${color }${template8 2 150 200 250 300}
${color1}${font Promenade:style=Regular:size=9}${voffset 3}Disk${font}${hr}
${color }${goto 10}${template3 sda Read 20 166}${goto 175}${template3 sda Write 20 166}${voffset -20}
${color }${goto 10}${template3 sdb Read 20 166}${goto 175}${template3 sdb Write 20 166}${voffset -10}
${color3} Command${goto 150}PID${goto 200}Read${goto 250}Write${goto 300}%I/O
${color }${template8 4 150 200 250 300}
${color }
${color } ${template6 / /}
${color } ${template6 /tmp /tmp}
${color1}${font Promenade:style=Regular:size=9}${voffset 3}Network ${font}${hr}
${if_up enp4s0}${color }${template5 enp4s0 Down 20 166}${goto 175}${template5 enp4s0 Up 20 166}${voffset -20}${endif}${if_up wlp0s16f0u1}
${color }${template5 wlp0s16f0u1 Down 20 166}${goto 175}${template5 wlp0s16f0u1 Up 20 166}${voffset -5}${endif}
${color1}${font Promenade:style=Regular:size=9}${voffset -5}Calendar ${font}${hr}
${color }${font DejaVu Sans Mono:style=Bold:size=7}${execi 1800 LANG=C cal -3}${font}
${color1}${font Promenade:style=Regular:size=9}${voffset -5}Yahoo News ${hr}${font}
${font Mgen+ 2cp:style=Medium:size=7}${rss http://headlines.yahoo.co.jp/rss/all-dom.xml 1 item_titles 10 }${font}

Windows XP, WX11K

KYOCERA WILLCOM WX11Kのデータバックアップ

WILLCOMのフィーチャーフォン、Kyocera WX11Kを使っているのだが、この使いにくいダメフィーチャーフォンは、データのバックアップもなかなか厄介だ。唯一の対応ソフトはトリスターの携帯万能だが、なんとこれがドライバは32bitのみを提供するという!!!!32bitのOSは既にlegacyになっているというのになんという仕様だ。

結局、もともと32bitのWindows XPがインストールされていたNEC Mateをリカバリーして使用した。

とにかく説明がわかりにくい。どう操作すればいいのか分からないし、ドライバインストールも勝手に変なタイミングでうごき、しかも十分なフィードバックがない。ケータイのドライバのインストールが必要、というのはそれなりの経験と勘での判断になる上に、さらにケーブル別にドライバーも必要で(やはり説明はない)、それを予め設定しておく必要があり、さらにそのケーブル別がまたわかりにくい。その他USBが3種類あり、その区別がつかないし、WILLCOMケーブルというのもある。

「モデムUSBケーブル」で通ったが、どうも最初に接続した時は最初のドライバインストールでビジーなっており、インストールできなくなっていた。

WindowsXP

これに伴ってWindowsXPを11年半ぶり程度に触った。

触ってみると、すごくいいな、というのが印象だ。インストール後、バルーンヘルプで案内が出る。なにをどう操作すればいいかというのが直観的に把握できるようになっている。また、目的のためにどこをどう触ればいいか、というのも直観的にわかるようになっている。

設定方法が奥深く行っている上に項目が意味不明になっているWindows 7などよりもはるかに使いやすい。UIもわかりやすく、改めてWindowsXPのUI設計は優秀だったなぁ、と思ってしまう。このような操作ガイド方法はLinuxでもあまり採用されていない。どちらかというと、ツアー、チュートリアルなどが多い。

WindowsXP、このように表面的には優秀だが、中身はカオスを極めていた。ろくでもないアクセス制御とつぎはぎの構造、安全性二の次、整頓されていない邪悪なAPIなどだ。IE6/7などはそれが如実に現れていたものだと言ってもいいだろう。

だが、こうしたユーザーフレンドリーさはMSはどこに置き去りにしたのだろう。

暗号化ファイルシステム EncFS と eCryptFS について

まえがき

linuxにおいてファイルシステム作成後にも利用可能な仮想ファイルシステム形式の暗号化ファイルシステムといえば、EncFSとeCryptFSだ。EncFSのほうが昔からあるが、eCryptFSはUbuntuが(LUKSではなく)使っているので一般化しているのかもしれない。

EncFSもeCryptFSも日本語のドキュメントに乏しい。それどころか、英語でさえあまり見つからない。まして、両者がどう違うのか、という話になると全くだ。そこで、私が色々試してみたところをまとめることにしようと思う。

基本的な暗号化強度と暗号化方式

EncFSがAESとBlowfishをサポートするのに対し、AES, Blowfish, DES3EDE, twofish, cast6, cast5と多彩な形式をサポートするのがeCryptFS。ブロックサイズはEncFSが指定可能で、eCryptFSはブロックサイズは暗号化方式ごとに固定。キーサイズはそれぞれがサイズは異なるものの選択は可能。

暗号化鍵としてはパスフレーズとopensslを両者サポートする。

暗号化の機能

EncFSは「ファイル名の暗号化(block/stream)」「ファイル名のファイルパスに基づく暗号化」「ファイルを暗号化する際にランダムなヘッダバイトを入れることで同一の内容であっても暗号化の結果が同一にならないようにする」といった機能がある。一方、eCryptFSはファイル名を暗号化するかどうかのみ聞かれる。

両方共にplaintext passthroughがオプショナルだが、これが何を意味するかが分からない。

eCrypsFSのほうは結構ややこしく、Ubuntuフォーラムをみるとファイル名暗号の復号化ができずレスキューできないことについて述べられている。それが示されるFNEK Signatureなのだろう。文章をみる限りでは~/.ecryptfsをどこかにバックアップしておけば復号化できるように見えるが、実際のところは分からない。

その他の機能

EncFSは–extpass=programというオプションがある。これはprogramの標準出力をパスワードとみなす、というもの。これを使うとパスフレーズを入力せずにパスフレーズが使えるため、手動で入力するのであればパスフレーズなどよりもはるかに複雑な方法を利用できる。単純にcatであっても、どのファイルをcatしたか、という予測は選択次第ではかなり難しい。たとえばhistoryなどで読まれてしまうというリスクはあるにせよ、通常は分からない。

しかしこの威力は別の暗号化されたボリュームにそのためのスクリプトを書いてしまう、という方法だろう。例えばeCryptFSなりLUKSなりでホームディレクトリを暗号化しておき、ログインスクリプト(例えば.profile.xinitrc)でマウントする、というようなことも可能。もちろん、その場合はオフライン暗号強度はEncFSの鍵とベースとなる暗号化ファイルシステムの鍵強度のウィーケストリンクとなる。

特徴

ファイル名暗号化した場合、どちらも暗号化後のファイル名が長くなるため、ベースとなるファイルシステムよりもファイル名の長さが制限される。256byteファイル名の場合、EncFSは190byte、eCryptFSは144byteに制限される。

また、EncFSはEncFSディレクトリ直下の.encfs6.xmlが暗号化の定義となっており、それがあるディレクトリがEncFSディレクトリとなる。このファイルと暗号化ファイルをコピーすればバックアップが可能。一方、eCryptFSは暗号化情報をファイル自身に持たせる。そのため、暗号化ファイルのみをコピーすればバックアップが可能。

しかしながら、eCryptFSはこのためにファイルサイズがかなり大きくなる。.encfs6.xmlはそれほど大きくないので不思議だが。7バイトのテキストが12kBほどになる。このため、MHディレクトリのような小さなファイルが大量にあるケースでは容量をかなり圧迫する。

どちらも元のファイルに一対一で対応した暗号化ファイルが作られる。そのため、マウントせずに暗号化ディレクトリをコピーすればバックアップがとれる。

EncFSはマウントしたユーザー以外はrootであってもアクセスできない。かならず利用するユーザーでマウントする必要があり、ユーザーのプライベートなデータ以外を置くことはできない。また、EncFSファイルシステムの中のディレクトリをマウントポイントにすることはできず、EncFSのマウントを入れ子にすることはできない(EncFSファイルシステムの中にEncFSファイルシステムを置くことはできる。マウントされた暗号化ファイルシステムのディレクトリをマウントポイントとしてマウントすることはできない)。

eCryptFSはこのような制限はなく、//homeをマウントすることも可能。

AESとBlowfish

一般には暗号化が速いのがTwofishとCAST5、復号化が速いのがBlowfishだと言われている。だが、実際は暗号化するデータのサイズ、バッファサイズ、そして内容にもよるので、一概には言えない。大きなデータに対してはBlowfishよりもAESのほうが高速であると言われている。逆に3DESは非常に強力だが、遅い。AES+Twofish+Serpentよりも遅いというのだから。

SSHのようなストリームの場合はBlowfishが高速だが、ブロック暗号ではそうとも言えない。BlowfishよりもAESのほうが強力であると見られているため、SSHと比べじっくりとりくむことができるディスクデバイスの暗号化はAESのほうがいいかもしれない。一方、メジャーなAESは解読しようとしている人が多いので解読されるリスクが高いという考え方もあるが、多分それは杞憂だろう。

AESの128bitは不十分だと思われる。192bitは速度と安全性のバランスがよく、安全性を確保するには256bitにすべきだろう。128bitは解読が可能であり、192bitは解読される可能性がある(ただし、並のクラスタでは生きてるうちには解読されない。スーパーコンピュータなら解読可能だろうし、計算機の進化や量子コンピュータも敵かもしれないが、それははるか未来のことだろう)。256bitは将来的にも計算量安全性が確保される。

個人的にはBlowfishが好きだが、EncFSならAES、eCryptFSならAESかCAST5が有力な選択肢だろう。LUKSはCAST5をメインとする。MHディレクトリならBlowfishもありかもしれない。

btrfsとの格闘

btrfs replace /dev/sdd2 /dev/sdb1 /homeしたら、システムが停止し、I/Oも停止。やむなく再起動したところ、案の定マウントできない。ちなみに、10.3%で、writeerrが1776あった。

理屈から言えばbtrfsはこのような場合でもデータを失ってはいないはずだ。なぜなら、btrfs replaceは新規デバイスにデータをコピーし、成功した場合にリファレンスを付け替える構造だからだ。

だが、現実はこのbtrfsファイルシステムにアクセスできない。1TB近いデータの損失は、バックアップをとってから結構重要なデータも増えており、致命的な状態だ。RAIDでカバーすることを基本としているだけに、ファイルシステム破損のダメージは大きい。

とりあえず、btrfsckしてみる。1200万ものエラーが発見された。だが、これによってマウントはマウント時にかなり待たされるものの、可能になった。ただし、失敗することもある。

それで再起動してみたが、やはりマウントできずコンソールに落ちる。btrfs device replace status /homeした上で、btrfs scrub start /homeしてみる。すぐにプロンプトは戻るが、btrfs scrub status /homeすると0secでabortされていることがわかる。明らかに異常な状態だ。

ファイルシステムをマウントすることができ(いつの間にかマウントを失っていることもあるが)、またファイルシステムにアクセスできるのだから、今のうちにデータをバックアップしておくべきだ。そう思い立ち、今までWindowsが入っていた(どのみちリカバリーのために消さなくてはいけない)ディスクをnukeし、XFSで再フォーマットした上でデータをコピーする。

構造として、/home/home/aki/shareにサブボリュームがマウントされているので、なかなかややこしい状態になっている。多分、btrfsのサブボリュームは、単にマスターボリューム以下にあるあるディレクトリをファイルシステムルートにみせかけているだけだと思うので、純粋にbtrfsのマスターボリュームをコピーすればいいのではないか、という気がするのだが、それでうまくいかなくかった時が怖いので、素直にサブボリュームをマウントした上でそれをコピーする。

最初のほうはかなりひっかかっていたが、やがてスムーズに動くようになった。もしかしてアクセスしながら自動的にbtrfsが修復していったということだろうか?(私のbtrfsは、2レッグミラーになっている)

そして完了後に別のサブボリュームをマウント、すぐに反応してくれる。異常な印象は受けない。ためしにscrubしてみると、なんと正常にスタートした!/homeも一応バックアップを取った上で、再起動してみると、正常にブートした。しかもそれだけではない。かねてから正常に動いていなかった「display1で正常にポインターカーソルが表示されない」「SEが出ない」も解消されている!一体なぜだろう。

とりあえずscrubした上で途中になっていたファイルシステムのメンテナンスを行い、そしてバックアップからの差分が膨らまないうちにと、今度はbtrfs device add /dev/sdb1; btrfs device del /dev/sdd2作戦。addは一瞬で終わる。一方、delは時間がかかる。これは正しい。addは本来ファイルシステムを作るだけだし、btrfsはマークをつけておくだけだったように思う。一方、delはデータを他のデバイスにコピーしてからリファレンスを消すので、そのデバイスのデータ分時間がかかる。まだ途中だが、今のところ支障はない。

ちなみに、そもそもなんでデバイス移行しようとしているかというと、LVM用に確保してあった領域を削除し、全域をbtrfsに割り当てるためである。

btrfsの不完全さのせいで生じたトラブルだが、btrfsの冗長性、可用性に救われた形になる。どういう反応をすれば良いのやら…

PureDocの自動since入れ

ヘッダに使用し、これまで手動で書いてきたsinceプロパティだが、本来であれば「書き始めた時」でなく「はじめて生成された時」であるべきだし、それは自動で行われるべきものだ。

そこで、実際にそのような機能を追加してみた。PureDocトランスレータ本体ではなく、トランスレーションユーティリティ(puredoc-translation)が処理する。

# Process META DATA
# META DATA is start and end line beginning ##--.
# Lines between them is proceed as YAML after strip beginning "# " .
argv_first = ARGV[0]
docstr = ARGF.read # Content

begin
if docstr =~ /^##--.*$/ && $' =~ /^##--.*$/
yax = $`.each_line.map {|i| i.sub(/^# /, "") }.join
header_meta = YAML.load(yax) || Hash.new

# Set since timestamp if a document generation is first time. (And update Last update time stamp.)
if ! argv_first.empty?
File.open(argv_first, "r+") do |f|
content = f.read

# Set since Time object if since is not set.
if ! header_meta.key?("since")
since = Time.now
header_meta["since"] = since
end

content.sub!(/^##--.*?^##--.*?$/m) do
el = $&.each_line.reject {|i| i =~ /^# last-update/ }.to_a # Get header texts but except last-update.

el.insert(1, "# since : #{since.strftime '%Y-%m-%d %H:%M:%S %:z'}\n") if since # Add since if since is not exist.
el.insert(1, "# last-update : #{File.mtime(argv_first).strftime '%Y-%m-%d %H:%M:%S %:z'}\n") # Add last update timestamp
el.to_s
end or next

f.seek(0)
f.truncate(0)
f.write( content )

end

end

DOC.meta = header_meta
end
rescue
DOC.meta = {}
end

従来は単にヘッダーを読んでいたところだが、ヘッダーがある場合に限り別の処理をしている。

最初のARGVを保存しているのは、ARGFをよんでしまうとARGVが変化するため。もともとSTDOUTに吐くプログラムなので、処理するのは最初に引数として与えられたファイルに対してだけ、もしSTDINから入れた場合も触らない。

last-updateはmtimeに設定している。YAMLから作られるタイムスタンプスカラーがTimeなのかDateTimeなのか、実験してみたら、Timeだった。DateTimeにしてくれたほうがいいのに…

last-updateは更新するため、ヘッダー文字列を分解する時点で除外している。sinceプロパティが存在するかどうかについてはYAMLとして理解した上でやっているが、書き換え操作は純粋に文字列処理となっていて、別物だ。

ファイルの書き換えは、seek, truncate, writeの順が正しいらしい。まぁ、seekしてwriteしてからfile.truncate(file.pos)でも問題ないとは思うが。

ともかく、これで自動的にsinceとlast-updateが入るようになった。

画像PDFに黒塗りを入れる

ドキュメントスキャナで作成したPDFファイルのドキュメント、公開したいが一部データは個人情報であり公開できない…

そんなようなケースに私は遭遇した。まずは単純にPDFエディタを試そうとしたのだが、それはうまく動かなかった。LibreOfficeでもだ。

となれば、「一度画像にバラす」というのが無難な方法だろう。imagemagickでバラすことができる。

$ convert something-pdf-file.pdf out.png

シンプルな話だが、実際にできあがったPNGファイルをみてみるとガタガタで品質はかなりひどい。どうやらxpdf/popperを使ったほうがよさそうだ。

$ pdftoppm something-odf-file.pdf out.ppm

これでppmファイルで出来上がる。ppmファイルはgimpで編集できるので、gimpを使って編集すれば良い。pdftoppmを使って変換した場合、ImageMagickと比べるとかなり品質は良い。そして再編する。

$ convert out*.ppm out.pdf

ここではImageMagickを使う。これによる品質劣化はなさそう?だ。

ちなみに、ImageMagickを使ってppmをjpegにすることはできるが、品質オプションなしだとjpegから再編すると容量は123%程度に膨らんだ(PPM=26MB, JPG=32MB)。-quality 30まで落として再編すると、6MBまで落ちた。品質は、今回は便箋に書かれた文字であるため、このレベルなら問題ないだろう。サイズ縮小においても効果のある手法だ。-quality 15ではかなり荒れるが、それでも可読性に問題はない。このバージョンに差し替える予定でいる。ちなみに、2ページのデータはもともと2.4MBのPDFファイルだが、208kBまでの縮小に成功した。

このような場合、mogrifyを使ったほうがてっとりばやい。これはglobを使って一気に変換することを可能にする。例えばmogrify -format jpg -quality 15 *.ppmのようにだ。出力ファイル名を指定しても構わない。その場合、拡張子の前に連番が入る。