Linux on 或る阿呆の記

AIプログラミングはマシンやOSを跨ぐと苦労する

Mon, 07 Sep 2026 00:00:00 +0900

最近、いくつかの自前のアプリケーションについて、Mac上で動かしていたのを、Linuxに移しました。この作業自体は既に何度もやっているので、AIにもそれらを参考にさせることですんなりいくかと思いましたが、だめでした。苦労しました。

Mac→Linuxへ

長らくメインのMac miniに自作のアプリケーションを常駐させてきました。その中には24時間稼働のアプリケーションもあります。一番重たいものでは仮想通貨トレードアプリなどそうでした。

これは元々、改修を即座に反映してログなど確認するには、開発マシンでそのままやるのが一番効率的だったからです。自作のアプリケーションではそんな運用でも特に問題はありませんでした。

とはいえ、よほど重い処理をさせるのではない限り、サーバーマシンは一定のスペックがあれば性能的には飽和するものです。もちろんCPUがよければそれだけキビキビ動くのも確かなのですけれど、多くのサーバアプリケーションのユーザは人間はではないことも多く、24時間安定して稼働できることのほうが重要です。

そういう次第なので、今はAIがあるしなぁと、重い腰を上げて、いまだMac miniにあったサーバアプリケーション、特に24時間稼働のものについて、Linuxサーバに移行することにしました。

問題はインストールと更新

今はAIがあるので、まぁすんなりできるだろう……と、できたかどうかは、微妙なところです。

まず表面化したのは、MacとLinuxではインストールで必要なプロセスがまったく異なるため、make installの内容が全然変わってしまう、ということです。まぁこれを嫌って小規模アプリケーションでもDockerなど扱う人も多いのですが、あれはあれで別の罠が色々とあるし、個人的にはなにかクリティカルな理由がなければネイティブにやります。これは低レベルの操作まで含めてAIに書かせることになるので、AIプログラミングの観点だとつらい面はあるのですが…

その結果がまったく異なるmake installではあるのですけれど、まぁmakeはまさにそのためのものではあるので、それは仕方ないのかなぁと思います。そしてその面倒くささをAIは吸収してくれるのだ……。

というのが期待されることではあるんですけれど、最近はLinuxのインストールにも色々とパターンがあるようで、それによって権限周りで色々と嫌なことが起きます。まずsystemdについて、権限をどうするかで割れます。AIにまかせっきりだと、システム権限でやろうとしたりユーザ権限でやろうとしたりしてブレます。

ここらへん多分今どきは、特別な理由がなければユーザ権限になるのかなぁと思うのですが、昔はシステム権限が普通だったはずなので、時間の切り刻まれたAIにおいては対応が確率で混ざってしまうのでしょうか。

しかもシステム権限にするとsudoの権限問題なども出てくるのですが、その対応について問うとsudo ALL=(ALL) NOPASSWD: ALLなどとんでもないことをしれっと提案してきて「この計画で進めてよろしいでしょうか」よろしくないぞ。スナック菓子感覚で大いなる力を使おうとするな。

全然違うものを参考にするというか模倣する

他にも「むむむ」と思ったのが、Mac→Linux移行はこれまでさんざっぱらやってきたので、他のプロジェクトを参考にするようにいったのですが、すると今度は技術選定が全然違うものを参考にしてカオス。

具体的には、Go言語による生成物がシングルバイナリなシンプルなアプリケーションがあり、それはインストールの過程でバイナリをmvするというもので、まぁシングルバイナリならそれはそれでいいわけです。

しかし今回のアプリケーションはNext.jsなど使っており生成物が色々あるわけなのですが、それをいろいろなexcludeを付与したrsyncコマンドを羅列して無理やり同期させようとしており、そんなことして良いはずがなく、「なんでそんなことするの」と聞いたところ、シンプルなシングルバイナリのやり方を何も考えずに真似してしまいました、とのことで。oh…

なんというか残念な新卒のような振る舞いです。まぁこちらの指示の仕方が甘いといえばそうなのでしょうし、実際こちらで参考にすべきプロジェクトを精査してどこをどう参考にすべきなのか指示すれば通った、と思います。でもそんな細かな指示を毎回するのしんどいなぁと思うし、そもそもAIはうまくいくときは任せとけとばかりにいい感じでやってくれることもまぁあるのです。

AIの暴走

たまに暴走するのは、確率の問題なのか、それともこちらの意図が変な普通に伝わって妙な制約を生んでしまうのか、多分両方あるのでしょうけれど、なんとなく肌感で「なんか迷走しそう」と思った時はだいたい迷走する感じです。人間のこの感覚はなんなのでしょうね。

