RaitoBezarius

Hi (Sécurix developer), we wrote our documentation in English and in French: https://cloud-gouv.github.io/securix.

Maintaining both languages is hard but we will do our best.

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!

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 :(.

Good luck with your product!

> 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.

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.

Disclaimer: NixOS developer, 23.05 Release Manager.

It is also probably impossible given some sources completely disappeared.

Did you mention sandboxed builds? Actively preventing pip to execute code arbitrarily at install time? Same for Node.js?

I cannot live without that anymore, that's the new golden standard.

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.

Tvix has no builder yet.

Nix. :-)

Flox has some solution for this.

Other than that, this is being worked on :).

It really is interesting.

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.

No you cannot fit their whole tree of dependencies, their semantics and their failures modes in a single HN comment.

People use basic tools because they have much more understandable semantics, everyone do not need a gigaton pile of Go code to deploy something.

You can use something like Nix or Guix for example.

Bonus: it produces OCI images also.

I definitely not believe that Docker images are boring, they are full of constant issues and stuff you have to keep track on the top of the fact they are not composable in many ways.

Rootfs is the boring technology, their semantics is clear and most kernels have support for them.

Better: use systemd which has became truly boring and restarts your services automatically and if you don't like systems, plenty of alternatives such as s6 do exist.

Well, Guix is also mentioned when someone talks about Nix, seems fair to me (and of course, Guix may be more relevant sometimes!).

Then, you had disaster recovery plans, you devised a strategy of what is an acceptable data loss, execute the reconstruction plan on the new big server, under some hours, the new big server is up again. You apologize, offer some financial compensation, etc.

And you learn from the situation, understand what are your new tolerance for data loss, failures, etc., then start new plans accordingly.

I'm tired to read this as if it was impossible.

> How do you implement healthcheck?

Most applications implement a simple endpoint which returns a known answer (whether it's an HTTP 200 code, a banner, etc.) You can just hit this endpoint using your favorite tool.

> Does the loadbalancer know how the healthceck is implemented?

Well, a lot of tooling supports native (periodic) healthchecks, e.g. NGINX or NGINX Plus (if you want to pay something else than managing K8S).

> How do you determine it's time to scale?

It is not that expensive to run performance monitoring such as netdata, sometimes, it is just a call to your distribution package manager, put it in your intranet, then you're done.

> How do you implement always-on-process? service unit, initd, cron?

Depending on what you're using in Linux distributions, why bother with initd and cron if you're running on a systemd-based distribution? Just use unit, timers, service, scope, slice and so on.

> How do you export the logs?

Again, if you're using a systemd-based distribution: `man systemd-journald-remote`.

Otherwise, Loki, rsyslog, many solutions do exist for these scenarios and do not require that much fancy configuration.

For mono-nodes, I would argue that the null logger exporter, called: "rsync your logs somewhere", is quite efficient.

> How do you inject configs? /etc/environment, profile.d, systemd config, /etc/bestestapp/config?

I do not even know why people worry about that. If you're using a systemd-based distribution, your configuration should live more or less in the service unit using Environment, EnvironmentFile and LoadCredential(Encrypted), if your app want some files, sure, put it in /etc/xxx or /var/lib/xxx/config.

As long as you do separate configuration from state (and use StateDirectory, etc.) and you do backup them, it is okay.

> What about secrets?

As said earlier, LoadCredential do the job, if you want to be fancy, you can run a UNIX socket server to distribute the secrets and some secret engine such as HashiCorp Vault.

Uncertain that K8S has a better story than that.

> Service discovery? Is unbound/bind9?

Uncertain you actually need service discovery in early stages. Assuming you need, you could run envoy if you have advanced needs. Or you could run PowerDNS/nsd/unbound/BIND9 as you said with a thin wrapper to register your services.

> And on and on and on and on.

Well, I do not agree, those are items you choose. Not everyone has these requirements, and not everyone needs to solve them the k8s way.

> These items are best done in a standard way. That's a major selling point in k8s. You define and implement these in a consistent way that also integrates seamlessly with other tools. Doubly so on cloud. Less reinventing the wheel means less money. The more teams, the faster this becomes exponentially expensive. Take this into consideration before your next interview.

That is a fallacy, k8s is not a standard way, they push for their standard way and it is in no case what everyone is doing.

Defining and implementing thing in a "consistent way" is something we have been doing for a long time before k8s, through standardization process with IETF and W3C for example. k8s creates its own world, and it is indeed compatible with the external world sometimes, but I do not believe that a pile of complexity on the top of YAML files and YAML manipulation tooling is a "consistent way" to define and implement things, no offense here.

> Doubly so on cloud.

Yeah, because the "cloud ecosystem" is pushing for this, but it has not been a standard.

> Less reinventing the wheel means less money.

Using a "simple feature" is not reinventing the wheel, but if we go this way, I have a challenger: NixOS. Just reuse their expert modules database and do your classical YAML stuff, but this time with a simple functional programming language.

> The more teams, the faster this becomes exponentially expensive. Take this into consideration before your next interview.

I think GP was discussing of an early stage and I do not think that all teams require to push at a very fast rate, there is definitely time for packaging and shipping it. BTW, in these organizations where I have worked, they adopted k8s and these "teams" could not use it because it was too complicated and wondered where their packaging team has gone.

There is no silver bullet and choosing a deployment platform stack is not a figured out science, but there is a lot of value of choosing composable and simple tools before moving to more integrated ecosystems.

> Take this into consideration before your next interview.

That is an amazing level of arrogance, I only hope you may accept there are alternatives. :)

Ha, that's something I was working on and I had a little proof of concept with Aleph.

Sure, 2% (1765MW) of France's production is coal at the moment.

It does not matter that plants are in maintenance, that is the normal state of complex systems like nuclear plants and a very desirable one. Sure, we could do better and close the last two coal factories to get 0% of coal modulo imports. That is still very different from 0% of nuclear. :)

Sure, at the time of writing, 62% of France's production of electricity is nuclear.

We're importing 9392MW also.

Non profit does not mean that it do not have to pay taxes on the money it manipulates.

Non profit orgs receive services from the state and they have a cost to fund social security and such.

Other non profits which do not have a very nice situation can receive help from the state, so why not share the bits of success of Lichess to everyone else?