@civodul end to end integration tests, e.g. nixos tests plays a major role as well

@dymaxion @whitequark @Di4na I mean, I am aware of the ongoing legislation efforts towards making sense out of the computer ecosystem when it comes to liability question.

But I think it's pretty unrealistic to expect this to be figured out without at least multiple phases.

If some legal ecosystem decide to punish OSS maintainers, this is just going to affect the performance of that legal ecosystem at this point.

So I doubt that a stupid law would stay for too long, except in the US?

@alanc @dalias I'd imagine it'd be reasonable to modulo those generated files like the version / hash rev or would you believe more sophisticated executable generated file would be present?

@dalias I honestly cannot comprehend, this seems to have nothing to do with the tightly coupling that we are talking about? I don't see how two software avoids talking to each other if they have to. Are you thinking of having the kernel or other primitive intervening here? If you want predictability, it's probably necessary to frame it in terms of static or dynamic description of the system, no?

@dalias I feel like this is a difference in wording, no? Or framing?

Are you saying that two programs interacting via a pipe is a forbidden construction? Or is it an argument about how everything should enable you to control what you put in-between the pipes?

@dalias Yes, as it is that portals over D-Bus are kind of "A|B" in my opinion and distro shell scripts to make useful things out of non-systemd init looks like the popen coupling sometimes, but that's my opinion.

Maybe that non coupling design is not coupling, but it can become in integration because of the lack of various things. Conversely, the tightly coupling dbus is just a bus and you could reproduce A|B with APIs, no?

@dalias Still have difficulties to grasp. I can actually disable all dbus activation if I want on my system. Or have mathematical guarantees on such stuff. What is preventing your system integration to do so?

@dalias OK, that's fair. Nonetheless, I must point out that both philosophies have produced different results, whether you find that user hostile seems to depend on your definition of user (for example, you but not me). You talked about "imposition of policy" in another thread, I must say that conversely this sort of final opinion is also for me the consequences of "imposition of policy" unilaterally by like-minded thinkers.

So in the end, I find these arguments hard to accept as criticism.

@dalias I maintain a distribution that probably exercises more code of systemd than any other distribution out there, it's not beautiful, there's a lot of issues but what I don't really understand after dealing with the alternatives is that other people seemingly *not involved* into working with the object of interest doing weird over-intellectualization of system design to discuss abstract problems related to that ecosystem.

@dalias What I find fascinating is that the discussion always goes like this and I am still unable to find a satisfying understanding of that behavior beyond different tastes and colors and a strange feeling of reading FUD (about user hostile behavior).

But I would be glad to understand that I am completely wrong and missing the point and actually the problem is **concretely** X, Y, Z.

@dalias Fair enough, be it related to dbus or tight coupling, I am afraid I am still unable to grasp what point you are articulating *concretely* with that. I see mostly theoretical concern, not grounded in modern and actual blockers you might have encountered because I still cannot derive a concrete instantiation of what you are saying, applicable to objects I am familiar with.

@alxlg @zimoun @adamhsparks NixOS developer here, I think that OCI ecosystem has unfortunately no chance to give the practical reproducibility constraints that Guix (or Nix but whatever) can offer you.

I'd look at it from a social PoV, there's no incentive, no interest for the OCI ecosystem to offer this sort of feature because industry does not care about this sort of thing.

*wears tvix.dev developer hat* ComposerFS is inferior to better store solutions for large dataset too.

@tcltk @clacke @nixos @tcl interesting, how realistic Tcl can become a replacement for bash for building derivations and having phases, etc. ? (aka nixpkgs stdenv)

Did anyone try?

@tcltk @clacke @nixos @tcl but we use bash and we do have folks maintaining perl stuff and bash stuff

Though the question is really: what is the Tcl ecosystem? Is it still full of people, active development, can upstream work with us, etc. Which are very interesting and desirable properties.

PSA: https://github.com/NixOS/calamares-nixos-extensions/security/advisories/GHSA-3rvf-24q2-24ww

If you installed #NixOS using the graphical *Calamares* installer on a non EFI system with a LUKS rootfs or have any LUKS partition which is not a rootfs.

Your LUKS encryption key has been exposed in the /boot partition, potentially unencrypted or encrypted via GRUB cryptodisk.

We consider this to be a serious vulnerability and we are disclosing it immediately as it was found in the Heads project.

We are exploring automatic remediation in https://github.com/NixOS/nixpkgs/pull/240411.

@dansup On the 0.11.6 tag branch?