It also requires JavaScript. I like to have JS off by default since running code on my machine is a privilege—one that I opt into, not the the site owner’s choice. This is frustrating since these blockers don’t let me know if the site is trustworthy first before needing to solve a Sudoku for Cloudflare or calculating useless hashes for Anubis.

So wild thinking folks would actually believe a massive, US-based, publicly-traded company when they say something is “privacy-respecting”.

Yikes. That Nix code is a mess without meaningful organization & only usable via experimental flakes.

There are two kinds of organization happening here that you might not see:

1. All .nix files (besides flake.nix) are flake-parts modules: https://flake.parts/

2. It's not only usable with experimental flakes. Works fine with unflake or trix.

The experimental part of flakes is enabling flake support in the `nix` CLI.

Flakes are also a design pattern in pure Nix syntax that can be evaluated fine without the experimental flag.

If you're curious about this meaningful organization, it's pretty well-documented:

https://denful.dev/

As for the experimental nature of flakes, it's more of a social experiment by now:

https://simonshine.dk/articles/if-flakes-are-experimental-wh...

Flake parts modules means that it’s an abstraction on top of an abstraction, flakes, on top of Nix. Then to need to throw unflake or trix at the problem is more layers & woven dependencies—same for ‘Dendridic’ patterns. If you invert that paradigm, & just import or callPackage Nix files from the flakes, then accessing say a package.nix or module.nix or overlay.nix is trivial for anyone not taking part in your specific design pattern—be it flakes, nilla, whatever. I feel this is another of these situations where engineers want to engineer their way out of messes by adding more code. Rather than a “how do I do X-PROBLEM in flakes?” if the question is “how to do X-PROBLEM is bog standard Nix?” you end up at design that tends to be a lot simpler since the the simpler bits are now decoupled from the framework (which flakes behaves more like); instead, flakes now own its complexity only in its file instead of its patterns ‘infecting’ simple parts (case in point, 2 weeks ago I helped a project get the overlays be compositionally sound by removing a coupling of inputs as a first argument & a self threaded into the package via callPackage). This is why ‘package normal form’ exists for packages in Nixpkgs so any setup can callPackage it… or how overlays already offer more powerful/flexible composition than input.follows which adds to flakes composition problems. With exceptions, Nix itself was already good enough for most cases… it just needed some design guidelines everyone could start reasonably follow (which the experiment post points out is “the good part” (good post btw… hadn’t seen)), except the state of flakes being as the are means they are stuck in limbo as too many projects now rely on it; which I guess that limbo itself means they are stable since all changes insight in-fighting—& all of these forks now have incompatible changes making it non-standard. I say best to just skip flakes since most projects don’t need anything more than pinned input starting point to produce: a package, an overlay, & a module (if relevant).

(for context, you're replying to the author of an alternative nix input pinning mechanism, which means... they're probably aware of all that and yet they chose their wording like this anyway)

Hahaha, I didn't see.

Hi toastal, I appreciate your work.

ຂອບໃຈເດີ້

Join the club! I did as soon as the Microsoft acquisition realizing this would be only a matter of time… with more projects (finally) leaving that ecosystem, I might finally be able to delete my last account with Microsoft.

    Location: Eastern Thailand
    Remote: Yes, can travel every so often
    Willing to relocate: No
    Technologies: Nix, NixOS, OCaml, PureScript, Elm, JavaScript, CSS
    Résumé/CV: https://toast.al/skills/
    Email: toastal+hn@posteo.net

Looking to transition off of front-end work & into devops. I can help monitor systems from Asian time zones. Flexible hours help & I don’t mind being up at “odd hours” as I am a night owl.

If it got proper tooling this would be true—but the community will need to build it. Darcs has more out of the box & more existing ecosystems to work with. Pijul is barebones by design, ready to be scripted, there’s just not much out there.

Immutable commits seem like a pretty good base for a decentralized VCS for me. In fact, Git was designed for this use case in the first place.

The snapshot-based system requires that the patch order matters which Darcs/Pijul don’t require so long as the patches apply since they commute. This means you can pull in patches from other users at an time in any order & still get the same stable reference. If you apply patches in a different order in Git, you will get a different reference hash & some entity ends up needing to be the centralized source of truth when doing deployments & stuff—which is probably why everyone ends up having some code forge for their code base on a centralized server to “sync” the state.

And with rebase, how are the commits immutable? Seems like MS GitHub found a way to mutably drop commits recently…

Xit has a better “take” on Git. Pijul & Darcs still have better fundamentals.

worse is better

pujil's patch alebgra is sick but the whole system implementation is so complex my guy is still toiling away on it, unfinished, after half a decade

We are finally getting closer to me getting to delete my last account with Microsoft. Nixpkgs: please follow suit.

reStructuredText & AsciiDoc are so, so much better than Markdown since they have rich feature sets to actually build documentation, blogging, & so on. It’s a massive shame everyone would prefer _yet another Markdown fork_ like the OP.