Foss-Issues on Ivon's Blog

KaLuG 2605 集会ノート：UbuntuとFedoraの合同リリースパーティー（豊富なテーマ付き）

infoivonblog.nkfjt@aleeas.com (Ivon Huang) — Sat, 16 May 2026 18:00:00 +0800

今日のトピックは実に多岐に渡りました！消化しきれないほどの量でした。そのボリュームはCOSCUPのライトニングトークに匹敵するほどでした。

アジェンダ：Ubuntu 2604 x Fedora 44 リリースパーティー

可愛らしいAIポスター

以下に簡単なメモを記載します。

Ubuntu 26.04

Nix

UbuntuCon COSCUP SLAT

カーネル 7.0

Framework 13 入門

SBCモジュール、Luckfox、ESP32、ESP32の使い方解説

SiFive P570

Linuxドライバ DTSビジュアライザー

LAVDスケジューラ

大まかな内容しか理解できませんでした。

ついに、またしても矛盾の極みに遭遇しました。

高雄で開催されたUbuntuリリースパーティーに参加したのですが、10人中9人がFrameworkかMacBookを使っていました。

ずっとFramework搭載のノートパソコンが欲しかったんです。自分でパーツを組み立てて、何でも交換できるからです。

今日、FrameworkのQAチームに連絡してステッカーをもらったので…修理不可能なSurface Go（誰もが知っているように、プラスチック製の水平調整板です）に貼って、Windowsのロゴを隠すことにしました！

内部システムは…すでにDebian Linuxにチューニング済みです。金属製の筐体とLinuxシステム――これで、基本的なフレームワークが完成しました…😇

KaLuGのメンバーと会った時、なんとRSSリーダーを使って私のウェブサイトにアクセスしている人がいると聞きました👀

オープンソースのデジタルカメラシステムはAndroidスマホ + Open Cameraしかなさそうだ

infoivonblog.nkfjt@aleeas.com (Ivon Huang) — Wed, 13 May 2026 10:00:00 +0800

ある問題を考えたことがある。オープンソースのデジタルカメラシステムは存在するのだろうか？

オープンソース撮影の画像処理ワークフローは存在するのか？オープンソース画像処理ソフトウェアにはGIMP、Krita、digiKam、darktableのようなものがある。しかしまずは上流の画像取得デバイスの問題を解決しなければならないだろう。

スマホよりはるかに大きい絞りを持つ一眼カメラやビデオカメラ、たとえばNikonやSonyが出しているものでは、その上で動くOSはどれもクローズドソースなのだろう。

底層ドライバーからソフトウェアまで開放されたデジタルカメラはあり得るのだろうか？単にRaspberry Piへカメラを付けたようなおもちゃではなく。

オープンソースソフトウェアを欠くカメラは、私に購入をためらわせる（実際には買う金もない：P）。

私がプロプライエタリソフトウェアを拒否するためにSwitchやPS5のような家庭用ゲーム機を買わないのと同じだ。彼らはBSDのオープンソース成果を奪った。Steamプラットフォームはぎりぎり受け入れられる。しかしPCでプロプライエタリなSteamゲームを遊ぶだけでも、私の内心は十分に苦しい。

Androidカメラの撮影技術でさえ、大部分はクローズドソースAPPのアルゴリズムに支配されているように見える。各スマホメーカーは自社純正カメラAPPを開発しており、私たちにそれらのクローズドソースAPPへ依存することを強いている。

たとえOpen CameraやFreeDCam、Photon Cameraのような機能豊富なオープンソースAPPがあっても、それらは各スマホのレンズハードウェア機能を完全にはサポートできない。たとえば30倍AIズームや、背後で写真を美化するアルゴリズムなどだ。

撮影後に後処理を行うアルゴリズムは、さらに各大メーカーの商業機密である。Sony、小米、Pixel、Samsungにはそれぞれ自社の味がある。Gcamを他のスマホへ移植できたとしても、その背後のアルゴリズムがどうなっているのかを理解することはできない。

したがって、OpenCameraで撮った写真の品質が純正カメラより一段低くなるとしても、それは純粋にイメージセンサーのハードウェア力を見る形になり、より多くの手動パラメータ介入が必要になる。あるいはRAW形式で保存し、その後digiKamで手動現像することになる。

とはいえ、Androidはカメラハードウェア機能へのアクセスに関して、少なくとも純Linuxより成熟しているだろう。AOSP公式ドキュメントを見れば、少なくともCamera2APIでISOを調整でき、Pixelには第三者APPが夜景モードを使える公式公開APIもある。

純GNU/Linux環境でIMXコンポーネントを駆動するとなるとさらに難しい。Linuxではlibcameraを使ってカメラを正常に動作させられるだけで天に感謝すべきであり、写真撮影という学問を研究している人はいない。

