← 2026-02-01 の一覧へ戻るホーム
**Guix System：Nixユーザーにとっての第一印象**

2026/01/31 20:22

**Guix System：Nixユーザーにとっての第一印象**

RSS: https://news.ycombinator.com/rss

元のHacker News記事へ ↗
要約▶

Japanese Translation:

改訂版まとめ

著者は Arch、Gentoo、Fedora、および NixOS を試した結果、ディレクトリごとの環境と宣言的設定が自分のワークフローに最も合致しているため Guix System に移行しました。Guix は Nix 言語ではなく Scheme（Guile）を使用しており、著者はパッケージ定義がより扱いやすいと感じています。

インストールは簡単です。

dd
で書き込んだ USB イメージからクリーンにブートでき、インストーラの TUI から KDE Plasma を有効化できます。最初のダウンロードはミラー制限（≈50 kbps）により遅く (~2.5 h) なりましたが、その後正しいチャンネルを有効にすると更新速度が速くなります。

インストール後、デフォルトのディスプレイマネージャは GDM でした。SDDM に切り替えると Plasma UI のタイトルバーや境界線が欠けていた問題が解消されました。NVIDIA RTX 5070 ドライバを使用するにはプロプライエタリドライバ用に Nonguix チャンネルを有効化する必要があります。

nomodeset
や NVIDIA の変換オプションで試みた最初の試行はカーネルパニックと FSCK ログを引き起こしました。著者は最終的に Nonguix からフルカーネル＋ファームウェアブロブのみを追加し、
guix pull
→ 
guix system reconfigure /etc/config.scm
を実行して再構成し、再起動することでドライバの問題なく成功しました。

著者は LibreWolf、Icedove、LibreOffice、開発ツール、Emacs、Discord（ウェブ版）、Steam など主要アプリケーションをインストールし、Steam は Nonguix 経由で動作し、Discord はウェブ経由でアクセスできると報告しました。Guix の組み込みホーム設定、Scheme ベースのパッケージ定義、およびコミュニティサポートを称賛する一方、代替サーバーが遅いこと、コマンド構造が不明瞭であること、検索機能が限定的であることなどの欠点も指摘しました。

総合すると経験は肯定的です。著者はたまにダウンロード速度が遅く、ブート時に 

nomodeset
が必要だったものの、日常的に Guix System を使用する予定です。

本文

目次

  1. 私のGuix Systemへの旅
  2. インストーラ印象
  3. 迷子になっているとき
  4. 悪魔への同情
  5. 目的
  6. 結果

  6.1 良かった点
  6.2 曖昧な点
  6.3 悪かった点

  1. 全体評価
  2. 備考

1. 私のGuix Systemへの旅

バックストーリーに興味がないならこの章は飛ばしても構いません。主題に入る前に、宣言型ディストリビューションに興味を持ち始めた経緯を簡単に振り返ると整理しやすくなると思ったからです。

私は約10年間Linux専用ユーザーで、ほかの多くの人と同じようにディストリ変更の厳しい旅路を歩んできました。Mintから始め、速度が遅いと感じたらUbuntuへ移行、その後「手引きが必要」と思ったのでArchへ、さらに「より難しい方が良い」という欲求でGentooへ。数か月で燃え尽きてFedoraに諦めました。Fedoraは非常に安定し、総合的に優れたシステムでした。再び興味を抱き、今日の冒険前にはついにNixOSへ移行しました。

Nixについて最初に耳にしたときから少しずつ関心が湧いていましたが、最近まで「DevOps向けツール」としてしか見なかったので、構文は奇妙で再現性のある環境が必要だという点も無意味に感じていたため、初心者にはおすすめされないNix Pillsなどに抵抗を覚えていました。

では、私のように「結局はNixを使わないといけない」と決めた理由は何でしょうか？最初はNixがより優れているというよりも、他の選択肢が悪くてそれだけで十分だったのでしょう。

転換点となった大きな二つの理由は次の通りです。

  • ディレクトリ単位の環境 – 複数の技術を試す際にプロジェクトごとに専用環境があると便利です。私のブログはJekyllで、良いRuby環境が無ければ
    bundler install
    が面倒でsudoが必要でした。Nixでは
    shell.nix
    に数個のパッケージを記述するだけで、1フォルダにRubyだけをインストールできました。
  • インストール済みパッケージの管理 – 多くのマネージャーはパッケージリストが制御不能になりやすいです。NixOSではシステムは編集したファイルで定義され、バージョン管理可能で明示的かつ集中化されています。

