RaitoBezarius

I'm part of the sysadmin team who studied the migration paths for the Dendrite in question in this blog post and unfortunately as a volunteer it's hard to find the time to invent migration paths (even if we have the knowledge) and make it happen while there's also many other needs unaddressed elsewhere.

Given that you seem expert in the matter, would you like to help and own the migration? That'd be awesome!

> The security team is composed of unpaid volunteers who work on numerous time-sensitive projects simultaneously. You may not be aware, but since a group of maintainers and contributors left earlier this year to form their own fork called "Lix," there have been many vacant positions across several Nix teams.

This is not true, there have been many vacant positions across several Nix teams because the original project has been unable to keep these people. When challenged about this inevitable situation of depleted labor, the answer of people involved in leadership was, "It's OK, we will have new people joining us anyway.".

Lix has been trying to connect with the Nix maintenance team, with very timid results from the Nix side. We continue to hope this will lead to a better cooperation.

Also, you say that they are "unpaid volunteers", the Nix maintenance team is composed of folks who have full-time responsibilities in VC companies who sells Nix-based products.

Tvix is compatible with Nix, thus it follows the /nix/store/$hash-$name naming scheme.

(Tvix developer here) 2 years after, Flakes are still what they are, IMHO, a pile of layering violations.

I do not see a path forward for them in Tvix before we get to fix them layer by layer, which Nix is trying to do (slowly?).

At some point, once we stabilize a bunch of things, I have some plans to do what I call the right design of Flakes, but it does not involve modifying completely the core of the interpreter to leak this implementation detail everywhere, but more make this a library concept.

Tvix developer here; Tvix is quite different from Nix and is a clean restart, in my humble opinion, it would be quite hard to integrate some features of Tvix in the current Nix because you have two targets: (a) getting the feature in the existing architecture of Nix (b) evaluating a good architecture for the feature itself in the ideal architecture.

Tvix developer here; we do have Windows in mind. Rust makes a bunch of things easier regarding this, but _not everything_. It's not a priority.

The location of the store is not really the main blocker in those sorts of situations, IMHO.

Tvix developer here; correctness is still not guaranteed, there's nothing to use here except if you already understand well Nix concepts to pick parts and build stuff on the top of it and accept the inherent instability :).

Not ready, so not a good reason to use it yet.

I moved to npins which has slightly more features that niv.

But niv has been great, I wish we can have patching natively so all my tons of patches can be bolted on faster.

For example, Flakes have no concept of cross compilation and makes this use case extremely tedious to use.

Flakes were a RFC then merged as an experimental feature and shilled too much to the community to the point they are now a quasi standardized feature even though they didn't go through RFC and therefore ignored all the valuable feedback.

This whole debacle made a lot of invested people tired on both sides.