‘search’ is currently showing the 23.11 as deprecated. Does anyone know how long this will continue to be available for? (Personally I am hoping it will stay that way for a while. 
Upgrades don’t happen over-night for me and I know 22.11 disappeared from search before I had upgraded and whilst I was still supporting 22.11.)
Is there a way to request this? Does it hurt anyone to leave the old version showing as deprecated, say till the next version comes out? Just a humble request.
I don’t know the specific date but I wouldn’t expect it to be around longer than 23.11 is supported. So sometime around the beginning of July.
However the CLI tools still work and man configuration.nix lists all available options.
The 23.11 “Tapir” release is now officially deprecated, and will reach its end-of-life and stop receiving security updates after 2024-06-30. Please schedule your upgrades accordingly.
The length of 23.11 support was also announced with 23.11 release already, as usual. But the lengths are predictable. We have 6 months release period, 1 month overlap of support.
How does the showing help? I thought the point of stable is backporting (security) fixes and making binaries for that. It’s nontrivial amount of work, both for infra and for humans.
@Sandro, thanks! Reading back I think my question could have been clearer. I was only referring to the search function remaining available, although I think you effectively answered that. I am assuming it will disappear at the same time as support ends. 
@vcunat thanks! I knew about the 6 month cycle but I hadn’t ‘discovered’ the 1 month overlap of support. I should have read up on this by now to discover the release and support cycle!
So, searching now, I can find references to the one month of support like in the announcement ‘This release will receive bugfixes and security updates for seven months (up until 2024-12-31).’ and in all the release notes. Wiki - Channel Branches only refers to releases every six months and RFC080 also only refers to the 6 monthly release schedule. I haven’t found much else on what happens once a release has moved out of ‘stable’ in general terms, like the updating of ‘search’.
Regarding ‘showing the search’, in my naivety I assume that the search content for 23.11 doesn’t need to change and is already what it is. Showing it as deprecated (and no longer supported) tells me it is in the state it was when ‘stable’ swapped to the next release.
In attempting to answer to ‘How does the showing help?’, I can only offer my personal point of view and say doing updates while keeping everything stable takes (me) testing and time. I find ‘search’ a very useful reference - it almost like the ‘command reference’ for a language. Knowing what the ‘syntax’ was vs what the ‘syntax’ is now I find quite useful but that maybe relevant to my experience level.
I understand that the world we now all live in moves forward endlessly. There is no question that the great efforts of the community are and should be focused here. A good experience for the users also seems important (to me at least) and removing the references the people who support them use in just 4 weeks seems like it could be open for discussion.
Right, I get that the search.nixos.org could behave more like https://status.nixos.org – at least visually that would seem OK to me (no idea how it works inside really, but I don’t expect it would be hard).
Ah, I haven’t thought of that. We could adopt the same terminology (rolling, stable, deprecated, end-of-life) on nix.dev, since we’re half-way there already: Nix reference manual — nix.dev documentation
Sadly, 23.11 has gone from search. 
I presume the search data is stored in a repo somewhere. I wonder if I can clone an offline copy for each version so I can decide when I have completed my upgrades?
You can use nix search if you really need search functionality for packages, and man configuration.nix for options.
Yes, thanks, this was mentioned before. I have looked at man configuration.nix which is quite useful. It doesn’t really help with packages though.
I tried your suggestions of nix search looking for the package ‘fd’ for example. I don’t use flakes (yet) as they are still don’t seem to be the ‘official’ way to go 
and stability, predictability and reliability are important to me so I sit behind the curve!
[fsbof@testclient2:~]$ nix search fd
error: experimental Nix feature 'nix-command' is disabled; use '--extra-experimental-features nix-command' to override
[fsbof@testclient2:~]$ nix --extra-experimental-features nix-command search fd
error: experimental Nix feature 'flakes' is disabled; use '--extra-experimental-features flakes' to override
[fsbof@testclient2:~]$ nix --extra-experimental-features nix-command --extra-experimental-features flakes search fd
error: cannot find flake 'flake:fd' in the flake registries
The invocation would be nix search nixpkgs fd (or as you wish, replacing nixpkgs with the applicable flake to search in). See nix search - Nix Reference Manual or man nix3-search.
Though, be forewarned that a two-letter search string will return a large list of results.
Thanks for the pointer, but I’m not sure nix search is the answer for me.
For example I know that nextcloud28 is available in 24.05 and unstable.
[fsbof@testclient2:~]$ nix --extra-experimental-features nix-command --extra-experimental-features flakes search nixpkgs linux.nextcloud28
* legacyPackages.x86_64-linux.nextcloud28 (28.0.7)
Sharing solution for files, calendars, contacts and more
Searching for nextcloud27 though which is available in 24.05 but not in unstable I get the following which suggests that I am by default searching in unstable rather than the channel that I am using on this client. Odd…
[fsbof@testclient2:~]$ nix --extra-experimental-features nix-command --extra-experimental-features flakes search nixpkgs linux.nextcloud27
error: no results for the given search term(s)!
Trying to force then channel seems to work, but gets messy and slow when it can’t find what I am looking for.
[fsbof@testclient2:~]$ nix --extra-experimental-features nix-command --extra-experimental-features flakes search github:NixOS/nixpkgs/nixos-24.05 linux.nextcloud27
* legacyPackages.x86_64-linux.nextcloud27 (27.1.11)
Sharing solution for files, calendars, contacts and more
trace: warning: writeReferencesToFile is deprecated in favour of writeClosure
[fsbof@testclient2:~]$ nix --extra-experimental-features nix-command --extra-experimental-features flakes search github:NixOS/nixpkgs/nixos-unstable linux.nextcloud27
trace: warning: cudaPackages.autoAddDriverRunpath is deprecated, use pkgs.autoAddDriverRunpath instead
trace: warning: cudaPackages.autoAddOpenGLRunpathHook is deprecated, use pkgs.autoAddDriverRunpathHook instead
trace: warning: cudaPackages.autoFixElfFiles is deprecated, use pkgs.autoFixElfFiles instead
trace: warning: cudaPackages.autoAddDriverRunpath is deprecated, use pkgs.autoAddDriverRunpath instead
trace: warning: cudaPackages.autoAddOpenGLRunpathHook is deprecated, use
<snip lots of similar errors>
error: interrupted by the user
Then it doesn’t seem to provide all the additional information about the package provided by the web search.
Yes, nixpkgs will refer to nixpkgs-unstable (by default). You’d have to specify the branch explicitly if you want something else.
What information are you looking for in search?
Thanks, I personally use search all the time, again probably because there is so much to learn here!
For Packages
For example USBIP 6.7 was available in NixOS 23.11. I don’t know where it has gone or why but I still having a running instance. The packages name for this was linuxKernel.packages.linux_6_7.usbip from memory.
For Options
If I hadn’t gone against policy to backport the fix to 23.11 despite its deprecation, there would be an unauthenticated remote code execution as root vulnerability in 23.11’s version of OpenSSH that people are actively trying to figure out ways to exploit. If the disclosure had happened a month later, a fix might not have been backported at all.
NixOS just doesn’t have the maintainer resources to keep old versions safe to run. If you can’t make plans to upgrade during the one month support overlap it might be a good idea to consider a distribution that has the resources to try and maintain LTS releases. It’s not just about shiny new software, but a matter of getting critical security fixes.
I understand that you might be using it in contexts where security isn’t a concern, though, and as a software archaeology enjoyer it’d be hypocritical of me to suggest that there’s no circumstance in which using an old version is justifiable; if it works for you, that’s great. I just think it’d be a bad idea for the project to offer resources that suggest that running unsupported versions is in any way advisable because of that.
Firstly thank-you, not only for actually doing the work but for your thoughtful feedback. I hope you can entertain discussion on this knowing I have no expectations and am perfectly happy with what I get. I just ask questions to help me learn.
So question one from someone who still has some, getting less by the day, versions of 23.11 running - where should I be watching/following to get notified of that type of update?
I presume being involved in some kind of ‘auto-update’ process would also cover this, although having had too many experiences of automatic updates breaking critical services when they are needed most, sometimes I think these can be as bad as the bugs they are supposedly protecting us against. IMHO computers are a tool and many users have deadlines that automatically doing anything doesn’t acknowledge. There is an accounting software company that recently rolled out critical updates over year-end, preventing accountants and bookkeepers getting reports - doh. I am moving desktop users away from the big two OS’s to linux distributions due to forced automatic upgrades and in the search of stability and predictability. I have a human process for managing updates that is admittedly slow but getting faster, but I also work in layers and try not to shy away from making the risk decisions as tough as that can be with no wins for getting it wrong. Question two is not really a question but an acknowledgement that I at least need to be aware of what the automatic update options are. Do you have any recommendations on guides for doing updates that examine risk, consequences and method. The ability to roll NixOS back is awesome, but it isn’t perfect if the ‘home’ has been upgraded. I found this out the hard way but there were no warnings. Experience is wonderful!
I am hoping to get myself into a position where I can contribute. It is unlikely I will ever become a ‘maintainer’ but I am sure there will be other ways I can support NixOS. I recognise the efforts of so many but there is so much to learn. I personally don’t expect anything open-source to be any particular way. I view it is my responsibility to test as best as I am able and understand what I am using. See my comments about predictability and risk above. I approach this understanding there is no one to (proverbially) ‘throw rocks at’, not that I ever see anyone successfully throwing rocks at the providers of the big paid for OS’s either! 
So hopefully no where in my original post or replies did I suggest that what I wanted was for 23.11 itself to hang around for longer.
This is interesting. I haven’t really seen this written down (and yes I admit sometimes I skim read so I miss stuff!), especially not on the download page, but it is something I have come to understand over the last year. Arch (for example) declares itself as a rolling release, Ubuntu (at the other end of the spectrum) does make note of their LTS releases. I have invested two years learning NixOS and on one hand, I might have made a different choice if I’d really understood the 6 month/1 month upgrades at the start, but on the other hand, I wouldn’t have learnt of all the strengths and be in the position to make the risk decision that, whilst NixOS is maintained, there is a definite place for it in my world and I will come up with methods to manage upgrades whilst maintaining stability. I will get better at this and I am grateful for automatic updates not being imposed upon me (even with the one month time frame when search disappears - lol). I am most definitely not about shiny new! 
Isn’t security a concern for everyone now in one way or another? I would say I am here largely because I view that the declarative and immutable nature of NixOS offers me the ability to manage reliability and recovery. I haven’t spent a lot of time yet looking into tightening all aspects of security (can you ever) but every one I see goes on a list to be addressed. I love your phrase ‘software archaeology enjoyer’ BTW!
To your final point, which I think is the answer to my original post. Does leaving search for the deprecated 23.11 (or other) up for longer than a month suggest that is advisable to run 23.11. I personally don’t believe so. I think the month that it was available, it was clearly marked as deprecated and that should tell people not to install it! This is unlike many of the Wiki type entries and guides that are out there that often don’t really offer a timeframe when they were written or a version they were written for!
Thanks again for your great feedback - it was really useful in making me think and assess.
BTW, the rolling nixos-unstable is very popular, at least among active NixOS contributors.
In this case it was announced on Discourse, but most security vulnerabilities aren’t quite so widespread and severe as to warrant sounding the alarm on that level. You could look at the 1.severity: security label on GitHub, but generally it’s safe to assume that security fixes are happening constantly all the time, and that regularly keeping up‐to‐date on a supported channel is the only reliable way to keep on top of them. It would be nice if we had some kind of security bulletin system so that people could be notified of security issues, but I don’t think the resources are there. Not all upstreams are fantastic at properly acknowledging or surfacing bug fixes that have security impact, so even with more maintainer resources there’s a limit to how much we could do in terms of backporting and notification. In non‐NixOS‐specific terms, the oss-security mailing list is a relatively central place where security vulnerabilities in FOSS software are often announced.
There’s not much we can do against breaking changes in upstream software, but I would say that NixOS stable channel updates and even the rolling‐release unstable channel are pretty good in terms of stability. The nature of configuring things in Nix makes it easier for us to surface breaking changes at the time your system configuration is built, and there is a large suite of automated QA tests exercising a fairly wide range of software that have to pass before the channels will update. For instance, those tests notified us that the functionality for running an OpenSSH server in the stage‐1 boot process was broken by the major version bump that we used to fix the issue in the unstable release, That made sure we fixed it before the update reached the fully‐tested release channels used by most users.
I personally run the unstable channel on all my systems, though it depends on whether you prefer smaller but more evenly‐distributed surprises or a whole bunch of them all at once when a new major release comes out.
I trust automatic upgrades on NixOS more than with most distributions, due to the aforementioned combination of build‐time system configuration checking, automated channel QA tests, and rollback functionality (it’s a lot better than nothing even if it’s not perfect, especially if you can set up things like ensuring your server automatically rolls back if its network configuration breaks).
If it’s viable for you to invest time in writing automated NixOS integration tests for things you care about (here’s a brief introduction), it can greatly increase the confidence you can get in updates without manual labour. Being able to script a virtual network of machines that run the services in your system configuration and check that things seem to be working correctly is a bit of a superpower (although anyone who contributes to NixOS can attest that testing things at that kind of scale does often lead to spending engineering effort on trying to fix flaky tests rather than real failures).
The support period is mentioned in the release notes for each release, but I don’t know if it’s surfaced anywhere more prominently than that. We’re less of a rolling release than Arch is, but we definitely don’t have the paid employees and corporate funding Canonical and Red Hat use to offer very‐long‐term support versions, which involve a lot of engineering effort to identify and manually backport security fixes for a wide range of software. The one month support overlap is definitely a bit of a tight upgrade window for many potential users, but it’s better for us to be realistic about what we can achieve with the resources we have than give people a false sense of security. Bugs are being addressed all the time and in the FOSS world it’s very hard to disentangle general maintenance and feature development work from security fixes.
I don’t have a particularly strong opinion about the availability of releases on the search site, honestly. In this case it seems like the worry about it disappearing led to you learning more about our update and support policies, which seems like a net good thing! But in general it would probably be fine to keep it up a bit longer, and maybe even helpful to users if we could plaster a big security warning on it. It’s partly a matter of consistency and expectations; the search is an example of something that doesn’t really require much maintenance work, but it could potentially lead to people expecting things that do. There’s also a tangible difference between the “deprecated” state where you can still expect security fixes, and the “unsupported” one where you definitely can’t.
No worries, hope you can find a setup that works for you 