31 ms·

The Curse of NixOS

• OOPMan 5y ago
  I gave up on NixOS years ago. It doesn't matter how many nice ideas you have, even revolutionary ones, when the core experience is just such a giant PITA.
• gypsyharlot 5y ago
  I always found Guix more appealing, because it uses a programming language that is useful for other things as well (GNU Guile). I really can't stand having to learn a new language for each thing I want to manage.
  • yaysyu 5y ago
    Does guix also have any equivalent to patchelf?
    • georgyo 5y ago
      Guix uses patchelf. Patchelf is very useful anytime you want to change the location of dynamic loaded libraries but don't want to set LD_LIBRARY_PATH. It is used in more places than you might originally think.
      • lillecarl 5y ago
        GoboLinux also uses patchelf.
      • rekado 5y ago
        We don't use patchelf for any official package definition. We have a package for patchelf, but it's only really useful when you have pre-built binaries that you can't rebuild from source.
        • georgyo 5y ago
          The main guix monorepo may set that hard requirement the everything just be built from source, but if you want to run closed source software than your only two options are make a fake FHS or use patchelf. Both methods have pros and cons. Only patchelf makes the result work well with other closed source programs. While from a philosophical point of view guix is pure, real world usage often needs closed source software.
          • rekado 5y ago
            Yes, for pre-built binaries you can't really get around patchelf. For example, that's also how CUDA is packaged for Guix.
  • globular-toast 5y ago
    Is the author aware of Guix?
    • alpaca128 5y ago
      Apparently not, or forgot about it when writing the article: > it's so clearly the only operating system that actually gets how package management should be done
      • Filligree 5y ago
        He might be one of the many, many people whose hardware isn't supported by Guix.
        • alpaca128 5y ago
          Oh right, I forgot it's a purely Free Software distro.
      • xxpor 5y ago
        Isn't Guix just nix with guile?
  • mplanchard 5y ago
    I completely agree, but the main benefit nix has over guix is some amount of MacOS compatibility. I don’t currently use a Mac, but I know that next time I have to use one for work, my home-manager-mediated config, which contains almost all of my user-specific configuration, will port right over just fine. The guix team doesn’t seem particularly interested in supporting MacOS, and I can’t blame them. The other benefit is mindshare, so things tend to get updated more quickly in nix than in guix. I do really wish I could use guile rather than the nix language though. I’ve gotten used to it, but the complicated abstractions in nixpkgs are still often inscrutable.
    • ninjin 5y ago
      I have had NixOS as my daily driver for nearly three years now and maintain a small number of packages in Nixpkgs. From my perspective, macOS support is a headache as it all of the sudden may require you to debug on a proprietary OS that you lack access to and that runs on two different hardware architectures in order to get a patch accepted. I am probably not going to make any friends for saying so, but I would much prefer if Nixpkgs for macOS was maintained separately. My personal reasons for not going with Guix is that it is a GNU project and thus you have to buy into the entire FSF philosophy. Sadly I do need to run on “problematic” hardware from time to time and would prefer if doing so did not require me to add unofficial extensions and be wary of uttering such heresy in the company of my fellow users. That being said, I like what Guix is doing and their documentation does frankly look better compared to the grass where I am standing. Lastly, yes, NixOS is a damn curse. Once you get the taste of having a declarative operating system it is really hard to go back. Trying out tiny tweaks to your audio, kernel, etc. all with the confidence that you know how to get back to what you had before is so very addictive. We need more diversity in this space.
      • mplanchard 5y ago
        Oh yeah no doubt MacOS is a huge pain. We use nix for installing system deps at work, and it seems like once every six months or so something will inexplicably stop working on Mac. Luckily I have an old Mac at home, but the new architecture means that one is becoming pretty much useless now for debugging some of the stuff that comes up. Still, being able to guarantee everyone working on the project has the same versions of everything is pretty nice. No need to worry about ancient Mac versions of bash or awk or sed or whatever, so we can script confidently.
  • valyagolev 5y ago
    as much respect as I have for Guile, I'd love the nix configuration language to have at least partially enforced types...
    • agumonkey 5y ago
      time for hix .. and lets revive http://lambda-the-ultimate.org/node/299 http://lambda-the-ultimate.org/node/299
    • eadmund 5y ago
      It really is a pity that Guix didn't go for Common Lisp instead — it does allow for gradual typing. And it has standardised a ton of stuff that Guile had to implement on an ad hoc basis.
      • dannyobrien 5y ago
        Honestly, I kind of like how Guix and Guile have been growing together. Like Rust and Servo (and the Rust compiler), I think the constraint of having a general-purpose language, but a general purpose language that is also responsive to a bigger project, has been beneficial to both.
• Kelteseth 5y ago
  > Almost all of the good things about NixOS are natural consequences of this single decision. This quote stood out to me because you can really use it anywhere, just replace NixOS with any other piece of software, like: "Almost all of the good things about <rusts_module_system_that_treats_a_file_as_a_module> are natural consequences of this single decision." Looking at you, c++20[1] - [1] https://gitlab.kitware.com/cmake/cmake/-/issues/18355#note_1109192 https://gitlab.kitware.com/cmake/cmake/-/issues/18355#note_1...
• rgoulter 5y ago
  """The first is relatively simple: they developed their own programming language to do configuration, which is not very good and is extremely difficult to learn. The vast majority of people using NixOS do not understand the language, and simply copy/paste example configurations, which mostly works until you need to do something complicated, at which point you're completely high and dry.""" Maybe this is nitpicking, but: the Nix language is about as straightforward as "JSON plus functions". Maybe that is difficult for people who haven't had an experience with pure/functional programming? Though, yes, the way Nix is used can be quite complicated/sophisticated. -- Even if all of Nixpkgs were translated to JavaScript, I think it'd still be complicated to understand. (Though I suspect using a more general purpose language would allow for more footguns). +1 to the sentiment that most of the time you can get by just fine, but when you can't, NixOS is more difficult to make progress with compared to other Linux distributions.
  • count 5y ago
    We already had JSON plus functions. We called it 'JavaScript' :)
    • jeofken 5y ago
      JavaScript also includes bad footgun-features like procedures, aka functions with effects. Neither Nix nor JSON have this feature, making Nix in this aspect closer to JSON than JavaScript is.
    • gorjusborg 5y ago
      Ha, nice! Seriously though, javascript is not a great language if you are looking for robust determinism. I can understand their decision to go elsewhere, given the domain and design.
      • IshKebab 5y ago
        People have tried: https://github.com/jkcfg/jk https://github.com/jkcfg/jk But yeah I agree. The thing is, if all you need is robust determinism why do you need a full functional language with currying and other complex concepts? Google had the same problem for Bazel, and their solution (Starlark) is way easier to understand.
• assbuttbuttass 5y ago
  As a NixOS user, I like this article a lot. But one thing stood out to me: > It also means that it's impossible to statically know what other packages a given package might depend on. Currently, the way this is implemented is essentially grepping a package for /nix/store/ to try to figure out what the dependencies are, which is obviously... not great. I'm not sure what the author is talking about here. He says it's impossible to find static dependencies, but then describes how it's implemented. I'm also not sure why the author thinks this solution is bad? Maybe because it could accidentally pull in more runtime dependencies than you were expecting?
  • mplanchard 5y ago
    There is also a nix store query to find this information. I’m on my phone so I can’t get it right now, but I’ll try to remember to grab it later. You can query all the dependencies of any derivation… this is how I verify the full suite of software that nix-direnv installs for local projects, by querying the store for its cached derivation’s deps.
    • valyagolev 5y ago
      i think “statically” means without executing the nix language stuff
      • mplanchard 5y ago
        Oh, I see, thank you for the clarification. I figure it’s just as hard to get a list of transitive packages dependencies without apt or whatever as it is without nix, though. And there’s an argument to be made that a pure function on a derivation can be considered static. But I don’t disagree with any of the general points: especially that nix the language, or more specifically nix in practice as it’s used in nixpgs, is very hard to learn.
  • deleted 5y ago
    [deleted]
  • tomberek 5y ago
• angryold 5y ago
  I have been using NixOS for the last 6 months or so and it's been great for a daily driver. I use it across a half dozen machines I use for various purposes (desktop/laptop, some servers and VMs) and keep a similar setup on all my machines so they're similar and have all similar packages for reuse for my workflows. The author is on point when you have to do any custom stuff (I basically have a bunch of hacks that do things a very non-NixOS way or use docker/containers for stand-alones) how rapidly things get out of hand. I still haven’t bothered trying to decipher some of that world yet.
