22 ms·

I Was Wrong about Nix

278 points by xena 7y ago

oldwinebottles 7y ago
Happy to see more people interest in Nix. At the end of the post there are some links on learning resources, that list is 100% the best way to get started.
- thundergolfer 7y ago
  I'd also highly recommend reading at least the first two parts of the Nix author's PhD thesis: https://grosskurth.ca/bib/2006/dolstra-thesis.pdf https://grosskurth.ca/bib/2006/dolstra-thesis.pdf It really clearly explores the problem space Nix dives into. I learnt a lot about why Nix needs to exist.
srik 7y ago
Caution for OS X users — https://github.com/NixOS/nix/issues/2925 https://github.com/NixOS/nix/issues/2925
- echelon 7y ago
  Why do they require /nix to be writable? It seems like the cache path should be user configurable. This reminds me of GOROOT/GOPATH and other complexities that arise when systems care too much about paths.
  - costrouc 7y ago
    There is a very good reason. Nix strives to be reproducible. Thus all hardcoded paths in builds have to point somewhere. /nix was chosen.
    - hpfr 7y ago
      I recognize your nick—I found a few comments of yours [0] [1] that were intriguing. You should publish your config, if you can sanitize it. [0]: https://old.reddit.com/r/linux/comments/9o44id/how_do_you_automate_your_distro_setup/e7sxhko/?context=3 https://old.reddit.com/r/linux/comments/9o44id/how_do_you_au... [1]: https://old.reddit.com/r/NixOS/comments/9mm2pb/syncing_across_machines/e7g65nq/?context=3 https://old.reddit.com/r/NixOS/comments/9mm2pb/syncing_acros...
    - kohtatsu 7y ago
      Sure, but you can translate the user-configured path to be /nix on inputs and outputs.
    - rgoulter 7y ago
      So, if you were to build a package assuming /opt/nix instead of /nix, the sets of packages would be entirely different. The "can't" is more of a "seems impractical" than "hardcoded assumption in the nix program itself".
      - zeckalpha 7y ago
        This ignores chroot
    - echelon 7y ago
      I don't mean to slight you or the effort you've put into this if you're an author or maintainer, but that's a terrible rationale. Given this choice, your tool doesn't fit well with other software, and from a systems perspective, it feels slightly egotistical. In the future, file systems will be immutable and only a few sanctioned volumes will be writable (if any). It'd be better if systems like this abstracted away the notion of the file system and operating system altogether. Everything should be virtual and that is how hermeticity and reproducibility should be achieved. That said, I admire the work you're doing and can't really point fingers as I'm not a contributor.
      - catalogia 7y ago
        > In the future, file systems will be immutable and only a few sanctioned volumes will be writable (if any). If any?! Where do I put my files if not on a filesystem? In some corporate cloud? Writable filesystems for corporations but not for the common plebian? Is that the sort of dystopian future you're envisioning? If I've misunderstood what you're saying, then I apologize. But I'm alarmed by my perception of what you're saying.
        echelon 7y ago
        Some IDEs allocate config directories in your homedir: .idea, .vscode, .vim Some of them do it under .config. Some systems write to /usr/local Some things scope to the project you're working in. Python venv, node_modules, etc. Build systems, such as Cargo, Maven, and Pants each do their own thing. Make, autotools... Have you looked at an Android filesystem? I don't even know how to describe it. Everything everywhere is horribly inconsistent. I'm thinking in terms of workloads, of which building and linking are merely types of work that produce artifacts. There are many types: server workloads, jobs, userland software. If you semantically declare what a workload needs, what dependencies it has, where those dependencies must exist, and what outputs it produces, everything can be wired together logically and hermetically. I'm hoping the immutable containers of the Docker/microservice world make their way onto the desktop. If I can reduce my entire desktop environment into a single config file and have it reliably reconstruct itself, it would be magical. I would freeze and wipe my machine constantly. Of course writable, mutable volumes will exist for humans, but software can't play in that realm or it will lose hermeticity. I've sort of gotten off track and am no longer speaking about package managers / build systems. I think there's a more general solution to all of these problems.
    - xenadu02 7y ago
      Taking a top-level directory isn't very good form IMHO. I understand wanting a hard-coded path but /opt/nix seems more in keeping with the Unix philosophy.
      - Annatar 7y ago
        It would be /var/opt/nix since it's data. Payload in /opt/nix and configuration in /etc/opt/nix. That's what the specification states.
- anarchogeek 7y ago
  I find it pretty stunning that Nix has decided to drop support for OS X over ideological reasons like this. There are workarounds, but the reality is that they're upset at apple's decision so they just dropped support. We're not close to a year in to this these issue threads. Any software which would be so anti-user does not deserve to be used. Nix might be magical but that sucks.
  - comex 7y ago
    > I find it pretty stunning that Nix has decided to drop support for OS X over ideological reasons like this. What are you talking about? There’s no such decision. The first comment mentions it as a possibility, but the rest of the (very long) thread is exploring different ways to solve the issue.
  - user555555555 7y ago
    Can you provide a link to where it says they have actually droped support. In that link they describe how to make a firmlink, its seems like they have a way to just keep doing their thing as before (edit, reworded)
    - whateveracct 7y ago
      It's FUD
  - tottenhm 7y ago
    This comment confuses me. It makes it sound like some authoritative figure came in and said, "Nix shall not support OS X because Apple is evil." But to my eye, this is not at all borne out by the thread. There's one or two early comments which float the idea that Apple/Catalina's problematic technical change "may force us to drop support for macOS...". That prompted lots of -1's, and then there's a gigantic thread where people are trying to figure out how to adapt, and that's an on-going/non-trivial process. Did I miss something? Is there actually a policy decision buried mid-thread that's hard to see? In your comment, I pick up some fear/vulnerability. There's no reassuring voice to say, "macOS Catalina support will be fixed yesterday!" I share that sense of fear/vulnerability, but I think it's a natural trade-off when you sign up for free/open/transparent/community-driven software. For better and worse, you get to watch how the sausage is made in real-time.
- kohtatsu 7y ago
  I'm lost, why does nix care so much about things being in /nix and not, for example, /usr/local/nix?
  - infinisil 7y ago
    - /nix has been the (default) location for at least 15 years without problems, changing this now just because Apple messed with this would be very strange - With Nix, every path in /nix/store has its own ./bin, ./share, ./lib, etc. As such, putting /nix anywhere but in / doesn't make much sense - And honestly, it's just short, fresh and distinctly different. The path symbolizes that Nix isn't bound by the conventions of other distro's And problems with changing this now: - It would be a huge amount of effort, there's many places where this location is assumed, not only in code, but also by people - Finding the workforce to actually do this change will be near impossible, as the only benefit is a slightly easier installation for the latest macOS version, which is not Nix's main platform
