Windows10への自動アップグレードとその意図

アップグレードとその拒否

Windowsは最新のWindowsである、Windows 10のデビューが迫っている。 今回はMicrosoft社がWindows 7/8/8.1からのWindows 10への更新の無料パスを用意するなど、「Windows 10への更新」を望んでいることが伺える。

Windows 10への更新は、「用意ができ次第、順次バルーンヘルプによって通知される」。

用意ができ次第というのは、Windows 10がリリースされ次第という意味ではなく、アップグレードを許すフラグが立てられてからだ。 パッケージWindowsを利用している場合、おそらくはリリースされ次第告知される。 一方、メーカーから購入したプリインストールWindowsを使用している場合、メーカーが検証を完了し、Goサインを出した時に更新される。

この更新を確認・通知するための更新は、Windows 7がKB3065987、Windows 8/8.1はKB3065988として提供されている。この更新を適用すると、通常の更新にWindows 10へのアップグレードが含まれるようになる。 アップグレードを入手し、アップグレードを促すところまでは、半自動で行われる。

その拒否方法はAsk COREで紹介されている。

これを適用した後、その適用(つまりWindows 10になる)は手動でGoサインを出さなければ行われない。(Get Windows 10というソフトで行われる)。 しかし、これは「うっかり」やってしまう可能性は大いにあり、かつ将来的に強制される可能性もある。 現時点ではWindowsのパッケージまたはライセンス販売を優先することと、急速な移行を狙って期間限定であるとしている。ただし、MicrosoftがWindows 7/8/8.1への残留を望まない気持ちのほうが強くなれば、これを延長して強制することも考えられる。 現在は更新の強制よりもWindowsを販売することを優先しているようだ。

意図の推測

Windows 10はMicrosoftが「最後のWindows」だとしている。 事実上ローリングリリースとなり、常に最新のWindowsが保たれる。例えばWindows 7→Windows 8のような変更はそもそもなくなり、毎日少しずつ変化し、やがてWindows 8になっている、という感覚に近い。

このようにするのは、検証・サポートコストの低減のためだ。 複数の状態を維持していると、そのサポートにも検証にも、コストと時間がかかる。 特に古いものを現状に合わせるというのは非常に困難であり、もちろんコストもよりかかるため、新しいものを出すよりもずっと負担が大きい。場合によっては競争力を失う結果にもなる。 リソースが少ない場合は、最新版以外は面倒を見ない、とすればそれなりにの競争力と品質を保つことができるる

ここに近づけるためのWindows 10のローリングリリース化である。 将来的なオープンソース・ソフトウェア化に言及するなど、Microsoftがその企業規模を以ってしてもWindowsの開発、保守が破綻しそうなほどに膨らんでいることが伺える。

だが、Microsoftにはかなり迷いがあるようだ。 よりオープンで、誰もが使えるインフラにしようとしている一方で、その収益やモデルを変更することを拒否する姿勢も見える。 現在までを見る限り、その体制変更は「変化の兆し」として歓迎されてはいるものの、それ以外については全てが悪化していると見られている。

自由や公開が不十分であり、利益の確保と強権の行使が過剰である。 どの立場からも激しく批判されているのが現状だ。

実際にMicrosoftにとってWindowsは大きなビジネスだ。 Windowsの売上の割合は意外と小さく、Microsoftのクラウドシフトによりさらに小さくなっている。 だが、Windowsの販売不振が業績に響く程度には大きい。それを手放す勇気がないのだ。

さらにWindows 10はHome editionに関してはWindows Updateの調整ができなくなる。 常に強制ダウンロード、強制適用である。 この強制がシャットダウン時などユーザーを妨げることなく行われるという情報もない。現在の自動適用と同様に、作業中でも構わずダウンロードし、適用した上で突如として再起動される可能性が高い。

さらに、Windowsの開発体制の変更に伴い、「アップデートを適用すると軌道できなくなる」というトラブルの発生頻度が激増している状況下だ。 Windows 10になると、おそらくこの頻度はさらに増加すると見られる。Arch Linuxのようなローリングリリースディストリビューションで言うところの、TestingあるいはUnstable相当の体制であるため、その頻度は高止まりするだろう。

