151–156 of 156 posts
Earlier quoted context omitted.
Guix not supporting non-free packages out of the box is the only real issue I have and that’s directly tied to the gnu origins. If guix were as pragmatic as NixOS and nixpkgs then I don’t think I’d have anything to say, lisp is way nicer.
Keep an eye out for https://gitlab.com/nonguix/nonguix .
Earlier quoted context omitted.
> apt-get install = That's still not reproducible unless you use snapshot.debian.org or snapshot.ubuntu.com as upstream package index.
You can easily host and manage your own package repository. My point is that this apparent limitation is not in itself a strong enough reason to embark on NIX. Go fill your boots if you want to use NIX, power to you, but be honest about why if you're going to write a piece about it.
Sure, it's not hard but it's work nonetheless, plus you'll incur the costs of maintaining that infrastructure indefinitely. Compare that to creating a Dockerfile which uses https://github.com/reproducible-containers/repro-sources-lis... to fully pin its package sources and calling it a day.
Earlier quoted context omitted.
I find this to be a real issue with environment variables. I am trying to create a tool to help see exactly where and by which program any environment variable was set/exported since boot. This is still in the conceptual phase but I'm looking into linux' ftrace to achieve this. Any ideas or pointers are welcome.
Yeah I think you can definitely find which process sets environment variables (I think you just need to intercept execve or whatever). The real problem is finding which processes use the environment variables. That's extremely difficult, if not impossible.
Nix falls into the camp in my mind that includes Rust: great idea that I just don't have time for right now. Reproducibility is the holy grail, IMO. It is so valuable that any system that actually achieves it will find some longevity and eventually be hammered into a useable form. I believed in the promise when AWS was all about amis. Then I believed in the promise with docker. It seems something like Nix is a natura…
> Reproducibility is the holy grail, IMO > I'll stick with […] docker with alpine for my deployments Huh. In my experience Alpine is the worst possible base image to use if you care about reproducibility. - The package index's URL cannot be pinned (URL expires on a regular basis) - The downloaded package index itself (tarball) cannot be pinned/cached, either, because old package versions (i.e. the URLs in the tarball…
As with anything in engineering there are tradeoffs, there is no singular perfect solution. My choice of alpine was from years ago when I examined the amount of included code in competing docker images and I found the alpine solution was geared towards the least amount of code required to achieve the desired goal (e.g. running a server of a particular kind). That line of thought almost certainly requires a new examination of the available options since the world has changed since I last did a deep dive into docker base images.
In a perfect world I want a base image that doesn't contain a single bit extraneous to executing the services I deploy (for whatever expansive definition of "necessary" I arbitrarily choose). And in that perfect world the image is completely reproduceable from a static definition. Oh yeah, and it should be stable/robust, free from exploits, etc.
So it might be too strong to say "holy grail" if one interprets that as a singular goal that needs to be fulfilled. I meant it as "one among many" in the list of virtues I look for.
That being said, there are a lot of minimal *nixes these days and I would expect Nix would be a contender in that realm as well.
Nope, not yet. I tried that 3 times, once for my mac, then for my linux and once for a project. Every time I gave it a solid try found it lacking so I made a note to wait a few more years. The promise of reproducible systems is so hard to resist but nix brings crazy complexity (not all of it necessary), I'd prefer a system where their package repo has 4 packages but it makes it easy enough to me to bring other packag…
Earlier quoted context omitted.
Until your use case hasn't been deciphered by a Nix scribe and then you have to fight the magic.
Which makes "next to zero time wasted configuring things" false, very much so. You will have to write your own derivation(s) using Nix[1]. In any case, from the article, what does not apply to Guix, too? I am leaning towards Guix because of its language (Scheme, i.e. Lisp-y), but I wonder about the differences between the two, today (besides userbase and hype). [1] https://nix.dev/tutorials/nix-language.html