5 ms·

Once you figure it out you never have to figure it out again. And there is likely someone else who already figured out something as common as this so you could

Once you figure it out you never have to figure it out again. And there is likely someone else who already figured out something as common as this so you could just import their config.

jchw 3y ago
I love NixOS, but if you're a heavy Linux user the odds that you do something fairly unique in your personal setup gets very high. For me, to give you an example of just one little microcosm, I have probably the only combination of SwayWM, gnome-keyring and NixOS in the world that works the exact way mine does, and it took quite a while to land on it (and sometimes time to maintain it.) It's actually pretty simple and elegant now, but getting to where I am today felt anything but simple. Back when I first started (5 years ago,) drivers for my label printer were not available, and I stumbled around trying to figure out how to make a derivation for them. Ultimately I succeeded, but for a n00b it did feel pretty ridiculously hard to try to figure it out while not even having much of a background in pure FP languages less the oddity that is Nix. I never got around to adding it to Nixpkgs, but thankfully somebody else did. There is indeed solutions for a LOT of things. Is home manager worth the time? Not sure, I just use global configs instead of home dir configs for most things. There's multiple solutions for secrets but I have a few different Nix configuration repositories (for different sets of machines, not one for each machine; I only do this when it feels like it makes sense, like to keep servers for some org separate from my home machines) and not all of them have SOPS setup because while it works, bootstrapping it always has me guessing a little to make sure the way I'm setting it up actually makes sense. Flakes. They're good, but I started before everyone recommended them for everything. The switching cost of flakes was not huge, but nor was it trivial, as I had to adjust a lot of workflows for it. This kind of negates the "you never have to figure it out again" thing. On the contrary, NixOS is a moving and vastly complicated machine, and it indeed feels like things need to be re-figured out quite often. Rust dependency management in Nixpkgs is sure to change in the future: right now it can't handle all of the situations that Cargo can and often requires including a copy of the lockfile in the Nixpkgs tree which seems unideal. Worth it still? Yes, because I can throw my boot drive out the window and have a machine back up and running in like 10 minutes. All of my desktop machines are very consistent, because any configuration that matters to me goes into declarative and versioned configuration. The concept of "hosing" my OS doesn't exist anymore, and even if a workflow does break, I can trivially bisect it to figure out why. Nix tools are super complicated, but they are super powerful too. NixOS is Linux with superpowers. All of the cool stuff that open source could theoretically enable you to do, NixOS makes practical. But is it perfect? No. To this day, you will not find a derivation for plenty of very useful closed source software. No VMWare Workstation, IDA Pro, etc. AppImage binaries that run other AppImages don't work with appimage-run; though I have a workaround with Nix-LD that does work, I've never seen anyone else doing it, so I suspect not too many people do this. Most open source software is there, but it can be a bit hit or miss at times. You'll occasionally find places where missing dependencies or hardcoded paths in the upstream sources lead to subtly broken or suboptimal things. So if you only manage one machine with NixOS or you don't have a lot of time to invest upfront, or you have some use cases that are pathologically difficult to deal with, it's not always practical for everyone. I think if NixOS immediately sells someone, they're in. They'll get it. If not? Maybe in a couple more years. For me, it was on first sight.
- colordrops 3y ago
  All fair points, i was a bit hasty with my comment. Do you mind sharing your configs for gnome keyring with sway? I'm on sway and would love to use that.
  - jchw 3y ago
    Here's a simplified version of what I have now. let dbus-sway-environment = pkgs.writeShellScript "dbus-sway-environment.sh" '' ${pkgs.dbus.out}/bin/dbus-update-activation-environment --systemd DISPLAY WAYLAND_DISPLAY SWAYSOCK XDG_CURRENT_DESKTOP=sway ${pkgs.systemd.out}/bin/systemctl --user stop pipewire wireplumber xdg-desktop-portal xdg-desktop-portal-wlr ${pkgs.systemd.out}/bin/systemctl --user start pipewire wireplumber xdg-desktop-portal xdg-desktop-portal-wlr ''; in { services.gnome.gnome-keyring.enable = true; programs.sway.extraSessionCommands = '' export GNOME_KEYRING_CONTROL=/run/user/$UID/keyring export SSH_AUTH_SOCK=/run/user/$UID/keyring/ssh ''; etc."sway/config".text = '' # ... exec --no-startup-id ${dbus-sway-environment} exec --no-startup-id ${pkgs.dex.out}/bin/dex -a # ... ''; } I believe all of this is necessary. Now in my case, I have a bit more going on, but I think most of it is no longer needed. In the past it was significantly worse in my configuration :) How this works: 1. When you set services.gnome.gnome-keyring.enable, you get a few things. It sets security.pam.services.login.enableGnomeKeyring which gives you the PAM modules needed to start gnome-keyring and pass it the password on login. It also sets up some systemd and DBus services, which are necessary for gnome-keyring to work right. 2. GNOME_KEYRING_CONTROL and SSH_AUTH_SOCK need to be set for things to work right. I traced down where they're supposed to get set in GNOME, but I don't remember why it did not work for SwayWM: I think things happened in the wrong order. So, I set them manually. 3. `dbus-sway-environment` is supposed to ensure that the DBus environment for the user session is updated with the graphical environment. I found this necessary for a number of things to work correctly. It's possible this isn't needed for gnome-keyring anymore, but it might still be. In the past I was using custom systemd user services to run the components of gnome-keyring in which case it really was needed. 4. Finally, dex. `dex -a` launches XDG Autostart applications. This is handy because when you set services.gnome.gnome-keyring.enable, several XDG Autostart applications get installed for the different modules of gnome-keyring. SwayWM itself, being a WM, does not start autostart applications, and in fact, you may not even want this behavior in general, in which case you should adjust it to explicitly start just the few keyring applications you might want. In case you don't know, the reason why both PAM and dex start gnome-keyring is because when PAM starts gnome-keyring, it's running in a sort-of bootstrap mode: it basically just exists to store the password temporarily, then the autostart modules take over later. addendum: I set XDG_CURRENT_DESKTOP=sway explicitly because my XDG_CURRENT_DESKTOP is normally Unity to trick Electron and other apps into using libappindicator. It may not be necessary to do this anymore, but I haven't tried to see what happens.
