4 ms·

Nix gives you a commit guarantee rather than arbitrary versions. You're going to put yourself in a bad time when you have edge cases: glibc changes or conflicti

Nix gives you a commit guarantee rather than arbitrary versions. You're going to put yourself in a bad time when you have edge cases: glibc changes or conflicting shared libraries. It sounds like it's a little bit too late, but I'm happy to provide some consulting on how you can get it to work idiomatically with Nix. Product looks cool!

nialv7 1y ago
nix solves the shared library incompatibility problem by being extremely conservative. every time anything changes, consequential or not - a comment got modified, documentation changes, a testcase got added, etc. - it will rebuild all dependents. and not just that, but all dependents of dependents, and dependents of dependents of dependents, on and on. this often results in massive massive rebuilds. sure you are not going to get shared library conflicts, but i think this solution is extremely wasteful, and can make development painful too - look at nixpkgs' staging process.
- smilliken 1y ago
  The reason someone changes a dependency at all is because they expect a difference in behavior. No one would feel the motivation to go update a dependency if they aren't getting something out of it, that's a waste of effort and an unnecessary risk. Each person doesn't have to perform the build on their own. A build server will evaluate it and others will pull it from the cache. The greater waste that nix eliminates is the waste of human time spent troubleshooting something that broke in production because of what should have been an innocent change, and the lost business value from the decreased production. When you trust your dependencies are what you asked for, it frees the mind of doubt and lets you focus on troubleshooting more efficiently towards a problem. Aside, I spent over a decade on Debian derived distros. I never once had one of these distros complete an upgrade successfully between major versions, despite about 10 attempts spread over those years, though thankfully always on the first sacrificial server attempted. They always failed with interesting issues, sometimes before they really got started, sometimes borking the system and needing a fresh install. With NixOS, the upgrades are so reliable they can be done casually during the workday in production without bothering to check that they were successful. I think that wouldn't be possible if we wanted the false efficiency of substituting similar but different packages to save the build server from building the exact specification. Anything short of this doesn't get us away from the "works on my machine" problem.
  - gf000 1y ago
    Yep, anyone not getting how absolutely huge the Nix model is should just install the whole KDE desktop, the Gnome desktop, and uninstall both. Only nix can make it basically a no-op.
  - nialv7 1y ago
    > With NixOS, the upgrades are so reliable Yeah they may be reliable _for you_. And do note this reliability doesn't come automatically with Nix's model, it is only possible because many people put a lot of effort into making it working correctly. If you use the unstable channels, you would know. My NixOS upgrades break _all_ the time. On average, probably once a month.
- setheron 1y ago
  Nix has support for bit reproduction and will not rebuild on comments if you specify it. Of course lots of software isn't ready for but reproduction which is why Nix has taken such a pragmatic approach. (I have written a lot about this). It's all a series of tradeoffs. If your goal is reproducibility (as close as you can get), you will have a larger graph likely ..since you are accounting for more! Sometimes we like to believe we can have our cake and eat it too rather than understand life's a series of tradeoffs. When we think we are getting a silver bullet, we've likely just pushed that complexity somewhere else.
  - nialv7 1y ago
    IIUC you are talking about CA-derivations? Yeah they may help but it's hard to know how much since it's not in production yet, despite being part of Eelco's original paper describing nix. So my hope isn't high. > When we think we are getting a silver bullet, we've likely just pushed that complexity somewhere else. True but we kind of just stopped looking. and I feel much of the solution space hasn't been explored.
- gf000 1y ago
  I mean, there is no other way that guarantees correctness across arbitrary tools/functions/builds. Like, what if I have a step that replaces certain comments with code? Also, the primary way to develop with Nix is to create your exact, reproducible environment in the form of a shell, and then develop there using the usual, language-idiomatic iterative way. But now you can actually have a very specific compiler-flag for only a single dependency mixed with a full different libc working in a given shell 100%, for you and everyone else, instead of iterating through nodejs and npm version combination to start working on this new project, taking a couple of days..
