Vivaldi 2.0

Vivaldi ウェブブラウザのバージョン2.0がリリースされた

動画にキレイな日本語字幕が入っていたりしてとてもいい感じだ。

Vivaldiは1.15から2.0に上がった形になる。 初期は不具合もそれなりに多く(それでも初期としては非常に良い出来で期待はできたが)開発者も少なかったので先行き不安なところもあったが、今やちゃんとしたブラウザになった。 今回の修正ではAltの無効化が大きい。VivaldiはAltがキャプチャされても(例えばスクリーンショットとか)メニューを開いてしまうので、この問題が(正しい解決方法ではないが)解決されるのは非常に嬉しい。

Vivaldの成り立ちは若干複雑で、Operaがコミュニティを捨ててただのChromiumに成り下がったことに納得が行かない人たちが出ていって作ったブラウザだ。 ところが、VivaldiはChromiumのフロントエンドでしかないし、コミュニティ機能のほうも当初から随分後退して「よくある程度よりも消極的」というレベルまで落ちてしまっている。

ではVivaldiに価値がないのかというとそんなこともなくて、中国企業に買収されたこともあってか不透明な振舞いを繰り返すOperaや、不信感を煽るような行為の多いGoogleと違ってクリーンでオープンという空気は保たれている。 Mozillaも多分に政治的になってしまっている現状において、Vivaldiは数少ない信頼できるオープンなブラウザだと見ていい。 このあたりはTakaakiさんのブログで詳細に説明されている。 また、マイナビの記事もなんとなくその空気が分かる。

また、VivaldiはChromiumをベースとしたブラウザとしては非常に珍しく、フロント部分はほぼ自前になっている。 Braveなどもそうなっているけれども、これによってVivaldiだからこそ使える部分も大きい。なにより、プライバシーを脅かすかもしれない要素は廃してコストをかけて自前で用意するあたり気合が入っている。

以前独自エンジン開発も辞さず、みたいな記事があったような気がしたけれども、それは見つからないので置いておこう。

この素晴らしいブラウザは使うほどに手に馴染む。 もしまだ使ったことがないという人がいたならば、ぜひ一度使ってみてほしい。

DPIと画面サイズとスケーリングとピクセルの話

概念の確認

今やあまり意識されることはないのだが、改めて言うと

  • ディスプレイは多数のドットからできている
  • 1インチ辺あたりいくつのドットがあるかというのがDPIである
  • であるから、DPIというのはXYがある。 ちなみに、ThinkPad X1 Carbon 2017は143x158DPIである。 (ppiといったりもする)
  • このためドットの実寸(正確に言えばドット間隔の実寸)はドット数が多いほうが、そしてディスプレイサイズが小さい方が小さくなる
  • ドット数が一定である場合、ディスプレイが大きくなるほど密度(解像度)は下がる
  • 逆にディスプレイサイズが一定である場合、ドット数が増えるほど密度(解像度)は上がる
  • ピクセル数はディスプレイ表示上の絶対数で、その実寸は変動的
  • cm, inch, mmといった単位は実寸上の絶対値で、実際に何ピクセルで描画するかは変動的
  • ラスターグラフィックス、あるいは固定的ピクセル数で描画されるUIは解像度が向上すると実寸としては小さくなる
  • ベクターグラフィックス、あるいは固定的実数値で描画されるUIは解像度が向上すると描画に使用するピクセル数が増加する

論理上の振る舞い

もともとWindowsは96dpiに固定的に設定されていた。 つまり、実際のディスプレイのDPIがどうであるかということに関係なく 1inch = 96pixels という計算をしていたわけだ。 これにより実数をピクセル数に変換していた。

このことから、また固定的ピクセル数でUIが書かれていたことも相まって、基本的に「解像度が上がるとありとあらゆる部品が小さくなる」という現象が起きていた。 Macも72dpiに固定されていて、同じような事情だった。

Windowsは可変値だが、現在Macは72dpiとして計算しつつ、1ポイントは2pxで表示するように変更された。

正しいのは明らかに正しいDPIを設定できるようにすることである。 というよりも、ディスプレイサイズとピクセル数がわかっていれば正しいDPIが算出できるはずだ。 ディスプレイサイズを論理サイズ(24インチとか)から算出するのは難しいが、そもそもどの製品も同じではないので、メジャーで測れば1分もかからない話だ。