• colinramsay 5y ago
  > I'm going to keep using it, since I can't stand anything else after having a taste of NixOS This is how I feel about NixOS. I like what it gives me but I don't really like much else about it. Unless something _just works_, you're looking at hours of debugging which will most likely lead to failure. Off the top of my head there are a couple of things I've hit a dead end on recently: - Packaging a Flutter desktop app because its build process downloads fonts from a URL and so makes the whole thing impure - Getting Blender's GPU support working, I think the same problem is causing Webcamoid to crash on launch Previously I used Arch, which I loved, but it was all to easy to completely shaft my setup and not be able to roll back.
  • nine_k 5y ago
    I'd say that packaging an app for NixOS should include rewriting all such impure steps, and making the fonts packaged along with the app is one such step. If the fonts can't be packaged for licensing reasons, even as a separate package, then well, you indeed can guarantee that you'd be able to install the app next time. If it's not what you seriously need, then likely the value proposition of Nix is not for you.
    • colinramsay 5y ago
      I agree. That doesn't negate the fact that it took me a while to understand what the issue was, see if I could get around it, work out how to disable the font downloading in Flutter, etc, etc. I may have been trying to force a round peg into a square hole but NixOS didn't do much to help me see the shape of the pegs and holes in the first place.
  • vasergen 5y ago
    > Unless something _just works_, you're looking at hours of debugging which will most likely lead to failure. Exactly my experience, in this case I simply switch to my OS package system (I use Nix only as a package manager on my Ubuntu). I think, I have round 95% of software coming from Nix, for the other 5% that doesn't work out of box, I just do 'apt-get install' Also, for installing different programing languages I switched from Nix packages to 'asdf', because packages on Nix often not up to date if I want to try recent release.
• AshamedCaptain 5y ago
  > But at the same time, I can patch the Python interpreter and then have some software running on my system actually use the patched version, since all of this stuff is configured through the same configuration system. If I want to do that, then I have to rebuild the entire system so as to use my patched version. This is because the NixOS "dependencies" are basically expressed as hashes of binaries. That is for me the single biggest deal-killer of NixOS, Guix, and while we're at it -- static linking.
  • Throwaway194902 5y ago
    NixOS and Guix do _not_ require static linking. They go even one step further and allow many versions of a dynamic object to exist at the same time and each software on your system chooses, which version of the object to link against.
    • AshamedCaptain 5y ago
      You cannot change the version used by a given binary unless you rebuilt that binary, effectively making it similar to static linking (you still get sharing of DSO files & pages, though). i.e. even if I have two versions of some low-level library installed, depending installed packages still hardcode which one of the two low-level libraries to use, and if I want to switch the system from one to the other, I have to rebuilt it (or at least all depending packages). Suppose I make an overlay of libc to add some functionality that I am debugging which changes the libc binary, albeit not the ABI. Can I still reuse the same packages? Can I still reuse someone else's binary cache ? Basically, can I do without having to rebuild the entire system (save for libc) ?
      • JamesSwift 5y ago
        If you are fine with sidestepping the system as intended then nothing prevents you from forcefully replacing the dynamically-linked, shared libc in the nix store.
      • watusername 5y ago
        Yes, there is system.replaceRuntimeDependencies [1] that does what you ask: It replaces dependencies recursively in derivation outputs through binary patching, creating _new_ store paths (so immutability is preserved). It does so by replacing all occurrences of the store paths of the original dependency (e.g., libc) with the new ones [2]. [1] https://search.nixos.org/options?channel=21.11&show=system.replaceRuntimeDependencies&from=0&size=50&sort=relevance&type=packages&query=replaceRuntimeDependencies https://search.nixos.org/options?channel=21.11&show=system.r... [2] https://github.com/NixOS/nixpkgs/blob/fad04722fc3d692e3511e58e337ec9fa627f5ba5/pkgs/build-support/replace-dependency.nix#L3-L19 https://github.com/NixOS/nixpkgs/blob/fad04722fc3d692e3511e5...
• aero-glide2 5y ago
  I hope the Simula VR guys are reconsidering having NixOS the default.
• avakand 5y ago
  I tried using NixOS on a laptop for a month and switched back to Arch a couple of months ago. It was an interesting experience - I never used functional programming language before, but nix was pretty ok as a configuration language. It looks like funny version of JSON with functions. Debugging it was a real pain though - I was trying to write (or copy from someone else config) a function to recursively import all modules from a folder and the error messages were hard to understand with stacktraces ending somewhere deep in standard library. The other problem was with nixpkgs, i.e. I haven't found a clear list of packages that were going to be updated. Jetbrains IDEA was updating very slowly and when I wanted to pin a version of it simply overriding version variable in the overlay was not enough - there were also some other linked variables. Emacs package from custom overlay constantly tried to compile itself, requiring me to check build status on hydra build system. In the end I decided that it's not really worth it. I don't have many systems and services to manage and for a raspberry pi and a vps multiple docker-compose.yaml files in git repo is enough. I think Henrik Lissner (author of Doom Emacs) wrote a really good piece about why someone should choose to use NixOS - https://github.com/hlissner/dotfiles#frequently-asked-questions https://github.com/hlissner/dotfiles#frequently-asked-questi...
  • epage 5y ago
    Another problem I ran into is trying to figure out how each package wants me to define plugins. There are common examples for Python environments (Python packages are like plugins into Python) but when it came to other software, I was at a loss when digging into things, even after reading all of the general documentation.
  • amarshall 5y ago
    > I haven't found a clear list of packages that were going to be updated. The ideal here, IMO, is to use flakes and the nix-diff to compare the build before switching. E.g. nixos-rebuild --flake '.#myhost' build nix-diff /nix/var/nix/profiles/system result sudo nixos-rebuild --flake '.#myhost' switch Could do the same without flakes after the fact by running nix-diff on different generations in /nix/var/nix/profiles (there may be a way before switch). It’s unfortunate that how to do the above is non-obvious.
• ashtonkem 5y ago
  The real break for me using NixOS as a regular driver was that I just could not figure out how to get Ruby on Rails to play nice with it. NixOS breaks a lot of assumptions that programs make about $PATH, and even if it's done for good reasons it plays holy hell with the development stack of some languages. I eventually gave up and moved my dev setup back to OSX (and then that PC died anyways). Maybe they've fixed it since then, I haven't tried. I do continue to use it for my homelab infrastructure though. It is extremely good at handling new versions of configuration of Prometheus, and I would never consider anything else at this point. Just not what I'd use as a dev environment.
  • JamesSwift 5y ago
    I moved to Docker for ruby/rails dev long ago and never looked back. Trying to do it locally, especially if there are others involved, is a path to pain and frustration as "works on my machine" creeps into a `bundle install` every few months.
    • qudat 5y ago
      After having spent weeks learning nix, I'm convinced that docker is simply a better tool for most use-cases of nix.
      • JamesSwift 5y ago
        Coming from docker before nix, I think nix is a better version of docker for some use-cases. If the ecosystem is supported then I much prefer nix for speed (both runtime and development speed)
        • qudat 5y ago
          I agree that when nix works, it's great. However, I find debugging docker infinitely easier than debugging nix. I played around with the idea of adding nix for work projects and getting buy-in from other colleagues. But after working with it for weeks and still running into issues, there's no way I could in good conscience recommend the tool.
• deleted 5y ago
  [deleted]
• DrBazza 5y ago
  In the footnote: > borgcfg ... Truly one of the worst languages I have ever seen. I'll see your borgcfg and raise you a reverse-Polish notation stack based one, written in a couple of hours and supporting a repo trading system for an investment bank for years.
  • deusum 5y ago
    And this whole time I thought the finance world was held up on an Excel spreadsheet.
    • DrBazza 5y ago
      Oh, it’s waaaay more fragile than that…
