ThinkPad e440 * Manjaro Linux KDE, Fcitx Mozc Neologd UT, Padre

ThinkPad e440にManjaro Linux KDE 15.12 (x86_64)をインストール

これまでPCLinuxOSで運用してきたThinkPad e440だが、どうしても不安定(KWinがフリーズして再起動することが多い、バッテリーモニターが機能しない、など)なのが気になってManjaro Linuxにしてみた。

私のThinkPad e440はCeleron 2950Mに4GB RAMの貧弱仕様、ピクセル数もWXGAにすぎない。RAMに関しては8GBに拡張してある。これによってようやくまともに動くようになった(その前は遅くて仕方がなかった)。ハードディスクも拡張済みだ。

このRAM拡張のおかげで、以前はまともに動かなかったKDE Plasma Workspaceが動くのだが、それでもかなり重い。それでもKDEが好きなのと、特にシステムを細かく設定し、好みのアプリケーションを使い分けてデータを扱いやすいように保存する…という意図がなければ、ひと揃い便利なものがあるKDEは非常に重宝するのだ。

最新のLXQtもあったが、今回もKDE。これでうちは4台がManjaroに。とうとう残るManjaroじゃないやつはIPFire, linuxbeanだけになってしまった。

e440はWindows 7が入っており(Windows 10にしたものの、結局Sonarがちゃんと動かないので戻してある)、デュアルブートなのがここまでのハードルになっている。

Manjaro Linux KDE 15.12時点ではインストーラは、Thusについては手動パーティショニングについてLUKSは使えるが、LVMは扱えない。また、GrubはMBRのみ。CalamareはLVM及びPBRをサポートするが、LUKSをサポートしない。

今回はLUKS優先でThusでインストールした。レガシーブートなので(Windows 7モデルを選択するとレガシーブートで、Windows 8モデルを選択するとUEFIで来る)問題が起きにくいというのはある。

Wi-Fiの問題

e440に入っているWi-FiモジュールはLinuxでうまく駆動しない。ある程度通信すると止まるのだ。

Manjaroだとほぼ直ちに止まる。PCLinuxOSだと通信量が少なければなかなか見立たない。openSUSEではストールしたのを見たことがない。

これがPCLinuxOSを選択する大きな理由だったのだが、結局止まるのであれば、あまり意味がなかった。

これを受けて、Wi-Fiはドングルを使うと割り切ってManjaroを導入することにした。

とはいえもしかしたらなんらかの改善方法があるのかもしれない。

以前にはブログでもその問題をみかけることができるが、バージョンが限定されている。
Ubuntuでfixが入っただけかもしれないので、特定のカーネルの問題ではないのかもしれない。

また、Dedoimedoでもこの問題について言及されている。こちらでは/etc/modprobe.d/rtl8723be.confとして

options rtl8723be fwlps=N ips=N

を記載することを勧めている。

これを受けて試してみたのが、まずkernel headerをインストールした上で、AURからrtl8723bs-dkms-gitをインストール。

そしてdkmsを有効にする

# systemctl enable dkms

そしてインストール

# dkms install rtl8723bs/2

これで再起動したところ、3.7GBのファイルのダウンロードに成功した。

ただし、時々不安定になるので、切断・再接続をする必要がある時もあるかもしれない。それでも十分実用になる。yaourt

Plasma5

sniproxy不要になったPlasma5だが、いくつかのアプリケーション(Mono関連, Cloud.ru, Skype, Wineなど)が結局systrayに入らない。
必要であればtrayerを併用するべき。