Legogris 7y ago
I've been using NixOS on my laptop for a couple of years now and I am still embarrasingly undereducated on how to do some of even basic things. I feel I still haven't fully grokked "the nix way". You will need to understand it pretty well to do even basic things like running specific versions of ruby or python with specific native libraries. I have spent a couple of hours here and there on nix pills but I think one really needs to set aside some concerted time to get into it properly. I consider myself fairly proficient with Linux in general and never had this kind of steep learning curve with other distros. (This is a not me criticizing NixOS, just noting that they do things very differently and you really need to invest some time and effort to start being able to solve your own problems rather than relying on what's provided by others)
- ngcc_hk 7y ago
  You frighten me a bit here. I looked at the article and have the ability to build a web site in a minimum locked env is great. Just try to taste it and it seemed not as he said. Wonder now.
  - ardfard 7y ago
    You don't really need to use NixOs to use Nix really. I use Nix inside my Ubuntu laptop to pin all my projects dependecies and it worked great.
    - ngcc_hk 7y ago
      Thanks. I would try. But given I know lisp a bit. May try the g one first.
- newnewpdro 7y ago
  Can't you just throw it in a container to explore and learn the ropes before pivoting your entire host?
  - deleted 7y ago
    [deleted]
prpl 7y ago
A little disingenuous to compare without docker multi-stage.
- Legogris 7y ago
  Care to elaborate?
  - prpl 7y ago
    You don’t typically include the entire toolchain in a container with docker because of the size. You also want to construct things a bit carefully so you get proper build caching, but it’s doable. Here is an example of this pattern with Go: https://github.com/pusher/oauth2_proxy/blob/master/Dockerfile https://github.com/pusher/oauth2_proxy/blob/master/Dockerfil...
    - Legogris 7y ago
      Right, but how does that relate to OP?
    - xena 7y ago
      FROM xena/go:1.13.6 AS build ENV GOPROXY https://cache.greedo.xeserv.us COPY . /site WORKDIR /site RUN CGO_ENABLED=0 go test -v ./... RUN CGO_ENABLED=0 GOBIN=/root go install -v ./cmd/site FROM xena/alpine EXPOSE 5000 WORKDIR /site COPY --from=build /root/site . COPY ./static /site/static COPY ./templates /site/templates COPY ./blog /site/blog COPY ./talks /site/talks COPY ./gallery /site/gallery COPY ./css /site/css HEALTHCHECK CMD wget --spider http://127.0.0.1:5000/.within/health || exit 1 CMD ./site As far as I understand, this is a multi-stage build.
      - _-___________-_ 7y ago
        Yes, but it goes to the trouble of making a static, dependency-free executable in the first stage, and then builds the second stage from alpine anyway.
- 7y ago
dragonsh 7y ago
If you like Nix than probably try GNU Guix [1] and if possible use Guix System on server side. This is one of the most modern development in operating systems. In the modern security conscious world where most companies run their workloads on virtual machines controlled by other companies, it's imperative that applications are deployed on such predictable, secure and reproducible operating systems. Guix supports transactional upgrades and roll-backs, unprivileged package management, and more. When used as a standalone distribution, Guix supports declarative system configuration for transparent and reproducible operating systems. I still think Amazon, Google and Azure will take a decade or two to build and offer something like this to it's customers. Indeed Google's Fuschia is trying to do the same, but I feel it's at least a decade away. It has one of the best wonderful documentation [2] to get started and explore with all the details. [1] https://guix.gnu.org/ https://guix.gnu.org/ [2] https://guix.gnu.org/manual/en/html_node/ https://guix.gnu.org/manual/en/html_node/
- ozataman 7y ago
  If I could trouble you for the common discourse here, would you mind summarizing why one may prefer to use Guix in the place of Nix? They seem to be based on the very same ideas and Guix even admits to being inspired by Nix.
  - kragen 7y ago
    Scheme instead of a bespoke programming language, and more focus on reducing the bootstrap set that compromises the goal of reproducibility shared by both systems.
    - svd4anything 7y ago
      But the bespoke language has some benefits. It’s concise and specifically designed for the problem. Also Nix has more contributors and that is very important to have a large collection of recipes to start from.
      - Koshkin 7y ago
candiddevmike 7y ago
I've tried to use Nix in the past, but I can't get past the layers of abstraction. Normally I go and consult the relevant docs for what I'm trying to configure (postgres, systemd, etc), but with Nix I also need to consult the Nix docs and figure out the discrepancies/map values between them. I love the idea of systems configuration like this, but I'd much rather see less abstraction ala cloud-init with nixos-rebuild. For those who use Nix, how do you deal with this kind of abstraction? Additionally, how soon do you see security updates land?
hardwaresofton 7y ago
I still don't see the light. I'll try and lay out my reservations, starting with the pain points of the docker image (out of order to coalesce some points): > The package manager’s database is included in the image > Most of the files in the docker image are unrelated to my website’s functionality and are involved with the normal functioning of Linux systems So remove it...? Docker multi-stage builds[0] make this really easy, though I still use separate containers for different times (building, testing, etc), and sometimes even multiple "stages" of containers for languages that take a long time to build (Haskell). > The package manager is included in the image Assuming you don't want the package manager itself, why not just use a scratch[1] or distroless[2] image? Well of course it's harder than one might expect to use those options (distroless is actually fine), because of the lie of "statically building" anything on most distros other than alpine, which brings us to the next pain point... > An entire copy of the C library is included in the image (even though the binary was statically linked to specifically avoid this) Using alpine gets you much closer (if not all the way there) to a proper static binary w/ musl libc. You may have to look into things like replacing the use of libnss or certain systemcalls with golang libraries, however[3]. My biggest problem with nix is that it just isn't worth the effort -- The ~5+ paragraphs of nix tools and scripts is just not at all attractive to me personally when I know roughly a day's worth of fiddling to get a proper static build is good enough most of the time. I've heard amazing things about nix, nixops, and all the tools there-in but there just isn't enough pain IMO to warrant completely changing how to do things. Nevermind the fact that disks get cheaper and cheaper, network gets faster and faster, and people are starting to look into pre-emptively sharing container images across meshes of nodes with tools like Dragonfly[4]. Another point that is somewhat related -- if nix is good, guix has to be better on some level (excluding factors like ecosystem) purely because it uses a full-blown language for the config (i.e. terraform vs. pulumi). It doesn't seem like nix will hold enough value before unikernels "arrive", then the problem of taking your distribution along with the program you want to deploy disappears alltogether. [0]: https://docs.docker.com/develop/develop-images/multistage-build/ https://docs.docker.com/develop/develop-images/multistage-bu... [1]: https://hub.docker.com/_/scratch/?tab=description https://hub.docker.com/_/scratch/?tab=description [2]: https://github.com/GoogleContainerTools/distroless https://github.com/GoogleContainerTools/distroless [3]: https://github.com/golang/go/commit/62f0127d8104d8266d9a3fb5a87e2f09ec8b6f5b https://github.com/golang/go/commit/62f0127d8104d8266d9a3fb5... [4]: https://d7y.io/en-us/docs/userguide/download_files.html https://d7y.io/en-us/docs/userguide/download_files.html
nitrix 7y ago
As much as I admire the people involved with Nix, taking the initiative to solve what they believe can be improved and the other developers like her, toying with new things and successfully managing to figure all this stuff out... I'm actually disappointed. The thing is, Nix is an absurdly complex piece of software, perhaps on a similar order of magnitude as maybe Kubernetes or other gizmos, requiring a very large time commitment to understand and to use properly. Just for fun, have any of you tried to keep up during the Docker bigbang, with all these technologies popping up left and right, switching names, dying abruptly, getting super-seeded or hacked with vulnerabilities? That was one of my most mentally draining year for me and I've been in the field for a while now. See... along the way, I've learned that Computer Science is always about tradeoffs. Now when I'm being asked to trade away my sanity learning this nonsense for in return a couple of megabyte of disk space that could've been wasted, I just don't see the value. Seriously, are we optimizing for the right stuff here? I know Nix is doing package isolation with a programmable environment defined by text files, it's immutable and all. I get it. But we have alternatives for these problems. They do a pretty good job overall and we understand them. Ironically, even those solutions I'm comfortable with are still struggling to get good adoption! How the heck is our field going to avoid fragmentation when it keep growing exponentially like this. Perhaps it's just me aging and getting groggy; though there must be an explanation for this phenomenon. Please, it definitely gnaws at me.
- Aloha 7y ago
  We just keep trying to hide complexity and fragility with more layers of redirection and abstraction - it doesnt solve the problem, but it makes it tomorrows problem. In the end, excessively clever people make me nervous, because they leave complex problems in their wake, which I'm not clever enough by half to solve.
  - ertian 7y ago
    I agree with you, mostly, but I really think Nix is one of those rare abstractions that is easily worth it: it has the potential to simultaneously solve and unify a bunch of different issues: reproducable builds, package management (system & language), container creation, system config, and so on. One language across all those domains is great, and the ability to rollback an entire system is amazing. Also: the ability to add your own software, GitHub tarballs, and piles as PHP as first-class citizens (you can cleanly remove them!) isn't emphasized enough. You can keep your wget, build script, db config, and nginx config all in the same file! I think if you weighed the complexity of Nix, and NixOS in particular, against the tools it replaces (or anyway, could potentially replace) it's a no-brainer. I'm a convert.
anonsivalley652 7y ago
If they built their app differently, such as using a temporary directory rather than building it in tree in the release path, they could've used staged builds to cache their steps in docker. What they do get from Nix package management is freedom from dependency hell. Actually, I prefer habitat (hab) for portable Linux packaging because it supports a crazy amount of caching, it does GC on unneeded packages, it has an internet-visible package repo to publish to and has a simple DSL that I can teach to anyone. I don't use its other features that much, and I don't use it on FreeBSD but I use hab studio on macOS now and then. Nix is pretty awesome because it almost marries package management and configuration management... if you think about it, the definition of a conventional OS package is an arbitrary one that limits configurability and customization. Gentoo, Arch and others try to work around it, but you really can't unless you can drive and hook intelligently into specification language that built the package and can accept modifications at different points without a lot of kludgy hacks or forks. Furthermore, the conventional package paradigm assumes one version and one configuration for everything, unless you want to get messy with variant packages. Nix and hab solve these issues. The problem is I can't suggest it in a lot of usage contexts because it would be like if I recommended Rust, Elixir or Haskell to a PHP shop. ;) I really want to but I know it's probably not a good idea. Nix is awesome wherever the badassometer says "above average." Give it a try, but use what works best. Best practices > Leverage build cache: https://docs.docker.com/develop/develop-images/dockerfile_best-practices/#leverage-build-cache https://docs.docker.com/develop/develop-images/dockerfile_be... Multi-stage build: https://docs.docker.com/develop/develop-images/multistage-build/ https://docs.docker.com/develop/develop-images/multistage-bu...
- ses1984 7y ago
  >If they built their app differently, such as using a temporary directory rather than building it in tree in the release path, they could've used staged builds to cache their steps in docker Can you explain this just a bit more, please? I was just reading the two articles you linked today, and your comment seems there is some piece of insight that's missing. If you search the multi-stage build article for "cache" the only hits are related to not using cache. What should I do if I want to leverage the cache as much as possible in a multi stage build?
kragen 7y ago
Yeah, Nix (or Guix) is kind of Docker Done Right.
- Sean1708 7y ago
  I think it's a lot more complicated than that. Yes there are plenty of people that use Docker as a package manager, but I think that's a failing of traditional package managers rather than a failing of Docker. You could, for exactly the same reasons, say that Nix is Nix Containers[1] Done Right but if that were true then Nix Containers wouldn't need to exist in the first place. [1]: https://nixos.org/nixos/manual/#ch-containers https://nixos.org/nixos/manual/#ch-containers
dr01d 7y ago
I would recommend multistage build but with distroless as final. https://github.com/GoogleContainerTools/distroless https://github.com/GoogleContainerTools/distroless
- fcarraldo 7y ago
  This seems like the real answer to this problem. I really like Nix conceptually, but the problem it's being used to solve in this case is already solved by Docker, and using a multistage build with a Distroless stage relies on fewer dependencies, fewer tools, and many fewer lines of config.
whateveracct 7y ago
I use Nix for every project once it grows enough for me to have to pin a directory. And sometimes sooner. I don't know it that well but I've picked up on design patterns, use the repl to figure stuff out, write small abstractions when necessary..and it works pretty great. And the gains grow as my dependencies become polyglot (even C + another language like Haskell..but when you add compile-to-JS, static asset generation into the mix it's amazing) Yeah it's hard to learn. No denying it. But every other "alternative" I've found doesn't actually approach it. So I've kind of gotten sick of reading about "alternatives" because it always feels like they don't actually solve the problem Nix solves. I always end up using the alternative+Nix. Classic example of this is the Haskell stack build tool. I could've bemoaned complexity and various capitalist criticisms when I first ran into it at a job. But I'm so much better off for not.
daenz 7y ago
Most of their complaints about Docker, specifically: * The package manager is included in the image * The package manager’s database is included in the image * An entire copy of the C library is included in the image (even though the binary was statically linked to specifically avoid this) Can be solved with Docker multi-stage builds[0]. This is essentially a separate build stage inside your single Dockerfile that sets up, builds, and creates artifacts. Those artifacts are then copied over into a later build stage. The resulting docker image is lean and yet the artifacts were built at docker build time, and its all contained in a single file. 0. https://docs.docker.com/develop/develop-images/multistage-build/ https://docs.docker.com/develop/develop-images/multistage-bu...
- takeda 7y ago
  The author did use a multi stage build.
  - xena 7y ago
    A ridiculously slim multi-stage build, but it was starting to show its weaknesses.
  - daenz 7y ago
    My mistake, you're right. I'm thrown off by the idea of someone using a multi-stage build and still having those complaints. Just use/build a final base image that is lean enough for your needs. You're not forced to have any cruft you don't want.
- deleted 7y ago
  [deleted]
kalium_xyz 7y ago
The effort involved in using nix becomes a lot less if you make templates and have IDE support.
tlrobinson 7y ago
> The image age might look weird at first, but it’s part of the reproducibility Nix offers. The date an image was built is something that can change with time and is actually a part of the resulting file. This means that an image built one second after another has a different cryptographic hash. It helpfully pins all images to Unix timestamp 0, which just happens to be about 50 years ago. This doesn’t mean builds done by Nix are bit-for-bit reproducible by default, does it? There are a lot of other ways to introduce non-determinism in builds, like rand() or network requests (which I think could only be eliminated in a generic way by literally emulating the CPU of the machine doing the build and not allowing external communication?)
- takeda 7y ago
  The nix by default makes builds in a sandbox. It is purposefully making certain operations unavailable (local home directory, local configuration, network access etc). I don't think it prevents Rand(), but that's not as common.
- fctorial 7y ago
  It provides the hash of files as a method of verifying the input identity. As long as the build file is pure function of build tools (gcc, make, etc), and the build tools themselves are deterministic, the build outputs should be reproducible. Though I've never seen anything like `-frandom-seed=<input-file-name>` in build files. I think bit-by-bit reproduciblity is one problem tackled by guix.
  - danieldk 7y ago
    I think bit-by-bit reproduciblity is one problem tackled by guix. I think the Nix folks are also interested to some extend. Currently, almost 99% of the paths in the minimum installation image are reproducible: https://r13y.com/ https://r13y.com/
eximius 7y ago
I still haven't figured out the nix language, how to find which package installs a particular binary if it isn't the name of the package, or how to find config options for packages I do have. Those three problems are what's holding it back for me. I still enjoy it so far, though.
- SitiSchu 7y ago
  To find out which config options exist for packages searching here can be quite helpful: https://nixos.org/nixos/options.html https://nixos.org/nixos/options.html Another way would be reading the nix expression on the nixpkgs GitHub repository.
Annatar 7y ago
This is so wrong on so many levels. So many complications. Monstrously huge binaries. Static linking. Docker and Nix mess of complex instructions, all custom. With RPM, it is one command, rpmbuild, with a standardized spec file and no need to link statically. No Docker image needed, or anything else. Just plug into a yum repository or into a Kickstart install group and you're done. No code or compose files or playbooks to write. Turn the VM on and have it automatically PXE / DHCP / TFTP boot and Kickstart install it with the desired software and configuration. Without writing a single line of code or lifting a finger.
- Nullabillity 7y ago
  And now your setup depends on working PXE (which requires custom DHCP config!) and a custom RPM registry. How is that less complex operationally? And you need to write custom rpmspecs and kickstart manifests. Do those not count as code? Kickstart also doesn't help you with any day-two ops concerns.
  - Annatar 7y ago
    "Custom DHCP config"?!? You do realize DHCP stands for "dynamic host configuration protocol"? That's exactly what it was designed for... And if you can't get "working PXE" (PXE is implemented in firmware, by the way), you might want to brush up on the basics of putting together an IT infrastructure, or this moment might be a good time for a career switch out of IT... There are no "Kickstart manifests", it's a ruleset. There is no "RPM registry" (this isn't Windows™️) or anything of the sort. There are no "custom spec files" as it's a formalized format with grammar and lexicography which the OS's software management subsystem understands - it's like putting a VHS tape into a video cassette recorder, modular and standardized. Day two is where a software deployment server and clearly defined change management process according to the department of defense capability maturity model come into play.
    - Nullabillity 7y ago
      > "Custom DHCP config"?!? You do realize DHCP stands for "dynamic host configuration protocol"? That's exactly what it was designed for... Usually used for assigning network configuration dynamically. I'd venture a guess that most people never touch their DHCP configuration, aside from assigning DNS and IP pools. And good luck getting your hosting provider to give you raw access to their DHCP config. > And if you can't get "working PXE" (PXE is implemented in firmware, by the way), you might want to brush up on the basics of putting together an IT infrastructure, or this moment might be a good time for a career switch out of IT... There is a lot more to stable PXE than having a client. Nevermind the insanity of effectively giving anyone who can broadcast IP packets root access to all new servers. > There are no "Kickstart manifests", it's a ruleset. Different words, same thing. > There is no "RPM registry" (this isn't Windows™️) or anything of the sort. Correct, guess I've done too much Docker recently. Meant RPM repository. Unless you're shipping around your RPMs manually? In which case, I refer back to the day two question marks. > There are no "custom spec files" as it's a formalized format with grammar and lexicography which the OS's software management subsystem understands - it's like putting a VHS tape into a video cassette recorder, modular and standardized. So.. the same as Nix definitions then? Except with Nix you don't have to worry about whether the system was set up for VHS or Betamax. > Day two is where a software deployment server and clearly defined change management process according to the department of defense capability maturity model come into play. So.. completely unrelated to the process you've advocated so far?
jolmg 7y ago
It's been years since I last tried NixOS. One of the things that I really didn't like was that changing something that had a lot of dependencies meant that everything that depended on it, needed to be rebuilt. That's so even if I knew the change couldn't affect how the dependencies would be built. I know why NixOS requires that. I think that's really cool from a safety side, but it was also really annoying to have to wait so, so long to use the system after an insignificant change. I wish there were a "I know what I'm doing; let me risk screwing up" mechanism. I don't know if there's one now, but I kind of doubt it. I imagine Guix would have the same problem.
- corysama 7y ago
  “even if I knew the change couldn't affect how the dependencies would be built.” That works wonderfully until it bites your face.
  - jolmg 7y ago
    Well, it depends on the change. For example, fixing a misspelling in a manpage could technically break something, but I think anyone would agree that it's fairly low risk. Likewise, there are changes one could make to code that could be easily judged to be low risk at breaking something. Being able to take the risk at your own judgment is what would be wonderful. In any case, such "bite your face" moments wouldn't necessarily be visible at the build-time of dependent packages. Rather, they'd be visible when running them. So, you end up waiting for all your dependents to be built exactly like they were already and still exhibit the bug you would have also seen using the previous build.
- Ericson2314 7y ago
  You want https://github.com/NixOS/rfcs/pull/62 https://github.com/NixOS/rfcs/pull/62. I'm very eager to see it done this year (ideally earlier but don't want to jinx myself).
  - bb010g 7y ago
    Holy shit, thanks for linking this.
pmarreck 7y ago
It is honestly great to have a tool that solves so many problems at once but the resultant complexity is intimidating for most developers I feel.
- takeda 7y ago
  This is true, it takes quite a bit of effort to learn it. I think what Nix needs is perhaps series of tutorials targeting how to solve common problems that nix is useful for. There are plenty of things that are abstracted in nixpkgs, so perhaps use them as building blocks and explain how they are implemented in different articles.
krick 7y ago
What's even the point of top-level domain "website"?
zegl 7y ago
Setting CGO_ENABLED=0 does not make the build fully static. To do this you currently need to set the following flags: -ldflags '-extldflags "-fno-PIC -static"' -buildmode pie -tags 'osusergo netgo static_build' See https://github.com/golang/go/issues/26492 https://github.com/golang/go/issues/26492
dfc 7y ago
> This article was posted on 2020 M2 10. What is "2020 M2 10"?
- deleted 7y ago
  [deleted]
- _Nat_ 7y ago
  Looks like that author prefixes the month with "M". Dunno why. Sometimes DD-MM-YYYY and MM-DD-YYYY can be confused, such that if one of those formats is used, it could be helpful to clarify. However, YYYY-MM-DD is typically pretty unambiguous, so it seems odd here. I guess it's probably meant in analogy to, e.g., "2020-Q1" (which would be the first Quarter of 2020) or "2020-H1" (which would be the first Half of 2020).
  - xena 7y ago
    I do it because it's visually unambiguous. It is clear what is the day number, what is the month number and what is the year number. I have no idea where Apple got this, but it's the date format used in the iOS Lojban locale. I kinda got used to it because it's also faster for me to type.
- bb010g 7y ago
  Year 2020, month 2 (February), day 10 (the 10th). In RFC-3339, 2020-02-10.
- xena 7y ago
  Year 2020, Month 2, Day 10
  - dfc 7y ago
    If the day is a single digits do you prepend D to it? Eg October 2nd?
kstenerud 7y ago
My only foray into nix was cut short because my 2gb machine RAN OUT OF MEMORY installing a package.
- fctorial 7y ago
  Well, it's not just a wrapper around "tar xf"
axilmar 7y ago
After reading the web page posted above, and the comments in here, I've reached the conclusion that Docker, Nix, etc are trying to solve a problem that shouldn't exist, and that the actual problem is at the operating systems' provided mechanisms for dealing with programs and dependencies. More specifically, it seems like the Unix filesystem layout, with its bin, etc, usr and other well-known directories is part of the problem. Also, the environment variables mechanism is part of the problem. Why couldn't we have a much simpler mechanism for running things? for example: a) each application should live in its own directory. b) each file or folder should be versioned. c) common files for applications, for example, fonts, should be installed in the application folder themselves, and the filesystem shall provide hooks for external systems to be notified when these files are created, moved or deleted. With this system, important files, for example tool executables, would automatically be found and invoked without the need for adding a path to them. d) runtime program dependencies should be provided via text file with parameters and not by environment variables. This text file would have to be specified each time a program runs, and the user could create specific scripts that run the program with specific parameters. Programs should have attached, in the same folder, the default parameters file. How's that different from environment variables? well, with this system there is no system-wide dependency of a program to a unique string, and therefore the requirement to override environment variables for specific programs wouldn't exist. I.e. programs shouldn't need environments to run, but list of dependencies. With the above solution, making repeatable and sharable development and test environments would be extremely easy: just copy the application folders and the configuration files one needs. If something is missing, copying it from another source would be the solution. Ultimately, having a set of programs at hand and wanting to combine them to produce some output is exactly the same as having a bunch of functions in a program and invoking them in a specific order to get some result. And while in programming we have recognized the problem of global state and we have taken measurements to minimize the problem, for example with functional programming, we haven't done so for programs. In other words, the problem is that we are trying to compute things using global state, once more, this time at the operating system level! For me, that's the fundamental issue. All these tools are welcomed, but unless the fundamental problem is solved, no real progress shall be made and there is always going to be tool fragmentation (i.e. do we use Nix? Docker? Some other solution? etc).
deleted 7y ago
[deleted]
h91wka 7y ago
I have to do a bit of DevOps at work, and I absolutely hate every second of it, hence I tried Nix, and I think it is absolutely awesome. As a software developer, I find the ability to take a cryptographically consistent closure of a program's environment and deploy it in a reproducible way across your dev, loadtest and prod machines _the only reasonable way_ to do things. Not to mention that Nix community is very knowledgeable and open to patches and suggestions. However after a brief investigation period I abandoned this idea altogether, here's why. In my opinion, Nix is only worth climbing its steep learning curve when you really utilize its "reproducible environment" concept. As a counterexample, take your home PC environment, which is 1) unique 2) quickly changing. You don't need to reproduce it very often (how often do you upgrade your laptop?). You don't really want a hash-perfect reproducibility there, and a simple Ansible script will work just fine. So, the target of Nix should be "serious enterprise", where you deploy hundreds of machines, right? Well, "serious enterprise" where I am at (banking) will _never_ adopt Nix. There are two main reasons why: 1) NixOS doesn't follow standard Linux filesystem hierarchy. They get around this by patching everything, both manually and automatically. nixpkgs repo contains thousands of patches. To put it in the perspective, OS is one of your trust anchors. I don't want to sound as "no one got fired for choosing IBM" guy, but legal people will scream bloody murder if they see extensive level of patching going on in the distro, for a variety of reasons, not necessarily tied to security. Some of their patching goes very deeply, BTW, and straight up changes behavior of the software. 2) Secrets management: it doesn't exist in Nix. nix store itself is world-readable. There are fundamental problems with some cryptographic algorithms that require entropy, and therefore go against "reproducible environment" concept. YMMV, but for me Nix didn't do the job, although I studied it deeply, and contributed some patches to nixpkgs. It looks like a futuristic research project. On the outside it is brilliant, but in brutal reality you need to run the ugliest scripts to patch shebangs and what not.
- fctorial 7y ago
  > Some of their patching goes very deeply, BTW, and straight up changes behavior of the software. Can you give some examples?
  - h91wka 7y ago