• gnu 5y ago
  NixOS and Guix are nice! Guix folks are doing some wonderful work off late. I have used NixOS for a while. But for casual desktop GNU/Linux users, it seem like solving a problem that doesn't exist. Have been using Debian on all my computers since 1998. Unless you are using Debian unstable and updating it daily, I hardly hit any breakage. Servers and deployments is another story.
  • dangerbird2 5y ago
    How does Guix compare to Nix? It seems like by using a scheme-based DSL instead of an ad-hoc configuration language, it solves one of the main complaints the author has about Nix.
    • fallat 5y ago
      IMO Guix is better but still has some work. My major pet-peeve of Guix is it's anti-proprietary software, which is a necessary compromise. The world is composed of many different people and beliefs; software should be belief-agnostic.
      • uncletaco 5y ago
        I think it's worth pointing out that guix will not package proprietary or binary software in the main channels but nonguix exists for those needs if one absolutely needs to have those packages in guix. At the same time guix packages flatpak which allows one to install most, if not all, of the proprietary packages they may want to use. I think the compromise from the guix maintainers is to develop and distribute free software but at the same time being silent on how a user goes about adding proprietary packages to their system. Which is fair IMO.
    • the_duke 5y ago
      Guix is cool but has two big drawbacks: The major one: package ecosystem. Nix has the largest and most up to date package repo of any distro [1]). Nix is already somewhat niche, but the Guix community is tiny. They also have a hard stance against proprietary software, so many things that are packaged for Nix aren't for Guix. Second: it's pretty slow. A lot of the Nix functionality is implemented in C++ . Guix is all written in Scheme, and uses a rather slow implementation. The main advantage is more coherent tooling and documentation. (Guix is much younger and doesn't have decades of legacy cruft) [1] https://repology.org/repositories/statistics https://repology.org/repositories/statistics
• gushogg-blake 5y ago
  > but the connection between those two things is essentially undocumented I often think documentation would be vastly improved if the author was simply answering the question _what problem did you solve, and how?_, but that seems like it would reveal too much of the dirty details of the design process somehow, so they try to describe the all the neatly encapsulated abstractions and metaphors they've come up with to describe the system (and to encode their own eventual understanding of it) instead. Basically - give us the dirty details and we can make the generalisations ourselves, instead of trying to load the generalised structures into our minds in the most efficient way possible.
  • tazjin 5y ago
    This implies that the author of the documentation is the person that wrote the thing though, which is surprisingly rare in larger projects. I wrote one of the more popular Nix language tutorials[0] and my approach there has been to try and explain everything as straightforwardly as possible and make it work both as a reference and a manual (i.e. you can quickly jump to a section that interests you, or read it from top-to-bottom). One thing that nixpkgs (the Nix package set, which is ~most of the public Nix code) suffers from is reinvention of abstractions (simply due to its age). For example, most programming languages have their own slightly different implementation of a `withPackages` function that gives you a prepared environment with some dependencies. Some of these use open sets, some of them use closed sets, in the latter cases overlaying things into them can get really confusing even for experienced Nix users and so on. In my opinion, the community should slow its focus on making lots of new features and spend time consolidating existing logic and agreeing on some basic abstractions. Maintenance work like that is not always fun though, and especially in unpaid open-source projects it's difficult to keep up the motivation for it. [0]: https://github.com/tazjin/nix-1p https://github.com/tazjin/nix-1p
• altgans 5y ago
  I am a NixOS user, but am interested in Guix. Based on a cursory look I have some questions: - How big is Guix on GNU? Does it throw wrenches in your way if you do anything "unfree"? How easy is it to install the nvidia-drivers? - How is the package ecosystem? 20.000 official packages seems a little low? Are there community packages? How easy it is to create your own packages? Why is the Neovim package only at version 4.4 [1]? Isn't version 5 officially released? - How good is the documentation? - Is there a project roadmap? Are there any issues preventing adoption? [1]: https://guix.gnu.org/en/packages/neovim-0.4.4/ https://guix.gnu.org/en/packages/neovim-0.4.4/
  • yewenjie 5y ago
    Yes, the low number of readily available packages is the primary reason I switched from Guix to Nix.
    • zeec123 5y ago
      And properitary drivers.
      • rekado 5y ago
        The "nonguix" repo has got you covered for all your vanilla Linux needs.
        • zeec123 5y ago
          No, it is an unofficial mess that breaks very often.
    • rekado 5y ago
      The default channel of Guix has more than 21,000 packages. Is that what counts as a "low number" these days?
      • Filligree 5y ago
        Well, I need CUDA so... I'm aware of nonguix, but it seems to break a lot more than the same packages in nixpkgs.
• yewenjie 5y ago
  There is Nickel in development which might replace Nix (the configuration language) in future. https://github.com/tweag/nickel https://github.com/tweag/nickel
  • hobofan 5y ago
    Let's hope that it gets proper docs until then, that actually lay out its syntax before trying to compare it to other languages. From what I gather, it's branching off of Nix and assuming familiarity with it. What does the `in` keyword do and why is it everywhere? From everything I can see from the code examples I highly doubt that it will reduce the number of complaints NixOS has about using a weird language.
• epage 5y ago
  I wish someone wrote a GUI for Nix that - System and home manager support - Multi-machine and multi-user support by following the practice of splitting the config up by roles / intent - Provided an "about:config" like experience for well defined fields - Integrated with git hosting for easy backup/restore - Included built-in search of other Nix config repos so you can see how other people did things (I was originally hoping to but my attention has been pulled in other directions since I keep giving up on adopting Nix)
  • KingMachiavelli 5y ago
    There isn't a GUI (although nix-gui [1] is in progress) but there is a very good and decently mature flake template called Devos [2] for accomplishing most of what you ask. It basically lets you write very simple profiles to group configuration settings together and then you can assign those profiles to machines or users. Things could still be improved but I found Devos to be good enough that NixOS is usable for personal and even some production use. Once I get around to it, I'll move/mirror my configs to Github which should serve as good examples. [1] https://github.com/nix-gui/nix-gui https://github.com/nix-gui/nix-gui [2] https://github.com/divnix/devos https://github.com/divnix/devos
• patrec 5y ago
  I think the author is quite wrong that the nix language is not very good and hard to learn. In fact it's not only the best external DSL I've seen, but also one of the few cases where inventing a new language rather than just repurposing a subset of something already established looks like a good decision to me. In fact, I consider it a marvel of language design. The mix of properties that nix has (laziness, purity, relative simplicity and good syntax for things like path-names, records or interpolation) absolutely makes sense for the problem domain and would be difficult to achieve with something more off-the-shelf. That is not to say there are no significant problems with it: the lack of static typing coupled with low runtime performance and bad error messages and debugging support means tracking down more complicated errors can be a pain and the laziness can further compound this. The main big design flaw in nix (as an ecosystem), from my perspective, is that there isn't enough separation between the parts of the build specification that a purely data driven (git hashes, version numbers, license info etc) and the parts that actually need computation (specifying a complex build recipe conditioned on various things). This lack of separation makes it harder than it should be to have tooling to programmatically transform the pure data bit (e.g. to bump the version) and also really raises the barrier of entry. Stuff that should just require a newbie to tweak some toml file often requires messing around with nix instead. There is tooling that has this separation (niv, for example) but there are a bunch of different solutions following different conventions and nixpkgs itself happily jumbles metadata with actual code. I think this has significantly held back the ecosystem. Specifically 99% of users ought to be able to just tweak some toml files to satisfy their needs rather than learning nix. This is starting to improve a bit with stuff like toml files for flake, but it's still not great. I also think the ergonomics of many of the nix command line tools are rather poor. But none of these issues seems to require significant changes to the core nix language (probably even the lack of static typing). So whilst I think there are significant practical warts, the core design is IMO extremely good.
  • avakand 5y ago
    >That is not to say there are no significant problems with it: the lack of static typing coupled with low runtime performance and bad error messages and debugging support means tracking down more complicated errors can be a pain and the laziness can further compound this. Some of this problems can be aleviated with good IDE support or language server.
• light_hue_1 5y ago
  Nix has two kinds of problems: the language and the interface. They can solve interface problems, but the Nix language is a tumor that won't be easily removed. The problem is that Nix the language is the worst of all worlds: - You can't print anything because the language is lazy. Forcing any values to print them can and will result in random operations happening on your store. You can never know which values are safe to inspect. This kills debugging. - Everything in Nix is recursive, datastructures contain copies of themselves as hacks to avoid building proper APIs. So again, you can't print anything, even if you're sure that printing the object won't do something crazy to your store. - There are almost no APIs and no uniformity in Nix. Packages are given total freedom to do anything. The Python ecosystem works totally differently from the Haskell one which works totally differently from the C++ one. It's insane. They use different datastructures, functions, etc. To do the same thing. - The Nix language has impossible error messages. You will get stuck. You can't view values and you can't get error messages. There's no moving forward from that unless you ask someone. - Laziness in Nix is different from laziness in Haskell. In Haskell, it's mostly about performance improvements and some cool tricks here and there. In Nix, laziness fundamentally means something: you build up packages and you force them to install them. Nix the package manager also has serious issues: - You cannot install Nix in your home account without root permissions (yes, there are hacks, but they break terribly). So Nix is actually less isolated and less portable than something like Anaconda! - The commandline experience is terrible. Nothing makes any sense. Not the names of the tools. Not their arguments. Why sometimes something is a binary and other times it's a mode of another tool, etc. - In exchange for making some hard things easy, Nix makes a lot of easy things very hard. Sure, it will manage an isolated environment. But, now you want a package from pip that isn't in Nix? There is literally no way for you to figure out how to do this, you need to find a tutorial online, hope it's up to date enough to work, and follow it step by step. And.. there's a good chance you misunderstood what the tutorial was doing and won't have the correct environment at the end.
  • bokchoi 5y ago
    > The commandline experience is terrible. Nothing makes any sense. Not the names of the tools. Not their arguments. Why sometimes something is a binary and other times it's a mode of another tool, etc. As a casual user of nix, this is the worst. I can never remember commands and it just increases barrier to entry. Git has a bad command line UI but nix is far worse even after their recent command line improvements. Edit: that said, I do like using home-manager to manage configs across multiple machines even though it can be confusing.
• teddyh 5y ago
  > The worst is, of course, GCL/borgcfg, the (turing complete) configuration language for Google's internal job scheduling software. “Noone has borgmon readability.” — Broccoli Man (https://www.youtube.com/watch?v=3t6L-FlfeaI https://www.youtube.com/watch?v=3t6L-FlfeaI)
• 112 5y ago
  Ranting about Nix being hard is like going to Russia and complaining that the local language doesn't sound English. Like many other things worth your time, it's something you learn through deliberate practice and focus.
  • darkarmani 5y ago
    > it's something you learn through deliberate practice and focus. That sounds like a massive barrier to entry and more effort than solving the problems I currently have.
    • Filligree 5y ago
      > That sounds like a massive barrier to entry and more effort than solving the problems I currently have. It's a lot of effort, and in the end you're left with a different, more interesting set of problems. I don't regret spending that effort, but it needs to be easier if we want more users. I don't think there's any answer besides lots more effort from the nixos dev side, however.
  • deckard1 5y ago
    There are many things that require tremendous practice and study that aren't worth your time as well. You have to justify it somehow. And I just don't see the value prop in Nix yet. I would compare it as such: Nix is to Docker what Google+ was to Facebook. Maybe it's superior. But the benefits are so marginal that the costs of switching will prohibit most from giving it a shot. Most people want reproducible builds and easy configuration. If they are getting that from Docker, why switch? At the distro level, average people are going to benefit by having reproducible builds done upstream. Debian does this, IIRC. As does F-Droid and a few others. If you trust Debian, then you implicitly trust the packages Debian installs. NixOS doesn't even solve the real aspect of Linux that I find terrifying: security. Linux is a blob of overlapping and bewildering security mechanisms and tools. You have groups, permissions, SELinux, capabilities. The whole thing leaks like a sieve.
• seddona 5y ago
  Interesting to see exponential growth in NixOS github stars https://star-history.com/#NixOS/nixpkgs&Date https://star-history.com/#NixOS/nixpkgs&Date . Perhaps the user base is reaching a tipping point where there will be the resources to address some of these problems.
  • floatingatoll 5y ago
    What fraction of those who starred a project on GitHub become committers to and/or donate more than once to it? I've always assumed that this is a vanishingly small amount, on the order of one in ten thousand or so, but I could be underestimating.
    • jonringer117 5y ago
      Currently, there's 8.7k stars, 7.2k forks. And 2000+ maintainers have added themselves: https://repology.org/repository/nix_unstable https://repology.org/repository/nix_unstable So, I would say a pretty large portion. Also, the contribution model for nixpkgs is just opening a PR, so it's a fairly low (non-technical) barrier-to-entry for most contributors.
• X6S1x6Okd1st 5y ago
  I certainly echo that it's a bit of a curse because as soon as you go off the happy path you start needing to learn the internals & the language neither of which are particularly easy. That being said, the rollback capacity, the ability to include a deterministic set of software needed for any particular software project (the inclusion of shell.nix or build.nix in a repo) is one of the few new pieces of technology that I'm unambiguously excited about becoming wide spread. It doesn't feel like it carries a dual use problem like AI or cryptocurrencies. This could mean the first time you want to use something that isn't inside nixpkgs, which to be fair has now overtaken AUR to be the biggest single repo of packages: https://repology.org/repositories/statistics/total https://repology.org/repositories/statistics/total
• swsieber 5y ago
  From everything I've read it seems like NixOS would really take off if they had great docs like Rust (both api docs and compiler error messages). Well, that and debugging.
• snicker7 5y ago
  Guix configuration is in Lisp, a well-established language (60 years and still strong). Moreover, Guix package code is written in a clear, declarative style. Nix package definitions, on the other hand, typically embed shell scripts in them.
  • zeec123 5y ago
    Yes, but systemd is missing and most drivers because they are not gnu.
    • civodul 5y ago
      Guix System uses Linux as its kernel, so no driver "is GNU", whatever that means. The choice to use the Shepherd rather than systemd is motivated by a vision that we can get better integration using a single language and set of tools all the way down. As an example, this gave us services in containers several years ago: https://guix.gnu.org/en/blog/2017/running-system-services-in-containers/ https://guix.gnu.org/en/blog/2017/running-system-services-in... Overall Guix System alone gives a coherent and unified view of the system; systemd also does that to some extent, but it's not in as good a position as Guix's declarative OS configuration to do that. For example, this is the kind of system exploration that Guix enables: https://notabug.org/civodul/guix-explorer https://notabug.org/civodul/guix-explorer
• JulianWasTaken 5y ago
  I too have tried nixOS and nix many times in the past few years (and just recently went back to having a computer with it permanently installed, albeit not my main one). I think another underappreciated reason it's been difficult to use is the CLIs involved are often really arcane (in ways that often remind me of using GNU find, a program I don't think is one that scores high UX marks). For example, uninstalling something with `nix-env` is spelled `nix-env -e something`, and querying is like `nix-env -iA ...` (yes there's a long form of the options, and most people tell you to never use nix-env, but these were the examples I recalled, I think the UX is similar across other tools). Trying to decipher what these command lines mean and searching for which ones do what you want is just really challenging, they don't follow the "rules" I'm familiar with for other CLI tools. (Maybe they follow norms from some other part of the OSS community though.) The new `nix` CLI seems to be trying to "dumb" things down a bit (or optimistically -- make a CLI that is more transparent about what operations it's doing), which is great, but it too exhibits some odd behaviors. E.g. recently after an upgrade I found it wouldn't work without passing `nix --extra-features flakes --extra-features nix-experimental-command`, even if I seemingly wasn't doing anything related to flakes. It is indeed marked experimental, so I can't fault it too much, but yeah I've found significant challenge as a new user in just trying to understand the various nix package manager binaries, their options, and how they map to "normal" package manager operations (even ignoring the procedural vs. declarative angle for how you actually manifest changes). EDIT: Other things I recall get me every time I reinstall nixOS is re-learning that you get to run `nix-collect-garbage` manually, that `nix-channel --add` doesn't automatically update, and I see I wrote down to remember that package names are case sensitive (though I didn't recheck that recently, hopefully that's changed?).
  • ratorx 5y ago
    > you get to run `nix-collect-garbage` manually If you mean running NixOS (the distro), rather than just Nix (the package manager), then there’s an option for this `nix.gc.automatic`. You may also want to look at `nix.optimise`. When using just Nix however, I don’t know if they bundle the timers.
    • jonringer117 5y ago