aseipp 3y ago
Ehh, the reality is not quite that rose-tinted; in practice you have to put the elbow grease in, still. It's normally not quite as simple as porting someones config IME, because often it's wrapped up with other things they need. I've been a NixOS user and committer for 10 years. Things do in fact change and sometimes you have to learn a new thing, often. I'm dating myself here but I still remember when the Great Haskell Package overhaul happened, in an attempt to start vendoring Haskell packages directly from upstream Hackage; before that there was totally different infrastructure and every package was added manually. That broke a lot of things. Similarly, I only started using Flakes last year after years and years of development. Rust packaging is still pretty bad and non-granular, unless you use cargo-based generators which all have issues, and none are upstream. If you are using even more marginal languages, your experiences will probably range from bad to worse. NixOS is constant evolving and things do get deprecated and changed. You do have to learn new things. What you don't have to deal with as often is just, things randomly breaking. And with Flakes you don't have to deal with ambient Nixpkgs changes. I have shell scripts using nix-shell I haven't had to touch in years, despite incompatible changes in the tools used by the script. I still have a walled off NixOS machine running a 15.03pre-release, IIRC. I could probably upgrade it but the software on it isn't going to break. I suspect the disk will fail first (which is fine for this machine.) I think the best analogy is this: tools like Nix, Guix etc let you move mountains as an individual. That's impressive. It still requires you to get your hands dirty and actually push the thing, which is still work.

Once you figure it out you never have to figure it out again. And there is likely someone else who already figured out something as common as this so you could just import their config.

jchw 3y ago

I love NixOS, but if you're a heavy Linux user the odds that you do something fairly unique in your personal setup gets very high. For me, to give you an example of just one little microcosm, I have probably the only combination of SwayWM, gnome-keyring and NixOS in the world that works the exact way mine does, and it took quite a while to land on it (and sometimes time to maintain it.) It's actually pretty simple and elegant now, but getting to where I am today felt anything but simple. Back when I first started (5 years ago,) drivers for my label printer were not available, and I stumbled around trying to figure out how to make a derivation for them. Ultimately I succeeded, but for a n00b it did feel pretty ridiculously hard to try to figure it out while not even having much of a background in pure FP languages less the oddity that is Nix. I never got around to adding it to Nixpkgs, but thankfully somebody else did. There is indeed solutions for a LOT of things. Is home manager worth the time? Not sure, I just use global configs instead of home dir configs for most things. There's multiple solutions for secrets but I have a few different Nix configuration repositories (for different sets of machines, not one for each machine; I only do this when it feels like it makes sense, like to keep servers for some org separate from my home machines) and not all of them have SOPS setup because while it works, bootstrapping it always has me guessing a little to make sure the way I'm setting it up actually makes sense. Flakes. They're good, but I started before everyone recommended them for everything. The switching cost of flakes was not huge, but nor was it trivial, as I had to adjust a lot of workflows for it. This kind of negates the "you never have to figure it out again" thing. On the contrary, NixOS is a moving and vastly complicated machine, and it indeed feels like things need to be re-figured out quite often. Rust dependency management in Nixpkgs is sure to change in the future: right now it can't handle all of the situations that Cargo can and often requires including a copy of the lockfile in the Nixpkgs tree which seems unideal. Worth it still? Yes, because I can throw my boot drive out the window and have a machine back up and running in like 10 minutes. All of my desktop machines are very consistent, because any configuration that matters to me goes into declarative and versioned configuration. The concept of "hosing" my OS doesn't exist anymore, and even if a workflow does break, I can trivially bisect it to figure out why. Nix tools are super complicated, but they are super powerful too. NixOS is Linux with superpowers. All of the cool stuff that open source could theoretically enable you to do, NixOS makes practical. But is it perfect? No. To this day, you will not find a derivation for plenty of very useful closed source software. No VMWare Workstation, IDA Pro, etc. AppImage binaries that run other AppImages don't work with appimage-run; though I have a workaround with Nix-LD that does work, I've never seen anyone else doing it, so I suspect not too many people do this. Most open source software is there, but it can be a bit hit or miss at times. You'll occasionally find places where missing dependencies or hardcoded paths in the upstream sources lead to subtly broken or suboptimal things. So if you only manage one machine with NixOS or you don't have a lot of time to invest upfront, or you have some use cases that are pathologically difficult to deal with, it's not always practical for everyone. I think if NixOS immediately sells someone, they're in. They'll get it. If not? Maybe in a couple more years. For me, it was on first sight.