非常にアピアランスは良いし(Plasma 4のリッチUIも良いと思うのだけれども、フラットUIになったのに見やすく、美しくなった。元々タブレットやネットブックに向けて作られたフラットUIは、あまり画面解像度もないラップトップには適しているということだろう。非常に見やすい。

全体に優れている。完璧ではないけれども優れている。
ManjaroをXFceからインストールするとKMailが動かなかったり、Akonadiでエラーが出たりするが、そうした問題はさすがに改善されている。

Kate, Kwriteは、通常のXFceから入れるものとはちょっと違う。違うのだが、PCLinuxOSではRubyの特異クラスをちゃんと理解したように思うのだが、こちらはダメだ。残念。

Manjaro Setting Managerが含まれないため困惑するが、こちらはkcmに統合されている。

バッテリーモニターは適切に動作する。パワーマネジメントもPlasma 5.3で無事追加されている。

パワーマネジメントでバッテリー駆動時の設定を行うためにはバッテリーを取り付けておかなくてはならない。

e440においてのみ発生する現象だが、Super+Shift+→が動作しない。
quicktileにその設定が使えないのが少々痛い。この問題はThinkPad e440上のKDEで常に発生する。

動作速度は良いが起動・終了は非常に遅い。安定性はPCLinuxOSのKDE4よりも安定している。
アイコンの通知表示が優れている。ただし、systrayに関しては自然に階層化されるCinnamonのほうが優れている。

クイックランチ的に置かれているアイコンはパネル上のウィジットである。Firefoxが邪魔なのだが、これを削除するにはパネル編集モードから削除する。

ウィジットはまだ少なめだ。リサイズ方法は、余白部分を左ボタンダウンを続けてメニューを表示する、というあまり直感的ではない方式。タッチインターフェイスを意識したのか。しかしそれは右クリック相当じゃないのか。

Kde Applications

KDEには膨大な、様々な、そして有用なアプリケーションがあることがおおきなアドバンテージだが、Manjaro KDEはその収録量が少ない。Konquerorすら入っていない。

(とはいえ、近年はKonquerorは入れない傾向があるため、それほどめずらしくはないのだけれど)

kde-applicationsグループにまとめられているので、

$ yaourt -S kde-applications

でしっかりと入る。

テーマ

ManjaroにはMaiaテーマが採用されている。

緑を用いたなかなかに美しいテーマで、Manjaro色が良いと思うかどうかという問題はあるが、ひと揃いあって統一感は良い。breezeよりも良いので、統一感をもたせにくい他のテーマを採用するのが難しい。

Maiaアイコンテーマの再起動、シャットダウンなどのアイコンは非常に好きで、アイコン自体は個人的にはcompassのほうが好きなのだが、結局Maiaのまま。壁紙もMaiaなのでフルMaia。

ちょっとこれはなんとかしたい。ウィンドウデコ
レーションはMaiaではなくbreezeなのだが、これは変更した。また、壁紙も変更した。

Plymouthはなぜか他と同じmanjaro-extra-elegantではなく、manjaro-elegantが採用されている。私はmanjaro-redefined-bsplashを採用した。

アクティビティ

使い方に困る人の多いアクティビティで、私もご多分に漏れずではあるが、e440においては追加したアクティビティがひとつある。

これはプレゼンテーション用で、パワーマネジメントをACと同じにしてある。
なお、ACではDim screenやスクリーンのオフなどは切ってあり、ブライトネス設定がない。

Fcitx Mozc Neologd UT

つい先日libkkcの話をしたばかりではあるが、やはり入力効率はMozcのほうが良い。しかし、MozcではATOKに及ばないのは当然としても、WindowsのGoogle日本語入力との差が激しい。

PCLinuxOSにおいてTomcatさんの仕事で非常に大きなアドバンテージとなっていたNeologd UTがAURにも来ていたる

これは、UTUMIさんがUTに代えた新たな仕事として作ったもののようだ。UTの35万語から85万語に大幅増となっている(半数は地名とのことだが)ので入力効率が大幅に向上しているのだ。
確かに出てくる文字が違う。UTだとAndroidのGoogle日本語入力と非常に似た変換候補という印象なのだが、こちらは違う。

ニコニコ大百科が使えなくなるので一部変換できなくなる言葉も出てくるだろう。もしかしたらニコ厨諸兄にあってはMozc UTでnicodicを有効にしたほうがいいのかもしない。

あとは、mecab-ipadic-NEologdがどれだけのものに今後なっていくか次第か。

とりあえず使ってみた感触では従来のMozc-UTよりも良いと思う。
ただし、サイズ自体もかなり大きいので、ディスク消費量が問題になる場合には不適。また非常にメモリ消費に対して厳しい場合も同様。

その意味ではuim-anthyが使えるPCLinuxOSは有利。Whizもいいのかもしれない。
とにかくパワフルで効率的な変換をしたい人にとっては、Linuxでは現状の最有力。Wimeを使うという手段もあるのかもしれないが。

Padre

AURのPadreがPerl::Devel::DumpvcarとPerl::POD::Abstractがビルドにこけるためインストールできない。prove -lrprove -rにビルドを通すため変更したとあるが、prove -lrに戻さないと通らないので注意。

さらに、perl-wx-scintillaに関しては、OUT OF DATEが立っていてビルドできない。
そのため、perl-padreのPKGBUILDを編集してperl-wx-scintilla-devに変更することはできるが、いずれにせよこれが原因でビルドできない。

なお、cpanでインストールしようとするとシステムがフリーズする。要注意。

fcitx-libkkcでかな入力

できるらしいとは分かっていたものの(libkkcの仮名入力に問題があったことを知っていたからだ)やり方がわからなかった。

ちゃんと調べてみたところ、(少なくともArchの場合は)/usr/share/libkkc/rules以下にサンプルがあり、かな入力は/usr/share/libkkc/rules/kanaなので、これで~/.config/fcitx/kkc/rules/defaultを置き換えれば良い。

使ってみてまず感じたのが、Shiftキーがひっかかっていると
英字が入力されてしまい、しかも確定されてしまうということだ。

これでは使い辛いので、マップを修正してみた。よさげならリポジトリにプルリクしてみるつもりだ。

ただ、libkkc変換精度も語彙も物足りない。Linuxディストリビューションによっては標準で入っている日本語入力(MozcだったりAnthyだったり)の語彙があまりにもひどくて、kkcはまとも、という場合もあるだろうが、Manjaro(Arch)であればMozc-UTがあるため、libkkcで効率が向上する、ということは残念ながらない。

ffmpegでスクリーンキャスト&ウェブカメラ撮影

ほぼArch wikiの通りではあるけれども

スクリーンキャスト

スクリーンキャストはPCの画面を録画する。

recordMyDesktopやIstanbulを使うことが多いかもしれないが、処理が遅くて録画した後が大変だし、音声に自由度がない。

とりあえずFullHDでキャストしてみた。

$ ffmpeg -f x11grab -video_size 1920x1080 -i $DISPLAY -f alsa -i pulse -acodec aac -vcodec libx264 -preset ultrafast -qp 0 tmp/test.mp4

これで左上から1920x1080の領域が録画される。音声はpulse経由であり、マイク保存することもできるし、モニターを保存することもできるし、特定のアプリケーション出力を保存することもできる。

特に音声を記録しないなら

$ ffmpeg -f x11grab -video_size 1920x1080 -i $DISPLAY -acodec aac -vcodec libx264 -preset ultrafast -qp 0 tmp/test.mp4

ALSAでやりたいなら

$ ffmpeg -f x11grab -video_size 1920x1080 -i $DISPLAY -f alsa -i default -acodec aac -vcodec libx264 -preset ultrafast -qp 0 tmp/test.mp4

特定のウィンドウを記録するにはxwininfoを使えばいける。

Gist

使い方としては、-w(ウィンドウモード)、-m(マイク有効)オプションを受け付ける。

ウェブカム録画

$ ffmpeg -f alsa -i pulse -f v4l2 -s 1280x720 -i /dev/video0 -acodec flac -vcodec libx264 -preset ultrafast tmp/test.mkv

意外ときつい。解像度を落とせばいける。

ただし、guvcviewなどで録画するよりはずっと快適。

PulseAudio応用

マイクから録る

単純にpavucontrolから録音しているアプリケーションのマイクデバイスを選択すれば良い

モニターを録る

入力装置をAll Expect Mintorsではなく、All Input Devicesにすればモニターも見える。
あとは録音しているアプリケーションでモニターを選択すれば良い

特定のアプリケーションだけ録る

$ pacmd load-module module-null-sink sink_name=MySink
$ pacmd update-sink-proplist MySink device.description=MySink

といった感じでSinkを作成、これがスピーカーとして入るのでアプリケーションの出力先にする。
これだけでは追加されるのはモニターだけでマイクロフォンはないが、Monitor of Null 出力を選択すればそのアプリケーションだけ取れる。

もちろん複数のアプリケーションをまとめて録音することも可能。

エンコード

ultrafastで録画したデータは非常に大きいので、圧縮する。

圧縮がしやすいように用意した~/.zshrc.d/40-zaliasesは以下の通り

## Video Conversion ##

videocomps() {
  #WebM? H.264? H.265?
  case $1 in
  264)
    case $2 in
    best)
      ffmpeg -i "$3" -vcodec libx264 -preset veryslow -crf 18 -strict -2 _comped_"${3:r}".mp4
      ;;
    goodslow)
      ffmpeg -i "$3" -vcodec libx264 -preset slow -crf 18 -strict -2 _comped_"${3:r}".mp4
      ;;
    good)
      ffmpeg -i "$3" -vcodec libx264 -crf 18 -strict -2 _comped_"${3:r}".mp4
      ;;
    normal)
      ffmpeg -i "$3" -vcodec libx264 -crf 23 -strict -2 _comped_"${3:r}".mp4
      ;;
    light)
      ffmpeg -i "$3" -vcodec libx264 -crf 28 -strict -2 _comped_"${3:r}".mp4
      ;;
    mobile)
      ffmpeg -i "$3" -vcodec libx264 -crf 36 -strict -2 _comped_"${3:r}".mp4
      ;;
    esac
    ;;
  265)
    case $2 in
    best)
      ffmpeg -i "$3" -vcodec libx265 -preset veryslow -x265-params crf=18 -strict -2 _comped_"${3:r}".mp4
      ;;
    verygoodslow)
      ffmpeg -i "$3" -vcodec libx265 -preset slow -x265-params crf=18 -strict -2 _comped_"${3:r}".mp4
      ;;
    verygood)
      ffmpeg -i "$3" -vcodec libx265 -x265-params crf=18 -strict -2 _comped_"${3:r}".mp4
      ;;
    good)
      ffmpeg -i "$3" -vcodec libx265 -x265-params crf=23 -strict -2 _comped_"${3:r}".mp4
      ;;
    normal)
      ffmpeg -i "$3" -vcodec libx265 -x265-params crf=28 -strict -2 _comped_"${3:r}".mp4
      ;;
    light)
      ffmpeg -i "$3" -vcodec libx265 -x265-params crf=32 -strict -2 _comped_"${3:r}".mp4
      ;;
    mobile)
      ffmpeg -i "$3" -vcodec libx265 -x265-params crf=38 -strict -2 _comped_"${3:r}".mp4
      ;;
    esac
    ;;
  webm)
    case $2 in
    best)
      ffmpeg -i "$3" -c:v libvpx-vp9 -b:v 0 -threads 8 -crf 10 -c:a libopus -f webm _comped_"${3:r}".webm
      ;;
    verygood)
      ffmpeg -i "$3" -c:v libvpx-vp9 -b:v 0 -threads 8 -crf 18 -c:a libopus -f webm _comped_"${3:r}".webm
      ;;
    good)
      ffmpeg -i "$3" -c:v libvpx-vp9 -b:v 0 -threads 8 -crf 23 -c:a libopus -f webm _comped_"${3:r}".webm
      ;;
    normal)
      ffmpeg -i "$3" -c:v libvpx-vp9 -b:v 0 -threads 8 -crf 28 -c:a libopus -f webm _comped_"${3:r}".webm
      ;;
    light)
      ffmpeg -i "$3" -c:v libvpx-vp9 -b:v 0 -threads 8 -crf 33 -c:a libopus -f webm _comped_"${3:r}".webm
      ;;
    mobile)
      ffmpeg -i "$3" -c:v libvpx-vp9 -b:v 0 -threads 8 -crf 48 -c:a libopus -f webm _comped_"${3:r}".webm
      ;;
    esac
    ;;
  esac
}

