Lycolog

Xperia 1 VIIIを買った話ではケースはZEROSHOCKがいいかなーと思ってZEROSHOCKを買ったのだが、MagSafe対応で磁器があると舞奈カードの読み取りなどで都合が悪く、ついでにZEROSHOCKは重くかさばるため、SpigenのRUGGED ARMORも買ってみようというので結局両方買ったやつ。

ZEROSHOCKの方が早く出ていたためSpigenのRUGGED ARMORが届くまでの一週間はZEROSHOCKを使っていた。

• ZEROSHOCKとRUGGED ARMORの比較写真
  • 表面（スマホはめるとこ）
  • 裏面
  • 下側
  • 上側
  • 操作感
• あとがき

ZEROSHOCKとRUGGED ARMORの比較写真

表面（スマホはめるとこ）

写真撮影の都合でややこしいが左がSpigenのRUGGED ARMOR、右がZEROSHOCKだ。

大きな違いとしてはZEROSHOCKの方が大きく、特に四隅のバンパーがゴツく、いかにも保護してくれる感じだ。多分よほどのことがなければ角が壊れることはないだろう。ZEROSHOCKには内側にハニカム構造があるため地面にバシーン！と落としてしまったときにもダメージは少ないと思われる。しかもカメラの段差分の分厚さがあるからなおさらだ。

とはいえ、四隅に関してはRUGGED ARMORにもエアポケットがあるため、最低限の保護はある。

また地味な部分だが、ZEROSHOCKは電源ボタンの表側に梁が入っており、表側から指を滑らせて電源ボタンにアクセスしづらいのに対し、RUGGED ARMORはそう言ったものがなく素直にアクセスできる。

裏面

裏返してみたところ。

ZEROSHOCKはカメラの段差を極限までなくしているがRUGGED ARMORは段差が目立つ。

またカメラの保護に関してはレンズ外周スレスレまで保護しているZEROSHOCKの方が優位だ。恐らくレンズの穴ピンポイントにアスファルトの突起が刺さらない限り、舗装路に落としてもレンズが守られるだろう。

一方でRUGGED ARMORは外周に出っ張りがあるため、ZEROSHOCKと比較した場合にやや脆弱に見える。しかし出っ張りが高めなので意外と平気かもしれない。またSONYのロゴが見えるため、美観的が良いのがいいところだ。

電源ボタンに関してみてみるとZEROSHOCKは裏側に梁がなく、このケースは裏側から電源ボタンにアクセスさせる設計なのが伺える。RUGGED ARMORは表裏どっちからでも電源ボタンにアクセスできる。

表面加工についてはZEROSHOCKはゴムっぽくて滑りづらい、RUGGED ARMORはザラザラしていて滑りづらい感じだ。手で持った時の感触はZEROSHOCKも悪くないのだが、RUGGED ARMORの触り心地はXperia 1 VIII本来の表面に近く、ケースを付けているのに、まるで付けていないような感覚があり、これは非常に良いと感じた。

またRUGGED ARMORのストラップホールは千切れやすいという評判があるため、ストラップホールを使う場合は、明らかに分厚くて頑丈そうなZEROSHOCKの方が耐久性がある可能性がある。

下側

下側から見たところ。

ZEROSHOCKは厚みがあり、コネクタが挿しづらい。またコネクタの穴がRUGGED ARMORに比べて小さかった。

RUGGED ARMORはUSB Type-Cとその横のスピーカー分の切り欠きがあるが、ZEROSHOCKはUSB Type-Cとスピーカーで穴が分かれている関係でこうなっている。

スピーカーから音を出す場合、余計なものが少ないRUGGED ARMORの方が音はクリアだろう。

上側

上側から見たところ。この写真だけ左側がZEROSHOCK、右側がRUGGED ARMORになっている。

ZEROSHOCKはイヤホンジャックの開口部を大きく取りすぎて、余りにも縁を捕捉しすぎて手前側の縁が容易く千切れやすそうになっている。

RUGGED ARMORの方は特にそんなことがない。

またカメラ部分の段差はZEROSHOCKにはほとんどなく気にならないが、RUGGED ARMORはやや気になる。なれれば気にならないとは思うが、音ゲーを机の上でやる場合は向かないだろう。

操作感

ZEROSHOCKはその分厚さゆえに、シャッターボタンを押すのに力が必要で、すぐにカメラを起動したいときに空振りすることがしばしばあった。逆に言えばボタンの保護は堅牢といえるだろう。とはいえ、スマホは表裏面か角から落ちるものなのでボタンを強打するシーンは余り思いつかないが…。