• kreetx 5y ago
  The major drawback for me with the nix language is that at in any location in the code I don't know what is the "shape" of the data it expects. Runtime does tell me but wish I could just go and look it up. Having a typed language would fix this. Other than that, been using nixos for ~2 years to configure my dev desktops: using the same config everywhere makes the machines identical and is thus a great relief, mostly don't carry a laptop anymore.
  • jonringer117 5y ago
    I generally use `nix repl` for this. I have an example of myself looking at what my configuration.nix renders to while debugging a module I was adding to nixpkgs/NixOS. https://youtu.be/bkDYmvKINm8?t=1949 https://youtu.be/bkDYmvKINm8?t=1949
• 0xbadcafebee 5y ago
  There are some fundamental problems that no distribution can solve (not even Nix). Every level of abstraction has its own set of dependency issues, yet there exists no abstraction or concept that handles conflicts in every one of those levels. There are a lot of hacks and kludges used by Nix in order to try to get there, but it's only most of the way. We've hit the limit of what we can kludge. I think the future of software dependency conflict resolution requires a fundamental shift in software design. We have to start new paradigms for software where handling interoperability with conflicting dependencies is a first-order feature of all systems. BerkeleyDB is a famous example of conflicts. You can't have one BerkeleyDB database shared by multiple apps designed for conflicting versions of BerkeleyDB. If you have two apps doing two different things with the same database, but they use different versions, you need two separate databases. This could be solved if both the database library and the applications were written with a version-independent abstraction. Regardless of the API/ABI, you have the app say "what versions do you support?", and then "you want v3? here's your interface", or "you want v4? here's this other interface". Internally, each app/db will use its own interface, but a translation layer will handle the v3 or v4 layer, without the application even being aware of it. As long as one of the apps is newer than the other, that newer app will have backwards compatibility with the old app. We won't need to install multiple stacks of dependencies (ala Nix) because different versions of apps will just be compatible. When in doubt, install a newer version. At first this seems unworkable. What, require everyone to constantly support every old interface?? But I think we can start over with some new concepts and primitives to handle the majority of use cases so the programmer (mostly) doesn't have to think about it. We already have relocatable versioned ABIs for things like Glibc where it advertises what minimum/maximum version it supports. We just take that a few steps further and make backwards compatibility the default. Maybe we get new build systems and new ways of linking and calling code, and ship old code bundled along with the new? We need new research to develop these new methods, because the current system we're dealing with has no more fixes possible.
  • madars 5y ago
    You might enjoy Stripe's "APIs as infrastructure: future-proofing Stripe with versioning" -- https://stripe.com/blog/api-versioning https://stripe.com/blog/api-versioning Original HN discussion: https://news.ycombinator.com/item?id=15020726 https://news.ycombinator.com/item?id=15020726
