3 ms·
A thing with a clunky UI that technically only restricts the capabilities of its parent tool is not the future. It's a tarpit for staying in the local optimum t
by tazjin 3y ago
A thing with a clunky UI that technically only restricts the capabilities of its parent tool is not the future. It's a tarpit for staying in the local optimum that most Nix use is in right now.
- Macha 3y agoI don't see Flakes as a decision that's impossible to work past more or less than traditional nix, given that you can use flakes from traditional nix (not as easily as overlays, I will give you that), and frankly refusing to take a real improvement for end users over a hypothetical better one that no one has managed to produce yet seems counter productive.
- tazjin 3y agoYou're talking about a different thing. I'm not interested in Nix for end-users who maintain office suite installations and Steam on their desktop computers. By all means, if somebody wants to make a great UX improvement for that - go ahead, but it doesn't need to be in the core of Nix.
- pxc 3y ago> It's a tarpit for staying in the local optimum that most Nix use is in right now. I know that pre-flakes conventions for reusing Nix code are pretty open-ended, and naturally 'pure evaluation mode' means turning a bunch of things off. I can also see how if you are interested in integrations with stateful systems or maybe relaxing certain constraints or allowing/tracking some 'impurities', that might also seem like a step in the wrong direction. Do you have any possibilities (or examples) in mind for how Nix might be used beyond the 'local optimum' of most current usage?