CRF値はH.264以外はちゃんとデータを出していない。
参考までにVP9 CRF33でエンコードするとこんな感じだった。

$ ls -lh
合計 50M
-rw------- 1 aki users 3.1M  3月 14 16:50 _comped_purebuilder.webm
-rw------- 1 aki users  47M  3月 14 16:46 purebuilder.mp4

シンプルなスクリーンキャストとはいえ、mobileはさすがにきつい。

サーバーをManjaro i3に

サーバー(ProLiant Microserver, Manjaro Linux LXQt)が、起動中にコケるようになっていたので、Manjaro i3で作りなおしてみた。

バックアップ作業

単純にsystemdユニット、そこから呼ばれるスクリプトと設定ファイルをバックアップした。
後にfstabもバックアップする必要があったことに気づく。

i3 Window Manager

i3 window managerは、タイル型ウィンドウマネージャだ。

タイル型ウィンドウマネージャというと、AwesomeやXMonadが有名だが、Manjaroで最も活発なのはi3だ。i3, XMonad, bspwmの比較を見ても、最も人気があるのはi3であるようだ。

Awesomeと比べると利点は多い。マルチディスプレイに対応しているというのが大きいのではないか。

bspwmもManjaroではCommunity buildのあるウィンドウマネージャだ。bspwmのほうが、ウィンドウに隙間があってスタイリッシュだが、i3のほうがとっつきやすい。ちなみに、Gnome3をi3で使っている人もいるようだ。なかなか変態的だ。けれど結構使いやすいのではないかという気もする。
ここまでカスタマイズすれば作業環境は快適だろう。

