Sops takes your hosts ssh key to decrypt your secrets during boot so you need those as additional key(s) as well.
See step 3 in the documentation: mic92/sops-nix
1 like
仕事用のWSL環境をArch LinuxからNixOSに変えた話
仕事用のWSL環境をArch LinuxからNixOSに変えたので初投稿です。
Linuxを日頃から愛している皆さんがWindowsマシンを渡されたら最初にやることは、好きなディストリビューションのインストーラーイメージが入ったUSBを挿してWindowsを排除することwsl --install --no-distributionだと思いますが、皆さんは最初にどんなディストリビューションのLinuxを入れているでしょうか。
私は今までUbuntuやAlpine Linuxなどに仮想環境やコンテナ上で触れることはあっても、実機や開発環境で使うことはありませんでした。
ある日、自宅で使っているPCがWindows 10からWindows 11にアップグレードできないと知って困っていたとき、学生時代の友人からArch Linuxを激推しされました。なので、Arch Wikiと友人のサポートを受けつつも、なんとか黒い画面で操作しつつインストールしたことから全てが始まったのを覚えています。
ログインしてKDE Plasma 5のデスクトップ環境が画面に出てきたときは感動しましたね。
そんな昔話はさておき、そういった経緯から私は仕事用のWSL環境でもArch Linuxを入れて普段の業務を遂行していましたが、Arch Linuxあるあるの「突然の危機」から逃れたい気持ちや好奇心からNixOSというものに切り替えたので、NixOSとArch Linuxのあれこれについて軽く記事を書いてみました。
Arch Linuxとは
その名のとおり、Linuxディストリビューションの一つです。
特徴としてローリングリリースを採用しているため、ディストリビューションにバージョンという概念がない点が大きいのではないでしょうか。そして、それを支えるpacmanというパッケージマネージャーが用意されており、pacman -Syuを実行すれば、カーネルを含むインストール済みのパッケージを一発で最新に更新できます。
サーバー用途向けではないですが、普段使いするユーザーで、周りのものを常に最新にしておきたい人にとったら最高だと思います。
さらに、PKGBUILDファイルからパッケージを作成できるArch Build Systemがあり、そのPKGBUILDファイルをArch User Repository（AUR）経由でユーザー間で共有できます。公式のリポジトリに含まれないパッケージやオリジナルのパッケージも、AURからPKGBUILDを入手して内容を確認し、makepkgでビルドすればpacmanでインストールできるのがよいです。
AURのパッケージはpacman -Syuだけでは更新されないため、別途ビルドし直すか、AURヘルパーなどを使う必要があります。
詳しくはArch Wikiを見よう！
wiki.archlinux.jp
困ったこと
常に最新の弊害
パッケージをアップデートすると、たまに突然トラブルが起きることがあります。
とりあえずすぐに解決したくてパッケージをダウングレードしようとしても、リポジトリからは最新のバージョンしか入手できません。キャッシュから復元するか、Arch Linux Archiveから古いバージョンのパッケージをダウンロードしないといけないなど、面倒なことになります。(downgradeという便利なAURのパッケージもありますが)
ダウングレードする際は、依存するパッケージも合わせてダウングレードする必要がある場合があります。
wiki.archlinux.org
私は当たったことがないですが、パッケージをアップデートしたことで復旧しづらくなった場合、NixOSのように世代を使ってロールバックする仕組みがないので、悲惨なことになるそうです。怖い！
そして、アップデート時に、変更した設定と新しいパッケージの設定がそれぞれ元の設定と異なり、互いにも異なる場合などは、既存の設定を上書きせずに新しい設定が.pacnewという拡張子付きのファイルとして生成されます。時間が経つと、.pacnewファイルを確認して対応するのが面倒になってきます。
wiki.archlinux.org
環境の維持
Arch Linux全然関係ないんですけど、自分の環境をまめにちゃんと整理できなくなってました。
最初はchezmoiでdotfilesを作って管理していたのですが、途中から面倒になってメンテしなくなっちゃいました。
いつでも、どんなときでも自分の使いやすい環境を構築するために作ったのに、結局は強制されないと維持しようという気にもならなくなっちゃうもんなんですよね。
ちゃんと定期的に更新する習慣をつけている人はえらいなと思います。
ちなみに、chezmoiはパスワードマネージャーと連携できたりと非常に良いdotfilesマネージャーなので興味のある人は使ってみてほしいです。
chezmoi.io
お掃除が大変
使わなくなったパッケージとかまめにアンインストールするならいいかもしれないんですけど、忘れていると知らない間に環境が汚れています。
そして後から整理しようと思っても、どれを消せばいいか覚えてない...
なので私は定期的にクリーンインストールしていましたね。
そんなあなたにNixOS
Arch Linuxと同じくLinuxディストリビューションの一つです。
NixOSとは何かを解説したいのですが、NixOSを知るにはまずNixを知る必要があります。Nixを知るための内容を書いているだけでこの記事が終わってしまうので、もし興味のある方はasa1984さんの素晴らしい本を見てNixを理解するところから始めるといいと思います。
zenn.dev
なぜNixOSなのか
NixのメリットをOSレベルで受けることができるからです。
nixos.org
アップデートを恐れなくていい
まだWSLで恩恵を受けた場面はないですが、もしnixos-rebuild switchを実行してWSLのNixOSが起動しなくなってしまった場合は、ひと呼吸おいて以下の公式ドキュメントを参考にしてください。復旧用のシェルから構成を復元することができます。
nix-community.github.io
また、NixOS 26.05のnixos-rebuildを使うと、NixOS内で世代を巻き戻すことが可能です。まず、以下のコマンドで世代を一覧します。
$ nixos-rebuild list-generations
Generation Build-date NixOS version Kernel Configuration Revision Specialisation Current
83 2026-10-27 18:54:04 26.11.20261023.3ec6363 Unknown Unknown [] True
82 2026-10-27 18:55:05 26.11.20261023.3ec6363 Unknown Unknown [] False
81 2026-10-27 18:54:15 26.11.20261023.3ec6363 Unknown Unknown [] False
...
nixos-rebuildで使用できる--store-pathオプションを使うと、別の世代の構成に切り替えることができます。
sudo nixos-rebuild switch --store-path /nix/var/nix/profiles/system-82-link
ローリングリリースにするか選べる
NixOSは年二回（5月と11月）に安定版をリリースするので、それらをベースに環境を構築するか、nixos-unstableと呼ばれるローリングリリースを選択することができます。
nixos-unstableはnixpkgsのmasterブランチを追いかけ、HydraというCIでチャンネルの更新に必要なビルドとテストを通過した時点の内容が反映される仕組みになっています。
なので、nixpkgsでは更新されていてもすぐに最新のパッケージがnixos-unstableに反映されるような感じではないです。
加えて、nixos-unstableは次期リリースバージョンの変更も入ってくるためちょこちょこエラーが出たり、非推奨の機能がポツポツ出てきたりと追従するのが大変だったりします。
宣言的で再現性の高い環境の構築と維持
Nixを使えば宣言的で再現性の高い環境を作り、維持することができます。
再現性が高いというのは、Nix言語で記述した内容に対して全く異なる環境でも同じ入力であれば同じ環境を構築することが可能だからです。
こんなことができるのは恐らくNixだけだと思います。
なので、Nixで置き換えられるものはどんどん置き換えておくと便利です。
私は以下のようなものをNixで管理するようにしています。
認証情報
sops-nixで管理してます
開発ツールの設定
エディタ周り：Helix
LLM周り：Herdr, Hunk, Hermes Agentなど
シェル周り：zshとプラグインとか
LLM
Agent Skills
AGENTS.md
etc
さらに、テーマ色をカスタムできるアプリでは、Nixで用意したカラーパレットを使って、それぞれに合うように見た目を整えたりもしています。
逆にNixOSで困ること
NixOSがFHSに従っていない
多分Nixを触り始めると最初にぶつかる壁だと思いますが、FHSに従っていないことで苦労する場面がちょこちょこあると思います。
FHS (Filesystem Hierarchy Standard)とは、LinuxをはじめとするUnix系OSにおいて、ファイルやディレクトリをどこに配置するかを定めた標準規格です。
ほとんどのLinuxディストリビューションでは、以下のようなディレクトリにプログラム、ライブラリ、設定ファイルなどが配置されます。
/bin
/usr/bin
/lib
/usr/lib
/usr/share
/etc
ただ、Nixはこれらに配置するものを/nix/storeに配置して管理するため、普通なら動くものが動かなかったりするケースがまぁまぁあります。
例を挙げると、protoのようなバージョンマネージャーでLinux向けに配布されたバイナリを落としてきても、動的リンカーやライブラリのパスが見つからず動かないことがあります。
でも、対処法がないわけではないです。
nix-ldを使用する
patchelfでバイナリが参照するライブラリのパスを上書きする
buildFHSEnvを使う
nix.dev
まぁ、この仕組みがあるから同一パッケージでも複数共存できるし、世代からロールバックできたりするわけなんで適応していきましょう。
/nix/storeがデカすぎる
同じ依存関係でも複数のバージョンを保持していたり、バージョンが同じでもハッシュ値が異なるものを別物としてそれぞれ保持しているからですね。
容量に余裕がないと苦しいと思います。
これも再現性を高め、依存関係を衝突させないための仕組みとして必須なのでしょうがないです。
一応以下のような記述をNixで書いておくと、Nix Storeの最適化と古い世代の削除を自動で行うことができます。
{
nix.gc = {
automatic = true;
dates = "weekly";
options = "--delete-older-than 30d";
};
nix.optimise.automatic = true;
}
ただし、削除された世代にはロールバックできなくなります。保持する期間は自分に合わせて決めましょう。
nix.dev
nhというオープンソースを使って定期的にクリーンアップするのもアリ
アプリケーションが直接書き込みを行うファイル
最近だと例に挙げやすいのはCodex CLIとかClaude Codeですかね。
これらのエージェントツールはそれぞれ、~/.codex/config.tomlや~/.claude/settings.jsonの中身を変更しようとするときがあります。
例えば~/.codex/config.tomlをHome ManagerなどでNix Store内のファイルへのシンボリックリンクとして配置すると、参照先のconfig.tomlは書き込みが禁止されています。そのため、Codex CLIが設定を変更しようとしたときに、うまく動作しない場合があります。
WSLにNixOSを入れる
さて、ここまで長々と語ってきましたが、最後にWSLにNixOSを入れてnixos-rebuildで世代を作成するところまで解説して終わります。
まずは、有志によってメンテナンスされているNixOS-WSLを使用しましょう。
NixOS-WSLとWSLのおかげでインストーラーイメージを使ってインストールするよりも楽に導入することができます。
WSL v2.4.4以降はReleasesからnixos.wslを落としてクリックするだけでインストールできるらしいです。なにそれ便利
nix-community/NixOS-WSL
インストールが終わって、PowerShellからwsl -d NixOSでアクセスするとnixosというユーザーでログインされます。
ウェルカムメッセージに表示されているコマンドを実行してセットアップを終えましょう。
チャンネルを使う場合、初回インストール後はsudo nix-channel --updateを一度実行する必要があります。
ユーザーパスワードの設定
このままこのユーザーを普段使いするのであれば、passwdコマンドでパスワードを設定しておいたほうがいいでしょう。
また、デフォルトの状態だとnixosユーザーがwheelグループに所属していて、パスワードなしでもsudoで色々操作できるようになっています。
sudoでもパスワードを要求する場合は、後述するconfiguration.nixにsecurity.sudo.wheelNeedsPassword = true;を設定します。
nix-community.github.io
configuration.nixを編集する
sudoeditで/etc/nixos/configuration.nixというファイルを指定してエディタを開きます。（デフォルトだとnanoが使われます）
sudoedit /etc/nixos/configuration.nix
設定可能な項目については、公式がオプションの検索ツールを用意してくれているので、それを見ながら記述していきます。
search.nixos.org
WSLだとありがたいことに、インストーラーイメージから行うような設定項目をほぼスキップできます。
世代を作る
nixos.org
変更をテストする
まず、変更したconfiguration.nixが正しく動作するか確かめるために、以下のコマンドを実行しましょう。
sudo nixos-rebuild test
このコマンドを実行すると、再起動するまでの間新しい構成を今動いている環境に反映することができます。
そのため、もし問題が発生して何も操作ができなくなったら、PowerShellからwsl --terminate NixOSでNixOSを停止し、再起動すると変更前の設定に戻すことができます。
世代を作成する
テストして問題なく動作していたら、以下のコマンドで世代を作成して再起動後も使えるようにしましょう。
即時に反映する場合: sudo nixos-rebuild switch
次の起動から反映する場合: sudo nixos-rebuild boot
もし、反映後に前の世代にロールバックしたい場合はsudo nixos-rebuild switch --rollbackを実行すると、一つ前の世代に戻すことができます。
wiki.nixos.org
終わり
以上、Arch LinuxからNixOSに移した話と、WSLへNixOSを導入するためのおまけでした。
他にNixOSの好きなところを挙げるとしたら、nix-shellとnix developが強力な点ですね。
LLMを動かすときにスキルとかで不足しているパッケージがある場合、一々パッケージマネージャーを使ってインストールしなくても、nix-shell -pを使えば一時的にnixpkgsからパッケージを落として実行ができます。
Nixも学習コストが高い部類ではありますが、LLMの登場で学習しやすくなったと感じているので、今後に期待できるLinuxディストリビューションの一つなのではないかと思っています。
/etc/nixos配下のnixファイルを弄ることに慣れてきたら、Nix FlakesやHome-Managerに手を出すともっと面白いです。
Arch Linuxもいいが、NixOSもいいぞ！
Can't say I love your business model for this stuff, but I do like to see work on improving Nix evaluation, and nix top sounds somewhat useful (Still need to set up nom for build logs).
For even faster GC, consider integrating:
Mic92/fast-nix-gc
1 like
Update: after a few very annoying hours with my coding agent, I was able to get an ast-grep-based treewide for some trivial cases (Still needs me to do a manual test to make sure that I didn't break any packages with this EDIT: 0 rebuilds! Although it did break nixpkgs-review :wink:).
nixpkgs#578434
For the rest, I think that I'll just get my coding agent to fix them in batch with more autonomous self-verification, then do a manual review of their changes and submit them to nixpkgs as I have the time to do review.
1 like
everytime i need something for nix mic92 already built it
1. Mic92/tribuchet
2. Mic92/nix-grpc-store
rbe but for nix t.co
18 likes · 1 repost · 1,912 views
@ProgrammerDude Yeah, it's worth a try, I think it could save quite a bit of IO on large files and folders. For remote builders, switching to gRPC with builtin compression helps also quite a bit Mic92/nix-grpc-store .
And then on the other side, nixpkgs's dependency tree could be shrunk.
3 likes · 1 repost · 83 views
Mentions
Sops takes your hosts ssh key to decrypt your secrets during boot so you need those as additional key(s) as well. See step 3 in the documentation: mic92/sops-nix
仕事用のWSL環境をArch LinuxからNixOSに変えた話 仕事用のWSL環境をArch LinuxからNixOSに変えたので初投稿です。 Linuxを日頃から愛している皆さんがWindowsマシンを渡されたら最初にやることは、好きなディストリビューションのインストーラーイメージが入ったUSBを挿してWindowsを排除することwsl --install --no-distributionだと思いますが、皆さんは最初にどんなディストリビューションのLinuxを入れているでしょうか。 私は今までUbuntuやAlpine Linuxなどに仮想環境やコンテナ上で触れることはあっても、実機や開発環境で使うことはありませんでした。 ある日、自宅で使っているPCがWindows 10からWindows 11にアップグレードできないと知って困っていたとき、学生時代の友人からArch Linuxを激推しされました。なので、Arch Wikiと友人のサポートを受けつつも、なんとか黒い画面で操作しつつインストールしたことから全てが始まったのを覚えています。 ログインしてKDE Plasma 5のデスクトップ環境が画面に出てきたときは感動しましたね。 そんな昔話はさておき、そういった経緯から私は仕事用のWSL環境でもArch Linuxを入れて普段の業務を遂行していましたが、Arch Linuxあるあるの「突然の危機」から逃れたい気持ちや好奇心からNixOSというものに切り替えたので、NixOSとArch Linuxのあれこれについて軽く記事を書いてみました。 Arch Linuxとは その名のとおり、Linuxディストリビューションの一つです。 特徴としてローリングリリースを採用しているため、ディストリビューションにバージョンという概念がない点が大きいのではないでしょうか。そして、それを支えるpacmanというパッケージマネージャーが用意されており、pacman -Syuを実行すれば、カーネルを含むインストール済みのパッケージを一発で最新に更新できます。 サーバー用途向けではないですが、普段使いするユーザーで、周りのものを常に最新にしておきたい人にとったら最高だと思います。 さらに、PKGBUILDファイルからパッケージを作成できるArch Build Systemがあり、そのPKGBUILDファイルをArch User Repository（AUR）経由でユーザー間で共有できます。公式のリポジトリに含まれないパッケージやオリジナルのパッケージも、AURからPKGBUILDを入手して内容を確認し、makepkgでビルドすればpacmanでインストールできるのがよいです。 AURのパッケージはpacman -Syuだけでは更新されないため、別途ビルドし直すか、AURヘルパーなどを使う必要があります。 詳しくはArch Wikiを見よう！ wiki.archlinux.jp 困ったこと 常に最新の弊害 パッケージをアップデートすると、たまに突然トラブルが起きることがあります。 とりあえずすぐに解決したくてパッケージをダウングレードしようとしても、リポジトリからは最新のバージョンしか入手できません。キャッシュから復元するか、Arch Linux Archiveから古いバージョンのパッケージをダウンロードしないといけないなど、面倒なことになります。(downgradeという便利なAURのパッケージもありますが) ダウングレードする際は、依存するパッケージも合わせてダウングレードする必要がある場合があります。 wiki.archlinux.org 私は当たったことがないですが、パッケージをアップデートしたことで復旧しづらくなった場合、NixOSのように世代を使ってロールバックする仕組みがないので、悲惨なことになるそうです。怖い！ そして、アップデート時に、変更した設定と新しいパッケージの設定がそれぞれ元の設定と異なり、互いにも異なる場合などは、既存の設定を上書きせずに新しい設定が.pacnewという拡張子付きのファイルとして生成されます。時間が経つと、.pacnewファイルを確認して対応するのが面倒になってきます。 wiki.archlinux.org 環境の維持 Arch Linux全然関係ないんですけど、自分の環境をまめにちゃんと整理できなくなってました。 最初はchezmoiでdotfilesを作って管理していたのですが、途中から面倒になってメンテしなくなっちゃいました。 いつでも、どんなときでも自分の使いやすい環境を構築するために作ったのに、結局は強制されないと維持しようという気にもならなくなっちゃうもんなんですよね。 ちゃんと定期的に更新する習慣をつけている人はえらいなと思います。 ちなみに、chezmoiはパスワードマネージャーと連携できたりと非常に良いdotfilesマネージャーなので興味のある人は使ってみてほしいです。 chezmoi.io お掃除が大変 使わなくなったパッケージとかまめにアンインストールするならいいかもしれないんですけど、忘れていると知らない間に環境が汚れています。 そして後から整理しようと思っても、どれを消せばいいか覚えてない... なので私は定期的にクリーンインストールしていましたね。 そんなあなたにNixOS Arch Linuxと同じくLinuxディストリビューションの一つです。 NixOSとは何かを解説したいのですが、NixOSを知るにはまずNixを知る必要があります。Nixを知るための内容を書いているだけでこの記事が終わってしまうので、もし興味のある方はasa1984さんの素晴らしい本を見てNixを理解するところから始めるといいと思います。 zenn.dev なぜNixOSなのか NixのメリットをOSレベルで受けることができるからです。 nixos.org アップデートを恐れなくていい まだWSLで恩恵を受けた場面はないですが、もしnixos-rebuild switchを実行してWSLのNixOSが起動しなくなってしまった場合は、ひと呼吸おいて以下の公式ドキュメントを参考にしてください。復旧用のシェルから構成を復元することができます。 nix-community.github.io また、NixOS 26.05のnixos-rebuildを使うと、NixOS内で世代を巻き戻すことが可能です。まず、以下のコマンドで世代を一覧します。 $ nixos-rebuild list-generations Generation Build-date NixOS version Kernel Configuration Revision Specialisation Current 83 2026-10-27 18:54:04 26.11.20261023.3ec6363 Unknown Unknown [] True 82 2026-10-27 18:55:05 26.11.20261023.3ec6363 Unknown Unknown [] False 81 2026-10-27 18:54:15 26.11.20261023.3ec6363 Unknown Unknown [] False ... nixos-rebuildで使用できる--store-pathオプションを使うと、別の世代の構成に切り替えることができます。 sudo nixos-rebuild switch --store-path /nix/var/nix/profiles/system-82-link ローリングリリースにするか選べる NixOSは年二回（5月と11月）に安定版をリリースするので、それらをベースに環境を構築するか、nixos-unstableと呼ばれるローリングリリースを選択することができます。 nixos-unstableはnixpkgsのmasterブランチを追いかけ、HydraというCIでチャンネルの更新に必要なビルドとテストを通過した時点の内容が反映される仕組みになっています。 なので、nixpkgsでは更新されていてもすぐに最新のパッケージがnixos-unstableに反映されるような感じではないです。 加えて、nixos-unstableは次期リリースバージョンの変更も入ってくるためちょこちょこエラーが出たり、非推奨の機能がポツポツ出てきたりと追従するのが大変だったりします。 宣言的で再現性の高い環境の構築と維持 Nixを使えば宣言的で再現性の高い環境を作り、維持することができます。 再現性が高いというのは、Nix言語で記述した内容に対して全く異なる環境でも同じ入力であれば同じ環境を構築することが可能だからです。 こんなことができるのは恐らくNixだけだと思います。 なので、Nixで置き換えられるものはどんどん置き換えておくと便利です。 私は以下のようなものをNixで管理するようにしています。 認証情報 sops-nixで管理してます 開発ツールの設定 エディタ周り：Helix LLM周り：Herdr, Hunk, Hermes Agentなど シェル周り：zshとプラグインとか LLM Agent Skills AGENTS.md etc さらに、テーマ色をカスタムできるアプリでは、Nixで用意したカラーパレットを使って、それぞれに合うように見た目を整えたりもしています。 逆にNixOSで困ること NixOSがFHSに従っていない 多分Nixを触り始めると最初にぶつかる壁だと思いますが、FHSに従っていないことで苦労する場面がちょこちょこあると思います。 FHS (Filesystem Hierarchy Standard)とは、LinuxをはじめとするUnix系OSにおいて、ファイルやディレクトリをどこに配置するかを定めた標準規格です。 ほとんどのLinuxディストリビューションでは、以下のようなディレクトリにプログラム、ライブラリ、設定ファイルなどが配置されます。 /bin /usr/bin /lib /usr/lib /usr/share /etc ただ、Nixはこれらに配置するものを/nix/storeに配置して管理するため、普通なら動くものが動かなかったりするケースがまぁまぁあります。 例を挙げると、protoのようなバージョンマネージャーでLinux向けに配布されたバイナリを落としてきても、動的リンカーやライブラリのパスが見つからず動かないことがあります。 でも、対処法がないわけではないです。 nix-ldを使用する patchelfでバイナリが参照するライブラリのパスを上書きする buildFHSEnvを使う nix.dev まぁ、この仕組みがあるから同一パッケージでも複数共存できるし、世代からロールバックできたりするわけなんで適応していきましょう。 /nix/storeがデカすぎる 同じ依存関係でも複数のバージョンを保持していたり、バージョンが同じでもハッシュ値が異なるものを別物としてそれぞれ保持しているからですね。 容量に余裕がないと苦しいと思います。 これも再現性を高め、依存関係を衝突させないための仕組みとして必須なのでしょうがないです。 一応以下のような記述をNixで書いておくと、Nix Storeの最適化と古い世代の削除を自動で行うことができます。 { nix.gc = { automatic = true; dates = "weekly"; options = "--delete-older-than 30d"; }; nix.optimise.automatic = true; } ただし、削除された世代にはロールバックできなくなります。保持する期間は自分に合わせて決めましょう。 nix.dev nhというオープンソースを使って定期的にクリーンアップするのもアリ アプリケーションが直接書き込みを行うファイル 最近だと例に挙げやすいのはCodex CLIとかClaude Codeですかね。 これらのエージェントツールはそれぞれ、~/.codex/config.tomlや~/.claude/settings.jsonの中身を変更しようとするときがあります。 例えば~/.codex/config.tomlをHome ManagerなどでNix Store内のファイルへのシンボリックリンクとして配置すると、参照先のconfig.tomlは書き込みが禁止されています。そのため、Codex CLIが設定を変更しようとしたときに、うまく動作しない場合があります。 WSLにNixOSを入れる さて、ここまで長々と語ってきましたが、最後にWSLにNixOSを入れてnixos-rebuildで世代を作成するところまで解説して終わります。 まずは、有志によってメンテナンスされているNixOS-WSLを使用しましょう。 NixOS-WSLとWSLのおかげでインストーラーイメージを使ってインストールするよりも楽に導入することができます。 WSL v2.4.4以降はReleasesからnixos.wslを落としてクリックするだけでインストールできるらしいです。なにそれ便利 nix-community/NixOS-WSL インストールが終わって、PowerShellからwsl -d NixOSでアクセスするとnixosというユーザーでログインされます。 ウェルカムメッセージに表示されているコマンドを実行してセットアップを終えましょう。 チャンネルを使う場合、初回インストール後はsudo nix-channel --updateを一度実行する必要があります。 ユーザーパスワードの設定 このままこのユーザーを普段使いするのであれば、passwdコマンドでパスワードを設定しておいたほうがいいでしょう。 また、デフォルトの状態だとnixosユーザーがwheelグループに所属していて、パスワードなしでもsudoで色々操作できるようになっています。 sudoでもパスワードを要求する場合は、後述するconfiguration.nixにsecurity.sudo.wheelNeedsPassword = true;を設定します。 nix-community.github.io configuration.nixを編集する sudoeditで/etc/nixos/configuration.nixというファイルを指定してエディタを開きます。（デフォルトだとnanoが使われます） sudoedit /etc/nixos/configuration.nix 設定可能な項目については、公式がオプションの検索ツールを用意してくれているので、それを見ながら記述していきます。 search.nixos.org WSLだとありがたいことに、インストーラーイメージから行うような設定項目をほぼスキップできます。 世代を作る nixos.org 変更をテストする まず、変更したconfiguration.nixが正しく動作するか確かめるために、以下のコマンドを実行しましょう。 sudo nixos-rebuild test このコマンドを実行すると、再起動するまでの間新しい構成を今動いている環境に反映することができます。 そのため、もし問題が発生して何も操作ができなくなったら、PowerShellからwsl --terminate NixOSでNixOSを停止し、再起動すると変更前の設定に戻すことができます。 世代を作成する テストして問題なく動作していたら、以下のコマンドで世代を作成して再起動後も使えるようにしましょう。 即時に反映する場合: sudo nixos-rebuild switch 次の起動から反映する場合: sudo nixos-rebuild boot もし、反映後に前の世代にロールバックしたい場合はsudo nixos-rebuild switch --rollbackを実行すると、一つ前の世代に戻すことができます。 wiki.nixos.org 終わり 以上、Arch LinuxからNixOSに移した話と、WSLへNixOSを導入するためのおまけでした。 他にNixOSの好きなところを挙げるとしたら、nix-shellとnix developが強力な点ですね。 LLMを動かすときにスキルとかで不足しているパッケージがある場合、一々パッケージマネージャーを使ってインストールしなくても、nix-shell -pを使えば一時的にnixpkgsからパッケージを落として実行ができます。 Nixも学習コストが高い部類ではありますが、LLMの登場で学習しやすくなったと感じているので、今後に期待できるLinuxディストリビューションの一つなのではないかと思っています。 /etc/nixos配下のnixファイルを弄ることに慣れてきたら、Nix FlakesやHome-Managerに手を出すともっと面白いです。 Arch Linuxもいいが、NixOSもいいぞ！
Can't say I love your business model for this stuff, but I do like to see work on improving Nix evaluation, and nix top sounds somewhat useful (Still need to set up nom for build logs). For even faster GC, consider integrating: Mic92/fast-nix-gc
Update: after a few very annoying hours with my coding agent, I was able to get an ast-grep-based treewide for some trivial cases (Still needs me to do a manual test to make sure that I didn't break any packages with this EDIT: 0 rebuilds! Although it did break nixpkgs-review :wink:). nixpkgs#578434 For the rest, I think that I'll just get my coding agent to fix them in batch with more autonomous self-verification, then do a manual review of their changes and submit them to nixpkgs as I have the time to do review.
everytime i need something for nix mic92 already built it 1. Mic92/tribuchet 2. Mic92/nix-grpc-store rbe but for nix t.co
@ProgrammerDude Yeah, it's worth a try, I think it could save quite a bit of IO on large files and folders. For remote builders, switching to gRPC with builtin compression helps also quite a bit Mic92/nix-grpc-store . And then on the other side, nixpkgs's dependency tree could be shrunk.