PinePhone向けにMegapixelsカメラAPPを書いている兄貴も、かなり無理をしてpipelineを一つ作っただけだ。

要するに、レンズハードウェアの素質が十分に強いAndroidスマホを買い、それをLineageOSへROM焼きして、Open Cameraを使う。私がSony Xperia 1 IIIに対してやったように。これが比較的受け入れられるオープンソース撮影方法である。底層ドライバーがクローズドソースなら、それはもうクローズドソースでいい。

初めてのUnix Socks

infoivonblog.nkfjt@aleeas.com (Ivon Huang) — Wed, 15 Apr 2026 23:00:00 +0800

彼らはこう言う。熟練したLinuxユーザーなら、unix sock(et)sの操作を理解しているべきで、当然unix socksも履くべきだ。coding力が倍増する、と。

真夏にこういう長い靴下を履くのは本当に暑くて死ぬ🥵

うん……たぶん私のcoding力がまだ足りないのだろう。このピンクの靴下の長さは、かろうじて太ももに届く程度だ。

それから、数年前に買った白いシェルジャケットは、かなり伍佰《純白的起點》アルバムジャケットの雰囲気がある。

今年はこの新しい青いジャケットを買った。見たところは普通のスタジャンだ。

しかし配色を少し濃くすれば、これは高松燈のMyGOバンド衣装ジャケットになるのではないか（幻視）

この服はメンズでもレディースでもいけるはずだよね…?なんとなく、化粧しないと外に出られない感じがして、少し女装を試してみたくなった。

私はすごいエンジニアを何人か知っていて、その一部は女装癖があり、一部はトランスジェンダーの人だ。しかし今の私の身分と接している人々を考えると、着て外に出ればより高い確率で社会的に死ぬ。だから、私はサイバー空間でだけ共有する。

Hackintoshは死んだ、それでいい。macOSを使うこと自体が不自由なシステムを広める行為だ

infoivonblog.nkfjt@aleeas.com (Ivon Huang) — Wed, 15 Apr 2026 16:00:00 +0800

Hackintosh is (kind of) dead.

なぜHackintoshを使うのか？あるいは、なぜmacOSを使うのか？

MacbookとiPhoneは監獄である。それなのにユーザーはAppleの檻を喜んで受け入れ、それが流行にまでなり、自分を果粉だと誇り、商品拜物教を形成している。

リチャード・ストールマンがRTテレビで言った言葉を借りれば、一般人はスティーブ・ジョブズの話術に説得され、Macbookはおしゃれでクールだと思い、自分からApple Storeへ走って行き、「どうか私に手錠をかけてください！」と言うのだ。

Richard Stallman Talks About Free Software RT News（10:58分處）

ここに一言補える：エンジニアはUnix-basedなシステムは便利だと思っているので、自由度を犠牲にしても問題ない。私にも手錠を一つください！見てください、私は大金を払ってoverpricedな手錠を買い、その上には私の名前まで刻印されているんですよ！

Appleの実体商品を崇拝するだけでも十分に大げさだが、さらに大げさなのはOSを崇拝することだ。Apple公式販売ではないハードウェアへmacOSをインストールするために形成された黑蘋果 (Hackintosh)コミュニティは、その典型例である。

2020年、AppleはARMアーキテクチャへの移行を始め、x86アーキテクチャのMacコンピューターへのサポートを段階的に放棄し始めた。

Apple公式資料とメディア報道を総合すると、macOS 26はx86_64アーキテクチャをサポートする最後のmacOSバージョンになるはずだ。将来的には、最上位のiMac Proであっても、Intelプロセッサを使用しているかぎりアップグレードできない。今後はARMアーキテクチャのMacしか使えなくなる。

つまり今後、普通のx86コンピューターではHackintoshで遊べなくなる。Hackintoshは（ほぼ）死んだ。少なくとも最新版macOSはインストールできない。旧版macOSはHackintosh互換のx86ハードウェアへまだインストールできるが、主流ソフトウェアからのサポートは徐々に捨てられていくだろう。現段階では、オープンソースコミュニティがApple Siliconを解析した成果としてAsahi Linuxがあるが、macOSをApple社製ではないARMデバイスへインストールすることはまだできない。

実のところ、私はこれでいいと思っている。人々にHackintoshを完全に諦めさせるからだ。この二十数年、Hackintoshを動かすことは、もともと大企業のbootlickerになる行為だった。

誰もが知っているHackintoshの豆知識を一つ話そう。Hackintoshをインストールするとき、通常はブートローダーに以下の文字列を追加しなければ、カーネルを正常に復号して起動できない：

ourhardworkbythesewordsguardedpleasedontsteal(c)applecomputerinc

