Category: Computer

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

買い物がてら，1時間半ほど本格的^^; にPokémon GOをやってきました．

途中で，弱っているPokémonが6匹いる2つのジムでバトルをしました．出発時はフル充電で．帰宅時の残量は81%でした．また本体の発熱もそれほどではありませんでした．

単純計算で，バッテリーの残量が20%まで使うとすれば，6時間くらい使えそうです．Huawei P9 Liteでは，購入直後でも3時間が良いところでしたから，文句なしです1Huawei P9 Liteのバッテリーが貧弱だったというのではなく，Pokémon GO（というか，ゲームで使われる高性能CPU）のバッテリー消費が甚だしいためです．iPhone 7でも3〜4時間程度だったと思います（ゲーム専用スマホ導入後は，連続使用してないので解りませんが^^;）．．

それと，移動しながらPokémon GOをして，気がついたのは，Wifiからモバイルネットワークへの切替がスムーズなことです．Huawei P9 Liteでは，切替時にしばしば「サーバーに接続できませんでした」と言うエラーが出ましたが，Zenfone MAX M2ではシームレスに切り替わってくれました．

もう一つ気がついたのはGPSの正確さです．これは良し悪しで，夜Pokémon GOを動かしたまま寝ると，Huawei P9 Liteでは多い日には10kmも徘徊してくれるのですが，Zenfone MAX M2はほとんど歩いてくれません^^; ちゃんと自分の足で歩くしかありません．

ゲーム専用スマホ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なのかもしれません．動きゃいいのでこれ以上調べませんが^^;