机でちゃんとした作業スペースがあるわけでもなく、膝の上の小さなキーボードの上でも扱いやすい、また複数のモニタープログラムを並べ、状況を把握したい場合にGUIを立ち上げてコンソールを叩くようなケースも考えられるのだし、サーバーにi3というのはベストな選択なのではないか。

i3やbspwmというとArchばかり出てくるが、それはArchであれば環境構築が楽なGUIとしての選択肢にもなりうるし、そもそもArchでもなければなかなかパッケージもないからだろう。

非常に機能的で使いやすいウィンドウマネージャだ。

Manjaro i3

Community buildではあるが、Manjaroにはi3 Editionが存在する。
ウィンドウマネージャの操作感こそ違うが、全体的な印象としては変わらない。Thusインストーラもそのままだ。インストール手順も、LUKSやbtrfsに関するソフトウェアも変わらない。

Manjaro Welcomeはいきなりフローティングウィンドウで表示される。
フローティングウィンドウはタイルとは完全に独立として表示され、マウスでフォーカスすることになる。ちなみに、クリックフォーカスではなく、オーバーフォーカスである。

ModはSUPER(Windows)に設定されている。Mod+Enterでターミナルエミュレータを開くことができる。基本的な操作方法は画面に表示されているし、mod+Shift+hでヘルプを表示できる。

なお、フリードライバで起動する必要があった。

アップデート

キーリングがおかしなことになってしまうので

# pacman-key --init
# pacman-key --populate archlinux manjaro
# pcaman-key --refresh
# pacman -Syuu

その間にavahi-daemonとsshdをenableしておく。mdns_minimalは既にエントリに記載されており、問題ない。

さらに、/etc/default/grub にデフォルトオプションとしてsystemd.unit=multiuser.targerを追加しておく。
グラフィカル起動する時は、Grubでオプションを編集して削る。

再起動したら、

# mhwd-kernel -i linux45

Linux 4.5はまだRC1だが、問題なく動作した。

設定

退避したファイルを戻すのだが、tarパイプでファイルとして保存したものを、tarパイプで戻そうとするとパーミッションを書き換えられてしまうので要注意。一度これでやり直しになった。

/etc/fstabを書いて完成だ。

i3は良いけれど

Synapticsによる設定をちゃんとしていれば結構快適だったりするし、Cinnamon/Plasma/XFceはタイリングもでき、便利なアプレットもあったりするので、実際に選択する機会は少ないかも。

Aukey CB-H15のテストとRealtek RTL8152/8153 Bawsed USB Ethernet Adaptorsバグ

この手のアイテムといえば

Aukeyからご提供いただいたUSB3.0ハブ兼GbEアダプタのCB-H15のテストと、Live with Linuxのネタのセットになる。

この手のデバイスは、あまり有名ではない。だが、重要性はましており、アイテムとしては増えている。
最近のラップトップはEthernetポートがついていないものが増えている。消費電力が大きく、高さもあるポートを嫌うのはわからないではないが、wLANが好きでない人は結構いるのではないか。

減ってしまったUSBポートを補い、Ethernetポートを復活させる、欠かせないアイテムが、このUSBハブ兼Ethernetアダプタだ。

また、PCルーターを使用する人にとっても欠かせないアイテムでもある。
消費電力が少なく騒音の小さいラップトップを使用する場合はUSBタイプでなければ難しいし、小型のサーバーを使う場合でもPCIeでの接続は結構難しい場合がある。
安定して確実に使えるのが、USBイーサネットアダプタである。USBハブを兼用している必要はないのだが、兼用しているものならば汎用性が高い。

実際に、USB2.0接続の100baseなアダプタを既に2つ持っている。
インターネットの速度的に、ルーティング先がインターネットにつながるのであれば100baseでも問題ないのだが、LANのルーターとしては不十分である。
USB3.0でGbEが使えるようになったのだから、それが利用可能であれば使いたいものだ。
ちなみに、その100baseなアダプタを2つも持っているのは、セルフパワーでも動作するという点を買ってのこと。

まだUSB3.0を使えるのが、バックアップ系になっているFM2+Killerしかないため、今のところはUSB3.0 GbEアダプタを導入してはいないが、この先導入する予定だったし、結構Amazonで探したりもしていた。

日本だとメジャーどころが多いが、中国だと結構あるらしい。
コストと品質を考えれば、やはり中国や台湾の当たりデバイスをひきたい…と考えるのは、まぁ好き者の性なのか。
TODOに入っている状態で見た限りでは、そんな感じだ。

そこにご提供いただけたため、渡りに船状態。
しっかりとテストしていく。

Linux上でのRealtek RTL8152/8153 Bawsed USB Ethernet Adaptorsのバグ

当然ながらLinux環境でのテストになる。
Manjaro Linux(4.1.15-1-MANJARO)で使用すると、一発認識される…のだが、「ケーブルが接続されていません」となる。

試していくと、リンクが100Mbpsならばケーブル接続を認めるのだが、1000MbpsだとNot Readyになってしまう。

上手くいかなくて調べたところ、バグらしい。

こういう問題なら、多分Ubuntuでも同様だと思う。
ここでUbuntu forumでなくArch forumが出てくるところに両者の差が…

ともかく、TLPのUSB BLACKLISTとして0bda:8152を登録する。
手順としては/etc/default/tlp

USB_BLACKLIST="0bda:8152"

のように記述する。

品質テスト

筐体

サイズは大きいが、軽い。
10.1や12.1のラップトップと組み合わせて放り込むには大きい。15.1のラップトップならバッグに入る。

