DerpFest14は今月頭ぐらいにAlpha版の名前で出てきた時から試していました。続いて12月18日付けでBeta版がリリースされ、非常にスムースに動いてくれましたので、「これでいってみよ！」ってことでDerpFest14を常用することにしました。
前版DerpFest13の最終版に比べると、特にカスタマイズ機能については少ない感じの状態です。これは、まず先に基本機能をしっかり安定させてから機能を増やしていく、という感じの開発方針なのかな？と勝手に思ったりしています。現状でも何ら不満はありません。
OSそのものとしては13も14も大した違いが無いように思います。少なくともびっくりするような点は何もありませんし、ごく普通に安定して使えます。
無いと思ってたAndroid14をPixel 4aにもたらしてくれたので。
導入してまだ間無しなので大した感想は無いんですが、初期リリースだからか機能的には超シンプルです。最小限のGoogleアプリが同梱されビルドされています。イメージとしては「Googleアプリが少ないGoogle純正Android」という感じでしょうか。見た目のカスタマイズに興味がある方にはまったく向きません（と思います）。
ですが、極めて安定して普通に使えます。もしかしたら、そういうポリシーで開発されてるのかもしれませんが、今ドキのカスタムROMとしては、そういう開発方針も何となく新鮮な感じがします。
機能がシンプルだからこそ維持・保守の負担が小さくて済むのかもしれませんし、それだから長く開発が続けてもらえるのかもしれません。
このまましばらく使ってみようと思います。
後日よくよく確認してみたら、なんと、アダプタ（AS804）の角度が変わってしまってました。たぶん、走行振動でズレてしまったんだろうと思います。
なんでそんなことになるんか…
こんな隙間なんて前は無かったのに…と思って、よくよく思い返してみれば、一昨年、ism PN1.1サドルに交換する前はシートポストのヤグラ部とリクセンアダプタがぴったりくっついてた（と言うか、そうなるようにアダプタを削った）のに、サドルを交換してレールの形や位置が変わった関係で、こんな隙間ができてしまっておりました。その時に気づいてて放ったらかしにしたのか気づいてなかったのか気にしてなかったのか…。何にしても、この隙間をこのままにしておいては問題が再発してしまいますので、恒久対策を講じておくことにしました。
これをサドルレール幅にカットして（脱落しないよう）タイラップでサドルレールに固定しました。（左の写真はタイラップ固定前）
サドル下ですし、多少の不格好は目立ちませんし、見た目にはあまり拘って対策しませんでした。
屋内用モールの耐候性・耐久性は不明ですが、場所が場所ですしまぁ問題無いでしょ、と気楽に考えています。
っということで、これでまた１つ課題解決です。
【後日追記】
１時間ほどサイクリング（１ｋｍほどの登り下りを含む）してきて、まったく問題ありませんでした。きっちりサドルバッグの角度が維持されてます。強度的にもOKのような気がします。
crDroid + RisingOS + DerpFest という感じで表現されていて、ちょっとだけ興味がわきました。
で、入れてみた感想ですが、まんま、その通り。見た目のカスタマイズ機能としては「crDroid + RisingOS + DerpFest」でした。これ以上はもう何も要らんなぁ…というぐらい充実してます。
あまり目立ちませんが、カーネルに実装された Zen というI/Oスケジューラも良い感じです。動作にインパクトなくバッテリ消費に優しいので、けっこうナイスです。気に入りました。
テストに使えるSIMが無いので、キャリア系の通信がどんな具合か確認できていませんが、とりあえず、この先も開発が続くとよいなぁと思うカスタムROMでした。
Pixel 4a用以外にも多くのデバイス向けにリリースされているようです。
①ステム取り付け位置を３ｍｍスペーサ２つ分上に
②ハンドルバーをDixnaジェイフィットモンローFZに変更
③ブレーキブラケット上面の角度が従来より少し緩くなるように、ハンドル固定角度とブレーキブラケット固定位置を調整
というような変更によって、現在の身体状況にできるだけ合わせた見直しを行いました。
ポジション見直しがほぼできたので、バーテープも新しいものに交換しました。このバーテープがクセ者で、「テープを巻く方向が普通と違う」「左も右も時計回りで巻け」「左が反時計回り、右を時計回りで巻け」と各種の指示があって悩まされましたが、試し巻きなど行って現物確認したところ、使うテープが左右で別であること、右も左も通常通り「左が時計回り、右が反時計回り」でよいこと、が分かりました。
買ってからかなりの時間が経ったもので、夏は厳しく暑く冬は厳しく寒い暗所で保管していたおかげか、テープ裏面の糊が剥離テープに固着してしまい、バーテープ自体に裏面糊が全く無い状態で巻くことになってしまいました。巻き始めと巻き終わりをしっかり固定し、途中も緩み弛みのないよう気をつけて巻きましたので、まぁたぶん大丈夫でしょう。と思っております。
バーテープはFizik VENTO Microtex Tacky BI-Color (Black x White)です。こんな面倒なものは、二度と買いません。（ってか、限定品だったらしくもう売ってないですよね）
【後日追記】
必要あったのかなかったのかも定かではありませんが（なんやそれ）、気持ち的に「バランスさせとかんとなぁ…」という程度の思いつき。
ま、良い乗り心地になるなら何でもＯＫです。乗ってみて確認していきます。
前回記事で既に書いておりますが、概ね「もうこれで大丈夫かな」という感じになってきており、それを実際に確認している最中です。
怪我で上半身（の丈）が短くなったことに加え、通勤しなくなったこと、コロナ渦による外出控え、免疫低下による外出控え、等などが重なりに重なって圧倒的な運動不足で、全身あちこちの筋力が落ちてしまいました。その関係で、前傾姿勢をとった時に体幹で上半身を支えきれず手や腕に体重がかかってつらくなっておりました。その辺りを対策するためのポジション見直しでしたが、現状できる範囲で上手く調整できたかな、と考えております。
とりあえず「これでしばらく使ってみる」セッティングで、ブレーキブラケットの位置を僅かに上げて、ハンドルバーを僅かに前下がりにしました。（って、写真で見ても分からんですよね）
変更前のセッティングで少し乗ってみて、ほぼほぼ問題無かった（と言うかけっこう快適だった）ので、大きくいじる必要は全くなく、「下ハンの末端部をもう少しだけ水平に近づけとくかな」ぐらいの理由です。
ジェイフィットモンローFZ、けっこう気に入りました。
FZ（フィットゾーン）も、まぁそれなりに効果があるのか、いちおう指３本（中指・薬指・小指）が問題なく入りブラケットをしっかりグリップできます。が、冬用のごつい手袋をした時にどうかは...。
もうあと何回か軽く乗ってみて、問題無ければ新しいバーテープに交換します。
一昨年２０２１年の８月９月頃に少しわめいておりました掲題の件ですが、ロードバイクでのサイクリングを復活するに際して最新版アプリを導入していたのですが、やっぱり、走行データの自動転送が全く行われません。
他のBrytonサイコンユーザでどのような状況になっているのかぜんぜん分かりませんが、とりあえず自分の手元では、どんだけ長時間我慢して待ってもまったく同期せず、しかたがないのでサイコンをUSBでＰＣに接続してサイコンの中の*.fitファイルを手動でアップロードして対応しました。
この先ももうアプリは要らんかな...とも思ったんですが、なんとなく悔しいので、結局、左図のように過去使っていて一番問題の少なかったバージョン2.14.133.310をインストールしておくことにしました。（APKMirrorから拾ってきたものです）
このバージョンを使うに際して困るのが、Google Playでアップデートがかかってしまうことで、アップデート対象から外さなきゃならんのですが、いちいち手操作でやるのもバカらしいので、自スマホがたまたま Magisk＋Zygisk な環境でもあるので zygisk-detach モジュールを導入して Bryton Activeアプリを導入している事を隠蔽することにしました。
Rider410というモデル自体がもうだいぶ世代が古いこともあり、新しい機種とかでは状況が違っているのかもしれませんが、Google Play上のアプリの評価欄に問題点を指摘してもベンダ側は完全無視（★が４つ以上でないと相手しない方針みたい）なのもあって、無駄なことをするのはやめて自衛措置することにしました。
ま、スマホ上のコンパニオンアプリなんぞ使わなくても、サイコンをUSBケーブルでＰＣに接続し、サイコンの中の＊．ｆｉｔファイルを手動でactive.brytonsport.comにアップロードすれば済む話ではあります。が、いちいちケーブルで繋いで手動でアップロードして...というのも軽く面倒くさいのでｗ、アプリに拘ってみたしだいです。
そういう感じで、この件はこれにて終了。
とにかく、手の置き場がない。ブラケットを持つ位置で、どう持っても手が痛い。落ち着く場所が無い。
結局、予告していた通り、超ショートリーチ・浅ドロップのハンドルバー・ディズナ ジェイフィット モンローFZ にリプレースすることにしました。
交換後の状態は左の絵の通り。元のセッティングからは、ブラケット位置が２０ｍｍほど手前に、ハンドル高が６ｍｍほど上に変化させたことになります。
とりあえず交換作業を終えただけでまだ実走していませんが、良い結果が得られそうな予感がしております。（なんて言って、乗ってみなきゃ何も分からんですけど）
手持ち資材に９０ｍｍ／１７度ステムと１１０ｍｍ／６度ステムがあるので、上手く使って良いポジションを狙おうと思います。「慣れ」という要素も絡むので、じっくり時間をかけて詰めていくことにします。
ひとまずイニシャルのセッティングをしただけなのでバーテープは古いのを巻き戻しましたが、良い頃合いをみてバーテープも新調したいと思っています。
実際には、遠くなったワケでは（もちろん）なくて、怪我によって自分の上半身（座高）が数ｃｍほど短くなったことが主因なのですが、乗車中は両腕が伸び切ってしまう／腕にかかる荷重が大きい、と感じました。
ロードバイクに乗れていなかった長い時間によって、前傾姿勢に対する「慣れ」が薄らいでしまっていることも要因の１つかもしれません。
いずれにせよ、無理な姿勢で乗るのはよくないので、セッティング見直しで調整してみよう、ということにしました。
その結果が左の絵の通り。上段が変更前、下段が変更後。ブレーキブラケット取り付け位置を１５ｍｍほど上にズラし、ブラケットの上向き具合を緩和する為にハンドルバーをギリギリまで前下がりにセットしました。また、ステム取り付け位置も３ｍｍスペーサ２つ分上に変更しました。
新しいセッティングでまだ乗っていませんが、見た目の感じだけで「これはダメやな」というのが伝わってきます。このようなセッティングが似合うハンドル形状ではない事が一番の理由で、今回のような目的にたいしては、超ショートリーチのハンドルを使う（例えばディズナのジェイフィットモンロー）／ステム突き出し長を短くするのが正しい選択のように思います。
今時点ではまだ、どれほどの頻度でサイクリングを復活するのか（できるのか）分かりませんし、あれこれ投資する段階ではないと思ってるので、とりあえずは、このセッティングで何度かサイクリングして試してみようと思っています。見た目ほどに酷く感じないかもしれませんし、使ってみて体感するのが大事ですから。
長年の在宅ワークによる運動不足、背骨圧迫骨折からの困難な回復、抗がん剤投与による癌（多発性骨髄腫）治療中の身、という状態でどこまで走れるのか自分でも不安でした。
が、心配ばかりしてても不安は解消しないので、やっぱり走ってみてみるしか方法がないな、ということで、信貴山麓・青谷の金山彦神社まで往復してきました。
ようやく秋っぽい気温になった天気の良い日曜日、沢山のサイクリストが大和川ＣＲを走っておられましたが、その中で１人、バンバン後続に追い抜かれまくってリハビリサイクリングしてきました。だいたい20km/h〜25km/hほど、ケイデンスは70〜80ほど。
天気予報で北東の風なのは知ってたので「行きも帰りも向かい風かもな」という予想はできてましたが、行き（東向き）は今のボクにはとても厳しいものでしたｗ 以前なら金山媛神社までノンストップで行ってましたが、今日はリビエールホールで休憩が必要でした。この時点で脚がダルダル。
そこから先、青谷からの登りも当然ながら脚が動かない。結局、金山彦神社までしか行けませんでした。「あわよくば...金山媛神社まで...」とか想像してましたけど、ぜんぜんダメ。無理して登ったら帰りが危ない気がしたので行くのをやめました。もっと元気になったら...
たった22kmほどのサイクリングでしたが、自分がまたロードバイクに乗り始めることができたことが嬉しかった。背骨の骨折の後ずっと腰と背中に痛みが残り続けていますが、乗車中はその痛みがほとんど無かったことも幸いでした。
これで「また、サイクリングを復活できる」と確信できました。
安全優先で、ゆっくり・ぼちぼちと回復に努めたいと思います。
【後日追記】
昨年４月頃「サイコンマウント、どーするかな」と悩んでた件、今回ようやく確認できて、片もちのスマート型で何ら問題ありませんでした。サイクリングの復活度合いに合わせて、マウント下側に取り付けるライトを新調しようと思っています。
メイン機OSはDerpFest 13 20230910ビルドで、2023年9月セキュリティパッチまで適用済み。アイドル時のバッテリ消費を抑える為、KernelだけAzureKernelを導入。新しいのがまだ出てこないので、やむなく2023/7/2リリース分を導入。
スタンバイ機の方は、2023年8月の純正OSサポートが最終となり、LineageOS 20.0に切り替えて、LSPosed＋AOSP mod＋Pixel Launcher Extendedを使って「カスタムROM」的な設定ができるようにしています。自分に必要なカスタマイズ項目は、これらのモジュールでもおおよそ十分でした。
細かいことを言うとキリがありませんが、見た目や導入アプリ、使い勝手など、メインとスタンバイで大きな差が無いように構成してあります。
メインとスタンバイの切り替えは「SIMの差し替え」で行うことを想定していますが、もしかしたら「バックアップ用に別キャリアのSIMを用意した方が良いのかも...」なんてことも少し考えたりしています。具体的にはpovo 2.0ですが、年間1000円未満のコストで回線を維持できるので、バックアップ用としては最適かな、と。
あともう１台、上記写真を撮ったMoto G5+もまだ生き残っておりまして、Android11ベースですがLineageOS 18のビルドを継続提供してくれているビルダさんがおられるので、ありがたく使わせてもらってます。
最近、Pixel6シリーズの純正OSサポート条件について変更がありそうという話があって、６ａを含む初代Tensorチップ搭載機に対するAndroidアップグレードが５年まで保証されることになりそうなのだとか。元が、アップグレード保証が３年間、セキュリティアップデートがその後の２年間、というものでしたが、統一されて「アップグレードとセキュリティアップデートを合わせて５年間」ということなんでしょう。端末が新しくなってもOSが新しくなっても、エンドユーザ側にはびっくりするような大きな変化は何もない（と思う）ので、今持っている機種をできるだけ長くサポート継続して欲しいと思っています。
この点だけは、Appleのサポートポリシーは素晴しいと思っています。とは言え、10年間もサポートしてもらったところで、さすがにハードウェアの処理能力が辛いだろうなとも思いますけど。
ということで、今ドキなＴＷＳを物色してJabra ELITE 4を選択しました。
選定に際して候補となったのはAnker Soundcore Liberty 4 NCあたり。つまり値段的にこの辺りを狙っておりました。型落ち機であるJabra ELITE 3が某通販で9000円となっていたのを見て、初めはそれに決めかけていたのですが、別の通販で貯めてたポイントを考慮するとELITE 4でも大して差が無かったので、発売日の新しい方に決めました。
付属のシリコン製イヤーパッドはＭサイズを装着して、自分の耳にはぴったりでした。キツすぎず緩すぎず。実使用時間がまだ短いのでこの先どう思うかは分かりませんが、気に入らなければサードパーティ品を含めて見直しをかけます。イヤーパッド、しょーむない部材のクセにバカ高いっすよね。それに「Ｓ／Ｍ／Ｌのセットです」なんてスカタンな売り方してるのが多くて…。単一サイズを複数セットで売ってくれよ…。
短めのUSB充電ケーブルが付属してきますが、太くて固くて取り回しにくいです。「5V以下、2A以下の充電器を使え」と言うぐらいなら、相応の太さのケーブルで良いでしょう、Jabraさん。
ヘッドフォン本体・ケースとも、「ツルン、ツルン」てほどではないですが手から滑り易そうで…。ケースからヘッドフォンを外す時も戻す時も。最初慣れないうちは何度かヘッドフォンを下に落としました。（部屋の中だったので大丈夫でした）
ノイキャンにはあまり興味はなくて重視してません。地下鉄車内で音楽を聴いてる時にANCオンにしてみましたが、電車の走行音など周囲の騒音はそれなりに聞こえてきます。ただ、音楽再生音量はあまり大きくしなくても聴き取れるので「これがANCの効果なんかな…」と思ってますが、その程度です。ほどほどに効果はあるんだと思います。「大音量にしなくてよい」ので、電車とかで近隣乗客に音漏れ騒音な迷惑をかけずに済むかな。
外音取り込みは屋外歩行中に有効化してみました。いちおう外の各種騒音が耳に届くんですが、音の聞こえ方が生音を生耳で聞くのとは大きく違い（当たり前ですが）、それぞれの音源の方向や位置・距離感が全く掴めません。自動車・自転車乗車中はもちろん歩行中やランニング中でも「公共の場」に居る時は、こんな程度の機能では全く役に立たないですね。危ないっす。Jabra ELITE 4が「その程度の機能なだけ」で、他の機種ではもっとマシなのかもしれませんが、ま、あんまし大きな期待は持たない方が身のため／社会のため、でしょうね。
以上のような家の外での状況とは違い、室内での利用要件下ではノイキャンも外音取り込みも「ま、いいんじゃない」って程度に機能してくれるように思います。
自分的には３代目のJabra機。これからしっかり働いてもらいたいと思います。
LineageOS にしてみたり crDroid を入れてみたり、Stock ROMに戻してみたり、したんですがどれもピリっとせず、DerpFestが最も自分の好みに合ってるな、と感じました。RisingOSは開発は進められているようですが、ビルドされたものがなかなか出てこず試しようもないので、敬遠しました。
画像を見てもらえれば分かる通り、ほとんどアプリを使うことはなく、仕事や体調の事などもあって家から出ることもほとんどないので、スマホ自体はアイドル状態が異様に長い使い方になります。（それを「使い方」と言うのかどうか…）
そういった自分の特性もあっての選択ですが、アイドル時の低消費電力だけが取り柄ではなく、アプリの起動にタイムラグがあったりなんてことはなく、きびきびと動作してくれます。UIのカスタマイズも上手く揃えられていて自分には必要充分なほど。
DerpFestも、メンテナーさんの興味が薄れたりデバイスを手放したりすると開発が止まってしまうんだろうと思います。そうなった時はまた次の乗り換え先を探す旅に…。Stock ROMの寿命が残ってればそれにするし、そうでなければLineageOSにでも…
Pixel 6aの方は、このまま常用するつもりで様子見しています。DerpFestも素晴らしく良かったのですが、初物のRisingOSに少し強めの興味がわいたもので…。
Pixel 4aの方は、ビルダさんの気持ちがcrDroidに傾いてるっぽいので、RisingOSのビルドが継続されないならcrDroidに移ってしまうかもしれません。
という状況ですが、今のところ RisingOS はとても気に入っております。
Pixel 4aの方は、com.android.hbmsvmanagerという「High Brightness Mode Manager」なるコンポーネントが暴れるようでｗ、アプリのバッテリー設定を Restricted にしても完全にはおとなしくならず、やむなく adb shell pm uninstall -k -user 0 com.android.hbmsvmanager でアンインストールして対処しました。（Pixel 6aの方では、この問題はもしかしたら開発者さんの方で対処済みなのかもしれません）
Google純正OSのサポート期限が近づいてきたPixel 4aの方が喫緊の課題ではありますが、なんとか食いつないで延命したいところです。
常用スマホのPixel6aですが、Google純正OSに少し退屈してきたのもあって、ＧＷ中からいくつかつまみ食いをしてきました。
で、「ファイナルアンサーかな」と思ったのが、コレ、Derpfest 13 "Tango" です。
導入してまだ間無しですが、素性の良さは充分感じられます。Moto G5Plus で一時期Derpfestを使ってたことがあり、その時も同じように好印象／好感触でしたが、その感じが全く変わってなくて、一瞬で「これに決ぃ〜めた！」となりました。
ミニマムではなく必要なアプリを絞り込んだ格好でGappsがパッケージされており、その選択が自分の好みにぴったり合ったものですし、機能やデザインも洗練されて良い感じです。
Derpfestのウェブサイトでは、まだPixel6aが公式デバイスとして掲載されていませんでしたが、Sourceforge上の公式ディレクトリには Bluejay ディレクトリが作成されROMがアップロードされていました。
ダウンロードしたROMアーカイブ中のpayload.binから vendor_boot.img を取り出してFlashし、その後リカバリを起動してFactory Resetしてからadb sideloadでインストールしました。
バッテリの保ち具合など常用機向けＯＳとしての使い勝手はこれから検証していくことになります。
【2023/05/25追記】
しばらく使ってみてDerpfestの良さがさらによく分かりました。開発者さんがTestbuildを公開してくれていて、現状で 20230524 build に更新していますが、何１つ問題は無く（私が見つけられないだけかも）極めて安定しています。バッテリ消費は十分に穏やかですし、UIのカスタマイズもとってもクールです。
まったく予定の無かったＧＷの空き時間の多くを埋めてくれたClamAVですが、「よっしゃこれでいこ」と思ってＧＷを終えた途端に問題発覚。てゆーか、ぜんぜん上手に設定できてなかった…。
ということで、ＧＷ明けも空き時間をClamAVと戯れておるワケですが、とりあえずバッチ一括検査処理の方は「なんとかこれで良いやろ」という感じに設定できたのですが、問題は OnAccess スキャナの方。こいつがぜんぜんダメ。
一番の問題は、Clamonaccから検疫処理を依頼されたclamdが途方もなく膨大な量のWARNINGログを吐き出すこと。１〜２分ほどの間に60万行以上も記録され、且つ、LogSyslog disabled と設定しているにもかかわらずSyslogにも同じ量が記録されてしまうこと。
発生するのは/home下ですが、記録されたファイルを見てますと、アプリ等の処理で一時的に生成してすぐ消えるようなファイルが対象になってしまうようです。その為、そういうログが出る度に、ログを点検してファイル名を確認して、パス名の共通性を見出してからclamd.confにExcludePathを正規表現で追記する、ということを「運用で」繰り返す必要に迫られました。
OnAccessExcludePath（--exclude-list=）は正規表現に対応しておらず柔軟性に欠けること、OnAccessスキャンだけではなくバッチ一括検査の時にも同様問題が起こる可能性があること、からclamd.confのExcludePathを修正してその都度clamav-daemonを再起動する、ということをやってます。（めんどくせー）
現状で、clamd.confのExcludePathは以下のように育ってますｗ
ExcludePath ^/dev/ ExcludePath ^/proc/ ExcludePath ^/sys/ ExcludePath ^/run/ ExcludePath ^/snap/ ExcludePath ^/media/ ExcludePath ^/var/lock/ ExcludePath ^/var/log/ ExcludePath ^/var/run/ ExcludePath ^/var/clamav/tmp/ ExcludePath ^/swapfile$ ExcludePath ^/.*lost\+found/ ExcludePath ^/root/quarantine/ ExcludePath ^/root/\.lesshsQ$ ExcludePath ^/timeshift/ ExcludePath ^/home/.+\.lesshsQ$ ExcludePath ^/home/.+\.tmp$ ExcludePath ^/home/.+\.txt$ ExcludePath ^/home/.+\.log$ ExcludePath ^/home/.+\.lock$ ExcludePath ^/home/.+\.sqlite-wal$ ExcludePath ^/home/.+\.db-journal$ ExcludePath ^/home/.+\.sqlite-journal$ ExcludePath ^/home/.+\.store_new$ ExcludePath ^/home/.+\.vbox-tmp$ ExcludePath ^/home/.+\.xml-tmp$ ExcludePath ^/home/.+\.js$ ExcludePath ^/home/.+\.json$ ExcludePath ^/home/.+temp-index$ ExcludePath ^/home/.+/\.temp.+$ ExcludePath ^/home/.+/\{.+\}\.final$ ExcludePath ^/home/.+.[a-zA-Z0-9]{6}$ ExcludePath ^/home/.+/[0-9]+\.ldb$ ExcludePath ^/home/.+/\.cache/.+/cache2/entries/[A-Z0-9]+$ ExcludePath ^/home/.+/\.cache/.+scr--[0-9]+\.png$ ExcludePath ^/home/.+/Downloads/.+\.crdownload$ ExcludePath ^/home/.+/\.config/google-chrome/Profile\ [1-9]+/ ExcludePath ^/home/.+/\.thunderbird/.+/virtualFolders-[0-9]+\.dat$ ExcludePath ^/home/.+/\.mozilla/firefox/.+/usage-journal$ ExcludePath ^/home/.+/\.mozilla/firefox/.+/newtab$ ExcludePath ^/home/.+/\.cache/mozilla/firefox/.+-\.vlpset$
まったくバカらしい話で、「OnAccessスキャンなんて使うもんじゃない」なんて意見も見られるワケで、ほんとにそういう感じで、つまらん運用作業に手間取られるぐらいなら .cache .local .config 辺りをClamonaccの監視対象から除外してしまうのが「賢いやり方」のようにも思いますし、一時はそのように設定していました。
ただ、そうしてしまうと「何の為にOnAccessスキャンなんて動かしてるの？」ということになって「Clamonaccなんて止めちゃえ」ということになってしまいます。現状まだそこまで諦めをつけられていないので、「つまらん運用作業」を繰り返してるしだい。（バカですよね…）
使うアプリが増えたら除外条件に影響するでしょう。使ってるアプリが機能修正されても影響することもあるでしょう。そういうのにどう対応していくのが良いのか…。とにかく、ClamAVのアップデートで膨大なログを吐き出すのが止まってくれたらありがたいのですが…。Syslogが無用に肥大するのが痛すぎ。
ということで、今のところ ClamAV OnAccessスキャナ には過度の期待は持てず、徐々に機能が良くなっていくのを眺めながら運用支障の無い範囲で自分なりの良い使い方を見出すしか方法が無いようです。
【後刻追記】
ExcludePathのコード内容ですが、この日記を書いてるシリから変更せざるをえない状況が何度か発生して、とりあえず最新内容に置き換えました。
【2023/05/25追記】
心底バカらしくなって OnAccessスキャナを使うのを止めました。ログの爆発を制御しきれませんわ。こんなのに付き合ってられん…。てことで、それに合わせて clamd.conf の内容をシンプルにして、１日１回バッチ一括検査する運用でいくことにしました。そう決めたら気が楽になった…。
Linux MINTで平和に過ごしております。セキュリティ対策の基本方針として「ソフトウェアをきちんとアップデートするから、ウィルス対策アプリなんて要らん。ノーガード戦法や」ということにしていましたが、今頃になって「いかがなものか…」という気がしてきて、ようやく重たい腰をあげて ClamAV を利用することにしました。
今回自分でやってみて分かりましたが、導入/構成がこれほど大変だとは思いもしませんでした。まぁ、その「大変さ」の多くは自分の知識/技術が足りてないせい、ではありますが…。
Ubuntuにパッケージが準備されているので導入自体は簡単な話です。問題は「きちんと動かすこと」でして、これがまぁ、手数が多いうえに思った通りの結果にならずにナンギしました…。
OnAccess Scanもバッチ一括のフルスキャンも、基本的には以下のページに書いてある通りに実施しました。
Setting up ClamAV - GitHub
https://gist.github.com/johnfedoruk/19820540dc096380784c8cf0b7ef333b
この中で示されているscan.shの内容が一部間違ってて上手く動作しなかったので、以下の赤字の箇所を手直ししました。
また、ウィルス検知した時の通知とは別に、一括検査が終了した時に結果をメール通知するようにしました（その為に Postfix/dovecotまでインストール／設定しましたがな…）。日常運用的に問題が無くなってきたらメール通知は止めてしまうつもりです。
OnAccess Scanですが、説明通りに設定して実行すると猛烈なパフォーマンス悪影響で「こりゃダメや」となりました。チューニングして問題回避する（or症状緩和する）余地は何かあるんだろうと思いますが、他にやることがいっぱいあるので後回しにして、とりあえず、OnAccessPrevention false として逃げました。
OnAccess Scanが想定通りに機能させれたら定例的な一括検査はするつもりは無かったんですが、そうではなくなったので日次でフルスキャンをかけるようにしました。/proc, /devなど一部ディレクトリを除外しつつ ／ からのフルスキャン。普通に端末を使ってる裏でフルスキャンをかけてみましたが、端末操作に気になる影響は無く、ざっと2時間ほどでスキャン完了するので、まぁ、ヨシとしました。
今回導入したClamAVは v0.103.8ですが、バグが原因なのか妙なエラーやワーニングが山ほどログに記録されており、パッケージのアップデートが待たれます（と他力本願）。「そもそも」という話でいけば、VirusEvent が全く機能しないのはこの手のプロダクトとして「いかがなものか」という気がします。
OnAccess Scanのパフォーマンス影響の対策、clamd.confの整理整頓、など宿題が残っていますが、ぼちぼち対処していくことにします。
店員さんのお薦めで選んだスピーカがDIATONE DS-31Pで、それを今日までずっと使い続けてきました。四半世紀以上、ですね…
しかしさすがに寿命末期、右スピーカの出力がしだいに下がってきて、どうにもならなくなってしまいました。左右バランスを調整して誤魔化してきましたが、我慢の限界…
で、新しく調達したのが上の絵にあるFOSTEX PM0.1e。先代DS-31Pと同じく、設置場所の都合で横倒しで設置してありますが、ちゃんと鳴りますｗ
音は、小型フルレンジ一発のスピーカなりですが、机上で小音量で圧縮音楽／ストリーミング音楽を聴くぶんにはまったく問題ありません。下も上も聴きやすい音を出してくれます。
第一印象として唯一気に入らなかったのは前面の電源LED。白色ですが目に刺さりますｗので、黒のアセテートテープでおとなしくさせました。
小型スピーカなのに予想外に大きな梱包で届いて驚きました。丁寧に保護されてて好印象。また、重量も「それなりに」あって、安モン小型スピーカばりの軽々しさは微塵もありません。しっかりした感じで安心感も高い。「良質なスピーカは、それ相応に重量があるもの」と信じております。
前の日記に書いておりましたが、スリープから復帰する時、パソコン本体は復帰しているように思えるのにモニタが真っ暗なまま復帰してこないことがありました。
ハイバーネートを無効にしたり、nVidia Driverの一部設定を変更したりしましたが対処しきれずにいました。が、ようやく正当な対策らしきものを見つけました。（探し方が下手なだけ）
っということで、この投稿に記載されてある通りの対策を実施して現在様子見中です。問題の症状はまだ一度も起こっておりません。
で、その後いくつか追加で調べてみたところ、もっと簡単に「/usr/bin/nvidia-sleep.shの先頭に exit 0 を追加すりゃエエ」というものを見つけました。つまり、問題原因だったのはこの nvidia-sleep.sh の処理内容だ、てことのようで。
この方法が簡単・手軽で良いかもしれません。
Windows(MS-IME)にせよLinux(fcitx＋Mozc)にせよ、ほぼデフォルト的に「IME OFF/ONは［全角/半角］」に割り当てられていると思います。が、［全角/半角］などという「遠いキー」は扱いにくいので、随分前から [Ctrl]+[Space] をIME OFF/ON に割り当てて生きてきました。
が、それだけでは不十分な場面に遭遇することも多くなってきました。
元の［全角/半角］キーアサインを残したままだった為、数字の［１］キーをタッチする時に誤って左隣の［全角/半角］に触れてしまい、意図せず IME 起動状態が切り替わってしまったケースが１つ。もう１つは、ウェブ画面での会員情報登録時など、ウェブ側がIME起動状態を入力項目によって切り替えてしまうものがあり、漢字氏名を入力するフィールドで [Ctrl]+[Space] したらウェブ側がIMEを起動してくれてたのにそれをOFFってしまったケース。IMEの起動状態はパネルやタスクトレーを見れば判別できますが、入力中は視線は入力フィールドにあるので目視判断は難しいところ。
１つめのケースへの対策は、［全角/半角］キーをキーアサインから全て削除して対応しました。これでもう誤って手が触れてしまっても何も起こりません。
２つめのケースが少し悩ましくて、[Ctrl]+[Space] を IME ON に、[Shift]+[Ctrl]+[Space] と［変換］を IME OFF にに割り当てました。ONとOFFを分離することで「IMEが必ずONになる、必ずOFFになる」となり、この方が分かりやすいんじゃないかと思って。IME OFFに２つアサインしたのは、現時点でどちらのキーが使いやすいのかしばらく試行してみるためです。Majestouch MINILA-R での［変換］は [Fn]+[Space] として操作します。［無変換］は単独キーがあるんですが、配置がいまいちなので使用を見送りました。
[Fn] というキー自体が必須ではないフルサイズキーボード等では、スペースバーの左右両脇の［無変換］［変換］を IME ONとOFF にアサインすれば済む話かもしれません。現用中の Majestouch MINILA-R ではスペースバー両脇の [Fn] は「（自分にとっては）そこに無くてはならないキー」なので [Fn] を殺すわけにはゆきませんでした。
ＯＳ含めソフトウェア類のアップデートは適切に実施すること、ウェブ検索でヒットしたページを手当り次第に見たりしないこと、というような基本的なことは実施するとして、システム的にどのように対策しておくか、という視点で、（１）システムワイドな対策としてhblockを導入、（２）ウェブブラウザにuBlock originを利用する、という方針でいくことにしました。
hblockだけでも充分なのかもしれませんが、ブラウザでの表示レイアウトが少し崩れてしまう（重箱の隅問題）ので、uBlock originを併用することにしました。
hblockもuBlock originも広告対策的なツールと理解されているのかもしれませんが、いろいろ危ないのは広告サイト（サーバ）のような気がしますし、それを人間系で対策するのは極めて難しいと思うのでシステム的にフォローしてもらうのが良いかな、と。
作業効率面からコンソールを使うこともあるんですが、ややこしい（面倒な）システム管理をしないのであれば、もうほとんどの作業がGUIで行えるようになってます。パッケージのアップデートは素早いですし、GUI操作に関する一般的なITスキルがあれば、もう誰でも使えるOSなんじゃないか、と思います。
それはともかく、使ってて１つ気になったのがサスペンドからの復帰した時の問題。
レジュームするまでの時間が短い場合は問題無いんですが寝る前にサスペンドして翌朝起きた時にレジュームする、というような場合に「PC本体はレジュームしてる（ように思える）んだけど、モニター出力が回復しない」という状態に何度か（何度も）遭遇しました。
キーボードを操作してもマウスを操作しても[Ctrl]+[ALT]+[DEL]しても、ディスプレイの電源をオフオンしても回復せず、ハードウェアリセットかけるしか方法がありません。
いくつか試してみた結果、上の図にある「ディスプレイの電源を切るまでの時間」を「なし」にすることで解消できました。（と思いますが、もしかすると、hibernateとhybrid-sleepを無効にしたのも問題解消できた要因の１つかもしれません）
この問題とは別ですが、サスペンド期間が短時間だった場合、レジュームした時にパスワード認証しないようスクリプトで設定しました。（参考にしたページ： Linux デスクトップ環境でサスペンドモードから安全にパスワード入力無しで復帰する方法）
あと全く別件で。たまたま偶然にMozcの設定が気になって見てみたら、郵便番号変換が有効になっていながら郵便番号辞書が無いことに気づきました。
これはいかん！と、早速郵便番号辞書を整備することに…し始めたんですが、シェルスクリプトやsed/awkから長らく遠ざかっていたため、いろいろ調べる／思い出すのに四苦八苦。ウェブ上にあった有用な情報をいただきながら、なんとかスクリプトを作成して、日本郵政が公開している郵便番号データ（を正規化したデータ）を元に辞書インポート用ファイルを作成し、郵便番号辞書を用意することができました。
１回ぽっきりの作業ならスクリプトなんて作らず手作業でやれば済むのですが、元データは毎月末に更新されるようですし、毎月ではなくてもいつかまた作業するかもしれないのでバッチ一括で処理できるようにしておきました。そういう準備をした事すら忘れてしまう可能性も大いにあるんですけどね…
"KEN_ALL.CSV"でググってみて分かりましたが、日本郵政の提供データ、中身が酷いっすね。気軽に使えんやん…。だいぶ以前から世の中の悲痛な叫びが多数あるにもかかわらず、一向に修正しない…。さすが、役人・役所由来の企業さんだと改めて理解を深めました。
【後日追記】
nVIDIA X Driverの設定を一部変更して様子見することにしました。接続しているモニタに対するVSyncが復帰しないのが原因ではないか？との根拠の無い推測でｗ
【さらに後日追記】
ようやく正しい対策らしきものを発見しました。
その「アプリ」ですが、自分的には以下の３点ほど。
１つは Tap, Tap。「背面タップで設定したアクションを起こす」アプリですが、機能的には非常に良いものの、永続的安定的にバックグラウンドで機能させる為にDozeモードにならない（＝OSにKillされない）必要があります。ので、「酷い状態」では無いものの目立つ感じでアイドル時も電力を消費してくれます。自分は背面タップでスクリーンOFF（＆ロック）に設定していましたが、背面タップは諦め、DT2Sをサポートするランチャーを使うことにしました。
２つめは Facebook Messenger。電力ガブ飲みってほどではありませんが、たいした用事も無いのにバックグラウンドで動き続けて…。このサービスの重要性に見合う電力消費とする為に、Facebook Messenger Lite に入れ替えました。ITインフラ後進地域向けのみに配布されているので、Google Playでは入手できません。APKMirror から拾ってきてインストールしました。電力消費グラフで目立たない状態になりました。このアプリで気に入らないのは、素でダークモードをサポートしない点。調べてみたら、Androidの開発者オプションでダークモードを強制すれば良い、とかあったのでその通りにやってみたら、なるほどダークモードにできた。「これでOKか」と思いきや、普通にダークモードに設定できていたFacebookアプリの方の表示がおかしくなりやがった。一旦ダークモード強制を諦め、Messenger Liteは白っぽい表示で我慢することにしました。
３つめはFacebookアプリ。こちらも Lite に入れ替えました。消費電力的な問題はそれほど無かったんですが、なんとなく「Liteで揃えとくか」みたいなｗ。で、こちらのLiteは標準でダークモードをサポートするので設定しましたら、なんと、Messenger Liteの方もダークモードになってくれました（なんやねんそれ…）。まぁとりあえず、望む結果が得られたのでヨシとしておきました。
っということで、Pixel 6a の電力問題も無事解決です。
【後刻追記】
Facebook LiteとMessenger Liteの「ダークモード」に関して、Facebook LiteからMessenger Liteを呼び出すとFacebook Liteで設定したモードで起動しますが、Messenger Liteを単体起動するとダークモードになりません。という仕様なのかどうなのか、とりあえず、そんな状況です。細かいこと言うのやめますｗ
ハード自体は10年以上前のシロモノで実用的には何１つ問題がないものなのですが、Microsoft的には「新しいのに買い替えないと、新しいOSへアップグレードさせへんぞ」ということで、SDGsな時代に無用な物品買い替え強要から逃れるため、2025年10月のWindows10の寿命を待たずにLinux移行を決断しました。
選択したOSは Linux MINT ２１．１ Cinnamon。Linux MINT Japanの追加パッケージを導入して日本語対応を整備しました。
ブラウザ等でクラウドサービスを利用していたのもあり、「Windows上でやれていた事の大部分が（比較的簡単に）Linux上でもできる」ようになりました。Web上にも多数の情報があり、導入や設定で困ることはほとんどありませんでした。
使用中プリンタはキャノンのMG6130というこれまた10年以上前のもので、Linux版ドライバは提供されてはいるものの Ubuntu 10.04 が動作（導入）保証のように記載されていました。案の定、素直にインストールできず、libpng, libtiff4, libpango等を手動導入することで対応できました。また、スキャナドライバも同様に libusb を手動導入して対応。これらの情報もウェブ上で見つかって、たいへん助かりました。
Windows上で使っていた年賀状アプリを Wine で動かしてみたのですが、動きはするもののフォントの関係かレイアウトが大きくズレてしまい、実用性に乏しい状態。フォントを導入すれば解決できるのかどうか…、でも「年に１度か2度ほど使うアプリ」のためにあれこれ手間かけるのもイヤだったので、VirtualBoxを使って仮想マシン上にWindows10を導入して、そこに年賀状アプリを入れておくことにしました。
まぁ、宅内ネットワーク上に最低１台Windowsマシンがあれば良いような気がするので、おいおい対応を考えていきたいと思っています。
今まで Linux をサブマシン的に使ったことはありましたが、メインで使うのは今回が初めて。覚えなきゃならない事・思い出さなきゃならない事がたくさんありますが、ぼちぼち頑張って対応していきます。
Linux MINT 21.1 + 日本語追加パッケージ、素晴らしい完成度です。データ用ストレージとして使っていたハードディスク（NTFS）もそのまま問題なく使えています。
説明通りに見た目も中身も綺麗にして初期化して「電源ONでAndroidセットアップから始まるね」まで確認して下取りに送り出しました。
と・こ・ろ・が、年明けてしばらくして下取り屋から連絡が…。「初期化されていない為、下取り不能。返送します」と。
大した額ではありませんでしたが、こちらがちゃんと対応したのにスカタンな対応しやがって！という気持ちを抑えてGoogleサポートに連絡しましたが、「下取り委託先の決定はもう変更できません。ですが、お気持ちを察して、下取り査定満額の半額で手を打ってくれ」との回答。
こちらも入院中でしたし面倒くさいこともしてられなかったので、やむなく「これにて一件落着」となったしだい。
そういう経緯で出戻ってきたPixel 4a。放っとくのももったいない気がして少し遊んでみることにしました。Bootloader UnlockしてカスタムROMを導入してみよう、と。
試したのは BlissROM v16.3。極めて素晴らしい纏まりのあるROMで、UIのカスタマイズの種類や数なども自分的には必要十分な感じです。Face Unlockもちゃんと機能しましたし、ほぼほぼ何も問題は見つかりませんでしたが、唯一、Google Payが機能しませんでした。Bootloader Unlockを検知してるのか「この端末じゃダメよ」となりました。
Magisk(25.2)、Universal SaftyNet Fix(2.4.0 & 2.3.1-MOD3.0)などを使ってなんとか隠ぺいできないか挑戦してみましたが、今のところ突破できず。ウェブ界隈には「これでイケる／イケた」という情報も多数ありましたが、当方では歯が立ちませんでした。
じゃ、まぁとりあえずSTOCK ROMに戻すか。ということで、Pixel Flasher(4.7.0.0)を使ってTQ1A.230205.002に戻しておきました。
ハードウェアのフル機能を使いたかったら妙な改造(？)などせずSTOCKのまま使えよ、ということですかね。でも、今年(2023年)夏にはOSアップデートの提供が終了してしまうんですよねぇ…。
なかなか難しいモンですね。
【後刻追記】
システムが素のSTOCK ROMであっても、Bootloader Unlockしているだけでダメみたい。この場合に「Magisk＋USNFでなんとかできるのか」は試してないので分かりません。そもそも、STOCK ROMを使う気なら Bootloader Unlockなんてしないから。
BlissROM v16.3
Magisk v25.2
Universal SafetyNet Fix 2.4.0 MOD1.1
これらを使ってなんとか左記の結果を得ました。
しかし、これもいつまで保てるのか…Googleやアプリ側とのいたちごっこなんでしょうからねぇ…
【さらに後日追記】
BlissROM v16.4が出たのでDirty Flashでアップデートしてみました。Changelogに記載がありますが、SafetyNet対策(？)が講じられたおかげで、Magisk・USNF が無くても Play Integrity API CheckerやYASNACをPassすることができました。より一層実用性が高まった感じ。
いろいろ考えてみたところ、Androidでの常套手段と言いますか「Google Play開発者サービスのデータ消去でもやってみるか」と思い出したしだい。
もしかしたら、これが「ビンゴ！」だったかも…
極めて良好な電力消耗状態になったような気がします。（対策してまだ経過時間が少ないので自信が無い）
明日１２日からしばらく入院しちゃうので、この手の事でジタバタできるのは今日まで。これで落ち着いてくれることを祈るのみ…です。
そうした事情を込みでの話ですが、アイドル状態での電池消耗具合は比較的平和な状態に落ち着きました。
また、ネットワークのSIM設定の項にあった Allow 2G を Disable に、Preferred network type を 4G にそれぞれ変更しましたが、もしかしたらこれも（電池消耗を抑える）効果があったのかもしれません。
満充電で楽々2日以上は保ったPixel 4aほどではありませんが、端末を普通に使ってて1.5日ぐらいは保つようになりました。
とりあえずこれで、Pixel 6aの初期的な設定はすべて完了です。ランチャーはあれこれつまみ食い的に試しましたが、どれも決め手に欠け、結局デフォルトのまま使うことにしました。
聞けば、たまたまGoogleから来たメールを見たら値引販売されている事を知って、値引額が11月のBlack Fridayのセール時と同額だったため「なんとなく、お薦めしてみるか…」という事だったそうです。
大臣の意向が180度方向転換しないうちに意思決定しておかないと…
と思った途端に意識が飛んでしまい、次に覚醒した時には既に Pixel 6a本体と純正ケース が手元に配送されてしまっておりました。（なんと不思議な世の中…）
ってことで、Pixel 6a ユーザとなって新年を迎えたワケでございます。
基本的には先代 Pixel 4aと同様に「純正状態で運用」しようと思っておりますが、ランチャーだけは「何か良いモノは無いか…」と探索中です。候補的には Smart Launcher が良い感じなのですが有償版が高いので…。機能的にはMicrosoft Launcherも良いのですが、スマホの世界でMicrosoftの世話になりたくない、ので…
機種変で得たモノ
・2027年までのソフトウェア的端末寿命
・好きな箇所を消しゴムで消せる写真アプリ
・防水(IPX7)防塵(IP6X)性能
機種変で失ったモノ
・写真画像無制限Upload可だったGoogle Drive
・小型軽量だったスマホ本体
これからボチボチと手懐けていきます。
【後日追記】
旧スマホ（Pixel 4a）からの移行ではUSB-Cケーブルを使ったローカルコピー式でデータ移行をしたのですが、それが原因かどうか、6aのアイドル状態での電池消費が思った以上に大きくて、あれこれジタバタしてみたんですが改善できず。結局、ファクトリーリセットかけて純新規にセットアップし直しました。これを書いている時点でまだ様子見中ですが、電力消費に妙な点は見当たりません。このまま落ち着いてくれれば良いのですが…
背面タップジェスチャーですが、純正機能のクイックタップでは機能不足の為、Tap,Tap アプリを使うことにしました。背面ダブルタップでスクリーンOFF＆ロック、に設定しています。Pixel 4aでも同じ設定で使っていましたが、スクリーンロックされるもののスクリーンOFFにならず「そういうものか…」と思ってたんですが、6aだと見事にスクリーンOFF＆ロックになります。
【さらに後日追記】
日本時間の1/4(水) 9:00am過ぎ頃でしたが、1月度のアップデートが降ってきたのに気づきました。手元に6aが届いた最初のアップデートはOS起動した状態から普通にアップデートしましたが、4aの時の経験と同様、ものっそい時間がかかりました。（トータル1.5hほど）
なので、今回は adb sideload でのアップデートを試してみることにしました。
結果は、Full OTAの.zipファイルダウンロードも含めてトータル15分ほどで完了。このやり方の方が圧倒的に時間を節約できますね。次からもこれ式にしよう。
過日記載しました通り、癌の治療は継続中で、目下の喫緊の課題／最優先取り組み事項であります。
今月中旬に３度目の入院予定で、昨年11月に採取した末梢血幹細胞を自分の体内に戻す自家移植を行う予定です。
今日より明日がより良い日になるよう、出来る事をやっていくのみ。
頑張りま～っしゅ