As always, stable releases are about how frequently breaking changes are introduced. If breaking changes potentially happening every day is fine for you, you can use unstable. For many use-cases however, you want some agency over when exactly breaking changes are introduced as point releases a la NixOS provide you with a 1 month window to migrate for each release.

With efficient cpus and lack of dedicated gpus I doubt the 4W of RAM is really that much of a battery drain.

What? If anything, it’d be more drain relatively speaking.

4W is quite a lot if you consider that a decently efficient laptop should draw 5-8W at idle max.

This should allow averagenon-technical users to keep up with development, without reading Github comments or knowing how to program.

;)

https://nixos.org/manual/nixpkgs/stable/#part-stdenv

robust stop and resume of download

You can stop/resume downloads via HTTP too. That’s up to the client to implement.

increased download speed with using several http and torrent sources at the same time

Again, this is a commercial CDN. Speed is practically infinite. Without the rather long ramp-up time too.

downloading from peers from within the same network

That sounds like a micro-optimisation for an edge-case.

automatic checksum calculation and redownlaod if needed

Not really necessary for an installer ISO downloaded via HTTPS.

Sorry that I asked. Seems that you feel very offensed by my question.

???

As mentioned, one of the reasons torrents don’t make sense here is that the ISOs change quite frequently. I don’t have exact numbers here but there’s nothing preventing them from changing every single day. The current ISO is only two days old.

Every seeder would have to discard the old ISO and re-download an entirely new ISO every few days or so.

Given that we need the CDN anyways, torrents just simply don’t make sense.

It doesn’t really make sense to use torrents here. We’ve got a commercial CDN serving these files for us and they change basically every day or so.

https://openbenchmarking.org/ for performance on Linux but it’s nowhere near as usable.

You gotta commend UB for their data presentation, it just sucks that the data is completely worthless.

I’ve heard that the original Linux kernel binaries+blobs are pretty huge

The kernel is <10MB and the initrd <20MB. “Pretty huge” is relative here.

You could override your kernel and strip stuff out of the initrd and I can assure you that it’s going to be a lot of pain but it’s easier to just make a 1GB boot partition these days and pretty much never worry about bloat again.

No, the actual issue was an impurity (not working in Nix’ pure model). Impurity is a bug; it was fixed years ago.

That being said, the statement that symbol conflicts do not exist on other distros is plainly not true.

I have never claimed such a thing.

Classical distros have exactly one instance of a library ABI’s .so in most cases which is usually the only place where any given symbol is defined.

You could technically provoke a symbol conflict using LD_PRELOAD and the like but it’s not something you commonly run into because package upgrades always replace the previous version entirely.

You could technically have multiple conflicting sos on classical distros too by prefixing a more detailed version but you don’t; doing such things kinda what differentiates Nix from classical package management.

This QT issue in particular was an impurity (working outside of Nix’ pure model; not as intended) caused by “installing” qt libraries into your environment imperatively (which isn’t something you should do anyways) that was solved a couple years ago.

Because other distros usually can’t have multiple versions of the same library to begin with.

There’s Nickel which is sort of Nix expression language 2.0 but, honestly, the Nix expression language is perfectly adequate for what it needs to do.

Not to say it couldn’t be better I wouldn’t put it inn any top 10 of what is holding Nix back.

Indeed, that looks like a bug. The version field is there but it doesn’t appear to be searched.

Could you open an issue on https://github.com/NixOS/nixos-search?

they say “you [person struggling to report a package-specific issue] are the problem; our system doesn’t need to change. YOU need to change”.

I have not met anyone in the Nix community who’s opposed to fixing actual systematic issues. I just highly doubt that the discoverability of github issue tracking in particular is a problem that Nixpkgs is in any way responsible for.

I too wouldn’t be entirely opposed to adding i.e. a little section on how to report issues but when you’ve read half a README, then opened CONTRIBUTING.md and read through that, you really should have discovered the “issues” tab to report your, well, issue by then.

It’s the reason Determinate Systems has a separately maintained nixpkgs-installer script, and separately maintained documentation.

No. The reason they have separate instances of those is that they allow a green-field approach to things. “Move fast and break things” is great for development but you can’t do that when the entire ecosystem relies on the things you might be breaking.

The installer is a great counter example actually. If someone wanted to replace the regular installer with the detsys installer right now, the greatest opposition they’d likely face is “hey, let’s be careful to not break users’ setups, does (niche feature) still work?”.
I wouldn’t be surprised to see it replace the current official installer within the next year.