これを強制するというのは明らかに非常に問題がある。

Windows 10をライブアップグレードにしたのも問題だ。 更新が破損することは、Windowsでは「よくある」。 実際、私のThinkPad e440は、初期化してもアップデートに必ず失敗する。そのため、Windows 10が降ってきても更新できないし、そもそも降ってこない。

かなり迷走していると見られる。 そもそも、今回アップグレード/アップデートの延期機能があるのはエンタープライズユースのもののみで、一般ユースのものはそれらは「強制する」という。 これらの情報もしょっちゅう変わっているが、Windowsを安定したインフラとして使いたい層はかなり多いはずであり、動かなるリスクを冒してまで最新の機能を求める層はWindowsにおそらくそこまで多くはない。 その選択権を剥奪するのが妥当なことだとはとても思えない。

WindowsはパソコンOSのデファクトスタンダードとしての自覚と責任を求めたい。 面白く革新的であることが求められるのは挑戦者であり、基盤であり標準となるものであれば、常に安定して使えるものであるべきだ。 一部のユーザー、特定の使われ方のみに適合するOSは標準としてふさわしくない。 また、行政などがMicrosoft製品を強要する社会的状況も早急に改善してほしいと思う。

適切な対応は

Windows 10のカーネル上の変更点は大きく、周辺機器が動かなくなる可能性はかなり高い。 出たばかりのホットなデバイスであればおそらく近い将来Windows 10に対応するだろうが、旧型デバイスだと期待薄だ。 私が使用しているスキャナー、プリンターもおそらくはダメだろう。

さらにソフトウェアが動かない可能性も高い。 私の場合、仕事で使っているソフトウェアがアップグレードするのも結構しんどい、SONAR PRODUCER, KOMPLETE ULTIMATEがある。 完全に動かなければ、アップグレードには10万円程度は必要になる。 FL STUDIO SISGNATURE BANDLEはライフタイムアップグレードに救われるが、ドラゴンスピーチの対応も疑問。

このあたりを考えると、デスクトップは更新しないことになるだろう。 特に新しいソフトウェアを導入する予定もないため、Windows 7のサポート切れ(2020年1月14日)まではかなりあることから、そのまま維持することになる。 新しいソフトウェアが動作しないようであれば、システム全体のアップグレードを検討する。 音楽関連ソフトウェアは集中させるしかないため、Windowsの更新を行うのであれば、全体を上げるしかない。 その際に対応できないソフトウェアは切り捨てられることとなる。既にWindows 7でXG Worksは動かなくなっている。

比較的無難な対応としては、Windows 7/8/8.1でアップグレード前にディスククローニングしておき、Windows 10にアップグレードしてさらにディスククローニングする、という方法だろう。

グレード間の巻き戻しをライセンス的にMicrosoftが許容するのかがわからないが、これであればWindows 10で動作しなければWindows 7/8/8.1のクローンを用いて巻き戻し、Windows 10移行に適切な時期が来た時にはクローンを用いてWindows 10を書き戻すことで、無償期間後にもアップグレードすることができる。

Microsoftが煽るほどにはWindows 10へのアップグレードは勧められない。 プレビューでもかなりの不具合が報告されている。趣味ユーザーであれば試してみるのもいいかもしれないが。

もう少し言うのであれば、Windows 8/8.1ユーザーは無条件にアップグレードしても良い、という意見も見る。 一方、Windows 7ユーザーはアップグレードは控えたほうが良い、ということだ。

なお、サポートが終了しているWindows XPと、延長サポート終了が近いWindows Vistaは無償アップグレードから外されている。 Windows 10はWindows Vistaが余裕をもって動くコンピュータであれば性能的には動作する可能性が高いが、これはMicrosoftの経営上の判断だろう。

Windows 10 previewからもWindows 10にアップグレードすることができるが、これにはWindows 7/8/8.1のライセンスでアップグレード認証したものだけであり、Windows XP/Vista、非正規Windows、Windowsなしコンピュータからのアップグレードはできない。

