25 ms·

Nix: An idea whose time has come

310 points by susam 5y ago

pictur 5y ago
is nix commonly used only for compiled languages? for example, is there anyone who creates and manages separate packages for frontend and backend in a web project? I would like to hear what benefits there are if any.
johnnyAghands 5y ago
Open paragraph starts with Joe Armstrong -- ok I'm sold.
geocrasher 5y ago
I'm not against Nix or any package manager. What I'm against is the general fragmentation of Linux that makes interoperability between distro's and window managers problematic. If there's every going to be a Year Of The Linux Desktop (TM) then there must be a way for a user to fulfill the expectation that they can select "Linux" instead of "Mac" and "Windows" when downloading software, and when they double click or drag it or whatever, it just installs without a fuss about which distribution they're using or which UI libraries they need or which package manager they use.
- podge 5y ago
  I agree with your point about fragmentation. But isn't the "Year Of The Linux Desktop" just a joke at this point? Even more so now that desktop computing is becoming less and less important to most people.
  - bee_rider 5y ago
    Well, we can't look forward to "Year Of The Linux Phone," because that's been around for a while now in the form of Android. Maybe "Year Of The Actual, Like, Real Linux Phone, Ugh, You Know What I Mean," though?
- ghostwriter 5y ago
  There's no fragmentation, Nix apart from many other things is first of all a build system, and it can build Debian and/or RPM packages for you from the same sources it uses for NixOS [1] [1] https://nixos.wiki/wiki/Nixpkgs/Building_RPM_DEB_with_nixpkgs https://nixos.wiki/wiki/Nixpkgs/Building_RPM_DEB_with_nixpkg...
- smoldesu 5y ago
  The problem as I can see it is that the "solutions" don't really work either. Here's your options, in order of viability: - AppImage. Basically the idea of "Apps" ripped straight out of MacOS and injected right into Linux. Works fine, but clutters your home directory with Another Folder and doesn't integrate with your desktop like a native package. - Snap. Works on any system that can install snapd, is owned by Canonical (a pro or a con depending on who you ask), but also auto-updates and has occasional performance problems. Plus, snapd is generally kinda fussy. - Flatpak. Sandboxing taken to it's (il)logical extremes. If you like random data loss, confusing package manifests, low-performance and generally broken software, this is the way to go. Of course, most people like it when their compositor doesn't break when installing third-party programs, so they avoid it like the plauge. It's a uniquely bad format, almost worth spinning up a Linux VM to try it for a laugh. Just make sure to use GNOME, it's useless anywhere else. That's the true hallmark of a cross-distro packaging solution! So yeah, we're probably due in for Another Competing Standard. At this point though, I think most developers are contented to just ship an RPM and an Arch package and let everyone else figure stuff out for themselves. Honestly, I prefer that approach when compared to the blasted wasteland that is cross-distro package management.
  - 3np 5y ago
    Could you be more specific about your issues with Flatpak? No idea what you’re talking about here.
    - 1_player 5y ago
      It's trolling of the "everything new in Linux is crap" type, just check their post history. Random data loss because one uses Flatpak, seriously?
      - smoldesu 5y ago
        > Random data loss because one uses Flatpak, seriously? I wish I was joking: https://twitter.com/planner_todo/status/1492084099875586049 https://twitter.com/planner_todo/status/1492084099875586049
- Ericson2314 5y ago
  The major problem here is the lack of dialogue between language-specific package managers and distro package managers. I think once that is fixed, a lot of stuff will start improving. I wrote https://github.com/NixOS/rfcs/pull/109/ https://github.com/NixOS/rfcs/pull/109/ in hopes Nix can help lead the way here.
  - AlphaSite 5y ago
    If this were true Mac and Windows wouldn’t thrive, but they do just fine without a system level package manager at all.
    - Ericson2314 5y ago
      Err i was trying to answer > What I'm against is the general fragmentation of Linux that makes interoperability between distro's and window managers problematic. I disagree that downloading software being hard is a major impediment. (though I realize the parent did continue to claim that.) How many people download executables on the regular anyways?
    - nick__m 5y ago
      Windows now has a first-party package manager: https://github.com/microsoft/winget-cli https://github.com/microsoft/winget-cli It positively surprised me when I did `sudo winget upgrade` (I first did `winget install gerardog.gsudo` in an admin prompt) and it detected and upgraded the majority of the already installed OSS on my Windows workstation.
- wheresmycraisin 5y ago
  Aren't we past that? Vast majority of Linux desktops are Ubuntu/Debian or Redhat/Centos. You target those two and you're set. Add Suse if you have a large European user base.
  - 3836293648 5y ago
    Or just target flatpak and let it mostly just work
- qbasic_forever 5y ago
  Nix doesn't have anything to do with that problem. If anything it helps as it lets multiple even conflicting versions of libraries and software coexist and run together. What you want is flatpak or appimage (or even snap). These are self contained distributed binaries that contain and isolate all their dependencies. It is simply a one file download for any linux distro. They work great--I use a ton of flatpak apps like VS Code all the time.
- contravariant 5y ago
  You phrase this as if it's getting continually worse, but I'm not sure if distros were ever that interoperable (unless you deliberately restrict yourself to a point in time where there was exactly 1 distro). If anything it seems to me that you now have a decent chance to get software to run on any recent distro, which wasn't always the case. Though that's just my impression, I'd be happy to be proven wrong by someone better informed.
- chlorion 5y ago
  I am not so sure that this is really as big of a problem as it's made out to be. To me it seems like people trying to make Linux software management work like Windows because that's what they are used to, so if the experience is different than what they are used to they assume it doesn't work well. Going to some project's website and trying to find a download to install is not typically how you install software on Linux, and people distributing software like that for Linux probably don't know much about Linux software distribution themselves. If you want a good experience you should be installing software from the system package manager instead of searching for deb files that are probably out of date and won't work on your system due to shared library compatibility issues. Using the system package manager is much different than what many are used to but it actually works very well. The other option is to use flatpak or similar software, which is designed to sanely handle out of repo software installation. I think people distributing their own deb/rpm/etc files from their project's website are causing active harm and confusing people who are new to Linux. The best option is to provide a link to the distros package if it exists (https://archlinux.org/packages/foo https://archlinux.org/packages/foo), instructions on how to build from source and a flatpak image (or similar). When a new user downloads a stray deb and has a bad experience with it (broken software, system breakage, etc) it really leaves a poor impression on them that could have easily been avoided.
  - n0w 5y ago
    I don't disagree with what you're saying, but it's interesting that some people might want to make Linux software distribution more like Windows or macOS because of unfamiliarity. The way you've described Linux software distribution sounds an aweful lot like software distribution on mobile devices. I think it should be pretty familiar to everyone by now. If anything I think Windows and macOS want to move closer to being like Linux in this regard. Maybe the experience of using cli tools like `apt` or `yum` has made people overlook the ease of installing software on Linux. Anyone that has used openSUSE or Ubuntu should know better.
- southerntofu 5y ago
  > there must be a way for a user to fulfill the expectation that they can select "Linux" instead of "Mac" and "Windows" when downloading software There's already established ways to do that such as AppImage, which has bonus points (compared to other solutions) for PGP signatures and differential (delta) upgrades. What's lacking is proper desktop environment integration for an ~/Apps folder like you have on MacOS where this pattern of one-file-per-app has been established for longer. If you want to go one step further, 0install would make it possible to not even have to choose between "Mac", "Windows" and "Linux" on the download page, which is kind of amazing in a way.
- 1_player 5y ago
  Heard of Flatpak?
gavinray 5y ago
> Nix often scares newcomers and experienced devs alike, because it proposes a fairly radical overhaul to how we think about package management and how we run software in general. I am not sure this is the main put-off of nix. Ideologically, I love nix. The syntax/language itself is a massive barrier IMO. I use Nix for personal projects, but I prefer the experience of Devcontainers. They're easier to understand and debug (for me). I'm watching eagerly the work being done by the ostree/rpm-ostree folks who are also trying to solve for a similar problem. Hoping to see something like "Nix but with YAML/JSON" come out of that. https://ostree.readthedocs.io/en/stable/manual/related-projects/#nixos-nix https://ostree.readthedocs.io/en/stable/manual/related-proje...
- Ericson2314 5y ago
  By their own text in what you linked: > OSTree only supports only system-level images, and doesn't do dependency management. I think that makes it....not really like Nix at all. Dependency management is Nix's core functionality. Everything I would happily delegate to other layers.
  - octoberfranklin 5y ago
    ... kinda like people who pretend that Zig is a competitor to Rust, and conveniently forget to mention that it does not promise memory safety. I've been seeing a lot of "steal their thunder" type project positioning lately when something is a radical leap forward but requires major effort to learn -- like nix or rust. People seem to have picked up on a strategy that if you can put together something inferior but easier to understand (zig doesn't need a borrow checker because it's memory-unsafe; ostree doesn't need a language because it ignores dependencies), and market it as an alternative to the radical thing, a much larger group of people will rally around the simpler thing instead of the radical thing because they feel threatened by the new thing that can't be learned in a weekend or even a week, and using only "20%-time" would take six months to master... I'm going to get downvoted to hades for this, but it's true.
    - ajb 5y ago
otikik 5y ago
For devops engineers and system administrators, yes. For the rest of us, Nix is still missing friendlier face and a gentler learning curve.
- n42 5y ago
  I'm not sure why you're downvoted so much -- I am all in on Nix. I use it professionally. I agree with you 100%. I'm convinced whoever solves the UX issue of Nix will have the next "big thing" on their hands. I hope it's the OSS community and not a repeat of Docker, Inc.
- takeda 5y ago
  By "rest of us" do you mean developers? I find Nix especially useful on that front by being able to provide a common dev environment and also when used for CI it can speed up builds through its caching. They do have unfortunate name of the project and it is harder to find articles about just Nix, while NixOS is more unique.
Arubis 5y ago
Nix is indeed a great idea. I do hope that idea’s time has come. But, oh, man, that config syntax. I’d love to see some alternative, human-friendlier interface; am thinking here of how Elixir really induced a significant pickup in usage of the BEAM owing largely to being perceived as friendlier to newcomers than Erlang.
- capableweb 5y ago
  Nix (the language, not to be confused with NixOS, the operating system) is not that hard to pickup, if you already know a programming language or two. Read through about the syntax and you'll get the gist in a couple of hours, and you basically know it inside out if you spend a day or two reading and experimenting with it. You just need to spend the time to understand it, and it's no longer a hurdle. What I think really stops NixOS from gaining mainstream popularity (eh, mainstream like in the Linux ecosystem, not mainstream-mainstream) is the inability of just downloading binaries and running them, when you have to. It's a huge hurdle to try to figure out the right incarnation to set the lib paths correctly for the binaries but woops, it's actually using something else and now you need to do some other hacky thing. nix-autobahn et al exists but are also hacky and sometimes outright doesn't work, and then you're basically lost, unless you can rebuild the binary yourself, which unless it's free/open source software, you're unlikely to be able to do. This, I think is the real reason people are avoiding to adopt it, because there is no easy solution to this problem, unlike the problem of syntax which can be solved by simply learning it.
  - Ericson2314 5y ago
    Yeah absolutely Don't get me wrong, Nix can and should be better in many respects, but: > Second, Nix surfaces all the complexity involved in building software and forces you to deal with it. Yes, and If you can't deal with the simple functional language Nix happens to come with, you will never be able to deal all that surfaced complexity. The latter is 10x worse more challenging. So in some sense the language is a decent filter for people who won't like the inevitable rest anyways.
    - 5y ago
