[HN Gopher] 20 years of Nix
___________________________________________________________________
20 years of Nix
Author : domenkozar
Score : 179 points
Date : 2023-03-18 12:09 UTC (10 hours ago)
(HTM) web link (20th.nixos.org)
(TXT) w3m dump (20th.nixos.org)
| haolez wrote:
| What happened to NixOps? It sounded like a great idea when I
| first read about it.
| bpye wrote:
| As far as I know, it's still about [0]. I've had a better
| experience with deploy-rs though [1] - or even just using
| nixos-rebuild to target the remote machine.
|
| [0] - https://github.com/NixOS/nixops
|
| [1] - https://github.com/serokell/deploy-rs
| amardeep wrote:
| I have been exploring nix for the past few months and my
| experience with nix has been both exhilarating and frustrating,
| simultaneously. On one hand, I find it hard to imagine not using
| nix now, but on the other hand, I hesitate to recommend it to
| other colleagues due to its steep learning curve, ux issues and
| potential for footguns.
|
| I sincerely hope that nix community improves the UX to make it
| more accessible to new users. Though for those willing to invest
| time in learning it, nix is extremely useful and highly
| recommended.
| tomberek wrote:
| There are two sides to this problem, the first is to improve
| the UX, but the second is to clearly describe a compelling
| reason for people to adopt. It is very tempting to only blame
| the first, but I think we need to also need to tell a better
| story and highlight the values in a better way. This would then
| give people a reason to get past the UX issues in the hopes of
| achieving those desired values.
|
| For example; people seem to have accepted that the benefits of
| using terraform in spite of various difficulties - the learning
| of its language or needing to hire specialists. The mantra of
| "infrastructure as code" is enough to drive adoption. What is
| our mantra? We need to accept that "reproducibility" isn't
| quite working and that we need either a clearer message, or to
| explain the message.
| grumbel wrote:
| > but the second is to clearly describe a compelling reason
| for people to adopt.
|
| Build source straight from Git: nix run
| github:someuser/someproject
|
| Need a different version? nix run
| github:someuser/someproject?ref=v1.0.0
|
| Wanna replace some dependency? nix run \
| --override-input somelib github:someotheruser/somelib \
| github:someuser/someproject
|
| Wanna fork: git clone
| https://github.com/someuser/someproject # do your
| changes nix run someproject/
|
| And the best part is, it's conceptually very simple, it's
| mostly just a bunch of symlinks and environment variables
| behind the scenes. If you wanna inspect what's in a package,
| just `cd /nix/store/yourpackage-HASH` and look around.
|
| NixOS just feels like a distribution build from the ground up
| for Free Software. The "reproducibility" in every day use
| just means that stuff won't randomly break for no reason. And
| if you don't wanna go the full NixOS route, you can just
| install the Nix package manager itself on any other
| distribution.
|
| That said, the part where Nix gets painful is when it has to
| interact with the rest of the software world. Things like
| software that wants to auto-update itself really does not fit
| into the Nix ecosystem at all and can be rather annoying to
| get to work.
|
| There are of course numerous other pain points, missing
| features and all that. But being able to flip between
| versions, fork, compile and all that with feels just so much
| better than anything else.
| carapace wrote:
| I disagree, I think the value proposition for reproducibility
| is clear, it's just that the learning curve "is too damn
| high!" I'm highly motivated to learn and use Nix (or Guix for
| that matter) but I've bounced off of it three or four times
| now, and I'm the kind of weirdo who learns new PLs for fun.
|
| Someone once said that you don't learn Nix, you reverse
| engineer it.
| IshKebab wrote:
| I agree with you. I can see the value of reproducibility,
| declarative system setup, etc.
|
| I would love that. But there's no way I'm fighting software
| with such a bad UX.
| rgoulter wrote:
| > We need to accept that "reproducibility" isn't quite
| working...
|
| I guess it doesn't sell Nix as strongly as it could..
|
| But, it's hardly for a lack of enthusiasm on Nix user's part.
| -- Rather, I've seen a few "what's nix good for anyway"
| comments, and this results in many lengthy replies extolling
| nix.
| soraminazuki wrote:
| Agreed, reproducibility is only one aspect of Nix and doesn't
| quite capture the whole picture. That's why so many newcomers
| see Nix as nothing more than a Docker replacement. There's
| also too much misconceptions about Nix the language that's
| scaring people off.
|
| I'd like to see more being discussed about:
|
| * Its unique ability to treat packages as programmable data
| (i.e., derivations)
|
| * Its use case as a building block for deployment systems
| that knows about and integrates with packages
|
| * Its JSON-like simplicity
|
| They're all central to the Nix experience, and yet it's often
| overlooked in Nix discussions.
| Zurrrrr wrote:
| > Its unique ability to treat packages as programmable data
| (i.e., derivations)
|
| How is this useful in practice?
| VTimofeenko wrote:
| It's super easy to extend packages. For example, I was
| playing with Kafka and wanted the standard package to
| coexist with a separate install of Kafka with some jar
| files I needed. It was super easy to create a new package
| of Kafka with extra install steps that downloaded and
| placed those jar files where I needed.
| orbisvicis wrote:
| I'm surprised that nix never ended up using augeas for
| package configuration because last I checked every
| upstream build option has to be reproduced in nix script
| by the packager.
| troutwine wrote:
| Two of the major differences between terraform and Nix that I
| see are 1. it's possible to muddle through in terraform and
| 2. Hashicorp has put a non-trivial amount of effort into
| documentation for all levels of users. I've taken a stab at
| using Nix for Rust projects and could not even get to a point
| where I had something that functioned. I found plenty of
| material online but was it out of date, idiosyncratic, did it
| use flakes or not, etc etc? I suppose I could have contorted
| my existing project to meet the examples I found in various
| GitHub repos but my stuff is bog standard Rust so I don't
| know that I'd be willing to. As for documentation, what
| should I, as a new and invested user, be looking for? Are
| flakes the future? Are they a distraction? Why are all the
| suggested docs I could find several year old guides on blogs?
| There's 20 years of information floating around and the
| official project documentation, well, I don't know who the
| audience is but it's not learners.
|
| It's a shame. The promise of Nix/NixOS is really interesting
| -- being able to deterministically create VMs with a custom
| user land is desirable to me -- but in practice I can't even
| get a simplistic project to compile, let alone something
| elaborate. Terraform is jank but it's not a whole language
| that needs to be learned, seemingly, before the official docs
| start to become coherent in their underlying context.
| drakerossman wrote:
| What I see as a barrier for entry to Nix/NixOS is not the UX,
| but the available documentation, or lack of thereof. One may
| consider the docs being part of UX though. I am in the process
| of writing a book about NixOS, you may track the progress here:
| https://drakerossman.com/blog/practical-nixos-the-book
|
| The emphasis is on how to make it as practical as possible,
| plus cover the topics which may apply to Linux in general, and
| in great detail.
| tacon wrote:
| Your email form to follow the book is returning errors to me.
| And you have no other contact channels I can find. Might want
| to look into that.
| drakerossman wrote:
| Thank you for pointing that out! I have a twitter with the
| same handle, if you would like to subscribe to that. If not
| - wouldn't you mind a follow-up email when I fix the
| subscription form?
| pveierland wrote:
| Currently working on a graphical UX where you can create and
| share flakes without writing Nix code at https://mynixos.com
|
| The site makes it easy to browse indexed flakes and configure
| flakes via options and packages. Hopefully the structure
| provided by the UI can makes it easier to get started with Nix
| flakes :)
| domenkozar wrote:
| Hey! We've been working at Cachix to address this using
| https://devenv.sh/.
|
| It's primary targeted to improve DX and on-board users quickly.
| tripdout wrote:
| This looks like a really nice UX improvement on top of
| typical Flake devshells.
| amardeep wrote:
| Thanks Domen,
|
| devenv.sh is quite nice, and have already started using it.
| domenkozar wrote:
| Do you still experience these UX issues and lack of
| documentation?
| pbronez wrote:
| DevEnv looks neat, maybe I'll try it.
|
| I expect my main hurdle will be stuff that isn't in NicPkgs.
| Especially for dev stuff, I'm going to want to pull in low-
| profile GitHub stuff or Python packages. What's the escape
| hatch to bring those into the dev environment?
| chriswarbo wrote:
| > What's the escape hatch to bring those into the dev
| environment?
|
| The function `pkgs.runCommand` is useful if you just want
| to run some Bash commands
| https://nixos.org/manual/nixpkgs/stable/#trivial-builder-
| run...
|
| The main difference compared to running commands in a
| normal terminal is that builds are sandboxed, with no
| network access by default:
|
| - If your commands need to download some particular files,
| you can have Nix fetch them separately (e.g. using
| `fetchurl`, `fetchGit`, etc.) and provide them to your
| commands via env vars. See
| https://nixos.org/manual/nixpkgs/stable/#chap-pkgs-fetchers
|
| - If you don't know what will be downloaded, or there's no
| way to run in an 'offline' mode, then you can specify hash
| for the result (making it a "fixed output derivation").
| That will give it network access, and Nix will check that
| the output matches the given hash for reproducibility (you
| can just make up a random hash to start with; Nix will
| reject the result, telling you its hash, which you can
| copy/paste into the definition :) )
|
| The reasons I like this approach include:
|
| - Bash is familiar/traditional and mostly-compatible with
| e.g. official install instructions provided by many
| projects, Stack Overflow answers, blog posts and tutorials,
| etc.
|
| - Powerful/unrestricted, in case we need to do some
| fiddling between some steps
|
| - Nix often reveals problems with those
| familiar/traditional instructions; e.g. if some deeply-
| nested part of an installer happens to run Python, it will
| fail if Python wasn't explicitly listed in its dependencies
| (AKA `buildInputs`). Revealing and fixing such things up-
| front avoids the "works on my machine" problem.
|
| - Bash commands are often tedious and inflexible; so after
| writing a few of these we may find ourselves wanting more
| structure, more reusable parts, etc. which is exactly what
| the helper functions in Nixpkgs provide (like
| `pkgs.stdenv.mkDerivation`,
| `pkgs.pythonPackages.buildPythonApplication`, etc.). In
| contrastt, starting off with those helper functions can
| seem overwhelming, and the benefits may be hard to
| appreciate immediately.
| amardeep wrote:
| For python, you could just install bare python with venv
| and/or poetry and manage your dev python dependencies
| outside nix. For eg. if you were using devenv.sh, there is
| an example here: https://github.com/cachix/devenv/tree/main
| /examples/python-p...
| rgoulter wrote:
| > What's the escape hatch to bring those into the dev
| environment?
|
| One thing you can do is try the Nix package manager on your
| Linux or macOS system. -- If it's not in nix, you can just
| do it the way you did things before.
|
| If you want to try NixOS:
|
| 1. Writing a package is only necessary for sharing code..
| you can still just have Python, setup a virtual env, & run
| the program as you would.
|
| 2. You could use a tool like Podman or Docker, to run stuff
| in containers. I've heard stuff like
| https://github.com/containers/toolbox helps this.
|
| (Among other solutions).
| theptip wrote:
| I think this project is really promising.
|
| My main concern is that it puts another layer of abstraction
| atop an already complex (and at times leaky) abstraction.
|
| I'd love to see more clear docs about what devenv is actually
| doing under the covers, and how to escape-hatch into Nix land
| when I inevitably need to tweak something.
|
| Also, similarly, how do I map Nix docs (often just a set of
| example expressions) into equivalent devenv incantations?
|
| (It's been a few months since I last looked so maybe things
| have come along since then.)
| __MatrixMan__ wrote:
| I think that's a valid concern. You read the nix pills and
| think you know what you're doing and then it turns out that
| the community has wrapped the things you've learned about
| in things you've never heard of, so you still can't learn
| from other people's repos.
| sbt567 wrote:
| This. I've been actively trying nix-based tooling on and
| off for my projects because it is legitimately solve the
| problem around sandboxing, versioning, reproducibility,
| consistency, etc. Recently, I'm trying to use asdf (and
| its faster alternative, rtx) and I keep telling myself
| "huh, nix could solve this problem better". But, damn it
| is infuriating to learn. Like other commenter said, it is
| the escape hatch that I'm missing so much. I really
| really want to convince myself to learn nix The Right
| Way. But, it feels like you will have another learning
| curve when using a nix-wrapper tooling.
|
| I still have a high hope for the future of nix. And I
| believe the time nix will rise in popularity is when they
| have sorted the UX-related issues.
| __MatrixMan__ wrote:
| One thing that has helped somewhat is being more thorough
| in my exploration of repo's that are doing things that
| are similar to what I'm trying to do.
|
| I want to use nix with a nim project, so I wrote a script
| that walks through all of the repo's in nimble (nim's
| package manager) and then filtered those for ones that
| had a flake.nix in the repo root.
|
| Going through them was a helpful dose of context. It's
| like you gotta approach it from theory to practice and
| from practice to theory and eventually your efforts will
| meet in the middle. I think. I have glimmers of meeting
| in the middle happening.
| lostmsu wrote:
| What are the footguns? I feel that footgun descriptions always
| have the most insightful bits about technology.
| chriswarbo wrote:
| A few antipatterns/annoyances I've come across over the
| years:
|
| Importing paths based on environment variables:
|
| There is built-in support for this, e.g. setting the env var
| `NIX_PATH` to `a=/foo:b=/bar`, then the Nix expressions `<a>`
| and `<b>` will evaluate to the paths `/foo` and `/bar`,
| respectively. By default, the Nix installer sets `NIX_PATH`
| to contain a copy of the Nixpkgs repo, so expressions can do
| `import <nixpkgs>` to access definitions from Nixpkgs.
|
| The reason this is bad is that env vars vary between
| machines, and over time, so we don't actually know what will
| be imported.
|
| These days I completely avoid this by explicitly un-setting
| the `NIX_PATH` env var. I only reference relative paths
| within a project, or else reference other projects via
| explicit git revisions (e.g. I import Nixpkgs by pointing the
| `fetchTarball` function at a github archive URL)
|
| Channels:
|
| These always confused me. They're used to update the copy of
| Nixpkgs that the default `NIX_PATH` points to, and can also
| be used to manage other "updatable" things. It's all very
| imperative, so I don't bother (I just alter the specific git
| revision I'm fetching, e.g.
| https://hackage.haskell.org/package/update-nix-fetchgit helps
| to automate such updating).
|
| Nixpkgs depends on $HOME:
|
| The top-level API exposed by the Nixpkgs repository is a
| function, which can be called with various arguments to
| set/override things; e.g. when I'm on macOS, it will default
| to providing macOS packages; I can override that by calling
| it with `system = "x86_64-linux"`. All well and good.
|
| The problem is that some of its default values will check for
| files like ~/.nixpkgs/config.nix,
| ~/.config/nixpkgs/overlays.nix, etc. This causes the same
| sort of "works on my machine" headaches that Nix was meant to
| solve. See
| https://github.com/NixOS/nixpkgs/blob/master/pkgs/top-
| level/...
|
| I avoid this by importing Nixpkgs via a wrapper, which
| defaults to calling Nixpkgs with empty values to avoid its
| impure defaults; but still allows me to pass along my own
| explicit overrides if needed.
|
| The imperative nix-env command:
|
| Nix provides a command called 'nix-env' which manages a
| symlink called ~/.nix/profile. We can run commands to
| "install packages", "update packages", "remove packages",
| etc. which work by building different "profiles" (Nix store
| paths containing symlinks to a bunch of other Nix store
| paths).
|
| This is bad, since it's imperative and hard to reproduce
| (e.g. depending on what channels were pointing to when those
| commands were run, etc.). A much better approach is to write
| down such a "profile" explicitly, in a git-controlled text
| file, e.g. using the `pkgs.buildEnv` function; then use nix-
| env to just manage that single 'meta-package'.
|
| Tools which treat Nix like Apt/Yum/etc.
|
| This isn't something I haven't personally done, but I've seen
| it happen in a few tools that try to integrate with Nix, and
| it just cripples their usefulness.
|
| Package managers like Apt have a global database, which maps
| manually-written "names" to a bunch of metadata (versions,
| installed or not, names of dependencies, names of conflicting
| packages, etc.). In that world names are unique and global:
| if two packages have the name "foo", they are the same
| package; clashes must be resolved by inventing new names.
| Such names are also fetchable/realisable: we just plug the
| name and "version number" (another manually-written name)
| into a certain pattern, and do a HTTP GET on one of our
| mirrors.
|
| In Nix, all the above features apply to "store paths", which
| are _not_ manually written: they contain hashes, like
| /nix/store/wbkgl57gvwm1qbfjx0ah6kgs4fzz571x-python3-3.9.6,
| which can be verified against their contents and/or build
| script (AKA 'derivation'). Store paths are not designed to be
| managed manually. Instead, the Nix language gives us a rich,
| composable way to describe the desired file/directory; and
| those descriptions are evaluated to find their associated
| store paths.
|
| Nixpkgs provides an attribute set (AKA JSON object)
| containing tens of thousands of derivations; and _often_ the
| thing we want can be described as 'the "foo" attribute of
| Nixpkgs', e.g. '(import <nixpkgs> {}).foo'
|
| Some tooling that builds-on/interacts-with Nix has
| unfortunately limited itself to _only_ such descriptions;
| e.g. accepting a list of strings, and looking each one up in
| the system 's default Nixpkgs attribute set (this
| misunderstanding may come from using the 'nix-env' tool, like
| 'nix-env -iA firefox'; but nix-env _also_ allows arbitrary
| Nix expressions too!). That 's incredibly limiting, since (a)
| it doesn't let us dig into the structure _inside_ those
| attributes (e.g. 'nixpkgs.python3Packages.pylint'); (b) it
| doesn't let us use the override functions that Nixpkgs
| provides (e.g. 'nixpkgs.maven.override { jre =
| nixpkgs.jdk11_headless; }'); (c) it doesn't let us specify
| anything outside of the 'import <nixpkgs> {}' set (e.g. in my
| case, I want to avoid NIX_PATH and <nixpkgs> altogether!)
|
| Referencing non-store paths:
|
| The Nix language treats paths and strings in different ways:
| strings are always passed around verbatim, but certain
| operations will replace paths by a 'snapshot' copied into the
| Nix store. For example, say we had this file saved to
| /home/chriswarbo/default.nix: # Define some
| constants with { # Import some particular
| revision of Nixpkgs nixpkgs = import (fetchTarball
| {...}) {}; # A path value, pointing to
| /home/chriswarbo/defs.sh defs = ./defs.sh;
| # A path value, pointing to /home/chriswarbo/cmd.sh
| cmd = ./cmd.sh; }; # Return a derivation which
| builds a text file nixpkgs.writeScript "my-super-duper-
| script" '' #!${nixpkgs.bash}/bin/bash source
| ${nixpkgs.lib.escapeShellArg defs} ${cmd} foo bar baz
| ''
|
| Notice that the resulting script has three values spliced
| into it via ${...}:
|
| - The script interpreter `nixpkgs.bash`. This is a Nix
| derivation, so its "output path" will be spliced into the
| script (e.g. /nix/store/gpbk3inlgs24a7hsgap395yvfb4l37wf-
| bash-5.1-p16 ). This is fine.
|
| - The path `cmd`. Nix spots that we're splicing a path, so it
| copies that file into the Nix store, and that store path will
| be spliced into the script (e.g.
| /nix/store/2h3airm07gp55rn9qlax4ak35s94rpim-cmd.sh ). This is
| fine.
|
| - The string `nixpkgs.lib.escapeShellArg defs`, which
| evaluates to the string `'/home/chriswarbo/defs.sh'`, and
| that will be spliced into the script. That's bad, since the
| result contains a reference to my home folder! The reason
| this happens is that paths can often be used as strings,
| getting implicitly converted. In this case, the function
| `nixpkgs.lib.escapeShellArg` transforms strings (see
| https://nixos.org/manual/nixpkgs/stable/#function-library-
| li... ), so:
|
| - The path `./defs.sh` is implicitly converted to the string
| `/home/chriswarbo/defs.sh`, for input to
| `nixpkgs.lib.escapeShellArg` (NOTE: you can use the function
| `builtins.toString` to do the same thing _explicitly_ )
|
| - The function `nixpkgs.lib.escapeShellArg` returns the same
| string, but wrapped in apostrophes (it also adds escaping
| with backslashes, but our path doesn't need any)
|
| - That return value is spliced as-is into the resulting
| script
|
| To avoid this, we should instead splice the path into a
| string before escaping; giving us nested splices like this:
| source ${nixpkgs.lib.escapeShellArg "${defs}"}
| f0e4c2f7 wrote:
| I find there is a perfect middle ground here (applies to
| multiple languages like this.)
|
| Nix + LLM.
|
| Especially if using GPT4 for quality. You get all of the
| usefulness of Nix, but created or edited using plain English.
|
| And then of course at the end you output the nix as an artifact
| to live in version control.
| SirensOfTitan wrote:
| What I would like is to replace both Docker and docker compose
| for prod images and local dev, respectively for my team. Is this
| possible with nix today? It's mostly a macOS box team.
|
| I use nix flakes to manage my own configuration, but last time I
| played with building docker images on macOS I had to stand up a
| builder image on qemu or inside docker.
|
| Further, I've historically run into friction between other
| package managers and nix. The poetry2nix and pnpm2nix kind of
| tools have a lot of friction [for example, private registry
| support for poetry is poor]. My current project has a dependency
| on xmlsec and it's a bit cumbersome to handle building non wheels
| on M1.
| shp0ngle wrote:
| nix is one of the things I always think would be neat to try, but
| I'm always scared away by the complexity.
| rgoulter wrote:
| You can get quite far without having to be aware of significant
| complexity.
|
| e.g. to take a look at https://devenv.sh/ or
| https://www.jetpack.io/devbox/docs/installing_devbox/ which aim
| to leverage nix without requiring nix knowledge.
| anarchogeek wrote:
| Doe nix work at all? Or is it just not actually functional on top
| of MacOS? I've tried a dozen times over the years and I've never
| gotten it working.
|
| Seriously, how is anything so hard to use still around after 20
| years!
| bpye wrote:
| I've never had an issue with Nix itself on macOS but there are
| occasionally packages that are broken on macOS but work on
| Linux - despite upstream supporting macOS.
| dindresto wrote:
| You might want to give the new installer by Determinate Systems
| a try: https://determinate.systems/posts/determinate-nix-
| installer
| [deleted]
| ziml77 wrote:
| I'm definitely going to give that a try. I had issues with
| the Bash script on macOS and was annoyed that it left me with
| a system that I had to manually clean up.
| SkyMarshal wrote:
| Hard to answer your question without info on what the problem
| is, but lots of people use it on MacOS. Maybe ask about your
| problem on /r/nixos or https://discourse.nixos.org/.
| kaba0 wrote:
| It absolutely works and is the best thing since sliced bread
| within package managers -- many UNIX tools are just simply
| broken on Mac (not always on the packaging side), and in case
| of more niche tools it is simply not a priority.
| striking wrote:
| I ship a development environment to a fleet of ~100 engineer
| laptops based on Nix. If it didn't work, I'd be out of a job
| thisismyswamp wrote:
| Why would engineers need their environment shipped to them by
| a human?
| striking wrote:
| Technically they `git pull` it themselves, but the fact
| that it continues to work involves a human.
| tmountain wrote:
| Do they run NixOS or just use the package manager? What's
| the host OS?
| striking wrote:
| They run macOS, pull a repo, run a setup script.
|
| They get a multi-user Nix install with a direnv
| integration that boots up project-local daemons. Think
| Postgres, Redis, and so on; those are all available,
| along with the Nix packages the env needs, while their
| current working directory is that of a project folder.
|
| Very few things live outside of the project, but the
| things that do are unfortunately stateful. We'll be
| solving that soon, too.
| amelius wrote:
| 20 years, is that the compile time now? ;)
| Reventlov wrote:
| Hold up we're talking about Nix not Rust !
|
| (yeah sorry couldn't resist, I know this is probably
| misleading)
| speed_spread wrote:
| And here I was thinking about Gentoo...
| mtlmtlmtlmtl wrote:
| Oh that takes me back to trying to explain to some Gentoo
| users back in the day that that yea you can optimise stuff
| better for your slow ass computer. But you now have to
| spend most of your time compiling code on your slow ass
| computer.
|
| I always found Arch to be a much more reasonable system for
| this use case because compiling _everything_ from scratch
| was just pointless, at least back then. But it still maoes
| it easy to rebuild packages with custom patches etc.
| jacoblambda wrote:
| > Oh that takes me back to trying to explain to some
| Gentoo users back in the day that that yea you can
| optimise stuff better for your slow ass computer. But you
| now have to spend most of your time compiling code on
| your slow ass computer.
|
| Honestly it depends what your goal is with gentoo. My
| whole sell with gentoo is that custom packages are just
| so easy. I can take some garbage toolchain from an
| embedded manufacturer and wire up an ebuild for it that
| "just works". Nix is similar once you get it working but
| the nixpkg and nixos DSLs just kinda suck in their own
| ways. So it may take me 10-15 min to write and install an
| ebuild while the nix package may take me an hour or two.
|
| Same goes for situations where you need weird kernel
| configs. It's so easy to just recompile the kernel on
| gentoo once you have stuff set up. The OS is built
| expecting a majority of users will want to tweak their
| kernels so the OS's tooling doesn't fight you when you
| do. I find this often less well handled in other distros.
|
| As for arch, it is pretty close IMHO but (while it may
| have changed since I used it last) I found that the
| "bleeding-edge" focus makes dealing with old janky
| dependencies to be pretty painful.
|
| Gentoo certainly isn't the first choice for the majority
| of people but it IMHO is a really good choice if you are
| going to be working with funky proprietary toolchains (o/
| hi embedded engs).
| mananaysiempre wrote:
| Sarcasm aside, here's a Nix manual from 2004:
| https://releases.nixos.org/nix/nix-0.5/manual/manual.html.
|
| (The compile time of Nix itself is unpleasant, but not exactly
| exceptional among programs written in the modern C++ style. The
| eval time even for Nixpkgs even on a ten-year-old i5 is
| annoying but not a terrible problem the way it's used now,
| though even on a recent Android device it's admittedly measured
| in minutes.)
| bpye wrote:
| With the Hydra binary cache I can quite comfortably update my
| Avoton C2550 based router or Raspberry Pi 4 AirPlay receiver
| within a few minutes. It's only if I need to build a non
| trivial package that I have to make sure I build on my
| desktop or in a VM on my MacBook.
| mananaysiempre wrote:
| I doubt your setup needed recompiling the Nix binary itself
| at any point. Even I did that more out of love of adventure
| than for any practical reasons, it's just that the scars
| are still there. (Still less than those from the time when
| the LibreOffice build was broken on Hydra and a routine
| system update jumped right into trying to perform it
| locally, even if that indeed was what I technically asked
| for...)
|
| And you know what, the long evaluation thing might just be
| a bug. Or at least I don't see any other reason why (e.g.)
| `nix-shell -p yt-dlp` works reasonably fast on my Nix-on-
| Droid[1] installation but `nix shell nixpkgs#yt-dlp` takes
| minutes.
|
| [1] https://github.com/t184256/nix-on-droid
| password4321 wrote:
| I tried to install NixOS using the live cd last week in a Hyper-V
| VM, but it failed to get anywhere due to SquashFS errors.
|
| That seemed pretty low-level so I'm putting it back on the back
| burner. User friendliness doesn't seem to be a top priority, and
| that's fine.
| jacoblambda wrote:
| > I tried to install NixOS using the live cd last week in a
| Hyper-V VM, but it failed to get anywher e due to SquashFS
| errors.
|
| I'm curious what happened here because just a few weeks ago I
| was using a NixOS live-cd to rescue a botched gentoo VM on my
| windows machine (managed with Hyper-V manager).
|
| If you give it another shot, run into the issue again, and
| document it, the Nix community would almost certainly help you
| debug it and figure out what went wrong.
| password4321 wrote:
| Thanks for sharing your counter-anecdata, I'll give it
| another shot.
| tmountain wrote:
| I'd like to learn more about the project history, who started it
| (early contributions), and the context under which the early work
| was initiated. Wikipedia has exactly two sentences on the
| history. Is there a better version of the Nix story available?
| nextos wrote:
| I guess the LISA '04 article and citations / citing work are a
| good starting point:
| https://scholar.google.com/scholar?cites=1106087772774893771...
| domenkozar wrote:
| The best talk I know about this is
| https://www.youtube.com/watch?v=t6goF1dM3ag
| julianeon wrote:
| Surprising to me that there's 0 Nix meetups in the Bay Area, as
| listed on that page. There should be one!
| toastal wrote:
| It feels so painful to go back to 'regular' Linux now. I'm so
| concerned about config file entropy and version incompatibility
| that Nix has solved for me. I'm happy I took the Nix Pill though
| and completely skipped over Docker and it's often-unnecessary
| overhead. Nix store is a better solution to reproducible builds,
| and the syntax is a lot better than LISP for Guix or whatever
| Skylark is trying to be.
|
| Currently I'm setting up a second machine to distribute builds
| and share a cache on my local network. Overriding C flags Gentoo-
| style for better optimization is supported, but it can take a
| while to build--especially with LTO--as Hydra only builds for
| generic x86_64 so sharing optimized kernels and other software is
| great. I successfully got a shared znver3 LTO-optimized Linux
| 6.1.19 kernel with ZFS support yesterday! I just wish I could
| have built in parallel the kernel on the faster PC and the ZFS
| stuff on the slower one and resynced the build input derivations
| when it was finished after running `nixos-rebuild switch --flake
| ..`.
|
| For the future, I hope distributed Nix caches become the norm
| like BitTorrent and we can all share optimized builds.
| Rapzid wrote:
| Nix feels like a dead end.
| lamp987 wrote:
| Huh? I see nix more and more in the wild.
| miniBill wrote:
| Can you elaborate? Personally I feel like everything else is a
| dead end compared to Nix
| vilunov wrote:
| I personally would prefer a build and environment tool which
| uses the modern Linux namespaces to prepare isolated
| filesystems without needing to reinvent a whole bunch of
| wheels.
|
| A number of problems that I would like to be fixed: - Post-
| build patches to insure correct shared library paths in
| artifacts due to requirement to use absolute /nix/store
| instead of using the traditional Linux filesystem. - Numerous
| wrappers around existing build tools to move dependencies
| into nix packages to generate stuff like Cargo.nix. - Not so
| good handling of content-addressable packages due to historic
| cruft. - Horrible-horrible way to compute runtime-
| dependencies of packages [1]. This may be okay as a heuristic
| to initialize a project, but in the end it must be tweakable
| manually.
|
| I see a future where a package manager builds a fully-
| isolated environment with only and only required dependencies
| for my app, using CAS but not forcing it's style of the
| filesystem on me. Nix is a good step into that direction, but
| that's not a usable product in my view, just a research
| project.
|
| [1]: https://nixos.org/guides/nix-pills/automatic-runtime-
| depende...
|
| Edit: Forgot to add, Nix the language is also not good, but
| I'd like not to discuss that matter. This would be solved by
| a more modular architecture, where we can manage package with
| a one tool and build packages with a different tool. Until
| then, I would be forced to code in Nix, and that's
| problematic no matter how good the package management is.
| Valodim wrote:
| The filesystem complaint seems so fundamental, you might as
| well be complaining that Linux didn't use C:\ as its
| filesystem root.
| Rapzid wrote:
| Sure; from an industry adoption point of view.
|
| I don't think it will ever gain widespread industry adoption.
| All signs point to it remaining in niche, even if growing
| currently, user communities while being a curiosity to the
| wider IT world.
|
| It's not even in the conversation in most of the professional
| world. A large portion those who use, like it, and write
| about it say they wouldn't recommend it to anyone.
___________________________________________________________________
(page generated 2023-03-18 23:02 UTC)