電話着信やデータ通信の不具合を改善も、やっぱり遅いGoogle Pixel7 アップデートの配信

「Pixel 7/8/Fold」でソフト更新、電話着信やデータ通信の不具合を改善

配信されているらしいが、使用している端末ではアップデートが確認できず。やっぱり配信が遅すぎ。こういう大事な修正は、真っ先に配信を全端末に行うべし。

ぜんぜん変わっていない。こういうのは良くないと思う。Googleの対応はクソという感想しかない。Android自体の評価も下がります。

Androidの端末を使用しているのは、仕事で表示確認の実機調査用のため。仕事で不要になったら、もう必要ないくらい。

メインはiPhone使ってます。iPhoneで、こういう重要なバグ修正の配信が遅れることはないので、安心してメイン端末として使えます。

追記:
どうもSIMが刺さっていると、遅延するらしい。SIMを抜いてWifi接続にて、設定でアップデートメニューを選択すると、更新ができた! こういうの良くないですよ。感じ悪い。

INTEL N100搭載のmini PCを購入

いままでRyzen7 3750H搭載のmini PCを使用していたが、ファンの音もうるさくなってSSDもくたびれてきたので、リプレース用として購入。
この価格で(購入時はクーポンもあって23,000円程度で購入)、このスペック。セットアップしたが、きちんと動作し、もたつくところもない。

初期のOSは22H2だったので、ちょっと設定に手間取ったが、23H2にアップデートしたあとは問題なく、動作している。

今回購入したAskHandのmini PCは、Windows11 ProのOEM版を搭載しており、きちんと認証が通った。リテールのWindows11 Proの値段が28,380円であるが、そのOSの金額より安い価格でOSつきのハードウェアが購入できるとは、価格破壊もいいところ。

(ライセンスの確認等は「ミニPCガチャ」で、Windowsがボリュームライセンス外れを引いた時の作業メモが詳しい)

Hyper-VでWindows10を動かしたり、WSLでLinuxを動かしたり、Officeを動かしたり。メモリが16Gなので同時に動かすのは厳しいが、それぞれ必要な時に起動させる程度であれば、まったく問題ないレベル。ゲームをしない普段使いなら、この値段、このスペックで充分と思います(と書きながら、普段使いはM1 Macbook Airだったりしますが)。

ちなみに、ストレージはこんな感じ。アイドル時は30度くらいの温度で低温安定。

HWMonitorで見るとこんな感じ。ファンの音が発生しているのに、ファンを認識していない模様(Amazon商品説明欄にも「AskHand専用の冷却ファンと銅製ヒートシンクを含むアップグレードされた冷却システムを搭載しています」と書かれているから、ファンは搭載されているはず)。

さすがにCPUまわりは、ローパワーなのに鞭打って、ずっと稼働している。が、50度前後であまり高温にはなっていない(これはディスプレイを4Kで出力している時、FULL HDの場合はCPUは4つのコア全部が800MHzと最低限のパワーで動作します。流石に4Kはちょっと厳しいようです)。

再インストールなどの場合は、ドライバを別途インストールする必要があるようですが、この配布先がOneDriveに共有になっていて、セキュリティの面でちょっと怖いところもありますね。

Google Pixel7 アップデートの配信が遅い

2023/12のアップデートが発表され、配布が始まったとニュースになっていますが、自分のPixel7では、2023/11が最新と言い続けています。

アップデートはローリングリリースということで順次配布となっており、順番が来るまで配信されないようですが、多くのセキュリティの問題が出ており、こういうのは迅速に適用すべき内容であると思いますが、こういうのが順次配信ということで置いてきぼりにされているのがPixelの問題だと思います(しかもいつ配信されるのかがわからないまま放置される)。

他メーカーの他機種のAndroidと比べて、きちんと毎月のアップデートが配信されるのは評価できますが、こういうローリングリリースはやめていただきたい。

AppleのiPhoneのiOSは、アップデートのリリース発表とともに配布がされていつでも適用可能になっていますが、どうしてAndroidはこういったリリース対応ができないのでしょうか。これだけでもAndroidをメイン端末にするのを忌避してしまいます。

2023/12/13追記
12/07リリースの更新が12/13にようやく配信されたので、適用。約1週間、時間かかりすぎ。リリース時点で詳細発表されているため、セキュリティ問題でインシデント起きてもおかしくないですね。こういうのはAndroidのOS更新だけでなくGoogle Playのアプリ更新でも起きていて、アプリの作者が「更新配信しました」と言っていてもGoogle Playにアクセスすると更新されていないことが多々あります(GoogleをログアウトしてGoogle PlayのサイトにWEBアクセスすると更新されているバージョン配布されているが、そのままWEBログインすると更新前の記述になっている)。こういうの良くないです。