nwmcsween 5y ago
Nix has a few shortcomings: * The syntax isnt well liked. * The package manager relies on global state which kills the use of sharing / over NFS. * The nixstore treats a filesystem as an object store. * Related to above, permissions aren't secure as they could be. Some of these can be worked around, some of them require an entirely new project.
- Ericson2314 5y ago
  That's a decent list, but I don't think we need to start from scratch. I think Nix can be adapted to meet all of those.
- catern 5y ago
  >* The nixstore treats a filesystem as an object store. That's a weird thing to list as a shortcoming, since that's the main innovation of Nix. ("package management as memory management" as the paper and thesis said)
  - nwmcsween 5y ago
    Because you can encode the same information within the files and some dirs while keeping the benefits of a filesystem, heck you could encode what nix uses sqlite for using symlinks, files and dirs
  - deleted 5y ago
    [deleted]
- ncmncm 5y ago
  Moreso than the syntax, the language semantics are a problem. There seems to be no value in a dynamically-typed system description language, but both a practical burden and a degree of unnecessary risk. Transitioning to a more consciously-designed, statically-typed, still-declarative language should put the project on sounder footing. The existing language interpreter should be easy enough to instrument to annotate all the existing specs with the actual types seen when building the corresponding packages, enabling automatic translation and transition to a better language for almost all packages, excepting only those (probably?) few that actually rely on dynamic-type follies. Those last could stay on the old language, be hand-translated to the new one, or be abandoned, case by case.
iamevn 5y ago
I dove in recently and am enjoying it on a home server. The only trouble I had was with setting up fuse filesystems correctly. A couple times it completely refused to boot because I got some fuse option wrong and a filesystem failed to mount. These were options that worked correctly when started dynamically through "nixos-rebuild switch" but not on boot through /etc/fstab. I've written my own overlays and some derivations for my own tools and genuinely enjoy the language.
panta82 5y ago
I'm sorry, I keep hearing about this thing, but it's just not solving any major problem I actually have in in programming or computer environment. Non-reproducable environments are just not such a big issue that it's worth "radical rethinking" of everything to solve.
- georgyo 5y ago
  What are the problems you actually have? If you want to deploy and configure something, nix does that exceptionally well. If you want to install up to date software on Debian, RHEL, or other distribution but not negatively impact the system, nix does that exceptionally well. If you want to build containers, nix does that decently. Nix solves a lot of problems beyond reproducible environments. And it solves them permanently for nearly all use cases.
  - panta82 5y ago
    But it sounds like you have to get deep into this programming language, and figure it out yourself for the stuff that's not already there? Containers and software installs etc. already have solutions that are much simpler to use. Don't require me to learn a new language or get into the weeds of how each package works.
- rgoulter 5y ago
  That's kinda fair, but I think it's worth keeping an eye on. Nix is really good at "programmatic environment for managing packages". Which is excellent for devops. There are advantages for developers, too.. but, developers can get away with quicker + dirtier solutions a lot of the time. e.g. Maybe your project assumes a specific version of Ruby or whatever. Nix can solve this in a nice way, but you can use Ruby version manager (or the general asdf). Want to install Python packages, without conflicting? Nix can solve this in a nice way, but you can use virtualenv. Build a container image? etc. An example of "practically useful, which Nix can do, others can't" I've seen is "just run the code from some repository". The non-Nix equivalent I've seen is `docker run <some image for a CLI tool>`. Nix allows the same UX, but without relying on containers. -- I think that's something everyone could benefit from. I think the benefits for developers are definitely there; the main downside is that compared to those "quick + dirty" solutions, anything off the happy-path with Nix is quite difficult.
__ryan__ 5y ago
Anyone use Guix[0]? How does it compare to Nix? 0: https://guix.gnu.org/ https://guix.gnu.org/
- capableweb 5y ago
  I've mostly used NixOS, but eyed Guix from time to time, not really dipped my toes into the Guix-water yet but not completely unwilling either, the syntax and cohesion is really interesting and alluring when compared to NixOS. I have the two threads favorites (sub-threads in a large conversation) that might be of interest to you: - https://news.ycombinator.com/item?id=18908591 https://news.ycombinator.com/item?id=18908591 - Guix seems interesting but I almost stopped reading when I read "Nix".... [submission: Guix: An advanced operating system] - https://news.ycombinator.com/item?id=23528380 https://news.ycombinator.com/item?id=23528380 - Does anyone know of a recent comparison of NixOS vs Guix? ... [submission: Guix Further Reduces Bootstrap Seed to 25%]
- southerntofu 5y ago
  I've briefly used both so don't expect my comparison to be exhaustive: - nix uses a centralized non-free repo (Github) ; guix relies on mailing lists for patches - nix invents an entire language ecosystem that's based on JSON + functions ; guix reuses an existing (and complete) programming language (GNU/Guile, a dialect of Scheme lisp) - nix packages proprietary software as long as they can provide a checksum for their executables/packages ; guix has a dedicated repo (non-guix) for that ; in both cases it's opt-in - nix has differences in behavior when run as a distro (nixos) or on a foreign system ; guix has unified naming conventions for both cases (although some details of setting up on a foreign distro for eg. GUI applications can be a bit tricky) - nix CLI is... confusing, to say the least ; guix CLI UX could be improved but is rather easy - nix packages tend to be updated more quickly compared to guix packages - guix maintainers are very picky about package descriptions: i tried to package a rust program along with ~20 dependencies, and the maintainer said i should come up with different short summaries vs long descriptions for those 20 dependencies... which are software i've never used so i'm not the good person to do just that - guix has a strong emphasis on security R&D: bootstrappability is making huge progress alongside the guix project (see blog posts), which to my knowledge isn't researched on nix side ; "guix challenge" and "guix git-authenticate" are very important/cool things to read about if you're curious - guix may introduce major syntactic changes to ease contribution, as was recently the case with "G-expressions" https://guix.gnu.org/en/blog/2021/the-big-change/ https://guix.gnu.org/en/blog/2021/the-big-change/ - nix uses mainline Linux + systemd ; guix uses Linux-libre + GNU/shepherd Probably many other differences other people will point out, but that's the ones that struck me so far attempting to use both.
breakds 5y ago
I have been running NixOS and uxing Nix for almost everything since I switched to it, and my experience has been great so far. It is one versatile solution to a lot of applications: 1. I run NixOs on on laptop and workstation, for work and for personal use. Any change to the configuration can be immediately transfered to other machines. And give me a new machine, I can quickly bring it up with the configuration that I am always using. 2. I run NixOS on my home server and machine learning cluster. Deploy experiment and service on them is as simple as updating the git-managed configurations. Meanwhile, if I want to use more power to run an experiment, NixOps can quickly bring up a set of machines on AWS with the configuration identical to my local experiment. You do not need to worry about setting up CUDA/pytorch and other dependencies every. 3. In my start-up, it definitely took more time to train the developers to learn Nix, but once they get familiar, everyone becomes a good DevOps engineer, which solves development environemnt (that invloves C++/Python), CI/CD and release really well.
willlll 5y ago
If there is something like heartbleed that needs to update a common dependency, how does NixOS deal with that? Do you need to rebuild everything that uses that dependency, instead of just changing the shared library on a more traditional os?
- catern 5y ago
  Yes - same as with containers.
- kibwen 5y ago
  Yes, but that's not a problem. In traditional systems the reason to avoid rebuilding everything isn't because it takes time (it does, but not that much time); the reason to avoid rebuilding everything is the fear that, halfway through rebuilding everything, you'll discover that some shared lib is missing, or some crucial toolchain has been uninstalled, or that some updated packages rely on incompatible versions of the same dependency, and it turns into a nightmare of toolchain and dependency resolution, leaving your system in a half-upgraded mess. But if the promise of Nix is true, then that's no longer possible; you rebuild everything, all the dependencies work out fine, and you go on with your day.
- ParetoOptimal 5y ago
  In practice you'll hit a binary cache or build once, push to your cache, then subsequent builds hit cache.
haberman 5y ago
It sounds like this is similar in concept to Bazel, except the output of Bazel is a statically linked binary instead of a binary that dynamically links .so's with known SHAs. In both cases you have a language that fully specifies how to hermetically and reproducibly build some output artifact(s) based on dependencies that are fixed down to the SHA.
- tadfisher 5y ago
  Dynamic linking is the default in nixpkgs, but Nix itself does not care what you build. So you can use the infrastructure in `pkgs.static` to build statically-linked binaries if you like.
- fooblessmooo 5y ago
  Nix is repeatable, but not upper-case Reproducible i.e. you don’t necessarily always get the same hash from the same build. Order of operations or concurrency or something like that.
