Manjaro 16.08 Preview

Manjaro 16.08 ELLADA

Manjaro LinuxはArch Linux派生のLinux Mint的なディストリビューションである。
初心者向けを標榜してはいるが、あんまり初心者向けではなく、Archから一般的用途においてこだわりよりも簡便であることを優先したものと思えば良いだろう。

その最新バージョンであるManjaro Linux 16.08 ELLADA。
8月31日に正式リリースされたが、今回のストレージクラッシュによる長時間の利用不能を利用してシステムのクリーンナップを兼ねて256GB SSDへの移行を再インストールで行い、Manjaro Linux 16.08 Pre5を試した。

Manjaro LinuxはArch Linux同様のローリング・リリースであり、どのバージョンからインストールしても常に最新のバージョンが保たれる。
しかし、新パッケージに含まれない変更も存在するため、インストールしたバージョンによって少し環境が異なってくる。
(なお、Arch Linuxではほとんど差が出ない)

これまでManjaro Linux 16.06ベースまでは試していたが、16.08は試していなかった。その変更点が重要だったため、少し言及する。

Calamaresインストーラ

これまでManjaroのGUIインストーラはThusとCalamaresのふたつがあった。

Thusが旧来のもので、ずっと「ベータ版です」と警告されていた。
そして、Thusは正式版になることなく開発停止され、ManjaroはCalamaresに移行していた。

Calamaresは汎用インストーラであり、Manjaro/NetRunnerのほか、FedoraやopenMandrivaも協力している。

だが、その完成度は低く、

  • ファイルシステム指定が十分に機能しない
  • LUKSが使用できない
  • LVMの利用もうまくいかない場合が多い
  • UEFIインストールもうまくいかない
  • 要は手動パーティショニングでは何もできず、自動インストールでもなんの選択肢もない

というもので、事実上Thusを使うしかなかった。

ところが、16.08からThusが削除され、Calamaresだけになった。
「当面は最新ISOは無理か!?」と思いきや、長年の問題とされてきた手動パーティショニングの問題をついに解決したというだけあって、LUKS暗号化を含めちゃんと機能するようになっていた。

今回は

  • SSD
  • GPT+BIOS
  • 2パーティション(/boot=EXT3, /=XFSonLUKS)

という構成にした。
XFS on LUKSはXFSを選択して「暗号化する」という選択だけなので難しさはない。LVMはインターフェイスがないので、LVM PVを選んでもどうだろう?

/bootはdefaults,noatime, /はdefaults, noatime, discardオプションとなった。
ルートファイルシステムに対するnoatimeはパフォーマンスは向上するが、セキュリティ的には決して推奨できないので注意(ただし、調査・検証を行う人に限る)。SSDに対するdiscardはきちんと認識されてオンにされる。

アートワーク

アートワークの改善に力を注いでいるそうで、/usr/share/backgournds以下に大幅にファイルが追加された。

これによりManjaroを活かした壁紙を設定する場合の選択肢が増えた。ただし、初期設定の背景フォルダとして指定されていないため、多くの人は気づいていないだろう。

VLC

標準で採用VLCがextravlcではなく、vlc-nightlycommunityとなり、VLC3系となった。

ディスク故障でbtrfsの機能を使い倒す

対応方法

ディスク容量が逼迫しているので何らかの対処が必要である。
とりあえず考えられる方法としては

  • ディスクを大容量のものに交換する
  • USBあるいはeSATA接続のディスクを追加する
  • NASを追加してディスクを追加する
  • AoEを使って他ホストのディスクを追加する
  • 内蔵ディスクを追加する

のいずれかだ。そもそも取り扱うデータ量が多いため、削減ということは考えられない。
もちろん、削減自体は行っているが、その精査にあてる時間のほうが重要で、無効な対策であると考えられる。それほど引き延ばすこともできない。

大容量への交換は効果的だが、現在3TBを使用しており、4TBの場合は33%の容量増となり、不足である。
6TB以上は高額すぎるため却下された。

USB/eSATAを最も有力な候補としていたが、台数搭載するためには金額的にも高く、またいずれの製品も信頼性に劣るようだ。

多数搭載のケースを使用するのであればReadyNASも有力な候補だった。ReadyNASはiSCSIに対応するが、「ReadyNASに搭載されているディスクを指定する」ことはできない。何台搭載しても、btrfs的に見れば1台にしかならないのだ。

そのため、btrfsで管理するためにはReadyNASを複数台追加する必要がある。ReadyNAS全体でbtrfsから見て1台のディスクであり、ReadyNASの台数=ディスク台数になる。
btrfsは不均等なRAID1をサポートするため、例えばReadyNASに12TBを搭載すれば12TB RAID1を構成することが可能だが、あまりうれしくはない状態になる。

AoEを使うのは追加費用のかからない方法だ(ディスクとホストはあるため)。
だが、問題はAoEを使う方法は常に

  • マウント前にターゲットホストを起動していなければならない
  • アンマウント前にターゲットホストを終了してはいけない
  • ネットワークを切断してはいけない