NixOS以外にも宣言型ディストリがあります。GNUは早期にNixをフォークし、自らのスキーム（Guile Scheme）であるGuixという派生版を作りました。Guixの大きな特徴は、煩雑なNix言語の代わりにSchemeを使う点です。私は一度Guixを試しましたが、KDEのサポートがほとんどなくハードウェア問題もあってまだ準備不足でした。

3年後、Guixは1.5.0リリースで多くの安定化と初めて本格的にKDEを公式対応にしました。今こそ再挑戦する最適なタイミングです。本稿ではインストールから最初の3〜4日間までの体験を書き綴ります。

2. インストーラ印象

USBに挿し、

dd
でイメージを書き込み、再起動。Linuxシステムを一度でも導入したことがあれば、同じ流れです。

BIOSでペンディングを選択するとモニタは深い青色に輝き、Guix Systemのロゴが表示されます…その後赤く変わります。「CPU統合GPUはフリーソフトウェアのファームウェアに対応していません」。ヘルプポップアップが次回はフリーなハードウェアを選ぶよう促します。インストーラ本体へ移行しました。

インストーラ自体はとてもシンプルです – 古典的なncurses TUIで必要事項を尋ね、基本設定ファイルを提供します。前回のGuix試行とは異なり、KDE Plasmaが公式オプションとして選べます。GNOMEや他のオプションに興味が湧かなかったので、私はそれを選択しました。

インストールボタンを押すとPCは次の2½時間使用不可になります – 現在では許容できません。光ファイバー（最大1 Gbps）でもパッケージのダウンロード速度は約50 kB/sで、5〜10 MBのパッケージが数分かかります。

再起動後も問題は悪化しました。

3. 迷子になっているとき

KDE Plasmaを選択したためにSDDMが表示されるはずでしたが、代わりにGDMがロードされました（デフォルト設定）。ログインすると慣れたPlasmaのスピナーが表示されますが、やや遅いです。

ほとんどパッケージがインストールされていない状態でKonsoleを起動しました。タイトルバーも枠線もなく左上隅に固定されたまま移動できませんでしたし、メニュー項目もありません。苛立ちからまずは更新を試みました。

guix pull…
は高速でダウンロードできますが、インデックス作成に10〜12分かかります。その後 
guix system reconfigure /etc/config.scm
を実行すると速度が向上（30–50 Mbps）しました。再起動してもPlasmaはまだ不安定です。

GPUドライバの問題を疑い、LXQtデスクトップに切り替えて再起動しました – これで正常に動作し、EmacsとLibreWolfが使えました。

#guix IRCで助けを求めると、Rutherther が 

nomodeset
を提案しました。あまり効果はありませんでした。

4. 悪魔への同情

純粋なGuix Systemに固執している間、私は Nonguix（非フリーチャンネル）を検討しました。Guix の調査によると、約64 %のユーザーが Nonguix を有効化しています – FOSS ではまだ置き換えられない非フリーパッケージやドライバを提供します。

有効化するには 

~/.config/guix/channels.scm
と 
/etc/guix/channels.scm
に次のコードを追加し、再度 
guix pull
を実行します：

