Live data from Hacker News

NixOS 22.11 “Raccoon”

nixos.org

151–160 of 201 posts

Re: NixOS 22.11 “Raccoon”

#151

Earlier quoted context omitted.

I'm just going to link to the best HN comment I've seen on this topic https://news.ycombinator.com/item?id=33679621

No mention of the fucky /nix/store paths for everything? I haven't used a lot of other distros, especially recent ones (my list: Slackware, Redhat, Ubuntu, Debian), but Nix is a drastic departure from the standard FHS and Linux conventions. Don't get me wrong - I love NixOS! I'm gradually switching my infrastructure to NixOS. There are very necessary reasons for Nix's departures. But it is jarring , and if we want co…

I guess I kind of think of that as like "Lisp has a lot of brackets!" true, but something someone looking into potentially using it knows already.

Re: NixOS 22.11 “Raccoon”

#152

Recently installed nixos and was trying to get docker installed with little success - I tried googling for a while and came up short. Maybe it’s obvious to veteran nixos users. Does anyone know of a comprehensive nixos guide or YouTube series? I’d love you forever.

Add this to configuration.nix:

virtualisation.docker.enable = true;

The best comprehensive guide is the manual:

https://nixos.org/manual/nixos/stable/

Re: NixOS 22.11 “Raccoon”

#153
post #13

I might want to try some new Linux distribution so I wonder: what doesn't work in nix? What are its weaknesses? What about devices with non-free firmware?

- You will have to learn both the nix language and working with nixpkgs. Learning nix is pretty trivial IMO (great resources are nix-1p[0] and Nix Pills[1]) but the documentation, while vast, is pretty shallow at the moment. You will likely have to resort to reading random blog posts, nix configs published by others and the source code of nixpkgs itself. - As mentioned by another commenter you will not be able to run…

> It is significantly more bandwidth- / rebuild-heavy. If an input for a derivation changes it will trigger a rebuild, which means either a redownload from the binary cache or a recompilation.

For general usage I didn’t notice it much, like, as an alternative to apt/pacman/etc. Ok, maybe don’t use it from a limited data plan (but isn’t true of every desktop OS?).

But sure, if you patch some lib n layers deep you will have to recompile many things, which is a godsend (in that you can actually do that), but will take a bit of time. But you can usually decrement its impact by really changing what has to be changed and using a “standard” channel for all the rest. With flakes it is especially easy to mix and match multiple nixpkgs repos at different versions.

Re: NixOS 22.11 “Raccoon”

#154

How long are we going to sit on our hands and pretend flakes aren't the only way forward? Am I just missing something?

Well they are - but there are a couple of things blocking it from becoming the default. I think the main thing is this PR: https://github.com/NixOS/nix/pull/6530 - Eelco Dolstra gave a talk on this recently as well if you wanna know more: https://www.youtube.com/watch?v=JE-vLFMTXxM

Another thing that comes to mind is the ability to parametrize flakes so that they can be configured from the CLI: https://github.com/NixOS/nix/pull/6583

Re: NixOS 22.11 “Raccoon”

#155

Earlier quoted context omitted.

I remember reading that nix unlike all other distros can install multiple version of the same package and I want this feature, but I guess programming a package config might be too much for me. Maybe I'll try nix package manager then.

> nix unlike all other distros can install multiple version of the same package The above is sometimes true and sometimes not. For the most part, Nix can install multiple versions of a program but only one can be in use at any given time. Nix is for the most part shell based workflow (as in bash, zsh, etc.). The `nix-shell` command lets you switch out the packages (and versions of packages) that are used in any given…

> Nix can install multiple versions of a program but only one can be in use at any given time.

That’s not really true and is only a limitation of how PATH works on UNIXes (the first match is used). But you can for example add an aliased name for multiple versions of the same package, or for another meaning of use you can have different executables in the same environment different versions of the same lib (e.g. one bash script references python3, the other python3-at-specific-patch/minor-version/whatever)

Re: NixOS 22.11 “Raccoon”

#156

Earlier quoted context omitted.

I remember reading that nix unlike all other distros can install multiple version of the same package and I want this feature, but I guess programming a package config might be too much for me. Maybe I'll try nix package manager then.

> nix unlike all other distros can install multiple version of the same package The above is sometimes true and sometimes not. For the most part, Nix can install multiple versions of a program but only one can be in use at any given time. Nix is for the most part shell based workflow (as in bash, zsh, etc.). The `nix-shell` command lets you switch out the packages (and versions of packages) that are used in any given…

> or the most part, Nix can install multiple versions of a program but only one can be in use at any given time.

