自分に通知を送る

人生には、自分に通知を送りたくなることがよくある。例えば、

$ tar xf 開くのにめっちゃ時間がかかるクソでかファイル.tar.gz 

ってしたときとか、あー終わったら呼び出してくれないかなぁって思うことがあると思う。
他にも、これは時間がかかりそうだなーという、なんかしらのコンパイルをするときとか、終わるまで待つのはだるいけど、でも終わったらすぐに結果が確認したい。そういうことがあるとおもう。
この手のまとまった時間が必要になるコマンドの実行が終わるまでは、液晶ディスプレイの前から離れて、まぁお茶でも飲んでおこうかな、って思うのが人情である。

これは、よくある問題である。
みんな、こういうとき、どうしているのだろうか。
自分は、url を叩いたら自分にメールを送るような仕組みを作って、コマンドが終わったら、その url を叩くようにしている。

やっていること

で、自分はこういうときのために、適当に url を叩くと、自分のスマホにメール(MMS)を送れるような簡単な web サービスを、6年くらい前にふと思い立って作った。
つまり、下のようなコマンドを打つと、結果的に自分のスマホに SAMPLEMESSAGE って本文に含まれたメールが届くようになっている。

$ curl "https://exampleserver.jp/yobidashi?msg=SAMPLEMESSAGE"

といっても、exampleserver.jp/yobidashi でやってることはアクセスが来たら、smtp サーバにアクセスし msg の内容を含むメールを送るだけである。

で、実際には、zshrc の中に更にこんな感じに書いている。

function sntfy() {
  curl --silent "https://https://exampleserver.jp/yobidashi?msg=$1" > /dev/null
}

なので実際には、こんな感じで使う

% tar xf 開くのにめっちゃ時間がかかるクソでかファイル.tar.gz ; sntfy tar_open_finished

これで、開くのにめっちゃ時間がかかるクソでかファイル.tar.gzを開いている間に優雅にお茶を飲みつつ、終わったら自分のスマホにメールが届き、tar.gz 内の内容を確認することができる。

懸念点

url を叩くと、今のところ、手元のスマホに push 配信され、届くのがはやいスマホのキャリアメールを使うようにしている。

でも、いつまでもキャリアメールがついているような高い携帯電話のプランを使わずに、格安スマホに変えたいなと思っている。
そうすると同様の仕組みは使えなくなる。

で、どうやら、最近は iPhone をはじめとするスマホでも web notify というブラウザ経由で web サーバーから手元のスマホに通知を送る仕組みがあるらしい。
色々調べてこっちを使う仕組みに切り替えたいなぁと思っている。

おわり

時間がかかる処理が終わったら自分に通知を送るために自分がやっていることについてざっと書いた。
よくある問題だと思うので、他の人がどうしているのか気になる。
みんなどうしてるのか教えてほしい。

自宅のTV録画サーバ兼NASを新調した

自宅のTV録画サーバ兼NASを新調した。
録画サーバとNASを前に作ったのは 8 年前で、ほぼ8年間稼働しっぱなしだったので、さすがに古くなってきたと思って新調した。
今年始めにメインのデスクトップPCを組んだので、今年に入ってから2台目の自作PCとなった。まぁ、そういうこともある。

ハードウェア構成

ハードウェア構成はこんな感じ。ケースとケースファンは流用。

項目型番とか大体の値段
マザーボードASRock H610M-HDV/M.2\11000 くらい
CPUintel Celeron G6900(Alder Lake)\7000 くらい
メモリADATA AX4U320088G16A-DCBK20 8GBの2枚セット\7300 くらい
システム用 m.2 SSDWestern Digital WDS480G2G0C 480GB\6300 くらい
電源Scythe CORE-TFX275\3300 くらい
データ保存用 HDDSeagate ST8000DM004 8TB\15000 くらいを2台
合計\65000 くらい

データ保存用のHDD を除くと \35000 くらいで、既製品の NAS の箱と同じくらいの値段になったりするのだけど、メモリを16GB積めていてこれがキャッシュとしてきいてくれていい感じであってくれ、という気持ち。
でも家のネットワークが未だに 1GBit Ethernet なので結局こっちがネックになる感じはある。

CPU はAlder Lake世代で一番性能が低いものだけど、用途を考えれば十分だと思う。というか、シングル性能は i9-10900 と変わらないということらしくなんか未だに CPU は進化を続けているのだなぁと思う。
いろいろなことをしたくなって性能に不足を感じるようになってきても、多分 i3 くらいまでは載せ替えても電源の面でも熱の面でも問題は起きないと思う。

録画機能の選定