ianthehenry 5y ago
> Whatever package is thrown your way, you can rebuild it locally and check whether you have the expected build output. This is analogous to verifying a binary downloaded from the Web by computing its sha256 hash, and comparing it to the one provided by the publisher of the binary. Can someone explain this to me? There is an experimental feature to add content-addressable packages that will give you this, but Nix package hashes are hashes of a package description, not the package, so you can't use them like a checksum. You can say "Hey do you have this package I want?" and a server can use the input hash to find what you're talking about, but there's no way that you can verify that what they gives you represents a good-faith attempt to build the package. I would also be very surprised to learn that a significant portion of Nixpkgs is "bit-for-bit" reproducible. That's hard! It's hard enough to get packages to work with Nix at all, and very few compilers/build systems/etc are actually concerned with literal reproducibility. Nix doesn't magically provide that. (There are also "fixed-output" package descriptions which are mostly used when you're downloading sources from the internet -- those actually are checksummed and verified, in case the remote source changed. I guess you could use that same mechanism for a build output, but you... don't?) Anyway, maybe this is a reference to the (experimental! bleeding edge!) content-addressable store stuff, but I don't think it's fair to call that a selling point of Nix yet. (Or I am way out of line. I don't really know what I'm talking about.) > Why is this important? Because it removes the need to trust the provider and makes the cost of detecting a failure or an attack much lower for the developer. Reproducibility means security for your systems and applications, and peace of mind for your developers. There is a large amount of trust when you download a binary Nix file, which is why you have to configure only trusted cache servers, and why cache servers will only accept submissions from trusted sources. Reproducibility is really important, and a great feature of Nix -- you can, given a package description, build it yourself instead of downloading it -- but emphasizing security and trust seems very misleading to me. If someone can clarify these points I would appreciate learning something new about Nix. > Nix undoubtedly has a steep learning curve, and there are two reasons for that. First, using Nix entails rethinking a lot of accepted wisdom and practices that have become second nature for a developer. Unlearning is hard. Second, Nix surfaces all the complexity involved in building software and forces you to deal with it. In order to make builds truly reproducible, this is largely inevitable. I disagree very strongly with these two statements. This reads like "It's not Nix's fault that it's hard to learn; it's your fault for not trying hard enough." I think that's absolutely not true. Nix is hard to learn, and it's mostly Nix's own fault -- which is a good thing! Because it means that it's fixable. Nix's approach to package management isn't some fundamentally difficult concept to wrap your head around. The concepts and ideas are pretty straightforward, once you understand them -- but how are you supposed to understand them? The Nix manual is sort of infamous, and not without reason. Nowhere in the manual will it teach you how to write a standalone package description -- although it will show you how to contribute one to the Nixpkgs repo, which is a pretty different flow. It doesn't really explain the high-level mental model I have of the Nix store as a simple graph database. There is almost no coverage of nix-shell, or the things it can do (which include some really cool things! Shebangs that explicitly list all of your scripts dependencies!). The quick start guide, until quite recently, explained how to install packages using the "wrong" command -- `nix-env -i git` -- which takes about a minute to run on my machine. (The "right" command -- `nix-env -iA nixpkgs.git` -- is instantaneous.) But it's not just the documentation's fault. Why is there a wrong way to install packages in the first place? It's one of many weird historical mistakes, which are all forgivable independently, but which add up to one of the most confusing and inconsistent command-line interfaces I have ever used. `nix-env -e` takes glob-looking things, but `nix-env -q` takes regular expressions... I dunno. There are tons of things like that. (There is a new command-line interface that you can opt into by editing a Nix config file, which is much better, but not without its own fun new set of problems.) In my experience the incidental complexity of Nix was a much larger barrier to learning about Nix than the "actual" complexity of bundling and building software that the article places the blame on. In case this wall of text should come across the wrong way: I love Nix, and I wouldn't want to give it up for anything. I switched away from Homebrew about a year ago and haven't looked back. I am someone who writes a lot of random scattered projects in lots of different languages, and being able to document "system" dependencies on things like pango or imagemagick or pcre or whatever is really useful for me, as a way to augment my cabal files or package.json files or whatever else. But it was pretty hard to learn how to wield it effectively. And I wish that others could experience the benefits without having to go through what I did (although if you want to go through what I did, I wrote about the experience here: https://ianthehenry.com/posts/how-to-learn-nix/ https://ianthehenry.com/posts/how-to-learn-nix/). Someone already said this but yeah, Nix the idea: long overdue. Nix the implementation: maybe check back in a couple years.
eointierney 5y ago
Aaargh! Nix is amazing! It is my daily OS driver. Except the documentation is terrible. Guix is communicably slightly better but ideologically slightly worse. Shepherd is lovely. How about someone creates a dsl in Rust that manages declarative system configurations at a _very_ high level of abstraction? We need the declarative purity, the categorical proofiness, the simplistic easiness of nix/guix, but we also need to make it actually useable.
- southerntofu 5y ago
  > How about someone creates a dsl in Rust that manages declarative system configurations at a _very_ high level of abstraction? Did you read my mind? I'm personally more interested in a "rustible" kind of tooling, but i can definitely see myself writing packages/abstractions for a "rustix" too. As nixops and guix deploy have shown, the two concepts are very related. Where do other likeminded people meet and talk about this? Should we create a chan on a friendly IRC/MUC server? (please not on a platform which requires web clients, or where the bridges to IRC/XMPP are bad)
  - laerus 5y ago
    > As nixops and guix deploy have shown, the two concepts are very related. can you elaborate please? are you talking about using Rust for package definitions?
    - southerntofu 5y ago
      Well package definitions is what i was referring to as "rustix". While grandparent comment was more about configuration management which i referred to as "rustible". I'm more interested in the latter, but i can see the appeal for both. Being able to generate docs (cargo doc) for the entire project and run doctests across all packages to ensure all provided examples actually work sounds very useful.
sontek 5y ago
I love the idea of nix but the inconsistency and developer experience is terrible. I want to suggest people use it but there is too many rough edges currently. For example, if you want to install a package the old way, you'll install it including the channel: nix-env -iA nixpkgs.ripgrep but then if you want to remove one, you don't reference the channel: nix-env -e ripgrep You have a similar issue if you want to use the new `nix` command. To install a package you'll do: nix profile install nixpkgs#ripgrep but running: nix profile remove nixpkgs#ripgrep will do nothing. It won't say "I didn't remove the package" or "package not found". It just returns silently. The only way to remove it is to point to the number from `nix profile history` or the actual path. It is unbearably slow: > time nix-env -qaP ripgrep nixpkgs.ripgrep ripgrep-13.0.0 11.17s user 2.70s system 73% cpu 18.970 total Overall I love the idea but it has a long way to go in developer experience and quality before it is ready for any mainstream adoption.
- Izkata 5y ago
  It's the "-A" that requires "nixpkgs." for installing. It's slower and probably there's other details I'm missing (the complexity rarely makes me want to dig deeper than these bare-basic nix-env commands since I only use it for a couple of things), but you can do "nix-env -i ripgrep".
  - soraminazuki 5y ago
    Actually, -A makes it faster and more precise about what you want to install. The Nixpkgs repository is defined as large associative array containing packages. When "-A nixpkgs.ripgrep" is specified, nix-env looks up the associative array using the key "ripgrep". That in theory should take constant time regardless of the size of Nixpkgs. When -A isn't specified, nix-env searches the entire associative array for a package whose "name" attribute looks similar to "ripgrep." That takes more time as the size of Nixpkgs grows. It's also less precise because the "name" attribute for packages aren't guaranteed to be unique, unlike a key for an associative array. It doesn't do an exact match either, because the "name" attribute also includes version numbers by convention. For uninstalling, nix-env doesn't have the -A flag, because it has to operate on the set of installed packages, not Nixpkgs.
frogperson 5y ago
I wanted to like nix, but its just too complicated and inconsistent for me to ever recommend it. If my team adopted it, there would be one nix guy/gal that did everything because no one else would bother to learn it. Also they seem to have alot of breaking changes in the cli. It's basically unlearnable at this point because none of the tutorials or examples work since they were written for a previous version. Nix seems like a good idea, but the implementation is just a mess. It reminds me of the messy inconsistent AI/ML code I see coming out of academia. I'll revisit when they have a single executable, that makes the simple things simple like every other package manager. `nix search mypackage` and `nix install mypackage` shouldnt be so difficult.
- annaaa 5y ago
  nix search nixpkgs mypackage nix profile install nixpkgs#mypackage
sharmin123 5y ago
taosx 5y ago
I really like the idea of nix, especially for my servers in order to do provisioning and configuration.. Problems 1. Not working by default 2. Documentation is ...not ready 3. There are some versioning issues [1] A week ago I tried to install the nix (the package manager) on my arch box using the recommended multi-user script and it screw up with permissions and ended up not working.
killjoywashere 5y ago
what makes this different from cmake?
- rgoulter 5y ago
  I've only used simple CMake stuff, but: CMake is aimed at describing how a C/C++ project is built, and competes with autotools. Nix is aimed at describing packages installed to a system, and competes with (say) apt-get or Dockerfiles or Ansible.
slapslash 5y ago
If there can be a „digital supply chain“ attack on packages, why shouldn‘t that be the case for the sources too?
- bpye 5y ago
  When you list the sources for a Nix package you also have to specify the hash expected. If it pulls the sources and the hash doesn't match then the package will fail to build.
  - slapslash 5y ago
    Ahh, I see. But couldn‘t the hash then also be used on the packages themselves?
    - rgoulter 5y ago
      The package in the cache which it's downloaded from? I think so. It would be a bit more involved that "replace the package for gcc-11". The packages are addressed by the inputs which built them. There has been some effort towards supporting content-addressable storage. https://www.tweag.io/blog/2020-09-10-nix-cas/ https://www.tweag.io/blog/2020-09-10-nix-cas/ https://edolstra.github.io/pubs/secsharing-ase2005-final.pdf https://edolstra.github.io/pubs/secsharing-ase2005-final.pdf
silisili 5y ago
I'm not really anti-nix, but never really understood the appeal. Linux is already a niche market, and this is some subset of that. I've been running a home grown Arch variant for years without a single issue. Why someone like me would want to type everything out as some config language is beyond me. I could likely completely nuke my setup and redo it all in less time and effort than learning Nix. In fact, I can say it takes about an hour - I usually do it anually.
- MarcScott 5y ago
  For me the appeal of NixOS is that I never have to nuke my setup. I probably used to do that about three or four times a year when I was running a Debian variant. I'd get lazy and install a bunch of stuff globally with apt and pip and then not really know what state my machine was in, then nuke it and start afresh. With NixOS I know what state my machine is in all the time, can transfer the configs to another machine, and never have to nuke it. I don't know the Nix language, and haven't bothered to learn it. I do understand my own config files though and steal from others if I need to.
  - silisili 5y ago
    Thanks for your experience. To be clear, I never reset because I have to, just to clear things out. Despite what anyone says, things do get funky. For example, I noticed different behaviors and tools between wpa_supplicant and iwd. Deleting iwd left me in a working but half state, as the ips stayed the iwd way. That times hundreds over a year really makes things weird.
    - soccerdave 5y ago
      Except with nix it doesn’t make it weird. If you delete iwd and something stops working, then you can just roll back to the previous generation of the nix store that included iwd.
- jordanbeiber 5y ago
  Linux, niche?! Idk where you’ve been, but Linux is ubiquitous and runs everywhere. It’s about scale mainly. A nixos host can be viewed as a solid state environment, in some respects. At least from a systems management perspective. If you scale up to more than one host, that you want to keep in a completely manged state, nothing really beats a model like nixos (or guix, although I lack experience). Having the complete system state of n machines, where n > 1 nixos is hard to beat. I have extensive experience with tools such as ansible and salt, but the state management of nix is just unbeatable. It’s, IMO, “how it’s supposed to work”. And with nixos you usually don’t have to nuke anything - a new system generation is enough.
colordrops 5y ago
Nix is like vim. If you base your opinion on the first month of use you are gonna have a bad one. The learning curve can be a bit steep, but once you get past it there's no going back.
palata 5y ago
I don't get it. So with Nix, every package I install will possibly come with its own dependency tree, completely independent from other packages. So instead of relying on distro maintainers who, say, check one version of OpenSSL, I'll be relying on the devs of each package. I doubt they will do the work, so either they will never update their deps, or update without checking them. It feels like Nix is like npm for my system, and distributes the trust I put in maintainers between all the devs of all the dependencies. That's not what I want... What am I missing?
- KingMachiavelli 5y ago
  > Instead of relying on distro maintainers who, say, check one version of OpenSSL, I'll be relying on the devs of each package. This actually is not the case (although you could do it). While Nix has the capability for every package to have it's own dependency tree, the actual channels/repositories don't keep track of more versions of packages than necessary. For example, OpenSSL has exactly 3 versions; the 3.0.x branch, the 1.1.1x branch, and the 1.0.1x branch. Some applications need the old 1.0.1x, most are probably on 1.1.1x, while others are moving towards 3.0.x Nix allows you to distribute packages and their dependencies as quickly as upstream allows but it still defaults to allowing dependencies to update normally and will rebuild packages automatically. For comparison, I checked Archlinux's repositories and they also have two versions of OpenSSL but they have to make sure the shared libraries don't conflict on the filesystem while Nix handles this automatically. For more sane examples, Nix can easily provide 5 different Python versions, 5 PostgreSQL versions, etc. But if a package doesn't care what the exact Python 3 version is, then it can just take "python3" as an input which will automatically upgrade as you would expect. If a package works with 3.8 but not 3.9 then it can be pinned to 3.8. Additionally, while the NixOS nixpkgs repository has a lot of maintainers, there are a lot fewer members with commit privileges so it's not the NPM wild west. With extensive use of Github actions/tags, they can quickly merge simple updates while making sure packages definitions are of high quality.
GolDDranks 5y ago
I think that Nix's time will come in some years. Without features like flakes and command line tools with better UX, it's still too hard. These things are in the pipeline, but at least for me, Nix doesn't feel quite polished yet. I'm using it on my servers though, and the experience is great when you don't have to do anything that differs too much from the "standard setup".
IshKebab 5y ago
> Some languages, such as Jsonnet or Starlark, are not statically typed Facebook's Starlark parser has some experimental support for type hints.
nmadden 5y ago
> As an example of where this central point of failure becomes problematic, attackers can modify a package to include malware in what is known as a digital supply chain attack. What we really want, and what no package manager can give us today, is reproducibility. Tavis Ormandy of Google Project Zero wrote a very good debunking of this supposed security benefit of reproducible builds: https://blog.cmpxchg8b.com/2020/07/you-dont-need-reproducible-builds.html https://blog.cmpxchg8b.com/2020/07/you-dont-need-reproducibl...
- pwm 5y ago
  Related: https://www.tweag.io/blog/2020-12-16-trustix-announcement/ https://www.tweag.io/blog/2020-12-16-trustix-announcement/
- tomberek 5y ago
  That article is merely making the argument that reproducibility on its own does not improve security. This is clearly true. Anyone can also claim that code-signing does not improve security because "well, you have to trust either this blob of software, or this certificate blob, or this signature, what's the difference?" The difference is when you start to compose these parts into a larger system. Dependable qualities of a system (eg: a specific hash function is one-way, or that specific problems are hard/easy to solve) can be used to create the security properties you want. I doubt Tavis is saying that builds should not be reproducible; just that it is not going to provide security on it's own in a trivial manner. I'd argue that reproducibility can help create secure systems with properties otherwise unobtainable (or difficult).
  - nmadden 5y ago
    I’m sure reproducible builds has some small part to play in supply chain security, but I think it is massively over-emphasised. My own view is that all of supply chain security is somewhat of a red herring anyway. I don’t want to have to trust software vendors at all, whether I think they may have been hacked or not. I shouldn’t have to trust log4j or any other legitimate dependency. And I shouldn’t have to audit the source code (or delegate that) to find out if I should trust it. We run all software with far too many privileges by default. Kate Sills at Agoric had a great article about this a few years back (Medium, sorry): https://medium.com/agoric/pola-would-have-prevented-the-event-stream-incident-45653ecbda99 https://medium.com/agoric/pola-would-have-prevented-the-even...
gizzlon 5y ago
> Whatever package is thrown your way, you can rebuild it locally and check whether you have the expected build output Isn't this just security theater? If you trust the source and build everything yourself you already have trusted binaries? For more see https://news.ycombinator.com/item?id=30395361 https://news.ycombinator.com/item?id=30395361 and their link
- southerntofu 5y ago
  Using a distro like nixos highers the bar for attackers since more eyes might be looking at upstream updates for malicious codes (not an obligation though). Moreover, i don't know about nix but in the guix ecosystem there's the guix challenge command which enables to query different build servers for the same build hash so you don't have to build it yourself but can split trust among several trustworthy actors. So one build server getting compromised would quasi-instantly raise alarms.
steeleduncan 5y ago
Is there a system for running a package cache for nix? I love how Nix stops dependency churn from breaking my builds. What worries me is that it introduces quite a few dependencies on remote servers, both for any global repository, and any tarballs referenced in the nix file. With golang, you can setup your own package proxy, point GOPROXY environment to that, and then be guaranteed that even if the original host is no longer available, you can build your code. Is there an equivalent for nix?
- southerntofu 5y ago
  I'm unaware of the details (haven't done that myself) but you can run your own build server and repository. The problem is more about archiving upstream sources, but if your own build server runs behind a caching proxy it should not be a problem once initial build of all your packages is done.
