61–70 of 183 posts
Earlier quoted context omitted.
Maybe a better design. Bet? Not so sure. Guix is Betamax to Nix's VHS.
What a bad analogy. Betamax was superior to vhs.
Nix/NixOS is kinda shit, but at least you can easily run closed source software on it.
Earlier quoted context omitted.
Think about it like this: with Ansible you start from some unknown state of the system and then iteratively do actions to hopefully get what you want. With Nix you know what the base state of the system is, and the configuration language lets you describe your desired end state. Then the computer figures out what to do in the middle. The fundamental design of Ansible is that you do imperative steps to reach an end st…
Yes - that was exactly my point. It has nothing to do with the configuration language. The end result of nix(os) could just as well be done from a bash script (not advisable, no). And the problems with ansible would not be any better off if they had used something like the nix-language instead.
As someone who really would like to have something like nix the thing that scares me away every time is the fact that the people creating this aparently did not think a lot about how to onboard users. And I don't mean a lack of documentation — what I mean is that the obvious decisions that have been taken (naming everything "Nix", using Haskell as a base for the syntax, ...) don't really fill me with confidence that…
> Using Haskell as a base for the syntax I don’t really think this is a problem at all? I mean, at the particular design point the language occupies there are basically three possibilities: - Kind of like Lisp (parens everywhere, painful with pervasive currying); - Kind of like ML (var and fun everywhere); - Kind of like Haskell. Nix is chooses the last of those, and it does not have most of Haskell’s funkiness: no “…
It's not really 'kind of like' any of Lisp/ML/Haskell IMO, and a good fit I think. Maybe it wouldn't allow everything or easily, but then if we're already only talking about being 'kind of like' (not actually using) an existing language that's not a problem.
(It's more like Prolog I suppose, not syntactically but in declarativeness, which is also missing from your list. Unless it's lumped in with Lisp for having too many parens.)
It's kinda ironic, the biggest innovation in package management and OS design is basically unusable for the average tech person. Compared to Nix, every other package manager is a security liability.
Compared to Nix, every other package manager is a security liability. Nix is great, but I don't see much difference with respect to security. In fact, Nix encourages and flakes formalize pinning of nixpkgs versions. I am sure that there are a bazillion repositories/configurations out there that use a pinned nixpkgs version with known vulnerabilities in glibc, libxml, or whatever. Besides that, packages in nixpkgs oft…
I would be cautious not to assume the alternatives are perfect https://security-tracker.debian.org/tracker/status/release/s.... It's not uncommon for nixpkgs to get a security fix out before debian.
I think the real issue is that nixpkgs has a lot more "long tail" packages than most package managers, where security issues are grey areas. e.g. upstream aren't great at handling them, making new releases with the fix or god forbid acknowledging the need to be able to backport a fix to a stable branch.
Though I don't disagree that timely reviews would help an awful lot in nixpkgs.
Earlier quoted context omitted.
Compared to Nix, every other package manager is a security liability. Nix is great, but I don't see much difference with respect to security. In fact, Nix encourages and flakes formalize pinning of nixpkgs versions. I am sure that there are a bazillion repositories/configurations out there that use a pinned nixpkgs version with known vulnerabilities in glibc, libxml, or whatever. Besides that, packages in nixpkgs oft…
> because of a lack of volunteers to maintain all of nixpkgs They need some serious shakeup from that side in my opinion. I've had PRs open for trivial things for >1mth. Issues, security stuff, new packages. They don't even document how to mark something as a security issue. PRs that mention CVE do that, but otherwise I couldn't find anything so for example https://github.com/NixOS/nixpkgs/pull/161198 which includes…
Only committers can add those labels - it's probably best to flag it in the PR subject line and hope a committer notices it and turns it into a label.
Edit: more...
When it comes to "trivial" changes I think there's an ironic "zone of triviality" where, if other reviewers are anything like me, reviews of more serious bumps will get prioritized. A minor bump is so likely to get superseded very soon that I'll prioritize something that is more likely to cause breakages and require attention. Some package areas (e.g. python packages) do periodic mass bumps of packages to catch the stragglers.
There are of course issues though drawing attention to "trivial" changes that are subtly important like, as you say, security issues.
Earlier quoted context omitted.
You can only work with what something is. Not with what it might be, one fine day.
Sure, but e.g. the documentation problems with Nix don't prevent you from working with it. While the problems make it less smooth and productive than it otherwise might have been, it might already be better than legacy systems for you. In particular, Nix can be used in a non-invasive add-on manner on ordinary distributions. We have it installed on RHEL servers at work, where it is used exclusively as a build system a…
In a world where there are thousands of things for me to learn (many of them with poor documentation), Nix is just one such thing.
The question is, do I care about its purported benefits, and sink my time and effort into it, or should I sink time and effort into learning Unreal Engine, playing Rimworld, or going for a walk?
So far, for me (and most of the world) the last three (and the rest of the thousands of things) win over Nix.
As someone who really would like to have something like nix the thing that scares me away every time is the fact that the people creating this aparently did not think a lot about how to onboard users. And I don't mean a lack of documentation — what I mean is that the obvious decisions that have been taken (naming everything "Nix", using Haskell as a base for the syntax, ...) don't really fill me with confidence that…
> Using Haskell as a base for the syntax I don’t really think this is a problem at all? I mean, at the particular design point the language occupies there are basically three possibilities: - Kind of like Lisp (parens everywhere, painful with pervasive currying); - Kind of like ML (var and fun everywhere); - Kind of like Haskell. Nix is chooses the last of those, and it does not have most of Haskell’s funkiness: no “…
> I don’t really think this is a problem at all?
Of course it's a problem. You shouldn't use a syntax that has been soundly rejected by the industry.
Earlier quoted context omitted.
JSON would be a nice way to make a config file. I say this as an xmonad user too, which does its configs in Haskell as well. I love Haskell its just I don't want it to be my config language
I don't think JSON is a nice way to write config files at all. You can't even add comments. I'd much prefer something like Cue.
{
"foo": "bar",
"COMMENT": "This bars the foo"
}As someone who really would like to have something like nix the thing that scares me away every time is the fact that the people creating this aparently did not think a lot about how to onboard users. And I don't mean a lack of documentation — what I mean is that the obvious decisions that have been taken (naming everything "Nix", using Haskell as a base for the syntax, ...) don't really fill me with confidence that…
I've been working on things to help onboard people. If you wanted something to help onboard you with NixOS, what would you want to see?
Earlier quoted context omitted.
I don't think JSON is a nice way to write config files at all. You can't even add comments. I'd much prefer something like Cue.
So long as the parser doesn't except on undefined keys, you can add pseudo-comments to many places in a JSON config file. { "foo": "bar", "COMMENT": "This bars the foo" }