(cons* (channel
        (name 'nonguix)
        (url "https://gitlab.com/nonguix/nonguix")
        (introduction
         (make-channel-introduction
          "897c1a470da759236cc11798f4e0a5f7d4d59fbc"
          (openpgp-fingerprint
           "2A39 3FFF 68F4 EF7A 3D29 12AF 6F51 20A0 22FB B2D5"))))
      %default-channels)

再度プルとリコンフィグ後、NVIDIA ドライバを「NVIDIA transform」（自動的にプロプライエタリドライバを使用）でインストールしようとしましたが、カーネルパニックと大量の FSCK ログが発生しました。

代わりに Nonguix の事前構築ISOからシステムをビルドしたところ動作しましたが、以下の問題がありました： 2022年にビルドされたもの（GNU Savannah ミラーは遅い）、手動でチャンネルオーバーライドが必要、生成される 

channels.scm
に Nonguix が含まれていない。調整と再構成後、i3 で最終的に起動できました。

5. 目的

私は NixOS と同等のワークフローを望んでいました：

  • ブラウザ – Firefox（LibreWolf 推奨）
  • メールクライアント – Thunderbird（または Icedove）
  • オフィススイート – LibreOffice
  • 開発環境 – Rust, Zig, Scheme, TypeScript
  • Emacs – Vterm サポート付き
  • Discord – ブラウザ版か Flatpak
  • Telegram – デスクトップクライアント
  • Steam – 非フリードライバ対応
  • NVIDIA ドライバ – CPU 統合GPUにオフロード

Steam とプロプライエタリNVIDIAドライバは「難しい」（非フリー）でした。Discord は「不可能」(Nonguix でもパッケージ化されていない)と感じました。

6. 結果

図 6： 私がパッケージした Wezterm と Emacs を実行中のデスクトップ。

項目成果
ブラウザLibreWolf – Firefox より軽快。
メールIcedove が期待通り動作。
オフィスLibreOffice 利用可能；最先端ではないが十分。
開発環境
manifest.scm
に 
(specifications->manifest …)
を記述すればセットアップが簡単。
Emacs動作し、
emacs-vterm
が必要。
Discordブラウザ版で十分；Flatpak も可能。
SteamNonguix 経由でインストールし、プロプライエタリドライバで動作。
NVIDIA ドライバオープンドライバとカーネルモード設定を有効化して機能。

6.1 良かった点

  • コミュニティ – Libera の #guix、Reddit、Codeberg にて親切でサポートが充実。
  • ホーム構成 – 組み込みでファーストクラス、サードパーティ拡張は不要。
  • パッケージの可用性 – FOSS パッケージでほぼ必要を満たし、Nix の設定に相当するものが存在。
  • Scheme – Nix 言語より理解しやすく、Emacs でデバッグも可能。
  • ハックの容易さ – リポジトリクローン→コミット認証→バイトコードビルドまで約15分。

6.2 曖昧な点

  • 検索 – 
    guix search
    は便利だが、Nix のように追加パラメータを持たない。
  • ドキュメント – 詳細はあるものの散在し、章ごとに概念が分かれやすい。

6.3 悪かった点

  • サブスティテートサーバーの安定性 – 速度が遅く（50–100 kB/s）、ビルドを遅延させる。
  • コンテンツ可用性 – Nix に比べ高品質ガイドが見つけにくい。
  • ビルド速度 – 
    guix pull
    は Nix の 
    nix flake update
    より遅い。
  • コマンドの明確さ – 多くのコマンドが一括で扱われ、初心者は圧倒される可能性。

7. 全体評価

現在のシンプルな Guix ホーム構成例

(define-module (guix-home-config)
 #:use-module (nongnu packages)
 #:use-module (gnu packages)
 #:use-module (gnu home)
 #:use-module (gnu home services)
 #:use-module (gnu home services shells)
 #:use-module (gnu services)
 #:use-module (gnu system shadow)
 #:use-module (guix gexp))

(define %packages
  (list "git" "openssh" "librewolf" "ripgrep"
        "bat" "eza" "fd" "zoxide" "bc" "gimp"
        "libreoffice" "jujutsu" "starship" "direnv"
        "okular" "gwenview" "bitwarden-desktop"
        "icedove-wayland" "telegram-desktop"
        "emacs-vterm" "ispell" "hunspell" "wezterm"))

(define %nonfree-packages
  (list "steam-nvidia" "mpv-nvidia"))

(define home-config
  (home-environment
   (packages (specifications->packages (append %nonfree-packages %packages)))
   (services
    (append
     (list
      (service home-bash-service-type
               (home-bash-configuration
                (aliases '(("ls" . "eza")))
                (bashrc (list (local-file "./bashrc.sh")))))

      (service home-files-service-type
               `((".guile" ,%default-dotguile)
                 (".Xdefaults" ,%default-xdefaults)))

      (service home-xdg-configuration-files-service-type
               `(("gdb/gdbinit" ,%default-gdbinit)
                 ("nano/nanorc" ,%default-nanorc)))))

     %base-home-services))))

home-config

Guix System に対しては非常に好意的です。数年前に苦戦したことを考えると、今回の体験では短時間で全てが理解できました。今後も長期的に日常運用として採用したいと思います。実行速度がやや遅く、ダウンロード速度が時折低下する点（

nomodeset
が必要になることも）を除けば、NixOS とほぼ同等の体験です。

パッケージングについては後日、Wezterm を自分でパッケージ化した経験を踏まえた記事を書きます。システム導入と同様に手間がかかることを実感しています。

ご覧いただきありがとうございました！

8. 備考

  • インストーラは比較的単純。
  • ハードウェア非互換の警告あり。
  • 最低でも2½時間（ミラーが50 kB/sに制限）でインストール完了。
  • KDE タイトルバーが欠落し、デフォルトでは動作しない。
  • デフォルトは X11、Wayland は NVIDIA の問題で実現できず。
  • IRC で 
    nomodeset
    を推奨されてもほとんど効果なし。
  • Nonguix を有効化するとシステムが起動しなくなる。
  • Nonguix ISO からインストールする場合、古いリリースでエラー多発、導入に 
    --disable-authentication
    が必要。
  • ダウンロード速度は再プル後に正常化。
  • sudo
    を使うタイミングが不明確。
  • i3 を低解像度で動かすと独特の雰囲気があるが、完全に機能するシステムを好む。

同じ日のほかのニュース

一覧に戻る →

2026/02/01 7:05

SwiftはRustよりも便利なプログラミング言語です。

## Japanese Translation: > **概要：** > 本文は、メモリ管理モデル、コンパイル先、設計哲学、機能セット、性能トレードオフ、およびクロスプラットフォーム対応範囲において Rust と Swift を比較しています。 > • **メモリ管理：** Rust はガーベジコレクションを用いず所有権／借用（ownership/borrowing）を採用し、Swift はコピーオンライトとオプションの「所有」セマンティクスを備えた値型をデフォルトにしています。両方とも unsafe な生ポインタをサポートします。 > • **コンパイル：** 両言語は LLVM を介してネイティブコードへコンパイルし、WebAssembly（WASM）もサポートします。 > • **設計目標：** Rust は低レベルでボトムアップのシステム言語、Swift は高レベルでトップダウンですが、オプションで低レベルアクセスを提供します。 > • **コピーオンライトと再帰：** Rust では明示的に `Cow<>` と `.as_mutable()` を使用してコピーオンライトを行い、再帰型循環を解消するには `Box<>`（または `Rc/Arc`）が必要です。Swift はコピーオンライトを自動化し、再帰を扱うために `indirect` キーワードを利用します。 > • **エラーハンドリング：** Rust の `Result<T,E>` と `?` 演算子；Swift の `do‑catch` と `try`。 > • **機能的対実用的特徴：** Swift は C ライクな構文（例：`switch` を match として、列挙型にメソッドを付与）で機能的構造を隠し、導入を容易にしています。また、非同期／待機、アクター、プロパティラッパー、結果ビルダーといった実用的な言語機能を追加し、迅速な UI やサーバ開発を促進します。Rust はよりミニマリスティックですが、細かい制御が可能です。 > • **性能とユースケース：** Rust のプログラムはデフォルトで高速であることが多く、Swift は使いやすさを優先し、最適化されていない限り遅くなる場合があります。そのため、Rust は低レベルシステム作業に好まれ、Swift は迅速な UI やサーバ開発を求める開発者に適しています。 > • **クロスプラットフォーム拡張：** Swift は現在 Windows、Linux、組み込みデバイス（例：Panic Playdate）、WebAssembly で動作し、汎用性が高まっています。ただし、コンパイル時間の長さ、機能セットの大きさ、Rust に比べて成熟度の低いパッケージエコシステムといった課題も残ります。

2026/02/01 2:21

モバイルキャリアは、あなたのGPS位置情報を取得できることがあります。

## Japanese Translation: Appleの次期iOS 26.3は、電話がApple独自のモデムシリコンとファームウェアを使用する際に「正確な位置情報」―単桁メートル精度のGNSS座標―を携帯キャリアに送信しないプライバシー保護機能を導入します。これは2025年に発売されるデバイスで利用可能です。この機能は、通常キャリアがこれらの詳細な座標をダウンロードできるRRLP（2G/3G用）とLPP（4G/5G用）の制御平面プロトコルを無効化します。Appleがモデムハードウェアとファームウェアの両方を管理しているために機能し、サードパーティ製モデムにはこのレベルの統合がありません。 セル塔ベースの位置決定（数十〜数百メートル精度しか提供できない）に加え、電話はデバイス上で静かにGNSS位置を計算し、ネットワーク要求が行われたときのみそれらを送信します。そうでなければ携帯端末からは何もデータが離れません。米国DEA（2006年）やイスラエルのShin Betなどの法執行機関は、RRLP/LPPを使用して調査用GPS座標を取得し、またイスラエルのキャリアは2020年3月にCOVID‑19接触追跡のために正確な位置データを収集し、近接接触者へのSMS警告を送信しました。 Appleはこの機能を、ユーザーがGNSSデータのキャリア要求から完全にオプトアウトできるようにする第一歩として位置づけており、そうした試みが行われた際に通知を受け取れるようにします。Appleのモデム搭載デバイスは即座に不正追跡リスクの低減から恩恵を受けますが、キャリアとサードパーティ製モデムベンダーはサービスを適応させる必要があります。本機能の展開はまだApple以外のモデム搭載デバイスには適用されていません。 *注：* RRLP/LPP以外にも未公開の仕組みが存在する可能性があり、外国キャリアによるSS7悪用（例：サウジアラビア）では通常デバイスをモバイルスイッチングセンターまでしか特定できず、GNSSよりも精度が低いです。

2026/02/01 6:14

**生成AIとウィキペディア編集：2025年に学んだこと** - **人間とAIの協働が増加** - 編集者は、AI が作成したドラフトを第一稿として定期的に利用し始めた。 - 人間のレビュアーが引用を追加し、事実確認・トーン調整を行った。 - **品質保証の強化** - 新しいAI駆動型ファクトチェックツールで、公開前に矛盾点を検出した。 - 自動スタイルチェックにより、ウィキペディアのマニュアル・オブ・スタイルへの準拠が確保された。 - **コミュニティの受容とガバナンス** - ウィキメディア財団は、許容されるAI貢献を明記したガイドラインを導入。 - AI関与の透明なログ作成がすべての編集に対して必須となった。 - **偏見緩和への取り組み** - バイアス検出アルゴリズムが特定トピックでの過剰表現を指摘。 - 編集監視チームは偏向した視点を修正し、多様な観点を追加した。 - **パフォーマンス指標** - 平均編集完了時間が2024年比で約30 %短縮された。 - AI支援による記事更新数は12 %から28 %へと増加した。 - **今後の方向性** - AI生成引用文献の継続的改善。 - 英語以外のウィキペディア版への多言語サポート拡充。 **主な結論：** 2025年には、生成AIがウィキペディア編集に不可欠なツールとなり、効率向上とともにコミュニティ基準・品質管理の強化を実現した。

## Japanese Translation: Wiki Educationは、英語版ウィキペディアの新規アクティブ編集者の約19％を供給するプログラムを運営しており、ChatGPT、Gemini、Claudeなどの生成AIツールがどのように利用されているかを監視しています。 2022年11月以降、同組織はAI検出器Pangramを使用して新しい編集に対する幻覚（hallucinations）と引用ギャップをスポットチェックしています。2015年から現在までの3,078件の新記事コーパスから、Pangramは178件をAI生成としてフラグしましたが、そのうちわずか7％が架空のソースを含み、2/3以上が引用された参考文献が主張を裏付けていないため検証に失敗しています。 スタッフはその後、これらの記事をクリーンアップし、最近の作業をサンドボックスへ戻したり、修復不可能な記事をスタブ化またはPRODe（プロテクト）しました。また、2025年にPangramをダッシュボードプラットフォームに統合し、ほぼリアルタイムで検出できるようにしています。2025年秋だけでも1,406件のAIアラートが記録され、そのうち314件（22％）がライブページに影響しました。さらに、217名の参加者（新規編集者6,357人中3％）が複数回アラートを受けました。この介入により、本空間でのAIコンテンツの予測比率は約25％から約5％へと削減されました。 学生たちは主に研究作業（ギャップの特定、ソースの検索、文法チェック）にAIを利用したと報告しましたが、課題テキストのドラフトには使用していませんでした。 今後、Wiki Educationは2026年もPangramを継続運用し、非プローズコンテンツへの検出精度を向上させる予定です。また、オプションのLLMリテラシーモジュールを提供しつつ、メールと動画による自動化トレーニングも継続します。