- KingMachiavelli 5y ago
  Yes, the nix store essentially acts as a cache. Nix can access "substituters" (e.g. remote nix stores/caches) over SSH. If you run nix-serve that's what cache.nixos.org is using (nix store over HTTP). [1] If you enable the "keep-outputs" and "keep-derivations" in your Nix config then your local nix store should keep anything it used until you manually clean out old derivations (assuming you aren't accessing the tarballs via some ---impure method). An easier option is to use a tool/service like cachix [2] to run your own repository which can be used just like the normal cache.nixos.org. [1] https://nixos.wiki/wiki/Binary_Cache https://nixos.wiki/wiki/Binary_Cache [2] https://www.cachix.org/ https://www.cachix.org/
- tomberek 5y ago
  This is an often unappreciated killer feature in Nix. (perhaps not well explained or documented?) copy runtime requirements: nix copy --to s3://some-bucket ./result copy full build description: nix copy --to s3://some-bucket ./result --derivation copy runtime of the buildtime: nix path-info -r nixpkgs#hello --derivation | xargs -n1 nix path-info | nix copy --to s3://some-bucket Then you set your substituter to s3://some-bucket either in nix.conf or in CLI with --substituters Or if you don't like s3, point it to https, ssh, or a simple local file directory.
Cloudef 5y ago
I've recently grown to like nix. When it works its awesome. When it doesnt work though prepare to get your hands dirty fixing some packages. https://github.com/NixOS/nix/issues/6113 https://github.com/NixOS/nix/issues/6113 https://github.com/NixOS/nixpkgs/pull/160554 https://github.com/NixOS/nixpkgs/pull/160554 The ability to compile everything simply just from one file is amazingly powerful though, and makes sure its all isolated. With NixOS being able to define whole system with one file is also extremely powerful. I bet valve's steamos wouldve been better with nixos as base and flatpak for users to install apps with, and i say this as someome who has used arch for over 10 years. Nix makes development of complex systems easier. Since the derivations can be cached, your builds will also be faster.
WJW 5y ago
Perhaps it is just me, but the provided example makes me shudder: > For a made-up example, let’s imagine your company maintains a tool built 25 years ago with the C compiler from that time. It can’t be upgraded safely because the entire world’s banking system would fall apart if it did. Maybe you keep a dedicated laptop as a digital time capsule to maintain this tool. Instead, you can create a Nix shell with whatever version of the tools you need, pinned and never upgraded. Yikes! If your company depends on a tool it can never upgrade because the business would collapse if you did, you should be embarking on mitigation projects and/or partial rewrites right now! Don't enable this abusive situation for longer with "Oh but Nix makes it much safer!", because that is going to make the problem that much worse when it finally does collapse.
- arianvanp 5y ago
  Look at it like this: Nix will also make it safer to upgrade. If it goes wrong you can easily roll back and try again with some extra patches. The fact that I _know_ I can go back to a safe state makes me less scared about delaying updates. So these situations will happen less if working with Nix IMO
- naasking 5y ago
  I'm not sure what you mean by "when it finally does collapse". What kind of scenario are you thinking about?
  - WJW 5y ago
    Maybe I'm projecting my own experiences onto this, but the few times I've encountered "critical 25 year old code that can't be upgraded" situations they have always been badly neglected and knowledge about their workings is either already gone or concentrated in a few people about to retire. No codebase has eternal life: sooner or later you need to upgrade the code anyway because some upstream vendor finally retired an API, or CPU vendor finally ran out of spare parts for the obscure architecture it was running on, regulation like GDPR means big changes are needed, etc etc etc. If you do the upgrades sooner, more of the domain knowledge that the original devs built up will still be around and upgrading will be relatively painless. If you delay until the last possible moment, you virtually guarantee that the upgrade will be as painful as possible. In the example, Nix being used as a bandaid to further delay upgrades is very likely going to lead to long term problems IMO, any codebase that is critical to a business should always be in a state of partial rewriting/refactoring/upgrading, to keep it up-to-date but also just to keep the current devs familiar with how it all works. Institutional knowledge degrades over time otherwise and regular maintenance is way cheaper than the occasional massive blowup. That said, nix has other benefits and it's merely this example that I have a problem with. Please don't use nix to excuse poor software maintenance practices, but use it for things it was meant for.
atombender 5y ago
Is anyone using Nix to standardize local development tool versions? In our company — as in most companies, I suppose — apps rely on a specific toolchain, such as the Go compiler, Protobuf, linters, PostgreSQL, and so on. Coordinating these is difficult. We have to maintain documents saying "install Go 1.17" and so on. Some people are on different architectures, though we are all on either macOS or Linux. The other challenge is coordinating these versions with what's used to build and test. A developer might accidentally develop using different versions than what we build and run with. Our solution for a subset of these tools is to use Docker. We have helper scripts to let you run some standard versions of some tools. But there is a lot of friction inherent to using Docker, especially on a Mac. My idea would be to use Nix to specify the complete environment, and that thjs could also be leveraged to run exactly the same environment in automated builds and tests. That would require running Nix locally as well as inside our Docker builds and CI runs (CircleCI, mostly). How difficult is this? My concern is that it could be difficult to mix Nix with the parent OS if you don't adopt NixOS wholesale, which I think would be going too far. For example, imagine we want Go and the Protobuf compiler in our toolchain. If we used official Nix packages for these, they probably declare dependencies on things like libc and other libraries that Nix also provides. But we'd like to continue using our Debian Docker images. Maybe instead of using the NixOS packages, we could write our own package tree from scratch for just the limited subset of tools we need?
- ris 5y ago
  See `dockerTools` for using Nix to build very minimal docker images.
- SAI_Peregrinus 5y ago
  My employer does this. They (the team that maintains this) use Nix & direnv, so local developers get nix-based tool versions when they `cd` into the company repo directories, and whatever their native machine provides elsewhere. They support NixOS, Ubuntu LTS, Pop!OS, and Mac OS for this setup. Anything else and you're on your own, but I use Debian with it and just occasionally submit patches.
  - atombender 5y ago

