31–40 of 52 posts
Earlier quoted context omitted.
Funny how it probably differs per ~5 years who is the most famous BDFL. I'd have gone for Linus Torvalds as the most famous, or maybe Guido van Rossum.
I’d never seen Shuttleworth labeled a BDFL until this thread. Your two are the first who come to mind.
He even uses `sabdfl` as his handle.
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
Earlier quoted context omitted.
I’d never seen Shuttleworth labeled a BDFL until this thread. Your two are the first who come to mind.
https://wiki.ubuntu.com/MarkShuttleworth He even uses `sabdfl` as his handle.
What's the goal here? As a Nix[OS] user for a couple years now, the underlying Nix impl is not really on my radar for personal problems i have with Nix. It's entirely about the language and (lack of) language-tooling. I write typed systems on purpose during my day/hobby programming, and dynamic untyped experiences are just no fun for me personally. Nickel is far more interesting to me on my checklist of UX issues. Ki…
I agree, as a new user I think Nix(os/pkgs)'s deficiencies are: 1. Documentation doesn't really explain how NixPkgs works and thus there is a lot of magic that is unintuitive for a new user. 2. The Nix language has a number of annoying gotchas. I always go through several rounds of syntax errors before several rounds of name errors before code can run. 3. Whence this definition? NixPkgs' extreme inversion of control…
nixpkgs
It's a monolithic source tree full of disorganized interdependent "derivations". It's nigh-impossible to find your bearings, and that's before you even think about the bazillion git branches and GitHub PRs.
I started this GitHub issue about 4 years ago: https://github.com/NixOS/nixpkgs/issues/93327
The more time goes by, the more convinced I am that all of the problems I have with Nix stem from how tightly integrated everything is in the nixpkgs source tree. I came to NixOS hoping for a package manager; but what I got is something else entirely. I find it incredibly ironic that a package manager whose core feature is isolated reproducible builds, could fail so hard at isolating packages from each other.
The nix language isn't the problem. The problem is the impenetrable novel that was written in it.
Wait, Nix isn't "modern" anymore? Can we please, for the love of Flying Spaghetti Monsters, stop calling everything new "modern" as if that word adds something to the quality of the product...
> Initial release June 15, 2003; 20 years ago
So... just by calendar time, no, nix probably isn't "modern". Though I do agree that calling a new thing modern isn't the most useful description; much better to say how it's better than the thing that came before it. The steel man is probably that "modern" is shorthand for "the underlying ecosystem/tools have shifted and the old thing suffers for not being able to adopt better ways of doing things, and this new thing will therefore be easier to work on / more robust / more feature-rich / less buggy / etc.", but I'd rather have that be articulated explicitly.
Earlier quoted context omitted.
I agree, as a new user I think Nix(os/pkgs)'s deficiencies are: 1. Documentation doesn't really explain how NixPkgs works and thus there is a lot of magic that is unintuitive for a new user. 2. The Nix language has a number of annoying gotchas. I always go through several rounds of syntax errors before several rounds of name errors before code can run. 3. Whence this definition? NixPkgs' extreme inversion of control…
I think you touched on it with #3, but here is my biggest issue with Nix: nixpkgs It's a monolithic source tree full of disorganized interdependent "derivations". It's nigh-impossible to find your bearings, and that's before you even think about the bazillion git branches and GitHub PRs. I started this GitHub issue about 4 years ago: https://github.com/NixOS/nixpkgs/issues/93327 The more time goes by, the more convin…
I think it's reasonable to say that the nixpkgs codebase is a behemoth that can be quite difficult to understand.
I think "nix and multiple versions of a package" is more nuanced. In that thread, several of the replies are saying "just use ...". As in, it's possible to vary the version of a package built. But, nixpkgs itself only has multiple versions of some package when that package is very popular (e.g. python, nodejs).
> The more time goes by, the more convinced I am that all of the problems I have with Nix stem from how tightly integrated everything is in the nixpkgs source tree. ... I find it incredibly ironic that a package manager whose core feature is isolated reproducible builds, could fail so hard at isolating packages from each other.
Having a repository with a large number of packages doesn't prevent you from writing Nix code outside of that repository.
Taking one large codebase and splitting it up into many codebases doesn't necessarily simplify things overall.
Wait, Nix isn't "modern" anymore? Can we please, for the love of Flying Spaghetti Monsters, stop calling everything new "modern" as if that word adds something to the quality of the product...
https://en.wikipedia.org/wiki/Nix_(package_manager) says > Initial release June 15, 2003; 20 years ago So... just by calendar time, no, nix probably isn't "modern". Though I do agree that calling a new thing modern isn't the most useful description; much better to say how it's better than the thing that came before it. The steel man is probably that "modern" is shorthand for "the underlying ecosystem/tools have shift…
I thought the mention of Rust, and versioning the language itself (like what Rust does) covers this.
That, and, the last few NixCpp revisions apparently had some significant regressions.
Earlier quoted context omitted.
I think you touched on it with #3, but here is my biggest issue with Nix: nixpkgs It's a monolithic source tree full of disorganized interdependent "derivations". It's nigh-impossible to find your bearings, and that's before you even think about the bazillion git branches and GitHub PRs. I started this GitHub issue about 4 years ago: https://github.com/NixOS/nixpkgs/issues/93327 The more time goes by, the more convin…
This is partly fair and partly unfair. I think it's reasonable to say that the nixpkgs codebase is a behemoth that can be quite difficult to understand. I think "nix and multiple versions of a package" is more nuanced. In that thread, several of the replies are saying "just use ...". As in, it's possible to vary the version of a package built. But, nixpkgs itself only has multiple versions of some package when that p…
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 problem isn't the quality of nixpkgs, or with any of its design decisions. The problem is that those design decisions are centralized and interdependent. That's the core issue that lead nixpkgs to be so poorly documented. It's the core issue that makes it incredibly challenging to create a sensible UI/UX for Nix and NixOS.
There are definitely benefits to a monolithic source tree. You can guarantee compatibility. You can have a clear place for communication about breaking changes and security updates. The thing is: you can get all of this without a monolithic source tree. Debian has been doing it for 30 years now. If anything, Nix should be able to do it better!
If the goal is to have a diverse set of package repositories, what better way to deliver them than a purely-functional declarative package manager? Nix is the one package manager that can handle totally incompatible packages, breaking changes, etc. all without breaking a sweat; yet at the same time keeps all its packages in a single monolithic source tree where none of that is allowed to be present. I see it as a missed opportunity.
Earlier quoted context omitted.
https://en.wikipedia.org/wiki/Nix_(package_manager) says > Initial release June 15, 2003; 20 years ago So... just by calendar time, no, nix probably isn't "modern". Though I do agree that calling a new thing modern isn't the most useful description; much better to say how it's better than the thing that came before it. The steel man is probably that "modern" is shorthand for "the underlying ecosystem/tools have shift…
> much better to say how it's better than the thing that came before it. I thought the mention of Rust, and versioning the language itself (like what Rust does) covers this. That, and, the last few NixCpp revisions apparently had some significant regressions.
Earlier quoted context omitted.
This is partly fair and partly unfair. I think it's reasonable to say that the nixpkgs codebase is a behemoth that can be quite difficult to understand. I think "nix and multiple versions of a package" is more nuanced. In that thread, several of the replies are saying "just use ...". As in, it's possible to vary the version of a package built. But, nixpkgs itself only has multiple versions of some package when that p…
> 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…
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.com/ggerganov/llama.cpp/blob/master/flake.nix
> yet at the same time keeps all its packages in a single monolithic source tree where none of that is allowed to be present
In a programming language, a function can be called with different arguments.
With Nix, since the packages are the result of functions, you can use these package definitions with whatever incompatibilities you like. -- I'm not sure what use case you're thinking of that Nix can't handle.