fcitx(4) vs fcitx5

ManjaroでもDebianでも,fcitx4はfcitx,fcitx5はfcitx5と呼んでいるので,ここでもそうします.

fcitx-mozcもちゃんと動くのですが,唯一使いにくい点があります.それは,半角英数モードと,日本語入力モードの切り替えが,トグル式しかないのです.

トグルとは,情報系では「同じ操作で2つ(以上)の状態が入れ替わる」とされていますが,電気系的には棒の出たスイッチで上でオン,下でオフのような明確な切り替えになりますから,全く別物ですね.ここでは情報系の,同じ操作で状態が遷移する方で行きます1Toggleの語源についての説明を見つけました. “Tugging Alterations” The Ethymology Nerd

日本語入力をするときに,文章や全体の構成などを考えながらタイピングしますから,ちょっと入力が止まったあとなど,今の入力モードをしっかり把握しているわけではありません.

従って保険のために,日本語入力キーを押すことが多く,それが癖になっていますが,それがトグル式だと保険の操作で逆に半角英数モードになってしまい,円滑な入力操作をかえって阻害します.

fcitx5では,日本語入力のオンとオフをそれぞれ別のキーにアサインできます2トグルも残っています.ので,保険的な操作で意図しない入力モードの遷移が起きません.

それでfcitxが動いているDebian(Core i7のサブworkstation=サブWSのサブOS)をfcitx5にしたかったのですが,いつも失敗していました.

Mozcがまともに起動せず,設定もできない状態でした.たふん,ライブラリーや設定ファイルの残骸が残っていてコンフリクトしているのだろうと想像していました.

しかし,DebianはサブWSのサブOSの位置づけですから,これで日本語入力が必要になる場面はほとんどなく,これまで放置していました.

今回,サーバーのOSをDebian arm64にするので,サーバー上での作業記録を日本語の文書に残す必要があり,したがって,fcitx5が必須となったので,Raspberry Pi 4 Model Bへのインストールや,Debian amd64のサブWSサブOSでいろいろいじって,ようやく,誤ってインストールしたfcitx-mozcを削除した上でfctix5-mozcをインストールしてちゃんと機能するようになりました.

できてしまえばたいしたことないのですが,

apt remove fcitx-mozc
apt remove fcitx
apt remove fcitx5
apt autoremove

を行った後に,ユーザーのホームディレクトリーで,

find -iname "*fcitx*"

として,fcitxの設定ファイルを探し出して3~/.config内にあると思います.をそれを念のため消してから,1度WSを再起動してから,

apt install fcitx5-mozc

をして,もう一度WSを再起動したら,fcitx5でMozcが使える様になりました.

たぶん,要らない再起動や,Log off / on で済むところもあると思いますが,systemdのDebianは起動が速いんで気になりません.

サーバーはDebianでいくことに

サーバーのdistroをGUIの動く64bit OSに切り替えるプロジェクト

Manjaroは,workstation (WS)としては優秀ですが,KVMのIPv6設定で苦戦するなど,システムいじり的に難航したこともあり,Debianで行くことにしました.

Raspberry Pi OSはDebian由来ですが,DebianそのものをRaspberry Piで動かすことができるとつい最近知りました.さっそく予備機扱いのRaspberry Pi 4 Model B 4GB RAM (RPi4 4GB)で試してみました.

DebianのサイトからダウンロードしたイメージにはGUIは含まれていません.いったん,apt update ; apt upgradeをした上で,kde-plasma-desktop, kde-full, fcitx5-mozcの順にインストールすると,Mozcで日本語入力できる,KDE Plasma Desktopが完成します.

kde-fullは,kde-plasma-desktopを含んでいるはずですが,先にkde-plasma-desktopをインストールした上で,kde-fullをインストールしないと,なんか変な状態になります.

また,fcitx5でなく,fcitxをインストールしてしまうと,removeしてからfcitx5-mozcをインストールしてもちゃんと機能してくれません.

こんなわけで,インストール過程では行きつ戻りつができないこともあり,新規にやり直して,ようやく4度目で思ったようなGUIのシステムができました.

その他のプジェクトの状況

Paspberry Pi 3 Model B(+)で監視カメラのストリーミング映像を見るプロジェクト

強制空冷式ケースの輸入に難航中.

仮想マシンのIPv6化プロジェクト

SLAAC, DHCPのどちらの方法でも仮想マシンがグローバルIPアドレスを取得できるようになりましたが,IPv6でインターネットに出られないまま進展なしです.

Wi-Fiルーターからデータが途絶する条件の絞り込み

