Kaohsiung on Ivon's Blog

KaLuG 2603オープンソース集会メモ

infoivonblog.nkfjt@aleeas.com (Ivon Huang) — Sat, 21 Mar 2026 17:00:00 +0800

今日のテーマはlightning talk形式の継続だった。前回から二か月ぶりの集まりだ。

雄校聯で引き続き学生サークル（迫真）の名義を使い、無料の会場を借りた。

メモはHackMDに置いてある。

まずShawnがRedHat OpenShiftの発展見通しを共有し、OKDとOCDの上下流開発関係を説明した。Fedora、CentOS Stream、RHELの関係を整理し、CentOS Streamはそれほど不安定ではないのだとわかった。彼はその位置づけがUbuntu LTSに近いと考えている。CentOS Streamには依然としてメジャーバージョン番号があり、kernelバージョンも固定される。RedHatは今でもCentOS Streamへ修正を送り、オープンソースコミュニティがエラーのテストを手伝う形だからだ。Shawnは、これによってより健全なエコシステムを形成できると考えている。しかし私は、それなら……Ubuntu LTSを使えばいいのでは、と思った。

ついでにFedora CoreOSの利点も紹介された。bootcを大量に採用し、image-based方式でシステムをデプロイする。その中で、時機が熟せば将来的にrpm-ostreeはcomposefsに置き換えられるかもしれないという話が出た。composefsはLinux kernelのerofs機構を有効に活用してシステムファイルを処理できる。しかし私はこう聞きたい。今すでにuBlue Bazziteのようなbootcで実装された製品があり、彼らの最大の問題はユーザーがローカルで手動に.rpmファイルをインストールしにくく、システムイメージを再作成するしかないことだ。これはlocal layeringと呼ばれる。ではcomposefsはこの問題をどう解決するのか？この問題について、私たち二人は満足できる答えを出せなかった。現時点ではこの技術もまだ定型化していない。今後を待つしかない。正直、私はシステムに何か追加パッケージを入れるたび、毎回クラウドで手動buildしたイメージを引っ張ってきてデプロイするなんてやりたくない。

KaLuG 2512 オープンソースコミュニティ集会小記

infoivonblog.nkfjt@aleeas.com (Ivon Huang) — Sat, 13 Dec 2025 17:00:00 +0800

前の二か月はどちらもSecond Spaceの共有スペースで集まっていたが、今日は初めて比較的大きな雄校聯の部活会議室へ移った。9階の床から天井まである窓から、向かいの中央公園の景色を見下ろせる。

今日のテーマはlightning talk形式。

議程：2512- 第一次雄校聯聚會

ShawnはPi500を本当に使えるコンピューターへ改造した経緯を共有した。外付けモニターを加えると、この金額はもうAndroidタブレット一台に近いではないか。ましてWaylandデスクトップは自分で設定しなければならない。やはり彼も、Fcitx5が特定のGTKプログラムで中国語を入力できない問題に遭遇していた。

ある高校生が登壇し、彼らが運営する鑽石Minecraft伺服器託管サービスを共有した。一部は公開版のPterodactyl Panelを改造したものとはいえ、やはりすごい。完全な管理システムがあり、コマンドを打たずにMinecraftサーバーコアをリアルタイムで差し替えられる。Aternosのような壮挙を思い出した。

YCが解決したいFRRouting Projectの題目は専門的すぎる。これはもはや業界内部の人でなければ答えられないレベルだろう。私はただ何度もうなずいて分かったふりをするしかなかった。ふう、もしグループディスカッションをするなら、私はおそらく役に立てない。

KaLuG 2510 オープンソースコミュニティ集会メモ

infoivonblog.nkfjt@aleeas.com (Ivon Huang) — Tue, 28 Oct 2025 17:00:00 +0800

今日はまず、ShawnがSystemd開発者も参加する会議「All Systemd Go」について共有するのを聞いた。本当にどんなプロジェクトにも参加できる会議があるものだな。この種の専門科目を探究する会議は、外国だからこそ開催できるのだろう。

議程：KaLUG meetup 2510 - kernel 遇上 user space

私たちは二か月連続でLinux kernelの話をしているようだ。すごい開発者を招いて共有してもらえるのは本当に光栄だ。

今日のKaLuGで聞いた、期待できるLinuxカーネルの新機能はsched_extプロジェクトだ。台湾の成大の貢献者による成果も含まれ、Linux 6.12で導入された。これはユーザーがeBPFを通じてuserspaceからスケジューラー(scheduler)を変更し、カスタムのスケジューリング操作を実現できるようにする。さらにcgroupも設定でき、各cgroupがそれぞれ異なるスケジューラーを独立して実行できる。過去にこの目的を達成するにはカーネルを再コンパイルする必要があった。なにせ内蔵スケジューラーは数種類しかないからだ。しかしクライアント側が作業場面に合わせて自分で実装したいスケジューラーを持っていても、上流がすべてのスケジューラーのマージを受け入れることはありえない。だから、このような経済的な方法を提供し、ユーザーが自分で定義できるようにしている。

KaLuG 2509 オープンソースコミュニティ集会小記

infoivonblog.nkfjt@aleeas.com (Ivon Huang) — Sat, 13 Sep 2025 17:00:00 +0800

今日のテーマはRustでLinux kernelのカーネルモジュールを書くことだった。将来カーネルへ入っていく言語については、早めにこの言語を理解しておく必要がある。

録画：KaLUG meetup 2509 - Rust 的奇妙冒險：Hello Heaven (Rust for Linux)

今回KaLUGのイベントに参加したとき、私は現実で本当にNixOSユーザーを見たのが初めてだった…ずっとこのシステムを試してみたいと思っていたが、抜け出せないカルトに落ちるのではないかとかなり心配している。

結局、declarative式reproducibleなシステムは主流ではない。あなたはAnsibleを見ていないのか？ディストリビューション横断のパッケージインストール解決策を論じるなら、現在はFlatpak、AppImage、Snap、Nix、Guixなどがあり、Podman + Distroboxのような比較的奇妙な方案を使うものさえある。pipとnpmは含めない。なぜならそれらはLinuxソフトウェアのパッケージング専用に設計されたものではないからだ。それぞれ実装は異なるが、いずれもディストリビューションをまたいでソフトウェアを使うことを実現できる。ディストリビューション横断のパッケージインストール方案を使う場面の一つは、安定したシステムに不安定なパッケージをインストールしたい場合だ。たとえばDebian Stableの安定したシステムと、Arch Linuxの最新パッケージを併せ持つようなものだ。どの方案を選ぶかは、ユーザーがどの機能をより重視するかによる。コンテナ化を気にせず、無套接觸を望むならAppImageまたはNixを使う。Nixはさらに開発者向けで、使い心地はmacOS上のHomebrewに似ている。しかもそのパッケージ管理機構は、ソフトウェアが絶対に依存関係を壊さないことを保証し、まるで静的リンクのようで、100%ロールバックもできる。少しのコンテナ権限制限を受け入れられるなら、選択肢は多い。どれがよりよいかを急いで決める必要はない。結局は開発者がどの形式を好むか、開発者がよりパッケージングしたがるか、そしてユーザーがそれらのソフトウェアを容易に取得できるかを見ることになる。私から見ると、FlatpakとSnapはユーザーに比較的優しく、Distroboxは純粋に開発者向けのツールで、Nixと同じく使うには高度な技術が必要だ。