310 points by susam 5y ago

is nix commonly used only for compiled languages? for example, is there anyone who creates and manages separate packages for frontend and backend in a web project? I would like to hear what benefits there are if any.

johnnyAghands 5y ago

Open paragraph starts with Joe Armstrong -- ok I'm sold.

geocrasher 5y ago

I'm not against Nix or any package manager. What I'm against is the general fragmentation of Linux that makes interoperability between distro's and window managers problematic. If there's every going to be a Year Of The Linux Desktop (TM) then there must be a way for a user to fulfill the expectation that they can select "Linux" instead of "Mac" and "Windows" when downloading software, and when they double click or drag it or whatever, it just installs without a fuss about which distribution they're using or which UI libraries they need or which package manager they use.

podge 5y ago
I agree with your point about fragmentation. But isn't the "Year Of The Linux Desktop" just a joke at this point? Even more so now that desktop computing is becoming less and less important to most people.
- bee_rider 5y ago
  Well, we can't look forward to "Year Of The Linux Phone," because that's been around for a while now in the form of Android. Maybe "Year Of The Actual, Like, Real Linux Phone, Ugh, You Know What I Mean," though?
ghostwriter 5y ago
There's no fragmentation, Nix apart from many other things is first of all a build system, and it can build Debian and/or RPM packages for you from the same sources it uses for NixOS [1] [1] https://nixos.wiki/wiki/Nixpkgs/Building_RPM_DEB_with_nixpkgs https://nixos.wiki/wiki/Nixpkgs/Building_RPM_DEB_with_nixpkg...
smoldesu 5y ago
The problem as I can see it is that the "solutions" don't really work either. Here's your options, in order of viability: - AppImage. Basically the idea of "Apps" ripped straight out of MacOS and injected right into Linux. Works fine, but clutters your home directory with Another Folder and doesn't integrate with your desktop like a native package. - Snap. Works on any system that can install snapd, is owned by Canonical (a pro or a con depending on who you ask), but also auto-updates and has occasional performance problems. Plus, snapd is generally kinda fussy. - Flatpak. Sandboxing taken to it's (il)logical extremes. If you like random data loss, confusing package manifests, low-performance and generally broken software, this is the way to go. Of course, most people like it when their compositor doesn't break when installing third-party programs, so they avoid it like the plauge. It's a uniquely bad format, almost worth spinning up a Linux VM to try it for a laugh. Just make sure to use GNOME, it's useless anywhere else. That's the true hallmark of a cross-distro packaging solution! So yeah, we're probably due in for Another Competing Standard. At this point though, I think most developers are contented to just ship an RPM and an Arch package and let everyone else figure stuff out for themselves. Honestly, I prefer that approach when compared to the blasted wasteland that is cross-distro package management.
- 3np 5y ago
  Could you be more specific about your issues with Flatpak? No idea what you’re talking about here.
  - 1_player 5y ago
    It's trolling of the "everything new in Linux is crap" type, just check their post history. Random data loss because one uses Flatpak, seriously?
    - smoldesu 5y ago
      > Random data loss because one uses Flatpak, seriously? I wish I was joking: https://twitter.com/planner_todo/status/1492084099875586049 https://twitter.com/planner_todo/status/1492084099875586049
Ericson2314 5y ago
The major problem here is the lack of dialogue between language-specific package managers and distro package managers. I think once that is fixed, a lot of stuff will start improving. I wrote https://github.com/NixOS/rfcs/pull/109/ https://github.com/NixOS/rfcs/pull/109/ in hopes Nix can help lead the way here.
- AlphaSite 5y ago
  If this were true Mac and Windows wouldn’t thrive, but they do just fine without a system level package manager at all.
  - Ericson2314 5y ago
    Err i was trying to answer > What I'm against is the general fragmentation of Linux that makes interoperability between distro's and window managers problematic. I disagree that downloading software being hard is a major impediment. (though I realize the parent did continue to claim that.) How many people download executables on the regular anyways?
  - nick__m 5y ago
    Windows now has a first-party package manager: https://github.com/microsoft/winget-cli https://github.com/microsoft/winget-cli It positively surprised me when I did `sudo winget upgrade` (I first did `winget install gerardog.gsudo` in an admin prompt) and it detected and upgraded the majority of the already installed OSS on my Windows workstation.
wheresmycraisin 5y ago
Aren't we past that? Vast majority of Linux desktops are Ubuntu/Debian or Redhat/Centos. You target those two and you're set. Add Suse if you have a large European user base.
- 3836293648 5y ago
  Or just target flatpak and let it mostly just work
qbasic_forever 5y ago
Nix doesn't have anything to do with that problem. If anything it helps as it lets multiple even conflicting versions of libraries and software coexist and run together. What you want is flatpak or appimage (or even snap). These are self contained distributed binaries that contain and isolate all their dependencies. It is simply a one file download for any linux distro. They work great--I use a ton of flatpak apps like VS Code all the time.
contravariant 5y ago
You phrase this as if it's getting continually worse, but I'm not sure if distros were ever that interoperable (unless you deliberately restrict yourself to a point in time where there was exactly 1 distro). If anything it seems to me that you now have a decent chance to get software to run on any recent distro, which wasn't always the case. Though that's just my impression, I'd be happy to be proven wrong by someone better informed.
chlorion 5y ago
I am not so sure that this is really as big of a problem as it's made out to be. To me it seems like people trying to make Linux software management work like Windows because that's what they are used to, so if the experience is different than what they are used to they assume it doesn't work well. Going to some project's website and trying to find a download to install is not typically how you install software on Linux, and people distributing software like that for Linux probably don't know much about Linux software distribution themselves. If you want a good experience you should be installing software from the system package manager instead of searching for deb files that are probably out of date and won't work on your system due to shared library compatibility issues. Using the system package manager is much different than what many are used to but it actually works very well. The other option is to use flatpak or similar software, which is designed to sanely handle out of repo software installation. I think people distributing their own deb/rpm/etc files from their project's website are causing active harm and confusing people who are new to Linux. The best option is to provide a link to the distros package if it exists (https://archlinux.org/packages/foo https://archlinux.org/packages/foo), instructions on how to build from source and a flatpak image (or similar). When a new user downloads a stray deb and has a bad experience with it (broken software, system breakage, etc) it really leaves a poor impression on them that could have easily been avoided.
- n0w 5y ago
  I don't disagree with what you're saying, but it's interesting that some people might want to make Linux software distribution more like Windows or macOS because of unfamiliarity. The way you've described Linux software distribution sounds an aweful lot like software distribution on mobile devices. I think it should be pretty familiar to everyone by now. If anything I think Windows and macOS want to move closer to being like Linux in this regard. Maybe the experience of using cli tools like `apt` or `yum` has made people overlook the ease of installing software on Linux. Anyone that has used openSUSE or Ubuntu should know better.
southerntofu 5y ago
> there must be a way for a user to fulfill the expectation that they can select "Linux" instead of "Mac" and "Windows" when downloading software There's already established ways to do that such as AppImage, which has bonus points (compared to other solutions) for PGP signatures and differential (delta) upgrades. What's lacking is proper desktop environment integration for an ~/Apps folder like you have on MacOS where this pattern of one-file-per-app has been established for longer. If you want to go one step further, 0install would make it possible to not even have to choose between "Mac", "Windows" and "Linux" on the download page, which is kind of amazing in a way.
1_player 5y ago
Heard of Flatpak?

gavinray 5y ago

> Nix often scares newcomers and experienced devs alike, because it proposes a fairly radical overhaul to how we think about package management and how we run software in general. I am not sure this is the main put-off of nix. Ideologically, I love nix. The syntax/language itself is a massive barrier IMO. I use Nix for personal projects, but I prefer the experience of Devcontainers. They're easier to understand and debug (for me). I'm watching eagerly the work being done by the ostree/rpm-ostree folks who are also trying to solve for a similar problem. Hoping to see something like "Nix but with YAML/JSON" come out of that. https://ostree.readthedocs.io/en/stable/manual/related-projects/#nixos-nix https://ostree.readthedocs.io/en/stable/manual/related-proje...

Ericson2314 5y ago
By their own text in what you linked: > OSTree only supports only system-level images, and doesn't do dependency management. I think that makes it....not really like Nix at all. Dependency management is Nix's core functionality. Everything I would happily delegate to other layers.
- octoberfranklin 5y ago
  ... kinda like people who pretend that Zig is a competitor to Rust, and conveniently forget to mention that it does not promise memory safety. I've been seeing a lot of "steal their thunder" type project positioning lately when something is a radical leap forward but requires major effort to learn -- like nix or rust. People seem to have picked up on a strategy that if you can put together something inferior but easier to understand (zig doesn't need a borrow checker because it's memory-unsafe; ostree doesn't need a language because it ignores dependencies), and market it as an alternative to the radical thing, a much larger group of people will rally around the simpler thing instead of the radical thing because they feel threatened by the new thing that can't be learned in a weekend or even a week, and using only "20%-time" would take six months to master... I'm going to get downvoted to hades for this, but it's true.
  - ajb 5y ago

otikik 5y ago

For devops engineers and system administrators, yes. For the rest of us, Nix is still missing friendlier face and a gentler learning curve.

n42 5y ago
I'm not sure why you're downvoted so much -- I am all in on Nix. I use it professionally. I agree with you 100%. I'm convinced whoever solves the UX issue of Nix will have the next "big thing" on their hands. I hope it's the OSS community and not a repeat of Docker, Inc.
takeda 5y ago
By "rest of us" do you mean developers? I find Nix especially useful on that front by being able to provide a common dev environment and also when used for CI it can speed up builds through its caching. They do have unfortunate name of the project and it is harder to find articles about just Nix, while NixOS is more unique.

Arubis 5y ago

Nix is indeed a great idea. I do hope that idea’s time has come. But, oh, man, that config syntax. I’d love to see some alternative, human-friendlier interface; am thinking here of how Elixir really induced a significant pickup in usage of the BEAM owing largely to being perceived as friendlier to newcomers than Erlang.

capableweb 5y ago
Nix (the language, not to be confused with NixOS, the operating system) is not that hard to pickup, if you already know a programming language or two. Read through about the syntax and you'll get the gist in a couple of hours, and you basically know it inside out if you spend a day or two reading and experimenting with it. You just need to spend the time to understand it, and it's no longer a hurdle. What I think really stops NixOS from gaining mainstream popularity (eh, mainstream like in the Linux ecosystem, not mainstream-mainstream) is the inability of just downloading binaries and running them, when you have to. It's a huge hurdle to try to figure out the right incarnation to set the lib paths correctly for the binaries but woops, it's actually using something else and now you need to do some other hacky thing. nix-autobahn et al exists but are also hacky and sometimes outright doesn't work, and then you're basically lost, unless you can rebuild the binary yourself, which unless it's free/open source software, you're unlikely to be able to do. This, I think is the real reason people are avoiding to adopt it, because there is no easy solution to this problem, unlike the problem of syntax which can be solved by simply learning it.
- Ericson2314 5y ago
  Yeah absolutely Don't get me wrong, Nix can and should be better in many respects, but: > Second, Nix surfaces all the complexity involved in building software and forces you to deal with it. Yes, and If you can't deal with the simple functional language Nix happens to come with, you will never be able to deal all that surfaced complexity. The latter is 10x worse more challenging. So in some sense the language is a decent filter for people who won't like the inevitable rest anyways.
  - 5y ago