まぁ私のつくる小規模アプリケーションならば、迷走暴走大爆走したところで大したことにはそうなりませんが、エラい人たちが金と時間をかけて作ったサンドボックス内での実験でも、AIが脱獄紛いのことをして現実のシステムを食い荒らす、というような事故（？）が起きているので、元より完全に制御するというのが無理なのでしょう。

Hugging Face侵害事件、OpenAIとMETRが最終報告書公開──約1200体のAIエージェントが“闇掲示板”で結託し700体が攻撃に参加 - ITmedia NEWS

それでもずっと使っているとなんだかコイツ（Model）のことわかってきたような気がする錯覚かもしれない感覚が生じるのですが、生じたあたりでどうせモデルチェンジなので、なんだかいつになっても悩みの質は変わらない感じですね。

あの日開いたソフトウェアが悪質かどうかAppleはまだ知らない

Sun, 30 Aug 2026 10:06:33 +0900

個人開発しているアプリケーションについて、永遠に公開を先延ばししてしまいそうだったので、えいやと公開しました。LoPiQというアプリケーションで、これはLinux版とMac版のバイナリをとりあえず配布したのですけれど、Mac版については例によってというのか、Appleからの嫌がらせで簡単に開かせてもらえない刑に処されています。

なにがOKなんだ😡

悪質なソフトウェアとは

自分のソフトウェアを自分のPCで動かそうとしたら「悪質なソフトウェア」疑惑をかけられるという屈辱。まぁこの嫌がらせについてはMacユーザならみんなもう慣れっこだと思うので、もういいんですけど。有名どころのアプリでも普通にありますし。AppleはiPhoneでストア税徴収の味をしめたのか、Macでもやりたかったんでしょうけれど、あまりうまくいっていないようです。

まー開発者からすればそりゃそうだという話で、Appleがタダで審査するならまだしも、なんで金払ってしかもAppleのよくわからない謎基準に合わせなければならないのか、完全に理由がありません。ユーザからの信用の問題というかもしれませんが、この開発元は信用できないがアプリストアにあるから大信用！とはならないでしょう。そもそも信用できないなら無理に使ってくれなくていいよという話です。ちなみにLoPiQはユーザ権限とはいえシェルスクリプトをそのまんま実行する暴れん坊なので普通に審査落ちるでしょう。

暴力はすべてを解決するの？

本来胴元に合わせる理由はないというのは、スマホも本当はそうなんですよね。iPhoneが出たときは、単一のストア、整備された決済システムというのも、これはまぁ確かに価値だったかもしれませんが、今となってはただのショバ代。それしかないことに合理的な理由はなく、単に力関係です。

なのでまぁ、最近はEUあたりがついに国家権力を使って介入し始めましたし、それに対抗するのはGoogleでもAppleでもなくトランプだったりするわけです。GAFAが何故GAFAになれたか、そこに米軍と米政府の存在が前提としてあったことを今更思います。全部力です力。いやだなー。

自由は何処

そうすると俺たちにはLinuxがあるじゃないかと思うわけですが、あっちはあっちで色々とあるようで…。実際Waylandなどはあまりいい話を聞きませんけれど、Windows/Mac以上にガチガチなところがあるようで、ここにRed Hatの思惑は当然あるでしょう。まぁそんなのもあって、僕はGUI環境として依然としてX11を使っており、xfceにしているのですが…。リーナス御大の引退も見えてくる中、Linuxも今後どうなることやら、といったところでしょうか。

まぁでも皆が皆統制的というわけでは当然なく、自由を追い求める実力者もいてくれていますので、自分としても、できる範囲で個人のための自由な計算機文化を伝えていきたいものです。

セルフホストしたWebアプリになぜかうまくアクセスできない時のチェック

Mon, 10 Aug 2026 00:00:59 +0900

私的メモ。そりゃそうだ集。症状は様々なので症状から逆引きというより流し読みして心当たりあるやつを思い出す集。構成が複雑になるほど、「端末Aでは症状A’になるが端末Bでは症状B’になる」など発生する。がんばれ。

環境

Linuxが基本。メインはLinux Mint Xfce。

一般

localhost以外からのアクセスを許可してない

症状: ローカル端末からはアクセスできるし正常に起動しているが、他端末からアクセスできない。

アプリ側でそういう設定になってるので、変更できるか否かという感じ。

ファイアウォールで許可していない

症状: ローカル端末からはアクセスできるし正常に起動しているが、他端末からアクセスできない。