• jeofken 5y ago
  Does anyone have some tips on how I can partition an EFI laptop for NixOS with full disk encryption? I’m struggling to install NixOS on my Librem 14 - and have resolved to Ubuntu as it does all that for me.
  • Ericson2314 5y ago
    Use LUKS, don't use LVM. I do that with ZFS for all the non-ancient stuff in github.com/Ericson2314/nixos-configuration
    • jeofken 5y ago
      Why avoid LVM? If you could point me to a practical instruction on how to get it running I’d be very thankful! I’m sure I’m missing something basic - as is usual when struggling with UNIXes…
      • Ericson2314 5y ago
        There is some LVM FUD I can't confirm, but really, it's just simpler. ZFS filesystems within the same "pool" are also just more flexible. The NixOS config part you can take from my repo. The command line part is the same as for any other linux. From memory: cryptsetup luksformat physical-part cryptsetup open physical-part arbitrary-name some-command-to-make-file-system ... /dev/mapper/arbitrary-name mount /dev/mapper/arbitrary-name
  • jeppesen-io 5y ago
    I'd recommend LUKS. NixOS has a guide in the wiki but if you're looking for an example, see my nix readme. Might have a typo or two but it's 99 percent there https://github.com/NelsonJeppesen/nix-lifestyle#luks-encrypted-nixos https://github.com/NelsonJeppesen/nix-lifestyle#luks-encrypt... Unencrypted boot with LUKS root, nothing fancy https://nixos.wiki/wiki/Full_Disk_Encryption https://nixos.wiki/wiki/Full_Disk_Encryption
• qudat 5y ago
  I didn't go all-in with nixos -- and I'm thankful I didn't. I simply tried using it for local development. I thought that I could replace the various language version managers with nix. I spent weeks working with nix to understand the language, how to use it, and reading as much documentation/blogs as possible. One really frustrating thing about nix I noticed early on is the lack of support for older language versions. For example, if you want to use something like ruby2.2 you'll get a notice saying that the package is insecure and it won't allow you to install it. They mention an environment variable you can set to get around it but even that didn't work properly. Is my use-case not relevant to nix? Even the simplest requests are met with unavoidable blockers. Frustrating. Something simple like installing a specific `node` version, corresponding `yarn`, and have it work just as well as `nvm` proved to be a challenge. I managed to get it working relatively well until I ran into weird issues with native bindings on a project that I have literally never seen before. Issues with `dlopen` and the ilk just made me frustrated enough to post this: https://twitter.com/neurosnap/status/1485427740610375680?s=20 https://twitter.com/neurosnap/status/1485427740610375680?s=2... I'm not even talking about the final stage of nix where all my npm packages are shasum'd and checked into nix, I'm simply installing two packages: node and yarn. Something this simple didn't work for every project I had. This is all not to mention that I have to add a `flake.nix` and `flake.lock` to every project or create some nix repo where I put all these files. I love the idea of nix and nixos and really wanted to get it to work. Ultimately it's just not there yet and I'm not sure it ever will be. Right now, the time you save by using nix is completely lost when you traverse down the rabbit hole of outdated documentation and never ending bugs with the actual system.
  • nicoburns 5y ago
    I've recently discovered `asdf` (https://github.com/asdf-vm/asdf https://github.com/asdf-vm/asdf). It's not as technically clever as nix, but it does allow you to manage version of most language toolchains with one tool.
    • jeremyjh 5y ago
      This is a great tool, I've used it for years. Its not really meant for production systems, but to manage multiple versions of Python, Node, Elixir, Erlang, Ruby etc it works great.
• smasher164 5y ago
  For me, Nix is one of those systems where I just had to spend a long time with it to understand it. It wasn't something I could master within a few weeks. After about a year of continued use and struggle, I've finally gotten to the point that I'm comfortable going off the beaten path and even contributing to nixpkgs.
  • bpye 5y ago
    Yeah I agree here, I used to find Nix somewhat unintuitive but I have now managed a few non-trivial projects. One being to package Xilinx ISE as a flake [0], and another to build an immutable Linux image using busybox and runit [1]. For the latter I still haven't quite gotten where I want but that's because I realised I needed dbus for avahi and dbus is just so ridiculously complex. [0] - https://github.com/benpye/nix-fpga-tools/ https://github.com/benpye/nix-fpga-tools/ [1] - https://github.com/benpye/nix-embedded https://github.com/benpye/nix-embedded
• parasense 5y ago
  I used to think the ideas of NixOS were great, but then I learned about `ostree`, and in my opinion things like Project Atomic (in Fedora), are probably more pragmatic or straightforward idiomatic implementation of those ideas. In essence the software packages resemble how git works behind the curtain. Git has a bunch of objects with cryptic names resembling hashsum's, and those are the files in your git working tree, they are sorta symbolically linked into the working-tree of the git repo. In the case of ostree, the working tree is a filesystem path such as the root of your filesystem. You can checkout a branch of the root filesystem on bootup, etc... and it's great for A/B testing because if there are any problems one simply boot into the previously known-good branch, etc. The problem there is people sorta hate having to reboot after modifying the HEAD of the ostree repo, which might conceptually resemble a git commit into the main branch. Flatpak to the rescue, which is itself another implementation of `ostree` but not for entire root fielsystems, but for the package's filesystem layout, what you might think of as the contents of any given nixos package path. The same kind of things happen, bundle libraries can be different in different runtimes, and multiple runtimes can co-exist, and their file objects are deduplicated, and shared or isolated. The configuration language is JSON, so it's easy to manage as a packager.
  • CameronNemo 5y ago
    You can checkout a branch of the root filesystem on bootup, etc... and it's great for A/B testing because if there are any problems one simply boot into the previously known-good branch, etc. You can also do this with NixOS, or even ZFSBootMenu.
  • discardedrefuse 5y ago
    Not just ostree. Using butane / ignition configs to setup coreos is very nice.
    • parasense 5y ago
      Sry for the necropost, but... I just started working on coreos at $dayjob. So your comment struck a nerve, but in a totally good way! :-) I'll checkout butane / ignition ASAP. Thanks!
• nwmcsween 5y ago
  The main problem with NixOS that the author touches on is the isolation as well as the global state NixOS maintains for mappings in the nixstore which makes NixOS root unsharable over NFS. There have been talks on #nixos of creating a LKM, etc to fix the security issues with NixOS but there is a better way to deal with this and just treat the FS as a file system and not an object store like NixOS does, state could be encoded in the file system.
• lallysingh 5y ago
  This post is dead-on. I've been trying nix in different forms for years, and it's been incredibly painful. The way the folks who use it normally talk about it is so different from real-life use by non-experts it feels like gaslighting. I only felt vindicated when reading https://ianthehenry.com/posts/how-to-learn-nix/ https://ianthehenry.com/posts/how-to-learn-nix/ -- it's not me it's them. Maybe one day it'll get good enough to be usable. Right now it's a long, long fight to get productive in any non-trivial (e.g., explicitly supported and documented) configuration.
  • res0nat0r 5y ago
    I've been messing with GUIX, just because the configuration language is much less confusing to learn and understand.
    • stabbles 5y ago
      You might as well try Spack, it's Python + a dsl to customize builds in a single line. Guix package descriptions look very daunting to me. [1] https://github.com/spack/spack/ https://github.com/spack/spack/