実際、Linux(Unix)においてX Window Systemはそのような方式を取っている。

そしてその上で実寸値で指定するか、あるいは画面に対する相対値で指定すれば画面密度によらないスケーラブルな指定が可能だ。

一般的にウェブUIはピクセル数で指定されている。 文字のような流動的情報はインチで指定するほうが一般的だが、これに従うと高解像度ディスプレイではUIは小さいが文字の大きさは正しくUIに書ける文字が減る、ということになる。

現実のスケール

ところが、現実はそうなっていない。

仕方ない部分もある。 例えばパソコンの場合は、13インチでも15インチでも、21インチでも24インチでも「だいたい100から115dpi」あたりに落ち着く。

これを基準にすると、5インチやそこらで400dpiを越えるスマートフォンが困ってしまう。

これは、パソコンを基準に実寸値で表すと、例えば「幅10インチのウィンドウ」といった場合、5インチのスマートフォンでは2画面分の幅があるすさまじく見づらいUIができあがる。

対してピクセル数で表すのもかなり危険だ。 例えばMimir Yokohamaのウェブサイトは900px幅であり、FullHD液晶の場合半分よりちょっと小さいくらい1なのだが、例えば手元のAxon7の場合WQHDなので幅は1440pxある。だから画面の幅の1/3くらい、実寸では5.18cm = 2.03937inchだが、900pxというと3.2375cmになる。

3.2375cmのウィンドウ、しかもサイドバーつき。視点から近いといってもあまりにも小さい。

スマートフォンをパソコンと同じ基準にするのは、実寸値だろうがピクセル数だろうが、かなり難しいわけだ。

じゃあどうしたか、というと、1px=1ピクセルじゃなくしてしまった。

なにを言っているか意味がわからないだろう。

実はMacも同じで、「1ポイントを2ピクセルで描画する」といったが、実はMacでは「1ピクセル指定しても実際は2ピクセルで表示する」ようになっている。 「密度が高いから従来の倍で表示しちゃおう」というわけだ。実際、Retinaディスプレイは180dpiとかあるので、従来のラスターUIをベクターUIのように扱って144dpi相当で描画されることはそれほど困らない。

技術に明るくないウェブエンジニア諸兄はCSSにこんなことを書いているかと思うが

何も疑問に思わないのだろうか。 1080pxをこえているならスマートフォンでは満たさない可能性が高いが、799pxなら今のスマートフォンは大概満たしているだろう。 だが、実際スマートフォンでこれが適用される可能性はかなり高い。

基本的に現代では96dpiを基準にスケールしている。 つまり、実際には180dpiくらいあるディスプレイなら、1ピクセルを倍で描画する。言い換えると、あたかもピクセル数が半分しかないディスプレイであるかのように扱う。

これは正しいのだろうか?

実際は、結構困る。 というのは、UIでピクセルで指定できない場合というのは普通にあって、この場合画面全体のピクセル数は「本当のピクセル数」を回答する。 これに基づいて割合を決めてピクセル数指定すると実際ははみ出してしまったりするのだ。

また、例えばThinkPad X1 Carbon 2017だと約1.4896倍にスケールする2のだが、900pxは1341px、1080pxは1608pxで表示されることになる。 ディスプレイ全体では1920pxなので、もちろん画面には収まるのだが、タイルした場合は1341pxは画面の半分に収まらないのでサイドバーは表示されなくなる。 「タイルしたときにはギリギリサイドバーが表示されたほうが良い」という私の考えは無碍にされてしまうわけだ。

これは12インチクラスのモバイルラップトップだとさらに厳しい。ThinkPad X280は12.5inchなので計算上は10.9inch->176dpiとなり、 12.1inchのLet’s Note SZに至っては10.5inch->182dpiとなる。 この計算においては、ThinkPad X280の場合幅1047px扱いとなり、1080pxですら満たせない。Let’s Note SZに至ってはギリギリ1000pxを満たす程度だ。

色々難しいのには理解を示したいところだが、現実問題としてこれは望ましくなく、「自分に使いやすい嘘DPIを設定する」以外になくなってしまう。