That's a bit hand-wavey. More precisely: when you run a command, like `python3`, you can only associate that with one file. If you want multiple Python 3 interpreters, you'll have to use different names (e.g. making symlinks).

Alternatively, you don't need to bother "installing" anything; e.g. I use Nix for projects which use Scala, Maven, Python, NodeJS, etc. yet I don't have any of those installed. Instead, each project includes a `shell.nix` file which specifies the tools it wants. Running `nix-shell` in different folders gives me access to different tools.

Also, with Nix we only need to care about the end result: we can "install" a bunch of different programs, even if they have incompatible dependencies, since we're not "installing" those dependencies. ("Install" just means putting a symlink in some bin/ folder, like /run/current-system/sw/bin on NixOS or $HOME/.nix-profile/bin on non-NixOS)

Re: NixOS 22.11 “Raccoon”

#157
post #23

Earlier quoted context omitted.

If you just want someone to shoot you straight: Documentation and naming conventions for Nix are absolute shit across the board. This will get downvotes, and people will say I'm wrong, but I'm 100% right. Go see yourself, it's bad. Language is called Nix, OS is actually called Nix, package manager is called Nix, just the whole thing seems like it was written in 1 week by a squirrel with 12 hands and a sack of ritalin…

Sounds like they aren't very smart if they can't elevator pitch it. Perfectly reproducible OS with easy rollbacks. OS never gets crufty, no need to reinstall every release version or two. Single configuration language for all apps and system components. Composable and shareble config modules at any level of abstraction, e.g. you can piece together many git repos to custom roll your OS. Isolated dependencies for every…

My Litmus test for package managers is the ability to install gnome, switch it out for kde and back. (Or starting with kde). One should be able to do that without accumulating garbage (packages that are no longer used, config files, etc), but so far only NixOS passes it (and I didn’t try but assume Guix).

Re: NixOS 22.11 “Raccoon”

#158
post #38

Earlier quoted context omitted.

> OS is actually called Nix Not true. The distro is called `NixOS`. The package manager and it's language is called `Nix`. I do agree that the learning curve is extremely steep.

That's not a learning curve, that's a brick wall. Maybe call the package manager something catchy like "pacman" or "update_software_from_repos" :)

Well, there is a model change as well, traditional package manager doesn’t make as much sense for Nix.

Re: NixOS 22.11 “Raccoon”

#159
post #139

Earlier quoted context omitted.

No mention of the fucky /nix/store paths for everything? I haven't used a lot of other distros, especially recent ones (my list: Slackware, Redhat, Ubuntu, Debian), but Nix is a drastic departure from the standard FHS and Linux conventions. Don't get me wrong - I love NixOS! I'm gradually switching my infrastructure to NixOS. There are very necessary reasons for Nix's departures. But it is jarring , and if we want co…

That's true! Whenever I demo Nix for someone in person, the first trick I do is > Look ma, no /usr/lib and right after that it's a chat about the Nix store, and then a tour of what all those ugly hashes let you achieve. I guess when I wrote that comment I was mostly thinking about what it's like to administer NixOS on a personal system over the moderate term, not the initial shock and wonder of hiking through the glo…

My personal administration involved a lot of digging through installed software's FHS to figure out how things worked. Especially coming up through Slackware. It's probably a learning style thing.

Mutable distros you directly edit stuff in /etc, then build your knowledge on top of that foundation. Whatever better practices you end up adopting, you're still ultimately modifying files in /etc (and probably elsewhere). A NixOS beginner shouldn't be touching config files, and can't even do things like replace a binary with a shell script wrapper to understand when and how a program is run by a different program.

So I see that departure as a pretty huge one, that will affect someone learning Linux on NixOS for many years, as they need to dig through NixOS specific docs to understand how they're supposed to configure something, rather than falling back to the regular packaging docs. Whereas with Debian you only need Debian documentation to know how to install a package, but after that the upstream package documentation tells you everything else.

As an aside, I feel like NixOS asks a fundamentally different question - "how can we mitigate Linux/Unix's complexity" rather than the traditional mutable distro question of "how can we best interact with Linux/Unix's complexity".

(Also, that sounds like a great approach to explaining NixOS!)

Re: NixOS 22.11 “Raccoon”

#160
post #88

I might want to try some new Linux distribution so I wonder: what doesn't work in nix? What are its weaknesses? What about devices with non-free firmware?

Nix feels to me like a cool but somewhat hacky v1 of a really great idea. I'm hoping someone creates a much more elegant successor. If Nix is CVS or even Subversion, I'm hoping for Git.

Maybe take a look at Guix? (I don't use it, but it sounds like what you describe)
Post reply on HN