8年前は、chinachu というTV録画用のwebサービスを使って、環境を構築した。
今回も chinachu を使おうと考えていたのだけど、この8年の間に chinachu のテレビ録画ボードを操作するAPIを提供することを目的とした部分が Mirakurun として切り出され、 chinachu 自体にはこの API を操作するための Web UI が残されるという機能分割が行われたようだった。
で、その Web UI の方についても obsolete になるらしく、じゃあどうやって使えばいいのかと思ったんだけど、 Web UI の部分を置き換えるいくつかの代替品があるらしく、それと組み合わせて使うといった形になったらしい。

今回は、Web UI としては EPGStation というものを使うことにした。
EPGStation と chinachu はともに Docker 内で動くようになっており、両方をまとめて起動できる docker-compose 用のファイルも配布されていたので、これを使うことにした。

心残り

標準の状態では Quick Sync Video を使わずに、完全にソフトウェアでトランスコードするので、トランスコード時の CPU の負荷が高い。
Dockerfile 内で FFMpeg をコンパイルしているので、ここで必要なライブラリやコンパイルオプションの追加をすれば、 QSV を利用可能になる。でも、とりあえずソフトウェアエンコーディングでも性能が足りているようなので、後回しにすると決めた。

OS の選定

録画機能がDocker コンテナの中で動くということで、物理マシンに直接インストールする OS についての制限はなさそうだったので、長期的にちゃんとアップデートを行っていくことを念頭に置き、 arch linux をホストの OS として用いることにした。

NAS 機能

録画機能が docker-compose で管理されているので、NAS機能の方も docker-compose で管理することにした。
debian のベースに samba をインストールした Dockerfile を書いて、それを使った。
NAS 用のディスクは btrfs の RAID 1 でフォーマットした。1台壊れても大丈夫だし、容量足りなくなったら大きめのディスクを足せば良いだけのはず。

心残り

samba に対する書き込みを行っている際に、 docker-proxy というプロセスがそこそこ CPU を使っていることに気づいた。
このプロセスはコンテナの中と外の通信を仲介する役割であり、–userland-proxy=false オプションを docker daemon に与えるとこれを使わずに、iptables で代替の処理を処理を行うようになるようだ。多分、iptables でやったほうが軽くなるだろうとは思うのだけど、とりあえず性能面で今すぐ困る感じにはならなかったので、標準の状態でいいやと言うことにした。
今後、コンテナで大量の通信を行うような利用法を考えるときにはこのオプションについて真面目に検討しようと思う。

ARM64 な VM に サーバーの引っ越しをした

今あなたが見ているこの blog の html は ARM プロセッサ上の VM から送られてきているんだ。(唐突)

Oracle Cloud の ARM インスタンスの無料枠に引っ越した

というわけで、海外の VPS (vultr) に乗り換えてから2年くらい経って、なんだか大したことしてないのに結構高くついちゃってるのが気にかかっている状況が割と長く続いていたので、この blog を含む各種サービスを Oracle Cloud の ARM インスタンスの上に引っ越しました。

VM の上では、この blog であったり、ちょっとしたツールを雑に作るための nodered であったり、grafana や chronograf といった可視化ツールを docker-compose で管理して動かしています。この blog には大したアクセスはないし他のサービスは自分しか使っていなくて CPU の負荷は小さい一方、いろんなサービスを動かし続けて置く必要はあってメモリは割りと多く使う状況で、CPU弱くてもメモリがたくさんある、安く使える環境があったらいいなぁと思っていました。

そんな中、 Oracle Cloud では ARM の CPU を 4コア分、メモリは24GB 分無料で使えるぞということを聞きつけ、こりゃあいいと思って、思い切って移行しました。

もともと各種サービスはすべて docker-compose による管理を行っていたものの、 x86_64 で動かすことしか考えておらず、ちゃんと移行できるんだろうかというのがネックでしたが、サーバサイドの ARM64 も出てきてずいぶん時間が経ったせいか、使っていた docker のイメージについては cAdvisor 以外は ARM64 のイメージがあり、MySQL については新しいメジャーバージョンにしか ARM64 用のイメージがなくバージョンを移行する必要があったりもしましたが、おおよそつつがなく移行できました。

昔、docker とサーバーサイドの ARM64 が出て来つつあるのを、自分はほぼほぼ同じタイミングで認識しました。で、イメージが cpu のアーキテクチャにがっつりと依存する docker が流行ったので、docker のせいで ARM64 がサーバサイドで広く使われるようになるのは少し遠のいたようなきがするなぁと思ったりもしたのですが、それから結構経って、ARM64 でも docker がずいぶん普通に使えるようになったことが確認できました。
今や macbook さえ ARM64 な時代ですしね。そんなもんなのかもしれません。

そんなわけで、 ARM1コア 6GBメモリで機嫌よく動いています。
無料の範囲だ。本当にええんか。

今後の予定

