[HN Gopher] Nixing Technological Lock In
___________________________________________________________________
Nixing Technological Lock In
Author : abathur
Score : 9 points
Date : 2024-02-18 17:42 UTC (5 hours ago)
(HTM) web link (economicsfromthetopdown.com)
(TXT) w3m dump (economicsfromthetopdown.com)
| nyrikki wrote:
| I have mixed feelings about this, particularly.
|
| "With Nix, there is a free way to build a deterministic,
| exquisitely organized warehouse for managing your entire software
| stack."
|
| I have had clients, especially with monorepos, that force one
| golden image organization wide.
|
| This is absolutely not the correct approach. When I was helping a
| company move to M1 macs, when Apple killed the Intel based skus,
| I had fonts, where the tests in compiling them would hard reset
| the laptop.
|
| But getting half a dozen teams to update the package to one that
| would compile was just as painful as any monolith.
|
| It is fine to use Nix for reproducibility, but don't enforce an
| enterprise wide monolithic configuration.
|
| Unfortunately the intersection of security policies and team
| independence results in this pattern arising organically.
|
| It is probably best to offer this as an optional tool to avoid
| those issues. But provide guidance from accidentally recreating
| the same problem.
|
| The python 3 isn't probably the best example as companies had
| over a decade to migrate. I personally migrates dozens of open
| source projects, almost always with the built in tools with some
| tests and reformating to match the projects coding style. Only
| once did that take me more than an afternoon per project.
___________________________________________________________________
(page generated 2024-02-18 23:01 UTC)