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

Lix is a modern, delicious implementation of the Nix package manager

lix.systems

Post reply on HN
Print view View original

41–50 of 52 posts

Re: Lix is a modern, delicious implementation of the Nix package manager

#41

Post by srid »

Both this fork (Lix) and the other one (Aux - https://news.ycombinator.com/item?id=40200343) appeared in the context of the recent Nix drama, related submissions on which are presented below:

Open letter to the NixOS foundation (50 comments) https://news.ycombinator.com/item?id=40107370

The dire state of NixOS's moderation culture (87 comments) https://news.ycombinator.com/item?id=40166912

---

Additionally, these r/NixOS submissions may be of interest:

Jon Ringer: "In case I'm unable to return, wish you all the best" (348 comments) https://old.reddit.com/r/NixOS/comments/1cd5fod/in_case_im_u...

Transparency about jonringer's suspension (153 comments) https://old.reddit.com/r/NixOS/comments/1ceeg8h/transparency...

Thoughts on Jon Ringer's temporary suspension (71 comments) https://old.reddit.com/r/NixOS/comments/1ceiz36/thoughts_on_...

Moderation no-go zones (55 comments; ongoing) https://old.reddit.com/r/NixOS/comments/1cfv8vo/moderation_n...

---

Finally, the RFC to improve the situation:

https://github.com/NixOS/rfcs/pull/175

Re: Lix is a modern, delicious implementation of the Nix package manager

#42

Post by srid »

srid wrote: post #41

Both this fork (Lix) and the other one (Aux - https://news.ycombinator.com/item?id=40200343 ) appeared in the context of the recent Nix drama, related submissions on which are presented below: Open letter to the NixOS foundation (50 comments) https://news.ycombinator.com/item?id=40107370 The dire state of NixOS's moderation culture (87 comments) https://news.ycombinator.com/item?id=40166912 --- Additionally, these r/…

The NixOS community is currently discussing how to appoint a constitutional assembly within 2 weeks (that assembly will decide how to do community governance for the project). The discussions happen on Zulip: https://nixpkgs.zulipchat.com/ - and you can request an invite if you've contributed before.

Notable threads, which may be relevant to explain why these forks were created include:

- https://nixpkgs.zulipchat.com/#narrow/stream/435937-constitu...

- https://nixpkgs.zulipchat.com/#narrow/stream/435724-governan...

- https://nixpkgs.zulipchat.com/#narrow/stream/435937-constitu...

Re: Lix is a modern, delicious implementation of the Nix package manager

#43

Post by KingMob »

infinisil wrote: post #30
KingMob wrote: post #15

Earlier quoted context omitted.

Not sure, but afaik, one of the first big changes was to use Meson for building, instead of Dolstra's homegrown build system. Apparently, the switch to Meson was approved, and coded, ages ago, but Dolstra kept dragging his heels on it.

I'm afraid the letter spread some misinformation: The meson RFC has in fact not been approved: https://github.com/NixOS/rfcs/pull/132 For a discussion on this, see https://github.com/KFearsoff/nix-drama-explained/issues/1

Doesn't that get the timeline backwards? I thought the RFC was opened in response to inaction on the part of switching to Meson, which had been informally agreed-on.

Re: Lix is a modern, delicious implementation of the Nix package manager

#44

Post by KingMob »

Y_Y wrote: post #25
KingMob wrote: post #14

Earlier quoted context omitted.

Well, they do say it's a fork in the About and FAQ pages. I'm guessing the front page's aim is to be broader, more newbie-friendly, more forward-looking, etc. > Oh cool, I had "rewrite in Rust" on my bingo card You may also be curious about tvix, which is a greenfield version in Rust, not a fork (but still pretty feature-incomplete, iiuc).

Ya, the best case here is that we end up with another implementation with its own benefits. I think that the existence of Guix and tvix (and others?) is beneficial, and the overarching idea of Nix is too big and useful to silo into just one project with one direction in mind.

Guix is cool, and I like Lisps, but it has very different goals, unfortunately. Culturally, it's quite hostile to any implementation on non-Linux platforms, and I use nix-darwin.

I agree the ideas behind nix should spread to how we build software in general.

Re: Lix is a modern, delicious implementation of the Nix package manager

#45

Post by infinisil »

KingMob wrote: post #43
infinisil wrote: post #30

Earlier quoted context omitted.

I'm afraid the letter spread some misinformation: The meson RFC has in fact not been approved: https://github.com/NixOS/rfcs/pull/132 For a discussion on this, see https://github.com/KFearsoff/nix-drama-explained/issues/1

Doesn't that get the timeline backwards? I thought the RFC was opened in response to inaction on the part of switching to Meson, which had been informally agreed-on.

I'm going to quote https://save-nix-together.org/:

> Single-handedly blocking Meson, which has a passed RFC, for five years because he doesn’t know meson but knows his own build system

I don't know about exact timelines, but the letter is definitely wrong about this part.

Re: Lix is a modern, delicious implementation of the Nix package manager

#46

Post by rekado »

KingMob wrote: post #44
Y_Y wrote: post #25

Earlier quoted context omitted.

Ya, the best case here is that we end up with another implementation with its own benefits. I think that the existence of Guix and tvix (and others?) is beneficial, and the overarching idea of Nix is too big and useful to silo into just one project with one direction in mind.

Guix is cool, and I like Lisps, but it has very different goals, unfortunately. Culturally, it's quite hostile to any implementation on non-Linux platforms, and I use nix-darwin. I agree the ideas behind nix should spread to how we build software in general.

> quite hostile to any implementation on non-Linux platforms

Guix has a usable Hurd implementation, which is a "non-Linux platform".

Re: Lix is a modern, delicious implementation of the Nix package manager

#47

Post by projektfu »

rgoulter wrote: post #40
thomastjeffery wrote: post #38

Earlier quoted context omitted.

> Having a repository with a large number of packages doesn't prevent you from writing Nix code outside of that repository. No, but it does define how (and where) I will write that code. It's not uncommon for a package to need complex dependencies like udev. It's definitely necessary for nixpkgs to have opinionated decisions about how dependencies are structured, and what options/defaults are available and where. The…

> No, but it does define how (and where) I will write that code. I don't follow your rationale here. e.g. many people write packages for their own "nix user repository". https://github.com/nix-community/NUR or there are examples of fairly sophisticated programs which declare packages outside of nixpkgs, such as helix or llamacpp. helix: https://github.com/helix-editor/helix/blob/master/flake.nix llama: https://github…

Nix can handle it, but can the user? That's my question. It took a while for me to understand the basic organization of nixpkgs well enough to do things like reconfigure a package properly for another package. Documentation-wise, the big picture isn't well-explained and, like I said, there is no official documentation recommending the use of a GUI tool to help. I see that there are tools available, but very little uptake of them in terms of documentation.

I am not sophisticated enough in Nix to say what a good roadmap would be. But I feel that if I were sophisticated enough I would be trapped in the mindset and not able to see how it could be made easier to comprehend for new users and tools. But who knows? As of now it's a very interesting puzzle and, while I take a lot longer to accomplish what I can do elsewhere, I enjoy the little aha moments along the way.

Re: Lix is a modern, delicious implementation of the Nix package manager

#48

Post by Y_Y »

rekado wrote: post #46
KingMob wrote: post #44

Earlier quoted context omitted.

Guix is cool, and I like Lisps, but it has very different goals, unfortunately. Culturally, it's quite hostile to any implementation on non-Linux platforms, and I use nix-darwin. I agree the ideas behind nix should spread to how we build software in general.

> quite hostile to any implementation on non-Linux platforms Guix has a usable Hurd implementation, which is a "non-Linux platform".

Funny you should mention that. I've been trying to use it for a while, but the link on the Guix website to get a Hurd-based VM image is broken and I haven't been able to generate it myself.

Re: Lix is a modern, delicious implementation of the Nix package manager

#49

Post by rekado »

Y_Y wrote: post #48
rekado wrote: post #46

Earlier quoted context omitted.

> quite hostile to any implementation on non-Linux platforms Guix has a usable Hurd implementation, which is a "non-Linux platform".

Funny you should mention that. I've been trying to use it for a while, but the link on the Guix website to get a Hurd-based VM image is broken and I haven't been able to generate it myself.

On any Guix System you can use the childhurd service or generate a disk image. More details here: https://guix.gnu.org/en/blog/2020/childhurds-and-substitutes...

Re: Lix is a modern, delicious implementation of the Nix package manager

#50

Post by rgoulter »

projektfu wrote: post #47
rgoulter wrote: post #40

Earlier quoted context omitted.

> No, but it does define how (and where) I will write that code. I don't follow your rationale here. e.g. many people write packages for their own "nix user repository". https://github.com/nix-community/NUR or there are examples of fairly sophisticated programs which declare packages outside of nixpkgs, such as helix or llamacpp. helix: https://github.com/helix-editor/helix/blob/master/flake.nix llama: https://github…

Nix can handle it, but can the user? That's my question. It took a while for me to understand the basic organization of nixpkgs well enough to do things like reconfigure a package properly for another package. Documentation-wise, the big picture isn't well-explained and, like I said, there is no official documentation recommending the use of a GUI tool to help. I see that there are tools available, but very little up…

> Nix can handle it, but can the user?

Learning how to write Nix in order to get it to do what you want can be tough, yeah.

https://www.tweag.io/blog/2024-05-02-right-words-right-place...

In this recent post discussing efforts which have been made to improve documentation, the author reckons that one of the reasons Nixpkgs is difficult to understand is that Nix's powerful expressiveness allowed different people to take different approaches to solve similar problems. (As opposed to, having to rely on a common solution).

IMO.. difficulties with Nix fall into three broad categories: with Nix's idiosyncrasies, with the Nixpkgs codebase, or with the software you're trying to get Nix to run.

On most OSs, you might not need to have a deep understanding of what's going on in order to fix a problem. With Nix (& NixOS), running into problems probably requires a decent grasp of what you're doing, as well as what Nix is doing, and maybe how the Nixpkgs code is doing it.

> the use of a GUI tool to help

I think between "easy/hard to understand" and "easy/hard to model with a GUI", GUI helps a lot with things that are easy, but not so much with things that are difficult.

e.g. with VSCode, you can get a GUI to help you set options. Emacs also has a GUI to help you customize options; but you don't get a GUI that helps you write elisp.

e.g. I'm not sure that efforts like https://github.com/snowfallorg/nixos-conf-editor (formerly "snowflake") provide much more help than what the "search nixos options" provides https://search.nixos.org/options

I think most of the time people run into difficulty, a GUI isn't going to help. (In the same way that people don't ask for a GUI for Terraform).

Post reply on HN