• tikhonj 5y ago
  I've been using Nix and NixOS for a while and I've seen four core advantages: 1. Nix store: what the article covers: multiple versions of the same package, "virtualenv for everything"... etc 2. Reproducibility: because package definitions are self-contained, I can pin and reliably reproduce everything for my packages. And I do mean everything. 3. Flexibility: Nix works for system packages on NixOS as well as user packages on any Linux or macOS. I've been sharing like 70% of my system config between Linux and macOS, and I don't know of any other tool that can do that. 4. Programmability: package definitions and config are extensible and composable. Yes, learning an ad hoc language to do this is a pain, but once I learned it I got a higher-level and better-abstracted way to define and combine packages than any other tool I've used. It's like going from C to OCaml. At this point I've started hating Dockerfiles because they can't easily be composed and don't provide any real facilities for abstraction. Ultimately, Nix took system management from feeling like an operational activity—maintaining and changing a bunch of mutable state to run the system—to declarative programming. Learning curve aside, making system management a reproducible programming activity with no system state to worry about has been a massive improvement.
  • dimsuz 5y ago
    Whenever Nix/NixOS gets discussed I always see same points being brought up again and again. And again. I've never seen anything which is discussing solutions or the roadmap (however distant) to solve those issues. Can it be that nothing is happening in this regard or is that really so that people only list same cons over and over again? :)
    • otabdeveloper4 5y ago
      It's like complaining about C++. It will always be there. Ignore it, it's just people venting about the fact that solving hard problems is hard.
  • mikepurvis 5y ago
    "... with no system state to worry about" I don't disagree with you, but one of my skepticisms about this is that Docker and Dockerfiles made the same promise like eight years ago, and at least as a small time operator (eg, homelab), it never really felt like the system was as stateless as it was telling me it was. There were always logs, indexes, caches, database content, and all the rest of it, and all of this had to be carefully volumed-out with those data containers being protected and versioned and carried forward independent of the throwaway Dockerfile-defined "application" containers. So far my experience of NixOS is that it doesn't particularly offer a new solution here, but at least it doesn't pretend anything. The configuration.nix "defines" the whole system, but obviously doesn't touch anything in /home or /var, so that's on you to back up, migrate, whatever.
• superkuh 5y ago
  Using NixOS to avoid the problems of dependency hell is like intentionally getting infected with sars-cov-2 to get immunity. You're intentionally exposing yourself the very thing you're trying to avoid.... to avoid it in the future? Instead of only having to, say, statically compile a single program that doesn't quite work with your system version of glibc or whatever, now you have to do do it for every single program. For popular software this is okay, someone else has probably already done the work. But for the long tail (most software) a pre-existing config won't.
• kerblang 5y ago
  Why do we need a programming language to run software installers? Like, all I really need is the ability to say, "Hey, for this thing, install it in a versioned directory, please, and leave /usr/bin the heck alone." or even "Okay you're stubborn and you won't give up on /usr/bin but at least do the first part for me." For most things (ls, find, etc) this is unnecessary but yeah for the pythons & javas and so forth, it's helpful. Seems like a lot of package managers already do the latter but sysadmins insist on There Shall Be Only One even when /usr/bin is already symbolic links into versioned installs (or links to links to links to versioned installs..). Maybe I'm missing the point entirely.
• zaphar 5y ago
  I actually think as a language Nix's runtime semantics are worse than borgcfg. Both have an obtuse and confusing syntax it's true. But Nix's extreme approach to laziness in the language means it essentially has "come from" semantics which is the source of the spooky action at a distance that the author speaks about. This combined with a lack of compile time type checking means that that debugging your nix code comes pretty close to feeling impossible. It is deterministic but tracking down what exactly broke your nix package code can be difficult when the source could literally be almost anywhere.
• dangus 5y ago
  Something that perhaps detracts from the positives of NixOS is that a lot of the tools that have the biggest issues with the need/difficulty of dealing with multiple versions and environments have long ago come up with their own solutions to the problem. Python has pyenv, NodeJS has nvm, Terraform has tfenv, and the list goes on. Then if you're running on a server/VM/cloud, it seems to me that you should be treating your systems as cattle instead of pets. I never update packages on servers, I build a new image/instance, test it, and replace the server. I wonder if some of the benefits of NixOS were either solutions looking for problems or solutions where better solutions rose to prominence. I haven't even started talking about containerization, either!
  • Filligree 5y ago
    > Then if you're running on a server/VM/cloud, it seems to me that you should be treating your systems as cattle instead of pets. I never update packages on servers, I build a new image/instance, test it, and replace the server. I have six or so servers, all of them configured differently. Not completely differently; they share some configuration. But not very similarly either. They're pets. They have a lot of state. Backups are running, but I certainly don't want to reinstall them. Despite being pets, I still want to do as little work to manage them as I possibly can. NixOS is great in this scenario.
  • jonringer117 5y ago
    > Python has pyenv, NodeJS has nvm, Terraform has tfenv, and the list goes on. Nix makes these all largely irrelevant, in a consistent way. If anything I would say this supports nix's usage. > Then if you're running on a server/VM/cloud, it seems to me that you should be treating your systems as cattle instead of pets. I never update packages on servers, I build a new image/instance, test it, and replace the server. You can do this is nix as well. You can take a configuration.nix and ship it as a version controlled file, an iso image, pxe boot image, ami, vhd, or other formats. > I wonder if some of the benefits of NixOS were either solutions looking for problems or solutions where better solutions rose to prominence. I don't think so: https://blog.flyingcircus.io/2016/05/06/thoughts-on-systems-management-methods/ https://blog.flyingcircus.io/2016/05/06/thoughts-on-systems-... > I haven't even started talking about containerization, either! Containers generally take an impure process and create a "snapshot-in-time". Nix allows you to "hydrate" your configuration in a reproducible and repeatable fashion. OCI images can only really be layered, can't be composed, and commands like `sudo apt-get install` or `pip install` also makes the runtime behavior dependent on when the image was created.