また、この事情により、以前はスケーリングを想定してフォントサイズはピクセル数からポイント数へと動いてきたのだが、 現在はスクリーンフォントはピクセル数で指定したほうが柔軟にスケールしてくれたりする。

個人的な所感

嘘DPIを設定するようでは、せっかくDPIが設定できることが無意味になってしまうし好ましくないと思う。 そもそも、96dpiを基準に固定したまま何倍にしよう、というのはVGA時代の失敗の繰り返し以外の何者でもないとも思う。

おおよそ正しいアプローチなのだから、DPIとスケール倍率という概念を分離できなかったものか。

実はGNOMEはDPIの設定がなくて、DPIを一切尊重しない。 そのかわり

$ gsettings set org.gnome.desktop.interface scaling-factor 2

のようにしてスケールできるのだが、このスケール、整数しか指定できない。 せめて1.5を指定させてくれとものすごーく言われているのだが(13.3inch, 14inchクラスでFullHDだと140から150程度なので1.5がちょうどよい)、対応の気配はない。

一方、KDE PlasmaはGTK+アプリケーションであっても適切にスケールしてくれるが、あくまでDPIによって自動的にスケールするだけで倍率の指定はできない。

現状で理想的なのは

  • DPIは正確なDPI値を算出する。この状態ではinchやcm指定は厳密に適切な値で表示される。 グラフィッカーには便利な状態
  • これによって自動的にRASTER_SCALEACTUALSIZE_SCALEが表示として倍率として設定される。これによって現在と同じ状態になる
  • RASTER_SCALEはディスプレイの論理ピクセル数に影響する。 つまりRASTER_SCALE=2の状態でFullHDディスプレイなら、水平ピクセル数は960だと回答する
  • RASTER_SCALEを手動設定可能とする。ユーザーは自動設定された値(デフォルト値でもある)を基準に好みに合わせて動かす。これに伴うディスプレイの論理ピクセル数も表示すると親切。
  • グラフィッカーのためにACTUALSIZE_SCALERASTER_SCALEと切り離して設定可能とする。ACTUALSIZE_SCALE=1にすれば1インチは1インチで正しく表示してくれる。

だと思うけれど、きっと誰も聞き入れてくれないだろう…

なお、4kディスプレイにしたWindowser向けにアドバイスとして「このままだと文字が小さいので解像度を1920×1080に設定すると解決するよ」と言っているのをかなり見るのだが、もはやこれは頭痛が痛い…


  1. 「半分よりも小さい」のは、フルHDディスプレイでタイリングしたときにサイドバーを表示させるためだ。

  2. これは、X Window Systemで正確なディスプレイサイズを入力し、精密にスケールできるKDE Plasmaを使った場合の話である。

Windows 10について

悪名高いWindows 10をある程度使ってみている。
とりあえず、それで思ったことをまとめてみよう。

OSとしての進化

一般の人の中にはOSの進化を頑なに認めない人がいるが、元々Windowsが(それ以前にMS-DOSが)ひどい代物である以上、修正すべき点は多い。低い生産性は人類の進歩を妨げさえする。

だから、Windowsはどんどん改善してもらわないと困る。

純粋にOSとしての点をみれば、それが正しいかどうかはともかく、かなり良くなっている。
「ここはこれがおかしくて、こうあるべきだからこうしてほしい」という点は山ほどあるのがWindowsだが、その望まれているあるべき解決方法ではなく、なぜか全然違う方法で提供して、「なんでそうなった!」と突っ込まれるのは恒例なのだが、今回もそのような変更点は非常に多い。

いつまで経ってもfork(2)をサポートしないこととか、まともなシェルを用意せずに、明らかにシェル、端末として使いようのないPowershellを導入したまま放置していることとか。

私はWindowsアプリは書かないし(書くとしてもクロスプラットフォームレイヤ上で)、コアな開発者でもないため感じることは少ないが、「クロスプラットフォームレイヤのWindows環境下での制約」という形で困る。

そういう内部的なことは置いておくとしても、Windows7以降で改善された点として

  • ISOファイルのマウントが可能になった(Win8)
  • 通知機能がまともになり、通知履歴が見られるようになった
  • すべてのUI部品が(一部は仮想的に)スケーラブルになった
  • Win + cursorによるquick tile機能が8方向タイルに対応した(現在位置に基づくタイル。Cinnamonと同じ)
  • IMEスイッチャが搭載された(Windows+Space)