プラスチックで安っぽいボディではあるが、それほど気にならない。

注目すべき点として、USBポートは横向きのタイプで、かつオフセットされている。
そして、オフセットされたポート側は角が角、反対側は丸められている。
恐らくは、壁につけて設置することを想定しているのだろう。このために、USBデバイスを挿してもひっぱられてハブが倒れてしまいにくい。

個別にLEDランプがあるのも嬉しい。携行よりは常設向きか。15.1くらいのラップトップを家で常用している人にベストか。

速度

iperf3で計測。

$ iperf3 -c mint.local
Connecting to host mint.local, port 5201
[  4] local 2001:c90:8481:3759:f21e:34ff:fe1f:a542 port 55861 connected to 2001:c90:8481:3759:3ed9:2bff:fe50:efed port 5201
[ ID] Interval           Transfer     Bandwidth       Retr  Cwnd
[  4]   0.00-1.00   sec  97.1 MBytes   815 Mbits/sec    0    273 KBytes       
[  4]   1.00-2.00   sec  95.7 MBytes   803 Mbits/sec    0    287 KBytes       
[  4]   2.00-3.00   sec  96.3 MBytes   808 Mbits/sec    0    305 KBytes       
[  4]   3.00-4.00   sec  96.5 MBytes   810 Mbits/sec    0    326 KBytes       
[  4]   4.00-5.00   sec  96.4 MBytes   808 Mbits/sec    0    343 KBytes       
[  4]   5.00-6.00   sec  96.5 MBytes   809 Mbits/sec    0    382 KBytes       
[  4]   6.00-7.00   sec  95.9 MBytes   805 Mbits/sec    0    404 KBytes       
[  4]   7.00-8.00   sec  95.9 MBytes   804 Mbits/sec    0    425 KBytes       
[  4]   8.00-9.00   sec  96.1 MBytes   806 Mbits/sec    0    448 KBytes       
[  4]   9.00-10.00  sec  97.5 MBytes   818 Mbits/sec    0    558 KBytes       
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval           Transfer     Bandwidth       Retr
[  4]   0.00-10.00  sec   964 MBytes   809 Mbits/sec    0             sender
[  4]   0.00-10.00  sec   961 MBytes   806 Mbits/sec                  receiver

iperf Done.

809Mbps/806Mbps。
800Mbpsを越えているので及第点だろう。

うちならば、

  • WAN/インターネット->OK
  • サイト間インターネット->OK
  • サイト内ネットワーク(AoE)->NG

といったところで、AoEや業務ルーターなど高いスループットや信頼性がが要求されるシーンでは使えないが、インターネットでボトルネックになることはまず考えられないし、AoEやdistccなどの高スループットが要求される用途で使われない異サイト間を接続するルーターへの接続なら(家庭用途では)問題ないだろう。

USBアダプターであることを考えれば(まして、USBハブと兼用)不満のない性能だ。

ちなみに、オンボードのQualcomm Atheros Killer E20x Gigabit Ethernet Controller

$ iperf3 -c mint.local
Connecting to host mint.local, port 5201
[  4] local 2001:c90:8481:3759:be5f:f4ff:fefb:bb5 port 52309 connected to 2001:c90:8481:3759:3ed9:2bff:fe50:efed port 5201
[ ID] Interval           Transfer     Bandwidth       Retr  Cwnd
[  4]   0.00-1.00   sec   110 MBytes   919 Mbits/sec    0   97.6 KBytes       
[  4]   1.00-2.00   sec   110 MBytes   920 Mbits/sec    4    180 KBytes       
[  4]   2.00-3.00   sec   110 MBytes   919 Mbits/sec    0    190 KBytes       
[  4]   3.00-4.00   sec   110 MBytes   919 Mbits/sec    0    206 KBytes       
[  4]   4.00-5.00   sec   110 MBytes   919 Mbits/sec    0    208 KBytes       
[  4]   5.00-6.00   sec   110 MBytes   920 Mbits/sec    0    212 KBytes       
[  4]   6.00-7.00   sec   110 MBytes   919 Mbits/sec    0    212 KBytes       
[  4]   7.00-8.00   sec   110 MBytes   919 Mbits/sec    0    212 KBytes       
[  4]   8.00-9.00   sec   110 MBytes   920 Mbits/sec    0    220 KBytes       
[  4]   9.00-10.00  sec   110 MBytes   920 Mbits/sec    0    240 KBytes       
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval           Transfer     Bandwidth       Retr
[  4]   0.00-10.00  sec  1.07 GBytes   919 Mbits/sec    4             sender
[  4]   0.00-10.00  sec  1.07 GBytes   919 Mbits/sec                  receiver

iperf Done.

さすがに速い。Killerイーサネットは遅いと言われているが、かなり速い。
PCIeのほうが安定して速い、ということなんだろう。

このような信頼性や速度を求めるのであれば、そもそもUSBでやらないだろう。

製品評価

最初に述べたように、この手のアイテムはラップトップユーザーなら必携だ。

持ち歩きにはそれほど向いていない。大きいためだ。だが、大きな(余裕のある)バッグを常用する人であれば、軽量であるため携行は苦にならないだろう。
要は軽量であるためでなく小さいためにモバイルラップトップを使う人なら携行には向かず、そうでなければ携行用にもなる。
少なくとも、スーツケースを使うような出張においては携行するのに苦もないだろう。

USB3.0の3口ハブとの組み合わせで、ラップトップなど端子が限られている中では現状ベストなアイテムだと思う。
USB3.0ハブとして使用する場合はそちらに帯域が取られることになり、LANはフルスピードが出ない。その意味で、純粋なEthernetアダプターというよりは、インターフェイス拡張という考え方が適当だろう。
その意味で、USB3.0 1ポートとUSB3.0の3口ハブとGbEという拡張は「マスト」なのだ。