と結構厳しい条件になる。
ターゲットホストが消費電力が大きく、また冗長系システムであり、日常稼働しているものであることを考えるとこれは厳しい。

そこで内蔵ディスク追加を選択した。

Z400の3.5inchシャドウベイの数は2、SATAポート数は6である。
現在、iStarUSAの5.25inchベイ*2を3.5inch HDD*3に変換するリムーバブルラックを使用してシステムSSDを含む計5台を搭載している。
そのため、2台追加となると、マウント的にもSATAポート的にも足りない。

採用した方法はエアリアのSATA*2 PCI-e 1xカードによりポートを2増設し、DVDドライブを除去してiStarUSAの5.25inch*3をHDD*5に変換するリムーバブルラックを搭載するというもの。

かなり無茶だが、さらに無茶なのが、そもそもビデオカードがGeForce GTX750Tiに変更されているために、隣のPCI-e 4xが埋まってしまっており、逆側のPCI-e 4xは使用済みなので、PCI-e 16xに接続した、ということか。

ディスク追加手順

ディスクの追加は、ディスクを装着した状態で

# btrfs device add /dev/sdx /path/to/volume
# btrfs device add /dev/sdy /path/to/volume
# btrfs balance /path/to/volume

のようになる。
balanceの所要時間は果てしなく、うちのケースでは40時間ほどかかった。

そして、balanceがまもなく終わろうという頃に、もともとあったほうのディスクが壊れた。

故障ディスクの除去と交換

故障ディスクが正常にアクセスできない状態にあるとき、btrfsファイルシステムへのアクセスはシステム全体を止めてしまう。
この状態ではbtrfs device deleteもできない。

もしこれが可能な状態であればdeleteよりも新規ディスクも装着した状態でのreplaceのほうが早い。

故障ディスクはオフラインの状態でまず除去してしまい、その上で新規ディスクに交換する。
そして、新規ディスクに対して

# btrfs device add /dev/sdx /path/to/volume

したあと、

# btrfs device delete missing /path/to/volume

するとreplaceに近い挙動になる。

しかし、実際にやるとシステムが死んでしまった。ログにがっつりRIPが残っていた。

ファイルシステム新規作成

もはや修復は不可能なので、ファイルシステムを再作成してバックアップから書き戻す。

dm_crypt上に作成するのであれば、dmデバイスを用意したうえで

$ sudo mkfs.btrfs -L labelname -d raid1 -m raid1 /dev/mapper/crypt_dev_*

こうしてみると気づくのだが、btrfsのミラーリングはミラーレッグの指定ができない。
ジャーナリングの強化版というコンセプトなので当然なのかもしれないが、結構不安。本物のRAID1がほしい人はLVMを使うほうが良さそう。LVM+Btrfsであれば、2台ずつ容量を揃える必要があるが、容量の異なるディスクを混在できる。

バックアップのbtrfsファイルシステムからのリストア

btrfsにはsend/receive機能があり、簡単にバックアップができる。

btrfs sendは差分も可能でストリームで送られる。つまりファイルとして保存することもできる。
この場合復元はcatによって行うことになるだろう。差分だとどうなるのかはわからない。

recieveはsendによって出力されるストリームを元にファイルへと書き出す。

ネットワーク越しのバックアップ手段として行う場合は、権限的な難しさがある。send/receiveはroot権限が必要なためだ。
rsyncであればユーザー権限でのバックアップが可能だが、send/receiveを使う場合はそうはいかない。
受け渡しをssh経由で行おうとすると、rootでのsshアクセスを許していなかったりして結構なネックになる。
別に鍵を作れば良い話ではあるが。

sudoを用いたコマンドラインで行うのであれば、socatを使用する方法がある。receive側は

$ socat tcp-listen:30000 | sudo btrfs receive /path/to/volume

send側は

$ sudo btrfs subvolume snapshot -r /path/to/volume /path/to/snapshot
$ sudo btrfs send /path/to/snapshot | socat stdin tcp-connect:receiverhost:30000

経路安全性を問題にするのであれば、openssl-listenを使うか、ssh -Lを使うなどの方法がある。
インターフェイスを限定できないのが問題なら、rubyワンライナーを使う方法や、もうひとつプログラムを増やし、ソケットで読んで書き込む仕様として、ssh経由でソケットに出力するプログラムを起動するという方法もある。

例えば次のようなスクリプトである。

#!/usr/bin/zsh
zmodload zsh/net/socket

zsocket -l /tmp/btrfs-syncer
sock=$REPLY
while zsocket -a $sock
do
  (
    btrfs receive /path/to/volume <&$REPLY
  ) &
done

こちらはrootで実行する。対してsshで実行すべきは

#!/usr/bin/zsh
zmodload zsh/net/socket
zsocket /tmp/btrfs-syncer
cat >&$REPLY
exec {REPLY}>&-

あとは