sagebird 7y ago
I am not familiar with the topic at hand. I know that include os stuff is young. But I wonder, would it be easier to build the website with go, with an os included, and then deploy that? Both the docker and nix approach seem like alot of random tasks or knowledge is required. Are there bad things about including an OS I am forgetting?
aliswe 7y ago
> And the output is 16 megabytes smaller. Am I missing something here? Is this the point? 16MB of saved space?

278 points by xena 7y ago

Happy to see more people interest in Nix. At the end of the post there are some links on learning resources, that list is 100% the best way to get started.

thundergolfer 7y ago
I'd also highly recommend reading at least the first two parts of the Nix author's PhD thesis: https://grosskurth.ca/bib/2006/dolstra-thesis.pdf https://grosskurth.ca/bib/2006/dolstra-thesis.pdf It really clearly explores the problem space Nix dives into. I learnt a lot about why Nix needs to exist.

srik 7y ago

Caution for OS X users — https://github.com/NixOS/nix/issues/2925 https://github.com/NixOS/nix/issues/2925

echelon 7y ago
Why do they require /nix to be writable? It seems like the cache path should be user configurable. This reminds me of GOROOT/GOPATH and other complexities that arise when systems care too much about paths.
- costrouc 7y ago
  There is a very good reason. Nix strives to be reproducible. Thus all hardcoded paths in builds have to point somewhere. /nix was chosen.
  - hpfr 7y ago
    I recognize your nick—I found a few comments of yours [0] [1] that were intriguing. You should publish your config, if you can sanitize it. [0]: https://old.reddit.com/r/linux/comments/9o44id/how_do_you_automate_your_distro_setup/e7sxhko/?context=3 https://old.reddit.com/r/linux/comments/9o44id/how_do_you_au... [1]: https://old.reddit.com/r/NixOS/comments/9mm2pb/syncing_across_machines/e7g65nq/?context=3 https://old.reddit.com/r/NixOS/comments/9mm2pb/syncing_acros...
  - kohtatsu 7y ago
    Sure, but you can translate the user-configured path to be /nix on inputs and outputs.
  - rgoulter 7y ago
    So, if you were to build a package assuming /opt/nix instead of /nix, the sets of packages would be entirely different. The "can't" is more of a "seems impractical" than "hardcoded assumption in the nix program itself".
    - zeckalpha 7y ago
      This ignores chroot
  - echelon 7y ago
    I don't mean to slight you or the effort you've put into this if you're an author or maintainer, but that's a terrible rationale. Given this choice, your tool doesn't fit well with other software, and from a systems perspective, it feels slightly egotistical. In the future, file systems will be immutable and only a few sanctioned volumes will be writable (if any). It'd be better if systems like this abstracted away the notion of the file system and operating system altogether. Everything should be virtual and that is how hermeticity and reproducibility should be achieved. That said, I admire the work you're doing and can't really point fingers as I'm not a contributor.
    - catalogia 7y ago
      > In the future, file systems will be immutable and only a few sanctioned volumes will be writable (if any). If any?! Where do I put my files if not on a filesystem? In some corporate cloud? Writable filesystems for corporations but not for the common plebian? Is that the sort of dystopian future you're envisioning? If I've misunderstood what you're saying, then I apologize. But I'm alarmed by my perception of what you're saying.
      - echelon 7y ago
        Some IDEs allocate config directories in your homedir: .idea, .vscode, .vim Some of them do it under .config. Some systems write to /usr/local Some things scope to the project you're working in. Python venv, node_modules, etc. Build systems, such as Cargo, Maven, and Pants each do their own thing. Make, autotools... Have you looked at an Android filesystem? I don't even know how to describe it. Everything everywhere is horribly inconsistent. I'm thinking in terms of workloads, of which building and linking are merely types of work that produce artifacts. There are many types: server workloads, jobs, userland software. If you semantically declare what a workload needs, what dependencies it has, where those dependencies must exist, and what outputs it produces, everything can be wired together logically and hermetically. I'm hoping the immutable containers of the Docker/microservice world make their way onto the desktop. If I can reduce my entire desktop environment into a single config file and have it reliably reconstruct itself, it would be magical. I would freeze and wipe my machine constantly. Of course writable, mutable volumes will exist for humans, but software can't play in that realm or it will lose hermeticity. I've sort of gotten off track and am no longer speaking about package managers / build systems. I think there's a more general solution to all of these problems.
  - xenadu02 7y ago
    Taking a top-level directory isn't very good form IMHO. I understand wanting a hard-coded path but /opt/nix seems more in keeping with the Unix philosophy.
    - Annatar 7y ago
      It would be /var/opt/nix since it's data. Payload in /opt/nix and configuration in /etc/opt/nix. That's what the specification states.