RUGGED ARMORはボタンが非常に押しやすく、シャッターボタンはもちろん、ボリュームボタンを押すのも快適だ。電源ボタンへのアクセスもいい。

着脱のしやすさではZEROSHOCKの方が遥かに良く、RUGGED ARMORは装着や脱着がし辛かったが、逆に言えばRUGGED ARMORはミチミチなので隙間にゴミとかが入りづらく、ケースが何かの弾みで脱落する可能性も低いと感じた。今回のは過去に使ったRUGGED ARMORの中でも最強クラスにミチミチだと思う。

あとがき

RUGGED ARMORはMagSafeがないのでマイナカードを押し付けても磁気ストライプが壊れないのが最大の利点である。

最近では少なくなったとはいえ磁気ストライプや磁器硬券と一緒に入れる場合、MagSafeがあると支障になるので、そういった心配をしなくていいのは非常にいいところだ。

ZEROSHOCKはサイズ的に胸ポケットに入り、実用面では問題なかったが、過度に大きすぎた部分もある。とはいえ、個人的に最大の欠点はMagSafeである。

ただ磁力が弱いのか、家電店でMagSafe対応充電器に貼り付けてもずり落ちたので、内蔵の磁石がどれだけ役に立つのかは謎だった。

結果として私はZEROSHOCKには戻らず、これまで通りRUGGED ARMORを使うことにした。

しかしなぜ今回RUGGED ARMORは出るのが遅かったのだろうか…。少なくともAmazonに出てきたときは発売日以降だったように思うし、商品が出ても配送日もかなり先だった。今でこそ即日配送になっているが私が買ったときは6/20が最短だった。この時は配送時期に一ヶ月近いブレがあったと思う。

ZEROSHOCKを買うことにして一旦キャンセルしたものの、やはり買い直したときは最短が後ろに倒れ、やはり一ヶ月近いブレがあった。注文後は結果として6/23が配送日になった。まぁ二度目の注文のときはXperia 1 VIII発売キャンペーンとか言うので値引きが入ってタイプ安くなっていたので結果としては良かった気もするが…。

こういうのがあるとXperiaへの対応がおざなりになりそうで今後が心配だ…。ただ表面加工は素晴らしいの一言だし、ひょっとしたら製品のクオリティを高めていたとかなのかも知れない。或いは日本市場が見捨てられているのか…。

まぁもし、RUGGED ARMORが対応しない時になったら、きっとその時はZEROSHOCKが生きるのかもしれない。いやまぁ、その時にZEROSHOCKがXperiaへの対応を続けていてくれたらの話ではあるが…。

PowerShellはWSL2の中から叩けるため、WSL2の中から通知を出したいときに使える。

PowerShellなのでホスト側のWindowsからも使える。

• 確認環境
• やり方
• このスクリプトのオプション
• Windows側から叩く方法
• 参考情報
• あとがき

確認環境

PowerShell 7では動かないので注意。

やり方

1. この内容をtoast.ps1など適当な名前で保存する。文字コードはUTF-8 BOM, 改行コードはLFにしておく

   param (
       [String]$subject = "WSL Notice",
       [String]$title   = "たいとるですー",
       [String]$message = "お知らせでーす",
       [String]$icon    = "C:/env/1e1b9fdf82a6a544.png",
       [switch]$keep
   )
   
   [Windows.UI.Notifications.ToastNotificationManager, Windows.UI.Notifications, ContentType = WindowsRuntime] > $null
   $template = [Windows.UI.Notifications.ToastNotificationManager]::GetTemplateContent([Windows.UI.Notifications.ToastTemplateType]::ToastImageAndText04)
   $xml = New-Object Windows.Data.Xml.Dom.XmlDocument
   
   $xml.LoadXml($template.GetXml())
   $toastTextElements = $xml.GetElementsByTagName("text")
   $toastTextElements.Item(0).AppendChild($xml.CreateTextNode($title)) > $null
   $toastTextElements.Item(1).AppendChild($xml.CreateTextNode($message)) > $null
   $toastImageElements = $xml.GetElementsByTagName("image")
   $toastImageElements.Item(0).SetAttribute("src", $icon) > $null
   
   if ($keep) {
       $xml.DocumentElement.SetAttribute("scenario", "reminder") > $null
       $actions = $xml.CreateElement("actions")
       $action = $xml.CreateElement("action")
       $action.SetAttribute("content", "閉じる") > $null
       $action.SetAttribute("arguments", "dismiss") > $null
       $action.SetAttribute("activationType", "background") > $null
       $actions.AppendChild($action) > $null
       $xml.DocumentElement.AppendChild($actions) > $null
   }
   
   $toast = [Windows.UI.Notifications.ToastNotification]::new($xml)
   $appId = $subject
   $notifier = [Windows.UI.Notifications.ToastNotificationManager]::CreateToastNotifier($appId)
   
   $notifier.Show($toast)
   