この文こそがDont Steal Mac OS.kextだ。彼らが自社OSの知的財産権をどれほど丁寧に保護しているか見てほしい！Apple認証ではないハードウェアでmacOSを実行することは、窃盗行為なんですよ！それなのにあなたは、こんな会社の顔色に合わせようとするのか？

ここで言うbootlickerには、OpenCoreやCloverのようなオープンソースのブート方式を熱心に作っている達人たちは含まない。彼らは多大な貢献をしている。macOSの構造を研究し、大量のplistとkextを書き、Apple公式認可ではないドライバーを動かせるようにしている。もしかすると本当に、オープンソースコミュニティが完全に自由なmacOSをリバースエンジニアリングする助けになるかもしれない。たとえばravynOSはDarwinカーネルとFreeBSDのオープンソースコンポーネントを混合したmacOS風システムであり、このシステムの存在はWindowsをリバースエンジニアリングするReactOSに少し似ている。このような研究用途でHackintoshを使う場合だけは有益である。

だが、私が主に言っているのはHackintoshユーザーの心態だ。bootlickerに属する、あるいは彼らを"apple" polisherと呼ぶほうがよいかもしれない。大企業のものを破解することで、自分の虚栄心を満たしている。しかしmacOSは依然としてクローズドソースソフトウェアであり、BSD革命の果実を盗んだ邪悪な資本である。これもBSDが悪い。FreeBSDが簡単に寝取られるBSDライセンスを使い、GPLを使わなかったからだ。德匹下。

macOSでは、ユーザーの自由はあらゆるところでApple社に制御されている。Homebrewという不具のパッケージマネージャーを使うことを強いられ、さらにAppleの計画的陳腐化を受け入れなければならない。期限が来ればシステムをアップグレードできなくなる。その会社が「私たちはもう十分長くサポートした」と主張していてもだ。

もしmacOSのデザイン美学が欲しいだけなら、LinuxにGNOMEやKDE Plasmaデスクトップをインストールし、少しテーマを入れれば80%くらい似たグラフィック体験は得られる（White-Surプロジェクトを参照）。それなのに、わざわざHackintoshをいじり、自分から進んで監獄へ入るのは、本当に理解しがたい。これを研究する時間があるなら、トースターでLinuxを動かす方法でも考えたほうがいい。

一歩譲って、商業ソフトウェアを使うにしても、互換性がより広いWindowsをインストールするほうがHackintoshよりよいのではないか？Windowsはたとえ邪悪でも、少なくともユーザーに基本的なハードウェア選択の自由を与える意思はある。何もかも一つの巨大企業にがっちり支配されているわけではない。

私たちがもっと研究すべきなのは、不自由なハードウェアへLinuxをインストールし、そのドライバーをリバースエンジニアリングして、ユーザーのコンピューターを解放することだ。macOSのような不自由なシステムをより多くのデバイスへ広めようとすることではない。

たとえmacOSがUnix-basedであっても、同じく推薦に値しない。1980年代のハッカー精神はとっくに失っている。

したがって、HackintoshやWindows on ARMを移植するより、Linux on everythingのほうが価値があるのではないか？Linuxを魔改造してAndroidのような囲い込み型システムにする悪質な会社は別として。

2011年、Apple社のスティーブ・ジョブズが亡くなったあと、各方面が次々に追悼文を発表した。しかし自由ソフトウェア財団の会長リチャード・ストールマンは、「死んでよかった」と評した。

彼が個人ブログで述べた原文はこうだ：

" Steve Jobs, the pioneer of the computer as a jail made cool, designed to sever fools from their freedom, has died. …… I’m not glad he’s dead, but I’m glad he’s gone. …Nobody deserves to have to die …… not even people guilty of bigger evils than theirs. But we all deserve the end of Jobs’ malign influence on people’s computing. "

粗訳：

「スティーブ・ジョブズ、愚かなユーザーのためにクールな監獄を作り、人々から自由を奪うことを専門にしたパーソナルコンピューターの先駆者は、死んだ。…..私は彼の死を喜んでいるわけではないが、彼が去ったことは嬉しい。……誰も死んで当然などということはない……たとえ彼が犯した悪事が何世代かけても償えないものであっても。しかし私たちは結局、ジョブズによるパーソナルコンピューターへの悪質な設計の影響を受け続けることになる。」

この言葉には多くの解釈がある。一つは、リチャード・ストールマンがApple社製品のもたらした影響を非常に不快に思っていた、というものだ。Apple社はプロプライエタリソフトウェアを推進し、それをMacハードウェアと抱き合わせ、大衆がコンピューター製品を選ぶ好みに影響を与えた。さらにApple製品は一部のBSDオープンソースプロジェクトの成果を借用しながら、システムを不自由なソフトウェアへ変えてしまった。これは「自由ソフトウェアの敵」と言える。Apple社はMicrosoftより善良なわけではないので、リチャード・ストールマンがこれほどAppleを嫌うのも不思議ではない。彼は自分の信念を最後まで貫く人物である。