nwmcsween 5y ago

Nix has a few shortcomings: * The syntax isnt well liked. * The package manager relies on global state which kills the use of sharing / over NFS. * The nixstore treats a filesystem as an object store. * Related to above, permissions aren't secure as they could be. Some of these can be worked around, some of them require an entirely new project.

Ericson2314 5y ago
That's a decent list, but I don't think we need to start from scratch. I think Nix can be adapted to meet all of those.
catern 5y ago
>* The nixstore treats a filesystem as an object store. That's a weird thing to list as a shortcoming, since that's the main innovation of Nix. ("package management as memory management" as the paper and thesis said)
- nwmcsween 5y ago
  Because you can encode the same information within the files and some dirs while keeping the benefits of a filesystem, heck you could encode what nix uses sqlite for using symlinks, files and dirs
- deleted 5y ago
  [deleted]
ncmncm 5y ago
Moreso than the syntax, the language semantics are a problem. There seems to be no value in a dynamically-typed system description language, but both a practical burden and a degree of unnecessary risk. Transitioning to a more consciously-designed, statically-typed, still-declarative language should put the project on sounder footing. The existing language interpreter should be easy enough to instrument to annotate all the existing specs with the actual types seen when building the corresponding packages, enabling automatic translation and transition to a better language for almost all packages, excepting only those (probably?) few that actually rely on dynamic-type follies. Those last could stay on the old language, be hand-translated to the new one, or be abandoned, case by case.

iamevn 5y ago

I dove in recently and am enjoying it on a home server. The only trouble I had was with setting up fuse filesystems correctly. A couple times it completely refused to boot because I got some fuse option wrong and a filesystem failed to mount. These were options that worked correctly when started dynamically through "nixos-rebuild switch" but not on boot through /etc/fstab. I've written my own overlays and some derivations for my own tools and genuinely enjoy the language.

panta82 5y ago

I'm sorry, I keep hearing about this thing, but it's just not solving any major problem I actually have in in programming or computer environment. Non-reproducable environments are just not such a big issue that it's worth "radical rethinking" of everything to solve.

georgyo 5y ago
What are the problems you actually have? If you want to deploy and configure something, nix does that exceptionally well. If you want to install up to date software on Debian, RHEL, or other distribution but not negatively impact the system, nix does that exceptionally well. If you want to build containers, nix does that decently. Nix solves a lot of problems beyond reproducible environments. And it solves them permanently for nearly all use cases.
- panta82 5y ago
  But it sounds like you have to get deep into this programming language, and figure it out yourself for the stuff that's not already there? Containers and software installs etc. already have solutions that are much simpler to use. Don't require me to learn a new language or get into the weeds of how each package works.
rgoulter 5y ago
That's kinda fair, but I think it's worth keeping an eye on. Nix is really good at "programmatic environment for managing packages". Which is excellent for devops. There are advantages for developers, too.. but, developers can get away with quicker + dirtier solutions a lot of the time. e.g. Maybe your project assumes a specific version of Ruby or whatever. Nix can solve this in a nice way, but you can use Ruby version manager (or the general asdf). Want to install Python packages, without conflicting? Nix can solve this in a nice way, but you can use virtualenv. Build a container image? etc. An example of "practically useful, which Nix can do, others can't" I've seen is "just run the code from some repository". The non-Nix equivalent I've seen is `docker run <some image for a CLI tool>`. Nix allows the same UX, but without relying on containers. -- I think that's something everyone could benefit from. I think the benefits for developers are definitely there; the main downside is that compared to those "quick + dirty" solutions, anything off the happy-path with Nix is quite difficult.

__ryan__ 5y ago

Anyone use Guix[0]? How does it compare to Nix? 0: https://guix.gnu.org/ https://guix.gnu.org/

capableweb 5y ago
I've mostly used NixOS, but eyed Guix from time to time, not really dipped my toes into the Guix-water yet but not completely unwilling either, the syntax and cohesion is really interesting and alluring when compared to NixOS. I have the two threads favorites (sub-threads in a large conversation) that might be of interest to you: - https://news.ycombinator.com/item?id=18908591 https://news.ycombinator.com/item?id=18908591 - Guix seems interesting but I almost stopped reading when I read "Nix".... [submission: Guix: An advanced operating system] - https://news.ycombinator.com/item?id=23528380 https://news.ycombinator.com/item?id=23528380 - Does anyone know of a recent comparison of NixOS vs Guix? ... [submission: Guix Further Reduces Bootstrap Seed to 25%]
southerntofu 5y ago
I've briefly used both so don't expect my comparison to be exhaustive: - nix uses a centralized non-free repo (Github) ; guix relies on mailing lists for patches - nix invents an entire language ecosystem that's based on JSON + functions ; guix reuses an existing (and complete) programming language (GNU/Guile, a dialect of Scheme lisp) - nix packages proprietary software as long as they can provide a checksum for their executables/packages ; guix has a dedicated repo (non-guix) for that ; in both cases it's opt-in - nix has differences in behavior when run as a distro (nixos) or on a foreign system ; guix has unified naming conventions for both cases (although some details of setting up on a foreign distro for eg. GUI applications can be a bit tricky) - nix CLI is... confusing, to say the least ; guix CLI UX could be improved but is rather easy - nix packages tend to be updated more quickly compared to guix packages - guix maintainers are very picky about package descriptions: i tried to package a rust program along with ~20 dependencies, and the maintainer said i should come up with different short summaries vs long descriptions for those 20 dependencies... which are software i've never used so i'm not the good person to do just that - guix has a strong emphasis on security R&D: bootstrappability is making huge progress alongside the guix project (see blog posts), which to my knowledge isn't researched on nix side ; "guix challenge" and "guix git-authenticate" are very important/cool things to read about if you're curious - guix may introduce major syntactic changes to ease contribution, as was recently the case with "G-expressions" https://guix.gnu.org/en/blog/2021/the-big-change/ https://guix.gnu.org/en/blog/2021/the-big-change/ - nix uses mainline Linux + systemd ; guix uses Linux-libre + GNU/shepherd Probably many other differences other people will point out, but that's the ones that struck me so far attempting to use both.

breakds 5y ago

I have been running NixOS and uxing Nix for almost everything since I switched to it, and my experience has been great so far. It is one versatile solution to a lot of applications: 1. I run NixOs on on laptop and workstation, for work and for personal use. Any change to the configuration can be immediately transfered to other machines. And give me a new machine, I can quickly bring it up with the configuration that I am always using. 2. I run NixOS on my home server and machine learning cluster. Deploy experiment and service on them is as simple as updating the git-managed configurations. Meanwhile, if I want to use more power to run an experiment, NixOps can quickly bring up a set of machines on AWS with the configuration identical to my local experiment. You do not need to worry about setting up CUDA/pytorch and other dependencies every. 3. In my start-up, it definitely took more time to train the developers to learn Nix, but once they get familiar, everyone becomes a good DevOps engineer, which solves development environemnt (that invloves C++/Python), CI/CD and release really well.

willlll 5y ago

If there is something like heartbleed that needs to update a common dependency, how does NixOS deal with that? Do you need to rebuild everything that uses that dependency, instead of just changing the shared library on a more traditional os?

catern 5y ago
Yes - same as with containers.
kibwen 5y ago
Yes, but that's not a problem. In traditional systems the reason to avoid rebuilding everything isn't because it takes time (it does, but not that much time); the reason to avoid rebuilding everything is the fear that, halfway through rebuilding everything, you'll discover that some shared lib is missing, or some crucial toolchain has been uninstalled, or that some updated packages rely on incompatible versions of the same dependency, and it turns into a nightmare of toolchain and dependency resolution, leaving your system in a half-upgraded mess. But if the promise of Nix is true, then that's no longer possible; you rebuild everything, all the dependencies work out fine, and you go on with your day.
ParetoOptimal 5y ago
In practice you'll hit a binary cache or build once, push to your cache, then subsequent builds hit cache.

haberman 5y ago

It sounds like this is similar in concept to Bazel, except the output of Bazel is a statically linked binary instead of a binary that dynamically links .so's with known SHAs. In both cases you have a language that fully specifies how to hermetically and reproducibly build some output artifact(s) based on dependencies that are fixed down to the SHA.

tadfisher 5y ago
Dynamic linking is the default in nixpkgs, but Nix itself does not care what you build. So you can use the infrastructure in `pkgs.static` to build statically-linked binaries if you like.
fooblessmooo 5y ago
Nix is repeatable, but not upper-case Reproducible i.e. you don’t necessarily always get the same hash from the same build. Order of operations or concurrency or something like that.

ianthehenry 5y ago