私はThinkpad e440をEthernetポートありきで選んでいるし、Pavilion x2-10を自宅で使うことは滅多にないので、基本的にラップトップでこのようなインターフェイス拡張を行うことがない(泊まりがけの作業などにおいてはe440を持ち出す)のだが、もしそうではない、Ethernetポートのないラップトップを使っていたとしたら、ましてデスクトップなしにメイン機として使っていたとしたなら、なくてはならなかっただろう。
言ってみれば、ThinkPadのドックステーションのようなものだと言っていい。もちろん、携行はずっと容易だ。

アイテムとしての価値はそうとして、ものはどうか。

まず、LANチップは評価は色々あれど、信頼性の高い、一般的なチップであることはLinuxerとしては非常に嬉しい。
私が使っている100baseのハブは、ドライバがちょっとbuggyで、CentOS6だと使えないなどの問題があった。
結局、ドライバに関係するバグ(udevに関するバグだが)によってこれはこれでワークアラウンドが必要になったが、情報が多く解決は比較的簡単だった。
これは結構重要なのだ。

もちろん、USB3.0ハブとしての機能は申し分ない。
USB3.0を増やさなければならないケースはあまり多くはないと思うが、ラップトップの端子数が2以下であるならば、キーボードやマウスを接続すると同時にフラッシュドライブを使用するようなケースは珍しくはないだろう。

片面の角が角、もう片面は丸となっていることについては、なかなか心憎い発想だとは思うが、実際に活用する場面は限られそうだ。だが、実際に壁につけて使用する場合は収まりもよいはずだ。

そして、USBポートがオフセットされているのは、実際にそのためにハブがこけないようになっている。これは、大きな魅力であり、選択時に比べるポイントの少ないこのようなアイテムにおいて選択する理由に十分なりうるだろう。

デザインも良い。

総合的に見れば、特にコンパクトさを重視しないのであればとても良い製品だ。
linuxer目線でいえば、あまりこうしたアイテムで使われているチップが判別していて、動作報告があるものというのがないため、この情報だけでも十分使う価値はある。
正直、800Mbpsは厳しいだろうと思っていたのでかなり嬉しかった。

Firefoxによるbtrfsの破壊トラブル

btrfsが頻繁に壊れるトラブルに見舞われた。
デスクトップがフリーズし、再起動するもディスクへのアクセスで非常に長い時間がかかる。
くりかえし再現したが、いずれもFirefoxの、特定のプロファイルでYouTubeを見ている最中だった。

btrfs scrubすると、ある特定のポイントに集中的にエラーが発見される。
結局、他のブラウザや、他のプロファイルでは発生しないが、
「問題のあるプロファイルを.mozillaごとリネームしても発生するし、問題のないプロファイルを同じファイル名にリネームしても発生する」という状態だった。

究明はできなかったが、とりあえず報告まで。

Yaourt(makepkg)の高速化

Manjaro Linuxでyaourtを用いたAURパッケージのビルドが非常に遅いので、設定を見なおしてみた。
設定ファイルは/etc/makepkg.confである。

CFLAGSとCXXFLAGS

実行速度のためのパラメータ。

-march=x86-64 -mtune=generic

となっているが、これは一般的なx86_64バイナリ(最適化されない)を生成する。
これを適切な値にすることで最適化されたバイナリを生成する。

通常は

-march=native

とするが、distccでは利用できない。

gcc -c -Q -march=native --help=target | grep march

とすることで最適な値を知ることができる。Xeon W3565ではnehalem, Godavari(A10 7870K)ではbdver3だった。

MAKEFLAGS

並列ビルドのための値が書かれているが、コメントアウトされている。

最適な値はコア数の倍とされているが、distccではコア数が限度のようだ。

BUILDENV

!がついているものは無効。ccacheを有効にするだけでもある程度違うか。

distcc

Arch Wikiの情報が正確で詳しい。

distccをセットアップした上で、makepkg.confの設定を変更する。
なお、DISTCC_HOSTSについて、Zeroconfを使う場合が色々書かれているが、単に.localで名前解決するだけの話であれば普通にホスト名を書ける。

しかし…

-j12でも結局ローカルとリモートの2コアしか使われていなかったようにみえて残念。

FM2+KillerのLinuxセットアップ: 既存のManjaro Linux (Arch Linux系)環境をクローンする

あらまし

元々、メインのLinux環境はFM2+Killerだったが、Z400に移行したことで位置づけが変わった。

メインの作業環境はZ400上にあり、既に構築済みだ。
FM2+Killerは冗長環境として、同様にLinuxを構築し、いつでも使えるようにしておくのが望ましい。

可能であれば、ハードウェアも全く同じものを用意すれば、簡単にクローンできる。
だが、Z400とFM2+Killerでは色々と違いがある。特に大きいのはグラフィックスカードの種類と、ディスプレイの数の違いだ。

さらに、FM2+Killerは

  • 障害時にメインと同様に使うことができるアカウント
  • サテライト的に使う一時作業用アカウント
  • 彼女がうちにいる時に作業に使うアカウント

の3つをセットアップする

インストール

私が使っているのはManjaro Linuxである。当然ながら同じManjaro Linuxを導入する。

既にManjaro Linux 15.09がリリースされているが、15.09はUEFIにインストールすることができないバグがある。特に

0.8.13 XFceをインストールし、アップグレードする。
違いはあとから埋める。

通常どおり、yaourt -Syuuでアップグレードした上で、新しいカーネル(4.1)を導入する。4.2でないのは、AMDユーザーに勧めない、ということなので。

インストーラで作るユーザーはメイン環境と同じユーザーにすること。
でないと、UID/GIDの違いでディスクを差し替えただけでは動かなくなる。

パッケージを揃える

メイン環境と同じパッケージが入っていればもし作業環境を作るにしても、少ない手間で可能だ。