Ubuntu設定メモ

Ubuntuのサーバ設定で主なポイントをメモします。

TimezoneがUTCになっていたので東京に変更。

# timedatectl set-timezone Asia/Tokyo

ホスト名を正しくつける。

# hostnamectl set-hostname www.example.com

Firewallはincomingだけ制御できればいいので、ufwでお手軽設定。80と443を開け、22をlimit設定。limit設定で不正アタック時に自動でブロックする設定になる。

# ufw enable

# ufw allow 80

# ufw allow 443

# ufw limit 22

# ufw status numbered

MySQL 8.xをインストール。

# apt install mysql-common mysql-client mysql-server

PHPは必要なモジュールをあれこれインストール。

# apt install php-fpm php-mbstring php-mysql php-pgsql php-sqlite3 php-xml php php-all-dev php-apcu php-apcu-all-dev php-bcmath php-bz2 php-cli php-cgi php-common php-curl php-date php-dev php-gd php-imagick php-imap php-json php-mail php-mail-mime php-mbstring php-memcache php-memcache-all-dev php-mongodb php-mongodb-all-dev php-mysql php-pclzip php-pear php-pgsql php-php-gettext php-ramsey-uuid php-random-compat php-readline php-redis php-redis-all-dev php-soap php-snmp php-tidy php-uuid php-uuid-all-dev php-xml php-xml-rpc2 php-xmlrpc php-yaml php-yaml-all-dev php-zip php8.1-opcache

Webサーバはnginxをインストール。

# apt install nginx

php-fpmのインストール規定の設定がソケットになっているのでnginxからの接続をIPアドレスからソケットに変更。

#fastcgi_pass 127.0.0.1:9000;
fastcgi_pass unix:/run/php/php8.1-fpm.sock;

/etc/nginx/conf.d/ssl.confから抜粋

MySQLはrootアカウントでアクセスしてユーザー設定する。MySQLのrootは初期状態でパスワードなし、Linuxのrootでアクセスするとそのまま繋がる。

# mysql -u root mysql

MYSQL> CREATE DATABASE データベース名;
MYSQL> CREATE USER ‘ユーザー名’ IDENTIFIED BY ‘パスワード’;

MYSQL> GRANT SELECT,INSERT,UPDATE,DELETE,CREATE,DROP,ALTER,LOCK TABLES,CREATE VIEW, SHOW VIEW ON データベース名.* TO ‘ユーザー名’;

サーバOS更新

このWEBサーバは、いままでCentOS7のVPSを使用していたのだけれど、そろそろ重い腰をあげてOSを更新。というかサーバごと入れ替え。

新しいサーバはUbuntu 22.04のVPS。別の環境への引っ越しで、クリティカルな部分はないもののあれこれめんどうだった。

先の見えないCentOS。またCentOSでのメジャーアップグレードも規定の方法がないのでサーバごと入れ替える必要があり、今回はディストリビューションをUbuntuに変更した。OSは使い勝手のよいFreeBSDでもいいかな、と思ったけれど、サーバ用OSとしてメジャーなLinuxに慣れておくことも重要なためUbuntuを選択。

環境の大きな違いは、CentOS7ではremiのレポジトリを入れてPHP8.2をインストールしていたのだけれど、Ubuntuでは標準でインストールできるPHP8.1にしていることくらい。これも大きな問題ではなく、そのままアプリケーションは移行できた。

きちんと新サーバが動作しているので、旧サーバは月末までに解約しよう。

macOS Sonoma 14.0 に対応したESET Cyber Security Proを入手する

もうすぐ、maoOS Sonoma 14.0がリリースされるが、それに対応したESET Cybet Securityについては、日本でのサポートを行なっているキヤノンマーケティングジャパンでは、現時点ではまだ「未対応」とされている。

実は、すでに対応バージョンが存在する。macOS Sonoma 14.0に対応したESET Cyber Security Proはこちらからダウンロードできる。
https://www.eset.com/int/home/cyber-security-pro/download/

日本語版はリストには存在しないがEnglish – United Statesを選んで、「DOWNLOAD」のボタンのリンクをコピー
https://download.eset.com/com/eset/apps/home/ess/mac/latest/eset_cybersecurity_pro_en.dmg
末尾の_enを_jp _ ja に変更すると日本語版が手に入る。
https://download.eset.com/com/eset/apps/home/ess/mac/latest/eset_cybersecurity_pro_jp.dmg
https://download.eset.com/com/eset/apps/home/ess/mac/latest/eset_cybersecurity_pro_ja.dmg

