コントラストの問題を文句言うには間違ったサイトに来ちゃったね、友よ。

同意。ページが読み込まれた後、最初に思ったのは「なんでこのページは読みづらいんだ？」ってことだった。

あと、セリフ体が使われてる。まるでスタイルシートの半分が欠けてるみたい。

Macの場合はShift-Cmd-Rでリーダーモード。

もっと強いブランド名が必要だと思う。それに、macOSではDocker Desktopの方がわかりやすいと感じた。最近はエラーが多いし、ファイルのマウントやネットワークリールのクリーンアップでランダムに失敗したり、突然遅くなってVMを再起動しなきゃいけなくなる。macOSでのPodmanは全然洗練されてない感じ。Orbstackの方がずっといい選択だよ。LinuxではPodmanを使ってるけど、そっちはめっちゃ速い。とはいえ、ほとんどの機能はsystemdと組み合わせてKubernetesの代わりになるように設計されてるみたい。Docker Composeのサポートが不安定で、TUI/UXも元のものに比べて遅れてる。

Podmanはちょっとした理由で諦めたんだ。まず、Dockerから逸脱してSELinuxの扱いを変えたせいで、CentOSの標準システムでSELinuxのセキュリティラベルを変更するのが面倒だった。それで無理だなって思った。もう一つの問題はDockerとの微妙な違いなんだけど、Docker Composeがそのままじゃ動かないくらいの小さな違い。Dockerに切り替えればすぐに動くし、時間を無駄にしてデバッグするのは良くないと思った。

最後にPodmanを評価したとき、Ubuntuは二級市民だった。Rootlessは簡単じゃなくて、追加の設定が必要だった。ドキュメントもひどかったし。Dockerはみんな嫌ってるけど、無限のエッジケースやバグがあるにしても、少なくともよく文書化されて理解されてる。Podmanが「ドロップイン置き換え」と主張してるけど、それはDockerのクソさを引き継ぐってこと？例えば、ufwの通過、envファイルの扱い、ボリュームなど。

Dockerの利点の一つは、ホストからコンテナへのファイル変更通知が信頼できること。これにより、コンテナ内のViteのようなツールが変更を検出できる。Podmanや他の多くの代替品は、macOSでのウェブ開発にはこれをうまく処理できていない。私の知る限り、TartやApple Containerもサポートしてない。誰か方法を見つけたかもしれないけど。

最後に確認したとき、podman composeはただの表面的なdocker composeの同等物だった。あと、inotifyのようなものがPodman側でランダムに壊れることが多いみたい。Podmanを使うことを勧めたいけど、Docker Composeとの互換性が良くないのと、ボリュームのinotifyがないせいで、開発体験が問題だらけなんだ。

今日、Fedora（Asahi）でpodman-dockerを使ってリモートホストでdocker composeを実行しようとしたんだけど、いろんなbuildxの問題にぶつかった。私にとって一番簡単な解決策はPodmanを削除してDockerをインストールすることだった。Claudeと一緒に解決しようとしたけど、数回の失敗の後に諦めた。Podmanを使いたいけど、Docker Composeとbuildxの互換性のギャップがあって、今のところは手間がかかりすぎる。絶対にもう一度試してみるつもりだけど。