最近界隈を賑わしているAUR問題
6/11頃から、公式ニュースなどで言われるようになってますが、AUR(Arch User Repository)に、悪意あるパッケージの採用と更新が多数発生していると発表しました。
そういうのはUbuntu界隈でやれよと思うわけですが、これらはすぐにコミュニティメンバーなどの協力もあり即座に発見されパッケージに含まれている悪意あるスクリプトにマーカーして850個以上発見したと言います。
現在、Arch LinuxチームはAURのクリーンアップ作業のため、新規AURアカウント登録を一時停止したと流れになっています。
これらはArch Linuxだけではなく、その派生ディストリビューションにも影響があるわけですが、基本的にはユーザー側は何もせずともparuやyayでアップデートが行われないようになっているかと思うので特別問題では無いと思います。
そもそもAURはあんまり使わず、公式パッケージしか入れていないという人にはおそらく影響はないだろうとも思います。
公式パッケージとAURの違い
公式パッケージは公式な段階を経て配布されるものであり、必ず安全かは何ともいえませんがほぼ問題ないと考えられる一方、AURはそういったチェックがなく個人が配布する場であるので、悪意あるコードが挿入されることは無きにしもあらずなわけです。
なのでユニバーサルパッケージシステムのFlatpakなどがあるわけです。
AURとFlatpakはどう違うか？
パッと見てFlatpakのインストールする時などにGithub等と文字が見えますので、単にアプリ作者がGithubに置いてあるものをFlatpakにバイナリを登録してるだけなんじゃないか？と思いがちです。
AURはそういう側面がありますが、FlatpakはFlathub運営が「変な外部スクリプトをダウンロードしてRoot権限を奪ってしまう」等がないように、セキュリティー面をチェックして、人間がソースコードとパーミッション(権限)などをチェックする審査があります。
Flatpakはクローズドな専用サーバーでビルドが行われており、ユーザーのPCでビルドをするわけではないので、多くのビルド中に悪意あるスクリプトを混入させるということが困難になっています。
もちろんこれらは100%安全だとはいえませんが、「個人の善意と目視チェック(コミットログの確認)に依存するAUR」に比べると、「システム(構造)として悪意ある挙動をさせない仕組みになっているFlatpak」の方が、普段使いにおける安全性は圧倒的に高いと言えます。
こういった事から、AURのビルドしたものの方が諸々の作用でファイルサイズが小さくなるものの、サイズが大きくなったとしてもFlatpakが利用されている理由の一つになっています。
FedoraのAtomicなディストリビューションとFlatpak
Fedoraに限らずではありますが、FedoraのAtomicなディストロではシステムコアが不変(Immutable / Read-only)であり、ユーザーがシステムを変更したりができません。そのためFlatpakと相性が良くシステムとFlatpakの二重の防御があるとも考えられます。usr/であったりにファイルを直接書き込んでいきますが、権限などがあるとはいえ危険ではありますよね？
またOSのアップデートが100%失敗しないというのもLinuxを使い始めたばかりのユーザーには安心感も感じられるはずです。
OSのアップデートが100%失敗しないとは？
FedoraのAtomic版のディストリビューションは、OSのシステムごとアップデートする仕組みです。またアップデートする以前のバージョンを保持しており、アップデートに失敗したら前のバージョンに切り替わり変わらず作業ができ、アップデートに成功したら丸ごと書き換えて最新にすると言う仕組みのため、半壊れ状態が起きません。 またOS全体を書き換えると言っても差分も上手に管理しており、従来のディストロ更新と大差はありません。ただ以前のバージョンを保持することからその分だけストレージ容量は必要になりますが、倍必要だとかそういうこともありません。 ただし、システムにアクセスできないサンドボックス上で動作するアプリを使用するということはファミコンなどと同じでソフトにあることしかできなくなります。これが制限があるという点です。自由度を低めるが大事な部分は保護すると言う方針です
アプリではどういう事があったか
Rust製で超高速なエディタ「Zed」のLinux版が1.0を迎え、本格的に普及しています。VS Codeのように重くならず、起動も動作も一瞬です。
Zedはどうしてアーキテクチャが異なるPCで動作するのか？
ZedはMacOSがメインで作られ、Linuxはほぼ同様に動きますがこれはどうやってるのでしょうか？
- MacOSの場合は、Apple独自のグラフィックAPIであるMetalを叩いています
- Linuxの場合は、標準的なAPIであるVulkan、あるいはより普及しているBlade(WebGPUベースの抽象レイヤー)を経由してGPUを駆動させています。
エディタの「コードを表示する」「ミニマップを表示する」という共通コードはそのままに、最後の画面に出力する部分だけを「Metal」から「Vulkan/Blade」に差し替えているわけです。
マウスやキーボードからの入力部分もOS固有の処理が必要になります。ZedはここもRustの条件付きコンパイルを使用してOS毎にコードを書き分けています。
30年も前のWin32 APIとかを1からいじるという魔境への挑戦があったのです。
Windowsユーザーをこじらした人がLinuxのUIはクソダサいし使いにくいと声高々に言いますが、化けの皮を剥がせばWindowsアプリというのは中身はWin32 APIで動いていたりするのです。
しかしWindowsは64bit OSだと言うじゃないかと思われる人もいると思います。これは簡単に言うと64bitも扱えるOSであると言うだけのことなんです。
なぜWindowsは名実ともに64bitにできないのか？
Windowsも今や64bit OSですが、そのアプリを動かすための根底にある仕組み(関数など)は、30年以上前の設計である「Win32 API」をベースにデータサイズを拡張して動かしているに過ぎません。名実ともに完全に近代化された64bit OSに刷新できないのは、古臭いシステムで動いている企業などの莫大な過去の資産(互換性)を切り捨てるわけにはいかないという、Microsoftのビジネスモデルが生んだジレンマがあるからです。
昭和に建てられた平屋の日本家屋に、最新のデジタル家電をこれでもかと導入して「最高のスマートホームです」と言い張っているのが現在のWindowsの構造です。ZedチームがWindows対応に数年という長い開発期間を要したのは、この30年分の歪みが蓄積した「Win32 API」という魔境に、Rustという最新の武器で1から挑まなければならなかったからだと言えます。
なぜそれほどまでしてWindowsに対応させる必要があったか
それはいくら古臭いシステムでも、デスクトップシェア7割を誇るWindowsを捨てるわけには行かなかった、そしてMacOSやLinuxと同等に動いてこそ、その価値があると言う理由に他ならないと思います。
ZedチームはElectron(Atomエディタ)というVS Codeの土台を作った人たちです。ElectronでWeb技術を用いて1つのコードでどのOSでも動くという手法を世界で初めて作った人たちです。
Zedはどういう使い方をされるか
Zedを使う人はプロからアマチュア、そして(アマチュア以下の)一般的人まで様々です。
- ディストリビューションに付属しているテキストエディターでは思うように作業できない
- VS codeでやらなければならないほどのことはしていない
だいたい普通の人はこれらの中間ぐらいの位置で、htmlを追加したり、それにCSSを当てたり、あわせてJavaScriptも追加すると言うぐらいの用途がせいぜいで多くの拡張機能も不要であり、思った時にサッと使える手軽さの方が重要です。
ディストリビューションに付いてくるようなテキストエディターはいわゆるノートパッドのような、メモ書きであったりちょっとコピーしたものを置いておくぐらいの使い方がほとんどで、それらでコードを書いているという人もいるのでしょうが、もう少し便利に、かつ同じように素早く起動することが大切な場合が多いと思うのです。
Windowsのパス問題
世の中のほとんどのプログラムなどではパスと言えば/(スラッシュ)で区切ります。ブラウザのパスでも、ローカルのファイルのパスでもだいたい/ですよね？\(バックスラッシュもしくは￥)で区切るのです。そんな事大した問題じゃないだろ？と思いがちですがこれは大した問題です。
# skipCopy
# URL
https://www.any.com/some/
# Linux
/home/[YourName]/.config/
# Windows
C:\Users\[YourName]\some\any\パス区切りを吸収する仕組みがアプリやシステムにあるのであれば、その部分では間違わないと思いますが、だいたいそういうパスを扱うような作業をする場合のアプリ等はWindows以外で作られていることも多く、だいたいが/だということで違いを吸収する仕組みを持たないnpmなどのパッケージもあります。\を/変換する設定(だいたいはreplace・置換)を書かないといけなかったりするのに気が付かず、ファイルが見つからないなどでどこにエラーがあるのかでしばらく悩むということが多々あります。
「自分はGUIを使用しているので関係ない」、「リンクは書いてあるのをクリック/タップして飛ぶから関係ない」と思うでしょう。
Windowsのコマンドとその他で利用できるコマンドも違います。なのでLinuxやMacOSでZedを使用する場合は何も考えずノーマルな使い方もできますが、Windowsで使用する場合は余計な一手間が必要なのも確かです。
かくいう私はWindowsでも使用してますけども。
「Steam Deck効果」の定着：PCゲームがほぼ動く
Steam Deckから始まったLinuxゲーミングの波は、2026年現在もさらに加速しています。
Proton(互換レイヤー)の成熟
Windows用に作られたゲームをLinuxで動かす「Proton」の精度が極限まで高まり、Steam上の大作ゲームのほとんどがインストールボタンを押すだけで、Windowsと同等(場合によってはそれ以上)のパフォーマンスで動くようになっています。
これにあわせて、アンチチート問題の緩和が進んでいます。これまでLinuxユーザーを苦しめていた「オンラインゲームの不正防止ソフト(アンチチート)のせいで起動できない」という問題も、開発元がLinux(Proton)への対応を標準化するケースが大幅に増えました。
以前書きましたが、ゲームというのはOSや他のアプリが動いた余力で動作しています。Windowsというのはその余力を作るために過剰な高級パーツを用意したりしても尚、まだ足りないというテレメトリーや無駄な動作が多すぎて、例えばゲームしている時はそれら停止すると言う術もありません。
Windows12の噂もチラホラとあり、わざわざ中古で12世代を選ぶよりもより新しいPCを求める方が無難ですが、それがWindows12にとって最適であるかもわかりません。
- Windowsでゲームが動くのであればWindowsにしたらいい
- 安い中古でWindows11を買えば良い
というのは言えない時期なのです。ではゲームができるからと安易にLinuxに移行すると言う人が増えると、何かトラブルがあった時に対処できず、その結果、
- linuxはクソだ
- やりたいものが動かない
という事になるでしょう。
Protonもだいぶ良くなったのは確かです。では、日本語はどうだと言うとSteamなどで配信されている日本語対応ゲーム(モンハン、バイオ、龍が如く、FFなど)であれば基本的にはインストールボタンを押すだけ日本語でプレイも可能になっています。
しかし日本語特有の壁というのがあって、
- 文字化け
- 日本語入力
- ムービー
この3つが壁になります。単にProtonが入ってるからと言ってそれらがクリアできるというわけではなく、最適なフォントを入れて設定しておけば文字化けは解消できるでしょうが、日本語入力はLinux側(Fcitx、ibus)とProtonの間で通信がうまく行かない事から「ひらがな・漢字」が入力できず、ローマ字のみになってしまう問題はあります。
ムービーに関しては日本のゲーム会社（特に和ゲーやビジュアルノベル）に多い問題ですが、Windows専用の特殊な形式の動画が使用されている場合はそこでストップしてしまう場合もあります。
まずはSteamのゲームプロパティから起動オプションに、以下の設定をします。
LANG=ja_JP.UTF-8 %command%ProtonDBで世界中のゲーマーがどれぐらい動作するのかを報告しているので、タイトル検索をしてどういうステータスが付いているかで、どこまで動作するかは判断できます。
Steamなどゲームの世界から一般向けディストロへの期待
コンシューマー機であれば、後から特別設定しないでも(言語の選択などは必要でも)、基本的には対応しているどんなゲームでもチャットは可能でしょうし、文字化けもないのではないかと思います。
Linuxは元々英語で作られていたりするので、日本語の対応は遅れがちでもあり別途設定しないといけません。ゲームに期待することはもっと簡単に日本語が扱えるような規格を作ってほしいということです。
そういう方向になっていけば今よりももっとLinux自体の敷居も下がると思うのです。
大きい部分でWaylandへの移行が終わった
GnomeにしろPlasmaにしろWaylandへ移行と開発キットの世代交代が終わり、判明していた大きなバグもとれつつありほとんどのユーザーにとってはトラブルがほぼ無くなりました。
Waylandだと動かないアプリがあるからX11に戻すというような妥協がほぼ不要になり、NVIDIA製グラフィックボードとの相性問題もほぼ過去のものになっています。これはつまり、ゲームや動画視聴時の画面の引き裂け(ティアリング)が標準で発生しなくなったということになります。
yserver
Waylandに移行が完了した所と言う話ですが、一方ではyserverというRustでゼロから書き直された、モダンな新世代X11サーバーが登場しています。
従来のX11(X.Org)は、30年以上前の古い設計や、今では誰も使わない機能(モノクロ画面のサポートや骨董品レベルの拡張機能など)が山のように積み重なり、コードが巨大な「スパゲッティ状態」になっていました。これが原因で、誰もメンテナンスできなくなっていたのがX11の最大の弱点です。
Rustでゼロから書かれたことで、古いX11にあったセキュリティ脆弱性やクラッシュのリスクを構造的に排除しています。また今どきらしく開発者がAIエディタを駆使して驚異的なスピードで組み上げたことでも話題になりました。
Waylandが標準になったとはいえ、「どうしてもX11じゃないと困る・X11の方が快適」というユーザーやデスクトップ環境が一定数残されているのも事実です。
Compizなどをそのまま現代の安全な環境で動かしたいという層にも刺さってはいるのですが、yserverが普段からLinuxを使用する人にとって今すぐ有益なものになるかと言うと、まだその段階だとは言えないのが現状です。
なので、凄いのができたらから今すぐこの環境に変えようという性質のものではなく、ブラウザがChrome主体になってもFirefoxがあるように、Waylandがどうしても使いづらいとか、あるいはXfceを愛用したいという人にも今後も使えるような希望、あるいは受け皿ができたと言う意味合いのもので、ユーザーからすると選択肢がありそれぞれがより良くしようという構造自体が結果的に技術の発展にも繋がって恩恵があると言えるわけです。
まとめ
しばらくびっくりするようなニュースは出てこないんじゃないかなとは思っています。
確認したら来てました。色々変わっているようですが、説明だけで結構な量になるので動画などを参考までに。