いまジョブズが亡くなったあと、彼の影響力も消えた。

そして私たちは、さらに貪欲なティム・クックを目にした。

Apple社によるユーザーへの支配は、MicrosoftやGoogleと同じく、増えることはあっても減ることはない。美名はAppleエコシステムだが、実際にはユーザーをより深い檻へ閉じ込め、抜け出せなくしている。

もしあなた自身が相対的に自由なハードウェア（x86はARMより互換性が高い）を持っており、さらに自由なLinuxとBSDオペレーティングシステムを選べるなら、なぜ自分をmacOSの監獄へ閉じ込める必要があるのか？

SteamはLinuxゲーミングに貢献したが、それが自由ソフトウェアではないことによる脅威には警戒すべきだ

infoivonblog.nkfjt@aleeas.com (Ivon Huang) — Mon, 06 Apr 2026 07:00:00 +0800

Steam is a threat to FOSS and user freedom on Linux.

なぜ自由ソフトウェアを追求するユーザーが、クローズドソースのゲームプログラムを遊ぶのか？そしてこの種のエコシステムの悪事に加担するのか？

正直に言うと、私は今ではどんなゲーム機も軽く見ることができなくなった。ゲーム機も一種のコンピューターであり、ソフトウェアを必要とする。PlaystationやSwitchのようなゲーム機が、魔改造されたBSDシステム上で動いており、しかも不自由なシステムだと知ってから、その上でゲームを遊ぶことを受け入れられなくなった。ゲームソフトは往々にして特定プラットフォーム限定で、流通しにくい。だからこれは不自由であり、私はPC上でゲームを遊ぶほうを支持する。そしてゲームを販売するストアと言えば、最大手はSteamだ。Steamも一つのコンソールプラットフォームと見なせる。ゲームを売るだけでなく、ゲームランチャーでもあるからだ。

Steamは確かにLinuxでゲームを遊ぶことに貢献し、ProtonとSteam Deckによってゲームを遊ぶ苦痛を簡略化した。しかし実際には、閉鎖プラットフォームを広めている。これはGoogle Chromeがブラウザー市場を占有しようとする野心に劣らない。結局それはプロプライエタリソフトウェアであり、商業企業によって推進されているからだ。クロスプラットフォーム対応とは、商業的な触手を広げ、できるだけ多くの場所を覆うことであって、ユーザーへの配慮を第一に置いているわけではないのでは？

ゲームを遊ぶことは人心を腐敗させやすい。開発者が設定した心理学的な誘惑テクニックに従って、商業企業があなたを誘惑する罠へ落ちていく。わかっている！すべてのゲームがそうだというわけではない。しかしゲームが面白くあるためには、この種の仕組みで人を誘惑しなければならない。ゲームに心理学は重要なのだ！そうでなければ、ゲーム内のキャラクターが甘ったるくあなたを旦那様/奥様と呼ぶことにハマったりしない！

SteamがFlathubほどオープンソースな水準に到達していないなら、やはり警戒すべき対象である。現段階でValveが悪事を働いていないからといって、今後も悪事を働かないとは限らない。私たちはG胖の長寿を願うしかない。

より深い問題は、なぜ自由・オープンソースソフトウェアを好むユーザーが、ゲームに対してだけ大目に見ることができるのかということだ。ゲームもまたソフトウェアの一種ではないのか？ここでの討論は悪くないと思う：Why are people here so worried about proprietary programs, but games get a pass?

このような偽善的心態を描いたミーム画像もある。画像出典

ここで少し話を逸らしたい。一部の自由ソフトウェア開発者は口がかなり悪い。たとえばSwayの初期バージョンはNvidiaをサポートしていなかったが、その理由の一部はNvidiaのWaylandサポートが非常に悪く、workaroundが必要だったことにある。そのためNvidiaグラフィックカードでSwayを起動するときは、--my-next-gpu-wont-be-nvidiaというFLAGを付ける必要があった。現在Nvidiaのサポートが改善された後、このFLAGは--unsupported-gpuへ変更された。

さらに、SteamをFreeBSDへ移植した作者：shkhln/linuxulator-steam-utilsは、Steamがホームディレクトリに完全な読み取り権限を持つため、悪意あるプログラムがあなたのSSH鍵を盗む可能性があると考えている。そのためSteam専用のユーザーアカウントを作るべきだ。そうでなければ、「私は馬鹿です」という環境変数：DUMB_PERSON_FLAG = '--allow-stealing-my-passwords,-browser-history-and-ssh-keys' を付けなければSteamを起動できない。