Manjaro Linux 0.8.13 setup (4)

インストールパッケージ

  • tegaki-models-zinnia-japanese
  • tegaki-recognize
  • tegaki-models-wagomu-japanese
  • tegaki-tools
  • tegaki-train
  • libsidplayfp
  • vice
  • man-pages-ja
  • ngrep
  • qlivestreamer-git
  • python-librtmp
  • nkf

tegaki系パッケージは、Mozcの手書き機能のため。 ただし、 ウィンドウを黒にしているためか、書いたところがまったく見えない。

man-pages-jaは日本語manpageのためのパッケージ。

ngrepはHTTP解析のために入れた。

qlivestreamerについてはあまり語らない。 Ustream関連で最も良い選択肢だと思われた。MPlayerの--dump-streamという方法もあるが、素直にCLIで。

なお、python-librtmpがないとモバイル用しか視聴できない模様。

nkfは入れ忘れ。 MailDeliver2が要求しなくなったので気づかなかった。

nkfをいれたのはberryjackのため。結構単純だが、Linuxで確実に機能するTwitterの画像に関するツールだ。 高速で、非常に良い。

Btrfsの破損

システムが急にフリーズをくりかえし、ガクガクしはじめたので再起動したところ、 ユーザーデータ用のファイルシステム(btrfs)がマウントできなくなった。

また、起動時がなぜかPlymothに以降するまでが遅い。

考えられる可能性としては

  • システムディスク
  • システムファイルシステム
  • データディスク(btrfsを構成する4台のいずれか)
  • dm-cryptデバイス
  • btrfs

のいずれか。

問題を切り分ける必要があったため、まずは確実に再現することを確認し、データディスクを切り離し、単一ディスクで起動した。 結果、正常に起動した。

なお、こうした理由も含めて、データディスクはsystemdユニットではマウントしていない。

その上で、LiveDVDでブートし、dm-crypt plainによる復号化とデバイスへのアクセスが可能であることを確認。 また、ファイルシステムに対する操作を行おうとするとフリーズすることも確認した。 なお、フリーズするとデバイスビジーになるため終了もできない。

通常のシステムを起動して、復号化までで留め、

btrfsck /dev/mapper/CRYPTDEVICE1

ずらずらーっとエラーが出る。updateどうちゃらとか。 だが、最終的にはエラーは0とリポートされる。

続いて

btrfsck --repair /dev/mapper/CRYPTDEVICE1

しかし、エラーが発見されなかった以上修正もされない。 だが、先ほどずらずらっと出たエラーは出なくなり、また正常に動作するようにもなった。 scrubしても0errorsだった。

btrfsは障害が発生した時に、障害が発生したことを通知できるようにできないものだろうか。 フリーズしたり機能しないなど、調査が大変だ。

先日のエントリでのメール処理

割と単純

メールアドレスのマスク

for i in tmp/ab-0*
do
sed -e -i 's/\w[a-zA-Z0-9_-]*@/*@/g' "$i"
done

PGPシグネチャの除去(メールアドレス対策)

for i in tmp/ab-0*
do
sed -e '/-----BEGIN PGP SIGNA/,/-----END/d' "$i"
done

Markdownのcodeblock化

for i in tmp/ab-0*
do
sed -i -e 's/.*/\t&/' "$i"
done

ちなみに、SylphhedはPGP-Inlineをメールに対して選択できないので

gpg --clearsign --local-user ADDRESS

して署名。

SpamAssassin

umask000で実行するようにしないとダメらしい。

ディレクトリやファイルはrootで作るが、アクセスは一般ユーザーで行うため。

Mikutterの効果音

ALSAであれPulseAudioであれ、内部ではaplayを使っているため、 使用するファイルはPCM(.wav)でなければ盛大なノイズになる。

第一カラムの数字を数値として合計する

簡易帳簿の計算のために用いた

puts ARGF.each.inject(0) {|sum, x| sum + (x.split(/\s+/).first.to_i) }

