The name, the logo, the values and many important strategic decisions seems to have already been decided, before a public channel of communication has been created.

Was this created by just you, or is there already a team?

This page was created by me. I have tried to capture what I feel are important values that are hopefully shared by others who are leaving or have left Nix. With the values, goals, and roadmap clearly stated, others can join to contribute. Part of the reason I felt this was important was to make sure that anyone who would want to contribute did not feel like there would be some rug pull moment. I wanted to outline exactly what was going to happen and how it was going to be better than what we have currently with Nix so that we can build that vision together.

As much as I think they overreacted when banning you, it also feels like an overreaction to fork that soon.

I hope a compromise will be found, and that you'll be back on NixOS as soon as possible!

NixOS uses a monorepo and I think everyone loves it.

I love being able to easily grep through all the packages source code, and there's regularly PRs that harmonizes conventions across many packages.

Nixpkgs doesn't include the packaged software source code, so it's a lot more practical than what Debian is doing.

Creating a whole distribution often requires changes synchronized across many packages, so it really makes things simpler.

https://github.com/NixOS/nixpkgs

I think it's important to add that they both have the biggest number of packaged software and the most up-to-date software of all distributions even though they have far fewer maintainers than Debian.

https://repology.org/repositories/graphs

Is nixpkgs really a monorepo as usually discussed? It's got packages, os modules, and some supporting scripts. Nix itself lives in a different place, so does the RFC planning, system artwork and a few other things. I would expect it all together to become a monorepo.

> even though they have far fewer maintainers than Debian.

Debian has ~1.5k contributors, nixpkgs lists >3.5k maintainers. (Although that list is not pruned over time)

> Is nixpkgs really a monorepo as usually discussed? It's got packages, os modules, and some supporting scripts. Nix itself lives in a different place, so does the RFC planning, system artwork and a few other things. I would expect it all together to become a monorepo.

I think we can say it's a monorepo of packages in this context. Not everything from the Nix ecosystem is there. It could also bundle the website, wiki, doc etc but I don't think it matter too much.

> Debian has ~1.5k contributors, nixpkgs lists >3.5k maintainers. (Although that list is not pruned over time)

Thanks for the info, I heard that a long time ago and never checked myself! It's probably less as you say but still probably bigger than Debian.

I guess it makes sense because it's so much easier to contribute there than to Debian.

> Nixpkgs doesn't include the packaged software source code, so it's a lot more practical than what Debian is doing.

This is the key difference. OpenWRT is a “monorepo” too, but it downloads tar balls etc of the upstream software. Makes sense.

Putting the source code of the upstream software in a monorepo sounds like a nightmare…

> I think it's important to add that they both have the biggest number of packaged software and the most up-to-date software of all distributions even though they have far fewer maintainers than Debian.

Only because of https://www.reddit.com/r/NixOS/comments/zp95a2/comment/j5ko9...

I also had plenty of issues with either packages not being available or not building, last I tried. At least with the AUR, it's generally only the latter you have to worry about ;)

Yeah, automation in Nixpkgs is crazy and goes far beyond any other distros (that I know of).

Why spend manual time when it can be automated?

But you can use `envfs` to "restore" that compatibility ;)

Or something heavier like `steam-run`

or `podman run -V "$PWD":/mount debian /mount/myapp` if you want a really heavy fix.

Packaging for nix isn't as hard as it might seem so I've found it easier just to do it the 'right' way.

I end up just using patchelf since getting the alternatives working is harder. I would prefer if NixOS is going to give up on moving everything into /nix that it just makes symlinks in the standard paths so users don't need to find something to do it for them.

With Guix we use `guix shell --container --emulate-fhs` to temporarily wire things up to their expected locations:

https://guix.gnu.org/en/blog/2023/the-filesystem-hierarchy-s...

I have thought this, too. But if that includes libraries or even stuff that would go under /usr/share, that could cause breakage on NixOS updates for software that expects specific versions of things at those paths.

This is probably less of an issue for executable paths, but if people really expect to be able to ./configure && make on NixOS, NixOS needs to have a whole different release cycle. Ideally you'd probably still want atypical prefixes, if just like `/usr/1.0/...` or something so you could have multiple releases (and software compiled against them) live side-by-side.

I think that could work really well, but it would be a huge maintenance burden and there's nobody up for it right now. And it would still involve some of the pain we currently have with unusual filesystem structure.

I have been using ZFS as root FS since the first release of ZFS on Linux (2013) on all my machines (laptops, NAS, server) and I can't imagine going back.

What are the advantages of it on a laptop. Do you have more than one drive in it?

I honestly use ext4 for everything based on ignorance and familiarity.

It’s actually quite useful for laptops.

Checksums if the mobile hardware is damaged, snapshots if you delete something in your daily driver, native encryption if laptop is stolen, backup of work data via ZFS send if you have a ZFS server, compression to use limited disk space in laptops, errors can be fixed with copies=2, etc.

