6 ms·

For end user devices, I much prefer Nix/NixOS [1] for this kind of thing. With Flakes [2] (experimental feature), you get full reproducibility. The documentat

For end user devices, I much prefer Nix/NixOS [1] for this kind of thing. With Flakes [2] (experimental feature), you get full reproducibility. The documentation is spotty and there is a considerable learning curve, but I've switched to NixOS on my laptop and desktop early this year and am mostly very happy with it. That doesn't cover sandboxing though. I would actually agree that sandboxing / restricting applications (Mac OS style) would be sorely needed on Linux desktop. Flatpak and Snap are trying to do this. A much saner approach than trying to find or maintain up to date, trustworthy Docker files for applications. [1] https://nixos.org/ https://nixos.org/ [2] https://nixos.wiki/wiki/Flakes https://nixos.wiki/wiki/Flakes

timClicks 6y ago
Snap provides a strong sandboxing layer, but IIRC Flatpak does not.
- the_duke 6y ago
  That is incorrect. https://docs.flatpak.org/en/latest/sandbox-permissions.html https://docs.flatpak.org/en/latest/sandbox-permissions.html
deleted 6y ago
[deleted]
ris 6y ago
Absolutely. Most Dockerfiles I come across are very much not written in a robustly reproducible way. The stacking filesystems model is really not very flexible (if you want to compose two docker images with dissimilar bases to be used together you have to resort to manually specifying which files to copy across from each base). Use of OS features to achieve its ends means the docker daemon itself requires far more privileges than I'm comfortable with and makes weirdness like docker-in-docker necessary...
- mikepurvis 6y ago
  Yeah, any Docker file that starts with `apt update; apt dist-upgrade` is an instant fail. You might be interested in this fascinating exploration of attempting to bend Docker into better caching and composition by injecting blocks of Nix packages as individual layers: https://grahamc.com/blog/nix-and-layered-docker-images https://grahamc.com/blog/nix-and-layered-docker-images
  - jrockway 6y ago
    I think the base images that are commonly used are just as bad; likely some random snapshot of upstream repositories at arbitrary times. You can refer to the sha256 of base images to avoid things changing, but I've never seen anyone do that. (The advice is "never use 'latest' because that could change out from under you", but other tags are just as mutable, and so that isn't real advice. You can follow the advice and have something just as bad happen.) The thing the upstream Linux distributions are missing are a lockfile with the hashes of installed packages. Programming languages figured this out (go.sum, package-lock.json, etc.) but distributions have not. Thus, people are often running "whatever" in production, because they simply don't have the ability to lock dependencies properly. I assume Nix solves this problem, and people should pay attention to how important it actually is.
    - eptcyka 6y ago
      In production, the companies I work with certainly do rely on SHA256 checksums to specify the base images.
      - jrockway 6y ago
        Do they just build their own images for open source things? I have never seen a dockerfile that does that.
        eptcyka 6y ago
        Yep.
GrantZvolsky 6y ago
I also phased out Docker for local, non-isolated workloads in favour of nix. It's saved me many hours of figuring out how to install software whose official packages don't work out of the box / aren't compatible with my distribution.
pknopf 6y ago
It's worth mentioning my pet project, Darch. https://godarch.com/ https://godarch.com/
mikepurvis 6y ago
I've examined this a number of times over the years for deploying a ROS (Robot Operating System) workspace to robots and laptops. Some of our competitors use snaps or various container technologies for this, but I've always felt that the isolation/sandboxing would be more of a barrier than a help— it's one more layer of udev rules and other indirection to have to punch through with another set of config files (and to no benefit as we're not trying to run multiple independent "apps" or anything). So currently at my org we use basically the same scheme I advocated for at a developer conference in 2016 [1]: we just build it all into a gigantic bundled debian package, and deploy that to the host system with apt. I keep revisiting these various technologies and all of them seem less mature than apt/dpkg, and mostly in service of features and capabilities which don't apply to my particular needs. Obviously I'm a bit of a niche case, and my needs aren't everyone's, but of all of them, nix is the one that seems to be doing the most that is truly interesting and different; being able to send a new nightly build out to users with requiring them to re-downloading an entirely new asset would be a major win. [1]: https://vimeo.com/187705228 https://vimeo.com/187705228
- strogonoff 6y ago
  I also suspect OS package managers are underused when it comes to deployments. I am guilty of that too, some irrational wariness of end-user tools being fit to deal with developer workflows. That aside, there is one slight possible pitfall in discarding one tech because it is less mature than the other: if we assume maturity only increases with time, the oldest product (e.g. apt/dkpg) will always be “best”. Made a note for myself to prefer “not mature enough for my needs” over “less mature than X”.
  - mikepurvis 6y ago
    I think for apt/dpkg, the system definitely does benefit from decades of careful, thoughtful design— for example you're pretty unlikely to come up with a version constraint between your packages which isn't expressible using the existing Debian scheme. And when I look at various modernish packaging systems, I often see a lot of this thrown out as unneeded complexity, only to be cobbled back in later when it's discovered how essential it really is (see for example Homebrew's long transition from being a dirt simple wrapper around "configure; make; make install" to becoming a full binary package manager). There's also the ecosystem benefit of having loads of helpers and supplementary tooling applicable to the formats— even stuff like having first-class support in proprietary binary stores like Artifactory, vs Nix where it's basically a shrug and "well... it works with any WebDAV server, so take your pick I guess?" The main complaint I have overall with Apt is the reliance on postinstall scripts, which means that even if you download and extract your packages in parallelized blocks, you still have a long serialized step when every single package needs to spawn a shell and run arbitrary commands, even if in most cases, the commands actually originate from a semi-declarative format (debhelpers, either invoked explicitly from the rules file, or implicitly by the presence of a corresponding debian/xyz file in the metadata). Anyway, if it were possible to somehow flag packages as atomic or configure-less, it might be possible to significantly speed up these operations, especially in environments like CI where you have everything mirrored in-network or possibly even on-machine so the overall install time is dominated by the package configure step.

