641–650 of 764 posts
Earlier quoted context omitted.
Nix solves the ad-hoc problem much more cleanly than Dockerfiles do
There’s purity of design/implementation and there’s usage. Often these are inversely related. I like nix - it’s probably the right direction, but just compare the UX to Docker. Comparatively Docker absolutely nailed it.
- devenv
- devbox
- others i'm forgetting
Earlier quoted context omitted.
> Come on, 30 days notice is a walk in the park Sure, maybe in a small business or startup, and even then I'd content not quite as easy as all that. When you're dealing with anything larger, say involving multiple teams, organisations, and priorities, 30 days is an insanely short shrift to look at figuring out what your actual route forwards is (and if you're provisioning something new, making sure you're allowed to…
If you're unable to take on a task that has a 30 day deadline in your org, regardless of size, you're experiencing a good amount of bloat.
Earlier quoted context omitted.
In many ways I agree with you. Just like Visual Basic 6, it's super-easy to get started with a Dockerfile, but nigh-on impossible to create a quality result with it.
There are similarities in the implementation as well, specifically around content addressable storage and layers. Nix needs reproducible builds as well, which is a limiting factor. What’s nice about Docker is that it’s flexible enough to actually get stuff done.
It doesn't have to be, Nix lets you choose your level of purity and it can build docker containers.
Earlier quoted context omitted.
> worlds better than the old ways of managing dependencies and making sure everyone on a project is aligned on what versions of things are installed. And Nix is worlds better than even this . Imagine!
Does Nix have an equivalent of docker-compose yet? nix-shell is amazing for installing binaries, but actually wiring up and running the services doesn't seem like a solved problem. Unless Nix expects a separate tool to do this once binaries are installed, of course.
I've linked it a few times in this thread already for that reason.
Edit: see https://devenv.sh/containers/
Earlier quoted context omitted.
Nobody is going to accept worrying about whether the torrent has enough people seeding in the middle of a CI run. And your usual torrent download is an explicit action with an explicit client, how are people going to seed these images and why would they? And what about the long tail?
> enough people seeding the .torrent file format, and clients, include explicit support for HTTP mirrors serving the same files that's distributed via P2P.
Earlier quoted context omitted.
docker-compose seems necessary only because you have your "official postgres dockerfile" and your self-built "web app dockerfile" (and maybe other things like an ElasticSearch dockerfile) Docker files seem necessary only because... well put it this way, think of a Docker image as "the cached result of a build that just so happened to succeed even though it was entirely likely not to, because Docker builds are NOT det…
except you cant deploy Nix files, and even if you could, better be sure that every employee is using Nix and have the same configuration. The whole point of docker is to make reproducible builds everywhere, not just your computer.
Ooh let me try...
"except you can't deploy Dockerfiles"
With docker you deploy the artifact, same with Nix. Nix can also create docker images.
> , and even if you could, better be sure that every employee is using Nix and have the same configuration.
How is this different than employees needing to have the same docker version?
In a large org, either will likely be provisioned.
> The whole point of docker is to make reproducible builds everywhere, not just your computer.
No.
Docker doesn't make reproducible builds, it makes repeatable builds.
The whole point of Nix is to make reproducible builds everywhere.
Earlier quoted context omitted.
That's why better to have NetBSD + pkgsrc combo for servers.
You misspelled Nixpkgs ;-) I'm kidding, of course, but IIRC pkgsrc (and alikes, such as APT) has a number of limitations, for example a very limited ability to have multiple versions of the same package installed, making it less than optimal replacement. (I believe a lot of people depend on ability to spin up a new version while the old is running, then do the cutover and shut down the old one after it's not is use.)
...and crucial features, like having security fixes backported.
As an SRE Manager, this is causing me a hell of a headache this morning. In 30 days a bunch of images we depend on may just disappear. We mostly depend on images from relatively large organizations (`alpine`, `node`, `golang`, etc), so one would want to believe that we'll be fine - they're all either in the open source program or will pay. But I can't hang my hat on that. If those images disappear, we lose the abilit…
If your business is depending on these open source projects to exist, shouldn't you be paying them so they can then pay for Docker?
Earlier quoted context omitted.
> except you cant deploy Nix files NixOps and nix-deploy: EXIST! https://arista.my.site.com/AristaCommunity/s/article/Deploy-... > better be sure that every employee is using Nix and have the same configuration. The whole point of docker is to make reproducible builds everywhere, not just your computer. lol, "tell me you never used Nix without telling me you never used Nix" because it literally guarantees that , each…
First you are tightly coupling your CI to your developers machine, that in itself is already a pretty bad idea. Second, if one employee wants to install htop on their machine, then every employee will have to install it, this can quickly become a problem when you have 500+ developers. Third, I think you missed the first part on the second quote, you are FORCING every developer to not only use linux but also to use on…
How?!
Earlier quoted context omitted.
The images you mention (alpine, node, golang) are all so-called “Docker Official Images”. Those are all the ones without a slash as the namespace separator in them: https://hub.docker.com/search?q=&type=image&image_filter=off... They are versioned and reviewed here: https://github.com/docker-library/official-images I don't expect them to go away. Disclosure: I maintain two of them (spiped, adminer).
"don't expect" or "for certain"? Can't really plan ahead without some kind of certainty.
If you are relying on images hosted by a third party, you have already committed to relying on something without certainty.