使い勝手

Windows 10の使い勝手そのものは改善しているといっていい。

UIについて考えてみると、基本的な部分はWindows XPの時点で既に完成されていた。Windows 95の時点で基本的な部分はできあがっていたが、見た目がチープであることと、たどりにくい階層構造が難点だった。
Windows XPではテーマ制を導入(Visual Styleの変更はパッチ当てが必要)、簡易なものではあるが、デスクトップ検索も追加している。
また、ウィンドウのタイル表示も可能になった。

Windows Vistaでさらなる改良が行われたが、本質的な進化というよりも、変化であるという面も大きかった。
Windows 7でアイコン式のタスクバーになったが、これも元よりそうであるべきだったというものではない。選択できるなら機能追加だが、選択できないので単なる変更だった。

明らかに改良された点は検索機能が強化され、ポータブルアプリの起動にランチャが不要になったという点だが、スタートメニューの構造やタイルの仕様変更などは、変更でしかないように感じられた。

ちなみに、Windows 7からはWin + Cursorによるquick tileが可能になった。ただし、Windows 7では左右のみだ。

Unix系デスクトップはこの時期、何を取り込んだのか先行したのかわからない機能を数多く導入している。quick tile機能はKDE4, Cinnamon 1.0の導入なので恐らくWindows 7のほうが早い。入れ替え式階層メニューはWindows Vistaが早いが、KDE Plasma 4のものはまた違うし、Cinnamonもさらに違う。また、MacのExpose相当の機能はCompizが入れたため、Windowsよりも早い。

だが、Unixデスクトップで考えても、機能的にはGNOME 2あるいはKDE3で既に完成していた。これらはWindows 95のUIを参考に発展したものであり、その後は細かな機能追加に過ぎないと感じている。

変化を求めている部分もあるし、変化に応じている部分もある。だが、どちらかというと、Microsoftは変な先読みをしている、というよりも自分がスタンダードを作るのだという妙な気負いがある。

それが、Windows 8でのスタートメニューを廃止してModarn UIを導入したことにあらわれているのだろう。奇抜だが、真新しさの演出と、Windowsがやればそれが普通になる、という考え方に基づくのだと思う。

結果として失敗した。実際に問題点が多く、使いにくかったということもあるが。

Windows 10のスタートメニューはその修正だと考えていい。スタートメニューとModarn UIを一体化させたものは、確かにある意味では使いやすいが、目新しいものであるというよりは、Androidスマートフォンで見慣れたものになった。

Windows 8からのフラットUIもより推し進めてはいるが、やはりデザイン的にリッチさに劣るように(個人的には)感じられるし、特に見やすくなったわけでもないため、単なる変更だろう。

機能が一体的に提供されるようになったために、それに従うかどうかだが、「Microsoft製のOS(Windows)で、Microsoftが推奨する音声エージェント(Cortana)を使用し、Microsoftのサーチエンジン(Bing)を介して、Microsoftのブラウザ(Edge)で開く」のであれば使いやすいのだ。

だが、これはAndroid同様のリスキーな面を持っている。

ケータイ化・個人情報商売という悪夢

Windows 10において問題なのは使い勝手ではなく、この2点だ。

Windowsは統合的な環境になった。基本部分ではなく、ユーザーのすべてを「Windowsが」提供しようというのだ。

そこには、メールやスケジュール、あるいはSkypeやTwitter, LINEさえも含まれる。
WindowsストアアプリはWindowsから独立ではなくなった。言い換えると、Windowsストアアプリに提供されている情報はMicrosoftにも与えられる、という形になった。

Windowsに、言い換えればMicrosoftに依存して生活するのであればこれは便利な機能だ。もちろん、Windows Phoneも一緒に。検索エンジンはBingだ。

だが、これはありとあらゆる情報的ライフライン及び情報そのものをMicrosoftに掌握させることを意味する。事実、Windwos 8.1ではデフォルトでオフだった、利用状況や入力内容の送信など、プライバシー上重大な懸念のある機能が、全てオンの状態になるようになった。

しかも、コアな利用状況のレポートは、送信をオフにするとWindowsが動作しないという理由をつけて、必ず送信させる。

