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

Nix – Death by a Thousand Cuts

dgt.is

Post reply on HN
Print view View original

251–260 of 336 posts

Re: Nix – Death by a Thousand Cuts

#251

Post by nothrabannosir »

tomn wrote: post #223
nothrabannosir wrote: post #197

Earlier quoted context omitted.

I don’t understand—the language itself is completely contained and separate from the derivation. Evaluation could be done in any language and the derivation will remain the output. You can absolutely have a better language generate derivations, surely? Hell, you could use Python typescript or go if you wanted to. They’d even be completely compatible with the unholy mess of cursed bash that is stdenv. What you can’t p…

> You can absolutely have a better language generate derivations, surely? Yes, hence guix. The issue is that it doesn't fit well into a pure functional language like haskell if you want to allow import-from-derivation or basic functions like "readFile", without putting everything in IO (complicating the DSL). https://nix.dev/manual/nix/2.25/language/import-from-derivat... What you can’t port over to another language…

Discourse is massive selection bias. The people who make it that far are not an accurate representation of the potential nix users.

Re: Nix – Death by a Thousand Cuts

#252

Post by gf000 »

pzmarzly wrote: post #107
soraminazuki wrote: post #39

Earlier quoted context omitted.

Wi-Fi should just work like any other Linux distro, assuming you have a desktop environment like GNOME or Plasma installed.

eduroam is not your everyday WPA{2,3}-PSK, it's WPA2-EAP. There are official shell scripts to provision certificates, but they only seem to work on major distros, and for some reason the eduroam website made different scripts for every university. Also, for most people this is their first (and last) experience with 802.1X, especially setting it up themselves. In my experience few years ago, it was a pain to set it up…

But then it would suck equally as much on any other Linux distro, NixOS has no relevance here.

(I have also suffered from tying to connect to eduroam on Linux laptops).

Re: Nix – Death by a Thousand Cuts

#253

Post by SuperSandro2000 »

eacapeisfutuile wrote: post #101
pkkm wrote: post #95

Earlier quoted context omitted.

Your veiled implication that Nix and NixOS aren't about "getting things done" is, I think, more than a little unfair. I'm using multiple programming languages at work. Each one of them has its own dependency manager that does basically the same job as the other ones. In Python it's Poetry, in Ruby it's Bundler, in JavaScript it's npm/yarn, in PHP it's Composer, etc. A lot of projects require extra setup steps outside…

That is not why neither Bazel or Buck was created.

Bazel is the bane of my existence. I have never seen such an anti distro tool that is so hostile against your system libraries.

Re: Nix – Death by a Thousand Cuts

#254

Post by SuperSandro2000 »

bjoli wrote: post #208
SuperSandro2000 wrote: post #154

Earlier quoted context omitted.

Guix has stripped away the biggest plus from NixOS: the module system and replaced it with a half assed system

I mean, modules are just regular guile modules. It feels somewhat clunky, but at the same time you can use guile's introspection to do fun stuff. I always found it more flexible, but on the other hand I never liked NixOS modules.

Yep, it feels somewhat clunky when you are used to NixOS modules :P

Re: Nix – Death by a Thousand Cuts

#255

Post by SuperSandro2000 »

tempfile wrote: post #229
SuperSandro2000 wrote: post #154

Earlier quoted context omitted.

Guix has stripped away the biggest plus from NixOS: the module system and replaced it with a half assed system

Can you say why you think nix modules are the "biggest plus" from NixOS? They don't even make the top 5 for me.

When installing Nextcloud I basically have the following 4 options: - Do everything by hand and read through the docs on every update. Does not sound like fun. - Use someones Ansible playbook and hope that they update it on time. meh, also customizing it is not a walk in the park and requires some effort on my side. - Use the upstream Docker container which has the same customization problem as Ansible - Use the NixOS module. Updates are fast. Configuration changes are being handled by NixOS and I can easily inject a nginx location block in my declarative config. I also can easily describe extra bits like pre-compressed assets which then are served by nginx in my normal workflow without having to think about them at all on updates.

overlays and the module system are THE killer features. Almost no one else has something comparable to offer and if those powerful features are well understood, they can save you soo much hassle.

Re: Nix – Death by a Thousand Cuts

#256

Post by SuperSandro2000 »

yoyohello13 wrote: post #188
emarthinsen wrote: post #119