$ sudo btrfs subvolume snapshot -r /path/to/volume /path/to/snapshot
$ sudo btrfs send /path/to/snapshot | ssh receivinghost.locadomain btrfs-syncer-client

注意点として、例えばsubvolというサブボリュームに書き戻したい場合、subvolというサブボリューム上にreceiveすると結構困ってしまう。
その場合はそのペアレントボリュームにreceiveした上で(snapshotの名前になってしまうので)mvするのが正しい。

なお、mvしてもreadonlyのままになるため、ロールバックするためには属性変更が必要。

$ sudo btrfs property set -ts subvol ro false

ro trueでreadonly。
IDによるマウントを使っているのであれば、set-default

追加のクリティカルヒット

しかし、またも/dev/sdgの大量エラーという結果になった。一見すると正常だが、ログを見ると1.77TiBの書き込みの間に71456ものblk_update_requestが発行されている。

2度続けてsdgだったため、ケーブル、ラック、ボードのいずれかが問題である可能性も考えられたため、ディスクを入れ替えて(/dev/sdfの位置にあるディスクと入れ替えた)試したところエラーはなく、ディスクの不良と断定。初期不良を申請し、翌日回答、翌々日到着となった(NTT-Xの対応は早い)。

ちなみに、NTT-Xにディスクの初期不良対応を申請したところ、

  • メーカーに確認→メーカー回答を得て応答(交換or返金)→交換の回答を得て発送→到着時に集荷として引き渡し

という手順だった。

交換ディスクは

# dd if=/dev/zero of=/dev/sdf bs=512M

として全域書き込みを行い、

# journalctl --no-pager | grep -F blk_ | tail

としてblk_update_requestが発生していないことを確認した。

そして前述の通り、新規ファイルシステム作成、マスターボリュームのマウント、socatと連動したsend/receive、リネーム、プロパティ変更と行い、エラーがないことを確認した。
なぜか全域でデータ量が5.30TiBまで減少していた。

しかしtopで、kworker/3:2及びksoftirqd/3が張り付いたままになっている。
kworkerはおそらくbtrfs絡みだろうし、ksoftirqdが固まっているということはディスク処理だろうから、しばらく待つことにする。特にkworkerはずっとS欄がR(Running)であり、明らかに忙しくしているので安全を考えて待つ。

結局kworderがしずまらなかったので、syncしてunmountし、それが問題なくunmountされたことを確認してからreboot。

エラーが何もないことを確認して、おそらくこれで完了。
とてもとてもとても大変だった。

ThinkPad e440 * Manjaro Linux x86_64 XFce 16.06

概要

これまでManjaro Linux KDEを使用してきたThinkPad e440だが、Manjaro Linux XFceに変更した。

e440のOSは安定せず、かなり変更を重ねている。これまで

  • openSUSE
  • Mageia
  • Manjaro XFce
  • PCLinuxOS FullMonty
  • Linux Mint
  • Manjaro LXQt
  • PCLinuxOS KDE
  • Manjaro KDE
  • Manjaro XFce

という流れだ。求められる条件は

  • BIOSでWindowsとのデュアルブートが可能
  • /の暗号化が可能
  • ローリング・リリースあるいは長期運用が可能
  • 先進的
  • RealTek RT8168 無線LANが利用可能

これがなかなか難しい。
ちなみに、Manjaro Linuxも現状、GUIインストーラでWindowsのデュアルブートとLUKSを両立させる場合、MBRの書き換えを防ぐことはできない。

Manjaro Linux KDEとXFceの違い

違わないようで、実は結構違う。

XFceの設定

Manjaroのパッケージ内にXFceに関する設定が不足している。特にKDEでインストールした場合は、XFceに関する設定は全くない。

XFceから新規ユーザーを作った場合は、おおよそ反映されるし、そのためパネルやアプレットが大きく異なるが、Mnajaroのメニューは階層化されていない状態になる。

LXQtとWiFi

KDEでインストールした場合、LXQtはconnmanを使おうとnm-appletを使おうと、D-BusエラーになりWi-Fiを使うことができない。XFceでインストールした場合はnm-appletが問題なく動作する

XDM

KDEはKDM、XFceはLightDMを使う。

KDEアプリの動作

XFceでインストールした場合、Akonadiが正常動作せず、KDEコンポーネントが完全には動かない。

KDEコンポーネントをフルに活用しとたKDE環境を望む場合は素直にKDEでインストールのが良い。

Wi-Fiの挙動

KDEの場合、Wi-Fiがおかしくなり、やがて接続は確立しているのに通信しなくなる。(チップはRT8168)
頻繁に発生し、再接続すれば復帰する場合が多いが、あまり放置しすぎると切断自体不可能になる。

XFceの場合は、その状態が発生しない。

また、mkwd-kernelを使うと、XFceの場合だけrt8168パッケージをインストールするようになっている。KDEの場合はndiswrapperパッケージをインストールする。これは、15.12と16.06の違いもあるのかもしれない。

アップデートアプレット