え？Linuxコミュニティにはどうしてこういう懸念がないのか。UbuntuであれArch Linuxであれ、ユーザーは皆Steamをそのまま入れている。

オープンソース信者は一般にプロプライエタリソフトウェアに過敏で、MicrosoftとAdobeは悪者であり、私たちのオープンソースソフトウェアのほうが優れていると考える。ところがゲームを売るものに対してだけは大目に見る。G胖はchadであり、他のテック巨人のように悪事を働かないと考えるのだ。そのためSteam上でユーザーの権利を侵害するアンチチートシステムやDRMのような仕組みを、抵抗ではなく黙って受け入れている。

Steamは24時間あなたのプレイ時間を監視していることも忘れてはならない。考えるだけで恐ろしい。なぜGoogleの監視はだめで、Steamならよいのか？

Steam自身がゲームに必ずDRMや何らかのアンチチート機構を使えと言っていないとしても、あなたがこのプラットフォームを使うこと自体が、こうした仕組みを黙認する共犯なのだ！

今のメーカーがアンチチートのために、「あなたの安全性のため」と口々に言いながら、どれほど奇妙な操作をしているか考えてみてほしい。Windowsゲームメーカーがチート対策のためにkernel levelのアンチチートプログラムを実装しているのを見るだけで、ぞっとする。これらのソフトウェア自体がウイルスのようなものだ。DRMのクラッキング対策暗号化と同じくらい邪悪である。ValorantのVanguardは最も変態的なアンチチートプログラムだと聞く。仮想マシンもブロックし、QEMU/KVMでどれだけ隠しても役に立たず、さらにコンピューターでSecure Bootを有効にしないと遊べない！

私たちは、SteamOSがゲーム開発会社のアンチチート需要を解決するために、あのようなkernel levelのアンチチートをLinuxへ持ち込むのではないかと非常に心配している。そうなれば、ユーザーのすべてのプログラム権限をスキャンし、さらにはLinuxカーネルとkernel moduleが特定メーカーによるデジタル署名済みでなければ起動できないと要求し、ユーザーの自由を破壊することになる。そしてSteamOSは、Play Integrityの寵愛を受けるもう一つのAndroidになってしまう！

一歩譲って言えば、時には私たちはプロプライエタリソフトウェアを使わなければならない。まあいい、ゲームは娯楽項目であり、第九芸術である。ぎりぎり容認できる。もしゲームを動画や音楽と同じファイルとして見るなら、ファイルがH.265やWAVのような不自由な形式を使っているからといって、見ることを拒否するわけではないだろう？

しかし、もしかすると私たちLinuxユーザーは、Steamを単純なゲーム販売プラットフォームとして扱えばよいのかもしれない。Steamに過度に依存してゲームを遊ぶべきではないのでは？Steamクライアントはブラウザーのようなものとして扱い、ゲームをライブラリへダウンロードしたらSteamを閉じ、ずっと開きっぱなしにしない。Steamゲームファイルはローカルディスクに存在するのだから、ゲームは独立したWineランチャーで起動すべきだ。Wineで起動できず、Steamクライアントに縛られてDRMやその他の仕組みを検証しなければならないゲームは、一律に購入拒否する。これが正しいのではないか？

まあ…結局Steam以外のWineランチャー案はどれもひどい。Lutris、Heroic、Bottlesにはそれぞれ問題があり、Steamほど魅力的ではない。人々は便利さと快適さのために、自由とプライバシーを放棄しやすい。

XFCEは時代遅れだ。Unix哲学はGUI設計には向いていないかもしれない

infoivonblog.nkfjt@aleeas.com (Ivon Huang) — Mon, 06 Apr 2026 06:00:00 +0800

XFCEは良い。しかし時代遅れだ。

現在のバージョンは4.20だが、インターフェイスはほとんど20年前と同じままだ。

いわゆるUnix哲学は、システムプログラミングの層にだけ適用できるもので、OSカーネルの上にあるグラフィカル環境の指針としては向いていないのかもしれない。

暴論：XFCEは、他のデスクトップが正常に使えない時の控えでしかありえない。GPUアクセラレーションがない状況でもうまく動くからであって、そうでなければこのデスクトップはとっくに時代遅れだ。可能ならKDEかGNOMEデスクトップを使うべきだ。この二つ以外のデスクトップを勧めるユーザーについて、私はいつも、ユーザーをユーザーとして見ておらず、誰もがkernel hackerだと思い込んでいる開発者か、そうでなければboomer精神で年功序列を振りかざしているだけだと思っている。

反Systemdで、Linuxは「Unix哲学」を堅持すべきだと騒ぐ連中にFreeBSDシステムを使わせれば、彼らはすぐ黙る。なにせグラフィックカードドライバーでさえ問題が起きやすい環境では、ネットに繋いで文句を言うことすらできないからだ。では、この壁を越えられる人たちは？彼らは黙々とシステムを使うようになる。

