3 ms·
I appreciate your presentation of an alternate viewpoint. The "build from source" camp provides solutions to a couple problems that at first glance seem to be
by pmahoney 10y ago
I appreciate your presentation of an alternate viewpoint.
The "build from source" camp provides solutions to a couple problems that at first glance seem to be difficult in a "principled mutation of binary image" model:
- Moving to a different architecture, e.g. x86 to ARM or ppcle. In build from source, I essentially change some parameters and components in the lowest level and rebuild.
- Other big changes to base components, e.g. compiling for Linux/libc vs. building atop a unikernel (obviously heavily dependent on what the upper layers are doing, but I can imagine wanting to run similar code atop multiple bases).
- Sharing common components. This is not really a "from source" thing, but is an important part of Nix. If two images include components in different orders, in Nix the common components will be shared (at the arguably coarse granularity of a Nix package), while the linear structure of Docker layers means once two images diverge, everything further down the chain will be its own copy, even if the same bits.
- geocar 10y ago"Sharing common components" is useful, and the fact that any combination of Nix packages is a valid combination is not something that is guaranteed by other package management systems[1]. However there's another, perhaps simpler solution: I can have a separate "wu-ftpd" container, and a separate "hylafax" container. This admittedly might not have been as easy when nix started, but it is very very easy now. [1]: https://cr.yp.to/slashpackage/studies.html https://cr.yp.to/slashpackage/studies.html