• taeric 5y ago
  I feel the conflict between the good and bad here is interesting. First, it has to be acknowledged that the reason everything can be installed to separate directories is a modern luxury. Hard drive space used to be much more constrained. Second, everything being installed to a unique location is why everything has to be rebuilt. And gets into the fun that you can't update just part. The problem, then, is we never converged to foundational level software. That is, if we agreed that bash was a foundation of the system, there would just be the one. And you wouldn't get an odd web of versions of it linked everywhere. All code would just use bash. I'm assuming there has to be some level of this in the package management. That some software is foundational to the system, while some is convenience shared code for applications?
  • AceJohnny2 5y ago
    > The problem, then, is we never converged to foundational level software. That is, if we agreed that bash was a foundation of the system, there would just be the one. And you wouldn't get an odd web of versions of it linked everywhere. All code would just use bash. I can't imagine how this would be possible, in practice. Software has fractal complexity, there are always things that need to be tweaked, unexpected interactions that need to be decided one way or the other (and changed back). I remember when Android decided to ship sqlite as part of the base OS, and everyone celebrated this robust, stable inclusion. And yet, sqlite continued to evolve, such that many Android apps nowadays just bundle their own version rather than use the OS's outdated version. Perhaps we're still in the early days of computing, and only just now starting to see a flattening of the S-curve of change (more likely, I've gotten older and "everything old is new again"), and now some kinds of "foundational" software can stabilize. But I note that there hasn't been a modern replacement of POSIX, and what POSIX defines is considered hopelessly outdated and limited.
    • taeric 5y ago
      This can really only work if we accept that some things will not change. Only software I know that did this is TeX. And it was deliberate there. He acknowledged that done things could be improved. Or just done differently. But, he made the choice that it is a foundation for a lot of other code, so bug fixes only. Edit: I should say explicitly that I agree with you. And I am interested in how this can be solved otherwise.
• aidenn0 5y ago
  I've been using NixOS for years and this article made me reflect on the nix language a bit. The nix language is weird looking, particularly if you don't have haskell/ml experience. It also has some unusual semantics that make for punctuation being necessary in places it otherwise might not. However, I think what trips people up is how foreign the semantics for the nixpkgs standard are. If you are spending all of your time confused and there's this thing that looks weird and confusing, which one are you going to blame? I will say that a dynamically typed lazy language is its own special hell for debugging though. The only sane way to find an error is to: 1. Start with something that is error-free 2. Make a single small change and see if it is still error free 3. repeat until you get an error; that last change is where the error was. Unless of course you just caused something else to be evaluated that wasn't before. Then that something else is where the error is.
• ilikejam 5y ago
  > The worst is, of course, GCL/borgcfg There should be a compendium of non-deliberately-hideous languages. I'll start. https://bigfix.me/search?page=18&searchString=relevance%20examples https://bigfix.me/search?page=18&searchString=relevance%20ex...
• anderskaseorg 5y ago
  > It also means that it's impossible to statically know what other packages a given package might depend on. Currently, the way this is implemented is essentially grepping a package for /nix/store/ to try to figure out what the dependencies are, which is obviously... not great. That’s not quite how it works. One of the features of the Nix language is that the interpreter associates an invisible “context” with each string to carry dependency information. When you coerce a derivation to a string (in order to use its path in another derivation), the context remembers the build dependency on that derivation. Any derivation built using that string will inherit build dependencies from its context. https://nixos.org/manual/nixpkgs/stable/#function-library-lib.strings.addContextFrom https://nixos.org/manual/nixpkgs/stable/#function-library-li... https://shealevy.com/blog/2018/08/05/understanding-nixs-string-context/ https://shealevy.com/blog/2018/08/05/understanding-nixs-stri... It is true that runtime dependencies are computed by string-searching the build output, but only for paths that have already been determined to be part of the build dependency closure. https://nixos.org/guides/nix-pills/automatic-runtime-dependencies.html https://nixos.org/guides/nix-pills/automatic-runtime-depende... Since store paths have a fixed format with a cryptographic hash, this works plenty well enough in practice—as evidenced by the fact that Nixpkgs exists and has more packages than any other Linux distribution. https://repology.org/repositories/statistics/total https://repology.org/repositories/statistics/total
• outworlder 5y ago
  The Nix package manager is amazing. I'm currently using it on my work OSX machine (instead of homebrew). It works well (with home-manager). The author is spot on about the language though. I don't understand why people have to keep reinventing the wheel and designing bad languages when good options exist. At least they didn't use YAML...
• hypersoar 5y ago
  I've been using Nix for about a year. I don't use NixOS but home-manager and nix-darwin. Just about every single time I've tried to do something new, it has ended up being way more complicated than I thought at first. - Installing emacs? You'll want to use the binary cache. No biggie. Except when it doesn't work, and your system update ends up building it from scratch--a two-hour process on my stalwart old desktop. - Setting up a local environment for a Go project? No problem. Er, except some tools need to be installed globally, quite against the Nix philosophy. - For a system or home configuration, you'll encounter packages, modules, and flakes. Packages are explained in the Nix documentation. The functions people actually use to make packages are explained in the Nixpkgs documentation. Modules are explained in the NixOS documentation. And flakes are explained in...uh...well, you'll figure it out. (You don't need flakes at this point, but they're on their way. And they won't replace packages entirely.) - Debugging? gl,hf - And this is all before we get into my admittedly complex system configuration using flakes, nix-darwin, and home-manager. Some things need to be set up at the system level, others at the home level. And cross-referencing the two is a pain. I just got an M1 mac. Some packages need to have their x86 versions installed, against Nix's protestations. I appreciate the guy who made a configuration framework that figured out how to do this, because I certainly couldn't. Anyway, I love it. I think it's the mathematician in me. The whole idea is too aesthetically pleasing for me to resist. The hope of having everything placed just so by a mere wave of my hand, too tempting. Damn the consequences.
  • dqv 5y ago
    >Installing emacs? You'll want to use the binary cache. No biggie. Except when it doesn't work, and your system update ends up building it from scratch--a two-hour process on my stalwart old desktop. Just don’t use emacs ;) In all seriousness, were you pulling from unstable? Disallowing installation because the hydra build is failing has gotten me, albeit for an obscure package I never use. >And flakes are explained in...uh...well, you'll figure it out. This is a funny quirk in the community I’ve seen, where everyone talks about using flakes but has a very difficult time of saying how. I finally figured out the weird incantation to get flakes to work. It was not trivial. (And the reason I’m not saying it here is because I simply don’t remember.)
• StreamBright 5y ago
  > The first is relatively simple: they developed their own programming language to do configuration Exactly this. I do not understand why did they do that.
  • jonringer117 5y ago
    Because it's a domain-specific-language, optimized for packaging software. The relevant passage: > Its only purpose is to describe components and compositions. A component is created through the derivation primitive operation, which accepts all information necessary to build the component. This includes its dependencies, which are other derivations or sources. Full phd thesis: https://edolstra.github.io/pubs/phd-thesis.pdf https://edolstra.github.io/pubs/phd-thesis.pdf
    • StreamBright 5y ago
      I understand that but I do not think that packaging is such a difficult subject that justifies a DSL as a new language.
• Ericson2314 5y ago
  I understand the first complaint but not the second > The second flaw is that NixOS does not actually provide real isolation. I thought this would going to be about security, but then it was about having to repackage the world. But Nixpkgs is current the biggest and most up to date package repository in the world (we finally beat AUR). Packaging enough stuff is emphatically not the problem. What I want to see is development be easier with Nix, because winning over the hearts and minds of upstream developers is the final frontier. To that end I wrote https://github.com/NixOS/rfcs/pull/92 https://github.com/NixOS/rfcs/pull/92 and https://github.com/NixOS/rfcs/pull/109 https://github.com/NixOS/rfcs/pull/109. As a side benefit, autogenerating more Nix means less handwritten Nix! I do think people give the language itself to much grief when the problem is more the library side with the copious override shenanagins and other stuff.
  • tikhonj 5y ago
    > I do think people give the language itself to much grief when the problem is more the library side with the copious override shenanagins and other stuff. I sympathize with this, honestly—the separation between Nix the language and Nixpkgs the library/codebase is just an implementation detail from the point of view of the user. This is especially true for core constructs like overrides—overriding is a pretty fundamental abstraction that would be part of a differently designed language, so the fact that it's more like a Nixpkgs convention is not going to be clear (or particularly useful) to somebody learning Nix.
    • Ericson2314 5y ago
      I think you have the mindset right, so thanks for elucidating that. I would still push back. Ultimately library + language is serving a single goal here, but "means to an end" != mere implementation detail! As a user of a language, it's incumbent upon you to learn the difference between library vs langauge in what you write. Full stop. I do wish Nixpkgs would be less rediculous. I wish there was a GUI too! But people who are going to write some code still need to learn the difference between language and library way. Ultimately I don't think a more mainstream language would even help with the override soup problem, and we will need a logic programming type thing, but that's a separate point.
• silasdavis 5y ago
  I've been running NixOS for 2 months having had my eye on it for a while. So far I feel like I'm making progress. Having started from the masochism of Gentoo followed by the relatively lesser masochism of Arch my feeling is at least these hours of configurating are not being poured into the void but will have a substantially longer payback period. Reinstalling Arch or Gentoo always inevitably involved a large amount of remembering long forgotten config incantations which despite a certain number of git configuration repos for system and home and some scripted installation tended not to avoid a significant amount of tedious unfulfilling grunt work at the bootstrapping console. Mind you I'm interested in views from those who are further along and feeling the pain. I can well believe that that getting to the first '80% how I want things' configuration might be much easier than the next 10% on the same path. I'm using unstable, flakes, and home manager as a module in the main configuration.nix. The language doesn't feel particularly arcane or difficult though so I don't relate to that complaint yet. As others have mentioned. A few fairly standard functional features (recursion, destructuring, first class functions) plus JSON sounds about right.
  • pimeys 5y ago
    It's a pretty good ride still (depending what you need). I tend to run a tiling wm with lots of customization and it's great to just have all these tools and behavior synced everywhere. I build emacs from scratch with lots of packages and special config. I have neovim with all the goodies, firefox installing with the plugins and config I want. All automatically synced between my machines. I also really pushed myself to learn to maintain nixpkgs. It's been tough, but definitely worth it. Config, if you want to take a look: https://github.com/pimeys/nixos https://github.com/pimeys/nixos
    • silasdavis 5y ago
      Thanks for the config it looks interesting and quite mature, the possibility of sharing such kind of has me on board. Incidentally I was coming from i3 (xmonad before but wanted something I could switch over to wayland where I could watch video like its 1995). Never in love with configuring all my own task bar, power management, disk mounting, screenshot program, rubbish task launcher with no icons, etc. but did it anyway for the sake of beautiful ceramic tiles... I've been playing with pop shell gnome extension for creature comforts, which via dconf plugin of home manager actually seems text configurable. Not that I've done it yet. See you are using sway, ever considered going IKEA with gnome?