2. 次の書式で叩くと通知トーストが出る

   powershell.exe -File 'C:/path/to/toast.ps1' -subject hoge -title fuga -message piyo -icon C:/path/to/icon.png -keep
   

このスクリプトのオプション

-subjectを変えると別の通知扱いになるため、通知を別々に貯めることができるようになる。

Windows側から叩く方法

powershell 'C:/path/to/toast.ps1' -subject hoge -title fuga -message piyo -icon C:/path/to/icon.png -keep

Windows側から叩く場合、-Fileは省略できる。

参考情報

• ToastTemplateType 列挙型 (Windows.UI.Notifications) - Windows apps | Microsoft Learn
  • ここの内容とググった情報からXMLの構造をエスパーして実装している

あとがき

Claude Codeの確認と終了のイベントで通知が出ると便利かなと思って作ってみたが、まだ試せていない。

取りあえずWSL2の中と、Windowsホスト側から叩いたときに通知が出ることは確認している。

PowerShell 7で動かそうと思ったらエラーまみれで動かず、PowerShell 7の場合、NuGetパッケージを取得するか、DLLのパスを直に指定するか、サードパーティの通知ライブラリを使うかということで、諦めた。

前回の対処ではMicrosoft Edge rounded cornersを設定して回避していたが、これが潰されたので回避方法を残す。

確認環境

• Microsoft Edge バージョン 149.0.4022.69, 149.0.4022.98
• Windows 11 Pro

やり方

1. スタートにピン止めしているEdgeを右クリックして「ファイルの場所を開く」
   

   

2. 開いた場所にあるEdgeを右クリックして「プロパティ (R)」
   

   

3. Microsoft Edgeのプロパティが出るので、「リンク先(T)」の入力欄の末尾に --enable-features=msForceNoRoundedCornerAndMarginを付け足す
   

   

4. 「OK」を押して保存する
5. Edgeを終了し、スタートのピン止めから起動すれば角丸が消える

端的に言うとこのコマンドで起動すれば消える。

"C:\Program Files (x86)\Microsoft\Edge\Application\msedge.exe" --enable-features=msForceNoRoundedCornerAndMargin

あとがき

レスポンシブシミュレーションの画面でも角丸が出るためWeb開発にも支障が出ると思うが、マイクロソフトはなぜこんな変更をしたのだろうか…。

余談だが、Bring back the "Microsoft Edge rounded corners" optionにフィードバックを送ると改善する可能性があるので直してほしい人は送るといいかも？私は送った。

現時点で625の投票と205個のフィードバックがついている。6月8日に見たときは391票と130コメントだったので、だいぶ増えている。

最近自鯖を別環境に移行するかどうかについて少し考えている。

現在はUbuntuで運用しており、記憶が確かならUbuntu 16.04 LTSから24.04 LTSまで使ってきているが、幾つかの問題を感じている。別にクリティカルでも何でもないので、やる必要性も薄い。

移行方法についてもやや難しく、UbuntuはNVMe SSD上で動いているため、本来なら別にNVMe SSDを買ってきてそこに試験的に移行先を作り、移行が環境した時点でUbuntuのNVMe SSDと物理的にすり替えたいところだが、SSDが高騰している関係でこの手が使えず、やるとしたら空いているSATA SSDに環境を入れて、運用が軌道に乗りそうならUbuntuを消し飛ばすしかなくなる。つまり戻せないか、戻す場合はUbuntuの入っているNVMe SSDをddでどっかにバックアップしてやる必要がある。凄いめんどい。

ひとまず、以下に移行したくなった好ましくない理由と、移行先について書いていく。

• Ubuntuの好ましくないところ
  • Ubuntuの商業主義が気に食わない
  • Snapが気に食わない
  • 動作が不安定
  • 26でのinit.d切り捨て発表
• Ubuntuの好ましいところ
  • 広く普及しておりノウハウが豊富
  • メジャーアップデートが容易
  • 特に何もしなくても大抵のハードウェアが動く
• 現在検討している移行先
  • Debian
    • 得られそうな利点
    • 懸念点
      • 通信速度が異常に遅かった
      • 移行しても旨味があまりなさそう
  • Proxmox
    • 懸念点
      • スペック的に運用できるか怪しい
      • 運用がだるそう
      • 監視がだるそう
