Archive for the ‘PC・技術’ Category

ブラウザはVivaldiを使っているのだが、どうにもメモリを馬鹿食いするので辟易して来た。ベースにしているChromeの作りのせいではあるのだが、普通に使っていても、気付くと全体(32GB)の半分以上のメモリを消費していることがあって(Vivaldiがほとんどを消費しているようだ)、さすがにそれは許せないと思ってきた。更に、近頃は起動後に段々重くなって、サスペンドしたタブを開く処理が遅くてイライラする。

そこで、起死回生というのか、そろそろ「古き良きFirefox」はいかがなものかと試してみた。今までに何度も試して来たのだが、そのたびにケチが付いて見送って来た。バージョンはもう60を超えており(64)、前回(2017年夏)の55から10近く上がっているので、ものすごく改良されたのではないかと期待したw

今までの主な問題は以下であった。

  • アプリの構造が変わって、必要なアドオンがほぼ全滅した。
    • そのため、縦のタブバーができない。
  • アイドル時のCPU負荷が高い。

試してみると、必要なアドオンは復活(別のものになったものもある)しており、縦のタブバーのアドオンもあって(Tree Tabsにした)、使えそうだった。CPU負荷については直っていないようで、アイドル時でも15%前後と高目ではある。ただ、良く考えてみたら、今まで見ていたCPU使用率(ps uxコマンドでの"%CPU")は、1コア(Hyper threading(以下HT)の1スレッド)当たりの値のようだ。一方、CPUはHTによって仮想8コアなので、psコマンドで出るプログラムのCPU使用率はPC全体では1/8になる。すると、例えばアイドル時に16%だったとしても、全体への寄与(増加分)は(16/8=)2%程度(HTなので、実際の負荷はもう少し大きくなりそうだ)の負荷なので、大きな問題はなさそうだ。実際、topコマンドの"%Cpu(s)"の表示にも合っている。

負荷について少し考えてみた。: 僕のPCは古いので、CPU(Sandy Bridge)の能力は高くない。一方、今のアプリは近頃のCPUを想定して作っているので、僕のPCのような古いCPUで動かすと、重くなってしまうのではないか。そして、HTで見掛け上は8個ものコアがあるように見えるが、1個の仮想コアで処理するには軽くないのだろう。とは言え、1仮想コアの負荷は100%にはなっていない(通常使用時は30%前後)ので、実行に無理がある訳ではなさそうだ。

ただ、Vivaldiでは重くならないのが何とも不思議ではある。メモリを使う代わりにCPU負荷を軽くしようという方針なのだろうか。あるいは、Firefoxにはいろいろな(古い?)CPUに最適化できていない箇所があるのかも知れない。VivaldiのコアはChromeなので、それを作ったGoogleなら、いろいろ知っているだろうしリソースもあるから、さまざまなことができている可能性はある。

他には、前にも書いたかも知れないが、Firefoxは(プロセス数を減らすためなのか、)各タブのイベントを処理をするためにCPUを動かし続けるような作りになっていて、(そのため、特にタブが多くなると、)負荷が高くなる可能性も考えられる。ただ、個人的には、必ずしもそうなってしまうとは思わず、ちゃんと作れば(あるいは、最適化を行えば、)負荷を低くできると思う(コードを見ていないので、あくまでも想像である)。

負荷が小さいに越したことはないが、10GB以上もメモリを馬鹿食いされるのに比べたらずっといいので、しばらく試して問題なければ移ることにする。なお、負荷が大きくなり過ぎるのが防げることを期待して、設定の"Content process limit"を2に減らした。また、メモリ使用量を更に減らすため、Auto Tab Discardというアドオンで、一定時間アイドルのタブをサスペンドするようにした(ただ、元々使用量が少ないので、効果は余り感じられない)。

なお、Firefoxの使用メモリ使用量は、前回同様、Vivaldiの1/3程度だった。以下に測定結果の例を示す。

VivaldiとFirefoxの使用メモリ量の比較

  • 測定条件
    • それぞれのブラウザで、概ね同じページ(3ウインドウ、約46タブ)を開いた。
    • ps uxコマンドを用いて各ブラウザのプロセスのRSSを合計した。
    • どちらも最新版
  • 測定コマンドの例: ps ux | grep firefox | awk '{sum+= $6;} END {print sum/1024;}'
  • 結果
    • Vivaldi: 約10GB
    • Firefox: 約3.2GB

現時点で分かっている問題(不満な点)は以下である。致命的なものはなく、アドオンや設定によって、基本的な使い勝手をVivaldiとほぼ同等にできた。

  • [済] 縦のタブバーにしても、ウインドウ上部のタブバーは消せない。 → CSS(userChrome.css)を修正して消せた。 (→ 参考1, 参考2)
  • [保留] Authy(2要素認証用トークン生成アプリ)が対応していない。 → Chromeアプリを使う。
    • Authyの起動直後はシステムがすごく重くなって、なぜかFirefoxも動かなくなる。
      • 数十秒待てば直る。
      • Firefoxの設定を初期化しても直らず。 → 諦める。
  • [済] ズームに"105%"がなく、ズームのデフォルト値が変えられない。 → アドオン(Fixed Zoom)でできた。
  • [保留] デザインが今一つごちゃついている。 → 我慢する。
  • [保留] ページの表示がおかしいことがある(例: じゃがさんのブログで上が妙に空いたり、下に白い部分が出ることがある)。 → 我慢する。
  • [TODO] スタイル(CSSの反映のされ方)が微妙にVivaldiと違う(例: 「いいね!」ボタンが大きい)。ブログのCSSが良くない? → 暫定的にボタンの文字を少し小さくした。

他に、僕のデスクトップ設定との絡みなのだが、Firefoxには右上にメニューボタンがあるので、ウインドウの位置によってはボタンが時計と干渉することがあるという、思わぬ落とし穴があった。メニューボタンは動かせないようなので、なかなか悩ましい。まあ、クラシックなメニューバーもあるので、大きな問題ではない。それに、アドオンで何とかなるかも知れない(上のタブ一覧を消したのと同様に、CSSの改造で動かせそうな気がする)。

CSSを変更してメニューボタンを左に移せた(→ 参考: "Show CSS Code"の内容をuserChrome.cssに追加する)。

今の懸念(心配)は、MSもChrome系に移ったため、Firefoxがとても少数派になり、将来、開発元のMozillaもろともなくなってしまう可能性があることだ。ただ、メモリ量の少ない小型機器でChromeを使うのは現実的ではないから、Firefoxも残る期待はある。嫌なのは、Red Hatのように変なところに買収されてしまうことだ。例えば、OracleやIBMやMSなんてところは避けたい。もちろん、Googleだってマズい。ここは是非、UbuntuのCanonicalと一緒になって歯を食いしばって頑張って欲しい。

特にその気はなかったのだが、いろいろと「移行」の多い年末だ。IT大掃除のようなものか。他に、OSのバージョンアップもしたいのだが、さすがに、スマフォの回線移行が重なって電話が使えない可能性がある状態で行うと、メールすら使えなくなってドツボに嵌まる可能性があるので、来年にしようと思っている。

 

PS. 少し前にスマフォでもFirefoxを試したが、まだ遅いままだったので止めた。以前と同様、最初はそうでもなかったのだが、何回か動かすと遅くなってしまう感じだ。何かのアドオンが悪いのだろうか。

  •   0
  •   0

今日だったか、偶然ニュースでb-mobileの新しい従量コース(990ジャストフィットSIM)の記事を見て、再び移行を考えてみた。今はOCN mobile ONEで、特に問題なく使えてはいるのだが、入会した時のサポートが余りにもひどかったし、使っていてもシステムやwebの使い勝手が信じ難いほどひどく(前時代的。下に例を示す)、何年経っても全く改善されないので、いつか退会しようと思い続けていたのだ。