• Karupan 5y ago
  I gave nix (the package manager) a shot about a month back and gave up quickly. The lack of documentation is real for anyone getting started. And it got even more confusing as you’d typically need more tooling and hacks for particular dev environments (Node.js is what I tried). As much as I dislike docker for dev environments, it is easy and consistent to setup and works for all the languages I’ve had to deal with.
• jfhufl 5y ago
  Would Nix benefit from something like the old CMU depot program? http://www.cs.cmu.edu/afs/.cs.cmu.edu/help/content/unix_linux/software_collections/local_depot.html http://www.cs.cmu.edu/afs/.cs.cmu.edu/help/content/unix_linu... Consolidating everything you want into /usr/local (exclude packages you don't want). I used to use this at my old job before package managers were ubiquitous.
• haolez 5y ago
  Is NixOps still a thing? It might be cool unifying nixpkgs with cloud infra, although Terraform and friends seem to already provide 80% of the value of such a solution.
  • jonringer117 5y ago
    terraform is more about reconciliation of a configuration, and moving a state closer to a desired end state. NixOS is congruent configuration management. There's a 1 to 1 correlation of configuration to reality, with no configuration drift.
    • haolez 5y ago
      I meant NixOps, not NixOS :)
• bob406 5y ago
  Absolutely agree that "isolated installations" are the future. Plan9 was way ahead of their time when they used their version of chroot and mounting to achieve basically something like that. And now the Fuchsia team is making this a pillar of their architecture even going so far that all installs are transparent: almost like running an app directly from an URL. And sandboxing it like a webpage, even when it's a native app. Ooops, I digress. But I really see this as a trend and NixOs one of the systems which are used to collect experience on the concept of isolation and refine it.
• xelxebar 5y ago
  Author might like to try Guix! It shares all the advantages listed and fixes the main complaint via using Scheme Everywhere. That said, the EDSLs for package and operating-system declarations are pretty darn nice. You don't really need to know lisp at all to be effective. Plus, the extensive documentation of both Guix and Guile Scheme are all available right there at the command line via the info docs. Even more, Guix already has tooling to spin up containers and VMs with profile content exposed on FHS paths! That addresses the /lib/ld-linux.so.2 and #!/bin/bash issues for using foreign binaries. About the only advatage of Nix over Guix I am aware of is that nixpkgs has more packages than Guix. Curious if there are others?
• cherryblossom00 5y ago
  I don't understand what's wrong with the Nix language. Sure, the space-delimited lists can get a little annoying, but other than that it's minimalistic enough to use a configuration language but complex enough to do more complicated things like overriding derivations. Maybe it's because I learnt Haskell before Nix so the syntax is very familiar to me, whereas I see how it could be a learning curve for other users. What I find the most annoying is the lack of documentation of some of the nixpkgs functions. Some of the functions provided by import <nixpkgs> {}.lib appear to be the same as the ones builtin to the Nix language and there doesn't seem to be any clear guidance on when to use which version. I've also had to look at the source code to find out the difference between writeTextFile, writeText, writeTextDir, writeScript, and writeScriptBin. [The docs][1] explain writeTextFile, but the only documentation for the rest is ‘Many more commands wrap writeTextFile including writeText, writeTextDir, writeScript, and writeScriptBin. These are convenience functions over writeTextFile.’. Additionally, it's a bit frustrating for me how all the documentation for nixpkgs — the lib functions, how to make a derivation, specific details for building packages in certain languages, how to contribute to nixpkgs, overriding packages/overlays etc — are in [one gigantic web page][2] that's quite slow to load and even slower to search for things in. [1]: https://nixos.org/manual/nixpkgs/stable/#trivial-builder-writeText https://nixos.org/manual/nixpkgs/stable/#trivial-builder-wri... [2]: https://nixos.org/manual/nixpkgs/stable/ https://nixos.org/manual/nixpkgs/stable/ (copied from my Lobsters comment https://lobste.rs/s/psfsfo/curse_nixos#c_y83hvy https://lobste.rs/s/psfsfo/curse_nixos#c_y83hvy)
• stelcodes 5y ago
  I used Nix and NixOS for more than a year as my daily driver. I've contributed to Nixpkgs. I agree with the author on most if not all of their points. Here's some advice: If you're interested in Nix, take steps not leaps. Use the Nix package manager. It's a great addition to distros like Debian. Then maybe use Home Manager (even though I think Home Manager is way over-hyped, see below). Then write a bunch of derivations. Then go learn the ins and outs of systemd. THEN go play with NixOS. If you skip any steps before the NixOS part, you will get lost in the weeds. The happy path of NixOS is very happy. The other paths are very challenging. You should really know a lot about both Nix and more traditional Linux packaging methods before you go all in on NixOS. And honestly, learning more traditional Linux utilities is a far better use of your time than learning the complex, ever-changing Nix landscape. It's a super cool project, I'm so glad it exists. But it should really be viewed as a _research_ project. Many good things will come out of it. Hopefully one of those things (like the author mentions) is a Nix clone written in a common language with a much better UX. Until then, try to avoid the urge to play with shiny things and stick to just using the Nix package manager and more traditional tooling. And about Home Manager, the reason why I think it's over-hyped is because it provides a declarative approach to something that was... already declarative. Your $XDG_CONFIG directory does not need a leaky Nix abstraction on top of it. It actually just makes everything 10x harder. The Home Manager Nix abstractions are terrible but people seem to love it? Why would I write my i3 config in Nix?? An i3 config literally cannot get any simpler. Why make it more complicated for no benefit? I also don't need a declarative list of all installed packages. I'd rather just use `nix-env` personally.
  • jonringer117 5y ago
    > And about Home Manager, the reason why I think it's over-hyped is because it provides a declarative approach to something that was... already declarative. Your $XDG_CONFIG directory does not need a leaky Nix abstraction on top of it I don't really agree, I spent about 30mins to get my home-manager config to support an m1 mac [0]. I don't really want to think how long it would take me to look up all of the homebrew package names, and learn a new package manager. Instead, I just pushed all of the linux-specific items into their own bin, a little more logic, and I was able to get back to a comfortable terminal + git + vim settings. Also, nix exposes congruent configuration management[1]. The state of my system is an exact reflection of the configuration. With other tools like ansible, vagrant, etc, I would get reconciliation configuration which is close on initial install but configuration drift is an ever-present concern; not to mention that large recipes and playbooks can take a very long time to run. Going the homebrew route would be divergent configuration, it would be very hard for me to get back to a certain configuration. With nix (and by extension home-manager), I can version control the configuration, improve it, roll it back, w/e I want. > Why would I write my i3 config in Nix?? You do get some type checking, although the iteration time would probably be similar. You could also just do `xsession.windowManager.i3.extraConfig = builtins.readFile ./i3.config;` if you really just wanted to wholesale read in your existing profile. > I'd rather just use `nix-env` personally. nix-env is a double edge sword. You can rollback (somewhat, I believe it's just a stack of all changes), which is an improvement. However, nix only retains the "derivation name" to try and management. But for packages like python38, if you try to upgrade it, it will determine that `python-3.11-a3` is the package which is the most up-to-date. I try to discourage using nix-env. [0]: https://github.com/jonringer/nixpkgs-config/commit/37ddfefa1773f2c24e1e60bc86a21498c084f8fc https://github.com/jonringer/nixpkgs-config/commit/37ddfefa1... [1]: https://blog.flyingcircus.io/2016/05/06/thoughts-on-systems-management-methods/ https://blog.flyingcircus.io/2016/05/06/thoughts-on-systems-...
• amai 5y ago
  Reading about NixOS reminded me of the assign command in Amiga OS: https://github.com/TheBeef/AmigaAssign https://github.com/TheBeef/AmigaAssign
• throwaway22032 5y ago
  The main issue with NixOS is not NixOS itself but software which sometimes has an insanely complicated build process. An example that's hitting me at the moment is Anki. The build process was changed by the developers a while ago and became some sort of Bazel mess. There's a GH issue that was opened and closed by the developer because, well, it works for them. https://github.com/ankitects/anki/issues/1378 https://github.com/ankitects/anki/issues/1378 Since then Anki has been broken on Nix and the only way to get it working is to either run the binary in a bubblewrap container (which has issues like breaking IME support) or just use a VM. Could I fix this? Probably, yeah, if I spent enough time, but really the way to fix it would be to do it upstream, and getting a project to change their build process (particularly once they've recently changed it) is basically a full time job. It's a bit similar to working with reproducible builds. The ecosystem is there, but you very often run into an upstream that just thinks "yo mate, it's not military software, why do I care". And really, they're probably not wrong, this is OSS, no-one is paying you.