Lots to catch up on, after the weekend …
Can you elaborate on your usecase for using unstable, while still wanting the stability? Then perhaps we can come up with a reasonable solution here.
As I said above: I’m helping flush out issues early, before they hit next stable. The reasonable solution is to recognize, that our stable users will also be hit by the same breakage that we are, only delayed, and that there is little qualitative difference between the channels, except for maturity.
Just going “why don’t you just use stable then?” completely misses that point.
Please do not see this as “taking the L”
Why not? I started a fight. I thought it was about stability of our user experience. Turns out it was also about the tone we find acceptable. I don’t have a problem with changing my approach and “losing” some of the sass, if it means that the community wins in civility. I only ask that we still take this issue seriously, even if I roll off the gas.
the particular case that triggered this thread seemed fairly reasonably considered, though?
Hard disagree. As detailed above, it was the most egregious case, I’ve seen in a long time:
- It removed working options for security reasons, even though they could be configured safely
- It introduced a submodule in its place, in a way that prevented both proper error message and any type of backwards compatibility, even as an afterthought [1]
- It seems to have done this in a paradoxical way, where
- we’re done after migrating internal users, because external users should expect to be broken on unstable
- we’re so concerned about our external user’s security, even after having migrated all internal users, that we can’t let them have their toys any more, not even with a warning. are we realizing that this way, we’re disincentivizing users from upgrade, which is even worse for security?
Perhaps ‘declarative’ was the wrong word to use, but did you really not understand what I was writing here?
I can see your hands, waving, but I actually don’t know precisely what your point is here. Is it “because we can detect a certain class of breakage (that which produce eval errors) earlier, it’s more acceptable to break our users”?
postponing your update
That goes exactly to the heart of the issue: Why is the NixOS security team deciding for me, that I can’t get my latest CVE fixes, before having reviewed all uses of fcgiwrap in my systems? In the name of fixing a local privilege escalation?
FFS! Local root exploits are a dime a dozen. Those should never hold up more important security fixes!
The maintenance burden […] all those should keep working […] do they share code
I agree that those aren’t easy problems. I’ll stand by my point that if we just stopped breaking things, then the maintenance burden will be a lot less than what should be expected, judging based on other systems.
I take some issue with your implication that anybody who disagrees with you must just not be very experienced.
Oh plenty more experienced people will disagree with me on any number of things. Just not about stability, because people who don’t value that, tend to burn out and change carreer. [2]
Also, I am taking issue with your implication that I’m in any way looking down at or thinking less of somebody inexperienced. If anything, I want to help them avoid some of the mistakes I’ve seen and made myself.
If that is your end goal, I’d immediately stop maintaining.
With respect, but issuing all-or-nothing threats like this makes me question if your current level of involvement is at a healthy place. If you need someone to talk to, my DMs are open.
I have scaled back my own involvement with NixOS at various points, where I noticed that I cared “too much” for it to be healthy, and now that I’m feeling better about it, I’m back. Hello. Most of my old stuff still works and that’s how I like it.
would it also be possible / worth introducing a separate of ‘backcompat’ modules translating old options to new? This way they’d be out of the main code base, and could be maintained by those with more interest in long-term backward compatibility?
This is a sensible approach IMO, also because it would allow overburdened maintainers to have a place to move what they’d consider “legacy” to, while still keeping half an eye on avoiding unnecessary breakage.
If security concerns can arise, we would need some mechanism to warn of this when the configuration is being evaluated, no? Any ideas how to solve this in code @bendlas?
We could handle that the same way as we handle e.g. outdated electron or node versions: By blacklisting, while allowing users to whitelist the known-insecure thing back.
There is also a NixOS option for warnings.
[1] btw, I think implementing services.<service>.<instance>
instead of services.<service>.instances.<instance>
has repeatedly caused issues. I think that could be something to put in an RFC, to always leave room for top-level options in services.
[2] yes, of course, there are nuances, especially in a project as big as NixOS, which is why I’m careful to qualify with stuff like “unless absolutely necessary” and “where is the line”. Also, I believe @raboof when they say they have extensive experience providing compatibility, not all of it good, but given how fast people seem to be with defending unnecessary breakage, I don’t think we’re erring on that side right now.