ffmpegで切り出し

例えば

ffmpeg -ss 420 -i source.mov -vcodec libx264 -t 360 -strict -2 -crf 32 dest.mp4

のように行う。

-ssオプションで開始秒数、-tオプションで切り出す長さの秒数を指定する。 -iオプションよりも手前に-ssを置くことで所要時間を大幅に短縮できるが、正しく切り出せない場合がある。しかし、copyではなく、明示して再エンコードすることで解決するという。

Xがおかしい

Manjaro Stable 2015-07-14を適用したところ、ログイン時にXFceが起動するようになった。 しかもそれだけではなく、「XFceが起動し、ログアウトすると選択したデスクトップ環境が起動する」というわけのわからない状態になった。

lightdmやX関連スクリプトを見たのだが、原因になるようなものは見当たらない。

結局、どうもユーザーコンフィグ関連がおかしくなっていたようで、

rm ~/.x* ~/.X*

で直った。

PureBuilder2

PureBuilder2とは

PureBuilder2は現行のPureBuilderを置き換える新しいサイトビルドツールだ。 コマンド一発でウェブサイトの更新が可能になる。「動的生成の事前作業化」が可能となる。

PureBuilderからの主な変更点は次の通り

  • Rubyでの実装 (Windowsで動作可能に)
  • MarkdownとeRuby対応

変更点は少ないようにみえるが、PrueBuilderとは互換性はないし、コードも新規に起こす。

Markdownへの対応

Markdownへの対応はKramdownライブラリを使用した。 非常に使いやすく、問題はないように見えた。 何を何に出力するかは、指定クラスの入れ替えによるポリモーフィズムによる。

このラッパークラスはごく簡単だと思ったのだが、そうはいかなかった。

現状、PureDocはライブラリであり、ドキュメントがRubyコードである。 これを出力するためのユーティリティはZshスクリプトになっている。

PureBuilderはその多くをPureDocに依存している。 PureBuilderが直接に依存していなくても、テンプレート側はPureDocオブジェクトを触れることになっているし、現状テンプレートを呼ぶところまでがPureBuilderの仕事なので、当然テンプレートではドキュメントを出力するために、PureDocオブジェクトを必要とする。

だが、当然ながらKramdownオブジェクトはPureDocオブジェクトと互換性がない。 機能を維持するためには、単にKramdownを呼び出すラッパーではなく、Kramdownを内部で使うPureDoc互換クラスが必要となる。

予定とは比べ物にならないほど大変な作業だ。

PureDocのインターフェイス

加えて、今のところPureDoc Translatorが保持している機能については、PureBuilderから使用することができなくなる。 旧来のPureBuilderは、コマンドとしてPureDoc Translatorを呼んでいたため問題がなかったが、ライブラリとして使うとTranslatorは使えない。

PureDocにその機能があるにはかかわらずPureDocに組み込まれていないのは、PureDocの仕様によるものだ。

PureDocの

##-----
...
##-----

という形式でYAMLをヘッダーとして埋め込めるという仕様は、PureDocにはないが、便宜上の拡張としてTraslatorにあり、PureBuilderはそれを前提として使用する。

これをPureDocに組み込むのであれば、PureDocクラスにその機能をいれてしまえば良い。 要はこの仕様をPureDocに取り込むか、PureBuilderに取り込むかの話なのだが、おそらくはPureDocに取り込むのが妥当なところ。

一方同じようにこのヘッダを取り扱いながら、ヘッダにLast UpdateとSinceを書き込む機能があったりするが、これはあきらかにPureDocではなくPureBuilderに実装されるべき機能だ。

一応、いまのところ次の方針を考えている。

  • meta取り込みはPureDoc#read_meta(text)で行う。このヘッダはコメントになっているので、テキストを与える必要がある。これはPureDocライブラリが勝手に実行することはない
  • PureBuilderはpuredoc.metaによりsincelast-updateを確認し、ない場合は追記する

PureBuilder2のおおまかなモデル

purebuilder本体はRubyライブラリとなり、基本的には各ディレクトリの.rebuild_rulesまたは.up*ファイルが処理手順となる。