KDEの場合はOctopiを使うし、アプレットもOctopiのものになっている。

ファーストインプレッション

もちろん、Manjaroということで同じものなのだが、実際には結構な違いがある。

Plasma Workspaceが結構不安定で(ハードウェア的な問題だろう。Manjaroに限らない)、よくKWinが再起動するのだが、安定しており、最初からWi-Fiを利用することができる(速度的には有線のほうが良いが)といったメリットがある。

機能的にはXFceはかなりそろっていて、非常に使いやすい。ただし、Thunarなど一部のXFceアプリはパスを問答模様で補完するため、普通に打っていると勝手に補完されてパスが違っているということがあったりする点はマイナス。
ただ、機能的な不足はないはずだが、実感としてはやはりCinnamonのほうが使い心地は良い。

XFceでインストールすると、KDEコンポーネントを使わない設定となるため(これを変更するのはなかなか大変)、全体に動作が軽く、安定している。e440程度の性能であればこのほうが良いかもしれない。

RT8168

ThinkPad e440に搭載されているのはLinuxでの扱いの難しいRealTek製WiFiチップRT8168だ。

XFceの場合はmhwd-kernelで自動的にこのドライバを含み、適切に動作するが、RT8168にはRT8169ドライバをロードしてしまう、という問題があり、mhwd-kernelによる新カーネルインストール時にもその回避を勧められる。

# echo "blacklist r8169" > /etc/modprobe.d/r8169_blacklist.conf

およその作業記録

# pacman-mirrors -g #ミラーを並び替える
# yaourt -Syuu --noconfirm # アップグレード
# mhwd-kernel -i linux46 # Linux 4.6カーネルのインストール(現在の最新)
# echo "blacklist r8169" > /etc/modprobe.d/r8169_blacklist.conf # RT8169モジュールの無効化
# reboot
$ yaourt -S gvim vi #viがないため、visudoなどが使えない
$ sudo visudo # パスワードタイムアウトの無効化
$ sudo vim /etc/yaourtrc #ビルドディレクトリ、エクスポートディレクトリなどの変更のため
$ yaourt -S medit geany geany-plusings ruby ruby-docs zsh mate-gtk3 qterminal lxqt leafpad #エディタ及び諸環境のインストール
$ yaourt -S mate-extra-gtk3 #一部conflictがあるため、全コンポーネントはインストールできない
$ yaourt -S adobe-source-han-sans-jp-fonts ttf-ohruri ttf-komatuna ttf-meguri ttf-migu ttf-ricty ttf-vlgothic tth-vlkoruri #フォント周り
$ mkdir ~/.config/fontconfig
$ medit !!$/fonts.conf #フォント設定
$ yaourt -S sshfs
$ yaourt -S xf86-input-synaptics #Touchpad Synaptics
$ sudo cp /usr/share/X11/xorg.conf.d/70-synaptics.conf /etc/X11/xorg.conf.d #設定ファイルのコピー
$ sudo vim !!$/70-synaptics.conf # Synapticsの設定
$ yaourt -S vivaldi-snapshot opera-developer chromium google-chrome chromium-widevine #ウェブブラウザ
$ yaourt -S atom-editor-git #Atom。時間がかかる
$ yaourt -S --noconfirm fcitx fcitx-anthy fcitx-mozc-neologd-ut fcitx-kkc fcitx-gtk{2,3} fcitx-qt{4,5} fcitx-m17n fcitx-configtool # IM関連
$ yaourt -S w3m lv #日本語環境向け
$ yaourt -S xorg-server-xephyr # XDMCPリモートログイン
$ yaourt -S claws-mail # メールクライアント
$ chsh #シェルをzshに
$ vim ~/.config/user-dirs.dirs # XDGディレクトリの変更
$ vim ~/.xprofile
$ mkdir bin lib mnt #個人的に必要とするディレクトリ

MDNSの設定などは最初からされている。

Synapticsの設定。2本指スクロールの有効化とナチュラルスクロール化、サーキュラースクローリング(左下起点)の有効化を設定してある。

# Example xorg.conf.d snippet that assigns the touchpad driver
# to all touchpads. See xorg.conf.d(5) for more information on
# InputClass.
# DO NOT EDIT THIS FILE, your distribution will likely overwrite
# it when updating. Copy (and rename) this file into
# /etc/X11/xorg.conf.d first.
# Additional options may be added in the form of
#   Option "OptionName" "value"
#
Section "InputClass"
        Identifier "touchpad catchall"
        Driver "synaptics"
        MatchIsTouchpad "on"
# This option is recommend on all Linux systems using evdev, but cannot be
# enabled by default. See the following link for details:
# http://who-t.blogspot.com/2010/11/how-to-ignore-configuration-errors.html
#       MatchDevicePath "/dev/input/event*"
            Option "VertTwoFingerScroll" "on"
            Option "HorizTwoFingerScroll" "on"
            Option "CircularScrolling" "on"
            Option "CircScrollTrigger" "6"
            Option "VertScrollDelta" "-111"
            Option "HorizScrollDelta" "-111"