ありとあらゆる情報を収集し、個人を監視するような行動は、これまでGoogle及びAppleがとってきたものだ。それと比べるとMicrosoftは穏やかなやり方をしてきた。

だが、今回Microsoftは積極的にプライバシーを手に入れようとしている。Web, Twitter, Facebook, Skype, LINEはもちろん、電話からメールまで全てだ。

それに合わせて規約も、メールの内容を読むというものになった。
また、利用には基本的な部分でMicrosoftアカウントと紐付ける必要がある。完全に個人を特定し、追跡できるようにするものだ。

これらのプライバシーに対する重大な懸念を、私は今回最も問題視する。

また、ケータイの場合はそうした統合的な機能を求める傾向があるのだが、Windows 8で学んだはずの「スマートデバイスとの融合は不自由を生む」ということを無視して、より融合を進める方向になった。

電話だのSNSだのといった機能は、Skypeと連動させることでパソコンでも利用可能なのかもしれないが、明らかにコンピュータの使い方としてそれは重要な部分ではない。それを中心に据えられるのは非常に迷惑だ。

また、パーソなりゼーションを進め、SNSの情報を常に表示し、ニュースを表示し…といった機能は、ビジネスシーンで使われるWindowsということを一切無視しているとしか思えない。

その意味で、ものすごく使いにくくなった。

KDE Plasmaも、KDEアプリケーションを使ってこそという部分はある。KDE PIMとAkonadiだ。
だが、使わないという選択肢はある。その場合、Plasmaを使う魅力は大いに損なわれてしまうのだが、普通のデスクトップ環境としては使うことができる。

今回のWindowsは、その選択権がない。ちなみに、しょっちゅうデフォルトのアプリをMicrosoft製のものに変えられるようになった。ブラウザがEdgeにされるのは日常茶飯事だし、IMEはデフォルトを完全に無視してMS-IMEを選択する。

アカウント

Windows 10ではアカウントが、コンピュータ上のローカルアカウントとMicrosoftアカウントの二種類がある。

ローカルアカウントをMicrosoftアカウントに接続することで、ローカルアカウントとして使いながらMicrosoftアカウントを要求するストアアプリを利用するといったことも可能だ。

だが、Microsoftアカウントでは、ログイン(今回からローカルアカウントでも「サインイン」という表現になった)時にオンライン認証をする。
そのため、インターネットに接続されていなければコンピュータを利用すること自体できなくなった。

デスクトップアプリとストアアプリ

ほぼ全てのプログラムに「デスクトップアプリ」と「ストアアプリ」という区別ができた。

Windows 8にもあった区別ではあるが、ストアアプリを使う機会が設定しかないということもザラにあったため、目立たなかった。

今回、多くの機能がストアアプリに移行したため、この区別が重要な意味をもつようになった。また、ストアアプリがウィンドウ表示できるようになったというのも大きい。

これにおいて重要なのは以下の点だ。

  • ストアアプリは事実上Microsoftが全権を持っている
  • ストアアプリではIMEがストアアプリに対応しているMS-IMEしか使えない
  • ストアアプリはオンラインアカウントとひも付けて実行される

表面から消失した機能

コントロールパネルが隠されてしまっている。
これは検索から起動できる。

これは、ストアアプリの設定を使わせるということなのだろうが、全項目があるわけではなく、重複があったり、片方にしかないものがあったり、表現に整合性がとれていなかったりと非常にわかりにくくなった。

設定に関してはgodmodeも追加された。これは、コントロールパネル的なデスクトップアプリのフラット版だ。

まだ、ログオフがメニューから消失した。
Windows 10はオンラインアカウントでのログインを原則としているため、サインアウトに変更されている。

logoffコマンドが存在するため、logoffで検索すれば抜けられる。あるいは、CAD(Ctrl+Alt+Delete)からでも良い。

総括

OSとしては妥当に進化した。あまりにもスマートフォンを意識しすぎて、デスクトップコンピュータとしての使い勝手が著しく損なわれた程度で、別に悪くなったとは言わない。

全てはログインを「ログオン」という表現から「サインイン」という表現にかえたことにあらわれていると思う。

今やWindowsを使うということは、Microsoftのサービスを利用するということとイコールなのだ。

