Live data from Hacker News

The Curse of NixOS

blog.wesleyac.com

241–250 of 361 posts

Re: The Curse of NixOS

#241
post #141
post #63

Earlier quoted context omitted.

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…

> My personal reasons for not going with Guix is that it is a GNU project That's a high price to pay. Look, the GNU project means different things to different people. On of the goals of the GNU project is to give users the tools to liberate themselves from arbitrary restrictions. The Hurd pretty much does away with the concept of an all-powerful root user as the only privileged account to alter settings such as netw…

During the earliest days of Guix certain relatively voluble community members had a tendency to create an impression that you -did- have to buy into the entire philosophy or you were actively unwelcome as a user.

Things seem to be much more sensible these days but it's worth bearing in mind that a bunch of people who tried to be early adopters will have come away with that impression and plan your evangelism for the current state of the project accordingly.

Re: The Curse of NixOS

#242

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 pac…

I think your reasons are focused on Nix for package management. For NixOS specifically, I would add: 5. It's essentially a source distribution with caching. If you want to add say a kernel patch, or any other type of patch, it's straightforward. Whereas running Debian and finding the solution to some problem is building a modified package, my usual conclusion was just to bear the problem until it was fixed upstream,…

Building packages from scratch for Debian can be a hairy endeavour, lots of tooling and it can be hard to know which one to use.

But building packages for Debian is dead simple, it is literally one command. Adding a patch to an existing package, and then rebuilding it, is a common operation.

Re: The Curse of NixOS

#243

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 pac…

Did they ever fix the need to disable SIP for nix to work on macOS? That made trying it out a nonstarter when I looked into it 2 or 3 years ago.

I hit similar issues a while ago, and I think they have this figured out now. The installer Just Works (tested on a MBP2015) as of a few months ago.

Re: The Curse of NixOS

#244

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 deve…

> 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.

Re: The Curse of NixOS

#245
post #230

Earlier quoted context omitted.

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…

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 a…

I've used Gnome a lot in my past. Also KDE since the early betas. At some point I just found out how tiling wms are kind of nice. After that it's no going back. It's like learning vim and then trying to go back to an editor with no modal editing.

Like. I need my editor, a browser, a few chat apps, music and lots of terminals. And I've used this config since i3 already for maybe over a decade. Every damn keyboard shortcut has been there for a long time. It's kind of hard to learn out of that...

Re: The Curse of NixOS

#246

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 deve…

I think you missed the key point. Software needs to be altered to run on Nix, and it needs to do so _systematically_.

Grab a script from the internet? Edit the shebang! Download some prebuilt software? Good luck finding /lib/ld-linux.so.2! Need to use some proprietary software you cannot edit? HALP!

Of course there must be some tooling to get around this, since stuff like steam is available (at least I hope), or else anything not packaged by nix would be a nightmare to install and use as a user. Any niche or domain specific software would become unusable. Take for example Quartus II or Vivado (just to name the two top FPGA EDAs), those two are not packaged by nix. Yes, there are a few recipes floating around, but those honestly scare me enough to not want to do it with more obscure tools like those for other, smaller brands, FPGAs.

(disclaimer: I never used nix, but that's my understanding from the article, and my own experience running proprietary stuff)

Re: The Curse of NixOS

#247
post #201

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 some…

> 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.

`nix.gc.automatic` is implemented as a systemd timer to run `nix-collect-garbage` periodically.

`nix.optimise` is just a nix conf option. Meaning anytime nix creates a store path, it will automatically dedup files by hardlinking them to a `/nix/store/.links/` path. There's no timer involved with `nix.optimise`. You can manually force existing paths to be "optimised" by doing `nix-store --optimise`

Re: The Curse of NixOS

#248
post #145

Earlier quoted context omitted.

Yes, the low number of readily available packages is the primary reason I switched from Guix to Nix.

The default channel of Guix has more than 21,000 packages. Is that what counts as a "low number" these days?

For me coming from Arch and AUR, yes.

Re: The Curse of NixOS

#249
post #107

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…

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

Re: The Curse of NixOS

#250
post #210
post #144

Earlier quoted context omitted.

Wow. Not true. You're not kicked out if you "dare" (how brave!) ask a question about it. You're welcome to chat about it on #nonguix. Is it really that hard to accept that #guix is not #nonguix and that we don't discuss proprietary software on the main channels?

There's two kinds of projects: Those who care about ideology And those that want things to actually work and get stuff done. The second group is the one that wins all of the users. Of course, there's room for both types of projects in the world. But don't be surprised when people who don't want to waste time on a political discussion that doesn't effect their lives in any way don't want to put up with it.

> But don't be surprised when people who don't want to waste time on a political discussion that doesn't effect their lives in any way don't want to put up with it.

There are no political discussions about the merits of proprietary software on #guix or the Guix mailing lists. It's just not the right venue for that.

So, yeah, I wouldn't want to waste my time on discussions like that, and we effectively don't.

> And those that want things to actually work and get stuff done.

This is a false dichotomy, but if you don't see it this way I'm not going to be able to convince you otherwise.

Post reply on HN