> Whatever package is thrown your way, you can rebuild it locally and check whether you have the expected build output. This is analogous to verifying a binary downloaded from the Web by computing its sha256 hash, and comparing it to the one provided by the publisher of the binary. Can someone explain this to me? There is an experimental feature to add content-addressable packages that will give you this, but Nix package hashes are hashes of a package description, not the package, so you can't use them like a checksum. You can say "Hey do you have this package I want?" and a server can use the input hash to find what you're talking about, but there's no way that you can verify that what they gives you represents a good-faith attempt to build the package. I would also be very surprised to learn that a significant portion of Nixpkgs is "bit-for-bit" reproducible. That's hard! It's hard enough to get packages to work with Nix at all, and very few compilers/build systems/etc are actually concerned with literal reproducibility. Nix doesn't magically provide that. (There are also "fixed-output" package descriptions which are mostly used when you're downloading sources from the internet -- those actually are checksummed and verified, in case the remote source changed. I guess you could use that same mechanism for a build output, but you... don't?) Anyway, maybe this is a reference to the (experimental! bleeding edge!) content-addressable store stuff, but I don't think it's fair to call that a selling point of Nix yet. (Or I am way out of line. I don't really know what I'm talking about.) > Why is this important? Because it removes the need to trust the provider and makes the cost of detecting a failure or an attack much lower for the developer. Reproducibility means security for your systems and applications, and peace of mind for your developers. There is a large amount of trust when you download a binary Nix file, which is why you have to configure only trusted cache servers, and why cache servers will only accept submissions from trusted sources. Reproducibility is really important, and a great feature of Nix -- you can, given a package description, build it yourself instead of downloading it -- but emphasizing security and trust seems very misleading to me. If someone can clarify these points I would appreciate learning something new about Nix. > Nix undoubtedly has a steep learning curve, and there are two reasons for that. First, using Nix entails rethinking a lot of accepted wisdom and practices that have become second nature for a developer. Unlearning is hard. Second, Nix surfaces all the complexity involved in building software and forces you to deal with it. In order to make builds truly reproducible, this is largely inevitable. I disagree very strongly with these two statements. This reads like "It's not Nix's fault that it's hard to learn; it's your fault for not trying hard enough." I think that's absolutely not true. Nix is hard to learn, and it's mostly Nix's own fault -- which is a good thing! Because it means that it's fixable. Nix's approach to package management isn't some fundamentally difficult concept to wrap your head around. The concepts and ideas are pretty straightforward, once you understand them -- but how are you supposed to understand them? The Nix manual is sort of infamous, and not without reason. Nowhere in the manual will it teach you how to write a standalone package description -- although it will show you how to contribute one to the Nixpkgs repo, which is a pretty different flow. It doesn't really explain the high-level mental model I have of the Nix store as a simple graph database. There is almost no coverage of nix-shell, or the things it can do (which include some really cool things! Shebangs that explicitly list all of your scripts dependencies!). The quick start guide, until quite recently, explained how to install packages using the "wrong" command -- `nix-env -i git` -- which takes about a minute to run on my machine. (The "right" command -- `nix-env -iA nixpkgs.git` -- is instantaneous.) But it's not just the documentation's fault. Why is there a wrong way to install packages in the first place? It's one of many weird historical mistakes, which are all forgivable independently, but which add up to one of the most confusing and inconsistent command-line interfaces I have ever used. `nix-env -e` takes glob-looking things, but `nix-env -q` takes regular expressions... I dunno. There are tons of things like that. (There is a new command-line interface that you can opt into by editing a Nix config file, which is much better, but not without its own fun new set of problems.) In my experience the incidental complexity of Nix was a much larger barrier to learning about Nix than the "actual" complexity of bundling and building software that the article places the blame on. In case this wall of text should come across the wrong way: I love Nix, and I wouldn't want to give it up for anything. I switched away from Homebrew about a year ago and haven't looked back. I am someone who writes a lot of random scattered projects in lots of different languages, and being able to document "system" dependencies on things like pango or imagemagick or pcre or whatever is really useful for me, as a way to augment my cabal files or package.json files or whatever else. But it was pretty hard to learn how to wield it effectively. And I wish that others could experience the benefits without having to go through what I did (although if you want to go through what I did, I wrote about the experience here: https://ianthehenry.com/posts/how-to-learn-nix/ https://ianthehenry.com/posts/how-to-learn-nix/). Someone already said this but yeah, Nix the idea: long overdue. Nix the implementation: maybe check back in a couple years.

eointierney 5y ago

Aaargh! Nix is amazing! It is my daily OS driver. Except the documentation is terrible. Guix is communicably slightly better but ideologically slightly worse. Shepherd is lovely. How about someone creates a dsl in Rust that manages declarative system configurations at a _very_ high level of abstraction? We need the declarative purity, the categorical proofiness, the simplistic easiness of nix/guix, but we also need to make it actually useable.

southerntofu 5y ago
> How about someone creates a dsl in Rust that manages declarative system configurations at a _very_ high level of abstraction? Did you read my mind? I'm personally more interested in a "rustible" kind of tooling, but i can definitely see myself writing packages/abstractions for a "rustix" too. As nixops and guix deploy have shown, the two concepts are very related. Where do other likeminded people meet and talk about this? Should we create a chan on a friendly IRC/MUC server? (please not on a platform which requires web clients, or where the bridges to IRC/XMPP are bad)
- laerus 5y ago
  > As nixops and guix deploy have shown, the two concepts are very related. can you elaborate please? are you talking about using Rust for package definitions?
  - southerntofu 5y ago
    Well package definitions is what i was referring to as "rustix". While grandparent comment was more about configuration management which i referred to as "rustible". I'm more interested in the latter, but i can see the appeal for both. Being able to generate docs (cargo doc) for the entire project and run doctests across all packages to ensure all provided examples actually work sounds very useful.

sontek 5y ago

I love the idea of nix but the inconsistency and developer experience is terrible. I want to suggest people use it but there is too many rough edges currently. For example, if you want to install a package the old way, you'll install it including the channel: nix-env -iA nixpkgs.ripgrep but then if you want to remove one, you don't reference the channel: nix-env -e ripgrep You have a similar issue if you want to use the new `nix` command. To install a package you'll do: nix profile install nixpkgs#ripgrep but running: nix profile remove nixpkgs#ripgrep will do nothing. It won't say "I didn't remove the package" or "package not found". It just returns silently. The only way to remove it is to point to the number from `nix profile history` or the actual path. It is unbearably slow: > time nix-env -qaP ripgrep nixpkgs.ripgrep ripgrep-13.0.0 11.17s user 2.70s system 73% cpu 18.970 total Overall I love the idea but it has a long way to go in developer experience and quality before it is ready for any mainstream adoption.

Izkata 5y ago
It's the "-A" that requires "nixpkgs." for installing. It's slower and probably there's other details I'm missing (the complexity rarely makes me want to dig deeper than these bare-basic nix-env commands since I only use it for a couple of things), but you can do "nix-env -i ripgrep".
- soraminazuki 5y ago
  Actually, -A makes it faster and more precise about what you want to install. The Nixpkgs repository is defined as large associative array containing packages. When "-A nixpkgs.ripgrep" is specified, nix-env looks up the associative array using the key "ripgrep". That in theory should take constant time regardless of the size of Nixpkgs. When -A isn't specified, nix-env searches the entire associative array for a package whose "name" attribute looks similar to "ripgrep." That takes more time as the size of Nixpkgs grows. It's also less precise because the "name" attribute for packages aren't guaranteed to be unique, unlike a key for an associative array. It doesn't do an exact match either, because the "name" attribute also includes version numbers by convention. For uninstalling, nix-env doesn't have the -A flag, because it has to operate on the set of installed packages, not Nixpkgs.

frogperson 5y ago

I wanted to like nix, but its just too complicated and inconsistent for me to ever recommend it. If my team adopted it, there would be one nix guy/gal that did everything because no one else would bother to learn it. Also they seem to have alot of breaking changes in the cli. It's basically unlearnable at this point because none of the tutorials or examples work since they were written for a previous version. Nix seems like a good idea, but the implementation is just a mess. It reminds me of the messy inconsistent AI/ML code I see coming out of academia. I'll revisit when they have a single executable, that makes the simple things simple like every other package manager. `nix search mypackage` and `nix install mypackage` shouldnt be so difficult.

annaaa 5y ago
nix search nixpkgs mypackage nix profile install nixpkgs#mypackage

sharmin123 5y ago

taosx 5y ago

I really like the idea of nix, especially for my servers in order to do provisioning and configuration.. Problems 1. Not working by default 2. Documentation is ...not ready 3. There are some versioning issues [1] A week ago I tried to install the nix (the package manager) on my arch box using the recommended multi-user script and it screw up with permissions and ended up not working.

killjoywashere 5y ago

what makes this different from cmake?

rgoulter 5y ago
I've only used simple CMake stuff, but: CMake is aimed at describing how a C/C++ project is built, and competes with autotools. Nix is aimed at describing packages installed to a system, and competes with (say) apt-get or Dockerfiles or Ansible.

slapslash 5y ago

If there can be a „digital supply chain“ attack on packages, why shouldn‘t that be the case for the sources too?

bpye 5y ago
When you list the sources for a Nix package you also have to specify the hash expected. If it pulls the sources and the hash doesn't match then the package will fail to build.
- slapslash 5y ago
  Ahh, I see. But couldn‘t the hash then also be used on the packages themselves?
  - rgoulter 5y ago
    The package in the cache which it's downloaded from? I think so. It would be a bit more involved that "replace the package for gcc-11". The packages are addressed by the inputs which built them. There has been some effort towards supporting content-addressable storage. https://www.tweag.io/blog/2020-09-10-nix-cas/ https://www.tweag.io/blog/2020-09-10-nix-cas/ https://edolstra.github.io/pubs/secsharing-ase2005-final.pdf https://edolstra.github.io/pubs/secsharing-ase2005-final.pdf

silisili 5y ago

I'm not really anti-nix, but never really understood the appeal. Linux is already a niche market, and this is some subset of that. I've been running a home grown Arch variant for years without a single issue. Why someone like me would want to type everything out as some config language is beyond me. I could likely completely nuke my setup and redo it all in less time and effort than learning Nix. In fact, I can say it takes about an hour - I usually do it anually.

MarcScott 5y ago
For me the appeal of NixOS is that I never have to nuke my setup. I probably used to do that about three or four times a year when I was running a Debian variant. I'd get lazy and install a bunch of stuff globally with apt and pip and then not really know what state my machine was in, then nuke it and start afresh. With NixOS I know what state my machine is in all the time, can transfer the configs to another machine, and never have to nuke it. I don't know the Nix language, and haven't bothered to learn it. I do understand my own config files though and steal from others if I need to.
- silisili 5y ago
  Thanks for your experience. To be clear, I never reset because I have to, just to clear things out. Despite what anyone says, things do get funky. For example, I noticed different behaviors and tools between wpa_supplicant and iwd. Deleting iwd left me in a working but half state, as the ips stayed the iwd way. That times hundreds over a year really makes things weird.
  - soccerdave 5y ago
    Except with nix it doesn’t make it weird. If you delete iwd and something stops working, then you can just roll back to the previous generation of the nix store that included iwd.
jordanbeiber 5y ago
Linux, niche?! Idk where you’ve been, but Linux is ubiquitous and runs everywhere. It’s about scale mainly. A nixos host can be viewed as a solid state environment, in some respects. At least from a systems management perspective. If you scale up to more than one host, that you want to keep in a completely manged state, nothing really beats a model like nixos (or guix, although I lack experience). Having the complete system state of n machines, where n > 1 nixos is hard to beat. I have extensive experience with tools such as ansible and salt, but the state management of nix is just unbeatable. It’s, IMO, “how it’s supposed to work”. And with nixos you usually don’t have to nuke anything - a new system generation is enough.

colordrops 5y ago

Nix is like vim. If you base your opinion on the first month of use you are gonna have a bad one. The learning curve can be a bit steep, but once you get past it there's no going back.

palata 5y ago

I don't get it. So with Nix, every package I install will possibly come with its own dependency tree, completely independent from other packages. So instead of relying on distro maintainers who, say, check one version of OpenSSL, I'll be relying on the devs of each package. I doubt they will do the work, so either they will never update their deps, or update without checking them. It feels like Nix is like npm for my system, and distributes the trust I put in maintainers between all the devs of all the dependencies. That's not what I want... What am I missing?

KingMachiavelli 5y ago
> Instead of relying on distro maintainers who, say, check one version of OpenSSL, I'll be relying on the devs of each package. This actually is not the case (although you could do it). While Nix has the capability for every package to have it's own dependency tree, the actual channels/repositories don't keep track of more versions of packages than necessary. For example, OpenSSL has exactly 3 versions; the 3.0.x branch, the 1.1.1x branch, and the 1.0.1x branch. Some applications need the old 1.0.1x, most are probably on 1.1.1x, while others are moving towards 3.0.x Nix allows you to distribute packages and their dependencies as quickly as upstream allows but it still defaults to allowing dependencies to update normally and will rebuild packages automatically. For comparison, I checked Archlinux's repositories and they also have two versions of OpenSSL but they have to make sure the shared libraries don't conflict on the filesystem while Nix handles this automatically. For more sane examples, Nix can easily provide 5 different Python versions, 5 PostgreSQL versions, etc. But if a package doesn't care what the exact Python 3 version is, then it can just take "python3" as an input which will automatically upgrade as you would expect. If a package works with 3.8 but not 3.9 then it can be pinned to 3.8. Additionally, while the NixOS nixpkgs repository has a lot of maintainers, there are a lot fewer members with commit privileges so it's not the NPM wild west. With extensive use of Github actions/tags, they can quickly merge simple updates while making sure packages definitions are of high quality.

GolDDranks 5y ago

I think that Nix's time will come in some years. Without features like flakes and command line tools with better UX, it's still too hard. These things are in the pipeline, but at least for me, Nix doesn't feel quite polished yet. I'm using it on my servers though, and the experience is great when you don't have to do anything that differs too much from the "standard setup".

IshKebab 5y ago

> Some languages, such as Jsonnet or Starlark, are not statically typed Facebook's Starlark parser has some experimental support for type hints.

nmadden 5y ago

> As an example of where this central point of failure becomes problematic, attackers can modify a package to include malware in what is known as a digital supply chain attack. What we really want, and what no package manager can give us today, is reproducibility. Tavis Ormandy of Google Project Zero wrote a very good debunking of this supposed security benefit of reproducible builds: https://blog.cmpxchg8b.com/2020/07/you-dont-need-reproducible-builds.html https://blog.cmpxchg8b.com/2020/07/you-dont-need-reproducibl...

pwm 5y ago
Related: https://www.tweag.io/blog/2020-12-16-trustix-announcement/ https://www.tweag.io/blog/2020-12-16-trustix-announcement/
tomberek 5y ago
That article is merely making the argument that reproducibility on its own does not improve security. This is clearly true. Anyone can also claim that code-signing does not improve security because "well, you have to trust either this blob of software, or this certificate blob, or this signature, what's the difference?" The difference is when you start to compose these parts into a larger system. Dependable qualities of a system (eg: a specific hash function is one-way, or that specific problems are hard/easy to solve) can be used to create the security properties you want. I doubt Tavis is saying that builds should not be reproducible; just that it is not going to provide security on it's own in a trivial manner. I'd argue that reproducibility can help create secure systems with properties otherwise unobtainable (or difficult).
- nmadden 5y ago
  I’m sure reproducible builds has some small part to play in supply chain security, but I think it is massively over-emphasised. My own view is that all of supply chain security is somewhat of a red herring anyway. I don’t want to have to trust software vendors at all, whether I think they may have been hacked or not. I shouldn’t have to trust log4j or any other legitimate dependency. And I shouldn’t have to audit the source code (or delegate that) to find out if I should trust it. We run all software with far too many privileges by default. Kate Sills at Agoric had a great article about this a few years back (Medium, sorry): https://medium.com/agoric/pola-would-have-prevented-the-event-stream-incident-45653ecbda99 https://medium.com/agoric/pola-would-have-prevented-the-even...

gizzlon 5y ago

> Whatever package is thrown your way, you can rebuild it locally and check whether you have the expected build output Isn't this just security theater? If you trust the source and build everything yourself you already have trusted binaries? For more see https://news.ycombinator.com/item?id=30395361 https://news.ycombinator.com/item?id=30395361 and their link

southerntofu 5y ago
Using a distro like nixos highers the bar for attackers since more eyes might be looking at upstream updates for malicious codes (not an obligation though). Moreover, i don't know about nix but in the guix ecosystem there's the guix challenge command which enables to query different build servers for the same build hash so you don't have to build it yourself but can split trust among several trustworthy actors. So one build server getting compromised would quasi-instantly raise alarms.

steeleduncan 5y ago

Is there a system for running a package cache for nix? I love how Nix stops dependency churn from breaking my builds. What worries me is that it introduces quite a few dependencies on remote servers, both for any global repository, and any tarballs referenced in the nix file. With golang, you can setup your own package proxy, point GOPROXY environment to that, and then be guaranteed that even if the original host is no longer available, you can build your code. Is there an equivalent for nix?

southerntofu 5y ago
I'm unaware of the details (haven't done that myself) but you can run your own build server and repository. The problem is more about archiving upstream sources, but if your own build server runs behind a caching proxy it should not be a problem once initial build of all your packages is done.
KingMachiavelli 5y ago
Yes, the nix store essentially acts as a cache. Nix can access "substituters" (e.g. remote nix stores/caches) over SSH. If you run nix-serve that's what cache.nixos.org is using (nix store over HTTP). [1] If you enable the "keep-outputs" and "keep-derivations" in your Nix config then your local nix store should keep anything it used until you manually clean out old derivations (assuming you aren't accessing the tarballs via some ---impure method). An easier option is to use a tool/service like cachix [2] to run your own repository which can be used just like the normal cache.nixos.org. [1] https://nixos.wiki/wiki/Binary_Cache https://nixos.wiki/wiki/Binary_Cache [2] https://www.cachix.org/ https://www.cachix.org/
tomberek 5y ago
This is an often unappreciated killer feature in Nix. (perhaps not well explained or documented?) copy runtime requirements: nix copy --to s3://some-bucket ./result copy full build description: nix copy --to s3://some-bucket ./result --derivation copy runtime of the buildtime: nix path-info -r nixpkgs#hello --derivation | xargs -n1 nix path-info | nix copy --to s3://some-bucket Then you set your substituter to s3://some-bucket either in nix.conf or in CLI with --substituters Or if you don't like s3, point it to https, ssh, or a simple local file directory.

