Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Nix is the ultimate DevOps toolkit

tech.channable.com

Post reply on HN
Print view View original

191–200 of 243 posts

Re: Nix is the ultimate DevOps toolkit

#191

Post by stjohnswarts »

salamander014 wrote: post #116
__jem wrote: post #105

Earlier quoted context omitted.

I switched to NixOS after tripping over my laptop's power chord during an update, which broke Linux in such horrifying ways that I didn't dare attempt recovery. I agree that I'm not sure the extra complexity is worth it for day to day use, but just the ability to avoid catastrophic failure and near instant setup on new machines is worth it I think.

Many times repairing those kinds of situations in Linux is as simple as: - boot linux livecd - mount your broken filesystem - bind mount the important bits from the live kernel (/proc) - chroot Like this: cd / mount -t ext2 /dev/sda1 /mnt #Here's your broken install mount -t proc proc /mnt/proc mount -t sysfs sys /mnt/sys mount -o bind /dev /mnt/dev chroot /mnt /bin/bash #boom you are in. Now do whatever you can to r…

I just use ZFS filesystem w/ snapshot before update

Re: Nix is the ultimate DevOps toolkit

#192

Post by gmfawcett »

jonringer117 wrote: post #179
gmfawcett wrote: post #166

Earlier quoted context omitted.

Eh, I don't think nix-env is all that bad. Put it this way: nix-shell lets you dip your toes in the water, without learning the Nix language. Amazing value added... but sometimes it's annoying that it forgets that package you used yesterday. nix-env lets you "install" software, without learning the Nix language. Great, now I can use that Nix package repeatedly without having to nix-shell it. We're still better off th…

The issue with `nix-env` is how it tries to decide a later version. Python also has this issue, because it will see that python3.7 has a newer version called `python3.10a3`, and installs the alpha/dev version, instead of the expected python3.7.x Honestly, if people just used nix for `shell.nix` in projects, it's still major value added

Is there a tool that works something like this:

- mkdir myproject ; cd myproject

- nix-shell-env init # creates an "empty-ish" shell.nix

- nix-shell-env install nixpkgs.whatever # adds dep. to shell.nix

- nix-shell # activate it

So you don't have to learn any Nix-language / nixpkgs ropes, but can still have a viable shell.nix built for your project. I could see that being a nice stepping stone between "nix-shell -p" and "learning the language."

Re: Nix is the ultimate DevOps toolkit

#193

Post by ben0x539 »

Ericson2314 wrote: post #154
oblio wrote: post #100

Earlier quoted context omitted.

> If you use Nix in a "drive-by" kind of way, it's very hard to make any inroads into the language. The documentation and tutorials are not really intended for a casual user - it is expected you will sit down with the Nix site like a good book, and go at it from start to finish. If (like me) you instead touch Nix little and often, doing small invocations or on-the-fly editing, the docs are much less useful. This is s…

There are some serious gotchas like nix-env in this read I would like to delete. But, that said, I don't think targeting "drive by usesr" is worth it. The benefits of Nix is that it dramatically organizes the absolute disgusting mess that is how most people manage their computer. I don't want to drive people trying things out away, but Nix will never be worth it unless you embrace it, and half-ways usage will deliver…

I've used NixOS at home since like 2016. While I haven't used it professionally or for "serious" enthusiast deployments, I don't think I can claim to be a drive-by user. I still insist on using nix-env because it's what all the first-party manuals tell me to do and I don't want to get into a situation where I am experiencing huge pain and the first-party people all tell me "well, that's on you for doing things in a different way".

At least my impression from a while ago is that the actual documentation Nix has seems to be aimed at "drive-by" or at least casusal/entry-level users, and to get the deeper insights that make the whole thing enjoyable, you need to give up on the documentation and just absorb all the details from github discussions, through extensive trial&error, etc.

Re: Nix is the ultimate DevOps toolkit

#195

Post by thomastjeffery »

oblio wrote: post #100
ivanbakel wrote: post #38

