Corbin

As a relatively heavy solution, you can use a container orchestrator that understands a failure to pull an image as a temporary or transient situation. The lightest orchestrator that I've used on NixOS in a homelab is k3s:

services.k3s.enable = true;

It is more-or-less a cut-down Kubernetes, and as such it will not fail to start merely because one Pod had an error pulling one Image. It will also offer a path forward if you want to continue building up software-defined networking.

That all said, I'd re-examine what you want from service isolation during OS upgrades; it's possible for routine NixOS updates to only restart affected services and not reboot. In production, nixos-rebuild switch can do things like upgrade shared libraries, switch webroots, or flip feature flags. Containerization might be unnecessary overhead, and I say that as a Kubernetes proponent.

Become a kernel contributor first. I don't think it's acceptable to stand outside a community and ask how you can control it by throwing money at it.

Reading between the lines, the documentation has the key:

Generic instances … correspond to Semigroup and Monoid instances defined by pointwise lifting.

In more words: each generic type can be broken up into a tuple-like row of components, and the generic type admits a monoid/semigroup whenever every component in the row admits a monoid/semigroup. In your handwritten Semigroup instance, the given code is agnostic as to the types of variables and functions; all that matters is that they already have Semigroup instances of their own.

Let me answer the other question: where's the monoid in the generated Rep? Well, there isn't one! The Rep merely has a struct-like product of component types. If a monoid exists for each component, then a monoid for the entire struct exists (and is built from the obvious pointwise lifting!) but otherwise there isn't a monoid derived from the struct itself. This should be a notable contrast from generic instances for e.g. Functor, where every Rep has exactly zero or one Functor due to the algebra of the semiring of types (there is an underlying algebraic equation with at most one possible solution.)

Well, here is a very funny one-off commit, but my biggest effort was probably substantial parts of a couple AMD/ATI GPU drivers, well-summarized here. As usual, that was a team effort, with particular credit to Deucher (AMD), Glisse (radeon maintainer), and Airlie (DRM/DRI maintainer). So, put up or shut up. Or, to paraphrase the sentiment that you seem to not grok: talk is cheap; show us your code.

Let me make it clear. I call out brigading because it is useless noise that distorts and obfuscates the kernel development process. I don't care that you're salty that I'm pointing out that your "absolute crickets" comment is not only incorrect, but empty in the sense that your lack of perception is not a substitute for the actual process of kernel development. Additionally, in this case, it seems like you're still focused on personalities rather than the underlying computer science; I expect "absolute crickets" when asking you about the topic of memory safety.

CPython is still 3-4x slower than PyPy.

I expect you to have zero kernel commits to your name.

Be less of a TERF.

That's not a real apology. Be contrite -- what will you change in your life, going forward, to be less hateful?

Your argument is completely specious. Re-read that list. Assembly is a second language in the kernel already, and really it's multiple languages, one per supported ISA. Perl and Python scripts are used to generate data tables; there are multiple build-time languages. eBPF is evaluated at runtime; the kernel contains bytecode loaders, JIT compilers, and capability management for it. The kernel has already paid the initial cost of setting up a chimeric build process which evaluates many different languages at many different stages.

Martin's already in the list of maintainers for another subsystem; this is a territorial play by Hellwig. Any kernel developer would recognize this; you don't seem especially familiar with kernel social dynamics either! Also please fix your formatting if you're going to copy-and-paste rather than linking.

Whose arguments are you apologizing for? Read the thread backwards. Your claims about C and kernel policy were wrong, therefore @[email protected]'s point about multiple languages was right, therefore your main defense of Hellwig acting in good faith is unevidenced. So, are you still so ready to insist that Hellwig is arguing in good faith? Would you say that this thread has adequately discussed the technical details and is ready to return to the overarching political point?

I would recommend looking at English WP's style guide on weasel words. Rather than matching evidence and countering claims, you've set up a nest of strongly-held opinions with words like "basically", "personal experience", "I believe", "an opinion of course", "it isn't just me", and refused to actually directly engage with the evidence scrutinized. Given that it takes maybe five minutes to find even just one piece of assembly that has no justification for not being written in C, I think that it's fair to characterize your position as inconsistent with actual kernel-hacking practices at best.