Nix forked, but over politics instead of progress

Recent ructions in the Nix project over moderation, leadership, and funding, have led to a fork… but one that fails to address the technical and human issues with Nix packaging itself. First there was an anonymous open letter calling for its community to "save Nix together". (Call us old-fashioned, but "openness" to us implies …

[Pascal Monett]

A directory tree managed by software ? No.

No thank you. I am a human being, I will not trust software to find my data, especially not in folders named with 64bit random letters.

I can actually manage my data and folders, thank you. I've been doing that since 1985. What I want is an OS that gives me the OS on one disk (it can fuck with folder names all it wants there), a Program folder at the location I specify, with all applications installed there, and a Data disk where I decide how data is stored.

If the OS gets borked, I want to be able to just reinstall that disk from backup and be up and running again.

I try to do that with Windows, but it is a chore. An OS that gives me non-human-readable folders ? Nope. Not interested, thank you.

[David 132]

Re: A directory tree managed by software ? No.

The remorseless creep of the GUID. First it was disk partitions, then it was Registry keys... I tell you, by the end of the decade we'll all be christening our children with GUIDs.

(Albeit that'll still be less stupid than whatever heiroglyphic Musk named his kids.)

Icon because I know I am shouting angrily at clouds here.

[I ain't Spartacus]

Re: A directory tree managed by software ? No.

65AD\#ZZZZ2358A1270-XDziiii5555! Come inside now! Your dinner is getting cold!

[Dan 55]

Re: A directory tree managed by software ? No.

I try to do that with Windows, but it is a chore.

I'm not sure which is more complicated, brain surgery or trying restore a full backup of a user profile including a complete correct non-corrupted user profile registry hive on a new computer in such a way that Windows' tiny mind doesn't implode after the user tries to log in.

Which by the way is the way Linux is going.

[Grogan]

Re: A directory tree managed by software ? No.

You're right that it's not as easy as it used to be, but you can still do it though, it's not like Windows and its SID's that you'll need special cloning/imaging software to deal with.

As soon as I build a kernel, I get rid of the UUID nomenclature in fstab (With important drivers built right in, you can trust hardware enumeration to be more consistent when not using silly systemd-udevd in the initramfs) but even that isn't too difficult at least if using an ext* filesystem, as tune2fs can actually change the UUID (not just generate a new one). So you can just change it to the same as what's in fstab and boot loader config instead of having to find, and set new ones in the files.

I recently had to do that with Arch, I had to convert it to boot from UEFI. I had used a CSM (cmos compatibility module) because I hate UEFI booting but I didn't realize that I was going to want Resizable BAR for a new graphics card and that a CSM conflicts with register addressing etc. So I had to tear down the partitions (need GPT), format and restore data. From off system, obviously. Chroot to install grub to UEFI partition, though even that can be done manually if you just use the fallback path (EFI/BOOT/BOOTX64.EFI). It was a hell of a lot better than a reinstall. Easier than I thought it was going to be, even.

If using a distro kernel, it still wouldn't be anything like Windows where it (pretty much deliberately) barfs on hardware changes in more than one way. At worst you'd have to build a new initramfs image if transplanting to a different machine. Or use a fat fallback one temporarily to avoid chroot and installing a kernel package (depending on distro of course)

[doublelayer]

Re: A directory tree managed by software ? No.

As I understand it, it's not your data that goes in those directories. It's installed programs and system configuration that they organize that way. You could put the programs folder on a second disk from the system disk, although you need to sync the main file in /etc which is used to build that program disk somewhere in case the system disk fails. Otherwise, as long as you're comfortable for programs to be in opaque directories, it sounds like this does what you asked for.

[Spazturtle]

It's all so tiresome.

[Dan 55]

Why wouldn't you want files called "/nix/store/nqi39ksavkfrxkrz3d0797n5wmzi9r30-go-1.16.15"?

This is the same kind of nonsense that lead to systemd, which of course means it's going to be in 99% of distros by this time next year for no fathomable reason.

[Joe W]

Came here to post pretty much exactly that comment...

[nematoad]

Snap.

Well, that makes at least three people that can see the trend in projects like systemd and Nix

If you edit the phrase to read:

systemd enthusiasts point out that this delivers lots of benefits, but to achieve these, you have to just… trust that your init will work and stuff will just auto-magically be found somehow.

It fits like a glove and shows the the lure of the incomprehensible is as strong as ever

[Someone Else]

Re: Snap.

...something about advanced technology and magic...

[steelpillow]

No fathomable reason

"it's going to be in 99% of distros by this time next year for no fathomable reason."

Oh, there's a very fathomable reason. BigCheese makes its money off support contracts tied to proprietary extensions. BigCheese is shit scared of easily-maintainable freebie versions. Since those are all derived from one Big Cheese or another, what better than to make the BigCheese distros shit to maintain so only our experts can rescue you?

Yesterday SystemD, today an unholy mix of Flatpack and Snap legacy installs, tomorrow let's Nix the world, bwahahaha!

[Bebu]

Careful...

《This is the same kind of nonsense that lead to systemd, which of course means it's going to be in 99% of distros by this time next year for no fathomable reason.》

The whole Nix circus is the sort of thing that would appeal to the systemd creator who might assimilate Nix into the systemd borg.

[Liam Proven]

[Author here]

> which of course means it's going to be in 99% of distros by this time next year for no fathomable reason.

No, I really do not think so.

Nix has a lot of opposition and that is deeply entrenched (meaning, big vendors putting a lot of money into it). Canonical has snap, which nobody else wants. Red Hat has Flatpak, which is in Fedora, but all the GNOME fans seem to like and so can be found on Ubuntu-based, Debian-based, and other distro families too.

And then the truly non-aligned have Appimage, which is my personal favourite.

If GNUstep got its finger out, then its all-FOSS version of NeXTstep/Apple's `.app` format could be a contender... but when I talk to the GNUstep folks, it's almost exactly like talking to the BSD folks: they don't even really understand the points I try to make, and so can't formulate any coherent response, because they don't know what to respond _to._

Nix is a Babel fish. By effectively removing all barriers to software portability between different distros and OSes, it has caused more and bloodier wars than anything else in the

history of creation.

So far, mainly in its own community. If it got widespread adoption, though... >_<

[Doctor Syntax]

"When I discovered Nix, I realized that, 30 years in, I'd been doing it wrong all this time."

After 40 years in or more I think I'll just stick with what we've dot - although I do hanker for the original idea that binaries were in /bin and user's home directories were in /usr and so on.

[Liam Proven]

[Author here]

> what we've dot

Freudian typo?

[jake]

Please use the "Tips and corrections" button .... Oh, wait.

[jake]

People who say "I don't like the *nix filesystem" really mean "I don't understand it[0], so therefore it's bad.". Or they are hawking a new idea in search of the almighty buck ...

Those of us who have been using *nix for several decades can see the logic behind the filesystem layout. Yes, I've tried GoBo, and fiddled about with Nix. I will not be switching over to either. They break too much stuff for absolutely no benefit to myself. You don't need to change something just because it is old, not when it works. For example, look at the layout of the controls in your car. How old is that basic setup? How about your common-or-garden wind driven water pump?

"although I do hanker for the original idea that binaries were in /bin and user's home directories were in /usr and so on."

What I see and use is a slightly evolved version of that ... part of the reason I run Slackware is because it's comfy.

_{[0] With an underlying, if unspoken, "And you can't make me learn it, either! I won't! So neener!"}

[jake]

Forrests and trees.

"That's a considerable endorsement from an experienced expert."

No, it's not. It's a marketing message from the CTO of a company that hawks the product he's hyping.

[Liam Proven]

Re: Forrests and trees.

[Author here]

> No, it's not. It's a marketing message from the CTO of a company that hawks the product he's hyping.

Not just that. I spent about 3 hours of the second day of the best and most interesting tech conference of the year talking to these guys. He impressed me with both his deep tech knowledge and his fervour for this tool.

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.

[jake]

Re: Forrests and trees.

I've been extremely leary of tech-evangelist types since Guy Kawasaki seriously commented that getting Macs into classrooms to get the kids hooked would be "better than heroin".

[Liam Proven]

Re: Forrests and trees.

[Author here]

> getting Macs into classrooms to get the kids hooked

I dunno, man. A world with loads of schoolkids who understand computers and aren't intimidated by them sounds pretty good to me.

There is a theory that it was the rise of 8-bit home computers and modems that helped bring about the fall of communism in Europe. The governments could control the distribution of physical _samizdat_ but once it went electronic and point-to-point, it could no longer effectively be suppressed. The secret police couldn't police it, and the result was *foom* *thud*.

I mean, it should have been Hypercard or Smalltalk. So long as it's bogus garbage like anything with curly braces, or anything interpreted by something written in a curly-braces language, it's going to remain strictly for the geeks .

[two00lbwaster]

Re: Forrests and trees.

> dunno, man. A world with loads of schoolkids who understand computers and aren't intimidated by them sounds pretty good to me.

Hmmm these days it just gets you a bunch of facile, cachet seeking vanity whores.

Which is why you should give them raspberry pis and make them build it and get it up and running themselves.

[Snake]

Re: fervour

But the Linux world really doesn't need yet another piece of software doing the same thing that [many] existing pieces of software do already. Plus, now it's forked, too.

Stop with the d@mn forking and recreating the wheel. If the "benefit" of FOSS is that everyone can do what they want, the "negative" is that...everyone does what they want. And you end up with a tangled mess of conflicting ideas, each on just half-baked in the pan because, rather than concentrate on making what exists the best it can be, you've divided your manpower and attentions to 10 simultaneous ideas. And then wonder why so much of the balance of the world doesn't give this idea the attention you feel it deserves.

[b0llchit]

Not trees but meshes

Once you have multiple applications you don't have tree dependencies, but they become meshes.

The only way to prevent mesh dependencies is to have all of a program encapsulated in a container. And then you are getting into, for example, flatpack, snap and docker territory. And yet, you are still running on one kernel. Or do you run a virtual computer instance for each app that runs barebone^(*)?

Speed and size does not seem to be a primary objective with all these levels upon levels of code and abstractions. Complexity is obviously no consideration when KISS is interpreted as grey-beard old fashioned.

^{(*) _{Every program tends to extend until it can read email. Now we are at the level of: Every program tends to extend until it becomes an entire operating system. And no, I wasn't thinking of emacs ;-)}}

[Mockup1974]

So what exactly was the Nix drama that led to the split about?

[A Non e-mouse]

lwn.net/Articles/970824/

[Sceptic Tank]

Friese kop

Eelco Dolst(r)a. Is that stubborn old goat Frisian by any chance?

(I'm only 75% Frisian, and things are already bad).

[Someone Else]

Does it surprise anyone...

...that a system dedicated to obfuscation and making its internals unparsable by a human brain would also come up with a name that is unparsable by a human brain (and unpronounceable by human lips)?

[Anonymous Coward]

Mumps programming language (1966)

We should bring back MUMPS from 1966.

[J. Cook]

Re: Mumps programming language (1966)

I'd rather contract a case of mumps(virus) than deal with MUMPS(programming language).

[captain veg]

familiar

"In NixOS, the traditional Unix layout is gone, with just a handful of empty directories left behind. It's replaced by a ton of folders under /nix/store/ called stuff like nqi39ksavkfrxkrz3d0797n5wmzi9r30-go-1.16.15."

Hmm. Quite a lot like Git, then.

-A.

[Teal Bee]

Re: familiar

This is an accurate analogy.

I guess the downvoters only know git from web interfaces and never actually interacted with it directly.

[AdamWill]

heck of an algorithm

"devise a consistent algorithm that categorizes applications, and libraries, and config files, and automatically allocates them to a human-readable tree"

you sure slipped the difficult part in there smoothly, huh...

[Dan 55]

Re: heck of an algorithm

And... if the algorithm works you're back where you started in the first place (a human-readable tree) before you put the filesystem through a hash mincing machine?

[TFL]

Everyone here seems overly focused on the gobbledegook path names, author included.

What those are doing for the system is to permit multiple versions of programs, libraries, and other dependencies, all fine-grained because it's based on hashes of the packages involved.

Those crazy-looking hash names also mean that the system can roll back cleanly to a previous config, just by adjusting some filesystem links.

In any case, none of this has to do with the very human issues facing the project. If other people don't want to use it, that's very easy. Just don't.

[Bebu]

Curious coincidence....

《the word axolotl comes from the Nahuatl: āxōlōtl, from ātl ("water") + xōlōtl ("slippery or wrinkled one"). That means that the original – and thus arguably correct – pronunciation is, roughly, "ah-show-loat", to rhyme with "goat."》

Last night I was looking up the earliest record of the tomato in Italy^☆ and ended up at traditom.eu (the site itself boggles my antipodean mind.)

An interesting read History of the Arrival of the Tomato in Europe

Nahuatl was also the language that the word tomato was ultimately derived: xaltomatl, xitomatl, tomatl.

I would imagine a few metaphorical xōlōtl tomatl* were thrown in this tiff.

* _{please pardon my inexcusable ignorance of Nahuatl. (This is clearly wrong. Why?)}

^☆ _{Elizabeth David appears to be misinformed in stating the tomato was introduced from (via?) China.}

[Bebu]

PATH was more of a problem

After two decades of maintaining multiple versions of many dozens of scientific and general software on nearly a dozen proprietary Unix platforms and OS versions the bigger problem wasn't installing multiple versions (/opt/$pkgnam/$pkgver works well enough) but maintaining the PATH (and shared library) environment variables on a per system and per user level.

I always wondered whether there was a better way of mapping the application's name, system properties and user to executable's file system location and experimented with all sorts of solutions none of which really worked all that well.

Giving each user an individual file system name space with all their preferred applications and versions under /bin, /lib etc seems the cleanest approach (a bit Plan9-ish. :)

[Lomax]

I must be doing something wrong

In the fifteen years I've been exclusively running Linux I can count on my fingers the times I've had package version conflicts that weren't easily resolved. I use Apt based distros and have been happy with how this works - my only concern being the growing number of app developers who can't be bothered to provide a repository or .deb for their stuff. Flatpak and Snap are increasingly the only options available, apart from building from source (which I prefer over the other two). I consider myself an advanced user, but cannot help feeling these are proprietary land-grab solutions looking for a problem. What am I doing wrong that prevents me from seeing the benefit of the bloat, duplication of effort and obfuscation offered by these alternatives?

[Liam Proven]

Re: I must be doing something wrong

[Author here]

> What am I doing wrong that prevents me from seeing the benefit of the bloat, duplication of effort and obfuscation offered by these alternatives?

I do know what you mean. For me, Git is more of the same. It is an extremely complex tool that solves a problem I don't have and have never had.

I think the key things are: scale of the system and distribution of the components. (Be those computers, or people, or programs, or files, it doesn't matter.)

Nix solves problems I don't have.

I very well remember the nightmares of RPM on Red Hat Linux, before `yum` or `dnf` -- or `zypper` for that matter. But Debian was massively arcane and the giant brains of its community were not so much unwelcoming, as that I felt that I was to them just one of the transient creatures that swarm and multiply in a drop of water, being scrutinised down a microscope.

I think there _are_ problems, but trying to communicate to these giant brains that the solutions that they have come up with are just too much for puny minds like my own, and the price of entry too high, is a task currently beyond me.

[captain veg]

Re: I must be doing something wrong

Well said.

I started in Linux with RPM-based distributions but, for my usage, DEB works much better. I'm now on Mint. I completely ignore the "Software Manager" app and do everything in APT or, more often Synaptic. This works well for me.

I don't really get why I would want something else.

-A.

[Anonymous Coward]

Home directories

To reiterate, home directories and user directories are unchanged. It is only the location of binaries / apps that have changed.

I dabble a bit using Nixos to build old software and it's great for that. I can 'cd' into one directory and the C and C++ compiler automatically change to the version required for that piece of software. If I change to another directory for another piece of software that needs a different compiler version then the change happens automatically.

If I find I need a tool in both directories then it is a simple matter to edit the config spec for the directory and go back in again. If I want something globally then I can edit the config that applies to the whole machine.

The main downside is the long learning curve to understanding the declarative config approach. :-(

[Teal Bee]

Re: Home directories

>I can 'cd' into one directory and the C and C++ compiler automatically change to the version required for that piece of software.

direnv is a wonderful program that does just this for bash. It needs an .envrc recipe in any such directory, or at least one of its parents, for it to work.

I don't know if Nix uses direnv, but it sounds very similar.