これらをまとめて呼ぶためのスクリプトが、purebuilder.rebuildallになる。

対象ファイルに対して

PureBuilder.build(file, outputdir, extname)

とすることでビルドできる形だ。

インタープリタ起動役は

rebuildallでrebuildスクリプトのインタープリタは拡張子によって判断するが、拡張子がない場合はperlを使う。

これは、perlはshebang行を解釈するためだ。この機能はsh/bash/zsh/rubyにないことを確認している。 Perlは「Shebangを解釈できないダメなシェルに代わって」起動するそうだが、どうやらLinuxが解釈するだけで、シェルに解釈を期待するのは厳しそうだ。

携帯電話キャリアの通信改竄問題(通信の最適化)

はじめに

高木浩光さんがauに問い合わせのがTogetterに上がっている

前編, 後編

これは極めて問題だ。 もちろん、対応者の著しい無知も問題だが、これは一般の人にはまず伝わらない。

ここは問題について絞り込んで説明しよう。

通信の秘匿の侵害

通信の秘密は憲法で保障されている権利だ。

通信はプライバシー権として保護され、それを侵すことはできない。 私人間効力についての議論はあるが、この対象になることについては電気事業法によって定められている。

さて、この厳しさをひとつ見てみよう。

  • 2006年5月にぷららがWinnyを遮断したことを、総務省は「違法」と判断している
  • OP25Bについて「通信の秘密を侵害するもの」と判断している

これらは、「封筒を見ている」という話だ。 通信を届けるために、見ないでいることができない情報を見て、通常の届ける以外の行為を行っていることを問題としている。

だが、ここでの問題はそうではない。 手紙でも、中に写真が入っているか、どのような写真であるかは、封筒の「中」を見なければわからない。

通信でも同様で、エンベロープ(封筒)情報にはデータが画像であるかどうかという情報はない。 それを解いて中にくるまれている本文を読まなければいけない。

たんに解くだけではない。 「含まれるかどうか」については読んでいかなければいけない。 それが人間でなく機械がしているにせよ、それを判定するためには本文も読まなくてはいけない。

auが「メールの添付ファイルも圧縮する」というのなら、それはauは全てのau経由のやりとりのメールをチェック読んでいるということを意味する。 これは、ezwebのメールでなくても、とにかくauのスマホでメールをうけとるか、送るかした全てのメールにおいてだ。

これがもし、TLSを用いたものも対象にしているのだとすれば、それは「暗号化されたものを解読して覗いている」ということになる。 これはさらに別の法律にもひっかかる。

そして、覗いただけでは済まない。 これを改変してしまうのだ。 物理的な手紙でいえば、

封筒を開封して本文を読んだ後、同封されている写真を「これじゃ大きくて飾れないね」といってハサミで切り取ってまた入れて封をして届ける

ということをしているわけだ。 そもそも改変するためには、読まなくては処理できない。 元のデータを見ることなく、そのデータを元に何かの結果を計算することはできない。 X + 10 の結果を実数で出すためには、Xの値が何であるかを知る必要がある、ということだ。

これを気持ち悪いと思わないか? 人間でなく機械だから許される、というものではない。 それだったら、あらゆる通信を盗聴して保存し、検索することなど当たり前にできてしまう。 もちろん、それで「こいつは犯罪性がある」「この思想は悪だ」などとマークしておく、などというか、かつてのドイツのような状況まであと半歩の状態だ。

極めて危険だ。

しかも、近年は権力側で堂々これを踏みにじることを「アリにしよう」といっている。 警察の盗聴などだが、「状況・期間・対象を限定し、裁判所の許可を必要とするから問題ない」などと言っているが、 既に日常的かつ恒常的に盗聴を行っていて、かつそれが明るみに出ても問題だとも思わない、という状況が存在し、その上で公権力はOKということにしてしまったら、憲法が形骸化するのは目に見えている。

改竄自体の問題

改竄自体の問題もある。

例えば、私が地図を送ったとしよう。

