OH: "$out will deliberately contain no kernel images so that there is no way for someone's naive U-Boot jank integration crap to brick their mission-critical Sheevaplug powering 5 hospitals"

#NixOS

@dymaxion @whitequark @Di4na I take you are familiar with the CRA situation then? Do we share the same understanding of the CRA text and the fact that it *does* exclude quite explicitly OSS developers and so on, in various practical ways?

@dymaxion @whitequark @Di4na Right, but, then, I think we are maybe discussing two different things? Most OSS devs are not concerned by supply chain security, it's delusional IMHO to try to move the Overton window on this matter, at this point in time.

Commercial interests are in the range of the CRA and we will see how it translate into benefits for the overworked burnout OSS maintainers in the community.

Whether the signal is positive/negative shall guide where the Overton window move?

@rriemann @neo @Linux @eu_os isn't this disingenuous? you are comparing migrations to Linux and you are asking to an explicit migration to NixOS? it's not like your bootc thing was tried in public sectors?

either way, what Neo proposed was to use Nix and this was successfully used at the European Commission, Target, Shopify, Mercury and many more companies who document their usage of #Nix

even Google is using #Nix these days, so…

@rriemann @neo @Linux @eu_os

- https://shopify.engineering/shipit-presents-how-shopify-uses-nix
- https://www.youtube.com/watch?v=GkgsFbwYdYA (Google)
- https://flox.dev/blog/nix-in-the-wild-the-flying-circus/ (server usecases)
- https://monzo.com/blog/securing-our-software-supply-chain-better-with-reproducible-builds-for (server usecases)

and more here: https://github.com/ad-si/nix-companies

This is not an exhaustive list of blog posts, a Google search give you this pretty quickly, at this point, I don't understand if you are trying or you are just waiting for people to convince you of something, but then, I don't think you understand what you are talking about?

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