I’m frustrated that such sweeping changes that can fail silently are not made without any notices at eval time, or rolled out gradually with deprecation notices, but just breaks silently between updates.
Thanks for letting us know! I was using killall SCREEN_LOCK_OF_YOUR_CHOICE quite a lot the last days 
FYI: I am using i3lock-color, and I had to activate security.pam.services.i3lock.enable (not security.pam.services.i3lock-color.enable).
1 Like
thanks for pointing out, perhaps that’s why gnome keyring no longer unlocks my ssh keys 
EDIT: somehow programs.gnupg.agent.enableSSHSupport = true; no longer sets $SSH_AUTH_SOCK
With nixos/system-path: convert environment.systemPackages to an attrset by r-vdp · Pull Request #255086 · NixOS/nixpkgs · GitHub we could easily alert when people install those programs through environment.systemPackages and something similar can be done with users.users.<name>.packages but I am afraid it is not possible to do that when home-manager is used.
PS: please keep this thread on topic now 
3 Likes
I guess since this somehow became its own thread, the problem isn’t necessarily just that a bunch of lockscreens were broke, it’s that without warning, pam behavior was changed for all nixpkgs-unstable (nixos-unstable?) users without any deprecation notice or warnings. The assumption that may have caused this could be that “all users will be using the module for the given package”.
That assumption however is deeply flawed. Often, it is the case that rolling your own module is preferable, so ultimately this boils down to a more diligent approach to breaking changes in general, that seems specially lacking for the unstable branches (and I speculate specially from stable users, that will do the actual testing when it hits either release or backport).
(here is the specific attempt at gating breakage that was present only in the module)
i3lock.enable = lib.mkDefault config.programs.i3lock.enable;
i3lock-color.enable = lib.mkDefault config.programs.i3lock.enable;
vlock.enable = lib.mkDefault config.console.enable;
xlock.enable = lib.mkDefault config.services.xserver.enable;
xscreensaver.enable = lib.mkDefault config.services.xscreensaver.enable;
Also this is absolutely possible, since home manager uses the package from nixpkgs, one could e.g. have an optional argument that defaults to false in the lockscreen packages, that then gets set by the default package option in the NixOS module to true. That could then conditionally warn when false. There are probably also other more elegant options, but it’s absolutely feasible.
4 Likes
By the way, if this happens in the future, loginctl unlock-session is a lot nicer than kill – especially for architectures like xsecurelock that try to avoid having a process kill unlock the screen.
5 Likes
Does this work via PAM, or does this require inclusion of this specific functionality in the locking application?
Can you outline how such a warning would work in a little more detail? I am having trouble understanding your idea end to end.
Also, I think the general assumption is that the modules provided by NixOS are used and like with this breaking change, users are generally on their own when running their own modules as it is very difficult and often not possible to detect when a package is not used in the module.
I also would go so far to not recommend running complete custom modules, unless users absolutely know what they are doing and rather recommend to build options based on top the existing. I’ve done that many times, that I build on top of a generic settings option more specific usecases.
2 Likes
I also wouldn’t go as far as to recommend people to use their own modules, but it goes a step further, I just don’t recommend people to use NixOS at all because of these types of changes that are just put out there without any other warning than this thread… I do think these types of changes can be for the better in the bigger NixOS picture, but the way nix has been going about it is just a deep red flag for industrial adoption because of this breakage without warning. And it’s the reason I keep telling people that nix could be the best thing since sliced bread but it just isn’t at the time because there just doesn’t seem to be any form of regulation and I actually purpose using something else…
And I think that’s getting at the deeper underlying issues that nix has been having with governance. No one seems to be taking responsibility and/or accountability and it’s led us through so many bad instances of uproar and still we’re in a spot where is just issues like this existing and no one to uphold any sort of standard. I might not be the right person to guide this process but there doesn’t seem to be anyone with substantial stake in the project to be willing to. And there’s in my opinion the major problem with the nix project: there’s a lot of cool stuff happening around nix, and I mean very cool (has anyone seen GitHub - NuschtOS/NuschtOS for example) but the core keeps being unstable without any guarantees or guidance and noone can expect anything they do now to uphold in the future, one of the core guarantees or NixOS… I can keep up with the changes but I can’t expect anyone else to do the same and it’s been a frustration of mine for a couple of years now and we haven’t gotten a step closer it seems. That’s what frustrates me about nix, as a six year user now, more than anything else.
4 Likes
The guarantee is that you can use the same inputs and nix code and get the same config (to a point). No one could ever honestly claim you can use your config from today with a nixpkgs revision 6 years from now; there will be breaking changes, because software that comprises the OS and our knowledge changes, and nixpkgs changes accordingly.
In the meantime, if you don’t want breaking changes, that is what the stable channels have always been for; they should only break when you switch to the next stable.
10 Likes
I didn’t mean to say that I was expecting everything to be stable for over 6 years, and I hope the mention of these breaking changes being for the better would have gotten that message across, because I do deeply appreciate everyone’s work going into nix(os) and the ecosystem. My post may have come across very negative now that I look back at it and that’s not the message I intended. But it’s been a frustrating feeling I have been having around nix(os) as a somewhat longtime user that I’m not sure is actually being addressed even with the changes in governance structure. I do hope it will change for the better and am supporting the current changes, that may not have had the time yet to come to fruition, and am mostly hoping to add a perspective from a long time but not very vocal user of the ecosystem 
4 Likes
What specifically would you like me to expand on?
If industrial users want industrial guarantees they can put their money where their mouth is (I say as an industrial user of NixOS). I give nothing, I expect nothing in return other than the gift that is being offered.
4 Likes
The corpo I work for does give some money, as does many others, although I could indeed imagine this being less interesting as Nix (package manager) enshittification continues, but that is all somewhat tangential.
I’ve been talking to various people about mobilizing people into moving funding away from the foundation and more towards individual contributors (which IMO makes up the bulk of the nixpkgs workload, and rarely gets anything close to a fair share). Specially considering that some of the money goes to stuff like nice tropical vacations with barely anything to show for it… I’d much rather see those random anime avatar contributors that actually push bytes to nixpkgs get more of the pie, also because they don’t strike me as the types to go to these events. Likewise for the yuppie infested meetups, they can afford their own pizzas anyways.
8 Likes
How would we trigger a warning when the mentioned programs are used through standalone Home-Manager? So far I could only come up with hacky ideas like parsing the NixOS version from /etc/os-release in the home-manager script and if it is at least 25.05 and the pam file do not exist, a warning is printed.
The pam module was in a pretty bad state a few years ago. It wasn’t expandable and IIRC you need to work with lib.mkDefault a lot and could easily break everything. It got a lot of rework in the last year or so and due to the nature of its importance, every oversight can be fatal. That does pam files where enabled by default was a bad decision in afterthought. Fixing that is kinda hard, we can easily fix it from within the NixOS module system but not for external tools like home-manager. They silently relied on the bad default for years and you can’t blame them. It is all based on decision from the past we now need to work with.
If you would be on stable, you would read the changelog when doing the update and there it is written that this default changed. You wouldn’t use unstable in the industry if high stability is key. You also wouldn’t use Debian Testing in a production environment where stability is very important.
6 Likes
First off, I totally agree that breaking changes like this hurt the user experience around NixOS. But strictly speaking, Home Manager is a downstream project. By using Home Manager and otherwise relying on NixOS defaults, you are implicitly subscribing to breaking changes.
There is no elegant way to propagate system state to standalone setups of Home Manager, and while there are possibilities with HM’s NixOS module, that is something we would have to build into Home Manager ultimately.
The idea with using some package attribute that creates a warning by default can be misleading if users use nix run / nix shell / etc.
In my case, I was not affected by this issue, as I exclusively use my own NixOS modules to configure system state and Home Manager at the same time. (See my session-lock.nix module, hm is an alias that is defined here)
I think we should encourage users of Home Manager to adopt a similar pattern, as many of Home Manager’s modules rely on some kind of system state, like users being part of the video group for any of Wayland compositors to work.
2 Likes
I think in general, breaking changes are communicated quite well, thank you 
! In my opinion, this is a very peculiar case:
- Most people here (I expect) used a screen locker like a regular package (or probably via a Home Manager module).
- Installing a package makes that package available for use, and we also expect packages to work just “like so”.
- However, some packages don’t work “like so” because they need system files.
Now, how can we know when to install a package regularly (e.g., via environment.systemPackages), and when we should use a NixOS module that installs the package AND system-relevant files?
Tackling the question from another side: Many of us prefer to install packages used by the user alone only user-wide, not system-wide. How can we know when a package/Home-Manager module needs a system-wide NixOS module configuration?
Thanks!
5 Likes
Right now the answer is “you can’t”, because knowing this requires some level of awareness of what’s happening in nixpkgs (both in the packages and the NixOS modules) and some general Linux knowledge. But it’s a safe guess that anything involving PAM or really access control in general will require some system config. Also, I would suggest to search for a NixOS option first to see if it exists, and check the code to see if it does something crucial that you might need in your config, before fully relying on a user-only configuration.
In this case, it’s not necessarily true that you must use the upstream NixOS module; however, if you don’t use said module, you’d have to recreate in some fashion the work that the upstream module does. I’ve done so before with some modules that I found unsatisfactory, but I found keeping up with upstream nixpkgs to be time-consuming and rarely worthwhile. (The only times it made sense for me were when the upstream module was so unsatisfactory that I didn’t want to keep up with it.)
2 Likes
I don’t think we should assume that just because someone creates a new NixOS module everyone would switch to using it. I’ve been using xscreensaver with NixOS since ~2017, via systemPackages (as I assume everyone who used it did at the time). The xscreensaver module was first created much more recently in Nov 2023. I don’t remember if I saw it before the recent PAM change, but if I did I would have noted it didn’t do anything useful for me. It doesn’t even put xscreensaver in systemPackages, so I still need to do that myself, even now that I’ve enabled the new module.
I also wouldn’t say I’m using “my own module”. I’ve just been running xscreensaver from my ~/.xinitrc and xscreensaver-command -lock from my window manager keybindings same as on any other Linux distro or any other Unix-like OS.
FWIW, I was annoyed when xscreensaver would unlock after a nixpkgs update, but I also expect things to randomly break occasionally in nixos-unstable. I’d rather help debug problems sooner rather than all at once when a new release is getting close to ready. What annoyed me more in this case was that after digging in to it (expecting some package update to have broken things, as is usually the case), it turned out to have instead been an intentional breaking change. I do appreciate that there was an attempt to set reasonable defaults though.
Anyway, as far as reducing unexpected impact to other users in the next stable release, would it make sense to have the PAM defaults depend on system.stateVersion? That would avoid breaking existing systems even for folks using home-manager or user profiles.
Personally, as someone who manages the packages I want via systemPackages I’d be happy with a warning when xscreensaver is in systemPackages but the PAM configuration for it is disabled.
6 Likes