シンプルさを追求するためにBSDシステムを使うとしても、デスクトップ環境がLinuxの影響を受けているという問題には向き合うことになる。

BSDがLinuxに勝る強みは、システムが完全な一つの全体として設計されており、システムソフトウェアとサードパーティソフトウェアがよく隔離されていることにある。FreeBSDのシステム設定ファイルとユーザー設定ファイルは分けて置かれ、一つは/etc、もう一つは/etc/usr/local/だ。そしてFreeBSDのinitは昔から今まで変わっていない。

こうした伝統的価値へのこだわりは、当然FreeBSDの主流デスクトップ選択にも影響している。2022年の投票：Preferred DE of the FreeBSD usersによると、主流デスクトップはKDE Plasma以外ではXFCEだ。GNOMEはここでは上位に入らない。

人によってはXFCEで十分楽しく使えるかもしれない。確かにそれほどLinuxの最新技術に依存していないため、Unix-likeシステム間で汎用的に使える。Linuxコミュニティにも、XFCEを好む人はまだ多い。

しかし昔の時代を経験していないユーザーにとって、XFCEは見た目が非常に醜く、時代遅れに映る。Mate、Cinnamon、LXDEも大して良くない。GNOME 40以降の設計は逆に急進的すぎて、モバイルデバイスに多く触れているzoomerだけが好みそうな感じがする。

こうしたデスクトップがどれも嫌なら、WMを使う？それはそもそもデスクトップとは呼べない。現代人が堕落したと言うつもりか、boomer？本当にWMを使い続けられる人などいない。ブラウザーでネットを見るだけだとしてもだ。デスクトップ機能があれこれ欠けていて、独立した小物ツールを山ほど入れて補う。最後には結局、車輪の再発明をするだけではないか？

唯一のX11デスクトップの大黒柱で、見た目がモダンでありながら伝統的なデスクトップの多機能性も維持するものとなれば、やはりKDE Plasma 6だ。BSDを入れるのはシンプルなシステムを追求するためではないのか、KDEのような大きなデスクトップ一式を入れるのは哲学に反するのでは、と疑問に思う人もいるかもしれない。私は、一部の人のKISSへの執着はすでに病的な段階に達していると思う。彼らはいつも現代のデスクトップを「肥大化している」と批判するが、現代のデスクトップはとっくにそんな単純な部品の集合ではなくなっている。良いユーザー体験を提供するために多くのサービスを走らせる必要があるのだ。さまざまなディスプレイパラメーターの変化に対応し、ユーザーに手動でxorg.confを書かせないようにするには、複雑さの増加は避けられない。それが嫌ならttyを使えばいい。

要するに、デスクトップのグラフィカル環境をどう設計すべきかを開発者の視点から見るべきではなく、もっと一般ユーザーに関心を向けるべきだ、ということだ。

ソフトウェアライセンスはBSDよりGPLを選ぶほうがよい：防御的民主主義を堅持し、オープンソースソフトウェアではなく自由ソフトウェアをもっと語れ

infoivonblog.nkfjt@aleeas.com (Ivon Huang) — Mon, 06 Apr 2026 05:00:00 +0800

GPLがBSDライセンスより優れている点は、それが一種の防御的民主主義であることだ。

積極的自由は消極的自由に勝る
#

防御的民主主義 (Wehrhafte Demokratie) の概念を借りれば、GPLは自由ソフトウェア運動を長く持続させる秘方である。

したがって、ソフトウェアを開発するなら自由精神を保つためにGPLを使うべきであり、Copyleftの自由精神を貫徹すべきだ。BSD、MIT、Apacheのような寛容(permissive)な条項ではない。著作権をPublic Domainへリリースするのとほぼ変わらないライセンス条項を使うくらいなら、いっそWTFPLを使ったほうがよほどすっきりする！

私たちはオープンソースソフトウェア(Open Source)ではなく、もっと自由ソフトウェア(Free Software)を語るべきだ。GPLはrestrict the freedomではなく、むしろprotect the freedomなのだ！

同じくオープンソースのOSであるにもかかわらず、BSDシステムがGNU/Linuxシステムに劣る点は、GPLの精神を持たないことにある。この道徳的な呼びかけを欠けば、コミュニティ全体の力は弱まり、純粋なボランティアになり、好き放題に奪われるシステムになる。

口汚く言えば、BSD Licenseは根本的に"Cuck License"、寝取られ条項だ。GPLライセンスは、俺の嫁をお前が抱くなら、お前の夫も俺に抱かせろ、というものだ。一方BSDライセンスは、お前が自分から嫁を他人に抱かせ、何の見返りもなくても構わないと思っているようなものだ！