地図は大きな画像だ。スマホでは表示しきれない。 だが、縮小して送ることはしない。なぜなら、地名が書かれているからだ。

もし、4倍のピクセルを持つ画像であれば、4倍まで拡大した時に表示されている領域の情報は4倍になる。 しかしドットバイドットの状態、つまり800×600の画像を800×600で表示している状態であれば、4倍に拡大しても情報は増えない。字が見えるようにはならないのだ。

つまり情報の欠落である。

さらにいえば、それがプログラムの一部を構成していたら? あるいは、データをチェックサムで検証していたら? いずれにせよ同一性を要求する場合においては問題は必ず生じることになる。

しかも、これは一方的に行われるものだ。

例えば、ある写真家が、

「自分の写真は完全な状態でのみ公開する。これを他の形式に変換したりピクセルサイズを変更するなどの加工を禁じる」

というみずからのポリシーに基づいた著作権(著作人格権)の行使を行っているとしよう。 その写真家はたとえばauのユーザーではない。auとは関係のない人物だ。 しかし、auユーザーがその写真を見た時には加工されてしまう。 この場合、著作者とauの間になんら契約はなく、auは著作権を侵害する。

ちなみに、画像非可逆圧縮については、同一性保持権に関しても侵害している可能性がある。

実際にそれにより起きた不具合と、それによる対応もTogetterにまとめられている

なぜやるのか

目に見えないのでわかりにくいが、帯域というのは携帯キャリアにとっては「商品」である。

使用量が増えればQoS(サービス品質)が低下するため、利用者離れにつながる。かといって、容量を拡大するのはコストがかかる。

そこで、通信料を減らそう、というのが最近の発想らしい。

これは言ってみれば、水道で、水道管の太さ、水の最大供給量は変えないが、「各家庭の蛇口を勝手に細くして水をたくさん使えないようにしよう」というようなもの。

もっとも、これは質的な問題でもあるから、「ちゃんと浄化するのはお金がかかるから、塩素大量にぶち込むだけにしよう」というようなことでもある。 それをまともに告知せずに行う、ということだ。せいぜい、契約書に「浄水方法はこっちに任せてね」と書いてある程度。

発想や思考形成としては食品偽装に非常に類似している。 なんらかの対応が必要なのは仮に認めるとしても、地位的有利を利用した傲慢な手法である上に、それを隠してできれば騙していたいという考え方に非常に問題がある。

COWON M2のプレイリスト(m3u)

実際にやってみてわかったポイント

  • ルートディレクトリはmicroSDの中のプレイリストならmicroSDのルート
  • ディレクトリセパレータは/でなく\を使う必要がある。
  • 文字エンコーディングはShift-JISを要求
  • 改行コードはCRLFでなければならない

不要な条件が含まれているかもしれないが

  • M2をマウント
  • microSDルートで端末を開く(nemoが開かれるので、そこからGnome Terminalを開いている)
  • そこからSMPlayerを起動
  • プレイリストを作ってプレイリスト保存。m3uファイルが生成される
  • 相対パスになっているので、絶対パス変換、ディレクトリセパレータの変更、改行コードと文字エンコーディングの変更を行う

というわけで、そのコードは

sed -e 's/\//\\/g' -e 's/^[A-Za-z]/\\&/' BASEPLAYLIST.m3u | nkf --windows --sjis > PLAYLIST.m3u

ということだ。 ただ、プレイリストが増えるとフォルダが正常に表示されなくなる、という問題が報告されている。 1つだけ作ってみた限り影響はなかったが、一応、注意する必要がありそう。

実際のm3uファイルはこの通り

#EXTM3U
# Playlist created by SMPlayer 14.9.0 (svn r0UNKNOWN) 
#EXTINF:372.33,01-Moon Over The Castle.ogg
\CD\Sony Computer Entertainment\Gran Turismo 2 - Original Game Soundtrack\01-Moon Over The Castle.ogg
#EXTINF:284.81,01-RONDO.ogg
\CD\T-SQUARE\33\01-RONDO.ogg
#EXTINF:354.96,03-Golf.ogg
\CD\Cube-Ray\The Shadow of Eruption\03-Golf.ogg
#EXTINF:264.75,10-futuristic imagination -album version-.ogg
\CD\School Food Punishment\amp-reflection\10-futuristic imagination -album version-.ogg
#EXTINF:293.63,01-TRIP.ogg
\CD\愛内里菜\TRIP\01-TRIP.ogg	