EndSection

Section "InputClass"
        Identifier "touchpad ignore duplicates"
        MatchIsTouchpad "on"
        MatchOS "Linux"
        MatchDevicePath "/dev/input/mouse*"
        Option "Ignore" "on"
EndSection

# This option enables the bottom right corner to be a right button on clickpads
# and the right and middle top areas to be right / middle buttons on clickpads
# with a top button area.
# This option is only interpreted by clickpads.
Section "InputClass"
        Identifier "Default clickpad buttons"
        MatchDriver "synaptics"
        Option "SoftButtonAreas" "50% 0 82% 0 0 0 0 0"
        Option "SecondarySoftButtonAreas" "58% 0 0 15% 42% 58% 0 15%"
EndSection

# This option disables software buttons on Apple touchpads.
# This option is only interpreted by clickpads.
Section "InputClass"
        Identifier "Disable clickpad buttons on Apple touchpads"
        MatchProduct "Apple|bcm5974"
        MatchDriver "synaptics"
        Option "SoftButtonAreas" "0 0 0 0 0 0 0 0"
EndSection

fonts.confの設定。

<?xml version='1.0'?>
<!DOCTYPE fontconfig SYSTEM 'fonts.dtd'>
<fontconfig>
  <match target="pattern">
    <edit name="dpi" mode="assign"><double>103</double></edit>
  </match>
  <match target="font">
    <edit name="hinting" mode="assign">
      <bool>true</bool>
    </edit>
  </match>
  <match target="font">
    <edit name="autohint" mode="assign">
      <bool>true</bool>
    </edit>
  </match>
  <match target="font">
    <edit name="hintstyle" mode="assign">
      <const>hintfull</const>
    </edit>
  </match>
  <match target="font">
    <edit name="rgba" mode="assign">
      <const>rgb</const>
    </edit>
  </match>
 <match target="font">
  <edit name="lcdfilter" mode="assign">
   <const>lcddefault</const>
  </edit>
 </match>
 <match target="pattern">
  <test qual="any" name="family">
   <string>serif</string>
  </test>
  <edit binding="strong" name="family" mode="assign">
   <string>Ohruri</string>
  </edit>
 </match>
 <match target="pattern">
  <test qual="any" name="family">
   <string>sans-serif</string>
  </test>
  <edit binding="strong" name="family" mode="assign">
   <string>VlKoruri</string>
  </edit>
 </match>
 <match target="pattern">
  <test qual="any" name="family">
   <string>sans</string>
  </test>
  <edit binding="strong" name="family" mode="assign">
   <string>VlKoruri</string>
  </edit>
 </match>
 <match target="pattern">
  <test qual="any" name="family">
   <string>monospace</string>
  </test>
  <edit binding="strong" name="family" mode="assign">
   <string>Migu 1M</string>
  </edit>
 </match>
 <match target="pattern">
  <test qual="all" compare="not_eq" name="family">
   <string>sans-serif</string>
  </test>
  <test qual="all" compare="not_eq" name="family">
   <string>serif</string>
  </test>
  <test qual="all" compare="not_eq" name="family">
   <string>monospace</string>
  </test>
  <edit name="family" mode="append_last">
   <string>Migu 1C</string>
  </edit>
 </match>
 <dir>~/.fonts</dir>
</fontconfig>

.xprofile。日本語入力関係ほか

#
# ~/.xprofile
#
# sourced by /etc/lxdm/Xsession
#

if which dbus-launch >/dev/null && test -z "$DBUS_SESSION_BUS_ADDRESS"; then
    eval "$(dbus-launch --sh-syntax --exit-with-session)"
fi

# Environment variables
#
export GTK2_RC_FILES="$HOME/.gtkrc-2.0"
export GTK_IM_MODULE=fcitx
export GTK2_IM_MODULE=fcitx
export GTK3_IM_MODULE=fcitx
export QT_IM_MODULE=fcitx
export XMODIFIERS="@im=fcitx"
export DefaultIMModule=fcitx
export PATH=$HOME/bin:$PATH
setxkbmap -model jp106 -layout jp

メインマシンをZ400からGodavariに戻して3画面にする

変更

昨日、GodavariマシンのグラフィックドライバをプロプライエタリなCatalystからオープンソースのAMDGPUに変更したが、だいぶ安定している印象なので、メインマシンをそちらに戻した。

Z400とGodavariはマシン選択としては結構微妙で、Z400は

  • 性能が1割程度高い
  • 画像・映像処理は2-3倍くらい速い
  • 全体的に安定している
  • 全体に帯域が広い
  • Intel CPUということもありDTM環境が正常に動く

一方Godavariは

  • 3画面出力が可能
  • 規格が新しいのでUSB3.0をはじめ新しいハードウェアがサポートされている
  • 最新のRCカーネルでもCPUが機能的に対応していないと文句を言われることがない
  • Z400のドライブ数6に対して8と多い
  • インターフェイス的に拡張性で有利。外部インターフェイスそのものも多い
  • 動作音が静か