anarchogeek 7y ago
I find it pretty stunning that Nix has decided to drop support for OS X over ideological reasons like this. There are workarounds, but the reality is that they're upset at apple's decision so they just dropped support. We're not close to a year in to this these issue threads. Any software which would be so anti-user does not deserve to be used. Nix might be magical but that sucks.
- comex 7y ago
  > I find it pretty stunning that Nix has decided to drop support for OS X over ideological reasons like this. What are you talking about? There’s no such decision. The first comment mentions it as a possibility, but the rest of the (very long) thread is exploring different ways to solve the issue.
- user555555555 7y ago
  Can you provide a link to where it says they have actually droped support. In that link they describe how to make a firmlink, its seems like they have a way to just keep doing their thing as before (edit, reworded)
  - whateveracct 7y ago
    It's FUD
- tottenhm 7y ago
  This comment confuses me. It makes it sound like some authoritative figure came in and said, "Nix shall not support OS X because Apple is evil." But to my eye, this is not at all borne out by the thread. There's one or two early comments which float the idea that Apple/Catalina's problematic technical change "may force us to drop support for macOS...". That prompted lots of -1's, and then there's a gigantic thread where people are trying to figure out how to adapt, and that's an on-going/non-trivial process. Did I miss something? Is there actually a policy decision buried mid-thread that's hard to see? In your comment, I pick up some fear/vulnerability. There's no reassuring voice to say, "macOS Catalina support will be fixed yesterday!" I share that sense of fear/vulnerability, but I think it's a natural trade-off when you sign up for free/open/transparent/community-driven software. For better and worse, you get to watch how the sausage is made in real-time.
