fcitxをunmergeして,ibusをmergeして,Mozcを再インストールしてみましたが,ibusがまともに動いてくれません.
ということで,Raspberry Pi 4でRaspberry Pi OSを使わないで,使える😓Workstationはできないかなという,試みはおしまいにします.
形としては何も残りませんが,Gentooの使い方と,Raspberry Pi用のKernelのクロスコンパイルと,自前のコンパイルの仕方をマスターできたのは大きな収穫だったと思います.
横断歩道での一時停止は善意ではなく義務 (Powered by WordPress)
fcitxをunmergeして,ibusをmergeして,Mozcを再インストールしてみましたが,ibusがまともに動いてくれません.
ということで,Raspberry Pi 4でRaspberry Pi OSを使わないで,使える😓Workstationはできないかなという,試みはおしまいにします.
形としては何も残りませんが,Gentooの使い方と,Raspberry Pi用のKernelのクロスコンパイルと,自前のコンパイルの仕方をマスターできたのは大きな収穫だったと思います.
ものすごく時間がかかりましたが,インストールできる範囲のKDE関係ソフトのインストールをしました.遅いながらも,Firefoxを含めて動きます.
しかし,日本語が入りません.AMD64 (x86_64)のGentooにあっさりインストールできたfcitx + MozcをRapsberry Pi 4にもインストールしましたが,うんともすんとも反応しません.日本語入力の設定をしようとしても,
というダイアログが出てしまいます.kcm-fcitxには,ARM64用はありません😓 fcitx-configtoolもありません.もう少しよく判っていれば,configファイルをエディターでいじるってこともできるかもしれません.
しかし,そもそもfcitxが全く起動してくれる気配がありません.
そこで,再度,USEフラグを “-fcitx4 ibus” にして,ibus環境でMozcを再buildしてみます.
これでだめなら,一旦終わりにします.日本語が読めても,書けなければWSとしては全く使い物になりません.
しばらく置いて,updateして日本語環境が使えるか再挑戦することにします.
結局だめ
ibus + Mozcにしてもだめでした.ibusも動いてくれません.一旦ここで終わります.
かなりswapを使ったようで,qtwebengine-5.12.2のemergeに29時間6分49秒かかりました😓
Core i7のマシン(AMD64 WS)では,4時間15分24秒でしたから,総合的なマシンパワーは6.8:1ということになります.
AMD64 WSは,32GBのメモリーを搭載していて,make -j16にしても,swapを使う事はめったにありませんが,Raspberry Pi 4 8GBは,しばしばswapを1〜3GB使ってましたが,これはけっこう大きな足引っぱりとなったと思います.
ちなみに,kde-apps-metaのemergeは,まだ続いています😓
AMD64 (x86_64)のマシンで,Chromiumのemergeをしたところ,およそ6時間10分で完了し,ちゃんと動いています.今この記事もChromiumから書いてます.
もし,AMD64 WSとRaspberry Pi 4 (RPi4) のemergeに関する総合的な速度が,先の推定どおり,3.7:1だとすると,RPi4では23時間くらいかかりそうです.
しかし,Raspberry Pi 4の実力はもっとないよう(qtwebengineのemergeは,11時に終わると見込んでいましたが,14時半を過ぎてもまだコンパイル中です)で,たぶん,24時間を軽く超えると思います.
ということで,Firefoxのほうがずっと軽いです😥
Raspberry Pi 4のGentooは,現在, kde-apps-metaという,普通のdistroならついてくる(けどほとんど使うことのない)小間物のbuildをしています.その中でも昨日からずっとかかずらわっているソフトがあって,コンパイルのステップの分母が,29072もあります.
emerge.logで見てみると,qtwebengineだそうです.UNIX Timeで “1611825911” なので,昨日の18:25から始めていて,この記事を書いている時点で,11時間半が経過して,分子の方は20500ですから,あと5時間強かかりそうです.
AMD64 (x86_64)のマシンの方で,調べてみると,たったの😥4時間25分で終わっていますから,総合的なマシンパワーは,3.7:1ということになります.ちょっと残念な数字です.
ちなみに,Raspberry Pi 4でPlasmaのスクリーンロッカーが走り出すと,スクリーンロッカーとX11でCPUの使用率の合計がほぼ100%となり,4つの内の1つのコアを専有していることになるので,多量のemergeの前には,GUIを止めてます.
ということで,一旦仕上がったところで,今後多量のupdateが来ると,何時間どころか,何日もemergeしっぱなしということになりそうなので,およそ実用的とは言えません.
ここまでやったので,KDE/Plasmaの一応仕上げまでやります.