ゲーム専用スマホ2代目(Zenfone MAX M2)

Pokémon GOをするのに応答性が悪いと認識しつつも,まる2年間Huawe P9 Liteを使い続けました.購入したのは,モデルチェンジの直前で値段が下がったときだったので,モデル的にはまる3年前のものです.

当時はそれでも十分満足でした.Pokémon GOの応答性の悪さも慣れればどうにかなりました(人間の適応能力は偉大です^^; ).

Pokémon GOを普通にしながら通勤すると,1日で1回〜1回半くらいの完全な充放電となります.したがって,1年で400回以上フル充放電をすることになり,バッテリーには酷な使用条件です(これがために,メインのiPhone 7でPokémon GOをしなくて良いように,ゲーム専用スマホを導入したわけです^^; ).

去年の夏に,バッテリーの持ちが低下してきたので,通販サイトから交換用バッテリーを買って自分で交換しました.しかしそれから9か月ほどで,また,明らかにバッテリーがへたってしまったので,今回2代目の購入に至りました.

アメリカの言いがかりで会社の存続の危機にあるGlobal企業Huaweiは今後も応援したいのですが,かといって,私個人が経済的なリスクを負うのも辛いので,苦渋の選択ですが,いったん最終候補としたHuawei Mate 20 Liteでなく,Zenfone Max M2を購入しました.まだこの春に出たばかりのモデルにもかかわらず,型落ち寸前で買ったHuawei P9 Liteよりも安かったです.

起動して,移行のインストラクンションに従って簡単に設定が引き継げました.

さっそくPokémon GOを動かしてみましたが,iPhone 7よりは応答性は落ちますが,気にならないほどです.

Zenfone MAX M2は,メモリーが4GBもあるからか(Huawei P9 Liteは,2GB),OSが進化した(Huawei P9 Liteは,Android 7.0ベース,Zenfone MAX M2はAndroid 8.1ベース)からかは解りませんが,バックグラウンドに残っているアプリがいくつもあっても,Pokémon GOの応答性は変わりません.まあ,これが当たり前のはずなんですが,Huawei P9 Liteでは,バックグラウンドのアプリは全部終了させておかないと,Pokémon GOの応答性が著しく低下しました.このこともあって,名実ともに「ゲーム専用スマホ」だったわけです.

なんか,普通のスマホとして使えそうなので,使い道をちょっと考えてみようと思いますが,Pokémon GOによってバッテリーが酷使されるという事情は頭に入れて使わないといけません.

Slackware ARM: ntpパッケージupdate時の注意

自分宛の注意事項です.

Raspberry Piは,バッテリーで駆動される時計を持っていませんから,起動時は1970年1月1日になってしまいます.

Slackware ARMは他のdistroと違って,起動スクリプトにこれをなんとかする仕組みがないので,ntpdが同期して最初に内蔵時計を更新するまで,1970年1月1日のままで,いろいろ不都合が起きます.

そこで,rc.ntpdのstart()内に,ntpdateを使ってとりあえずどこかの時間サーバーから時刻をもらってくるコマンドを書き加えています.

しかし,ntpのパッケージをupdateすると,オリジナルのntpdateコマンドの入ってないスクリプトに上書きされて,この機能が失われてしまいます.

ということで,リブートしたとき1970年1月1日になるようだったら,rc.ntpd-has-ntpdateとして保存しているスクリプトをrc.ntpdに上書きコピーすること(念のため当該スクリプトが更新されていないかも確認する).

CWKはLibreOfficeで読める

ときどき,自分のPC(Macintosh)や,サーバー内に,”.cwk”という拡張子のファイルが見つかることがあります.これは,もとはApple Works(さらに前はClarisWorks)で作成したドキュメントのファイルの拡張子です.

けしからん事にAppleは,AppleWorksをディスコンした後,AppleWorksで作成されたファイルを読み込める機能のソフトを提供していません.

今日,中身を,とある目的に再利用できる可能性のあるファイルを見つけたんですが,そういうわけで読み込む方法がなく,中身をダンプして,テキスト部分だけ抽出して,文字コード変換でもしようか考えていました.

ネット検索範囲を英語のforumまで広げたところ,LibreOfficeで読み込めるのではないかという情報を見つけたので試ました.若干の字化けがあったものの,みごと再利用できる状態で読み込むことができました.

Kernel 4.19.36ではext4(SLAB?)関係のバグ改善か(Raspberry Pi)

以前,Raspberry PiのKernelが4.14系列から4.19系列になったときupdateしたら,rsyncを使う自作バックアップスクリプトを実行すると,rsync実行中にシステムが無応答になったので,しばらくKernelを4.14系列の最終1Raspberry Pi用としての「最終」.の4.14.98-v7+にとどめていました(「Kernel 4.19.xはRasPiにNGか」).

昨日,久しぶりに,4.19へのupgradeを敢行してみました(4.19.36-v7+)ところ,1度目のバックアップスクリプト実行は,トラブルなく終わりました.

まだ,1度だけですが,以前は1度で確実にトラブりましたので,改善された可能性が高いです.しばらくこのまま様子を見ます.

追記

よく理解しているわけではありませんが,rsyncによるバックアップ中slabtopで観察していると,4.19.23, 25のときは,ext4_inode_cacheのcache sizeは増える一方で制御が効いていないようでしたが,4.19.36では,増えたり減ったりしています(「アンダーコントロール」の状況^^; ).

SLAB関係のbugというよりは,ext4関係のbugなのかもしれません.動きゃいいのでこれ以上調べませんが^^;

やはりTwitterはあかん

いちおう,Twitterでもヘイトスピーチ的なtweetは消去するような対策が取られたというので1年半ぶりに復帰してみましたが,一応そういう体制はあるものの,完全には機能していないようです.

ということで,またしばらく,Twitterでの活動は控えます.

また,Facebookについては,セキュリティー情報の漏洩などの度重なる不始末に対する意思表示として,また,公には書きにくい個人的な事情により,完全停止はしませんが,ごく一部の方々とのみの交流という具合に,活動範囲を狭めることにします.