I allocate all my SSD space to one ZFS pool and then:

- I can easily create new subvolumes (filesystems or block devices), for different mount points, containers, other distributions, VM disks...

- The free space is shared between all of them, no need to anticipate a partitioning layout

- I have a service that automatically snapshots some of them, others not

- I love the ZFS tools, I'm very happy to use them on all my machines

- I use NixOS everywhere and so it's also easier to share the same conf on all my machines

- I can send volumes easily from one machine to the other (zfs send)

I probably miss other things, but I also love consistency ;)

ZFS still gives benefits with one disk. Ignoring the data integrity stuff (which is better with ZFS even if you have no ECC), you also get snapshotting, potentially boot environments, you can backup your data to another machine using zfs-send, you get native encryption (including encrypted backups for free), highly performant compression, and (depending on your system) a nice memory cache algorithm.

On my FreeBSD Thinkpad X220 there are two SSDs running a ZFS mirror. Why? Why not!

Why shouldn't it be a valid opinion to not like cryptocurrencies?

And to not want to contribute?

Why is not ok to prefer money regulated by the rule of law?

Moreover, I have no idea how I could help with the problem of recovering stolen cryptocurrency/NFTs or lost private keys.

How is it different from using Clang's CFI (control flow integrity)?

I thought this was the same technique used in webassembly.

Chromium is using this too i think

CFI helps with control flow exploits, but it doesn't prevent memory corruption for example.

This sandboxing technique ensures that both control flow and memory accesses remain in the sandbox (except for when you explicitly allow otherwise).

To be fair, when sending a Pixel for reparations, Google very clearly and explicitly asks to factory_reset the phone.

I personally didn't reset it when I sent my Pixel 3 to fix the charging port because my Pixel was fully encrypted.

All Pixels are encrypted by default as long as you have any kind of lock method enabled (PIN, password, shape...).

I don't really understand how this person got his files in cleartext and accessible.

Another comment quotes:

  > About a month ago my wife broke her pixel phone. It couldn't be turned on so
  > we couldn't wipe it. We contact Google and used the device care to get an RMA.

In this case, the phone would not turn on prior to repair and could not be wiped.

How did the person conducting repair power it on and unlock it then?

Edit: I mean how did they bypass the lock screen?

Sometimes letting the battery drain completely will clear a hung phone (which is like the old "take the battery out for 5 minutes, then try it again" trick). Or the service center knew the magic buttons to press to get it to boot. Or the battery was bad. Or one of a million other reasons that a phone can fail in a way that makes it appear dead, but a service tech knows how to get it running.

They repaired it, presumably.

>All Pixels are encrypted by default as long as you have any kind of lock method enabled (PIN, password, shape...).

No lock method?

That's what I think. Either no lock method, they're lying, or there's an unknown exploit or backdoor. Either way I'd be interested to know the outcome of this. As a Pixel user it's concerning.

by repairing it

They probably fixed it first

maybe no password?

That's the sort of confidence I get from the DMV, they require you to pay by check beacuse the person issuing IDs with all our personal information can't be trusted with nine dollars in cash.

My impression from the (now deleted) text is that the phone wasn't booting or in a state where it could be factory reset, at least not without considerable effort.

It is possible the victim made some bad choices. It does not make it fair for Google employees/contractors/whatever to violate their privacy and access their personal information, then post it online.

If the phone does not turn on, I guess I could "wipe" it by opening it up and drilling through every chip I can find. Google would have harder time repairing it then but that's their problem ;-)

"Any optimization you could do in Rust is probably easier in C++"

I think this feeling comes from the fact that it takes longer to learn the basics of Rust compared to C++.

However, once one has learned C++ or Rust to a reasonable level, I would argue that Rust is actually easier to use.

This is not the same thing but many people make this claim.

Each is easier than the other, depending on where you look and where you come from.

But it is a fair bet that changes to C++ code to implement a point performance optimization will be smaller than the same sort of change would be for Rust code. For the latter, you are likely to need to re-architect that part of the system some to get your optimization and still satisfy the borrow checker. Having a borrow checker that demands satisfaction is a virtue, but there is no denying it adds cost in the small, where we're talking about, notwithstanding that such cost may be paid back at the system level.

> it takes longer to learn the basics of Rust compared to C++.

Does it really? For example I'd think that initialization of objects is a topic that should be in "basics", yet initialization of objects in C++ seems disproportionately complex compared to Rust (at least to me).

Yet, object initialization is not a thing anyone needs to pay much attention to. Yes, there are historical rabbit holes, but you need not go down them.

> object initialization is not a thing anyone needs to pay much attention to

So it's perfectly fine for me to leave objects uninitialized because of lack of attention?

It's perfectly fine to initialize them in the simplest and most obvious way.

Having read a great deal from him, I just want to confirm everything said about Andrew Gallant, and I absolutely trust him too!

This blog post is a great testament to his human skills: https://blog.burntsushi.net/foss/