安定して動作するのであれば3画面をとってメインをGodavariにした形だ。
処理性能をうまく使って分散できると全体のパフォーマンスは向上するかもしれない。
このマシンでやらざるをえないScrubの時間が伸びるのが不安だが。

FHD 3画面

うちの環境は変則的な配置で計5画面がセットされているが、通常利用可能なディスプレイはFHDが3台だ。

  • LG 22EN33
  • LG 22EN43
  • SAMSUNG S22B300

いずれも低価格帯のものだが、21.5インチのFHDの液晶ディスプレイである。インターフェイスはLG 22EN43がHDMIを備える以外はDVI-DとVGAを備えている。

LGのものは画質も悪く、INPUT切り替えが極めて遅い(特に信号がないチャンネルを経由する場合はものすごく遅い)。ついでにいうとサポートの対応が極めて悪い。視野角も狭く、色も明らかにおかしい。はっきりいって、とても気に入らない。

サムスンのものは、視野角が広く色味も良い。画面は綺麗だし、最低限の機能ではあるが、使いやすい。
ただし、スタンドは完全な固定で、しかもVESAマウントもないためアームも使えない。

これまでは左右で(DVIと、DP-DVI)左がプライマリだった。
基本的にどのような配置にしても、結局左側ばかり見てしまう。左右均一に見られるようになるまでは結構なトレーニングが必要だ。

トリプルにした場合、左をプライマリにすると間違いなく右ディスプレイは見られない。
真ん中(サムスン)をプライマリにするしかないが、ここで思わぬ問題。

FM2+Killerのディスプレイ出力はHDMI, VGA, DVI-Iで、かなり配置は固定されてしまう。
この都合でサムスンはVGA接続なのだが、もともと画面がゆるめなサムスン、VGA接続だとすごく滲む。
プライマリが滲むというのは、ものすごく気になる。結局、Z400のディスプレイが真ん中をとばして左右になってしまうが、サムスンと22EN33の接続を両方とも入れ替えた。

トリプルってどうなの

一言でいえば難しい。
プライマリディスプレイが正面にあるわけで、今までよりも左右どちらも見えなくなった。

隠さなくても切り替えて使えるというメリットはもちろんあるのだが、一覧できる情報量は減ってしまった。

また、配置についても、頭を囲むように角度をつけて配置したほうが一覧性が上がる、と考えていたのだが、実際はフラットに近づけるほうが情報を把握できる。

当たり前だが、画面に接近するほど視野は狭くなり一度に入る情報量は減る。

そう考えると、一覧性からいえばウルトラワイドディスプレイが良さそうに思える。
あちらは縦はFHD相当だが、横はFHDの2倍ある(4kと同じ)。
幅が随分と必要になるが、ウルトラワイドディスプレイ2枚というのも選択肢なのかもしれない。

もし、並列作業があまり得意ではないが情報の一覧性を向上させたいのであれば、マルチディスプレイよりも4k1枚にしたほうが明らかに捗る。

もし、FHDから4kにした場合に液晶一辺の長さも倍になるのであれば、情報量は単純に4倍と考えていい。
しかし、そうでないのであれば4倍には到達しない可能性が高い。それでも、ひとつの画面となり、見やすくなることでデュアルディスプレイよりも情報量は増えたと感じるのが一般的であるようだ。

もちろん、この問題はコンテキストスイッチとは別に考えなくてはいけない。

例えば資料をみながら作業をするような場合に、作業側をみなくてもブラインドでできるが、資料は見なくてはいけない状態だとしても、単一のディスプレイで資料だけを広げていると(Windows、あるいはそれに類する挙動を示すウィンドウマネージャでは)資料を最大化して上にしたままでは作業することができない。
さらに、トレーダーがよく行うように複数の情報を監視しながら作業するのであれば多数の情報が一覧できる状態でなくてはならない。こうしたことが並列性としてのニーズであり、実際にアクティブに利用されている「作業空間」として使用するためには訓練が必要になる。

一方、単純に複数の情報を切り替えながら行うために、ウィンドウ出し入れの切り替えではなく視線移動で行うことで効率化したいというのがコンテキストスイッチだ。例えば、ニコニコ生放送をみながらツイッターしたい…といったことでもそうだ。典型的にはドキュメントを開いたままプログラミングというのがある。
切り替え時間がつまり、またその際に目に入れておくことができることで情報をロストしにくく、結果的に効率をあげることができる。
ウィンドウが増えればスイッチのコストがあがるため、余計に大きくなる。

つまり、必ずしも同時に視界に入っている必要はないのだが、意識されていないと同じディスプレイでのウィンドウスイッチで済ませてしまい、切り替えるのにもそれなりに慣れが必要になる。