これまではWindows上で他のサービスを利用することも当たり前だった。だが、これからはそうではない。WindowsはMicrosoftのサービスを使うことを強要する。Appleがそうしたように、ロックインして競合する他のサービスの利用を不能とする可能性もないわけではない。

既に、Windowsを起動すれば当然にGoogle Chromeが起動し、Google日本語入力で文章を打ち…ということはできなくなった。Edgeに変更された設定を戻し、Google日本語入力に切り替えなくてはならない。

また、Windows上で行う作業は当然に秘密が保たれていると信じていただろう。これからはそうではない。Windows上で行う作業は、須くMicrosoftが知りうるものなのだ。

こうしたことをどのように考えるかによって、Windows 10が良いものか悪いものかの判断ができるだろう。

Mikutter

Mikutterが2.0.6になったのでアップデートするついでにプラグインを導入してみた。

Mikutterのプラグインは原則~/.mikutter/plugin/pluginnameディレクトリに導入する。このpluginnamepluginname.rbを読む仕様のため、これに合わせなくてはいけない。

ほとんどのプラグインはGitHubで管理されており、git clone URI.git ~/.mikutter/plugin/pluginnameで大体はいける。そうでなくてもそのような形式のディレクトリに一式ぶちまければいける。

しかし、当然ながらそれによって依存関係の欠如が生じる。例によってMikutterリポジトリでbundle installすればいいのだが、いくつかのGemファイルがエラー終了してしまう。少しハマったがよくよく調べてみるとruby-develが入っていないということだった。

プラグインを利用していないのでまだその効果のほどは分からないが、Userconfig Accessorはロードするとクラッシュしてしまう。

操作系プラグインはごく単純なものが多いが、これを見ると自分で書くのも難しくはなさそうだ。ただし、「何にアクセスするか」という問題は出るだろう。

しかし、個人的にはRubyスクリプトであることが非常に助かる。ローカルな対応のためにソースを読んだり、挙動を確認するためにソースを読んだりできるからだ。

Linuxトラブルとの格闘

15日、Manjaroが起動しなくなった。systemdが途中で沈黙してしまう、という症状だ。

systemdが、となるとそう簡単ではないため、とりあえずMageiaに戻ったのだが(もちろん、home directoryにおける様々な問題が生じた)、17日、そのMageiaに致命的な現象が生じた。

極めて重くなったため、topしてみると、nepomukfileindexなるプロセスが非常に激しく動いている。これはなんだ?

とりあえず再起動してみると、fork bombが発生した(konsoleが27 windows開いた)。nepomukのせいか!?

ファイルアクセスが激しいということはデータを盗み出す類のプロセスである可能性が高いと判断し、直ちにイーサネットケーブルを抜いて、別システムのインストールを行うことにした(今インシデントを扱える状況ではない)。

Manjaroを潰してSSDにMageiaをインストールすることにしたのだが、Btrfsが扱えない、LUKSをかけるとパスワードが入力できないなどのトラブルで何度も再インストールを余儀なくされた。

なお、Manjaroの再インストールもこの過程で何度もトライしているのだが、pacman-key –populateに失敗するためどうしようもなかった。どうもForumにあるこのケースと同様のようだが、相当苦戦しているで容易ならざることか。このフォーラムでも解決していないようだ。

特に注意してほしいのが、インストーラでキーボードレイアウトにJPを選ぶとJPキーボードでインストールされる。ところが、ログインするとその状態ではinput methodが何も設定されておらず、iBusはUSキーボードのレイアウトで入力させる。そのため、記号を含むパスワードを設定しているとキーボードレイアウトの違いからlogin incorrectとなる。

なお、KDMではJPキーボードでインストールしているのであれば自動的にJPキーボードの配列で入力することになり、ログインは通常通りできる。このことでだいぶハマった。

しかしセットアップしていくと、再びnepomukが顔を出す。何者なのだこいつ。

そこでrpm -qfしてみると、nepomuk, nepomuk-core, kde-coreに含まれていることが分かった。調べてみると、まっとうなプロジェクトで、それを積極的に利用している例がKDEだという。

ではあのfork bombとは別ものだったのか。あの妙な挙動は何だったのか。

