ブラウザのベンチマーク (2)

バッテリー駆動 & ファンレスの自然空冷(手前のMacBook Air M4)で,SpeedoMeter 3.1でこれだけのスコアが出ることをApple Siliconを使ってない方々はご存じない.奥は強制空冷のM4 Mac mini.

以前,手持ちのいろんなPCの環境でSpeedoMeter3.1によるベンチマークを測定しました.

今回Raspberry Pi 4 Model B RAM 8GBにRaspberry Pi OS 13.4 (Trixie)を走らせてFirefoxで測定しました.スコアは0.668で最低新記録を更新しました.

Raspberry Pi 4 Model B RAM 8GB Raspberry Pi OS 13.4 Firefoxによるベンチマークスコア

M4 Mac miniでx86_64(AMD64)をエミュレートするより遅いとはなかなかです😓

比較表をupdateしました.

DescriptionSafariFirefoxChrome (Chromium)BraveOptionalComment
Macbook Air M450.639.256.353.7macOS 15.7.4
M4 Mac mini51.740.056.053.8macOS 15.7.4
M4 Mac mini w/Rosetta 249.916.60.785Intel binaryをRosetta 2で動かす.Chromeについては本文参照
iPhone 1636.3iOS 26.4
iPhone 1428.5iOS 26.4
Intel Mac mini (2018)19.913.719.918.9Core i7 6-core 3.2GHz,macOS 15.7.4
Lenove ノートPC17.818.0 (Edge)Core i7-10750H 2.60GHz, Windows 11
Google PIXEL 8a16.2
Android 16
Manjaro Linux AMD6411.17.26 (Konqueror)Core i7-4790S 3.20GHz
Nixos Linux AMD649.7210.9 (Chromium)8.21 (GNOME Web)同上
Mac mini Late 20129.625.8710.69.55Core i7 quad-core 2.6GHz
Raspberry Pi 52.534.73 (Chromium)6.55Raspberry Pi OS 13.3 RAM 8GB
Raspberry Pi 4 Model B0.668Raspberry Pi OS 13.4 RAM 8GB

VLC RTSP視聴が不安定 (2)

しかし,それではシステム全体のセキュリティー上の問題が残ります.そこでGeminiに相談して,VLC関係パッケージのみupdate/upgradeしないようにしました.

dpkg -l | grep vlc

とすると,筆者のシステムでは16のパッケージがあることがわかります.そこで,

apt-mark hold $(dpkg -l | grep vlc | awk '{print $2}')

とする1ことで,以後のupdate/upgradeでholdされた16パッケージは除外されます.

実際にこの状態で最新の13.4にupdate/upgradeして一晩経ちますがVLCは安定してReal Time Streaming Protocol (RTSP) 画像の再生を続けています.

  1. 筆者はSlackware流儀にのっとりroot権限でシステムのメンテをしています. ↩︎

Dovecot 2.4

リモートで管理しているDebianのサーバーですが,まだDebian Bookworm (12)で動かしています.そろそろTrixie (13)にupgradeするように圧力がかかりそうなので,クローニングした仮想マシンでupgradeの予行演習をしました.

まずは,apt update && apt dist-upgrade1でBookwormの最終形にupgradeします.これは全く問題なし.

次に,/etc/apt/sources.list内のbookwormをtrixieに書き換えて,apt update && apt dist-upgradeをしたところ,dovecotの再起動に失敗してupgrade自体が途中で終わってしまいました.

dovecotの設定ファイルの問題のようです.こういうときのために,仮想マシンでsnapshotを撮りながら作業していますのでbookwormの最終形に巻き戻してやり直しです.

とりあえずは,

systemctl stop dovecot
systemctl disable dovecot

としてから,再度trixieへのupgradeを試みたら成功しました.

あとはdovecotの問題の解決です.Debian (Raspberry Pi OSも)では,Bookwormにはdovecot 2.3.xが,Trixieには 2.4.xが付いてきます.2.3.xから2.4.xで設定ファイルに見直しがあったようです.

エラーは/etc/dovecot/conf.d/10-mail.conf内の,

mail_location = mbox:~/.mailbox:INBOX=/var/mail/%u

で起こります.ユーザーのディレクトリーのmboxを “.” で始まるディレクトリーにして通常のlsでは見えないようにしたいのです.

GeminiとChatGPTに聞きましたが,遠回りをして解決にたどり着きません.かなり時間を浪費しました.

AIへの相談をやめて,自分の管理しているサーバーを調べたら答えがありました.

mail_path = %{home}/.mailbox
mail_inbox_path = /var/mail/%{user}

のように,dovecot 2.4.xでは2行で既述すれば良いのです.

  1. 筆者はSlackwareの「root権限になってからシステムのメンテをする」流儀のため,ログインしてsudo -iをしてroot権限を取得してから作業します.そのため,コマンドにいちいちsudoを付けません. ↩︎

reset-failed

何気なくroot権限で1

systemctl status

で全体を眺めようとしたら,赤い字で “degraded” と出ます.

これまでも出ていたと思いますが気にしていませんでした.せっかくですからAI (Gemini)に聞いてみました.

systemctl --failed

で,certbot.timerであることがわかりました.以下省略しますが,もともとSlackwareでLet’s Encryptから証明書を “手動” で発行してもらっています.その場合,自動で更新できないようです.どっちみち管理しているもう一か所も手動なので,いつも2台続けて更新作業をしてきました.ですので,certbotによる自動更新を止めます.

systemctl disable --now certbot.timer
systemctl reset-failed certbot.service

これでめでたく “degraded” が消えました.

  1. 筆者はSlackware流儀のため,システムのメンテはroot権限で行いコマンド毎のsudoは使いません. ↩︎

RPi4とRPi5の比較

Raspberry Pi 4 Model B (RPi4)とRaspberry Pi 5 (RPi5)のRedis Object Cacheの反応時間の比較です.

Raspberry Pi 4 RAM 8GBのRedis Object Cacheの反応時間
Raspberry Pi 4 RAM 8GBのRedis Object Cacheの反応時間
Raspberry Pi 5 RAM 8GBのRedis Object Cacheの反応時間
Raspberry Pi 5 RAM 8GBのRedis Object Cacheの反応時間

差は歴然としています.RPi4ではピークが39msで平均は目の子で23msくらいですが,RPi5ではピークは14ms,平均は5msくらいです.

ざっと5倍くらい速い,というこれまでもっていた印象があてはまります.