timClicks 6y ago

Snap provides a strong sandboxing layer, but IIRC Flatpak does not.

the_duke 6y ago
That is incorrect. https://docs.flatpak.org/en/latest/sandbox-permissions.html https://docs.flatpak.org/en/latest/sandbox-permissions.html

deleted 6y ago

[deleted]

ris 6y ago

Absolutely. Most Dockerfiles I come across are very much not written in a robustly reproducible way. The stacking filesystems model is really not very flexible (if you want to compose two docker images with dissimilar bases to be used together you have to resort to manually specifying which files to copy across from each base). Use of OS features to achieve its ends means the docker daemon itself requires far more privileges than I'm comfortable with and makes weirdness like docker-in-docker necessary...

mikepurvis 6y ago
Yeah, any Docker file that starts with `apt update; apt dist-upgrade` is an instant fail. You might be interested in this fascinating exploration of attempting to bend Docker into better caching and composition by injecting blocks of Nix packages as individual layers: https://grahamc.com/blog/nix-and-layered-docker-images https://grahamc.com/blog/nix-and-layered-docker-images
- jrockway 6y ago
  I think the base images that are commonly used are just as bad; likely some random snapshot of upstream repositories at arbitrary times. You can refer to the sha256 of base images to avoid things changing, but I've never seen anyone do that. (The advice is "never use 'latest' because that could change out from under you", but other tags are just as mutable, and so that isn't real advice. You can follow the advice and have something just as bad happen.) The thing the upstream Linux distributions are missing are a lockfile with the hashes of installed packages. Programming languages figured this out (go.sum, package-lock.json, etc.) but distributions have not. Thus, people are often running "whatever" in production, because they simply don't have the ability to lock dependencies properly. I assume Nix solves this problem, and people should pay attention to how important it actually is.
  - eptcyka 6y ago
    In production, the companies I work with certainly do rely on SHA256 checksums to specify the base images.
    - jrockway 6y ago
      Do they just build their own images for open source things? I have never seen a dockerfile that does that.
      - eptcyka 6y ago
        Yep.

GrantZvolsky 6y ago

I also phased out Docker for local, non-isolated workloads in favour of nix. It's saved me many hours of figuring out how to install software whose official packages don't work out of the box / aren't compatible with my distribution.

pknopf 6y ago

It's worth mentioning my pet project, Darch. https://godarch.com/ https://godarch.com/

mikepurvis 6y ago

I've examined this a number of times over the years for deploying a ROS (Robot Operating System) workspace to robots and laptops. Some of our competitors use snaps or various container technologies for this, but I've always felt that the isolation/sandboxing would be more of a barrier than a help— it's one more layer of udev rules and other indirection to have to punch through with another set of config files (and to no benefit as we're not trying to run multiple independent "apps" or anything). So currently at my org we use basically the same scheme I advocated for at a developer conference in 2016 [1]: we just build it all into a gigantic bundled debian package, and deploy that to the host system with apt. I keep revisiting these various technologies and all of them seem less mature than apt/dpkg, and mostly in service of features and capabilities which don't apply to my particular needs. Obviously I'm a bit of a niche case, and my needs aren't everyone's, but of all of them, nix is the one that seems to be doing the most that is truly interesting and different; being able to send a new nightly build out to users with requiring them to re-downloading an entirely new asset would be a major win. [1]: https://vimeo.com/187705228 https://vimeo.com/187705228

strogonoff 6y ago
I also suspect OS package managers are underused when it comes to deployments. I am guilty of that too, some irrational wariness of end-user tools being fit to deal with developer workflows. That aside, there is one slight possible pitfall in discarding one tech because it is less mature than the other: if we assume maturity only increases with time, the oldest product (e.g. apt/dkpg) will always be “best”. Made a note for myself to prefer “not mature enough for my needs” over “less mature than X”.
- mikepurvis 6y ago
  I think for apt/dpkg, the system definitely does benefit from decades of careful, thoughtful design— for example you're pretty unlikely to come up with a version constraint between your packages which isn't expressible using the existing Debian scheme. And when I look at various modernish packaging systems, I often see a lot of this thrown out as unneeded complexity, only to be cobbled back in later when it's discovered how essential it really is (see for example Homebrew's long transition from being a dirt simple wrapper around "configure; make; make install" to becoming a full binary package manager). There's also the ecosystem benefit of having loads of helpers and supplementary tooling applicable to the formats— even stuff like having first-class support in proprietary binary stores like Artifactory, vs Nix where it's basically a shrug and "well... it works with any WebDAV server, so take your pick I guess?" The main complaint I have overall with Apt is the reliance on postinstall scripts, which means that even if you download and extract your packages in parallelized blocks, you still have a long serialized step when every single package needs to spawn a shell and run arbitrary commands, even if in most cases, the commands actually originate from a semi-declarative format (debhelpers, either invoked explicitly from the rules file, or implicitly by the presence of a corresponding debian/xyz file in the metadata). Anyway, if it were possible to somehow flag packages as atomic or configure-less, it might be possible to significantly speed up these operations, especially in environments like CI where you have everything mirrored in-network or possibly even on-machine so the overall install time is dominated by the package configure step.