Hello, we already have the name: http://lix.systems/. It'd be great if you would consider another name otherwise we will have to compete for the SEO and confuse a lot of our userbases :(.
> 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 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; 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 :).
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.
Honestly, we are an open source project, not a company. If we have the money, of course, we would prefer to spend it there and do better and more with it.
If this is threatening in a serious countenance, our growth and ability to conduct our project. I'm not sure if we need all the 9s of durability of S3, given that people already lost all their buckets on S3.
We do not have the money to store 5x or 6x the contents of the cache.
So we much prefer to have control, and we have enough skills to run all that shit easily, the problem is that the skilled people are in rare availability and are usually working on harder problems than running that. So ultimately, this is a balance problem.
Those benchmarks are wrong and misleading. Tvix contributor (but mostly reviewer I would say) here. We still don't have finished the integration with our own store, using the Nix store forces us to be slower than Nix, therefore the claims are bogus alas.
Tvix can *evaluate* a serious (?) chunk of Nixpkgs, but we have strictness bugs in some areas.
What was shown was the ability of systemd to have restart policies of units and the ability to load secret over some sort of Unix socket primitive. Plus, it does not even try to do topological sorts, it restarts everytime and accepts that its preconditions are false.
And basically as it can do that for any more or less untyped pile of resource, it is "flexible".
Sure, void* + a tag is flexible.
K8s is tiring.
Reconciliation is not exclusive to K8s, it's not the best system we have, not even close.
It is a particularly popular system with very specific choices, which has a nice property of assuming that state drifts therefore reconciliation is a must.
The annoying part is that: to show everyone else that K8s is complex, it is necessary to build a reconciliation based piece of software that compose well with the rest of the world and prove that you don't need K8s to achieve the same features that most people use, except if you are $bigcorp.
Alas, people have finite time and I do think it is quite clear how to build this using more fundamental pieces such as systemd and more.
Making this kind of article even more frustrating because I get the good intent of convincing people that K8s is not frightening and complicated.
I really feel there is a lack of theory and research definitions in this area of computer science. Rigor is missing.
Good luck with your product!