OCNの腐っている点(例)

  • システム: 光とモバイルそれぞれに(向こうからの連絡受け取りにしか使わない)メールアドレス(キャリアメールの扱いじゃないので、何にもありがたくないゴミ)が割り当たる(自分のアドレスは使えない)。なんと、それらを一つに統合できないようにして、間違えないようにするという親切設計w そういえば、IDみたいな番号も契約ごとにあって、どっちがどっちか分からなくなって、大変ありがたいわ!
  • Web: 何かしたくても、どこをクリックしたらいいかすぐに分かることはまずなく、何度も試行錯誤させることで頭の老化を防いでくれる、親切設計だw 何度試行錯誤したって分からず、ググッて第三者が書いた手引きを見てようやく分かる。画面遷移は妙に遅く、それも高齢者向けなのかも知れない。

b-mobileの新しいコース(音声付き)の最低料金は、1GBで990円/月(税抜き、以下同)と手頃だ。それで、移行したらどのくらい得(出費の削減)になるか検討してみた。

今は3GB/月で1800円である。ただし、光にも入っているので、割り引きが200円/月ある。他にIP電話050plusの基本料金300円が無料になっている。すると、実質料金は、1800-200-300= 1300円/月となる。

b-mobileにした場合、年間の差は、(1300-990)*12= 3720円となる。が、b-mobileにはOCNのSpotifyのカウントフリーがないから、旅行や帰省時にSpotifyを聴くとデータ量が増えて追加料金が掛かる可能性が高い。それを考慮すると、差(得)は約3120円/年※となる。一方で、移行するには、事務手数料が合計約6000円掛かるので、約2年経たないとペイしない。

※Spotifyのデータ量の計算を誤っていたため、正しい差(得)は約2124円/年となる。 (12/25 15時 訂正)

それでは割に合わないないから止めようと思ったのだが、Spotifyは速度を約100kbpsやそれ以下にできるので、b-mobileの低速モード(200kbps程度)でも使えそうなので、追加料金は要らなそうなことが分かった。更に、僕は電話はほとんど使わないので、050plusの基本料金300円を除外して計算し直すと、OCNの実質料金は、1800-200= 1600円/月となり、b-mobileにした場合の得は、(1600-990)*12= 7320円/年となって、移行の手数料が1年でペイできる計算になって、なかなかいい感じだ。

それで、b-mobileの評判などを調べてみたら、近年の業績が悪く(赤字続き)、事業継続性にリスクがあるように思えた。また、事業に一貫性がない(プランの乱立、ドコモを捨てたり戻したり)のも気になる。使っているうちに会社が売却されたり、プランがなくなったり、値上げされたりするリスクがあると思った。

それで、同様な条件(音声付き※、1GB・千円/月前後)で他を調べてみたら、以下が挙がった。

  • イオンモバイル: 500MB: 1130円/月
  • LinksMate: 1GB: 1100円/月
  • ロケットモバイル: 神プラン: 200kbps: 980円/月
  • DMM: ライトプラン: 200kbps: 1140円/月

※音声なし(データのみ)ならもっと安くなるのだが、さすがに、IP電話だけだと掛けられない相手があるし、待ち受けで電池を消費する可能性があるなど、問題が多いので止めた。

ロケットとDMMは低速で実用性に疑問があったので、却下した。どちらもYouTubeなどは(滅多に使わないが)無理そうだし、DMMは3日で366MBの制限があるので、いざという時に使えない可能性がある。するとイオンとLinksMateが残り、データ量では後者なのだが、調べたら手数料が高いという欠点があった。具体的には、他社への移行時に、MNP転出手数料以外にSIM解除手数料が3000円掛かるので、高く付く。

結局、イオンが残った。イオンだと、(1600-1130)*12= 5640円/年の得となり、移行手数料が1年ちょっとでペイできるから、悪くない。ただ、データ量の500MB/月(= 約16MB/日!!: 一体いつの時代かと思う)はすごく心許ないのだが、過去3か月の使用量を調べたら、余り外出しないせいか250MB/月程度だったので、問題はなさそうだ。

余談だが、イオンというのは我ながら意外で、今のスマフォをシャープにした時と同じような、(負の)驚きがある。「なんでわざわざ・・・」みたいなw まあ、名前にこだわらず実を取ろうとしていることの現れか。

運のいいことに、イオンはキャンペーンで来月頭までに契約すると3か月分の料金が無料になることもあり、早速手続きを始めたのだが、すぐに落とし穴に嵌ってしまった。OCNはMNP番号の発行に3営業日程度掛かるとのことで、早くても27日頃までは待つ必要がありそうで、それだと年内の切り替えは厳しいものがある。今日・明日(は無理にしても数日)でスパっと切り替えられると思っていたのに、まったくがっかりだ。

一体何にそんな時間が掛かるというのか? 事務員が確認して印刷して上司のハンコでももらいに行くのか? Webにログインする時に厳重なセキュリティを通したのだから、番号発行を希望されたら機械的にチェックして発行すれば、一瞬で終わることだろう。あるいは、実はそういう仕組みなのだが、処理に使っている計算機の速度が1MIPSくらいしかなくて、何をするにも時間が掛かるのだろうか?w (時間が掛かるのは、OCNだけでなくイオンもそうなので、どこでもそうなのかも知れない。てことは、"MNP協会"みたいな天下りとか利権団体での処理が必要で、そこはお茶飲みと喫煙するしか能のないジジイばっかりなために遅いのだろうか?)

まったく、ガラパゴス国 日本の伝統は素晴らしいねえw

という訳で、その後、再考してまたb-mobileに傾いたものの、将来性を考えてイオンに戻った。が、考える時間はたっぷりあるので、いろいろ迷ってみたい。あと、正直言って、もっと安くないと移るメリットは大きくないのだが、OCNからの脱却の第一歩として実施したい。モバイルを止めれば残りは光で、仮にどこかに引っ越すとしたら、その時に抜けられる可能性は充分にある。引っ越さなくたって、ハードルが下がるから意味はある。

(12/23 12:52) 予想外に早く、さっきMNP番号が来たので、さっそくイオンに契約した。あとはSIMが来るのを待つばかりだ。昨日や今日が営業日だったのかは知らないが、2日目に来た。もう少し正確に書けば顧客の不安やイライラも減ると思うのだが(イライラするのは僕だけ?)、安全側に振っているのだろうか。そういえば、以前もこんなことがあった気がするw

 

PS. 050plusの代わりのIP電話としてSMARTalk(= Fusion。今は楽天系になったそうだ)に申し込もうとしたら、過去に登録していたクレジットカードを再度使う場合には、手数料500円が掛かるという落とし穴があった。iPhoneを止める時に退会したのが失敗だった。これにもがっかりしたが、仕方ない。電話は余り使わないので、当面はプロバイダの提供している、番号にプリフィックスを付ける割安(といっても高い)な電話で我慢することにした。万が一仕事が軌道に乗って、多用することになったら、入ればいい。

  •   0
  •   0

最新のAppImage版のdigiKam(5.9.0)では、Googleマップが暗くなり、ちゃんと表示されなくなってしまっている。OpenStreetMapにすれば問題ないが、Googleマップの方が表示が綺麗なので、できればそちらを使いたい。それで検索したら、想像どおりAPIキーの問題だそうで、6(まだベータ)では直っているとのこと。そこに5での暫定対処の方法(Googleマップに関係するファイルを入れ替える)も出ていた。

ただ、AppImage版はOSのディレクトリ(/usr/share/digikam)を使わず、アプリ一式が1つのファイルになっているので、そのままでは対処ができない。そこで、以前見つけたAppRunを修正する方法でできないか試したら、できた。