Cloudef 5y ago

I've recently grown to like nix. When it works its awesome. When it doesnt work though prepare to get your hands dirty fixing some packages. https://github.com/NixOS/nix/issues/6113 https://github.com/NixOS/nix/issues/6113 https://github.com/NixOS/nixpkgs/pull/160554 https://github.com/NixOS/nixpkgs/pull/160554 The ability to compile everything simply just from one file is amazingly powerful though, and makes sure its all isolated. With NixOS being able to define whole system with one file is also extremely powerful. I bet valve's steamos wouldve been better with nixos as base and flatpak for users to install apps with, and i say this as someome who has used arch for over 10 years. Nix makes development of complex systems easier. Since the derivations can be cached, your builds will also be faster.

WJW 5y ago

Perhaps it is just me, but the provided example makes me shudder: > For a made-up example, let’s imagine your company maintains a tool built 25 years ago with the C compiler from that time. It can’t be upgraded safely because the entire world’s banking system would fall apart if it did. Maybe you keep a dedicated laptop as a digital time capsule to maintain this tool. Instead, you can create a Nix shell with whatever version of the tools you need, pinned and never upgraded. Yikes! If your company depends on a tool it can never upgrade because the business would collapse if you did, you should be embarking on mitigation projects and/or partial rewrites right now! Don't enable this abusive situation for longer with "Oh but Nix makes it much safer!", because that is going to make the problem that much worse when it finally does collapse.

arianvanp 5y ago
Look at it like this: Nix will also make it safer to upgrade. If it goes wrong you can easily roll back and try again with some extra patches. The fact that I _know_ I can go back to a safe state makes me less scared about delaying updates. So these situations will happen less if working with Nix IMO
naasking 5y ago
I'm not sure what you mean by "when it finally does collapse". What kind of scenario are you thinking about?
- WJW 5y ago
  Maybe I'm projecting my own experiences onto this, but the few times I've encountered "critical 25 year old code that can't be upgraded" situations they have always been badly neglected and knowledge about their workings is either already gone or concentrated in a few people about to retire. No codebase has eternal life: sooner or later you need to upgrade the code anyway because some upstream vendor finally retired an API, or CPU vendor finally ran out of spare parts for the obscure architecture it was running on, regulation like GDPR means big changes are needed, etc etc etc. If you do the upgrades sooner, more of the domain knowledge that the original devs built up will still be around and upgrading will be relatively painless. If you delay until the last possible moment, you virtually guarantee that the upgrade will be as painful as possible. In the example, Nix being used as a bandaid to further delay upgrades is very likely going to lead to long term problems IMO, any codebase that is critical to a business should always be in a state of partial rewriting/refactoring/upgrading, to keep it up-to-date but also just to keep the current devs familiar with how it all works. Institutional knowledge degrades over time otherwise and regular maintenance is way cheaper than the occasional massive blowup. That said, nix has other benefits and it's merely this example that I have a problem with. Please don't use nix to excuse poor software maintenance practices, but use it for things it was meant for.

atombender 5y ago

Is anyone using Nix to standardize local development tool versions? In our company — as in most companies, I suppose — apps rely on a specific toolchain, such as the Go compiler, Protobuf, linters, PostgreSQL, and so on. Coordinating these is difficult. We have to maintain documents saying "install Go 1.17" and so on. Some people are on different architectures, though we are all on either macOS or Linux. The other challenge is coordinating these versions with what's used to build and test. A developer might accidentally develop using different versions than what we build and run with. Our solution for a subset of these tools is to use Docker. We have helper scripts to let you run some standard versions of some tools. But there is a lot of friction inherent to using Docker, especially on a Mac. My idea would be to use Nix to specify the complete environment, and that thjs could also be leveraged to run exactly the same environment in automated builds and tests. That would require running Nix locally as well as inside our Docker builds and CI runs (CircleCI, mostly). How difficult is this? My concern is that it could be difficult to mix Nix with the parent OS if you don't adopt NixOS wholesale, which I think would be going too far. For example, imagine we want Go and the Protobuf compiler in our toolchain. If we used official Nix packages for these, they probably declare dependencies on things like libc and other libraries that Nix also provides. But we'd like to continue using our Debian Docker images. Maybe instead of using the NixOS packages, we could write our own package tree from scratch for just the limited subset of tools we need?

ris 5y ago
See `dockerTools` for using Nix to build very minimal docker images.
SAI_Peregrinus 5y ago
My employer does this. They (the team that maintains this) use Nix & direnv, so local developers get nix-based tool versions when they `cd` into the company repo directories, and whatever their native machine provides elsewhere. They support NixOS, Ubuntu LTS, Pop!OS, and Mac OS for this setup. Anything else and you're on your own, but I use Debian with it and just occasionally submit patches.
- atombender 5y ago