Earlier quoted context omitted.

I am of a similar opinion, but I think it's largely due to my typical use case. If you use Nix in a "drive-by" kind of way, it's very hard to make any inroads into the language. The documentation and tutorials are not really intended for a casual user - it is expected you will sit down with the Nix site like a good book, and go at it from start to finish. If (like me) you instead touch Nix little and often, doing sma…

> If you use Nix in a "drive-by" kind of way, it's very hard to make any inroads into the language. The documentation and tutorials are not really intended for a casual user - it is expected you will sit down with the Nix site like a good book, and go at it from start to finish. If (like me) you instead touch Nix little and often, doing small invocations or on-the-fly editing, the docs are much less useful. This is s…

> Most users of anything are drive-by, rather casual users.

On top of this, Nix could be extremely well suited to casual users. It inherently avoids most of the problems that plague casual users of traditional package management tools.

Unfortunately, most of the more serious Nix contributores I have interacted with are in too deep to see the usability problems. Even worse, usability issues get trivialized, and users who ask for basic improvements get talked down and told they just aren't getting the magic of Nix.

For example, the topic of versions has been argued about for over five years: https://github.com/NixOS/nixpkgs/issues/9682

Re: Nix is the ultimate DevOps toolkit

#196

Post by thomastjeffery »

Ericson2314 wrote: post #154
oblio wrote: post #100

Earlier quoted context omitted.

> If you use Nix in a "drive-by" kind of way, it's very hard to make any inroads into the language. The documentation and tutorials are not really intended for a casual user - it is expected you will sit down with the Nix site like a good book, and go at it from start to finish. If (like me) you instead touch Nix little and often, doing small invocations or on-the-fly editing, the docs are much less useful. This is s…

There are some serious gotchas like nix-env in this read I would like to delete. But, that said, I don't think targeting "drive by usesr" is worth it. The benefits of Nix is that it dramatically organizes the absolute disgusting mess that is how most people manage their computer. I don't want to drive people trying things out away, but Nix will never be worth it unless you embrace it, and half-ways usage will deliver…

Organizing that mess should make every user a casual user, serious it not?

Re: Nix is the ultimate DevOps toolkit

#197

Post by earthboundkid »

I think it's interesting that the motivating usecase is Python. Python's dependency management is extremely bad and many tools exist just to try to cover up how bad it is without solving the core problems. Would Docker have ever become popular without Python?

Re: Nix is the ultimate DevOps toolkit

#198

Post by ris »

root_axis wrote: post #42

I love nix as a concept, but in my experience it isn't practical on systems without a ton of memory. I regularly get build errors due to oom errors.

To run it on systems with low memory, I suggest performing any custom builds on a separate machine.

In "normal" circumstances you don't generally have to do any builds at all - (almost?) everything should come from the binary cache. To be doing all these rebuilds it sounds like you're customizing packages, which is already something other distributions don't tend to let you do at all.

Re: Nix is the ultimate DevOps toolkit

#199

Post by takeda »

jamie_ca wrote: post #172
mdoms wrote: post #164

Earlier quoted context omitted.

> You can also stub the hash (e.g. with lib.fakeSha256). nix-build will fail with a hash mismatch and tell you the correct hash. Are you kidding me?

Oh, shades of my favorite bug ever, doing commercial product QA two decades ago. The product had an external license file you'd need to drop alongside, and on boot if your licence key didn't match for your name + connection settings, the retail build would spit out both the key in the file, and the expected correct key for your settings. It was not a priority fix for them, either. At least this one is merely informat…

In this case it is intentional and basically became a feature to the point that probably majority uses.

The hash requirement is kind of a chicken & egg problem, because to fetch a file you need the hash, and to get the hash you need to fetch the file. So this gives a way to escape it.

There's also the "proper way" to use the prefetch command (I personally like the nix-universal-prefetch) which basically fetches file to the cache and outputs the hash, but in that case it is one extra command which you need to figure arguments for, so the former method is just faster.

Post reply on HN