Adopt a legacy codebase that is massive and requires EXACTLY ruby 2.6.0-rc1. On ubuntu, using rbenv, it takes a newby 30 sec to list all the available versions, and 30 sec to install ruby 2.6.0-rc1.

Try finding that version on search.nixos.org.

Nixpkgs has never has supported that version and does not support using multiple versions of Nixpkgs either (not even the currently maintained branches). You can try to and it’ll probably (perhaps even likely) work but it’s not “intended” to and nobody will want to deal with issues you might encounter with that.

We regularly kick out packages that have stupid version requirements like that for a reason. Eventhough we could technically have an infinite amount of versions of any package we choose not to because it’s a maintenance burden we cannot support.

The “proper” way of handling an issue like that (I’m sorry to say but depending on some old specific version is actually an issue of the dependant) is to “vendor” the dependency; copying its expression out of the Nixpkgs tree and maintaining it yourself.

try searching for the extremely-commonly-needed “Core Framework” package on search.nixos.org

According to repology, a package under than name exists in no repository and it knows about a damn lot of repositories:

https://repology.org/projects/?search=Core+Framework&amp;maintainer=&amp;category=&amp;inrepo=¬inrepo=&amp;repos=&amp;families=&amp;repos_newest=&amp;families_newest=

I don’t know which “Core Framework” you are referring to either.

But more importantly please ignore those details and look at the bigger picture; we are on the same team. I’m not insulting or ignoring the massive accomplishments nix team has made. They (maybe you as well) are giants that have moved moutains and accomplished things I wouldve considered basically impossible. I want to help the core devs have LESS work. I want to have productive discussions about the trade-offs of federated vs monorepo, searchability, documentation improvements, installer scripts, etc.

But we can’t.

Not until the discussion starts with “I agree there’s a problem” instead of “there is no problem other than YOUR lack of skill” I’ve yet to see a “bigger picture”-issue described in what you wrote.

At this point I’m not sure whether we’re talking about the same Nix community anymore. We have a lot of those “big picture” issues in the Nix community and we’re aware of them. What we need the most help with is fixing them, not finding them.

The messy mono-repo was never desgined to be searchable

I’m not sure what you mean by “searchable”?

https://search.nixos.org/packages exists and it’s generally pretty damn good.

The monorepo design is unmaintainable/unscalable from a package maintainer standpoint. There’s a ton of contributor burnout, there’s no real quality control on packages

There is contributor burnout and perhaps some quality issues here and there but the monorepo isn’t the reason for that. In fact, it’d be a lot worse if we had hundreds of smaller repos instead as wide-reaching changes would become basically impossible with our current manpower.

There have been calls to fragment Nixpkgs for years but they’ve almost always been struck down because none of what was suggested would improve anything about our current maintenance issues.

to outsiders its not obvious how to report package-specific issues

You simply open an issue on GitHub. I don’t know how it could be any more clear.

I just checked and we don’t explicitly document this in CONTRIBUTING.md but I don’t think we should need to. It’s just too obvious IMO.

how to edit/fix/contribute to a single package

https://github.com/NixOS/nixpkgs/blob/master/CONTRIBUTING.md#how-to-create-pull-requests

flakes hub is fixing this, and I’m really excited for that.

FlakeHub fixes none of the maintenance issues of Nixpkgs.

It doesn’t work like that. Submodules are for defining the type, so the only thing you get is interface (options), not implementation.

I know I can restructure the code in other ways (eg. let .. in)

Do that.

Also be aware that some use-cases might be covered by library functions such as lib.flatMap or lib.pipe.

Could you provide a more concrete example? There"s nothing preventing what I think you’re trying to do.

Write what you are trying to do and then the accompyaning error.

Here’s my btrfs module for reference:

https://github.com/Atemu/nixos-config/blob/431d76e67219a37f1e2e06042141df417530200b/btrfs.nix

Why the overlay? If you just want to give the drvs names (good practice IMO), simply use a let binding.

The buildEnv is unnecessary: systemPackages does the same with all the derivations in the list in the end anyways.

It’d be pretty neat if hm could populate a temporary directory and open a shell where $HOME is that temp dir but I don’t think it can.

As for rollbacks, see https://nix-community.github.io/home-manager/index.html#sec-usage-rollbacks

You actually would not. The content of the post can stay but the username/identifier has to be removed. Written text is not PII to my knowledge and every social platforms I’ve actively used only delete the identifier (Reddit, GitHub).