• 通信速度の比較
  • Ubuntu 24.04.4 LTS
  • Debian 13.5.0のLive installer上での計測
  • Proxmox VE 9.2-1
• あとがき

Ubuntuの好ましくないところ

ここに書いていることはほとんど運用面では関係ない吝嗇である。端的に言えばCanonicalの姿勢が嫌いなのである。

Ubuntuの商業主義が気に食わない

自鯖はLinuxのDesktop環境の検証も兼ねているのでUbuntu Desktopを導入しているが、何かあるとCanoninalの製品に誘導されたり、過去にはMSアカウントとの連携をお勧めしてくる画面とも出会った記憶がある。こういうところがどうも好きになれない。

私はCanonicalに金を払う気がないし、LinuxをMSアカウントや、その他何かしらのアカウントと連携させたいとも思っていない。スタンドアロンこそが正義だ。

いやまぁ、Edgeのアカウントは連携するけどさ。

Snapが気に食わない

Snapに対する私の理解としてはSnapdというデーモンの上で動くアプリケーションという感じだ。

コンテナ化されたアプリケーションがDocker見たいなやつの上で動いている。なんかリソース食いそうだしキモイ。ネイティブアプリケーションはバイナリでそのまま動いてほしい。

噂ではFirefoxはaptでインストールしてもSnapdの上で動くらしい。これはWikipediaにも載ってるほど有名な話だ。何故snapdを使ってないのにそうなるのか？キモすぎる。

私は仮想化に対しては余り良いイメージがない。何故なら仮想環境分のオーバーヘッドを含み、無駄にストレージやメモリを食うこと、ホスト環境とゲスト環境の差異により問題が発生した時の特定が困難なことがある。

明示的に触れるDockerやVMならまだしもSnapdは一般向けで普通カスタマイズしない気もするし、そもそもカスタマイズが必要になるとしたらバカバカしい。なんでFirefox動かすのにそんな設定しないといけないのか？

動作が不安定

インストール直後にapt upgradeを叩くとリポジトリが死んでることがある。これは非常に嫌だ。

なんで公式でキッティングされてるリポジトリが死んでるのか？本当に営利企業がやってるのか？と思う。

他にもノートPCに入れてると蓋を閉じて開きなおしたときにキーボード入力が効かなくなり、一切何も操作できなくなることもあった。これは大分困る。

基本的にUbuntuのDesktop環境は不安定で、よくフリーズやクラッシュすると思う。それでもUbuntu 8.04 LTS辺りのころよりは安定したとは思うが…。

26でのinit.d切り捨て発表

init.dを捨てろという話なのだが、移行がだるい。

Ubuntuの好ましいところ

一方で、Ubuntuにもいいところはある。

広く普及しておりノウハウが豊富

人気のディストリのため、情報が多いのは強みかもしれない。

パッケージリポジトリも多く、基本的にUbuntu対応は多いと思う。

メジャーアップデートが容易

コマンド一個叩けばアップデートできるのは便利だ。設定の移行も手伝ってくれる。

特に何もしなくても大抵のハードウェアが動く

5種類くらいのデバイスに突っ込んだり、NICを増設したり、色々してきたが、今のところドライバを入れるとか何か対応したことはない。楽である。

現在検討している移行先

取り敢えずそんなこんなで移行先を探すことにした。

Debian

人生で最も最初に触ったディストリ。保守的で質実剛健という話を聞くやつ。

得られそうな利点

• Canonicalの商業主義から解放される
• Ubuntuより安定している可能性がある
  • Debianは徹底的なテストを経てリリースされているそうなので

懸念点

通信速度が異常に遅かった

懸念点としては何故か通信速度が異常に遅かった点だ。Live installerでiperf3で計測したところ、なんか異常に遅かった。これでは使い物にならない。原因は調べていないがNICは10000Mbpsでリンクアップしていたので、NICより手前で何かが起きていた可能性がある。

以下はDebian 13.5.0のLive installer上で計測した値だ。

Windows -> Debian

Debian -> Windows

移行しても旨味があまりなさそう

手間がかかるだけでCanonicalの開放以外のメリットがなさそう。

移行の手間としても全ての手順をマニュアルに書き出すかAnsibleのような構成管理ツールでやる必要があり、非常に面倒そうである。

Proxmox

仮想環境をたくさん作ってその中でアプリケーションを運用するやつ。コンテナ単位でのバックアップも取れるなど便利そうだ。

この環境に移行する場合、移行が楽というのが最大のメリットだ。一度適当な環境に仮構築しモジュールごとに移行し、移行完了したらLXCのバックアップを取り、Ubuntu環境を潰し、Proxmoxに入れ替え、バックアップを復旧して移行すればリスクも手間も最低限で済む。