間抜けなことにこれは本当によくある。

ファイアウォールの設定確認する。ufwの場合のコマンド。

sudo ufw status

空いてなかったら追加。

sudo ufw allow <ポート番号>

セキュリティグループ的なので許可していない

AWSをはじめとするクラウドとかVPSで、そもそもネットワークインタフェースに到達していないケース。許可しよう。

ポートの競合

症状: なんかうまくいったりいかなかったりする

複数のアプリケーション、なんなら同一のアプリケーションでポートが競合している。調べるときのコマンドはこれ。

sudo lsof -i :8080

AdGuardHome(AGH)とかLAN内DNSを使っている場合

LAN内DNSに向いてない

症状: LAN内ドメインだけ名前解決できない

そもそも論としてLAN内DNSに向いてない。ルータでDNSをLAN内のやつ指定するか、あるいは各クライアントでそれぞれ設定するか。

AGH側でDNS書き換え設定を忘れている

症状: LAN内ドメインだけ名前解決できない

稀によくある。設定しよう。

サブドメインの法則決めてワイルドカード使うのが楽ではある（ワイルドカードを使えばサブドメインの証明書発行を知られないというのもある。まぁサブドメイン知られたところで別にLAN内限定公開なら問題ないかもしれないが気持ち悪いので…）。

IPv6が優先されている

症状: 名前解決できない。端末によってはできることもある。

AdGuardHomeで頑張ってIPv6対応するか、ルータで切れるならIPv6切るか、あるいはクライアントでIPv6を切るか。クライアントで切る場合は対応はOSによって異なる。Macは基本的にDNSサーバをIPv4で設定すればいけると思うのだが、Windows/Linuxは明示的にやる必要あり。Androidはアプリ使う必要がある。自分はRethinkDNSを使っている。iOSは持ってないから知らない。

このとおり、OSによって状況が異なるため「端末AではいけるけどBではいけない」ということが起きうる。さらに同じOSでも設定してたりしてなかったりすると、それでも異なる症状になったりする。めんどくさい。

あわせて読みたい

LAN内DNSでIPv6は使わないのでWindowsでIPv6を無効化する

/landnsipv6windowsipv6/

/android-lan-agh-dns/

Caddyを使っている時

AGH + Caddyまで持っていくとだいぶ捗るけど構築は面倒くさい。DNS-01チャレンジを利用しているとエラーパターンが増える。

Caddyfileの設定を忘れている、間違えている