引越し後も相変わらず docker-compose でサービスを管理しているのですが、まだARMが 3コア、メモリは18GB 残っていて、かつ k8s のマネージドサービス自体はこっちも無料で使える ので、残ったコアとメモリで k8s の素振りでもして慣れてきたあたりでまたそちらへ引っ越そうかなぁと思っています。
最近、仕事で k8s に触れる機会が増えてきたので、趣味と実益を兼ねてぼちぼちやっていきたいですねぇ。

core i7-12700 を CPU に使ったPCを組んだ

あけましておめでとうございます。
最近、メインで使っている Windows のデスクトップ PC で曲を書いているときに CPU の不足を如実に感じるようになってきたので、PC を新調しました。
前回、前々回購入したデスクトップ PC は、 mouse computer で買って、出来合いのデスクトップ PC に SSD やら GPU やらのパーツを足して使っていました。
今回は、core i7-12700 という CPU がどんなもんなのか気になって仕方なかったので、パーツごとに自分で買って、いわゆる自作 PC を作りました。

今回使ったパーツ類

最後に PC を自作したのは、およそ 8 年前で、そのときには celeron j1900 ベースの録画マシンを作りました。
その頃と比べると、最近は CD-ROM/DVD-ROM ドライブはそもそもつけなかったり、HDD/SSDも m.2 でマザーボードに直接つけるようになっていたりと、配線が随分少なくなり最近は随分手軽になったんだな、という印象を持ちました。

主目的は先に書いたように CPU の性能不足の解消なのですが、CPU の新しい機能に興味があってそれがどのように動くかを見るというのもサブの目的としてある。というのも今回選んだ core i7 12700 には高性能な Performance-cores と高電力効率の Efficient-cores が乗っており、Windows 11 ではこれらをうまいこと使い分けることで高性能を実現しているらしい。
当然 Linux にも今後類似の機能が実装されていくことになるわけなので、その進化をソースコードレベルで負いつつ実感してみたいなと思っている。

というわけで、CPU の機能を直接叩くために、久々に VM 上ではなくベアメタルで Linux を動かす必要があるので、すごく久しぶりに、 Windows と Linux の dual boot 環境も作ってみるつもり。
楽しみだなぁ。

4K モニタを 2 枚買った

27 インチの 4K モニタを買いました。
LG の 27UL650-W というモデルで、1枚あたり4万3千円くらいでした。
電車が人身事故で止まってしまい、仕方ないなといって降りた駅近くにあった電器屋さんで見かけて、ベゼルも狭くてシンプルな出で立ちだし、これいいんじゃないか?って思ってこれに決めました。

https://www.lg.com/jp/monitor/lg-27UL650-W

これまでは、12年ものの 24 インチの WUXGA のモニタを 2 枚、縦にモニターアームを使って積んでいましたが、今回同じように縦に積みました。
12年も使ったんだから、もう流石に新調していいだろうって。

モニターアームは、24 インチから 27 インチに大きくなったんだから、モニターアームも長いものにしなきゃと思ったんですが、実際には長くする必要がなくて、上の方にはみ出してしまってなんか不格好になりました。
これは高さが 70cm あるんですが、60cm くらいで充分足りました。これはちゃんと計算すれば事前にわかったことなので、反省。

高解像度のディスプレイを使ってみて思ったのだけど、パソコンの文字が読みづらいと感じる一端は、解像度の不足だったかもしれないなーって思った。解像度が高いと単純に文字が読みやすくなる。

MacOS で使ってみた

最近 Macbook Pro 13 を買ったので、thunderbolt から hdmi への変換を 2 つ買って、2 枚のモニタに表示してみました。
仮想解像度は、2560 x 1440 くらいが、自分にはちょうどよかったです。
確か、27インチの5KディスプレイのiMacも仮想解像度の横幅が2560だったはずだなので、作ってる側も想定しているくらいの密度なんだろうなーと勝手に思いながら使っている。
画面に出せる情報量が増えて、文字もきれいで読みやすくなったので大満足。

主にブラウザ、vscode、IntelliJ、terminal くらいしか使っていないので、特段困ったことはありませんでした。
昔から高解像度モニタに対応しているからストレスなく使えるなーって感じ。

Windows 10 で使ってみた

Scaling は 175% にして使ってみた。
ブラウザ、vscode、IntelliJ あたりはまともに動く。

Studio Oneもまともにうごく。一部のvstプラグインについては、Studio One 側の機能であるスケーリングがまともに効かない。
普段から使用頻度が高いVSTがうまく動かなかったりするのでそこそこストレスフルだけど、まぁ許せる範囲。

Arch Linux(xfce4) で使ってみた

上記 Windows 10 にインストールされた VirtualBox 上に作った Arch Linux の VM に、以前から xfce4 環境を構築していたものの設定を変更。
設定を変更したのは下記URLに記載のある1箇所だけ。何の問題も生じていなくていい感じ。

https://wiki.archlinux.jp/index.php/HiDPI#Xfce