Yikes, lot’s of bad advice in this thread.

My advice: Go develop an actual threat model and find and implement mitigations to the threats you’ve identified.

If you can’t do that, that’s totally okay; it’s a skill that takes a lot of time and effort to learn and is well-compensated in the industry.

You will need to pay for it. Either through an individual assessment by someone who knows what they’re doing, managed hosting services where the hoster is contractually liable and has implemented such measures, by risking becoming part of a botnet or by not hosting in a world-public manner.

My recommendations:

• Pay for proper managed hosting for every part of your system that you are not capable of securing yourself. This is a general rule that even experienced people follow by i.e. renting a VPS rather than exposing their own physical HW. There are multiple grades to this such as SaaS, PaaS and IaaS.
• Research, evalue and implement low-hanging fruit measures that massively reduce the attack surface. One such measure would be to not host in a manner that is accessible to the entire world and instead pay for managed authenticated access that is limited to select people (i.e. VPN such as Tailscale)
• git gud

(but-with 'nix (lots-of 'parenthesis))

Did you/your distro set up realtime ulimits correctly such that pw can acquire rt priority?

That’s a very odd example to choose given how trivially interchangable kernels are.

At NixOS, we ship the same set of kernels on stable and rolling; the only potential difference being the default choice.
I’m pretty sure most other stable distros optionally ship newer kernels too. There isn’t really a technical reason why they couldn’t.

To be able to predict when something you depend on breaks.

This “something” could be as “insignificant” as a UI change that breaks your workflow.
For instance, GNOME desktop threw out X11 session support with the latest release (good riddance!) but you might for example depend on GNOME’s X11 session for a workflow you’ve used for many years.

With rolling, those breaking changes happen unpredictably at any time.
It is absolutely possible for that update to come out while you’re in a stressful phase of the year where you need to finish some work to hit a deadline. Needing to re-adjust your workflow during that time would be awful and could potentially have you miss the deadline. You could simply not update but that would also make you miss out on security/bug fixes.

With stable, you accumulate all those breaking changes and have them applied at a pre-determined time, while still receiving security/bug fixes in the mean time.
In our example that could mean that the update might even be in a newer point release immediately but, because your point release is still supported for some time, you can hold on on changing any workflows and focus on hitting your deadline.

You need to adjust your workflow in either case (change is inevitable) but with stable/point releases, you have more options to choose when you need to do that and not every point in time is equally convenient as any other.

Rolling vs. point release is not about whether a breaking change happens or not but when.

With rolling, breaking changes could happen at any time (even when inconvenient) but are smaller and spread out.
With point release, you get a big chunk of breaking changes all at once but at predictable points in time, usually with migration windows.

Ahhhhh whyyyyy, you’ve got all of these standard response codes made for you, why would you blatantly ignore them like that?!

In this comparison, the devil is in the detail.

With Ansible, you have an initial condition onto which you add additional state through automatically executed steps dictated by you until you (hopefully) arrive at a target state. This all happens through modification of one set of state; each step receives the state of the previous step, modifies it and passes the entire state onto the next step. The end result is not only dependant on your declared steps but also the initial state. A failure in any step means you’re left in an inconsistent state which is especially critical for the case of updating an existing state which is the most common thing to do to a Linux system.

In NixOS, you describe the desired target state and the NixOS modules then turn that description into compartmentalised bits of independent state. These are then cheaply and generically combined into a “bundle”; wrapping them into one big “generation” that contains your entire target state.
Your running system state is not modified at any point in this process. It is fully independent, no matter what the desired system is supposed to be. It is so independent in fact that you could do this “realisation” of the NixOS system on any other system of the same platform that has Nix installed without any information about the state of the system it’s intended to be deployed on.
This “bundle” then contains a generic script which applies the pre-generated state to your actual system in a step that is as close to atomic as possible.
A good example for this are packages in your PATH. Rather than sequentially placing the binaries into the /usr/bin/ directory as a package manager would when instructed by ansible to install a set of packages, NixOS merely replaces the bin symlink with one that points at an entirely new pre-generated directory which contains the desired packages’ binaries (well, symlinks to them for efficiency). There cannot possibly be an in-between state where only some of the binaries exist; it’s all or nothing. (This concept applies to all parts that make up a Linux system of course, not just binaries in the PATH. I just chose that as an easy to understand example.)
By this property, your root filesystem no longer contains any operating system configuration state. You could wipe it and NixOS would not care. In fact, many NixOS users do that on every boot or even use a tmpfs for /.

(Immutability is a property that NixOS gains almost by accident; that’s not its primary goal.)

You could take the revision number. nixos-unstable has 567011 commits currently.

Original price doesn’t matter, you need to compare it against current new offerings. A drive like that, I’d buy for 8-10€/TB at max. because current new HDD pricing is 15€/TB at the low end.

What you also need is SMART output. Watch out for high uncorrectable errors, writes and whatever. I’d never buy a drive without having seen its SMART data.