colordrops 3y ago
All fair points, i was a bit hasty with my comment. Do you mind sharing your configs for gnome keyring with sway? I'm on sway and would love to use that.
- jchw 3y ago
  Here's a simplified version of what I have now. let dbus-sway-environment = pkgs.writeShellScript "dbus-sway-environment.sh" '' ${pkgs.dbus.out}/bin/dbus-update-activation-environment --systemd DISPLAY WAYLAND_DISPLAY SWAYSOCK XDG_CURRENT_DESKTOP=sway ${pkgs.systemd.out}/bin/systemctl --user stop pipewire wireplumber xdg-desktop-portal xdg-desktop-portal-wlr ${pkgs.systemd.out}/bin/systemctl --user start pipewire wireplumber xdg-desktop-portal xdg-desktop-portal-wlr ''; in { services.gnome.gnome-keyring.enable = true; programs.sway.extraSessionCommands = '' export GNOME_KEYRING_CONTROL=/run/user/$UID/keyring export SSH_AUTH_SOCK=/run/user/$UID/keyring/ssh ''; etc."sway/config".text = '' # ... exec --no-startup-id ${dbus-sway-environment} exec --no-startup-id ${pkgs.dex.out}/bin/dex -a # ... ''; } I believe all of this is necessary. Now in my case, I have a bit more going on, but I think most of it is no longer needed. In the past it was significantly worse in my configuration :) How this works: 1. When you set services.gnome.gnome-keyring.enable, you get a few things. It sets security.pam.services.login.enableGnomeKeyring which gives you the PAM modules needed to start gnome-keyring and pass it the password on login. It also sets up some systemd and DBus services, which are necessary for gnome-keyring to work right. 2. GNOME_KEYRING_CONTROL and SSH_AUTH_SOCK need to be set for things to work right. I traced down where they're supposed to get set in GNOME, but I don't remember why it did not work for SwayWM: I think things happened in the wrong order. So, I set them manually. 3. `dbus-sway-environment` is supposed to ensure that the DBus environment for the user session is updated with the graphical environment. I found this necessary for a number of things to work correctly. It's possible this isn't needed for gnome-keyring anymore, but it might still be. In the past I was using custom systemd user services to run the components of gnome-keyring in which case it really was needed. 4. Finally, dex. `dex -a` launches XDG Autostart applications. This is handy because when you set services.gnome.gnome-keyring.enable, several XDG Autostart applications get installed for the different modules of gnome-keyring. SwayWM itself, being a WM, does not start autostart applications, and in fact, you may not even want this behavior in general, in which case you should adjust it to explicitly start just the few keyring applications you might want. In case you don't know, the reason why both PAM and dex start gnome-keyring is because when PAM starts gnome-keyring, it's running in a sort-of bootstrap mode: it basically just exists to store the password temporarily, then the autostart modules take over later. addendum: I set XDG_CURRENT_DESKTOP=sway explicitly because my XDG_CURRENT_DESKTOP is normally Unity to trick Electron and other apps into using libappindicator. It may not be necessary to do this anymore, but I haven't tried to see what happens.

aseipp 3y ago

Ehh, the reality is not quite that rose-tinted; in practice you have to put the elbow grease in, still. It's normally not quite as simple as porting someones config IME, because often it's wrapped up with other things they need. I've been a NixOS user and committer for 10 years. Things do in fact change and sometimes you have to learn a new thing, often. I'm dating myself here but I still remember when the Great Haskell Package overhaul happened, in an attempt to start vendoring Haskell packages directly from upstream Hackage; before that there was totally different infrastructure and every package was added manually. That broke a lot of things. Similarly, I only started using Flakes last year after years and years of development. Rust packaging is still pretty bad and non-granular, unless you use cargo-based generators which all have issues, and none are upstream. If you are using even more marginal languages, your experiences will probably range from bad to worse. NixOS is constant evolving and things do get deprecated and changed. You do have to learn new things. What you don't have to deal with as often is just, things randomly breaking. And with Flakes you don't have to deal with ambient Nixpkgs changes. I have shell scripts using nix-shell I haven't had to touch in years, despite incompatible changes in the tools used by the script. I still have a walled off NixOS machine running a 15.03pre-release, IIRC. I could probably upgrade it but the software on it isn't going to break. I suspect the disk will fail first (which is fine for this machine.) I think the best analogy is this: tools like Nix, Guix etc let you move mountains as an individual. That's impressive. It still requires you to get your hands dirty and actually push the thing, which is still work.