I don't get the upset over forking. If the fork stops releasing and dies out, no problem. If it grows and advances the flag, then that's good, right? All of the reputational risk is being taken by the forkers. Who else is being hurt, here?
100% piss baby stuff imho.
Edit: "This is systemd, but for WOKE"
This post has "everything" in the same way as the buffet of the Beau Rivage at midnight: the goods are warmed over, but the overs are good warm.
the odd sobriquet of Auxolotl
Has the pendulum swung back already? I make it to parenthood just in time for puns to fall out of favor?
Now that Dr Dolstra has gone
Dr Dolstra
This particular curmudgeon, though, feels that this particular Nix fork missed a big opportunity: to automatically generate and manage more human-readable filesystems.
The cardinal sin of Nix is apparently naming things. Since Aux exists for any other reason than fixing this, it has not atoned and can never atone.
Nix works wonders by automatically storing code in a software-generated and software-managed directory hierarchy. This has a profoundly off-putting side-effect: it eliminates a human-readable filesystem.
A specter is haunting Linux - the specter of /nix/store.
This particular jaded old hack much prefers the approach of GoboLinux.
And what is the solution? ~~FreeBSD Ports~~GoboLinux!
What Gobo offers is akin to semantic versioning, but applied to the filesystem: a semantic filesystem layout, where folder names encapsulate versioning info and are more meaningful than the old 1970s reduce-typing-effort-at-all-costs approach.
Cool, semantic versioning, that will save us.
The thing is, though, that we were all beginners once, and anything that makes Unix even more forbidding for both beginners and veterans is a problem.
The last great addition to Linux was FHS 2.3, apparently.
oh i dunno, "what is wrong with you people" is a reaction with something to it
Liam adds in the comments section
Nix fans love it with a passion I have only seen previously for horribly obsolete text editors, but the odd thing is that they mostly keep quiet about it, which TBH I find a very endearing characteristic.
They most certainly do not keep quiet about it!!!
-- a person who has posted about programming on Mastodon
While the author is being a bit of a tool, they're right about one thing: everybody who jumped the gun prior to the board announcement is now left with an ostrich-sized amount of egg on their face and no obvious path towards reconciliation other than eating a very large omelette. In particular, Jake and the Aux team don't have an obvious technical roadmap, which is a serious problem for a nixpkgs fork; also, I feel bad for Xe, who has left the community entirely and condemned themselves to pre-Nix distros. Pride leads to hubris leads to self-flagellating blogposts.
...I say, as I continue quietly working on my own reimplementation of Nix...
that’s my biggest frustration with Aux. they’ve actually dropped the nixpkgs fork after the board announcement, but I haven’t seen many concrete plans after that. there’s so much low hanging fruit for improvement on NixOS’s mechanisms and processes and I’d love for someone to take a swing at fixing all that — but I don’t think Aux is currently anywhere near focused enough to be it
at least we got Lix out of things, which I think is an incredibly important project to have especially after the board announcement. Nix’s new governance structure has a gigantic gap in it in the form of the Nix evaluator, and I feel strongly that’s intentional. having an independent and modernized (but compatible) Nix implementation will be better for the ecosystem as a whole.
I’d love to hear about your Nix implementation when it’s in a shareable state. I’ve got a few Nix-related projects myself that need a good home — some finished ones are waiting for things to fully settle before I decide how they’ll be released, but one project I’d like to start (but don’t know where it should go) is much better directory-local evaluation — that is, lorri/nix-direnv/use nix but with just one vastly-improved implementation in the evaluator.
Yeah, Lix is good. It's not what it claims to be, but just being a CppNix fork is enough.
So, I'm not developing in secret. My code is here, in my rpypkgs flake, and as the .packages.${system}.reguix attribute of that flake. One would probably want this Cachix cache if they're on amd64 and want to avoid building PyPy or CPython. (Upstream discussion about this bootstrap path is here.) I'll send out a more serious round of invites once the lexer, parser, compiler, and evaluator can actually handle a real-world evaluation.
For posterity: Hi! I'm linking this to you because you'd like to contribute to Regiux. Cool! You need to know RPython, a dialect of Python 2.7 used to specify interpreters. In a nutshell, RPython is statically-typed with lots of metaprogramming, somewhere around Java or Haskell. You write a Python 2.7 program, it gets imported into memory, and then the RPython toolchain compiles from memory into C, optionally generating a JIT compiler. For a gentle explanation, check out Brown et al doing Brainfuck (1, 2); if you'd like to see what high-performance RPython looks like, check out my DIVSPL interpreter or my take on Brainfuck.
that’s awesome, and RPython seems like a great choice for a more comprehensible foundation for a Nix evaluator! I’ll definitely be digging into this more as time permits this weekend. feel free to start a thread for this if you’d like more eyeballs on it at any point in the future!
condemned themselves
I don't know if I'm correctly grasping whether this bit is meant satirically.
Check out their recent posts; they've been spending a lot of time trying to reconstruct their NixOS experience and finding it to be more work than they imagined.
Oh dear, ouch, and yup.
I guess he has a Proven track record...
*pauses for laughter*...
Laugh, you bastards!
In any case, I think this guy misses the point regarding /nix/store naming conventions, particularly the dependency graph hash after every package name. This little brilliant thing basically tells you all you need to know about it's association. It's also part of why you can have several packages from several different closures without resorting to adding -1, -2, etc.
That being said, I have been eyeing Guix because of how the nix community was run... but let's see how things go.
This is the best summary I could come up with:
VR murder headset inventor Palmer Luckey's "AI" powered combat-drone maker Anduril is a big user, and offered to sponsor the annual Nix conference last year, to considerable controversy.
Nix enthusiasts point out that this delivers lots of benefits, but to achieve these, you have to just… trust that your path and so on will work and stuff will just auto-magically be found somehow.
It offers better isolation between components than the classic Unix approach of dumping all binaries in /bin… or /usr/bin or /sbin or /usr/sbin or /usr/local/bin, according to some arcane system that last made sense on a DEC PDP with half a dozen 5MB hard disks in 1972.
One possible issue is that this could result in very long directory paths, but with all the work on next-generation filesystems from Btrfs to OpenZFS to bcachefs, this can surely be addressed.
Gobo retains the classic Unix directory tree, empty apart from lots of symbolic links, for backwards-compatibility, but hides it from human users with the GoboHide kernel module.
As Michael Brantley, CTO of Nix vendor Flox told us at FOSDEM, after three decades administering proprietary Unix machines and later Linux ones:
The original article contains 1,072 words, the summary contains 192 words. Saved 82%. I'm a bot and I'm open source!
this is FreeAssembly, a non-toxic design, programming, and art collective. post your share-alike (CC SA, GPL, BSD, or similar) projects here! collaboration is welcome, and mutual education is too.
in brief, this community is the awful.systems answer to Hacker News. read this article for a solid summary of why having a less toxic collaborative community is important from a technical standpoint in addition to a social one.
some posting guidelines apply in addition to the typical awful.systems stuff:
(logo credit, with modifications by @dgerard@awful.systems)