3 ms·

Perhaps it is just me, but the provided example makes me shudder: > For a made-up example, let’s imagine your company maintains a tool built 25 years ago with

by WJW 5y ago

Perhaps it is just me, but the provided example makes me shudder: > For a made-up example, let’s imagine your company maintains a tool built 25 years ago with the C compiler from that time. It can’t be upgraded safely because the entire world’s banking system would fall apart if it did. Maybe you keep a dedicated laptop as a digital time capsule to maintain this tool. Instead, you can create a Nix shell with whatever version of the tools you need, pinned and never upgraded. Yikes! If your company depends on a tool it can never upgrade because the business would collapse if you did, you should be embarking on mitigation projects and/or partial rewrites right now! Don't enable this abusive situation for longer with "Oh but Nix makes it much safer!", because that is going to make the problem that much worse when it finally does collapse.

arianvanp 5y ago
Look at it like this: Nix will also make it safer to upgrade. If it goes wrong you can easily roll back and try again with some extra patches. The fact that I _know_ I can go back to a safe state makes me less scared about delaying updates. So these situations will happen less if working with Nix IMO
naasking 5y ago
I'm not sure what you mean by "when it finally does collapse". What kind of scenario are you thinking about?
- WJW 5y ago
  Maybe I'm projecting my own experiences onto this, but the few times I've encountered "critical 25 year old code that can't be upgraded" situations they have always been badly neglected and knowledge about their workings is either already gone or concentrated in a few people about to retire. No codebase has eternal life: sooner or later you need to upgrade the code anyway because some upstream vendor finally retired an API, or CPU vendor finally ran out of spare parts for the obscure architecture it was running on, regulation like GDPR means big changes are needed, etc etc etc. If you do the upgrades sooner, more of the domain knowledge that the original devs built up will still be around and upgrading will be relatively painless. If you delay until the last possible moment, you virtually guarantee that the upgrade will be as painful as possible. In the example, Nix being used as a bandaid to further delay upgrades is very likely going to lead to long term problems IMO, any codebase that is critical to a business should always be in a state of partial rewriting/refactoring/upgrading, to keep it up-to-date but also just to keep the current devs familiar with how it all works. Institutional knowledge degrades over time otherwise and regular maintenance is way cheaper than the occasional massive blowup. That said, nix has other benefits and it's merely this example that I have a problem with. Please don't use nix to excuse poor software maintenance practices, but use it for things it was meant for.
  - naasking 5y ago
    I suppose it depends on the application. NASA is still communicating with voyager, and being able to setup a build environment for the old protocols written 40 years ago on a modern computer would be quite valuable to them. I imagine there are also still microcontroller systems that communicate via standardized protocols that don't need APIs of the kind you're thinking of. Say, like older nuclear power plants. Everything has a shelf life, but a long lifetime doesn't necessarily mean a system has to constantly evolved/kept up to date in the manner you're describing. Being able to install an environment that's guaranteed to reproduce the original system as deployed would be valuable though, and Nix seems it could fit the bill.
    - WJW 5y ago
      Fair enough, there are definitely some applications where old does not mean out of date (mostly non-internet-connected applications I think). The original example in the article contained "It can’t be upgraded safely because the entire world’s banking system would fall apart if it did.", which definitely does seem like a disaster waiting to happen. Nix seems like it could fill a niche, but I do wonder if it will be as ubiquitous as some articles proclaim. Certainly with the apps I currently work on (Ruby/Rails mostly) we already experience almost none of the pain that Nix claims to solve, so I doubt many will switch.
      - naasking 5y ago
        Source code and abstract virtual machines make many things easier. However, I expect Rails is typically deployed via Docker or something to capture dependencies. That part could be replaced by Nix, in principle. People also use Nix quite in combination with Docker, so clearly Docker doesn't go far enough on the developer experience, and Nix doesn't provide isolation so Docker provides advantages from that side. I feel like there should be a more integrated, comprehensive solution for this sort of thing, but these are on the right track.

by WJW 5y ago

arianvanp 5y ago

Look at it like this: Nix will also make it safer to upgrade. If it goes wrong you can easily roll back and try again with some extra patches. The fact that I _know_ I can go back to a safe state makes me less scared about delaying updates. So these situations will happen less if working with Nix IMO

naasking 5y ago

I'm not sure what you mean by "when it finally does collapse". What kind of scenario are you thinking about?

WJW 5y ago
Maybe I'm projecting my own experiences onto this, but the few times I've encountered "critical 25 year old code that can't be upgraded" situations they have always been badly neglected and knowledge about their workings is either already gone or concentrated in a few people about to retire. No codebase has eternal life: sooner or later you need to upgrade the code anyway because some upstream vendor finally retired an API, or CPU vendor finally ran out of spare parts for the obscure architecture it was running on, regulation like GDPR means big changes are needed, etc etc etc. If you do the upgrades sooner, more of the domain knowledge that the original devs built up will still be around and upgrading will be relatively painless. If you delay until the last possible moment, you virtually guarantee that the upgrade will be as painful as possible. In the example, Nix being used as a bandaid to further delay upgrades is very likely going to lead to long term problems IMO, any codebase that is critical to a business should always be in a state of partial rewriting/refactoring/upgrading, to keep it up-to-date but also just to keep the current devs familiar with how it all works. Institutional knowledge degrades over time otherwise and regular maintenance is way cheaper than the occasional massive blowup. That said, nix has other benefits and it's merely this example that I have a problem with. Please don't use nix to excuse poor software maintenance practices, but use it for things it was meant for.
- naasking 5y ago
  I suppose it depends on the application. NASA is still communicating with voyager, and being able to setup a build environment for the old protocols written 40 years ago on a modern computer would be quite valuable to them. I imagine there are also still microcontroller systems that communicate via standardized protocols that don't need APIs of the kind you're thinking of. Say, like older nuclear power plants. Everything has a shelf life, but a long lifetime doesn't necessarily mean a system has to constantly evolved/kept up to date in the manner you're describing. Being able to install an environment that's guaranteed to reproduce the original system as deployed would be valuable though, and Nix seems it could fit the bill.
  - WJW 5y ago
    Fair enough, there are definitely some applications where old does not mean out of date (mostly non-internet-connected applications I think). The original example in the article contained "It can’t be upgraded safely because the entire world’s banking system would fall apart if it did.", which definitely does seem like a disaster waiting to happen. Nix seems like it could fill a niche, but I do wonder if it will be as ubiquitous as some articles proclaim. Certainly with the apps I currently work on (Ruby/Rails mostly) we already experience almost none of the pain that Nix claims to solve, so I doubt many will switch.
    - naasking 5y ago
      Source code and abstract virtual machines make many things easier. However, I expect Rails is typically deployed via Docker or something to capture dependencies. That part could be replaced by Nix, in principle. People also use Nix quite in combination with Docker, so clearly Docker doesn't go far enough on the developer experience, and Nix doesn't provide isolation so Docker provides advantages from that side. I feel like there should be a more integrated, comprehensive solution for this sort of thing, but these are on the right track.