kohtatsu 7y ago
I'm lost, why does nix care so much about things being in /nix and not, for example, /usr/local/nix?
- infinisil 7y ago
  - /nix has been the (default) location for at least 15 years without problems, changing this now just because Apple messed with this would be very strange - With Nix, every path in /nix/store has its own ./bin, ./share, ./lib, etc. As such, putting /nix anywhere but in / doesn't make much sense - And honestly, it's just short, fresh and distinctly different. The path symbolizes that Nix isn't bound by the conventions of other distro's And problems with changing this now: - It would be a huge amount of effort, there's many places where this location is assumed, not only in code, but also by people - Finding the workforce to actually do this change will be near impossible, as the only benefit is a slightly easier installation for the latest macOS version, which is not Nix's main platform

Legogris 7y ago

I've been using NixOS on my laptop for a couple of years now and I am still embarrasingly undereducated on how to do some of even basic things. I feel I still haven't fully grokked "the nix way". You will need to understand it pretty well to do even basic things like running specific versions of ruby or python with specific native libraries. I have spent a couple of hours here and there on nix pills but I think one really needs to set aside some concerted time to get into it properly. I consider myself fairly proficient with Linux in general and never had this kind of steep learning curve with other distros. (This is a not me criticizing NixOS, just noting that they do things very differently and you really need to invest some time and effort to start being able to solve your own problems rather than relying on what's provided by others)

ngcc_hk 7y ago
You frighten me a bit here. I looked at the article and have the ability to build a web site in a minimum locked env is great. Just try to taste it and it seemed not as he said. Wonder now.
- ardfard 7y ago
  You don't really need to use NixOs to use Nix really. I use Nix inside my Ubuntu laptop to pin all my projects dependecies and it worked great.
  - ngcc_hk 7y ago
    Thanks. I would try. But given I know lisp a bit. May try the g one first.
newnewpdro 7y ago
Can't you just throw it in a container to explore and learn the ropes before pivoting your entire host?
- deleted 7y ago
  [deleted]

prpl 7y ago

A little disingenuous to compare without docker multi-stage.

Legogris 7y ago
Care to elaborate?
- prpl 7y ago
  You don’t typically include the entire toolchain in a container with docker because of the size. You also want to construct things a bit carefully so you get proper build caching, but it’s doable. Here is an example of this pattern with Go: https://github.com/pusher/oauth2_proxy/blob/master/Dockerfile https://github.com/pusher/oauth2_proxy/blob/master/Dockerfil...
  - Legogris 7y ago
    Right, but how does that relate to OP?
  - xena 7y ago
    FROM xena/go:1.13.6 AS build ENV GOPROXY https://cache.greedo.xeserv.us COPY . /site WORKDIR /site RUN CGO_ENABLED=0 go test -v ./... RUN CGO_ENABLED=0 GOBIN=/root go install -v ./cmd/site FROM xena/alpine EXPOSE 5000 WORKDIR /site COPY --from=build /root/site . COPY ./static /site/static COPY ./templates /site/templates COPY ./blog /site/blog COPY ./talks /site/talks COPY ./gallery /site/gallery COPY ./css /site/css HEALTHCHECK CMD wget --spider http://127.0.0.1:5000/.within/health || exit 1 CMD ./site As far as I understand, this is a multi-stage build.
    - _-___________-_ 7y ago
      Yes, but it goes to the trouble of making a static, dependency-free executable in the first stage, and then builds the second stage from alpine anyway.
7y ago

dragonsh 7y ago

If you like Nix than probably try GNU Guix [1] and if possible use Guix System on server side. This is one of the most modern development in operating systems. In the modern security conscious world where most companies run their workloads on virtual machines controlled by other companies, it's imperative that applications are deployed on such predictable, secure and reproducible operating systems. Guix supports transactional upgrades and roll-backs, unprivileged package management, and more. When used as a standalone distribution, Guix supports declarative system configuration for transparent and reproducible operating systems. I still think Amazon, Google and Azure will take a decade or two to build and offer something like this to it's customers. Indeed Google's Fuschia is trying to do the same, but I feel it's at least a decade away. It has one of the best wonderful documentation [2] to get started and explore with all the details. [1] https://guix.gnu.org/ https://guix.gnu.org/ [2] https://guix.gnu.org/manual/en/html_node/ https://guix.gnu.org/manual/en/html_node/

ozataman 7y ago
If I could trouble you for the common discourse here, would you mind summarizing why one may prefer to use Guix in the place of Nix? They seem to be based on the very same ideas and Guix even admits to being inspired by Nix.
- kragen 7y ago
  Scheme instead of a bespoke programming language, and more focus on reducing the bootstrap set that compromises the goal of reproducibility shared by both systems.
  - svd4anything 7y ago
    But the bespoke language has some benefits. It’s concise and specifically designed for the problem. Also Nix has more contributors and that is very important to have a large collection of recipes to start from.
    - Koshkin 7y ago

candiddevmike 7y ago

I've tried to use Nix in the past, but I can't get past the layers of abstraction. Normally I go and consult the relevant docs for what I'm trying to configure (postgres, systemd, etc), but with Nix I also need to consult the Nix docs and figure out the discrepancies/map values between them. I love the idea of systems configuration like this, but I'd much rather see less abstraction ala cloud-init with nixos-rebuild. For those who use Nix, how do you deal with this kind of abstraction? Additionally, how soon do you see security updates land?

hardwaresofton 7y ago

I still don't see the light. I'll try and lay out my reservations, starting with the pain points of the docker image (out of order to coalesce some points): > The package manager’s database is included in the image > Most of the files in the docker image are unrelated to my website’s functionality and are involved with the normal functioning of Linux systems So remove it...? Docker multi-stage builds[0] make this really easy, though I still use separate containers for different times (building, testing, etc), and sometimes even multiple "stages" of containers for languages that take a long time to build (Haskell). > The package manager is included in the image Assuming you don't want the package manager itself, why not just use a scratch[1] or distroless[2] image? Well of course it's harder than one might expect to use those options (distroless is actually fine), because of the lie of "statically building" anything on most distros other than alpine, which brings us to the next pain point... > An entire copy of the C library is included in the image (even though the binary was statically linked to specifically avoid this) Using alpine gets you much closer (if not all the way there) to a proper static binary w/ musl libc. You may have to look into things like replacing the use of libnss or certain systemcalls with golang libraries, however[3]. My biggest problem with nix is that it just isn't worth the effort -- The ~5+ paragraphs of nix tools and scripts is just not at all attractive to me personally when I know roughly a day's worth of fiddling to get a proper static build is good enough most of the time. I've heard amazing things about nix, nixops, and all the tools there-in but there just isn't enough pain IMO to warrant completely changing how to do things. Nevermind the fact that disks get cheaper and cheaper, network gets faster and faster, and people are starting to look into pre-emptively sharing container images across meshes of nodes with tools like Dragonfly[4]. Another point that is somewhat related -- if nix is good, guix has to be better on some level (excluding factors like ecosystem) purely because it uses a full-blown language for the config (i.e. terraform vs. pulumi). It doesn't seem like nix will hold enough value before unikernels "arrive", then the problem of taking your distribution along with the program you want to deploy disappears alltogether. [0]: https://docs.docker.com/develop/develop-images/multistage-build/ https://docs.docker.com/develop/develop-images/multistage-bu... [1]: https://hub.docker.com/_/scratch/?tab=description https://hub.docker.com/_/scratch/?tab=description [2]: https://github.com/GoogleContainerTools/distroless https://github.com/GoogleContainerTools/distroless [3]: https://github.com/golang/go/commit/62f0127d8104d8266d9a3fb5a87e2f09ec8b6f5b https://github.com/golang/go/commit/62f0127d8104d8266d9a3fb5... [4]: https://d7y.io/en-us/docs/userguide/download_files.html https://d7y.io/en-us/docs/userguide/download_files.html

nitrix 7y ago

As much as I admire the people involved with Nix, taking the initiative to solve what they believe can be improved and the other developers like her, toying with new things and successfully managing to figure all this stuff out... I'm actually disappointed. The thing is, Nix is an absurdly complex piece of software, perhaps on a similar order of magnitude as maybe Kubernetes or other gizmos, requiring a very large time commitment to understand and to use properly. Just for fun, have any of you tried to keep up during the Docker bigbang, with all these technologies popping up left and right, switching names, dying abruptly, getting super-seeded or hacked with vulnerabilities? That was one of my most mentally draining year for me and I've been in the field for a while now. See... along the way, I've learned that Computer Science is always about tradeoffs. Now when I'm being asked to trade away my sanity learning this nonsense for in return a couple of megabyte of disk space that could've been wasted, I just don't see the value. Seriously, are we optimizing for the right stuff here? I know Nix is doing package isolation with a programmable environment defined by text files, it's immutable and all. I get it. But we have alternatives for these problems. They do a pretty good job overall and we understand them. Ironically, even those solutions I'm comfortable with are still struggling to get good adoption! How the heck is our field going to avoid fragmentation when it keep growing exponentially like this. Perhaps it's just me aging and getting groggy; though there must be an explanation for this phenomenon. Please, it definitely gnaws at me.

Aloha 7y ago
We just keep trying to hide complexity and fragility with more layers of redirection and abstraction - it doesnt solve the problem, but it makes it tomorrows problem. In the end, excessively clever people make me nervous, because they leave complex problems in their wake, which I'm not clever enough by half to solve.
- ertian 7y ago
  I agree with you, mostly, but I really think Nix is one of those rare abstractions that is easily worth it: it has the potential to simultaneously solve and unify a bunch of different issues: reproducable builds, package management (system & language), container creation, system config, and so on. One language across all those domains is great, and the ability to rollback an entire system is amazing. Also: the ability to add your own software, GitHub tarballs, and piles as PHP as first-class citizens (you can cleanly remove them!) isn't emphasized enough. You can keep your wget, build script, db config, and nginx config all in the same file! I think if you weighed the complexity of Nix, and NixOS in particular, against the tools it replaces (or anyway, could potentially replace) it's a no-brainer. I'm a convert.

anonsivalley652 7y ago

If they built their app differently, such as using a temporary directory rather than building it in tree in the release path, they could've used staged builds to cache their steps in docker. What they do get from Nix package management is freedom from dependency hell. Actually, I prefer habitat (hab) for portable Linux packaging because it supports a crazy amount of caching, it does GC on unneeded packages, it has an internet-visible package repo to publish to and has a simple DSL that I can teach to anyone. I don't use its other features that much, and I don't use it on FreeBSD but I use hab studio on macOS now and then. Nix is pretty awesome because it almost marries package management and configuration management... if you think about it, the definition of a conventional OS package is an arbitrary one that limits configurability and customization. Gentoo, Arch and others try to work around it, but you really can't unless you can drive and hook intelligently into specification language that built the package and can accept modifications at different points without a lot of kludgy hacks or forks. Furthermore, the conventional package paradigm assumes one version and one configuration for everything, unless you want to get messy with variant packages. Nix and hab solve these issues. The problem is I can't suggest it in a lot of usage contexts because it would be like if I recommended Rust, Elixir or Haskell to a PHP shop. ;) I really want to but I know it's probably not a good idea. Nix is awesome wherever the badassometer says "above average." Give it a try, but use what works best. Best practices > Leverage build cache: https://docs.docker.com/develop/develop-images/dockerfile_best-practices/#leverage-build-cache https://docs.docker.com/develop/develop-images/dockerfile_be... Multi-stage build: https://docs.docker.com/develop/develop-images/multistage-build/ https://docs.docker.com/develop/develop-images/multistage-bu...

ses1984 7y ago
>If they built their app differently, such as using a temporary directory rather than building it in tree in the release path, they could've used staged builds to cache their steps in docker Can you explain this just a bit more, please? I was just reading the two articles you linked today, and your comment seems there is some piece of insight that's missing. If you search the multi-stage build article for "cache" the only hits are related to not using cache. What should I do if I want to leverage the cache as much as possible in a multi stage build?

kragen 7y ago

Yeah, Nix (or Guix) is kind of Docker Done Right.

Sean1708 7y ago
I think it's a lot more complicated than that. Yes there are plenty of people that use Docker as a package manager, but I think that's a failing of traditional package managers rather than a failing of Docker. You could, for exactly the same reasons, say that Nix is Nix Containers[1] Done Right but if that were true then Nix Containers wouldn't need to exist in the first place. [1]: https://nixos.org/nixos/manual/#ch-containers https://nixos.org/nixos/manual/#ch-containers

dr01d 7y ago

I would recommend multistage build but with distroless as final. https://github.com/GoogleContainerTools/distroless https://github.com/GoogleContainerTools/distroless

fcarraldo 7y ago
This seems like the real answer to this problem. I really like Nix conceptually, but the problem it's being used to solve in this case is already solved by Docker, and using a multistage build with a Distroless stage relies on fewer dependencies, fewer tools, and many fewer lines of config.

whateveracct 7y ago

I use Nix for every project once it grows enough for me to have to pin a directory. And sometimes sooner. I don't know it that well but I've picked up on design patterns, use the repl to figure stuff out, write small abstractions when necessary..and it works pretty great. And the gains grow as my dependencies become polyglot (even C + another language like Haskell..but when you add compile-to-JS, static asset generation into the mix it's amazing) Yeah it's hard to learn. No denying it. But every other "alternative" I've found doesn't actually approach it. So I've kind of gotten sick of reading about "alternatives" because it always feels like they don't actually solve the problem Nix solves. I always end up using the alternative+Nix. Classic example of this is the Haskell stack build tool. I could've bemoaned complexity and various capitalist criticisms when I first ran into it at a job. But I'm so much better off for not.

daenz 7y ago

Most of their complaints about Docker, specifically: * The package manager is included in the image * The package manager’s database is included in the image * An entire copy of the C library is included in the image (even though the binary was statically linked to specifically avoid this) Can be solved with Docker multi-stage builds[0]. This is essentially a separate build stage inside your single Dockerfile that sets up, builds, and creates artifacts. Those artifacts are then copied over into a later build stage. The resulting docker image is lean and yet the artifacts were built at docker build time, and its all contained in a single file. 0. https://docs.docker.com/develop/develop-images/multistage-build/ https://docs.docker.com/develop/develop-images/multistage-bu...

takeda 7y ago
The author did use a multi stage build.
- xena 7y ago
  A ridiculously slim multi-stage build, but it was starting to show its weaknesses.
- daenz 7y ago
  My mistake, you're right. I'm thrown off by the idea of someone using a multi-stage build and still having those complaints. Just use/build a final base image that is lean enough for your needs. You're not forced to have any cruft you don't want.
deleted 7y ago
[deleted]

kalium_xyz 7y ago

The effort involved in using nix becomes a lot less if you make templates and have IDE support.

tlrobinson 7y ago

> The image age might look weird at first, but it’s part of the reproducibility Nix offers. The date an image was built is something that can change with time and is actually a part of the resulting file. This means that an image built one second after another has a different cryptographic hash. It helpfully pins all images to Unix timestamp 0, which just happens to be about 50 years ago. This doesn’t mean builds done by Nix are bit-for-bit reproducible by default, does it? There are a lot of other ways to introduce non-determinism in builds, like rand() or network requests (which I think could only be eliminated in a generic way by literally emulating the CPU of the machine doing the build and not allowing external communication?)

takeda 7y ago
The nix by default makes builds in a sandbox. It is purposefully making certain operations unavailable (local home directory, local configuration, network access etc). I don't think it prevents Rand(), but that's not as common.
fctorial 7y ago
It provides the hash of files as a method of verifying the input identity. As long as the build file is pure function of build tools (gcc, make, etc), and the build tools themselves are deterministic, the build outputs should be reproducible. Though I've never seen anything like `-frandom-seed=<input-file-name>` in build files. I think bit-by-bit reproduciblity is one problem tackled by guix.
- danieldk 7y ago
  I think bit-by-bit reproduciblity is one problem tackled by guix. I think the Nix folks are also interested to some extend. Currently, almost 99% of the paths in the minimum installation image are reproducible: https://r13y.com/ https://r13y.com/

eximius 7y ago

I still haven't figured out the nix language, how to find which package installs a particular binary if it isn't the name of the package, or how to find config options for packages I do have. Those three problems are what's holding it back for me. I still enjoy it so far, though.

SitiSchu 7y ago
To find out which config options exist for packages searching here can be quite helpful: https://nixos.org/nixos/options.html https://nixos.org/nixos/options.html Another way would be reading the nix expression on the nixpkgs GitHub repository.

Annatar 7y ago

This is so wrong on so many levels. So many complications. Monstrously huge binaries. Static linking. Docker and Nix mess of complex instructions, all custom. With RPM, it is one command, rpmbuild, with a standardized spec file and no need to link statically. No Docker image needed, or anything else. Just plug into a yum repository or into a Kickstart install group and you're done. No code or compose files or playbooks to write. Turn the VM on and have it automatically PXE / DHCP / TFTP boot and Kickstart install it with the desired software and configuration. Without writing a single line of code or lifting a finger.

Nullabillity 7y ago
And now your setup depends on working PXE (which requires custom DHCP config!) and a custom RPM registry. How is that less complex operationally? And you need to write custom rpmspecs and kickstart manifests. Do those not count as code? Kickstart also doesn't help you with any day-two ops concerns.
- Annatar 7y ago
  "Custom DHCP config"?!? You do realize DHCP stands for "dynamic host configuration protocol"? That's exactly what it was designed for... And if you can't get "working PXE" (PXE is implemented in firmware, by the way), you might want to brush up on the basics of putting together an IT infrastructure, or this moment might be a good time for a career switch out of IT... There are no "Kickstart manifests", it's a ruleset. There is no "RPM registry" (this isn't Windows™️) or anything of the sort. There are no "custom spec files" as it's a formalized format with grammar and lexicography which the OS's software management subsystem understands - it's like putting a VHS tape into a video cassette recorder, modular and standardized. Day two is where a software deployment server and clearly defined change management process according to the department of defense capability maturity model come into play.
  - Nullabillity 7y ago
    > "Custom DHCP config"?!? You do realize DHCP stands for "dynamic host configuration protocol"? That's exactly what it was designed for... Usually used for assigning network configuration dynamically. I'd venture a guess that most people never touch their DHCP configuration, aside from assigning DNS and IP pools. And good luck getting your hosting provider to give you raw access to their DHCP config. > And if you can't get "working PXE" (PXE is implemented in firmware, by the way), you might want to brush up on the basics of putting together an IT infrastructure, or this moment might be a good time for a career switch out of IT... There is a lot more to stable PXE than having a client. Nevermind the insanity of effectively giving anyone who can broadcast IP packets root access to all new servers. > There are no "Kickstart manifests", it's a ruleset. Different words, same thing. > There is no "RPM registry" (this isn't Windows™️) or anything of the sort. Correct, guess I've done too much Docker recently. Meant RPM repository. Unless you're shipping around your RPMs manually? In which case, I refer back to the day two question marks. > There are no "custom spec files" as it's a formalized format with grammar and lexicography which the OS's software management subsystem understands - it's like putting a VHS tape into a video cassette recorder, modular and standardized. So.. the same as Nix definitions then? Except with Nix you don't have to worry about whether the system was set up for VHS or Betamax. > Day two is where a software deployment server and clearly defined change management process according to the department of defense capability maturity model come into play. So.. completely unrelated to the process you've advocated so far?

jolmg 7y ago

It's been years since I last tried NixOS. One of the things that I really didn't like was that changing something that had a lot of dependencies meant that everything that depended on it, needed to be rebuilt. That's so even if I knew the change couldn't affect how the dependencies would be built. I know why NixOS requires that. I think that's really cool from a safety side, but it was also really annoying to have to wait so, so long to use the system after an insignificant change. I wish there were a "I know what I'm doing; let me risk screwing up" mechanism. I don't know if there's one now, but I kind of doubt it. I imagine Guix would have the same problem.

corysama 7y ago
“even if I knew the change couldn't affect how the dependencies would be built.” That works wonderfully until it bites your face.
- jolmg 7y ago
  Well, it depends on the change. For example, fixing a misspelling in a manpage could technically break something, but I think anyone would agree that it's fairly low risk. Likewise, there are changes one could make to code that could be easily judged to be low risk at breaking something. Being able to take the risk at your own judgment is what would be wonderful. In any case, such "bite your face" moments wouldn't necessarily be visible at the build-time of dependent packages. Rather, they'd be visible when running them. So, you end up waiting for all your dependents to be built exactly like they were already and still exhibit the bug you would have also seen using the previous build.
Ericson2314 7y ago
You want https://github.com/NixOS/rfcs/pull/62 https://github.com/NixOS/rfcs/pull/62. I'm very eager to see it done this year (ideally earlier but don't want to jinx myself).
- bb010g 7y ago
  Holy shit, thanks for linking this.

pmarreck 7y ago

It is honestly great to have a tool that solves so many problems at once but the resultant complexity is intimidating for most developers I feel.

takeda 7y ago
This is true, it takes quite a bit of effort to learn it. I think what Nix needs is perhaps series of tutorials targeting how to solve common problems that nix is useful for. There are plenty of things that are abstracted in nixpkgs, so perhaps use them as building blocks and explain how they are implemented in different articles.

krick 7y ago

What's even the point of top-level domain "website"?

zegl 7y ago

Setting CGO_ENABLED=0 does not make the build fully static. To do this you currently need to set the following flags: -ldflags '-extldflags "-fno-PIC -static"' -buildmode pie -tags 'osusergo netgo static_build' See https://github.com/golang/go/issues/26492 https://github.com/golang/go/issues/26492

dfc 7y ago

> This article was posted on 2020 M2 10. What is "2020 M2 10"?

deleted 7y ago
[deleted]
_Nat_ 7y ago
Looks like that author prefixes the month with "M". Dunno why. Sometimes DD-MM-YYYY and MM-DD-YYYY can be confused, such that if one of those formats is used, it could be helpful to clarify. However, YYYY-MM-DD is typically pretty unambiguous, so it seems odd here. I guess it's probably meant in analogy to, e.g., "2020-Q1" (which would be the first Quarter of 2020) or "2020-H1" (which would be the first Half of 2020).
- xena 7y ago
  I do it because it's visually unambiguous. It is clear what is the day number, what is the month number and what is the year number. I have no idea where Apple got this, but it's the date format used in the iOS Lojban locale. I kinda got used to it because it's also faster for me to type.
bb010g 7y ago
Year 2020, month 2 (February), day 10 (the 10th). In RFC-3339, 2020-02-10.
xena 7y ago
Year 2020, Month 2, Day 10
- dfc 7y ago
  If the day is a single digits do you prepend D to it? Eg October 2nd?

kstenerud 7y ago

My only foray into nix was cut short because my 2gb machine RAN OUT OF MEMORY installing a package.

fctorial 7y ago
Well, it's not just a wrapper around "tar xf"

axilmar 7y ago

After reading the web page posted above, and the comments in here, I've reached the conclusion that Docker, Nix, etc are trying to solve a problem that shouldn't exist, and that the actual problem is at the operating systems' provided mechanisms for dealing with programs and dependencies. More specifically, it seems like the Unix filesystem layout, with its bin, etc, usr and other well-known directories is part of the problem. Also, the environment variables mechanism is part of the problem. Why couldn't we have a much simpler mechanism for running things? for example: a) each application should live in its own directory. b) each file or folder should be versioned. c) common files for applications, for example, fonts, should be installed in the application folder themselves, and the filesystem shall provide hooks for external systems to be notified when these files are created, moved or deleted. With this system, important files, for example tool executables, would automatically be found and invoked without the need for adding a path to them. d) runtime program dependencies should be provided via text file with parameters and not by environment variables. This text file would have to be specified each time a program runs, and the user could create specific scripts that run the program with specific parameters. Programs should have attached, in the same folder, the default parameters file. How's that different from environment variables? well, with this system there is no system-wide dependency of a program to a unique string, and therefore the requirement to override environment variables for specific programs wouldn't exist. I.e. programs shouldn't need environments to run, but list of dependencies. With the above solution, making repeatable and sharable development and test environments would be extremely easy: just copy the application folders and the configuration files one needs. If something is missing, copying it from another source would be the solution. Ultimately, having a set of programs at hand and wanting to combine them to produce some output is exactly the same as having a bunch of functions in a program and invoking them in a specific order to get some result. And while in programming we have recognized the problem of global state and we have taken measurements to minimize the problem, for example with functional programming, we haven't done so for programs. In other words, the problem is that we are trying to compute things using global state, once more, this time at the operating system level! For me, that's the fundamental issue. All these tools are welcomed, but unless the fundamental problem is solved, no real progress shall be made and there is always going to be tool fragmentation (i.e. do we use Nix? Docker? Some other solution? etc).