Arch Linuxにパッケージを揃える機能はなさそうだったので、スクリプトを書いた。

#!/usr/bin/ruby
# -*- mode: ruby; coding: UTF-8 -*-


PLIST = File.exist?(".previous_autoyaourt_target_list") ? File.open(".previous_autoyaourt_target_list", "r").each.map {|i| i.strip[/^\S+/] } : nil 
TLIST = ARGF.each.map {|i| i.strip[/^\S+/] }
EXCLUDE = [ /nvidia/i, /^linux/, /^libva/, /catalyst/, /maxthon/, /^opencl/, /^ocl-/, /^libcl/ ]

File.open(".previous_autoyaourt_target_list", "w") {|i| i.puts(TLIST) }


loop do
  clist = IO.popen("pacman -Q", "r") { |io| io.each.map {|i| i.strip[/^\S+/] } }
  to_install = ( TLIST - clist ).delete_if {|i| EXCLUDE.any? {|r| r === i } }
  
  if to_install.empty?
    break
  end
  
  system("yaourt", "-S", *to_install[0, 15]) or abort "Yaourt failed!!!"
end

if PLIST && ! ( dlist = PLIST - TLIST ).empty?
  
  puts "*******************************************"
  puts "CLEAN UP PHASE"
  puts "*******************************************"
  
  
  
  system("yaourt", "-R", *dlist)
end

Manjaro Linuxは標準でyaourtは入れているが、Rubyが入っていない。
Rubyをインストールし、元となる環境で

pacman -Q > target-paclist

のようにした上でこれを持ってくる必要がある。そして

ruby yaourtsyncer.rb target-paclist

のようにするわけだ。

--noconfirmオプションはつけていない。問題が発生することがあり、またひとつずつ確認したほうが安全だからだ。

別にパッケージデータそのものを持ってきて(/var/cache/pacman/pkg/以下にある)インストールする方法もあるのだが、今回は1台クローンするだけの話だし、健康にビルドしていく。

事前にsudoのタイムアウトを外しておいたほうが良いが、visudoはあるのにviがない。先にviをインストールしておく。gvimをインストールしてリンクしておいても構わない。

もし手間を短縮するなら--noconfirmをつけてもいいのだが、いずれにせよ手をかけねばならない状態になったり、失敗した時にいちいち外したりしないといけなかったりする。

これでうまくいかないのが、旧リポジトリからいれているパッケージ、失われたパッケージ、壊れてしまったパッケージだ。

旧リポジトリから入れているのがxcursor-lcd-*、なくなってしまったのがjoyutils、などなど。
これらはmakepkgでビルドしたものに関してはパッケージを持っているだろうし、pacmanやyaourtで入れたのなら/var/cache/pacman/pkg以下にある。これを導入する。

グラフィックスドライバに関連するものについては個別の環境によるため、除外している。
カーネルは元々yaourtでいれるようにはなっていないので、これも除外。

ちなみに、fcitx-mozc-utやJava関連、inkscape-gtk3-bzrはビルドが非常に長いので流用したほうが良い。

ユーザー

残り2つのユーザーを追加し、設定する。

これらユーザーはこのコンピュータのローカルなものなので、好きなように設定して構わない。

サテライト環境ではsshfsを用いてマウントすることで、UID/GIDの差を吸収できる。

冗長環境

当然ながらユーザーの設定も、元のPCに合わせたものにしたい。

私の環境ではホームディレクトリの下のディレクトリにbtrfsサブボリュームがマウントされており、また別のディレクトリがEncFSのマウントポイントにもなっている。

単純に持ってきてしまうと、btrfsの膨大なデータをコピーしてしまうし(5TB近い)、EncFSのデータを復号化したまま持ってきてしまう。

これを避けるため、マスター環境のサブボリュームマウントポイントを同様に作り、sshfsでマウントし、