AppImage中のスクリプトAppRunの頭で環境変数XDG_DATA_DIRSを設定しているので、その先頭に、優先させたい(入れ換えたい)ファイルのあるディレクトリを追加すれば良い(どんなディレクトリでも入れ換え可能な訳ではなく、ライブラリなどから$XDG_DATA_DIRS経由で参照される、/usr/shareのようなものが有効なのだろう)。

今回は/usr/share/digikam/geoiface/backend-googlemaps.htmlを入れ換えるので、以下のようにした。

  1. 入れ換え用ディレクトリ(例: $HOME/bin/digikam5-ai-ext/share/digikam/geoiface)を作成する。
  2. その下に/usr/share/digikam/geoiface/*をsym-linkする。
  3. backend-googlemaps.htmlだけをdigikam6のもの(tarファイルをダウンロード・展開して取り出す)に交換する。
  4. AppRunの中のXDG_DATA_DIRSの設定する行で、以下のように、先頭に入れ換え用ディレクトリ($HOME/bin/digikam5-ai-ext/share/)を追加する(太字部)。
    • export XDG_DATA_DIRS=$HOME/bin/digikam5-ai-ext/share/:$DIR/usr/share/:$XDG_DATA_DIRS

そのAppRunを使うdigikamを起動したら、再び地図が出るようになった

 

PS. それにしてもAppImageだのFlatpakだのSnapだの、似たようなのがいっぱいあって面倒だし効率が悪いし間違えやすいから一つにして欲しい! ここにもLinux内の抗争があるのか? 馬鹿らしい。

  •   1
  •   1

少し前に、Spotifyアプリがメモリを消費し過ぎることの弊害を緩和できないかと思って、それまで無効にしていたスワップを有効にしてみた。ところが、その後くらいから、Thunderbirdが2日くらいでハングし、Thunderbirdのプロセスをkillすることもできず、OSをrebootしようとしてもエラーでハングしてしまってリセットするしかなくなる問題が多発した。その時、dmesgやreboot時のコンソールには、以下で始まるエラーが出ていた。

[149418.786180] BUG: unable to handle kernel NULL pointer 
dereference at 0000000000000010

どういう訳かは分からないが、スワップを有効にしたのが悪かったように感じたので、無効にして試しているのだが、一週間経っても問題が起こっていないので、やはり、スワップが原因だったようだ。

ただ、Linuxでスワップが良くないことは信じられない。考えられるのは、スワップ領域を初期化せずに有効にしたためかと思う。その他には、起動時のdmesgに、以下のような警告があったのが気になっている。

[ 11.107687] nct6775: Found NCT6776D/F or compatible chip at 
0x2e:0x290
[ 11.107694] ACPI Warning: SystemIO range 0x0000000000000295-
0x0000000000000296 conflicts with OpRegion 0x0000000000000290-
0x0000000000000299 (\_GPE.HWRE) (20150930/utaddress-254)
[ 11.107699] ACPI: This conflict may cause random problems and 
system instability
[ 11.107701] ACPI: If an ACPI driver is available for this device, 
you should use it instead of the native driver

これは以前からもあったのだが、スワップが有効だと問題が起こるのかも知れない。警告から、センサーチップNCT6776Dとグラフィック(Intel内蔵)のアドレスが重複していると思われるので、次回問題が起こったら、BIOS設定でグラフィックのアドレスを狭められれば、試してみたい。無理なら、検索して見つかった対処の、カーネルの起動パラメタにprocessor.nocst=1を追加することを試してみたい(ただ、それで別の問題が起こらないかという心配はある)。

いずれにしても、今のところ問題は起こっていないので、このまま行けそうな気がする。もしスワップを有効にする時は、このことを思い出したい。

(11/16 3:47) 昨日、再びThunderbirdがハングした。今度は約12日間動作していた。スワップをonにすると問題が起こりやすくなるようだが、直接的な原因でなさそうだ。そこで、上記の対処を試そうとしたのだが、Intel内蔵グラフィックのアドレスは変更できず、カーネルの起動パラメタprocessor.nocst=1も設定しても同じACPIの警告が出たので、効果がなかった。

それで、ACPIのアドレス重複を解消できるかと、別のカーネル起動パラメタacpi_enforce_resources=laxを止め、センサのドライバnct6775も止めてみたのだが、アドレス重複は解決できなかった。そもそも、acpi_enforce_resources=laxとnct6775ドライバは1年以上前から使っていて、近頃まで問題がなかったので、今回の原因ではなさそうだ。また、別のセンサのドライバasus_atk0110を試したが、うまく動かなかった(センサの値が取得できなかった)。

更にログを調べたところ、Thunderbirdのハングの直前のスリープからの復帰の数分後に、snap関連のメッセージの直後にカーネルのエラーが起こっていた。以下に、その時のログを示す。

Nov 15 23:57:33 localhost snapd[1285]: storehelpers.go:398: 
cannot refresh snap "core": snap has no updates available
(略)
Nov 15 23:57:40 localhost systemd[1]: Mounting Mount unit for 
spotify, revision 26...
Nov 15 23:57:40 localhost kernel: [758674.540346] BUG: unable 
to handle kernel NULL pointer dereference at 0000000000000010

snapdは、Spotifyアプリをsnap版にするために使っているのだが、snapとカーネルの相性が悪いことが考えられる。それで、今度はSpotifyアプリをsnapでない版に戻して様子を見ることにした。また、問題を起こりやすくするため、スワップをonにしてみる。

(11/27 19:19) その後はThunderbirdのハングやカーネルのBUGは起こらず、Spotifyアプリを後の投稿に書いたように、snapから取り出した版にし、snapの機能・サービスを使わずに使っていた(関係なさそうなので、スワップはoffに戻した)。それでも問題が起こらなかったので、現象はsnapとスリープに関係しているようだ。今推測しているのは、以下のようなことである。

  1. スリープ(サスペンド)からの復帰時、少しの間、LANが正常に動作しない時間(1-2分)がある。
  2. その時にsnapがマウント処理(上のログの23:57:40、2行目)を行うと、カーネルのBUG(同3行目)が発生する。
  3. そうなると、どういう訳かThunderbirdもハングする。

その推測に基づき、1番の問題に対処するため、スリープからの復帰時にLAN IFを一時停止する処理を追加して、再度snap版のSpotifyアプリを使うことにした。LANの一時停止処理の間はスリープからの復帰処理が終わらないので、snapのマウント処理も行われないはずである。以下に、LANの一時停止処理の流れを示す。この処理は、スリープなどの前後に実行されるスクリプト(/etc/pm/sleep.d/89name)に格納している。

  • スリープや休止からの復帰時(resumeまたはthaw)に以下を実行する。
    1. LAN IFを停止(nmcli device disconnect IF名)する。
    2. 少し(1秒)待つ。
    3. LAN IFを起動(nmcli device connect IF名)する。
    4. 少し(1秒)待つ。

この処理は、以前別の問題(NW通信不調)が起こったために追加したのだが、近頃は問題が起こらなくなったようなので無効にしていた。別のルータを使っていた時は起こらなかったので、ルータとNICやドライバやOSの相性が悪いようだ。

(11/28 15:33追記) シャットダウン時にハングアップした時にコンソールに出たカーネルのエラーメッセージの最後辺りの文字列("propagate_one+0xbe/0x1c0")で検索したところ、これはカーネルの既知の問題(2016-04-19)のようだ。問題が起こる契機は異なるが、メッセージは同じだ。

シャットダウン時にハングした時のカーネルのエラーメッセージ

また、メッセージ中に"do_mount"とあるので、昨日の推測どおりsnapのマウント処理が契機になって発生すると考えられる。

修正版を探したところ、カーネル4.4.0-23.41で修正されているのだが、使っているLinux Mint(正確にはUbuntu)のパッケージはなかった。ベースはUbuntuのLTSのため、対応する問題が限られているのではないかと推測する。この問題を修正するには、おそらく最新のLinux Mint 19にするしかなさそうだが、来年に予定しているので、それまでは昨日記した対処(スリープからの復帰時にLAN IFを一時停止する)で様子を見ることにする

(11/29 2:40) アップデートマネージャの設定を見直し、"Always show kernel updates"をonにしたら、更新版カーネル(4.4.0-139.165)のパッケージが表示され、その履歴に本問題の修正も含まれていたので適用した。おそらくこの問題は解消すると思われるが、元々ルータとNICやドライバやOSの相性から、以前に起こっていた問題は起こりそうなので、スリープからの復帰時にLAN IFを一時停止する処理は有効にし続ける。

 

(11/16 3:47 題を若干変更)

 

(仕事ブログより転載・一部表記を修正、題を若干変更: 元の投稿日時: 2018/11/10 17:39)

  •   0
  •   0

Snap版Spotifyアプリを使っていて、(それが原因かはまだ不明なのだが、)Linuxのカーネルがバグ起因のエラー(NULLポインタ参照)を起こして、ThunderbirdがハングしたりOS再起動時にハングする問題が起こり、エラーが起こる直前(スリープ(サスペンド)からの復帰後)にSnapのマウント処理が行われていて、他に原因が見つからないので、Snapとスリープとカーネルの相性の問題を疑っている。それで、試しにSnapの仕組み(サービス)を使わずに、Snap版Spotifyアプリを単体で動かせないものかと思った。それには、Snapのパッケージを展開して中身のSpotifyアプリを取り出せばいいのではないかと考えた。それでSnapの展開ツールを探したのだが、見つからなかった。が、少しして気付いた。

結論としては、Snapパッケージの展開にツールは不要である。Snapのサービス(snapd)を起動し、目的のSnapパッケージをインストールし、そのアプリを起動できる状態にすれば、中身が/snap以下にマウントされるのだ。例えば、Spotifyは /snap/spotify/26 のようなディレクトリ(最後の数字はリビジョンと思われる。最新版はcurrentにsym-linkされている)にマウントされる。そして、Snapの中身を取り出すには、そこからコピーするだけでいい。

それから少し試行錯誤して、本来の目的の、Snap版Spotify(の中身)を通常のプログラムとして動かすことができた。以下のような手順である。以下は、OSがSnapのサービスを使っていない(有効にしていない)前提であり、Snap版Spotifyの中身を「Snap抽出版Spotify」と表記した。

準備

  1. Snap抽出版Spotify用ディレクトリ(例: ~/spotify/ext-snap)を作り、chdirする。
  2. マウントされたSnapのSpotifyのディレクトリ(以下、Snapのディレクトリ) /snap/spotify/current/usr/share からspotifyをコピーまたはsym-linkする(私はコピーしたが、sym-linkで問題ないと思う)。
  3. Snapのディレクトリ /snap/spotify/current/usr/share 下のspotify以外の全ファイルをsym-linkする。
  4. ライブラリ用ディレクトリ(例: lib)を作り、chdirする。
  5. Snapのディレクトリ /snap/spotify/current/lib/x86_64-linux-gnu/ 下の全ファイルをsym-linkする。

OS起動時の準備

以下をOS起動時に実行する(例: /etc/rc.localに追加する)。

  1. Snapのサービス(snapd)が有効でない場合起動し、念のため少し待つ。
    • 例: /bin/systemctl start snapd; sleep 0.5
  2. Snapのサービスsnapdとsnapd.socketを停める。
    • 例: /bin/systemctl stop snapd; /bin/systemctl stop snapd.socket
  3. 使わないSnapのマウントポイントをumountする。
    • 例: umount /dev/loop[1-5] (環境によって異なると思われる)

Spotifyの実行

以下をスクリプトにしておけば、それを実行することでSnap抽出版Spotifyが起動できる。

  1.  LD_LIBRARY_PATHに上記のlibを設定または追加する。
    • 例: export LD_LIBRARY_PATH="$HOME/spotify/ext-snap/lib"
  2.  Spotifyアプリを起動する。
    • 例: ~/spotify/ext-snap/spotify &

以上の手順で、Snapサービスを使わずに(無効にしたまま)Snap版Spotifyの中身のアプリを起動できる。ただし、Snapでのパッケージの更新などは行われないので、適宜自分で行う必要がある。

 

[付録] 以前のSpotifyの画面構成に戻す。

上の作業をした後で、おもしろいことが分かった。Snap版のSpotifyアプリ(バージョンの例: 1.0.93.*)は、従来の版(バージョンの例: 1.0.80.*)とメニューやページの構造が異なっている(例えば、"Your Daily Mix"は"Made For You"に変わった)。一方、私は以前の方が使いやすいので戻したかったのだが、ちょっとした手順でできた。以下のようにすればよい。

  1. Snap抽出版Spotify用ディレクトリ下のAppsディレクトリ(sym-link)を削除かrenameする。
  2. 従来の版のApps(/usr/share/spotify/Apps)をsym-linkする。

上記作業の実行例を以下に示す。

  1. cd ~/spotify/ext-snap
  2. mv Apps{,.orig}
  3. ln -s /usr/share/spotify/Apps .

以前調べた時に分かったことだが、Apps下にはSpotifyアプリの画面のアプリ(JS)やCSSが入っており、ある程度カスタマイズできるようだ。あと、私の環境(Linux Mint Xfce + Fcitx + Mozc)ではSpotifyアプリに日本語が入力できないのだが、ライブラリを変えたり追加したりすれば、なんとかなるかも知れない。余裕があれば試してみたいと思う。

(11/24 17:24追記) App下のファイルで、古いものにするとうまく動かないものがある(例えば、settings.spaは新しいもの(Snapのもの)でないと表示されない)ので、適宜修正する必要がある。筆者はsettings.spaをSnapのものにした。本当はウインドウ左側のメニューだけを交換したかったのだが、それを出すと思われるzlink.spaを交換するとアイコンが出なくなってしまうので、諦めた。

(12/20 6:55追記) その後、元々の問題(Snap版Spotifyを使うとLinuxのカーネルのバグ起因のエラーが起こる)が解決したようなので(数週間、問題が起こっていない)、上記の方法は止めて、Snap版Spotifyをそのまま使っている。

 

(仕事ブログより転載・追記: 元の投稿日時: 2018/11/21 10:45)

  •   0
  •   0

筆者は、今まではdigiKam5はPPAの5.5を使っていたのだが、起動が遅い(画像ライブラリの読み込みが遅いようだ)ので、ずっと最新版を使いたかった。しかし、日本語モードはあるものの、日本語入力できない問題があったので移行できなかった(筆者の環境はLinux Mint 18 Xfce, Fcitx+Mozc)。また、digiKamのサイトではディストリビューションのパッケージを使うように書いてあるのだが、Mint 18はUbuntu 16 LTSベースのため、パッケージのものは4.4と古くて使えない。

日本語入力ができない問題の原因は、それがAppImageになっているために、中身のテキスト入力に関連するライブラリが不足しているためではないかと考えた。少し前に検索したところ、(他のアプリの例では)環境変数QT_PLUGIN_PATHに元のOSのディレクトリ(例: /usr/lib/x86_64-linux-gnu/qt5/plugins/)を設定すればできるはずなのだが、そうしても駄目だった。

それで、先日、Snapの中身のSpotifyを実行できることが分かったので、これもAppImageの中身を単独で実行したり、中身を展開して修正することで、日本語入力できるようにならないかと考えた。検索したら、AppImageのフォーラムにヒントが書いてあり、AppImage中のAppRunというスクリプトを修正すれば良さそうだった。

そして、それまでに、AppImageは--appimage-mountオプションを付けて起動すると、イメージをマウントできる(プログラム本体は実行しない)ことが分かっていたので、マウントしてAppRunの中身を見たところ、それは普通のシェルスクリプトで、最初にLD_LIBRARY_PATHやQT_PLUGIN_PATHを設定(上書き)していることが分かった。それで、QT_PLUGIN_PATHを修正したAppRunを作り、そこから本来のプログラム(この場合はdigiKam5)を起動すれば良さそうなことが分かった。

それで、どのように実装するか考えたのだが、マウントされたAppImage全体をコピーして、必要な箇所を修正するのでは容量が無駄になるし、中身を変更したAppImageを作り直すのはアプリの更新のたびに作り直す必要があって面倒なので、(余り変更がなさそうな)AppRunだけを抽出して修正し、そこから、あらかじめマウントしたAppImage中のアプリ(この場合はdigiKam5)を起動するようにした。

さっそく、指定したAppImageファイルとAppRunでAppImage中のプログラムを起動するスクリプトを作り、それでdigiKam5のAppImageを起動したら、無事、日本語入力できるようになった。実際に日本語入力している例を以下に示す(筆者の好みで、英語モードにしている)。

AppImage版のdigiKam5で日本語入力ができるようになった。

一般的な説明を書くと、あるAppImage(Qt5を使っているもの)を日本語入力できるようにする手順の流れは、以下のとおりである。

  1. AppImageをマウントする(AppImageに--appimage-mountを指定して起動する)。
  2. AppImageがマウントされたトップディレクトリのAppRunを別のディレクトリにコピーする。
    • マウントディレクトリは/tmp/の下の一時的なもの(例: /tmp/.mount_XXXXXYYYY)になる。マウントポイントは指定できないので、AppImageの出力をscriptコマンドを使って取得することにした(なぜか、バッククォートやリダイレクトでは取れなかった)。
  3. AppRunの先頭にあるであろう、環境変数QT_PLUGIN_PATHの設定に、元のOSのディレクトリ(例: /usr/lib/x86_64-linux-gnu/qt5/plugins/)を追加する。
    • digiKam5での例: export QT_PLUGIN_PATH=$DIR/usr/plugins/:/usr/lib/x86_64-linux-gnu/qt5/plugins/
  4. 同様に、AppRunの先頭にあるであろう、環境変数DIR(およびAPPDIR)を適宜修正する。これは、AppImageのマウントされたトップディレクトリを想定しているようなので、筆者はカレントディレクトリにした。
    • digiKam5での例: DIR=`pwd`
  5. AppImageのマウントポイントにchdirし、修正したAppRunを実行する。

digiKam5のAppImageが更新された場合には、基本的には上記手順で2と3を省略し、同じ修正版のAppRunを起動するだけで良いはずだが、AppImage中のAppRunが変わった場合にはうまく動かなくなるので、再度修正が必要である。 → (11/27 6:58追記) 修正したAppRunを実行する前(上記手順5のchdir後)に、AppImage中の(最新の)AppRunとの差分を求めて、修正の必要があるかをチェックするようにした。

 

なお、SpotifyのSnap版も同様にQT_PLUGIN_PATHを設定すれば日本語入力ができるようになるかと思ったのだが、Qt5を使っていないようなのでできなかった。 (11/27 8:44追記) その後、GTKを使っていることが分かったので、immodulesにライブラリを追加したり、関連する環境変数(例: GTK_IM_MODULE)をいくつか指定してみたのだが、なぜか駄目だった。設定が間違っているのかSpotifyが対応していないのか不明だが、フォーラムでは数年前に指摘されているものの「修正を待つように」と書かれているだけなので、(Snapには関係なく、)元々のSpotifyアプリが対応していない可能性が高い。

 

(仕事ブログより転載、題をわずかに変更: 元の投稿日時: 2018/11/26 21:26)

  •   0
  •   0

仕事サイトを作ってから1.5か月くらい経ったが、相変わらず閑古鳥しか居らず、そろそろ撤収(まだ撤退ではない)モードだ。受託開発とLinux用オリジナルソフトなどについて案内を出したのだが、コメントや問い合わせは一切ない。見込みが甘かった。僕の経験も合わせて理由を考えてみると、以下のようなことが思い浮かんだ。

  • 受託開発
    • 開発業者を探す人は、ネットで検索なんてせず、主に、過去の実績(= 付き合い)のある業者を選ぶ。
      • 検索するにしても、個人でなく企業を探す。
      • それ以外に、企業は営業が担当者を周って売り込むので、発注時に名前が浮かぶ可能性が高い。
      • 個人に依頼するなら、誰か(偉い人?)の知り合いであることが多い(そうでないと説得できない)。
      • 担当者が発注先を選定するのでなく、上から指示される場合も多い(それで失敗することも多いがw)。
    • 仮にネットで探したとしても、どこの誰とも分からない、有名でもない人に頼む気は起こらない。
      • リスクしか思い付かないし、上を説得できない。日本では100%そうでは?
      • 上を説得するとして、担当者がそこまでして責任をかぶる意味がある?
      • 個人だと、失敗した時の賠償能力がないのも弱い(保険はあるが、まだ一般的でない)し、仮にその業者(= 僕)が駄目になったらぽしゃるのが確実なのも弱い。
    • 仮に、「この経歴なら頼めそうだ」とか思っても、発注者はソフト単体でなく「システム」を作りたいことが多いが、個人ではシステム全体は担当できない(ソフト以外も絡むことが多いのと、工数や時間の制限がある)。
      • その場合、部分を切り出して発注することになるが、そんな面倒なことをしても、発注者にはデメリットしかない。
      • そもそも、作りたいシステムの中身について詳しい発注者は少なく、どういう風に切り出せるか分かる人はほとんど居ない(逆に、詳しいつもりの発注者に中身を細かく指定されると、失敗の原因になる)。
      • 頼むにしたって、きっちりとした契約でなく、派遣(SES)みたいに、「あれやって、これやって」と都合よく使いたい。
    • 得意分野が流行りから外れている。
      • 今はAI(機械学習)、ブロックチェーン、IoTなどか。あとはドローンやVR・AR? (良く知らんw)
      • あと、Python全盛だしw
      • 何でもスマフォだし。
  • Linux用オリジナルソフト
    • Linuxのユーザーが元々少ない。
      • PCを使う人が減っているうえに、PCならWindows。
      • Windowsが嫌になっても、(Linuxでなく)Macに行く風潮。
    • Linuxで、例をあげたソフト(Spotifyやバックアップ関係)を使う人は更に少ない。
      • (仕事サイトよりアクセス数が多いこちらに書いても、要望もコメントもなかったので、)僕の作ったものは(ニッチ過ぎて?)元々需要が少ない。
      • (すぐに手に入る)有名な既存ソフトを使うか自分で作る人が多い?
      • 「欲しい方居ますか?」などと聞くより、まずは公開しないと駄目?
    • 分野が流行りから外れている。(受託と同じ)

という訳で、勝てる見込みはなさそうだ。3か月経過するまでは様子を見ることにするが、近頃はやる気が低下して更新していないので、期待できなさそうだ。まあ、こうなることを予想して大きな投資はしなかったので問題ない。短期決戦・即断即決な性格なので、無駄なことは早目に止めることにする。それから、仕事サイトの技術的な投稿を順次こっちに転載しよう。

そして、来年の頭は次の進め方を考えよう。とは言え、日本では、「有名/天才プログラマー」になる以外は会社に属する(= 社員 or 派遣)しか現実的な選択肢はなさそうだが、夢のような会社がない限り避けたい・・・ (他にはクラウドソーシングでの受託もあるが、元々安いうえに価格競争になり、受けてもリスクが高過ぎるので、やる気は起こらない)

 

題は、今掛かっている、しみる歌より。

PS. 全くの冗談だが、「MusicBeeの使い方」を最新版に対応させて加筆して本にするとか、MusicBeeの有料サポート(トラブルや設定や音質改善などのコンサル)を引き受けるなどの方がはるかに需要がありそうだ。あ、本は、今時紙は古いし出版してもらうのは大変だが、電子ブックなら自分で作って売り出せそうでいいかも知れないな。Windowsは嫌いだけど、仕事になるなら贅沢は言えない。まだ需要はあるのかな。でも、仮にその本が売れたって、単発なので続かないだろう。が、その後のきっかけ(= 名前を売る)にはなるかも知れない。

と、「冗談からアイデアが出たかも知れない」とぬか喜びしながらアドバルーンを揚げる、今日この頃w

PS2. オリジナルソフトの当初の収受手段として寄付を考えていたが、ほとんど効果がないことに気付いた。自分だって滅多にしないからだ。近年したのはMusicBeeとLinux Mintくらいだ。「寄付歓迎」と書いてあっても、まず「まあ、あとで」とか「見なかった」ことにするし、うるさく出すと逆効果になる。お金をもらうなら、寄付ではなく販売や課金の方が良さそうだ。

それから、技術的な内容の投稿をしても、仕事のプロモーションにはならなそうだ。というのは、僕が何かで困って検索して役に立つ情報を見つけたら、即座に試して、OKだったら「良かった!」とか「なるほど」で終わるからだ。同じサイトをよほど何回も見ない限り、元のサイトに戻って、「このすごい人はどういう人なのか」などと調べることはないし、お礼を書くこともまずない。問題を解決することが目的ではなく、早く「本題」をやりたいからだ。

悲しいが、現実は厳しい。。。 (僕がセコ過ぎるだけで、実際は違うってことはないですよね?w)

PS3. FaceBookは既に撤退した。流入は最初に1件しかなく、仕事には全く無意味なことが分かったためだ。しばらく見ていたが、「知り合いかも」に出る人で、業者とそれに引っ掛かる人(実はサクラなのかも)以外に活発な人は少ない感じで、やはり、もうオワコンなのかも知れない。

  •   0
  •   0

PHPをバージョンアップする件。手始めに自分のPCでやったら、予想外に面倒な事態になってしまった。

僕のPCのLinux(のパッケージ)には最新のPHPが提供されていないので、PPA(昔流行った「ペン―」じゃないですw)という第三者のパッケージで手軽にバージョンアップしようとした。それを使ってPHP自体の更新はうまく行ったのだが、その後がいけなかった。そのPPAには、どういう訳かPHP以外のパッケージが山ほど入っていたのだ。PHPを入れて少しして、別のパッケージの更新の通知が大量に出て、不思議に思ってそれらの中身を調べたら分かった。

知らない(馴染みのない)パッケージが(通常はないほど)沢山出て来て嫌な感じがしたのだが、その時は少し迷ったものの、「まあいいか」と更新した(これが最悪の選択だった・・・)。が、あとで良く考えてたら、PHPだけでも第三者に依存するのはリスクがあるのに、他の多くのパッケージまで依存するのは危険なことに気付いた。例えば、更新されたパッケージには重要な通信モジュールである、OpenSSLが入っていたのだ。親切で入れたのか、パッケージを分けるのが面倒だったのか、PHPと依存関係があるのか分からないが(更新する前から問題なく動いていたし、依存関係があるなら最初から自動でインストールされるので、最後は理由ではなさそうだ)、さすがにちょっと怖い。今までのPPAではこんなことはなかったので、おかしいと思う。

それで、仕方ないのでPHPのバージョンアップはOSを更新して(OSの正式パッケージで)行うことにして、更新したばかりのPHPを戻した。OSのものはバージョンが一つ古いが、しばらくは使えるだろう。更に、さっき更新されたパッケージも戻そうとしたら、それが一筋縄では行かなかった。。。

パッケージを戻すには、一旦アンインストールして入れ直すか古いバージョンを指定してインストールする必要があるのだが、更新されたパッケージは既にいろいろな依存関係にはまっていて、素直にアンインストールできなくなっていた。いろいろ調べて四苦八苦して、多くは戻せたが、全部は無理だった。

OSを更新(バージョンアップ)すれば直る(リセットされる)可能性はあるが、直らない可能性もあるし、最悪の場合、OSの更新が失敗することもあり得るし、更新するまでおかしな状態のままなのは嫌なので、どうしても元に戻したい。

もう少し試行錯誤はするが(上書きインストールができないかなど)、今のところは、バックアップからリストアするしかなさそうな感じになっている。まったく溜息だ・・・ 手抜きや良く考えずに"OK"を押すのは良くないね。

(22:47) どうしてもリストアは気が進まなかったので(余計なものが残ったり、事態を更に悪化させる可能性があるため)、良く分からないなりにパッケージ管理コマンド(aptitude)を試行錯誤したら直った。基本的には、今までやったとおり、古いバージョンを指定してインストールするか不要パッケージを削除するので良かった。

ただ、ポイントは、それで問題が生じる場合に解決するための対処候補が出て、最初の候補は依存するいろいろなパッケージを削除するとか出て怖いのだが、何度か次候補を出して行くと、仕舞いには問題のパッケージをダウングレードする候補が出る(ことがある)ので、それを実行することだ。そうすると、依存関係がガチガチのものも、魔法のようにうまく直った。それでも駄目な時は、パッケージの依存関係を調べて、インストールや削除の順序を変えるといいようだ。

今日インストールしたパッケージのバージョンを調べた限り、元に戻せたようだが、まだ不安はあるし、とても疲れた。。。 変なPPAには充分注意する必要があるが、なかなかできない。

最後に書かなくてもいい一言: PPAは嫌いでも、Linuxは嫌いにならないで下さいw

 

PS. 最新のPHPにする方法を検索すると、このPPAを使う方法が当たり前のように出て来るが()、みんなこういうことは気にしないのだろうか(気付いていない?)。まあ、Linuxの正式なパッケージだって、信頼性は保証されていないが、どこの誰とも分からない第三者(個人)の作るものなので、そこには誤りや最悪の場合には(提供者が意図するかしないかに関わらず、)マルウェアなどの混入の可能性がある(今は問題なくても、将来の更新時におかしくなる可能性は0ではない)と思うのだが、そうでもないのだろうか。みんな、人柱になる気が充分なのか。

今回特に嫌だったのは、このPPAには目的のパッケージ(PHP)以外のものが多数入っており、目的のパッケージは確認したり使ったりするので問題ないことが分かるにしても、自分が使わない・意識していないパッケージが異常だとかマルウェアだったとしても気付かない可能性が高いことだ。

PS2. PHPを最新にするには、もう一つ方法がある。自分でソースをダウンロードして、ビルドするのだ(これをやった人がPPAを作って提供していることがある。だから、PPAを使うと楽になるのだ)。が、パッケージと違って、状態を最新に保つには、PHPが更新されるたびにビルド・インストールする必要があって、なかなか手間が掛かる。特に、マシンが何台もあると面倒だ。まあ、ビルド・インストールを自動化すればいいが、結構怖いものがある。 でも、それもいいかも知れないと、今思ったw いや、ちゃんとやるなら依存関係のあるモジュールも芋づる式に更新する必要が出て来るから、やっぱり現実的ではなさそうだ。 (12/15 8:13)

  •   0
  •   0

先日ちょっと書いた、Linuxではマウスホイールの加速ができない(ディストリビューションやデバイスによってはできるかも知れないが、僕の使っているLinux Mint Xfceにはない)件だが、できるようにする方法が見つかった。まだアイデアの実現性が確認できた(PoC)段階だが、一応使えるようになった。

はじめに書いておくが、現状でも、ウインドウサーバ(X11)の設定などでマウスホイールの加速をすることはできる。例えば、imwheelコマンドを使えばホイールの倍率を設定できる。ただ、それは今一つ実用的でない。僕も以前試してうまく行くと思ったのだが、問題があって止めた(そのことを忘れていた)。

その問題は、設定やimwheelは常に加速する(「加速」というより、「倍率」という方が正しい)ので、例えばVivaldiブラウザでタブ一覧をホイールで選ぼうとすると、1ノッチしか動かさなくても設定した倍率のノッチ分(例: 3ノッチ)動いてしまって、まともにタブが切り替えられないことだ。imwheelは設定で対象のウインドウを指定または除外できるが、Vivaldiのタブ一覧は子ウインドウではなさそうで、除外できなさそうだった(実際には子ウインドウなのだろうが、容易には分からなかった。もし分かったとしても、自分が使うすべてのアプリについて調べるのは、実用的でない)。

そのため、単なる倍率設定でなく、本当に加速する機能が必要だ。その、「本当に加速する」は以下の定義とする。

  • ホイールの回転速度(以下、速度)が速い時にホイールの変化数を増やす。
  • ホイールの速度は、ある時間内のホイールの変化数(ノッチの変化数)とする。
  • 増やす値は、例えば、ホイールの変化数にあらかじめ設定した値(加速係数)を掛けて求める。

上記の定義を実現する処理の概要を以下に示す。

  1. マウスをLinuxのウインドウサーバ(X11)(のイベントドライバevdev)が無視するように設定する。ホイールだけ無視できるなら、そうする。
  2. マウスイベントを取得する。
    • 通常のX11では、ホイールはマウスのボタン4と5に割り当てられているので、それらのイベントを取る。
  3. ホイール以外のイベントは、そのまま発生させる。
  4. ホイールのイベントは、加速処理をしてイベントを発生させる。
    • ホイールの速度は、所定の時間内に(連続して)取得できた同一イベント数から求める。イベントの有無の判定にはselectを使った。
    • ホイールの速度に比例させてホイールイベントを追加発行する。
      • 例: 2イベント発生、速度= 40イベント/s、加速係数= 0.1 → 0.1*40*2 -2= 6イベント追加

イベント処理の概略図

イベント → ホイールイベント処理プログラム → ウインドウサーバ (X11)
                 ホイールイベント: 加速処理をして出す
                 他のイベント: 何もしないで出す

次に、本方式の実現性を確認するためのテストプログラムを作成した。C言語は手間が掛かるのでPHPを用いた。この時、evdevの設定変更のたびにX11を再起動したくなかったので、上記1番のevdevがホイールを無視するように設定する処理について、evdevと並行してイベントを読めるか試したら読めたので(ただし、通常の設定ではrootの権限が要る)、実装を保留して残りの処理を実装した。また、evdevと並行動作させるため、他のイベントを発生させる必要もないから、上記3番の実装も行っていない

なお、加速処理で追加のホイールイベントを発生させる処理は、速度や負荷の点から、本来はネイティブなX11のライブラリを使うべきだが、今回は実現性の確認が主な目的なので、xdotoolコマンドで発生させた(例: xdotool click 4 (または5))。

作成したプログラムは(予想に反してw)期待どおり動いた

最初は想定していなかったのだが、この処理はウインドウサーバ(X11)の処理と並行して動作できるので、X11への変更は全く不要で、プログラムの追加だけでできた。そのため、最初は仮想環境で動作確認や修正をしようと思って準備したのだが、全然使わなかった。

以下に、本方式のデモを示す。

○ページのスクロール (ホイールを6回、速く動かした場合)

通常(ホイール加速なし)の場合 (スクロール速度は変わらず遅い)

 

本方式の場合 (スクロール速度が高速)

 

○タブの切り替え (ホイールをゆっくり動かした場合)

imwheelの倍率を有効にした場合 (複数タブ分飛んでしまう)

 

本方式の場合 (タブが正常に切り替えられる)

 

考案した方式でホイールの加速が実現できることが分かったが、現状では以下のような問題点や不足点があるので、追って改良して正式版にしたい。

  • ホイールイベントの追加数が多い場合(加速が大きい場合)、スクロールが遅い(終わるまでに時間が掛かる)。そのせいか、今一つ感触が悪い(「スムーススクロール」に似た、ぬるぬるした感じ)。 → 不具合の修正と動作・パラメタの調整で解消し、きびきび動くようになった。
    • 追加数が一定値以上の場合はホイールでなくPage Up/Downにすると良さそうだが、アプリの対応状況に依存するので、単純ではない。
    • 追加イベントの発行にxdotoolを使わなければ速くなるのか、要確認。 → xdotoolのイベント発行間隔(--delay)を指定する必要があった。
    • Windowsでの動作を調べる。
    • 設定(しきい値、加速係数など)を調整する。
  • 追加イベント発行中(スクロール中)にマウスを動かしてウインドウが切り替わると、別のウインドウにホイールイベントが行くので、思わぬ結果になる。 → スクロール開始時のアクティブウインドウにイベントを発行するようにしたが、まだ不十分な点もある。 → 上記のスクロールが遅い不具合を修正したため、ほとんど問題にならなくなった。
    • ウインドウが切り替わったらイベント発行を停めたいが、結構難しそう。
    • Windowsでの動作を調べる。
  • マウスのイベントデバイス(/dev/input/event*)を自動検出する。 → 対応した(複数のマウスがある場合は、最初のものに対応することにした)。
  • ホイールイベント発行にxdotoolでなく、ネイティブなX11のライブラリを使う。 → 対応した。
    • PHPから容易にイベントを発行できるX11ライブラリが見つからなかったため、XTestを使ったサンプル(fakeMouse)を元にして、標準入力からマウスのボタン番号などを読んで対応するイベントを送信するプログラムを作り、本プログラムとパイプで接続して、ホイールイベントを送信できるようにした。
      • 構成: 本プログラム(標準出力) → [ボタン番号] → (標準入力)マウスイベント送信プログラム → [マウスイベント] → X11
      • イベント送信プログラムはネイティブライブラリを使っているし、イベント送信のたびにプログラムを起動せずに済むので、速度や負荷は問題ないはずである。 → 何となく、スクロールがスムーズになった気がする。
  • 設定の最適化
  • その他、設定変更機能、異常対応処理や細かい機能の追加。

 

(12/15 7:51追記) 使っていて大きな問題はないが、一部のアプリ(NixNote2)でホイールを高速に動かすと誤動作(逆方向にスクロール)する。そのアプリ固有の問題なのか、イベントの出し方に何かコツがあるのかは不明だ。ただ、xdotoolでイベントを出していた時は無視されたし、他にもこれとは関係ない問題が若干あるので、NixNote2固有の問題の気がする。

 

(12/13 8:31 改良・修正結果を反映; 9:54 若干修正、デモビデオを更新; 19:13 xdotoolを止めた件などを反映)

PS. これはいくら検索しても出てこなかったので、まだ誰もやっていないと思うが、どうだろうか? 誰かは居るかな。

PS2. もし、ご入用・ご興味のある方がいらっしゃいましたら、コメントなどでお知らせ下さい。公開を検討します。

  •   0
  •   0

○現状維持の話

先日思い付いて少し試していた、ウインドウマネージャーを入れ換える件は、結論としては止めることにした。OS(正確にはディストリビューションやデスクトップ環境)の入れ換えまでも検討したが、僕にはメリットがなさそうだった。僕の要求を満たすウインドウマネージャー・デスクトップ環境がなかったのだ。

重要な条件は以下である。

  • カスタマイズ性がいい(容易に自由に・細かく設定が変更できる)。
  • 重くない(CPU負荷が高くない、メモリ消費量が多くない)。ただし、機能は充分であること。
  • デザインがしょぼくない。
  • Xfceのように中身が古臭くない。
  • 開発が継続している。

特に、カスタマイズ性が重要だ。例えば、今回の発端となった、ウインドウ枠の幅(実際にはリサイズ時につかめる幅)を自由に変えられることだ。逆に、機能として、見た目が「すごい」こと(例: アニメーション効果)は全く不要だ。

それで、以下のようにいろいろなウインドウマネージャー・デスクトップ環境を検討、試用したが、どれも現在のXfceから移行する価値があるとは言えなかった。

ウインドウマネージャー

検討したもの: Compiz, cwm, Enlightenment, Fluxbox, FVWM, Gala, KWin, Marco, Mutter, Muffin, Openbox, Sawfish, Awesome, XMonad

まず、カスタマイズ性の点から、思想が相容れないElementary系は却下した。また、個人的にKDE系にはいい経験がないので却下した。それから、余りにも古く感じるMotif系やそれ以前のもの却下した。あと、馴染みない・余りにも汎用性のない言語でカスタマイズするもの(XMonad, Sawfish)も却下した。

それから、残ったいくつかの候補を仮想環境(VirtualBox)上のLinux Mintにインストールして試した。また、Linux Mint Xfceで切り替えて使える、Metacity+ComposingとCompizも試した。

試用結果(概要):

  • Awesome: 使い勝手が悪く(例: リサイズが枠でできない)、設定が面倒(テキストファイル)。
  • Mutter: 見た目はXfce4と変わらない。ウインドウマネージャー単体では使えず(不便・意味がない)、設定アプリなどが別途必要。
  • Metacity+Composing: Mutter同様、ウインドウマネージャー単体では使えない。(だったら、何のために入っているのだろうか??)
  • Compiz: 不安定(設定を間違えると動かなくなる)、余計な視覚効果(ウインドウの移動がぬるぬる)が多い。

デスクトップ環境に含まれているウインドウマネージャーは、それだけを入れても意味がないことが分かったので、ディストリビューションやデスクトップ環境も入れ換えてみることにした。

ディストリビューション・デスクトップ環境

検討したもの: Budgie (Solus Linux, Ubuntu Budgie), GNOME 3 (Ubuntu GNOME, Debian, Fedora), Manjaro, KDE Plasma (Ubuntu), Cinnamon (Linux Mint), MATE (Linux Mint), LXQt, Debian, Lubuntu, Arch Linux

上記と同様いい経験がないので、KDEとFedoraは却下した。MATEは今と同じLinux Mintであり、しかもCinnamonとXfceの中間で、敢えて移行する意味が余り感じられないので、却下した。LXQtなどは今より更に軽量系で高機能は期待できないので、却下した。また、純粋なGNOMEは評判が悪いので、却下した。そのため、GNOMEが標準のディストリビューションも却下した(ただ、KDEもGNOMEも駄目だと、かなり選択肢が減ってしまう)。

試用結果(概要):

  • Solus Linux (Budgie)
    • Solus: 日本語対応に問題あり(ソフトウェアセンターにfcitx, mozcなし)かつ対応ソフト不足(使うソフトがソフトウェアセンターにないことが多かった)。
    • Budgie: カスタマイズ性が特にいいとは言えない。ただし、(ウインドウの枠幅は狭く、設定変更は不可だが、)リサイズ時につかめる領域が広い。
  • Linux Mint Cinnamon
    • Budgieと同様に、ウインドウの枠幅は狭く設定変更は不可だが、リサイズ時につかめる領域が広い。
    • デスクレット(デスクトップに置く部品)、アプレット(バーに置く部品)がいろいろあって便利そう。
    • Xfceで自分でやっていたことの多くが、最初からできている感じ。
    • パネル(バー)の設定の使いやすさやカスタマイズ範囲は今一つ。設定項目は少ない感じ(意味不明な設定もあった)。Xfceの方がいろいろできるかも。
  • Manjaro (Xfce): KDEを推しているようだが嫌なので、OSを評価するためにXfceで試した。
    • パッケージのソフトがUbuntuより若干少ない感じなので、敢えて移るメリットはなさそう。
    • Xfceなので、デスクトップ環境の使い勝手は同じ(外見は違う: テーマの違いか?)。

結局、特別にカスタマイズ性その他のメリットのあるものが見つからなかったので、換えるのは止めた。そういう点では、Xfceは僕に最適なことを実感した。ただ、簡単に移行できるなら、Linux Mint Cinnamonは悪くないと思った。あと、ウインドウの枠幅は狭い(設定変更も不可)が、リサイズ時につかめる領域が広い(枠外でもある程度の範囲でつかめる)ものがあったのは、なるほどと思った。合理的で全く問題ない。しかも、見た目も(枠が太くならないので)ダサくない。ずっと前にではあろうが、進歩したことなのだろう。この点はXfceは駄目だ。僕は自分で何とかしたが、直す気がないのは余りにも意固地だと思う。

少し考えたら、リサイズ時に枠外でもつかめるようにするには、その範囲(枠の周囲)を透明な子ウインドウにするか、ある線の近くにマウスが来たらイベントを出す仕組みがあるのならそれを使う必要がありそうで、今のXfceの構造とはかなり違って来るから、簡単にはできなさそうだ。でも、前者はできそうな気もする。枠を透明な画像にすればいい?? → 試したくなった! → 駄目だった(透明部はウインドウがないことになるようで、マウスポインタが変わらなかった)。

余談だが、ウインドウマネージャーなどを試す時にマウスホイールの設定も見てみたのだが、全部同様だった(というか、ホイールの設定がない)。今のLinuxのマウスホイールのサポートは貧弱(加速しない)で、結構不満に思っている。何ページもスクロールすると指が疲れるので、そういう時は気が重くなる。何かいいソフトがないか、時々探している。もし、加速に対応しているものがあったら、万難を排して移行したかも知れないw

○非現状維持(現状打破ではない)の話

ウインドウマネージャーは現状維持でいいのだが、逆に、偶然、駄目なものを見つけた。PHPである。今はOSのパッケージにあった7.0を使っているのだが、何かのついでに、7.0のサポートが終わることを知った。今まで全く注意していなかったのが悪いのだが、寝耳に水だった。調べたら、最新は7.3のようで、全く浦島太郎状態だ。。。 0.1や0.2くらいなら見過ごすが、これはさすがに放置できない。

仕方ないので移行する方針にして、準備のために、ドキュメントでバージョン間の違いを調べたのだが、さすがに山ほど違っていて見切れないし、読んだって、自分で作っていないソフトに関しては全く判断できない(自分で作ったものでも分からないw)。仕方ないので、他者のソフトについてはその資料で対応しているかを調べ、不明なものや自分で作ったものについては、動かして試すことにした。

あと、今使っているPHPのモジュールが最新版にもあるかを調べて気になったのは、mcryptが廃止になったことだったが、インストール履歴を調べたら、今は使っていないソフトのために入れたものなので、問題なさそうなことが分かった。他には、今使っているソフトで更新が停まっていて(おそらく開発終了)、最新のPHPに対応しているか不明なものがあった。もし駄目なら、別のソフトに入れ換える必要がありそうなので、面倒だ。

○まとめみたいなこと

どっかの役人のように金科玉条のごとく現状維持しかしないのは、愚の骨頂だ。そんなの要らない。一方、Linux Mintのサイトのバージョンアップの案内には、「やみくもにバージョンアップするのは良くないです。問題なければそのままでいいんですよ」というようなことが書いてあって、この業界では結構珍しく、共感できた。まさにそのとおりだ。そして、毎年だか毎月だか知らないけど、常に素晴らしい最高の「何か」を出して強制的に更新させた挙句に問題を起こす会社には、アフォとしか言いようがない。

  •   0
  •   0