Intrigued by a recent post about problems with the Fastly CDN leading to long download times for the ISOs, i started wondering why we don’t have a secondary download option via Torrent like most other distributions have.
This would add a fallback option in case this happens in some regions (and some users, myself included,might prefer using torrent as it doesn’t stress infrastructure one doesn’t pay for) and the hashes prevent tempering concerns (if they are checked by the user after download that is). Although adding a GPG signature file might also be something to consider to prevent some damage if nixos.org is ever breached.
I don’t think the arguments work as great as written out.
Hashes and GPG are basically an orthogonal topic.
Big ISOs get released roughly every 2 days. So people who download it will be useful seeders for about one day on average, assuming they do keep seeding. -small ISOs are rotated faster, more than one daily normally.
I’m not against, to be clear. Someone needs to write the code, and if won’t be expensive, we can then deploy it on the official infra.
That’s again an orthogonal issue. IIRC it’s been proposed also on the current ISOs, so that we’d save some place in S3, as we never delete so far and just the ISOs eat gigabytes per day.
The biggest setback I see is that ISO only starts you up.
I’m afraid that too many places rely on cache.nixos.org working reasonably, so that just getting ISO won’t really help that much. You’ll surely need updates sometimes (bothersome to do through ISO), and even for the initial installation, you might want packages that are not present on the ISO.
By the way, the Fastly CDN service is donated to NixOS.org free of charge.
This may actually be somewhat of a disguised beginner-UX discussion. I’d wager many people coming from traditional Linux will expect an ISO. Jumping right into NixOS is easier with an ISO for that audience, because it doesn’t require installing Nix to build you custom config. But we could argue that’s not the way people should approach the ecosystem and just on principle not provide ISOs but instead tell beginners to start with vanilla Nix and then spiral themselves up via VMs.
And then there’s of course a resource question: What’s cheaper? New people pulling ISOs or new people pulling from the cache after a Nix installation, and then pulling all the dependencies to build their own things to deploy NixOS?
I believe that avoiding ISO (or using just minimal ISO) would be cheaper. The individual packages “need” to be well cached anyway, as people who just update are getting them either way. And you only download those that you need.
But I wouldn’t think these costs are a significant factor for this topic. The biggest cost part is probably the huge total size of all the historical ISOs, but there it will be most cost-effective to simply delete (most of) old ones, etc.
The issue is not necessarily cost, but the download time for a new NixOS user. I’ve experienced long download times for a NixOS ISO piddling along at <1Mbps on my 1Gbps fiber connection. That’s a common enough experience that we periodically get threads asking - hey, why can’t I do what I’d do for every other distro and use a torrent?
I’d argue it’s not orthogonal because it seems to be the only good reason we don’t offer a torrent for ISOs.
I think having the published ISO be up to date is more important than having a torrent. For one, it minimizes the amount that has to be downloaded from cache.nixos.org when performing the installation, but also updates to the ISO can actually be critically important e.g. for hardware support or security reasons (see: the security advisories on our calamares repo)
There is a small difference; whatever caused a single tcp stream from fastly to be so slowly, having started the download using it, the entire download would be in the same stream. That would not be the case for a torrent, effectively masking whatever is the core issue here.
Niche use-cases of experimental features should not expect first-class support.
We have little regard for what a distro not known for stability does.
Our installer also includes support for ZFS which requires use of an LTS kernel at most times of the year.
They used to use some odd version between LTS and the latest to which they then backported security fixes throughout the release cycle (poorly I might add: 2 weeks release cycle, yikes!). I don’t know if they’ll continue doing that now that the upstream kernel marks all bug fixes as CVEs.
Anyhow, I don’t think we will be wasting resources backporting security and other bug fixes to some kernel when Greg does that for us already.
Putting a hash next to a download on an HTTPS website offers no security benefit whatsoever.
FWIW there has been talk of switching to the latest stable kernels by default, or at least prioritizing latest‐kernel ISOs and having installers default to the same kernel variety that was installed from. Though yes, users of ZFS would need to use the LTS kernels, and it’s a little awkward with the stable release cycle.
Just to make this point clear (and emily, we’ve discussed this with others on matrix before, so this is more a reply for the thread than for you), the issue is that any non-LTS kernel is likely to go EOL before a NixOS stable release does. If stable releases with a non-LTS kernel by default, then it will have to change kernel versions before that stable release goes EOL itself.
In my opinion, this is a dealbreaker. The whole point of NixOS stable releases is that packages only receive bug fix and security updates, not major version changes. Breaking this purpose for the kernel is, IMO, unacceptable.
That said, distributing ISOs with newer kernels in addition to LTS kernels is reasonable to me, and the installer probably ought to autodetect which one you’ve used and generate the configuration.nix with kernelPackages set accordingly.
I think it would be reasonable for the default unstable installer to use the latest stable kernel, and the default stable installer to use the LTS. People who use unstable but not ZFS are probably better‐off with the latest kernels.
I also don’t think that upgrading the stable kernel in a release cycle would be that bad – they backport most of the bugs anyway – but I can understand why others would not consider it so. (This is a very weak take, I don’t expect us to actually do this and it is likely that you could convince me that it would be a non‐starter in a few minutes of conversation.)
Also, as mentioned on Matrix I think ideally it would be two kernels in the same ISO, selectable from the boot menu, and we just flip the default depending on the release branch, say.
Two kernels in the same ISO sounds like an excellent idea. We should tell the user which one they’d want though. E.g. “LTS kernel (ZFS support)” and “Latest kernel (better support for new hardware)”.