Cuck Licenseの結果を描いた画像。大意としては、当初Minixを開発した教授が、善行の態度でBSDライセンスによりリリースしたところ、Intelに持っていかれ、Intel MEというCPU低層レベルの大規模監視ソフトウェアを作るために使われるとは思わなかった、というもの。

來自Luke Smith的網站

ハッカーコミュニティだけでは、大企業資本に対抗する十分に強力な武器にはならない。ソフトウェアの自由を守るには、自由ソフトウェア運動の指導も必要だ。GPLはBSDライセンス条項と比べ、ソフトウェアの将来の良性的発展を保証できる。つまりソフトウェアがソースコードを開放した後、同等の還元を出す必要があり、ソフトウェアが簡単に独占されないようにする。GPL自体は既存のビジネスモデルに友好的ではなく、しかも「自由ソフトウェア」という名義も「オープンソースソフトウェア」という名号ほどビジネスに友好的ではない。

これは一つの高リスクな賭けに基づいている：最初の一社がこの規則へ投資する意思を持ち、精神面でもGPLの精神に共感して初めて成功し、完全なエコシステムを発展させる可能性がある。現在見る限り、当時のLinuxの大勝負は成功した。Linuxの発展を本当に支援する企業が現れたからだ。典型的な例はRedHatである。

現在、多くの企業が技術的にGPLを回避し、Linux Kernelの成果を盗む、または寄生して自社のクローズドソース製品を開発しようとしているが、GPLがもたらした影響は依然として大きく、Linuxの中心が永遠に自由でオープンソースであることを確保している。

GNUとLinuxの関係はもっと密接であるべきだ。それこそ自由なOSである。だが現在直面している問題は、一部のプロジェクトがLinuxの開発成果だけを奪い取り、それをクローズドソース製品に使い、表面的にオープンソースのふりをして人々の信頼を騙し取っていることだ。

誰能想到這張圖的原圖是Richard Stallman在TED Talks的演講

ただ、LinusがRMSの意見を採用せず、Linux KernelをGPLv2からGPLv3へアップグレードしなかったのは少し惜しい。Linusは実用主義者に属し、確保しているのは消極的自由であり、オープンソースへの還元というやり方だけを強調する。しかし大企業が抜け穴を掘ってそれをクローズドソース製品へ変えることを防ぐ条項を入れようとはしない。理由の一部は、Linuxがすでに成熟し、世界的な商業プロジェクトとなり、関わる利益が多すぎるため、変えないほうがよいのだろう。

しかし、「一時の安全と引き換えに基本的自由を犠牲にする者は、最後には安全も自由も得られない。」

Arch LinuxとSteamOSの異同について簡単に述べる

infoivonblog.nkfjt@aleeas.com (Ivon Huang) — Thu, 02 Apr 2026 02:00:00 +0800

SteamOSとArch Linuxの関係についての迷信は、少し正しておく必要がある。この二つはイコールではないし、SteamOSを使っているからといって"I use Arch btw"と言えるわけではない。

最近Arch LinuxでGalgameを遊んでいたら、ほぼ同じテスト条件なのに、SteamゲームのProtonがわけのわからないクラッシュを連発して、もううんざりした。Debianに戻したら全部問題なくなったので、この問題について話してみる。

愚見ながら、Arch Linux & CachyOSのようなローリングリリースはゲーム用途には向いていない。半ローリングリリースのFedora ＆ Bazziteもだめで、百戦錬磨のDebian StableかUbuntu LTSでないと信頼できない。昔の自分がよくArch Linuxでゲームする気になったものだと思うが、今はもうDebianを使っている。

もう一つ考慮すべき点は、ProtonDBへゲーム互換性を報告するとき、追跡可能で安定したシステムバージョンを使いたいということだ。テストプラットフォームは安定しているべきで、常に変化し続けるシステムであるべきではない。

SteamOS公式サイトの資料によれば、SteamOS 3.0以降が実際にArch Linuxをベースに開発されているのは確かだ。しかし、SteamOSはimmutableなシステムであり、ユーザーはシステムファイルを変更できないし、変更すべきでもない。システムのOTA更新のたびに新しいimageをダウンロードして旧版を上書きする。それにSteamOSはローリングリリースではなく、システム更新のスケジュールはValveという商業企業が決めるものであって、Arch Linuxのローリング更新ではない。

Valveには自社のSteam Deck & Steam Machineの製品体験を守る必要があり、参照可能なコンソールプラットフォームになることを目指しているので、更新をあまり急進的にすることはできない。たとえば2026年の安定版SteamOS 3.7.8では、デスクトップモードのKDEデスクトップはまだ5.27系だが、Arch LinuxのKDE 6.0はすでに2024年にリリースされている。SteamOS 3.8.0のKDE 6はいまもベータ版のままだ。現在のSteamOSのメイン画面コンポジタ、Gamescopeの戦略は、XWaylandでX11ゲームを動かしつつ、WaylandのHDRサポートも享受するという継ぎ接ぎの戦略によって成り立っている。将来的に純Waylandへ進めるかどうかには、大きな疑問符が付く。