分からないのだが、とりあえずは安心していいのだろうか。もちろん、virus checkもすませてあり、問題はほぼなかった。少なくとも懸念していた問題はみつからなかった。漏洩調査が必要だが、これはかなり難しい。また、汚染調査の追跡は、これから行うことになる。これもしばらくかかるだろう。パスワード変更作業などが迫っている。

ついでなので、インストール時点で/varを別に切りLVM上に置く、SSDにインストールするなどの懸案を片付けた。また、これまではhome directory(/homeとは別に、/home/user)にマウントしていたのだが、dor filesに非互換が生じることがあるため、この解決のために/home/user/shareにマウントするようにした。共有すべきdot filesをsymlinkにすることでdor filesなどの共有問題を解決し、基本的にはデータ共有とすることで問題及び影響を生じにくくした。

share下にあるディレクトリの設定上の問題(~/binなどでもある)が生じるため、従来通り~/localのpathを維持するため、~/localは../share/localのsymlinkとした。

今回の作業でよくわからない変化があった。

まず、gtk-query-updateをしてFirefoxで正常に日本語入力が可能になった。これまでなぜできないのか分からず様々な方策を試しているような状態だったのにだ。一方、meditはIMEは機能するが入力できない状態、つまり変換も確定もできない状態となっている。

Recent Linux

Skype

8/3からSkypeにログインできないという障害が発生した。Skypeを起動し、ログインしようとするとSkypeは接続できませんでしたと表示され、loginを拒否されてしまう。

これは、MicrosoftがSkypeの仕様を変更したことに伴うものと─思われ、Windowsのほうでも何かがあったらしい(詳しくは知らない)。だが、Skype for Linuxでログインできない症状はかなり長引いた。

結局は8/7にSkype for Linuxが4.2から4.3に上がっていて(アップデートがこないかかなり気にしていたので、アップデートパッケージにSkypeが含まれていなかったことはかなり自信がある)、ログインできるようになった。詳しいことは不明だ。

Manjaro

Linuxがだいぶ更新が進んだはずだ、ということでKaveri対応のディストリビューションを再び探すことにした。最大の問題はやはりeCryptFSがないことだ。そのほかCryptsetup, EncFS, lv, NKF, w3mがないのもかなり痛い。

ManjaroでKaveriを使う記事がでていたので、それを参考にインストールしてみたが、pacman -Syuでアップデートしようとすると、xdg-suのPGP keyが信用できないとしてアップデートできない。この障害のために結局はどうしようもなく塩漬けだ。

AMDの公式なドライバのあるopenSUSEで問題なく動いているという報告があるため、openSUSEをもう一度試そうかとも思うのだが…

とりあえずはEncFSとNKFをインストールすることでその場をしのいだ。

EncFS on Mageia4 x86_64

Megaia4にEncFSパッケージがないので、自分で用意した。本当はeCryptFSが欲しかったのだが、どうも難しそうなので、EncFSでとりあえず代用。

まずはpbone.netでMageia5用EncFSのsrc.rpmパッケージを入手。そしてrpmbuild --rebuildしてみるが、

download/encfs-1.7.4-11.mga5.src.rpm をインストール中です。
警告: ユーザー iurt は存在しません – root を使用します
警告: グループ iurt は存在しません – root を使用します
警告: ユーザー iurt は存在しません – root を使用します
警告: グループ iurt は存在しません – root を使用します
エラー: ビルド依存性の失敗:
rlog-devel = 1.3 は encfs-1.7.4-11.mga4.x86_64 に必要とされています
fuse-devel = 2.6 は encfs-1.7.4-11.mga4.x86_64 に必要とされています
chrpath は encfs-1.7.4-11.mga4.x86_64 に必要とされています
boost は encfs-1.7.4-11.mga4.x86_64 に必要とされています

とうまくいかない。そこでrlog-devel, fuse-devel, chrpath, boostとそれに関わるものをインストールした上で試すと無事、encfs-1.7.4-11.mga4.x86_64.rpm, encfs-debuginfo-1.7.4-11.mga4.x86_64.rpm, lib64encfs6-1.7.4-11.mga4.x86_64.rpmの3つのパッケージが生成され、インストールできた。

比較的シンプルで汎用性のある暗号化ファイルシステムで、FUSEを使う分このようなケースにおいて取り扱いやすい。