deleted 7y ago

[deleted]

h91wka 7y ago

I have to do a bit of DevOps at work, and I absolutely hate every second of it, hence I tried Nix, and I think it is absolutely awesome. As a software developer, I find the ability to take a cryptographically consistent closure of a program's environment and deploy it in a reproducible way across your dev, loadtest and prod machines _the only reasonable way_ to do things. Not to mention that Nix community is very knowledgeable and open to patches and suggestions. However after a brief investigation period I abandoned this idea altogether, here's why. In my opinion, Nix is only worth climbing its steep learning curve when you really utilize its "reproducible environment" concept. As a counterexample, take your home PC environment, which is 1) unique 2) quickly changing. You don't need to reproduce it very often (how often do you upgrade your laptop?). You don't really want a hash-perfect reproducibility there, and a simple Ansible script will work just fine. So, the target of Nix should be "serious enterprise", where you deploy hundreds of machines, right? Well, "serious enterprise" where I am at (banking) will _never_ adopt Nix. There are two main reasons why: 1) NixOS doesn't follow standard Linux filesystem hierarchy. They get around this by patching everything, both manually and automatically. nixpkgs repo contains thousands of patches. To put it in the perspective, OS is one of your trust anchors. I don't want to sound as "no one got fired for choosing IBM" guy, but legal people will scream bloody murder if they see extensive level of patching going on in the distro, for a variety of reasons, not necessarily tied to security. Some of their patching goes very deeply, BTW, and straight up changes behavior of the software. 2) Secrets management: it doesn't exist in Nix. nix store itself is world-readable. There are fundamental problems with some cryptographic algorithms that require entropy, and therefore go against "reproducible environment" concept. YMMV, but for me Nix didn't do the job, although I studied it deeply, and contributed some patches to nixpkgs. It looks like a futuristic research project. On the outside it is brilliant, but in brutal reality you need to run the ugliest scripts to patch shebangs and what not.

fctorial 7y ago
> Some of their patching goes very deeply, BTW, and straight up changes behavior of the software. Can you give some examples?
- h91wka 7y ago

sagebird 7y ago

I am not familiar with the topic at hand. I know that include os stuff is young. But I wonder, would it be easier to build the website with go, with an os included, and then deploy that? Both the docker and nix approach seem like alot of random tasks or knowledge is required. Are there bad things about including an OS I am forgetting?

aliswe 7y ago

> And the output is 16 megabytes smaller. Am I missing something here? Is this the point? 16MB of saved space?