I use NixOS as my daily driver. I concur. I wouldn't recommend it for most people (even for me, when I decided to give it a try). I'd probably just go Arch if I were to do it over again. The concept behind Nix/NixOS is amazing, but it needs to be polished. Flakes are the future, but they are languishing in this experimental status. Even simple things like installing packages from stable and unstable channels are too…

After spending some time on NixOS I basically decided to hold off until flakes become official and the docs are written with them in mind. In the mean time I just run Arch with Nix home-manager and I'm happy. I've developed enough good habits over the years that I don't get breakages, and home-manager allows me to easily sync my dotfiles across machines..

If you are using more than 2 channels than flakes are the natural progression.

Re: Nix – Death by a Thousand Cuts

#258

Post by nothrabannosir »

tomn wrote: post #239
kstenerud wrote: post #235

Earlier quoted context omitted.

> but if you look through the help section on discourse, the questions are not about the language Mostly because people don't know how to ask questions about the language. That was my experience. Over the past decade I've made a few forays into Nix and NixOS (I still need to revert one of my servers back to Debian from NixOS). Inevitably I find the language obtuse, and the help online is always in the form of code fr…

> the help online is always in the form of code fragments whose purpose kinda sorta looks alright maybe, but doesn't ever seem to fit into the setup I've built. So then I'm faced with completely rearranging the structure to match the helpful code, or try to massage the helpful code into my structure (which may or may not be a monstrosity, nor could I explain what every one of the magical incantations are for) None of…

The semantics of the language make it virtually impossible to write a good lsp with “go to definition”, particularly when you get into the module system (which is where you need it most). This is a massive barrier to entry and the only way to solve it is to spend a lot of time imbibing nix lore. It’s a fundamentally unsustainable language design for adoption as an incidental build tool and it’s no surprise that those who manage to persist are also the ones who spend a lot of time with it. Unlike a more ergonomic language with good tooling and semantics which encourage adoption by casual users.

Re: Nix – Death by a Thousand Cuts

#259

Post by JamesSwift »

thln666 wrote: post #80
nunez wrote: post #17

I'd like more clarity on this: > The advantage over docker here is that (when using Flakes) Nix builds are completely reproducible. Docker containers may be isolated, but surprisingly they are not deterministic out of the box. With some work you can make docker deterministic, but thats what you need, its much easier to use Nix. as the whole purpose of the Dockerfile is to create a reproducible environment.

The whole purpose of the Dockerfile is not to create a reproducible environment. The purpose of a Dockerfile is to run a bunch of commands inside of a container and save the output. Those commands may or may not produce the same output every time they're run. For example, if you have a debian base container that you run `apt install nginx` in, what version you actually get depends on a lot of different things includi…

> For example, if you have a debian base container that you run `apt install nginx` in, what version you actually get depends on a lot of different things including what the current version of nginx is inside of the remote repositories you're installing from _when the docker build command is executed_, not when the Dockerfile is written.

Its even worse. Its not the current version when the command is executed, its _the current version taking the layer cache into account_, which is a classic docker gotcha in needing to do single line `apt-get update && apt-get install` to sidestep. The layer cache really makes it hard to reason about.

Re: Nix – Death by a Thousand Cuts

#260

Post by microtonal »

tomn wrote: post #218
microtonal wrote: post #201

Earlier quoted context omitted.

My impression is that you can't really build nix as a DSL in haskell, because the core insight of nix is to introduce the "derivation" function into a pure programming language, whose behaviour is pure (the output is determined by only the inputs), but whose implementation is very much not (it builds packages from a specification). Evaluation is completely pure (at least with flakes, which disallows querying environm…

> Evaluation is completely pure (at least with flakes, which disallows querying environment variables, etc.). Evaluation of derivations will result in .drv files in the store, but that does not add impurity to the language itself. Building the .drv is a separate step (instantiation). If import-from-derivation is enabled (it normally is, it's a very useful feature, and the foundation of flakes), then some derivations…

If import-from-derivation is enabled

I have never looked at the implementation of IFD, but I assume that the evaluation and instantiation are still separated (and Nix will do multiple passes).

Even then functions like "readFile" are considered to be pure in nix, but not in haskell.

I am pretty sure that, unless you use --impure, all files that are read are required to be in the store. Since the store is read-only, it does not break purity.

At any rate, I agree that there will be some hoops to jump through. But I think it would be possible to make a Haskell DSL to define derivations similar to Nix. But I don't know why one would want to.

Post reply on HN