実際にはEXTINFの詳細な値は必要ないらしい。

24本骨和傘 蛇の目

横浜駅西口で行われていた物産展で購入した蛇の目風の傘。 恐らくは「しのびや」で売っているものと同一のもの。

これが、とてもよかった。

まず、柄は木でできている。 結構高級な傘でも柄がまっすぐなものは見たことがないし、これもちょっと曲がっている。 また、ちょっとバリがある。

ジャンプ傘ではないが、金具を押す部分はラバーでカバーされている。 そのため、痛くない。かじかんだ手でも問題無いだろう。

グリップは内側はフラットになっている。 これは、さすときには掌に当てると痛くない。しかも、持ち運ぶ時は指の腹を当てると持ちやすい。 ちょっとしたことだが、とても便利だ。

非常にしっかりとした傘だが、回すと随分ぐらつく。どうやらやや大きめに回転するようになっているようだ。 ただし、バネ効果があり、センターに戻ろうとする。軽くひねるだけで反対に振れる。 つまり、小さくひねるだけで傘は大きく反転回転運動をすることになる。 要はしずく落としを簡単にさせてくれるわけだ。 なお、この時傘は開くようになっている。閉じたまま振りたい場合は注意。

ちょっとした工夫と、ちょっとした手間だが、非常に丁寧なつくりで使いやすい。 強風に耐える設計ではないが、それでも24本骨でしっかりしている。

とても良いものだった。

Manjaro Linux 0.8.13 setup (3)

"インストール作業"

  • libaacplus
  • evince
  • gedit
  • gedit-plugins
  • gedit-core-assistance
  • ggjs
  • libgit2-glib
  • flashplayer-standalone
  • cnijfilter-mp620
  • xfce4-goodies
  • purple-line
  • wireshark
  • dconf-editor
  • expect
  • firefox-aurora
  • gstreamer-vaapi
  • libvdpau-va-gl

ビデオ関連と、あとはこれまで使っていて欠如しているものを足した。

firefox-auroraはFlashのOut Of Dateに対応したもの。xfce4-goodiesは中途半端に入っていた。

expectはmkpasswdコマンドのためにある。

ビデオプレイヤーの設定

ビデオのパフォーマンスが非常に悪い。 しかも、えらいCPU大食いなので、調べてみたら、ビデオ再生は無条件にGPUを使う、わけではないようだ。

なお、ビデオカードはAMD A10-7700Kで、AMD Radeon R7ということになる。

VLC

環境設定→入力/コーデック→ハードウェアアクセラレーションによるデコード

がある。だが、VDPAUでもDRM経由のVA-APIでも「開けない」と言われてしまう。なぜかnvidiaドライバーを開こうとしたりしている。

X11のVA-APIならば、ただしくAMD用ドライバーで再生するが、フリーズしたり、盛大なブロックノイズなどが頻発する。

Smplayer

VLCよりも快適な再生ができているSMPlayerは、

環境設定→ビデオ→出力ドライバー

で設定できる。色々あるが、とりあえずgl (高速 - ATI カード)を選択することで改善された。

また、「パフォーマンス」の項目にDecodingがあり、Hardware decodingを選択(vaapiにした)することでハードウェアアクセラレーションが利用可能なようだ。

fetchmailが止まる

fetchmailが受信中に停止。 SIGINTで中断して再開するも止まってしまう。

試してみると、特定サーバーで止まる。 そのサーバーより前に記述されているサーバーは正常に処理される。

どうやら、特定メッセージの受信で止まってしまうらしい。 調べたが、あまり有用な情報はなかった。 IMAPでそのメールを除去すると正常に動作するようになった。

この問題は2回目。