# Support for 23.11

**URL:** https://discourse.nixos.org/t/support-for-23-11/46795
**Category:** Development
**Created:** [June 10, 2024, 9:37am UTC](https://discourse.nixos.org/t/support-for-23-11/46795 "2024-06-10T09:37:11Z")
**Posts on this page:** 1
**Showing post:** 20

<div class="post-metadata">

### Author: ![emily](https://discourse.nixos.org/user_avatar/discourse.nixos.org/emily/32/1628_2.png) [@emily](https://discourse.nixos.org/u/emily)
#### Post date: [July 4, 2024, 9:35am UTC](https://discourse.nixos.org/t/support-for-23-11/46795/20 "2024-07-04T09:35:49Z")

</div>

> [@fsbof](#):
>
> 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?

In this case it was [announced on Discourse](https://discourse.nixos.org/t/security-advisory-openssh-cve-2024-6387-regresshion-update-your-servers-asap/48220), 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](https://github.com/NixOS/nixpkgs/pulls?q=is%3Apr+label%3A%221.severity%3A+security%22) 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](https://oss-security.openwall.org/wiki/mailing-lists/oss-security) is a relatively central place where security vulnerabilities in FOSS software are often announced.

> [@fsbof](#):
>
> 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’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](https://github.com/NixOS/nixpkgs/pull/323796) 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.

> [@fsbof](#):
>
> 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 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](https://nix.dev/tutorials/nixos/integration-testing-using-virtual-machines.html)), 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).

> [@fsbof](#):
>
> 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`! 😉

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.

> [@fsbof](#):
>
> 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!

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.

> [@fsbof](#):
>
> Thanks again for your great feedback - it was really useful in making me think and assess.

No worries, hope you can find a setup that works for you 🙂

---

_[View the full topic](https://discourse.nixos.org/t/support-for-23-11/46795)._