稀によくある。設定しよう。ドメインの前にスペース空いてないとかよくある examp.com{。caddy validateとcaddy fmt --overwriteしよう。Docker版ならサービス名caddyの時

docker compose exec caddy caddy validate --config /etc/caddy/Caddyfile

フォーマットは

docker compose exec caddy caddy fmt --overwrite /etc/caddy/Caddyfile

Caddyfileの設定を読み込むのを忘れている

ファイル書き換えただけで。リロードしよう。

caddy reload

Docker版

docker compose exec caddy caddy reload --config /etc/caddy/Caddyfile

証明書の発行に失敗している

症状: 証明書エラー

自己証明書以外のとき。ログを見て判断。利用しているレジストラに対応したCaddyを使っているか確認。あとAPIの権限を確認。

証明書を発行していない

症状: 証明書エラー

Docker版で docker compose up -dリロード代わりにした場合、証明書が発行されないまま。docker compose downしてから起動し直す。

(Docker利用時) バインドマウントを忘れている

症状: 404エラーがでる

Docker版Caddyを使っている時。ホストマシンのディレクトリをそのまんまfile_serverとか使ってホスティングする場合、バインドマウントしないと当然見えない。

Tailscaleを使っている場合

最近使ってないけど、使っていたときはややこしかった。特にAGH、Caddyと併用するとカオス。

MagicDNSがうまく機能しない

Tailscaleから付与されるIPアドレスを直打ちするほうが無難。

AGHと一緒に使う

TailscaleのDNSをAGHに向けること。

個人的にはこの構成はそもそも管理がとても複雑なのでやめたほうがいいように思う。

<参考>

/splitdns/

Cloudflare Tunnelとか使っている場合

トンネルが落ちている、接続されていない、間違えている

当たり前の見落としをよくする。

トンネルが競合している

症状: 繋がったり繋がらなかったりする

Docker版とネイティブ版両方動かしていたりとか、よくわからないことをすると起きる。

Linux Mint Xfce 22.3 でIPv6を切る

Sun, 09 Aug 2026 00:00:00 +0900

操作メモ。

環境

Linux Mint Xfce 22.3

やりたいこと

LAN内通信でIPv6を有効にしたくないのでクライアント端末で切りたい。

個別の理由としては、AdGuardHomeを使っていて、IPv6の設定するのがつらい。外との通信はルータ経由でIPv6を使うのでルータレベルで無効にしたくない。

操作

タスクバー右下のWi-fiアイコンを右クリックし「接続を編集する」
操作したいWi-fiのSSIDを選択し、設定アイコンをクリック
IPv6設定タブをクリック
メソッドを「無視する」に変更する
保存して再接続する

メソッドには「無効」もある。違いと使い分けはAI曰く以下。

項目	無視（ignore）	無効（disabled）
動作	IPv6アドレスの割り当て処理をスキップ	IPv6機能そのものを完全停止
ローカル通信	維持される（`fe80::`などが残る）	完全に遮断される
システム影響	互換性トラブルが起きにくい	一部アプリや機器接続に影響が出ることがある

無視で問題なければそのほうが多分安全。

2026-08-22: その後うまく接続できないことがあり、結局IPv6そのものを停止ました（無視しました）。。。

以上。

メインのノートPCをLinuxにしたいなぁと思いつつ

Wed, 10 Jun 2026 00:56:07 +0900

Windows 11のうんこっぷりにキレ散らかす日々、いい加減Linuxに切り替えたい。おらもう勝手に再起動されるの嫌だ。

今この記事を書いているWindows PCは、5年くらい前に買ったASUSのTUF GAMING F15だ。モバイル版のRTX3060(VRAM 6GB)がのっており、消費電力もかなり高いのだが、その高い消費電力でやっていることがブログ執筆ではしょうもない。

と言いつつゲームもちょくちょくしているので、一応ゲーミングPCの面目躍如はある模様。が、そのためにLinuxに移行する踏ん切りがつかなかったりもする。以前デュアルブートでPop!_OS 22.04を入れていたこともあるのだけれど、あの時は所詮デュアルブート、本意気ではなかった。本気でやるならやはりWindowsごと消さねばなるまい。

なのだけれど、Linuxだとゲームとかやっぱりつらくなるよなぁ、と思って躊躇している。最近はSteamをはじめたいていのゲームは動くという噂なのだが、俺たちのDMM Game Playerはそうもいかなさそうである。いやまぁ、DMM Game Playerにあるようなのはたいていスマホ版がある（というかそっちが本体に近い）ので、別に動かなきゃ動かないで別にいいんだが…。

しかしまぁ、SteamなんかにしたってWindowsネイティブのほうがたいてい良いのではないかなぁ。と思ってAIに聞いてみたら、「古いWindows向けのゲームなんかはむしろLinuxのほうが動くこともある」らしく、一長一短であるらしい。そうなのか。しかし今更古いWindowsゲームでやりたいのがあるのか、と考えてみると特にない。

特にないというか、冷静に考えるとゲーム自体大してやっていないのだけれど、子供時代ゲームが大好きであの頃の楽しさを忘れられないためか、常に「ゲームを楽しくやりたいなぁ」と欲求だけが亡霊のように残っており、やりもしないゲームが積まれ続けて10年以上経過したかと思う。いやでもきっといつかまたやるから…。

あとは地味にLinuxでEmacsキーバインドを実現する手段が確保できていない、というのがある。Windowsではkeyhac + Fakeymacsでほぼやりたいことができるのだが、これと同等のことをLinuxでやろうとすると、どうしたらいいのかちょっとわかっていない。しかも僕はJISキーボードをUSキーボードのように使うということもしていたりするので余計に厄介である。なんだかんだで今なおWindowsではこういうかゆいところに手が届くソフトウェアが有志により開発されているのは大きい。あとはMSが滅びてくれたら完璧なんだけど。

それとまぁ、e-taxのようなクソアプリを使わざるを得ない状況もあるので。まぁこれは何もゲーミングPCでやる必要はないため、本当に必要ならそれ用の事務用PCを中古で用意するほうがいいかもしれない。なにもRTX3060の消費電力でやることではあるまい。いやまぁ、それをいったらブログ執筆もそうなんだけどさ…。

あとドライバ周りで苦労することになる可能性もあるしなぁ。開発自体はLinuxのほうがやりやすいけれど、それはメインデスクトップのMacでやればいいことではあるし。サブノートはLinuxなので、メインノートはWindowsを使うことで、一通りのOSを触り続けられるというのはあるし。

いずれにせよ今月はちょっと落ち着かないので、やるとしても来月かなぁ。MSが余計なことしなければWindowsでもいいんだけどなぁ。

<関連記事>

/windows-11-init/

Trilium Notes (Docker) のマシンを移行する

Sun, 07 Jun 2026 21:21:36 +0900

現在運用しているTrilium Notesについて、Intel Mac mini 2018 + Docker Desktop から Linux Mint Xfce 22.3のサーバマシンに移行する。

環境

Trilium Notesのlatest
移行元
- Intel Mac mini 2018
  - macOS Sonoma 14.6.1
  - Docker Desktop for mac v4.76.0
移行先
- ThinkPad L390
- Linux Mint Xfce 22.3
  - Docker 29.5.2

手順

移行元のマシンで停止する。

docker compose down

docker-compose.ymlでデータディレクトリを確認する。TRILIUM_DATA_DIRがどうなっているか見る。

# Running `docker-compose up` will create/use the "trilium-data" directory in the user home
# Run `TRILIUM_DATA_DIR=/path/of/your/choice docker-compose up` to set a different directory
# To run in the background, use `docker-compose up -d`
services:
 trilium:
 # Optionally, replace `latest` with a version tag like `v0.90.3`
 # Using `latest` may cause unintended updates to the container
 image: triliumnext/trilium:latest
 # Restart the container unless it was stopped by the user
 restart: unless-stopped
 environment:
 - TRILIUM_DATA_DIR=/home/node/trilium-data
 - TZ=Asia/Tokyo
 ports:
 # By default, Trilium will be available at http://localhost:8080
 # It will also be accessible at http://<host-ip>:8080
 # You might want to limit this with something like Docker Networks, reverse proxies, or firewall rules,
 # however be aware that using UFW is known to not work with default Docker installations, see:
 # https://docs.docker.com/engine/network/packet-filtering-firewalls/#docker-and-ufw
 - '8080:8080'
 volumes:
 # Unless TRILIUM_DATA_DIR is set, the data will be stored in the "trilium-data" directory in the home directory.
 # This can also be changed with by replacing the line below with `- /path/of/your/choice:/home/node/trilium-data
 - ${TRILIUM_DATA_DIR:-~/trilium-data}:/home/node/trilium-data
 # - /etc/timezone:/etc/timezone:ro
 - /etc/localtime:/etc/localtime:ro

ここでは~/trilium-dataとなっている。ついでにMacで/etc/timezoneがなかったのでコメントアウトされているね。

とりあえずアーカイブ化しよう。

tar -czvf trilium-data-backup.tar.gz ~/trilium-data

こいつを新しいマシンに転送してやる。

scp trilium-data-backup.tar.gz ユーザ@IPアドレス:移行先のパス

新しいマシンで、これを保存先ディレクトリ上に展開する。今回はtrilium-dataにしている。

tar -xzvf trilium-data-backup.tar.gz

保存先ディレクトリに入って、もしデータベースの一時ファイルが存在したら削除する。

rm -f document.db-shm document.db-wal

準備ができたらコンテナの起動。とりあえずフロントで。

docker compose up

エラーなく起動したら、http://IPアドレス:ポートにアクセスする。以前使っていたパスワードでログインできることを確認する。

問題なければOK。Ctrl-cで停止して、改めてバックグラウンドで起動する。

docker compose up -d

これでOK。しばらく動かして、安定していることを確認したら元のコンテナは削除してよい。

<関連記事>

/evernote-notion-trilium-notes/

Dell Latitude 5290は中古PCサーバの母艦としていいかもしれないね、一方クライアントなら意外にも…

Tue, 26 May 2026 00:00:00 +0900

うちには40台くらいジャンクPCがある。特に2018年前後を集めており、定番なのはLenovo ThinkPadとDel Latitudeあたりだ。このへんはまぁ安いといってもジャンクの中では高いのかもしれないのだが、既に送料で底打ちがあるため、バランスを取るならこのへんかなぁ、とは思う。ジャンクでバランスもなにもないが…。

結局Linuxに似合う中古PCはなんなんだい

個人的には、漁っているとFUJITSUのLIFEBOOKやPANASONICのLet’s Noteの古いやつなんかが、むしろ良いのではないか？という気がしている。流通量もそこそこあるし。あのへんはLenovoやDellとは異なる方向にブランドなので、必ずしも安くなっていない…なんなら骨董品レベルのものがやけに高く売られていることもある。あの時代のパーツがほしい人向けなんだろうか…しかしコンシューマのPCでそんなことあるかなぁ。

まぁなんでもいいのだけれど、無難にいくならThinkPadかLatitude、というのはそれはそう、という感じだ。ただ2018年より、ThinkPadの上位モデルであるX280以降はメモリソルダリングという悪に手を染めてしまっているため、それより一つ落ちるはずのL390のほうが、メモリの拡張性高い分使いやすいという逆転現象が起きている。筐体の無骨さもサーバ用途ならばむしろ悪くない。まぁ問題は、L390はThinkPadシリーズの中だとそんなに量が出回っていないということかな…。あと、LANポートがないのもいたいね。

そこでいくと、Dell Latitude 5290は攻守ともに強い感じだ。メモリも換えられるし。ま、ちょっと重いかな。Dellらしい無骨さではある。しかし前述したようにサーバで無骨さは褒め言葉よ。ただ同じ型番で2-in-1タイプもあるらしいが、そちらはオンボードという罠仕様になっている。まぁジャンク漁りをする人の中でも2-in-1を狙うのはさらに数寄者だろうから好きでやっているんだろうが…。

なので、僕はThinkPad L390を母艦にしているけれども、Dell Latitude 5290も実は候補に上がっていた。しかし結局L390になり、Latitude 5290は仕事で使うPCとして供養する流れだ。Core i5-8250Uと8GBという必要十分なスペックに、LANポートがあるのが決めてになったかな。LANポートがあると、それ経由でシングルボードな子機とサクッと接続できるのがよい。SSDは家にあった128GB SATA SSDだがね。m.2 2280フォームファクタのSATAがあるなんて、ジャンク漁るまで知らなかったよ…。

まぁThinkPadだのDellだのも当然のように裏蓋ネジなかったり画面TNでもやってたしCMOS切れてたり通信たまに切れたりバッテリー死んでたりするという点では変わらない。そこは安くどうにかできるならなんとかするし、できるけど高く付くならそういう使い方は諦めるという割り切りが必要だ。

クライアントならちょっと冒険してみて…

さて少し目先を変えて、そんなサーバとかじゃなくて、普通に普段遣いでやりたいんだけど、という向きでは、僕の見た感じだと感触はかなり異なる。

ここで一番重要なのは液晶で、画面は生きててIPSフルHDとバッテリーとキーボードタッチパッドが生きていること、が条件となる。あとためらわないレベルで外観が保たえれていることとか（時々戦争に持っていったの？みたいな可愛そうな筐体がある…）。ここがクリアしていればあとはまぁなんとか。

まぁあるにはあるんだけど、普通に1万超えてくるよねこんなの。高いよ。ジャンクでも2万くらいはある。まともな中古店なら2万後半から3万しててもおかしくない。これからもっと高くなるかもな。

…なんですけど、PANASONICとかLIFEBOOKで捨て値になっているように、バッテリーが死にかけだけどもまだ残っていて、驚くべきことにIPS FHD（ときどきTN FHDがあるので気をつける）、みたいなのが、3000円とか5000円とかで手に入ったりすることもある（送料込み）。もちろんCPUは期待するな。Core i5第4世代でも気にするな。でもバッテリー生きてるならなんでもいいじゃない！たとえ残り39%とかだったとしても！

このへんのはね、まぁさすがに常用はつらいと思うけど、サーバよりも持ち運びたいタイプの特定用途のクライアントPCとして活躍の場があると思ったな。筐体のめっちゃ軽いからね。当時は最先端だったんだろう。

PANASONICの昔のやつとかでもボタン一つでWi-fi切り替えギミックとかほしい人はほしそうなやつあるしね。まだそこまでちゃんといじってなけど、僕はけっこういいと思ったな。

どんどん検証していく

40台くらいジャンク揃えたけど「完璧だ！」みたいなのマジでなくて、「こいつはここがなぁ…」のオンパレードです。今はThinkPad L390を使っていて、これは比較的の文句のないPC…に見せかけて、クリックパッド死んでたりするからねｗあとなんか全体的にもやってる。まぁあんまりメインディスプレイがっつり見ないけどね。

とりあえず今日現時点においては、このサイトはThinkPad L390 Core i5-8265U, 32GB RAMで動いております。RAMだけすごい。普段は3-6GBの利用料なので完全に無駄。でもこれからメインサーバの機能をうつしていったら重くなるかも。

最初の間は消費電力も10Wくらいだったけど、メディア系のサーバを入れ始めたから、いまは15Wくらいにあがってそうだなー…。Jellyfinとかは入れる予定ないんだけど。Immichは入れようかなぁ。家族にAppleやGoogleにお布施しているのがいたら救ってもいいんだが…。

この子がいつでも最後のちからを振り絞れるように、後ろに何台ものジャンクを控えさせておかないとな。そういう態勢を整えて、知見を共有していきたい。

まぁなんにしても、あんまり失敗したくなくて、でもLinuxほしいなぁって雑に思う人はDell Latitude 5290はいいと思うよ（2-in1は避けつつ）。ジャンクなら別途パーツ含めて1万、保証付きの中古ショップなら…25000くらいかなぁ。ジャンク市場もこれからどうなることやら…

Linux Mint Xfce 22.3 + LyrionMusicServer + Squeezelite で音楽生活

Mon, 25 May 2026 00:00:00 +0900

メインサーバになりつつあるLinuxマシンに、チューナレステレビをHDMIでつなぎ、TVに光オーディオ出力でアンプに繋がっている。たいへんややこしい状況だが、どうせなら音楽はこのアンプでききたいものである。

ということで、音楽サーバ構築編。

環境

とてもややこしいけれども以下のような感じだ。

graph TD
subgraph PCA ["PC A (操作端末 / リモコン)"]
Browser["Webブラウザ / App(Material Skin UI)"]
end
subgraph PCB ["PC B (Linux Mint / サーバー兼再生機)"]
direction TB
LMS["Lyrion Music Server(楽曲管理・配信)"]
subgraph AudioOutput ["音声出力プロセス"]
Squeezelite["Squeezelite(再生用クライアント)"]
PipeWire["PipeWire / ALSA(OS音声制御)"]
end
Storage[("音楽ファイル群(HDD/SSD)")]
end
subgraph AudioPath ["中継・出力"]
TV["Mi TV(音声ハブ)"]
Speaker["外部スピーカー"]
end
%% 接続とデータの流れ
Browser -- "① 選曲・操作命令 (Port 9000)" --> LMS
LMS -- "② 音楽ストリーム送信 (Port 3483 / localhost)" --> Squeezelite
Squeezelite -- "③ 音声データ引き渡し (default出力)" --> PipeWire
Storage -. "スキャン (パーミッション確認済)" .-> LMS
%% 物理接続
PipeWire == "④ HDMI出力 (DEV=3)" ==> TV
TV == "⑤ 光デジタル出力" ==> Speaker
%% スタイル設定
style PCB fill:#f5f6f8,stroke:#4f5b66,stroke-width:2px
style LMS fill:#d1e7dd,stroke:#0f5132
style Squeezelite fill:#fff3cd,stroke:#856404
style Browser fill:#cfe2ff,stroke:#084298
style PipeWire fill:#e2d9f3,stroke:#4b2c7e
style TV fill:#eeeeee,stroke:#666

HW/SWは以下。

ThinkPad L390
- 32GB RAM
- Linux Mint Xfce 22.3
- squeezelite v1.9.9-1449
- Lyrion Music Player v9.1.0

インストールと設定

Lyrion Music Server

Getting Started with LMS - Lyrion Music Serverより、ダウンロードリンクを取得。記事を書いた時のリンクだとこれ。

wget "https://downloads.lms-community.org/LyrionMusicServer_v9.1.0/lyrionmusicserver_9.1.0_amd64.deb"
sudo apt install ./lyrionmusicserver_9.1.0_amd64

ステータスを確認する。

sudo systemctl status lyrionmusicserver.service

enabledでactive(running)になっていることを確認する。

ポートを空ける。

sudo ufw allow 9000/tcp

そうしたら http://IPアドレス:9000にGo。右下のNextボタンで、音楽ファイルの場所と、プレイリストを保存する場所を指定することになる。

ここで、ディレクトリのパーミッションは755でないとLMSが読めない。基本的にホームサーバならディレクトリは755でよいはず。外付けディスクとかでパーミッションまとめて変える必要があるときはfindで一気にやってしまう。たとえば/mnt/hddのときは以下の感じ。

find /mnt/hdd -type d -exec chmod 755 {} +

ホームディレクトリは~/.sshとかあるんでまとめてやるとか雑なことはしない。

さらに音楽ファイルの権限も600とかだと読めない。音楽ファイルのあるディレクトリに移動して、パーミッションを変更する。

find . -type f -exec chmod 644 {} +

再スキャンするときは、Web画面で歯車よりServerから再スキャン可能。

とにかく音楽フォルダとプレイリストフォルダのパーミッションは整えてやる必要がある。ちなみにうちの場合は音楽ファイルは外付けのハードディスクドライブで、プレイリストフォルダは内蔵SSDのホームフォルダ内にしている。

Squeezelite

まずポート空けておく。

sudo ufw allow 3483

以下でインストール。

sudo apt install squeezelite

入れたら出力を確認する。

squeezelite -l

なんかいっぱい出てくる。ここでハードウェアを指定して /etc/default/squeezeliteを書き換えていく、ということになっているのだが…。

ただねぇ…僕はここから相当転がされた結果、一つの結果にたどり着いたが、これは一般的ではない、とあらかじめ申し添えておく。

まずapt installしたら勝手にsystemctlで動いているsqueezeliteを殺す。

sudo systemctl stop squeezelite.service

有効化はされてないのでdisableする必要はないが、もしenableしてしまったらdisableもしておく。

そのうえで、~/.config/autostartにスタートアップスクリプトを書いていく。ディレクトリがなかったら最初につくる。

mkdir -p ~/.config/autostart

そしたら設定ファイルを書く。

cat << 'EOF' > ~/.config/autostart/squeezelite-tv.desktop
[Desktop Entry]
Encoding=UTF-8
Version=0.9.4
Type=Application
Name=Squeezelite-TV
Comment=Hand-launched success command with delay
Exec=bash -c "sleep 5 && squeezelite -o default -n MiTV"
OnlyShowIn=XFCE;
StartupNotify=false
Terminal=false
Hidden=false
EOF

Execのところは適当に。-n MiTVは僕がMiTV使ってるからなので。適当にわかりやすい名前にする。

再起動して、LMSで見つかるかどうか試す。見つかればOK。

これは明らかに標準の方法ではないが、これが一番安定した。systemdはクソ。昔から思ってたけど、僕の頭が悪いんだと思っていた。今となっては自信を持って言える。僕の頭が悪かろうがなんだろうが関係なくsystemdはクソ。

systemdはクソ

疲れた。なんだかんだで半日消費した。あとは運用していきたい。

ちなみにフォルダ管理派はフォルダをブラウズするように設定できるが、そのへんの話はMacのときに書いたのでそちらを参照。

/mac-mini-2018-lyrion-music-serverlms-logitech-media-server-squeezelite/

ってかPipeWireって何？とか、基本的なところ理解できてないなぁと思った。systemdはクソ。

Core i5-8xxxUをLinuxサーバにしたらメモリより先にCPUが燃え尽きる

Mon, 18 May 2026 00:00:00 +0900

だからメモリ8GBでも気にしなくてｲｲﾝﾀﾞﾖ！

ざっとこんな感じさ。4コアを使い尽くしているよ。でもメモリは3GBだよ。32GB刺しているのにゴミのようだ。

まぁこれは動画をエンコードしているのでそれはそう、ではあるのだけれど、基本的に3GBくらいが普通なんだよね。一番多いときでも7GBくらい。まだ多くの機能をIntel Mac mini 2018をやっているから、それらの機能を全部うつしたら…特にImmichなど重量級なのを移したらもっと使うだろうけれど、それにしても多分CPUのほうが先に音を上げるんじゃないかな？かな？

まぁディストリビューションはLinux Mint Xfceで、最新のUbuntu使ってGNOME使ってとなればこうもいかないと思う。でもそれはOSの本懐じゃないよね。CUIとか言う前にまず軽量GUIを試すべきだ。特にホームサーバにおいて、GUIは非常に有力なのだ。これを利用しないのは非常に勿体ないと思う。

最先端GUI or CUIってーのは極端だ。リッチなクライアントかもしくはクラウドのサーバかってそういう思考になっちゃってんじゃない。でもPCってそうじゃなかったよね。もっといくらでも良い選択肢があるのだし、それを選び扱えてこそじゃなかろうか。

そんなわけで、第8世代の値下がりジャンクをLinuxサーバにしてやろうという賢いユーザはメモリについて8GBで実用上十分くらいでいいんじゃないかな。

ちなみにこんなPCでエンコードしているのは、現在制作中のデジタルコンテンツ管理アプリ、DigitalShelf（仮）の試運転です。試運転といっても自分のデータを扱っているのでゴリゴリ本番なんだけどね。また、これは標準機能ではなくて、ffmpegを使った外部プラグインという立ち位置。外部プラグインなのでソースコードは開示しなくていいって寸法よ。別に開示してもよかったんだけど、なんかもうOSSは開示したらAIでアタックされるという酷い時代になったので、もう何もできないよね。

まぁ僕もAI使ってアプリ作っているわけだが…。激動の時代だけれど、結局shは動いているという事実を大事にして明日を生きよう。