ArchLinuxからNixOSに環境を移行する+移行後のつまづいたポイントとかメモとか
追記
NixOSへの移行はここで完了していますが、引き続きNix環境でつまづいたポイントをここに書き溜めていく方針です。よってここはクローズされることはありません。
全体の記事化も検討しましたが、1つ1つの内容は独立しながらもゆるやかに繋がっているため、おそらくこのままスクラップであり続けると思います。
最近の更新でKDE Plasmaが5→6になった影響で様々なものが壊れた。X11環境特有っぽいバグも見られるのでストレスがマッハ(画面上にウィンドウレベルのアニメーションが入るとフレームレートが一時的にガタ落ちして作業にならない)
戻すのも面倒なので前から気になってたNixOSに移行して再現率100%の環境を作る
事前に見てた記事
- https://zenn.dev/asa1984/articles/nixos-is-the-best#環境構築
-
https://zenn.dev/nixos/articles/ff1cc62ff04de0
今見つけた記事 - https://zenn.dev/nyarla/scraps/d0eeca162a780a
まずはVM上で環境を作る
IntelliJ製品の導入
この一見単純なことで盛大に沼った。ので解決までの道程を書く
とりあえず基本的なことはwikiの通りやれば良い
一部pluginをbuildinで導入できるので入れられるやつは入れておくとお得。対応してるリストはこれ。現時点では少ないけど、copilotみたいな一部パッチが必要なものを自動でやってくれるのでうれしい。AndroidStudioはaddPluginできないっぽいのでそこだけ残念(普通にCopilot導入したら動いたのでヨシッ)
JetbrainsToolBoxも入れてみたけどまあ普通に動く。一応nix-ldの設定とnix-ld-rsも入れた。こいつのせいかは知らないけどlinuxのzenカーネルだと意味わからんもんをビルドしようとした挙句失敗するのでノーマルのカーネルかxanmodとかにしておくと良い
Failed to locate library: libGL.so
普段MinecraftのMOD開発をするのだが、IDEAからマイクラのクライアントが起動できないことに気付いた
同様の問題がdiscourseにもあったけど、解決方法は記載無し(最終的にはnix-ldも使えないことは無いけど微妙だった)
調査した結果、lwjglがLD_LIBRARY_PATH経由でlibGLを捜索するのが原因っぽい。ld.so経由してくれたらnix-ldが動作したのになんなんだよお前
とりあえずideaの起動時にLD_LIBRARY_PATHに必要な依存関係のパスを渡そうと色々やった
試行錯誤した順番で紹介(一番良かったやつは最後)
1. スクリプトでラップする
idea = (pkgs.writeShellScriptBin "idea-ultimate" ''
export LD_LIBRARY_PATH=$NIX_LD_LIBRARY_PATH
exec ${patched-idea}/bin/idea-ultimate "$@"
'');
とか
Githubで検索してヒットしたこれ
requiredLibPath = with pkgs; lib.makeLibraryPath [
libGL
udev
];
idea = pkgs.runCommand "intellij" {nativeBuildInputs = [pkgs.makeWrapper];} ''
mkdir -p $out/bin
makeWrapper ${patched-idea}/bin/idea-ultimate $out/bin/intellij --prefix LD_LIBRARY_PATH : ${requiredLibPath}
'';
コンソールからしか起動できないので微妙
2. overrideAttrsでpostInstallを書き換える
意味なかった。謎
3. pkgs.symlinkJoinでラップ
これとこれ
みて書いた。ちゃんとKRunnerから呼べたので満足
ファイル
これに辿り付くまでに5時間ぐらい持ってかれた。その代わりld.soとかnixについて深く知れたのとgithubの上にある検索バーが最強って分かったので良いことにする
neovimを設定する
昔から使ってたこの設定達をnixに移植しつつ、もっと小さい環境を作ろうとした
ここ数年neovimだったりlunarvimだったりを使った感想として、自分にとってvimはgitのコミットメッセージをコマンドラインから書くときと、書き込みにsuper user権限が必要なファイルを弄る時だけ必要なツールなので、基本設定+skkぐらいに抑えた
ぶっちゃけhome-managerの設定が最強だったので特に言うことないけど、ソースコード見ないと気付かなかったことがちょくちょくあったので書く
programs.neovim.pluginsの書き方について
例では
with pkgs.vimPlugins; [
yankring
vim-nix
{ plugin = vim-startify;
config = "let g:startify_change_to_vcs_root = 0";
}
]
しか書かれてないけど、実はAttribute Setの時は便利なオプションが他にもある
- type
上の例でもあるconfigで記述している言語を指定できる。デフォルトはviml
だが、lua
とかteal
、fennel
が指定できる。使用例 - optional
trueにするとneovim内で:packadd
しない限りロードされない設定になる。条件によっては有効化したくないプラグインがあればここに式をつっこむだけで良いので便利そう。自分は使う場面がなかった - runtime
.config/neovim/
内に実際に配置したい設定を記載できる。conifg
の場合はinit.luaまたはそこからリンクされたinit.vimの中に記載されるので、例みたくって感じでneovimの機能を活かした設定ができる{ "ftplugin/c.vim".text = "setlocal omnifunc=v:lua.vim.lsp.omnifunc"; }
それぞれの詳細は以下のオプションを参照
ここまで書いたけどtype以外は今回使わなかった。
とりあえずgithubから指定したプラグインはcommitのrevisionまで指定できたので、当分壊れることは無いだろうって思えるのが嬉しい。
超地味なTipsだけど、programs.neovim.extraLuaConfigの先頭に改行を入れておかないと
vim.cmd [[source /nix/store/path-to-init.vim]]require'cmp'.setup {
みたいな感じで間に改行が入らないので注意。上で紹介したpluginsの設定でtype="lua"
なものがあるときも同じことが起きるので、とりあえず\n
を入れておくと安心かも
vim.cmd [[source /nix/store/path-to-init.vim]]
#ここでちゃんと改行されるようになる
require'cmp'.setup {
wallpaper-engine-kde-pluginの導入
今回の移行の動機であり破壊の原因でもあるKDEに自分が拘る原因の8割はこいつにある
Linux環境でありながらWallpaperEngineの壁紙がそのまま使える神プラグイン。これが入らないことにはお話にならない。
単なるPluginならKDEから入れて終わりだが、こいつは専用のlibが存在し、自分でビルドするしかない。ということでNixの仕組みを経由して構築してみる
文章としての情報はゼロに等しかったが、githubで検索したら割とヒットした。ありがとう先駆者
その中でも自分のやりたいことに近かったこれを参考に作成した
無事にビルドできたものの、Pythonのwebsocketsライブラリが無いよって怒られた。
試行錯誤を続けた結果、home-manager側で設定してたpython312を消したら解決した。試行錯誤で3時間以上持ってかれたふざけんな
最終的にはこう
一応関連スレッドにも投下しておいておいた
追記
上記の設定はまだ完璧じゃないことが後に分かった
どうやら手動でインストールしたプラグインとうまいこと噛み合って動作していたらしく。クリーンな環境で再度導入するとno_pyext_file_foundというエラーが出てpython3が無い扱いになった。
再度調査をしたところ、手動でインストールした際には存在していた~/.local/share/plasma/wallpapers/com.github.casout.wallpaperEngineKde
が消えていることに気付いた。そしてこの中のcontents/pyext.py
ってファイルを読み込もうとして失敗したのだと思われる。
どうやらNixは/run/current-system/sw/share/plasma/wallpapers/
にcom.github.casout.wallpaperEngineKde
を作成しており、これをKDEは認識できてないっぽい。良い方法が思い浮ばなかったのでとりあえずスクリプトでごり押すことにした
上で貼ったdiscourseでもこの件について話してたけど、まあ悪くない手段なんじゃねって言われたのでこれでヨシッ
nixpkgsの既存パッケージを書き換える
Steam内の表示で日本語が文字化けしていたので色々調べたら、使ってるNoto fontsが可変フォント(variable fonts )?ってやつだかららしい
これを修正するPRがあったんだけど、Steam以外ではバグらないってのでCloseされちゃってるってことでこの変更を自分の環境で適用する必要がありそう。
変更内容自体に関しては毎度毎度参考にさせていただいているdotfilesに丁度修正されたNoto fontのパッケージが書かれてたのでこれを参考に書く
ついでにpkgsにはオーバーレイって機能があるっぽいのでこれで既存のnoto-fonts-cjk-sans
とかを書き換えてみる
inputs.home-manager.lib.homeManagerConfiguration
とinputs.nixpkgs.lib.nixosSystem
にはnixpkgs.overlays
って同じ名前のフィールドがあるらしく、そこに関数を渡してあげれば良いだけっぽい
ってことで差分はこんな感じ
多分ちゃんと適用されてると思う...んだけど、Steamの表記は直らなかった
fc-list
から確認したけどちゃんと名前にVF
が付いてないので成功はしてるはず
これ以上情報も無ければやれることも無いので放置。前からずっと英語設定で使ってたので自分の名前以外は読めるから良しとする。ちなみにwqy_zenhei
を入れたりしても意味なかった
追記
なんかいつのまにか表示されるようになった。謎
Plasma6に挑戦
結論:ダメ
数日前にも試して、その時はWayland環境だとログインしてsddmから抜けたらsystemdのlogだけ出てplasma(kwin?)が起動しなかった。6にするならWaylandにしたいので一旦Plasma5で進めてたんだけどもう一度トライ
とりあえずwallpaper-engine-kde-pluginをqt6ブランチに変更してビルドしようとしたけど、Qt6が無いと言われて怒られ続けたので諦め。今回は先駆者も居ないっぽいので撤退
依存関係を参考にすべくAURを眺めながらやったんだけど、全部用意してもダメって言われたのでなんもわからん。もうちょい知見が溜まってから再チャレンジするとしよう(その前にHyprlandになってる可能性もある)
同様の理由でこっちも見送った(途中まで書いたので依存関係がどうにかなったらすぐ入れられるはず)
実機に導入する
ここまで丁寧に作り上げてきたnixファイル達を以てしてもイレギュラーは発生する
USBからのインストール作業を終えて準備しておいたファイルにhardware-configuration.nix
だけ移動させて、いざ
sudo nixos-rebuild switch --flake .#maindesk
と意気揚々にコマンドを実行した矢先に問題が発生した。Nvidia のPRIME機能が有効だからIBusを指定しろだのなんだの...なんですかそれは?
がんばってスマホで調べたところ、どうやらラップトップ向けにそういう設定があるらしい
そんなのミリも触ってないので困惑していたら、どうやらこいつのせいだったみたい
わからん設定をわからんまま放り込むのはやめた方が良い(戒め
ちゃんとこれのソースコード見たら有効化されてました
設定内容がぜんせんCommonじゃないというつっこみをしつつ、こいつの設定を消してついでにnvidiaの関連設定を行った。
ほぼ環境を再現することができた(このあとアイコンとか直した
セキュアブートを有効にする
Nixはどうやらlanzabooteってやつを使ってセキュアブートをやるのがメジャー(というかサポートされている唯一の方法?)らしい。実際今まで見てきたdotfileにもこいつがいた気がする。
とりあえずマニュアルの通りにやってみたが、マザボからSecureBootを有効にするとsystemd-bootが起動しなくなるという問題にぶつかり、まだまだ発展途上なこともあって同じような症状の報告や有力な情報は発見できなかった。そもそもドキュメントにあったSetup Mode
とやらを自身のマザボの設定から見つけることができなかったので、自分で生成した鍵を使って署名するってことが想定されていない可能性がある。
PreLoaderを使う方法の開拓
そもそもセキュアブートをやりたい動機として、セキュリティ面での意識の高さなどはなく、単に普段デュアルブートしたWindowsで遊ぶゲームにひっついてるマルウェアのご機嫌を取るために毎回マザボの設定を切り替えるのが面倒なだけなので、ArchLinux時代お世話になったPreLoaderをNixでも使ってみようと思う。
とりあえず先駆者が居ないか探したのだが、おもしろいことに検索にはヒットせず。Githubでもまさかの0だった(執筆時に検索し直したら自分だけ出てきて草)。ただやることに関してはArchLinuxと変わらんはずので、ArchWikiと睨めっこしながらnix式での再現を目指した。このタイミングでAURのPKGBUILDを読んでみたが、これぐらいシンプルなものなら読めたしそのままnix式に落とし込めるようになった。途中複数のソースを含めよう[1]としたり、圧縮されてないファイルを処理するときのnix式の書き方[2][3]を模索して時間を溶かしたが、0からの構築に成功した。1週間前はNix言語なんもわからん状態だったことを考えると成長を感じれてうれしい。
あとはArchWikiの通りにフォールバックの設定までをNix式に落し込んで完了。実際にセキュアブート環境下でPreLoaderが動作してハッシュの登録までできるようになった。
唯一の問題として、普通にsudo nixos-rebuild switch(or boot) --falke ...
したら以下のエラーが出て処理に失敗するようになった
Traceback (most recent call last):
File "/nix/store/0ky2fq2qv0qbgnaqfmc3mc0pb5vcpdnn-systemd-boot/bin/systemd-boot-builder", line 394, in <module>
main()
File "/nix/store/0ky2fq2qv0qbgnaqfmc3mc0pb5vcpdnn-systemd-boot/bin/systemd-boot-builder", line 377, in main
install_bootloader(args)
File "/nix/store/0ky2fq2qv0qbgnaqfmc3mc0pb5vcpdnn-systemd-boot/bin/systemd-boot-builder", line 305, in install_bootloader
raise Exception("could not find any previously installed systemd-boot")
Exception: could not find any previously installed systemd-boot
エラー内容的に前回のsystemd-bootの状態を探そうとして、改変されてるから失敗したって感じかな?ぶっちゃけ根本的な原因は分かってない。とりあえず問題の箇所はここだったあったのでやってみる。
ってことで作成したパッチがこれ
これを作成するにあたってエラーの根本的な原因を調査したところ、どうやらbootctl status
で出力される情報からsystemd-bootのバージョンを抽出する正規表現が単一のefiファイルしかない時のみを想定されていたせいであった。
つまりは
ESP: /boot (/dev/disk/by-partuuid/9b39b4c4-c48b-4ebf-bfea-a56b2395b7e0)
File: └─/EFI/systemd/systemd-bootx64.efi (systemd-boot 255.2)
ってのが想定されていたところが、自分の環境では
File: ├─/EFI/systemd/HashTool.efi
├─/EFI/systemd/PreLoader.efi
├─/EFI/systemd/systemd-bootx64.efi (systemd-boot 255.2)
├─/EFI/systemd/loader.efi (systemd-boot 255.2)
└─/EFI/BOOT/BOOTx64.EFI
みたいな感じになっており、3番目と4番目にバージョンが記載されている。これのせいで精査が失敗していたみたい。
作成したパッチを自身に適用して従来のエラーが出ないことを確認。ってことでPreLoaderを使った完璧なセキュアブート環境が用意できた
今回作成したパッチはできるなら本流にPR送りたいけど、コメント的にあの正規表現は生成されたやつっぽいので、やるなら日を改めて大元の処理を直すところからやろうと思う。ってかなんならissue作るところからやるべきかも?なんて名前で出しゃええんや。英語なんもわからん
とりあえずissue投下した。伝わるといいな
rust-roverを動かす
適当なプロジェクト読み込んだら普通に怒られたので、こいつを動かすためのflake.nix作りをやった
試行錯誤の途中で見かけたプロジェクト達
- 昔使ってたやつ: https://github.com/nix-community/fenix
- 環境構築時にいれてたやつ: https://github.com/oxalica/rust-overlay
- cargo.lockから自動でビルド環境を作るやつ(差分に必要なもの以外を全部キャッシュするので2回目以降のビルドがめちゃ早い): https://github.com/nix-community/crate2nix
- direnvとかと連携するやつ: https://github.com/numtide/devshell?tab=readme-ov-file
ちなみに全部rust-roverにとっては無意味だった。いらない子だね
動作を理解する
そもそもの話として、rust-roverはrustupと密接に連携しており、こいつがあること前提な動き方をする。
ただ、今まで見てきた記事はNixの思想的にrustupを導入することをおすすめしない人ばっかりだったので自分もその気だった。が、こいつを動かすために必要なのはnixの思想ではなくrustupのエコシステムである。
ってことでまず自身の環境からrust-overlayを消してrustupを入れた
これで8割は動いた。後はプロジェクトに応じて以下のような最小限のdevelop環境を構築すればいい
{
description = "Rust-Nix";
inputs = {
nixpkgs.url = "github:nixos/nixpkgs/nixpkgs-unstable";
utils.url = "github:numtide/flake-utils";
};
outputs = { nixpkgs, flake-utils, ... }: flake-utils.lib.eachDefaultSystem (system:
let
pkgs = import nixpkgs {
inherit system;
};
in with pkgs; rec {
devShells.default = mkShell {
nativeBuildInputs = [ pkg-config ];
buildInputs = [ openssl ];
};
});
}
まあぶっちゃけこのレベルなら一々ディレクトリに移動してnix develop
してrust-rover .
ってコマンドからやるのが面倒くさいだけなのでopensslとpkg-configを実機に入れても良い気がする。Runnerから起動したいので自分は入れておくことにした入れたけどダメだったので上で書いた方法を使う必要があるかもしれない。不便なのでそのうちどうにかしたい
direnvとの連携
上記の問題はrust-roverだけでなくWebStormでも発生した。corepack経由でpnpmを動かそうとしたところ、corepack enable
でのリンク作成がNixによって阻まれ、その結果WebStormがpnpmを認識できなかった。
とりあえずNixでcorepackをどのように利用すれば良いかを調べたところ、このような記事を発見した
上の記事ではnix shellを用いていたが、とりあえず似た感じでflakeに落とし込んでみた
{
description = "pnpm-Nix";
inputs = {
nixpkgs.url = "github:nixos/nixpkgs/nixpkgs-unstable";
utils.url = "github:numtide/flake-utils";
};
outputs = { nixpkgs, flake-utils, ... }: flake-utils.lib.eachDefaultSystem (system:
let
pkgs = import nixpkgs {
inherit system;
};
# https://zenn.dev/eiel/articles/15103684351cb8
corepack = with pkgs; stdenv.mkDerivation {
name = "corepack";
buildInputs = [ pkgs.nodejs-slim ];
phases = [ "installPhase" ];
installPhase = ''
mkdir -p $out/bin
corepack enable --install-directory=$out/bin
'';
};
in with pkgs; rec {
devShells.default = mkShell {
packages = [ corepack ];
};
});
}
これによってnix develop
した環境からwebstormを起動すればとりあえず認識してくれるようになった。
ただこれだとrust-roverの二の舞である。
ってことで解決策を探したところ、どうやらdirenvで解決できるらしいってことがわかった
このタイミングでnix-direnvってリポジトリを発見し、flakeとの連携テンプレートに出会えた
同じように.envrc
を設定し、コンソール上からdirenv allow
を実行して動作を確認。
WebStormにはプラグインを導入したら、ちゃんとpnpmが認識されるようになった
home-managerをnixosの設定と統合する
今まではsudo nixos-rebuild switch
とhome-manager switch
を個別に実行していたが、わざわざ二回実行するのが手間なので統合する。
余談:これでnixosのロールバック対象に含まれるようになる...?確証は無いがこれまでの手法よりは可能性がありそう
とりあえず最小限の例はここに買いてある
home-managerのmoduleを追加する方法が公式には書かれていないが、以下のように書くことで追加できる最終的な差分はこんな感じに
気付いた不便ポイント
home-managerの設定に渡せる追加の引数がユーザー別に指定できない
これのせいでマルチユーザーを定義することができない。後に困りそうだけど今のところ環境ごとに1ユーザーしか設定してないので良しとすることに
参考:
教訓:usernameをミスると詰む
users.users.${username}
をインストール時に設定したものから変えるとログインできるユーザーが無くなって詰むという話
ノートPCに導入しようとしたらこれに遭遇して再度メディアからのインストールをする羽目になった
焦りすぎてFIxになってる修正コミット
おそらくパスワードのハッシュまで設定に盛り込んでおけば復旧できる可能性があると思うが、変わってしまった後からはどうしようもなくなるので詰む
ちなみにロールバックも意味ない。最初期のものまで戻ってもダメだった。メディアからchrootして直そうとしたけどエラーでて再構築ができなかった。謎
今思えばrootなら入れたかもしれない。まあ後の祭り
Hyprlandを試す
とりあえずVMでやってみる。おためしなので以下を参考に一旦同じ環境を用意してみようとした
VMの場合ハードウェアアクセラレーションを有効化しないとログインしても戻される状態に陥いったため注意
とりあえず起動を確認したけど、weztermもGPUアクセラレーションのせいか起動しない...?一旦放置
WIP(進捗があれば書く)
複数のユーザーが存在する環境をサポートする
Linuxでマルチユーザー使ってないこと自体目を疑われそうな事案であるが、実際今までの構造では1つのNixOS環境に複数ユーザーの設定を記述することが困難であった。
理由としては簡単で、nixosのspecialArgs
とhome-managerのextraSpecialArgs
にusername
を入れ、各地でそれを利用していたためである。マルチユーザーを管理する場合はこのどちらも使用しないように全体へ変更を加えないとならない。
ということで変更したのが以下のコミットである
NixOS側
specialArgs
にはusernames
(全てのユーザー名のリスト)のみを渡すように変更し、username
を要求するような設定はユーザーを定義する際に一緒に設定できるよう工夫を加えた。現在は以下のように設定ができるようになった
ついでにありきたりな設定はデフォルト値を持つように設定しておいた
85行目のコードで上の個別の設定を取得し、全てをnixosSystem
のmodules
に渡している
Home Manager側
home-managerでは末端の設定などでusernameを使用する可能性があるため、args以外の方法でusernameを取得する方法を調べた。imports
構文にて参照した先では、参照元までで設定されている内容がconfig
という引数として受け取れるらしい。今までで{ config, ...}: {...}
のように引数にconfigを使っている人をあまり見て来なかったため知らなかったので助かった。
困っていたポイントも解消されたので以下のように設定を行った
confPath
にて指定したファイルからは{ config, ...} : { .... = config.home.username; }
のようにしてユーザー名を取得できるようになる
今回の設定にあたり、以下のような引数が爆誕した
この引数を良い感じに変換して利用するためNix言語にて利用可能な関数やReplによるテスト、VMから実行を繰り返して丁寧に検証を行った
filter
map
concatMap
optional
optionals
foldl
など、自身の需要に合った関数を見つけるまでが大変だった...
以下は調べる際にお世話になったサイト
Linuxでソフトウェアを利用するという感覚の変化
ArchiLinuxを使ってた時からかなり自分の中で変わった部分。今まで(正確にはこのコメントを書くまで)はソフトウェアを起動して利用するという行為はインストールしてPCに導入してから使う物だし、使えるソフト=インストールしてるソフトという認識であった。
だが、Nixパッケージマネージャの場合はこの辺の理解がかなり変化する。まずインストールされているかどうかに関係なくnix run nixpkgs#<任意のパッケージ,neofetchとか>
[1]で使いたいソフトをその場で使うことができる。nix shell nixpkgs#<任意のパッケージ1> nixpkgs#<任意のパッケージ2>
と入力した後であれば、パッケージ内のソフトどうしの組み合わせ(何かのjson出力をjqで整形とか)も動作する。インストールしている訳ではないため、runした後やshellの後exit
すればそのソフトは使えなくなる。
Nixにおいてパッケージを使うというのは、nixpkgsから対象のパッケージの定義を取得し、それより求められるハッシュ値を元にビルドキャッシュ(成果物)を取得した後、一時的にPathを通したりしているだけに過ぎないということが分かる。
NixOSに導入するパッケージとして定義したものは、その一時的なPathの設定がOS起動時〜終了時までに延長されているだけであり、このような仕組みのお陰でNisOSの世代システムは成り立っていると理解できる。
インストール後の試行錯誤で大量に出来上がった世代たち[2]
最初の方にも述べたが、この直感を手に入れたのはDirenvのflake連携を使い初めたあたりである。
Direnvはその名の通りenvをその定義があるディレクトリに入った段階で適用するためのソフトであり、今のシェル環境をflakeによって定義されたdevelop環境にDirenvと連携して自動で変えることができる。
これはまさしくenvのPath(を含むenv達)を通しているだけという理解で全てが説明できてしまう。この単純な仕組みのおかげで、有名なIDEAやエディタのNix Flake専用の対応を期待することなく、環境構築で既に馴染みのあるDirenv連携を使うだけでNixOS自体に何かの依存関係やツールチェインを入れる必要がなくなる。
ここまでで、ソフトを使うということは、対象のソフトをPathに通すことが本質であるという理解になった。
ちなみに「結局DLしてインストールはしてるし、ソフトはPCに入ってるだろ」と思うかもしれないが、nix-collect-garbage
した瞬間に今使ってないソフトたちは消える。不要なものは自動で消せるというだけでも魅力的ではないだろうか
Hyprlandにあごがれて
unix pornとかを眺めてるとタイル型ウィンドウマネージャが大変うらやましく感じる(あと軽そう)
実際今のKDE5に少しずつガタが来ててちょっとしたところでフラストレーションが溜ってたので乗り換えのための環境を作っていく。
KDE5不満点
- スクリーンロックが入ると画面がパスワード入力を30秒ほど受け付けない
- たまに画面更新がされない(IDEAのnew fileの名前入力欄がそれがあるであろう場所をクリックするまで見えないとかが起きる)
- 新規ウィンドウの表示が入ると一瞬画面が固まる(連打するとやばい)
などなど
TODOリストは以下
現状の構成
- WM: Hyprland
- Bar: Hyprpanel
- Launcher: rofi
- Widget: eww
- WallPaper: swww
- LockScreen: HyprLock
- FileManager: natilus(GNOME)
- ColorPicker: Hyprpicker + gcolor3
- ScreenShot&edit: grimblast + swappy + zenity
VMのチラつきのせいで右上消えちゃった...はやくメインPCに入れたい
あまりにHypr系のソフトが強い。ステータスバーとかeww→waybar→hyprpanelの流れで落ち着いた。ぶっちゃけ設定のしやすさ的にこれぐらいで良いんだよ感ある。
本当はKDEのDolphin/Gwenviewが使いたかったが、kvantum+qtctでのテーマ設定がいくらやっても動かないので諦め
抱えてる問題
- VM環境でめちゃくちゃにチラつく
ハードウェアアクセラレーションを有効にしてないせいと思われる。それはそうとしてVirtManagerからGPUパススルー無しでハードウェアアクセラレーション有効にする方法って無い...? qemuのコマンド直だといけそうな記事は見たけど自分でVM管理したくないので気が引けてやってない。 -
Kvantumのテーマが適用されない
本当に謎。途中でインストール済みのdolphinは駄目なのにnix run nixpkgs#dolphin
して起動したものはいけるとか起きて本当に頭をかかえた←どうやらコマンドラインからQt5向けのDolphinを起動するとうまくテーマが適用されて、rofihyprlandのexec経由だと駄目らしい。なんで????hyprlandのenvにスクリーンショット
nix run nixpkgs#dolphin
←→インストールしてるやつ"QT_QPA_PLATFORMTHEME,qt5ct"``"QT_STYLE_OVERRIDE,kvantum"
を入れてとりあえず解決した。もっとスタイリッシュな方法が欲しかった... -
fcitx5-skkが動かない
libskkの問題だったので更新待ち https://github.com/NixOS/nixpkgs/pull/354218 - ewwのウィジェットが起動直後にどっかいく
メインPCに移行してから対処予定。原因は謎