その後データ途絶が発生していません.テレワークでクラウドを使うという一番Wi-Fiのヘビーユーザーの家族がいますが,仕事中にまた途絶しては困るので別のルーターからつなぐようにしたこともあって,トラブルが出にくいのかも知れません.トラブルが出ないならそれはそれでいいのですが.

仮想マシンのIPv6現状 (2) 6年前よりちょっと前進

ちょっとだけ進みました.仮想マシンが取得するIPv6のアドレスを,意図したとおりに,

  • IPv6のDHCPで与える
  • SLAACで降って来る形で与える

が可能になりました.仮想マシンがSLAACでIPv6のグローバルなIPアドレスを取得できたのは,今回が初めてではないかと思います.

なお,DHCPの場合は,Gentoo Wikiに書かれている通りでいいですが,SLAACで与えるには,IPv6の仮想インターフェース(virbr0など)をpreifxが64bitにしないとだめなようです(Gentoo Wikiの例では96bitにしている1DHCPの場合は,prefix 96bit長でも大丈夫です.96bit長や,112bit長にしたほうがルーティングしやすいように思いますが,まだ,仮想マシンからインターネットにIPv6で出られないので,なんとも言えません.).

その “正しい” 方法は,libvirtのドキュメントに書かれているそのまんまです😥

あとは,ルーティングの問題ですが,DHCPにしても,SLAACにしても,アドレスを取得した仮想マシンのそのままのルーティングではなんにもできないようです.

それで手動でルーティングの設定を,ああでもないこうでもないといろいろ試していますが,今のところちっともうまく行っていません.

ホストのManjaroが,IPv6を転送しない設定(または仕様)なのかなと感じているほどです.

仮想マシンのIPv6現状 〜6年前と同じ😓〜

今日は暑いけど,死ぬほどは暑くなかったので,懸案の畑の除草耕耘をしました.1時間ちょっと運転して,ローターから草を取るためエンジンを止めたら,2度とかからなくなりました.想定の範囲内ではありますが,明日に回す領域が多く残ってしまったので,もうちょっと耕したかったです.

さて,一番進めたい,監視カメラのモニターをRaspberry Pi 3 Model B(+)でしようというプロジェクトですが,中国の通販サイトに手頃なヒートシンク付きケースを注文したのに発送されません.5日延期しましたが,だめみたいで返金になる見込みです.

で,まあかなりどうでもいい部類の仮想マシンのIPv6化プロジェクトに取り組んでいますが,これも壁に当たっています.

自分のBLOGを調べたら,6年前に同じことをやって同じところで頓挫していたことが解りました.

さてどうしたもんでしょう.

突如として速度が大幅低下・切断するルーター

いやー参りました.先日のLANのトラブル1BLOGには書かなかったようです.,どうもMesh Wi-fiルーターが原因のようです.

今日もLAN内の不具合が発生しました.接続は切れないけど,速度が1Mbps以下に低下する機器が何台か生じました.トラブルの概要は,

  • LANケーブルでつないでいる機器の速度低下はない
  • Mesh Wi-Fiルーターの親機近くのWi-Fi接続の機器がWi-Fiにはつながったまま大幅に速度を落としている(一部当該Wi-Fiとの接続が切れていたものもある)
  • 速度の低下したスマートフォン2家庭内ではもちろんWi-Fi (LAN)につないでいます.を,Mesh Wi-Fi子機の至近距離に移動したら速度が回復した
  • Mesh Wi-Fiの親機を電源リセットしたら,親機至近のWi-Fi接続機器の速度も復旧した

というものです.

これまでも,しばらく使っているとデータを転送しなくなるEthernet HUBや,Wi-fiルーターに当たってしまった経験がありますが,今回は上記のような状況からしてMesh Wi-fiのルーターがそれのようです.

素人の推測ですが,ルーティングテーブルや,健康状態のためのデータのカウントなどを保持していて,想定外の数値に達して,動かなくなるものがあるようです.

以前職場で使っていた国内有名Wi-fiルーターメーカーの品が,ある程度の時間使うと必ず止まってしまい,このときは客観的に判断して他の原因が考えられませんでした.

健康状態のカウントで,機能不全になるSSDがあるようですから,他の機器で起こらない保証はありません.

数日前に発生したトラブルでは,ギガビットHUBが怪しいとにらんだのですが,その推測は外れで,Mesh Wi-fiの親機の方のようです.今日のトラブルでは,LANのトポロジーは変えず,電源リセットも当該のWi-Fiルーターだけ施して,LAN内の全ての機器の速度は回復したので,たぶん間違いないと思います.

NuroにしてからLANからインターネットのアクセスが快調で満足していましたが,たぶんメーカーも想定してないデータ量なんだと思います.

もう少し様子を見て,原因の機器を確定させたいと思います.