Valveは「システム全体」としてのSteamOSとSteamクライアントが安定していることを確認してからでなければ、更新をリリースできない。

一方、Arch Wikiによれば、Arch Linuxのソフトウェア更新スケジュールは固定されていない。各ソフトウェアにはそれぞれ異なるメンテナーがいて、オープンソースコミュニティが安定したと判断すればリリースされる。全民公募テストでbugを拾うようなもので、テスト期間は十分に長くない。

このやり方の利点は、問題があればすぐ発見して修正できることだ。欠点は、現在のシステムが完全に安定しているかどうかを誰も保証できないことだ。変数が多すぎる。

Arch Linuxはインストール直後の状態ではそもそもグラフィカルインターフェースがない。いわゆる「デフォルト値」は存在せず、一つの「全体」もないので、全面的にテストしてから更新をリリースすることは難しい。小さなパッケージ更新一つでKDEデスクトップが吹き飛ぶ可能性もある。

Arch LinuxにおけるSteamクライアントは、オープンソースコミュニティがValveのリリースしたインストールパッケージをもとに改変したものだ。Steamクライアント本体にはProtonの実行を満たすための独自Runtimeがあり、できるだけOSのlibraryへ依存しないようにしているとはいえ、Arch LinuxシステムのコンポーネントはやはりSteamクライアントに影響する。ランダムに問題が出るのだ。

リリースモデルから見ると、SteamOSは数あるローリングLinuxディストリビューションよりもずっと安定している。SteamOSに近い体験を持ちながら、なおかつ安定しているローリングリリースを実現するのはかなり難しい。

現時点のSteamOSはまだ特定の数機種のハードウェアにしか対応していない。もし将来、本当にオープンソースの汎用x86イメージファイルをリリースしたら、彼らのGithub issue ticketは爆発的に増えるのではないか……。

Linux操作入門の工具書《電腦上試跑 LINUX：硬體測試筆記》短評

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

Linuxを知りたい初心者に勧められる中国語の本で、しかも全部がサーバー運用保守の知識ではないものはないだろうか？

最近、軟體自由協會の会員会議に参加し、趙惟倫会員の著書《電腦上試跑 LINUX：硬體測試筆記》を知ったので、ダウンロードして読んでみた。なかなか良い出来だとわかった。

趙惟倫（bluebat、FSF会員）著、軟體自由協會SLAT出版の《電腦上試跑 LINUX：硬體測試筆記》という工具書は、非常に詳細なLinux参考書であり、少しのコンピューター概論と現代Linuxシステムの操作知識を融合している。読者がLinuxの実行過程を理解する助けになる。

この本のテーマはLinuxカーネルの動作原理を語ることではなく、実務上Linuxを操作する時に遭遇する問題を分析し、システムサービスのデバッグ方法を理解することにある。《鳥哥的Linux 私房菜》と比べると、本書は実際にハードウェアへ触れる時に遭遇する状況をより多く扱っている。

書中では最新版Fedora 43を例として解説し、Linuxの起動フロー、グラフィカルシステム、音声システム、ネットワーク接続、電源管理などの動作原理を説明している。原理を簡単に紹介した後、実際のコマンド操作を補い、Systemdを主要なシステム管理手段として使う。日常的にLinux自由ソフトウェアを使うことに興味のあるユーザーは、この本を実用的な工具書として参照し、システムに問題が出た時にどのコマンドがデバッグを助けるのかを理解できる。

ただし作者の解説はなおコマンド操作を中心としている。FreeDesktop XDG標準には触れているものの、Linuxデスクトップ環境GNOMEやKDE PlasmaのGUI操作への言及は少なく、かなり惜しい点である。また大部分はX11環境の操作について語っており、未来の趨勢であるWayland技術にはあまり触れていない。

Linuxで市場シェアが最も高いデスクトップ環境はGNOMEだ。GNOMEデスクトップは各バージョン更新でランダムにUI位置を動かしてユーザーをいじめがちだが、GNOME 40以降のデスクトップワークフローはすでに「定型」になったと思う。GNOMEの特色を少し解説してもよいはずで、Linuxシステムのバージョン更新によって大きな差が生じることはないだろう。

この本には紙本と電子版があり、全文はGitHubで取得できる。書籍ライセンスはCC BY-SAである。

ソースコード：https://github.com/cc-books/testnotes

実体書の購入：電腦上試跑Linux: 硬體測試筆記 - 天瓏網路書店