eddythompson80 1y ago
> You're going to put yourself in a bad time when you have edge cases: glibc changes or conflicting shared libraries. I totally understand the value proposition of Nix. However I think saying "bad time" is a bit hyperbolic. At most it's "You'll be losing a pretty significant guarantee compared to Nix". Still probably "packed to be more likely to work correctly" than 95% of software out there.

nialv7 1y ago

nix solves the shared library incompatibility problem by being extremely conservative. every time anything changes, consequential or not - a comment got modified, documentation changes, a testcase got added, etc. - it will rebuild all dependents. and not just that, but all dependents of dependents, and dependents of dependents of dependents, on and on. this often results in massive massive rebuilds. sure you are not going to get shared library conflicts, but i think this solution is extremely wasteful, and can make development painful too - look at nixpkgs' staging process.

smilliken 1y ago
The reason someone changes a dependency at all is because they expect a difference in behavior. No one would feel the motivation to go update a dependency if they aren't getting something out of it, that's a waste of effort and an unnecessary risk. Each person doesn't have to perform the build on their own. A build server will evaluate it and others will pull it from the cache. The greater waste that nix eliminates is the waste of human time spent troubleshooting something that broke in production because of what should have been an innocent change, and the lost business value from the decreased production. When you trust your dependencies are what you asked for, it frees the mind of doubt and lets you focus on troubleshooting more efficiently towards a problem. Aside, I spent over a decade on Debian derived distros. I never once had one of these distros complete an upgrade successfully between major versions, despite about 10 attempts spread over those years, though thankfully always on the first sacrificial server attempted. They always failed with interesting issues, sometimes before they really got started, sometimes borking the system and needing a fresh install. With NixOS, the upgrades are so reliable they can be done casually during the workday in production without bothering to check that they were successful. I think that wouldn't be possible if we wanted the false efficiency of substituting similar but different packages to save the build server from building the exact specification. Anything short of this doesn't get us away from the "works on my machine" problem.
- gf000 1y ago
  Yep, anyone not getting how absolutely huge the Nix model is should just install the whole KDE desktop, the Gnome desktop, and uninstall both. Only nix can make it basically a no-op.
- nialv7 1y ago
  > With NixOS, the upgrades are so reliable Yeah they may be reliable _for you_. And do note this reliability doesn't come automatically with Nix's model, it is only possible because many people put a lot of effort into making it working correctly. If you use the unstable channels, you would know. My NixOS upgrades break _all_ the time. On average, probably once a month.
setheron 1y ago
Nix has support for bit reproduction and will not rebuild on comments if you specify it. Of course lots of software isn't ready for but reproduction which is why Nix has taken such a pragmatic approach. (I have written a lot about this). It's all a series of tradeoffs. If your goal is reproducibility (as close as you can get), you will have a larger graph likely ..since you are accounting for more! Sometimes we like to believe we can have our cake and eat it too rather than understand life's a series of tradeoffs. When we think we are getting a silver bullet, we've likely just pushed that complexity somewhere else.
- nialv7 1y ago
  IIUC you are talking about CA-derivations? Yeah they may help but it's hard to know how much since it's not in production yet, despite being part of Eelco's original paper describing nix. So my hope isn't high. > When we think we are getting a silver bullet, we've likely just pushed that complexity somewhere else. True but we kind of just stopped looking. and I feel much of the solution space hasn't been explored.
gf000 1y ago
I mean, there is no other way that guarantees correctness across arbitrary tools/functions/builds. Like, what if I have a step that replaces certain comments with code? Also, the primary way to develop with Nix is to create your exact, reproducible environment in the form of a shell, and then develop there using the usual, language-idiomatic iterative way. But now you can actually have a very specific compiler-flag for only a single dependency mixed with a full different libc working in a given shell 100%, for you and everyone else, instead of iterating through nodejs and npm version combination to start working on this new project, taking a couple of days..

eddythompson80 1y ago

> You're going to put yourself in a bad time when you have edge cases: glibc changes or conflicting shared libraries. I totally understand the value proposition of Nix. However I think saying "bad time" is a bit hyperbolic. At most it's "You'll be losing a pretty significant guarantee compared to Nix". Still probably "packed to be more likely to work correctly" than 95% of software out there.