4 ms·

>It's pretty nifty. It's how Amazon's stuff used to work (though not using Stow) back several years ago. No idea if they've migrated from that approach to con

>It's pretty nifty. It's how Amazon's stuff used to work (though not using Stow) back several years ago. No idea if they've migrated from that approach to containers, or similar, yet. Every application you deployed would have the necessary components deployed (or re-used if you had something else that already used it), and then build the application space from symlinks to those parts. Worked really well.

thrtythreeforty 3y ago
Ah, symlink farms, how I love to hate thee! They are alive and well.
- yjftsjthsd-h 3y ago
  Why do you hate them? (FWIW this is a sincere question; given the number of these things I touch, I would very much like to know if there are problems I need to know about and/or better alternatives)
tubs 3y ago
Still works on link farms, yep. And works pretty well!
RGamma 3y ago
Amazon has an internal Nix/Guix? Probably not much public info on this...
- kstrauser 3y ago
  Alternatively, Amazon is using stow, a common GNU utility whose info page refers to a version of Perl released in 1992, or something similar to it, instead of Nix and Guix which didn't exist when Amazon started.
  - fnordpiglet 3y ago
    Which is also the software this submission is about
  - RGamma 3y ago
    Would Amazon rely on stow when it is in this peril? Unless they really do rely on it and maintain an internal fork, which would make this situation even worse. Or they use it anyway...
  - coldtea 3y ago
    It used neither, but it's own implementation of the concept ("symlink all the things!", which is much older than both, and has lots of other implementations too, aside from Nix and Stow. It's how gobolinux works too, for example.
- paholg 3y ago
  It's not the same. It's been a while, so I'm sure to get things wrong, but you basically had different package groups you could set up. So a service would have its group that it could update, test, and deploy with at once. But like if I produced a package, and another team depended on it, there was no guarantee that the group I ran in CI had versions in common with the group that they deployed. I also remember some weirdness just within one package, like maybe your PR build was based on your local group setup and not anything "official". The coolest thing about it is that you could make a PR against multiple repos at the same time, even if one depended on the other. Like you could add a function to a library in one repo and call it from another repo in one PR.
- Twirrim 3y ago
  Yes. From what I was told, it was already of reasonable vintage when I joined in 2013.

thrtythreeforty 3y ago

Ah, symlink farms, how I love to hate thee! They are alive and well.

yjftsjthsd-h 3y ago
Why do you hate them? (FWIW this is a sincere question; given the number of these things I touch, I would very much like to know if there are problems I need to know about and/or better alternatives)

tubs 3y ago

Still works on link farms, yep. And works pretty well!

RGamma 3y ago

Amazon has an internal Nix/Guix? Probably not much public info on this...

kstrauser 3y ago
Alternatively, Amazon is using stow, a common GNU utility whose info page refers to a version of Perl released in 1992, or something similar to it, instead of Nix and Guix which didn't exist when Amazon started.
- fnordpiglet 3y ago
  Which is also the software this submission is about
- RGamma 3y ago
  Would Amazon rely on stow when it is in this peril? Unless they really do rely on it and maintain an internal fork, which would make this situation even worse. Or they use it anyway...
- coldtea 3y ago
  It used neither, but it's own implementation of the concept ("symlink all the things!", which is much older than both, and has lots of other implementations too, aside from Nix and Stow. It's how gobolinux works too, for example.
paholg 3y ago
It's not the same. It's been a while, so I'm sure to get things wrong, but you basically had different package groups you could set up. So a service would have its group that it could update, test, and deploy with at once. But like if I produced a package, and another team depended on it, there was no guarantee that the group I ran in CI had versions in common with the group that they deployed. I also remember some weirdness just within one package, like maybe your PR build was based on your local group setup and not anything "official". The coolest thing about it is that you could make a PR against multiple repos at the same time, even if one depended on the other. Like you could add a function to a library in one repo and call it from another repo in one PR.
Twirrim 3y ago
Yes. From what I was told, it was already of reasonable vintage when I joined in 2013.