いずれにせよ、枚数が増えるというのは結構な難易度増であり、シングル→デュアル→トリプルと増えるにつ違って著しく使いこなすのが難しくなる。
ただし、定期的にアクセスしている、あるいは状態を確認する必要のために結局常にひらいておきたいウィンドウというのはあるわけで、そのためにウィンドウが一枚使われてしまい、そのウィンドウに専有されないことで作業効率が上がったりもする。

ディスプレイ枚数を増やすと即ち作業効率があがるということはなく、PCの性能同様、それを使いこなすだけの腕があるかという問題が生じる。だから、それを踏まえてサイズと解像度を選択するほうが効率は簡単に上がる(もちろん、ウィンドウを並べるくらいのスキルはある前提だ)。

VGA

VGAは長らくコンピュータで使われてきたアナログ端子である。

デジタル表示を行う液晶ディスプレイにアナログインターフェイスをもちいるというのはかなり理解に苦しむ。そもそもディスプレイ描画はデジタルで行っているわけで、アナログインターフェイスで出力するからにはD/A変換を行っているわけだ。CRT(ブラウン管)なら表示がアナログなので、アナログ信号をそのまま表示にすればよく、取り扱いが簡単なのでそれで良いとしても、液晶の場合点描であるから結局A/D変換が必要になる。

最初から最後までデジタルなら別に変換がいらないのに、途中をアナログにするせいで2回変換するので非常に無駄だ。もちろん、液晶ディスプレイ普及とともにDVIが一般化したのだが、なぜか根強く残ってしまい、残っているからには対応せざるをえないということで、DVI2個にしてくれれば良いものをDVI+VGAにしたりして苦慮させられている。

2015年に終了した、レガシーインターフェイスである。

さて、VGAについてだが、多かれ少なかれ液晶に表示してもCRTのようなぼやっとした画面になる。ディスプレイによってその度合いは大きくことなり、今回の場合はサムスンのディスプレイはVGA入力ではにじみがひどく、文字が読みづらいレベル。LGのものはそこまで気にならない。

ビデオを表示している分にはVGAのみづらさというのはそこまで目立たないし、TVを観るためという人にとってはそれほど重要ではいなのかもしれないが、文字をみる時にはVGAは明らかに読みづらい。高解像ディスプレイで文字を小さくしている人にとっては、一段とその読みづらさが目立つ。

ビジネス用コンピュータではずっとVGAのみ採用ということが続いてきたが(NVSで、変換アダプタはVGA*2という状況)、VGAで事務作業はものすごく向いていないと思う。

学び

  • ディスプレイ解像度の向上は多かれ少なかれ作業効率に寄与するが、その度合いは条件による
  • ディスプレイサイズの向上の作業効率への影響は条件による
  • ディスプレイの枚数増は使いこなすのにスキルが必要。トリプルになるとかなり難しい
  • ディスプレイ枚数を増やすよりはより大きくドット数の多いディスプレイにかえるほうが有効
  • 特に文字作業の場合はVGA接続をやめるだけでも効率あがるかもしれない
  • ディスプレイの配置は大事。作業効率に影響する。マルチディスプレイならなるべく視線にフラットなほうがいい
  • 安いディスプレイと高いディスプレイにはかなりの差がある
  • LGはやめておこう

AMDGPUドライバーを試す

AMDGPU

Catalystドライバーの出来がよくないので、そして一向によくならないので、デキが良いと評判のamdgpuドライバーを使ってみることにした。

AMDGPUドライバーは、mesa上で動作するオープンソースドライバーであり、ベンチマークテストではCatalystには及ばないが良好な成績を収めている。
実験的だが、AMDGPUドライバー上でカーネル/Xバイナリに依存しないプロプライエタリドライバーを使用するAMDGPU PROドライバーも存在する。

インストール

Manjaroではcoreにmhwd-amdgpuが含まれているが、本体はextraにあるxf86-video-amdgpu。

なお、AURにあるAMDGPU PROは軒並みOUT OF DATEになっている。

VDPAUおよびVA-API

勝手に有効化されるため、$VDPAU_DRIVERは無効化する。

VA-API設定は環境変数として

LIBVA_DRIVER_NAME=gallium

VLCでは出力設定をVDPAUではなく、OpenGL GLXビデオ出力(XCB)に設定しないとビデオによってはエラーを吐き、動作しない。
画像が乱れる場合もあるが、VLCではありがちなことと理解している(Quadro+nVidiaでも同じだから)。

Flashのアクセラレーションも/etc/adobe/mms.cfgの

EnableLinuxHWVideoDecode=1

で動作する。

Cinnamon 3D

特に設定しなくても問題なく動作する。

マルチモニター

テストの限りではカーソルの歪みはない

Skype

テストできず。

Cinnamon 3.0.1, Linux 4.6 RC4

Cinnamon 3

Manjaro Update 2016-04-26でCinnamonが3.0.1になっていた。リリースでは触れられていないけれど…

これで結構変わっていたので、ポイントを挙げておくと

  • ダイアログ表示がフェードイン/フェードアウトアニメーション追加
  • 警告音がぽこぽこに変更された
  • テーマ設定でコントロールがかなりの部分使えなくなった
  • Dropboxが0秒起動だとsystrayに入らなくなった
  • Mail.ruは自動起動でsystrayに入るようになった

