@lanodan @erincandescent @danderson i have plenty of those

"create an ssh tunnel once online"
"swap the http proxy settings once connected to VPN X which has a route to Y"

and currently they use a bunch of wait-for-online stuff that is not really nice and too many busy loops

@danderson i'd kinda kill for something like systemd directives that does pass the socket

"StopWhenUnroutableTo=0.0.0.0/0"
"StartWhenRoutableTo=0.0.0.0/0"

etc.

but unsure where is the right design and what direction should we go

@navi @danderson well, in practice, posix compliance is often shoved in the throat as a reaction which prevent other people to depart from posix compliance to explore other APIs?

it's not meant as a snark that posix is an absolute bad thing but i concur with the end of your message, people do take it as an absolute and this is what is bad

@navi @danderson i feel like we are talking about something else now

things like the Android model are such a departure of the posix model that it seems quite unplausible that we will get there while pushing around the posix model to get there

what realistic and useful value do we have to keep the posix model as a beacon?

@solene do you have a pointer or some contact?

@solene on QubesOS matter, would you happen to know if there was already attempts to run QubesOS pieces on a NixOS-based system (not NixOS as a guest VM)?

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