正式な日本語サポート対応版ではないので、ご利用はご自身の判断でどうぞ。不安な場合は、キヤノンITソリューションズのサポートが「対応」と言うまで待ちましょう。

追記2023/09/26
依然としてApple Siliconにネイティブ対応していないようだ。Intelアーキテクチャのみのパッケージング。そろそろネイティブ対応してほしい。

ちなみに、Sonomaに対応していないESET Cyber Security Proのまま、OSのアップデートをすると、このあたりの情報ではネットワークが死ぬらしいので注意。

追記2023/09/27
さくっとSonomaに更新。ESET Cyber Security Proもきちんと動作しているようです。

2023/09/29更新
キヤノンITソリューションズより、macOS Sonoma 14.x への対応についてにて対応バージョンが公開されました。対応版はV6.11.414.0とのことで、上記の先行してのインストールしたバージョンと同じものです。

Amazonを騙るspamメールが届いた

というようなフッターのついたspamメールが届いた。

Amazon Japanは合同会社だし、フッターに(C) Sumitomo Mitsui Cardとはどういうことだ。

Amazonの利用規約に書かれている正式な会社名、連絡先はこちらです。

一部のファイルが利用できなかったため、バックアップの作成が完了しませんでした。Macのロックを解除するとバックアップの作成が再開されます。

MacのTimeMachineで、初期化したHDDを接続後、初回のバックアップにて「一部のファイルが利用できなかったため、バックアップの作成が完了しませんでした。Macのロックを解除するとバックアップの作成が再開されます。」というエラーでバックアップに失敗。

Macを再起動して、再度初期化したHDDを、あらためて繋いで初回バックアップを試みても、エラー再現。何が起きているのかさっぱりわからない状況。

そもそも、新規にTimeMachineでバックアップを取るのは、このところ、1ヶ月〜2ヶ月程度のバックアップ期間で、なぜか古いバップアップが認識されなくなって、でもディスクは使用したままという謎な挙動になってしまい、ディスクの容量不足になってしまうため。これはこれで、TimeMachineの挙動としてはおかしいが、HDDを初期化して繋ぎ直して、新規バップアップをとれば、いままではなんとか復活していたのだが、本日ばかりはちょっと、トラブル。

初回のバックアップでエラーが出る、MacのハードやOSはこんな感じ。

エラーの状態からバックアップを再度行うと、1回目のバックアップとして完了。HDDを見るとinterruptedの失敗のディレクトリが残っている状態。そのあとで1回目の成功のディレクトリができている。

これ、どういう状況なんでしょうか。これで1回目のバックアップは正しく取れているのでしょうか。リストアしていないので、成否がわかりません。

2023/09/22追記

本日、またディスク容量とバックアップ履歴がおかしくなる事象が発生し(ディスクを直接見ると8/27からのディレクトリがあるのにTimeMachine管理画面では09/20からのデータしか見えず、それ以前のデータはアクセス不能で削除もできない状態)、またHDDをフォーマットして繋ぎなおし、バックアップ指定した。今度はエラーなく初回バックアップに成功した。

どうもディスク容量と履歴がおかしくなるのは、このところの何回かの事例発生から想像するに、古いバックアップが1日ごとになっている状態で、ディスクをぎりぎりまで使って次のバックアップの際に、1日単位のバックアップを消さないといけないときに発生するのではないかな。macOS 13 Venturaに更新してから発生しているので、OSのバグの予感。もう直ぐ、macOS 14がリリースされるが、修正されているだろうか。

Windowsのプロセスを強制的にkillするには、wmicコマンドのdeleteオプションを使う

taskkillコマンドを使う

taskkill /f /im explorer.exe

taskkillではアクセス拒否されてしまい、killできないこともある。管理者権限で指定しているのだから、killできないとおかしいのだが。

これでも言うことを聞かない場合は、こちらを試す。

wmic process where "name='explorer.exe'" delete

これなら、確実にプロセスをkillできるようだ。

wslでsystemdを起動する方法

wslを起動してから、

$ sudo vi /etc/wsl.conf

でエディタを起動して、以下を記述する。

[boot]
systemd=true

これで、次回のwslの起動から、systemdが自動起動してinitの処理を行うようになる。ただし、initの処理が走るためにwslの高速な起動が、もっさり起動になってしまうのが、玉に瑕。