3 ms·
Interestingly, it occurred to me that NixOS might be in perfect position to enable painless "gradual migrations" of tooling. Imagine alternative history of UNI
by akavel 10y ago
Interestingly, it occurred to me that NixOS might be in perfect position to enable painless "gradual migrations" of tooling.
Imagine alternative history of UNIX, where NixOS was invented really long time ago, before 'less' was created. Now, imagine we're Mark Nudelman and we want to add fancy features to 'more' (instead of creating a new tool named 'less'). We could do this freely, and all tools depending on peculiarities of "old more" could be pinned to use a "private" old version of the binary, while new ones would by default use the "new more". Then, the backwards tools could be gradually updated, until no one imported the "old more" and it could be safely removed from the nixpkgs repository. (While any external, non-nixpkgs package definitions could still backport the "old more" definition should they really need it.)
Does this reasoning have any holes?
- zeveb 10y agoI can imagine, though, that more(1) in that case would eventually fork, so that some software depended on my-more and others on his-more and still others on her-more. And that-other-dude's-more would have a security vulnerability, and no-one would update it, and we'd all get pwned, oh the embarrassment.
- RubyPinch 10y agoI'd be asking the question of wether anything depended on `more` that couldn't depend on `less` already, but instead depends on more because more is not less. Or, in other words, maybe the issue is cultural instead of technical, which would in practice, result in new users going to either more (the relic) or less (the bloated), depending on their views, instead of all new users going to less edit: reading through the rest of the comments here, it seems a lot of people prefer more, for various reasons!