ダイアログがフェードインするようになったのは非常にかっこいいが、Fcitxのサジェスト/プレエディットもフェードインするようになり、実用性が明らかに低下した。このあたりは開発者は意識しないのだろう。(Fcitxを使うようなことがないだろうから)

Cinnamonは機能はシンプル、特に設定項目は少ない。デスクトップエフェクトもほとんど選択できないし、ショートカットの設定も少ない。

だが、非常にツボを抑えた機能を持っている。

例えば、クイックタイルはシンプルにSuper+Cursorであり、現在位置を基準にしてタイルする。Super+Leftは非タイルなら左にタイルし、右タイルならフローティングする。

PAアプレットではサウンド出力先を一括で変更できる。この機能で変更した場合カスタマイズされた設定に戻すのが大変なので使用していないが。

他にも

  • ネットワークアプレットによる切り替え・切断が加担
  • ウィンドウのボタンは配置も任意に設定できる
  • ウィンドウコーナー機能もある
  • デスクレット機能
  • 拡張機能(ほとんど正常に動作しない)
  • 通知のオンオフ
  • サブメニューを持つsystrayアイテムはスライド式で階層化される

軽量で安定していることもあって(さらには高速でハードウェアアクセラレーションも使用することもあって)、本来はPlasmaを利用したいと思いつつ、Cinnamonから抜けられないのもこうしたことからだろう。

Linux 4.6 rc4

Linux 4.6 rc2においては、Godavariマシンでは問題がなかったものの、Nehalem-WSマシンでは

  • btrfsマウント時に大量のメッセージが表示される(RAID6のベンチマーク?)
  • シャットダウン時、dmなどが閉じられず電源停止に至らない
  • オーディオデバイスの入力が大量のノイズで埋もれる

といった問題が生じていた。

だがこれらはRC4で解決した

btrfs関連の修正も既に多く入っており、非常に期待できる。相変わらずのいい仕事だ。

Xリモートログイン

うちにある練習機は、Pentium M 1.70GHz, 512MB RAM, 40GB SATA1 HDDという非力なラップトップだ。

一方、予備環境は32GB RAMを備えるGodavariマシンなので、明らかにそれを活用するのが正しい。
ただ、デスクスペース的にGodavariマシンの前に座ることができない。

そこで、リモートデスクトップでGodavariマシンを使いたいと考えた。

XDMCP

XDMCPは、昔からある「X serverを使ってリモートデスクトップ」。

ふたつのX serversを接続し、ターゲットのX Clientが描画する領域をXプロトコルで端末へ転送する。XDMサーバーは要求・操作を仲介する。

リモートデスクトップでリモートコンピュータに「ログインしたい」場合は最も簡単な方法として「ログインする画面から画面をとばしてもらえば良い」わけで、それを実現するのがXDMCPだと考えていいだろう。

LightDMでサーバーセットアップ

ものすごく単純な話で、/etc/lightdm/lightdm.conf

[XDMCPServer]
enabled=true
port=177

のようにする。

Manjaroは標準(XFceイメージ)ではLightDMを使用する。KDEイメージはKDMなので、あまり安定していないらしい。
LightDMが最善なもよう。

クライアント

XnestかXephyr。

なぜかログインできないというトラブルが多発したが、結局はXFceならログインできた。(最初はログインできなかった)

Xephyrのほうが使いやすい印象だ。なんといってもフルスクリーンが可能(-fullscreenオプション)。また、VNCと違い、端末側が解像度を指定できるというのもメリット。

$ Xephyr -query 192.168.1.17 -screen 1920x1080 -br -reset -terminate :1 -fullscreen

LightDMセッションにおいてのみ、キーボードがUSになっていた。

遅い

リッチな環境であるVNCやRDPよりもXクライアントひとつ飛ばすだけで重いときいてはいたが、画面全体を飛ばすXDMCPだと、1GbEでも動画再生はきつい。

セキュリティ

覗かれる、という問題は、SSH経由でのXDMCPは無理なようなので、どうしようもない。

その他の選択肢

NX

良好なパフォーマンスを得る方法として、NXが挙げられている。

NXはNoMachineのFreeNXが昔話題になったが、その後の選択肢としてはGoogleのNeatX、あるいはnxagentといったところのようだ。

AURを見ると、nx-allなど、OUT OF DATEフラグが立っているがFreeNXもあるようだ。

x2go

x2goは最近話題のようだが、XとSSHということなのだろうか。

VPS相手にできるようだから、パフォーマンスは良いのかもしれない。

Waylandの場合

Waylandはこうした機能がなく、リモートレンダリングサーバーがあれば良いとしているらしい。

X.OrgをWayland上で動かせば実現するけれども、新しく作りなよ、ということらしい。

Waylandは今どうなっているのだろう。

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で効率が向上する、ということは残念ながらない。