$ rm -rf (^(.mountpoint))(#qD)

して

$ rsync -avH -x --exclude=/.cache -e ssh "$HOSTNAME":./ ~/

これはなるべく、コンソール上で作業したほうがよい。rootでは、FUSEを使うため支障がある。

~/.cacheは特に同期する必要がなく、同期するととても時間がかかるので省略。--delete-afterなどはとても危険。

私の場合、~/.sshがシンボリックリンクなので失敗する。
この状態で削除とリンクを同時に行えばよい。リンク自体は別にsshfsを解除していても-fオプションで可能。

なお、これで気がついたのだが、こうしてまっさらにしてコピーしても、Cinnamonの壁紙とテーマはなぜか反映されず、ローカルの設定が保たれる。ローカルで設定した後に吹き飛ばしてもだ。

なお、このテストの家庭で全データを吹き飛ばしかけた。
幸い気づくのが早く、重要なデータの損失はなかった。

rsyncのファイルシステムをこえない-xオプションは非常に便利。

なお、autostart関連は除外したかったのだが、うまくいかなかった。
これは--excludeの書き方の問題。

ManjaroでCinnamonが破損 + Plasmaのセットアップ

Cinnamonが起動しない

Manjaro 2015-10-19 Stableを適用後の2015-10-22に、Cinnamonが起動しない、というトラブルに見舞われた。
正確には起動はしているように見えるのだが、表示されない。マウスカーソルがウィンドウ位置に合わせて変わるものの、一切の表示がない。

別ユーザーでも生じるため、自力で解明できず、結局Manjaro Forumに助けを乞うこととなった。

crazyg4merzさんにお答えいただき解決した。

2015-10-21に追加でアップデートされたcoglパッケージ(cogl-1.22.0-1.1-x86_64)がダメであったらしい。
これがDEを破壊する毒入りパッケージであったということだ。

sudo pacman -U /var/cache/pacman/pkg/cogl-1.22.0-1-x86_64.pkg.tar.xz

で解決した。

Plasma Workspace

Cinnamonが起動しない間、Plasma 5を使っていた。

ManjaroにPlasma 5がきたばかりの頃は、Plasma Workspaceコンポーネンツ自体のエラーが非常に多く、使い物にならなかった。

そこからすればだいぶ安定したとは思うが、まだkAlarmなど勝手に落ちるプログラムは多い。
また、kcmの内容をみても、まだまだKDE4の品質には追い付いていない、という印象だ。

とはいえ、追加された機能もあり、「完全に機能すれば」かなり素晴らしいDEであるとは思う。
UI自体はPlasma 5よりものしぃKDE 4のほうが好きだし、KDE 3はもっと好きだが。

Plasma 5で追加された機能のうち、私にとって重要だったのは、QuicktileにTopとBottomが追加されたことだ。
これまでは四隅と左右の6方向だったが、ようやくCinnamon同様に8方向に対するタイリングが可能になった。

このほか、強化された点を含め、Plasma 5の魅力が

  • 通知が制限された多段で表示される。Cinnamonは通知がひとつずつなので通知に領域を占領されてしまうし、XFceは大量に表示されてしまいデスクトップがうめつくされてしまう。
  • 8方向にタイルできる
  • KDE関連のアプケーションを含めて統合的にショートカットを設定できる
  • リマインダ機能がある
  • KDEに統合されているアプリケーションは非常に便利に使うことができる。
  • 通知領域への表示・非表示が任意に設定できる
  • DPI設定を忠実に反映してくれる(UIも含めて)
  • タスクスイッチャに使いやすいBreezeがある

Cinnamonのほうがいいのが

  • 通知の非表示が可能
  • PulseAudioアプレットの機能が貧弱
  • systrayでなくsniによる実装で、systrayに入ってくれなかったりする
  • WINEの文字表示が汚い
  • 全体にフォントレンダリングがCinnamonのほうが綺麗

SylpheedとTomboyを使っているが。KMailとKOrganizerを使っていたらもっと便利だろうと思う。

Systray問題

xembed-sni-proxyをインストールし、起動すれば解決するといえばするが、アイコンが表示されない。

私はTrayerを使い

trayer --edge bottom --align right --widthtype request 

のようにしている。右下にしているのは、デュアルディスプレイだから。
ちなみに、Trayerは領域を確保せず、stalonetrayは確保する。
最大化した時にかぶるかどうかが違う。

タスクマネージャを外してtintを使う、というのも方法かもしれない。

WINEにおけるLINEのフォントの問題

XFceでもPlasmaでもWINEのLINEの文字は汚い、というかCinnamon/GNOMEだけが綺麗に表示できる。

XFce, PlasmaはWindowsっぽいレンダリング(むしろビットマップっぽい)、CinnamonとGnomeは通常通りInfinarityのそれだ。

しかも、PlasmaやXFceにおいては、フォント幅が適切に保たれず、フォントが重なって欠けて見えるため可読性が非常に低い。

これについては、regedit.exeHKEY_CURRENT_USER\Control Panel\Desktop以下

FontSmoothing REG_SZ 2
FontSmoothingGamma REG_DWORD 0x000003e8(1000)
FontSmoothingOrientation REG_DWORD 0x00000001(1)
FontSmoothingType REG_DWORD 0x00000002(2)

のように設定。これで幅は確保される。
だが、アンチエイリアスは効かないので、HKEY_CURRENT_USER\Software\Wine\X11 Driver\ClientSideWithRenderという値を作る。これできくようになる。

ただ、英字フォントについてはAAが効かないので違和感は結構ある。
これは、regeditの表示など、LINE以外のいくつかにも有効に働き、そこでは英字に対してもきいている。
しかし、Freetypeのものと比べると随分汚い。

色々ためしてみたのだが、うまく行かなかった。

LinuxでPLANEX PSX-CV02を使ってゲームパッド

PLANEX PSX-CV02は、PCでPlayStation/PlayStation 2のゲームパッドを使用するためのコンバータである。
PlayStation3でも利用することができる。

Arch wikiにはゲームパッドを利用するのはかなり難しいということが書かれているが、少なくともPSX-CV02はManjaro Linuxで「挿せば認識する」ものだ。

これでもう、PSコントローラをつなげばTorcsではおおよそ正しく動く…のだが、いくつか問題がある。

まず、ゲームパッドでマウスが操作されてしまうため、まともに使えない。
これを無効にするため、/etc/X11/xorg.conf.d/50-joystick.confとして

Section "InputClass"
		Identifier "joystick catchall"
		MatchIsJoystick "on"
		MatchDevicePath "/dev/input/event*"
		Driver "joystick"
		Option "StartKeysEnabled" "False"       #Disable mouse
		Option "StartMouseEnabled" "False"      #support
EndSection

を記載して再起動する。

で、この状態でTorcsがプレイできる。ただし、Torcs上でスティックのキャリブレーションが必要。
どうも、Analogをoffにしていると(あるいは、フルデジタルのコントローラだと)十字キーはスティックとして認識され、Analogをオンにしていると十字キーは十字キーと認識されるようだ。

ちなみに、ボタン配列は

  • Btn0 = Triangle
  • Btn1 = Square
  • Btn2 = Cross
  • Btn3 = Circle

と結構変。このマッピングはjstest-gtk-gitパッケージのjstestで変更もできる。

Torcsはいいのだが、WINE上の某ACTゲームはパッドをそのまま認識してくれない。anitimicro-gitパッケージのanitimicroがキーに対するマッピングを可能にする。これはなかなか便利で、ちゃんと機能した。

なお、結構言われているように、これに接続すると12軸24ボタンの1つのジョイスティックとみなされる。パッチングが必要なようで、とりあえず困っていないので放置。

PS3でネジコンを使うことも可能であるらしいこのアダプタ、なかなかよさそう。