またDebianで発生したNICの極端な通信速度劣化についてもProxmoxでは確認できなかった。但しUbuntuよりは遅く見えた。

懸念点

スペック的に運用できるか怪しい

例えばコンテナ単位でのリソース管理はその一つだ。例えばコンテナごとにCPUやメモリ、ストレージを割り当てるとすると、特定のコンテナが跳ねたときにリミットにかかって動作が劣化するが、ネイティブで動かしていればCPUやメモリ、ストレージは共有なので、なんかいい感じにしてくれる。限界突破しない限りOOMは起きないし、私のサーバースペックであれば普通起きない。

しかしコンテナ化して1コンテナCPU2コア、メモリ2GBとかしていればしょぼいVPSみたいになって動作が劣化しそうだし、そんな立派なスペックでもなく、現状CPU6コアのメモリ32GBなので、この割り当てだとすぐに枯渇するのは自明である。ブレードサーバーを持ったホームラボ、k8sを使った運用のようにクラスタ化された環境なら、これはうまくいきそうだが、しょっぱいスペックのマシン一台で成り立つかどうかは怪しい。

Opus 4.8は成り立つというが、この分野ではLLMの言うことを真に受けたくはない。そもそもLLMの出力なんか何言ってるかわからないけど動くからいいか！で採用するものでしかないと思っている。

運用がだるそう

例えば10個くらいLXCを上げているとして、コンテナのイメージをアップデートしますとかなると全部上げていかないといけないだろうから、これは面倒そうだ。

他にもLXC1とLXC2, LXC4に対して作業する場合、それぞれのLXCにSSHDと鍵を入れる必要があり、無駄なオーバーヘッドが出る。つまりLXCを増やし、そこの中に入る場合は台数分のSSHDが多重起動し、その数分の鍵が必要だ。まぁこれについては最悪一個にしてもいいが…。切り替えについてもnginxでリバプロしてハブを作れば上手くいくかもしれないが、そもそもそれが出来るかよくわかっていない。軽くググった感じはできるらしいが、そもそもスイッチする時どうなるのか見当もつかない。/lxc1/path/toみたいな形式になるのだろうか？

そう考えるだけで運用がだるそうである。

pct setを使えばうまくいく可能性が示唆されているが、どうやらこの方法は前述のように根本にパスを追加して、そこから分けていく考えのようだ。ユーザーやグループとかどうなるんだこれ…？Proxmox側でID揃えてくれるのかな？

あとホストのアップデートもだるそうな気がしている。

監視がだるそう

動作パフォーマンスを取ろうにもホストとゲストのどっちのCPUやメモリの使用率を取るかは悩みである。ホストには空きがあるが、ゲストには空きがなければ広げた方がいいかもしれないし、この辺りについては考えがまとまっていない。

通信速度の比較

Ubuntu 24.04.4 LTS

Windows -> Ubuntu

Ubuntu -> Windows

Debian 13.5.0のLive installer上での計測

以下の計測値は全てクライアント側で取得したもの。Windows側にCwndが出ているので表が逆かもしれない（Proxmoxではクライアント側にCwndが出ていたため）

Windows -> Debian

Debian -> Windows

Proxmox VE 9.2-1

以下の計測値は全てWindows上で取得したもので、Proxmox->Windows側はProxmox側のログの値ではない（転記が面倒だったためWindows側の値を取っている）

Windows -> Proxmox

Proxmox -> Windows

Proxmox側（クライアント）にはCwndが出ていたが、Windows側（サーバー）の値を取っているため、その情報が欠落している。

あとがき

Proxmoxで運用の支障がなければ環境分離の観点から移行できるとよさそうだが、メンテナンスのだるさを考えた時にどうかというのでぐるぐるしている。

かといって今のUbuntuを拡張すればするほど移行が手間になってくるので、悩ましい。しかし単一ホストで全部運用するのは間違いなく楽だしなぁ…。

取り敢えずDebianに移行する旨味は余りなさそうだし、これはしなくていいかと思った。

Proxmoxはやってみないとわからない部分もあるのでUbuntu環境のバックアップを入念に取ったうえでやるかもしれないが、問題はUbuntuをバックアップするストレージをどうするか…。

そもそも現時点でやる意義も怪しいので、今はやらない方に倒し、必要が出たときにやるのも一つではある。やりたくなった時にはそれはもう地獄が待っているかもしれないが、それ以前に私はやりたいことが無数にあるのだ。

今回は検証ができたという意味では一つ成果だと思うし、一旦ここで留めておこう。