Recent searches
Search options
The level to which systemd stans demand you prove claims against systemd that you didn't even make as soon as they see you say something they interpret as vaguely "anti-systemd" is really astounding and impressive.
@dalias right, like, the really frustrating thing is that we like almost all of systemd's architectural decisions... and we do believe there need to be more people paying attention to overall ecosystem health stuff with Linux... but we don't like the clear hegemonic intent. BDFL is not an appropriate governance structure for something with this scope.
@irenes At least 75% of my objection to systemd is governance & unilateral imposition of policy.
@jbowen @RL_Dane @dalias as an anarchist, we want loosely-coupled tools not only because they're more likely to have enduring utility, but for ideological reasons. we have no desire to be dependent on any hierarchical power structure for something so fundamental as our creative expression, and we do very much treat computers as creative tools.
I think the distaste with projects like that is that it's a small group trying to impose their will (in often petty* ways) over all.
I don't get that feeling with the BSDs, even though it's literally one small group making nearly *every* decision about what goes into the OS.
*Gnome apps looking like gnome apps in all DEs and breaking my OS/DE/personal theming and USABILITY is petty AF. I don't care about your glorious vision, people, sit the heck down.
@RL_Dane @dalias @irenes also, it’s weird and fucking ridiculous that I have to maintain a large multi-service blocklist of systemd stans and red hat employees just to avoid being signal jammed with toxic nonsense every time I want to discuss anything negative about their ecosystem. this particular cathedral has already used its position to destroy our ability to effectively communicate, and I do resent that
".Ah. I had no idea it was about "Free Software" vs "Open Source."
I think the last 25 years have proven that the only thing you get by courting corporations is free stuff (nice, expansive codebases like the modern Linux kernel) and slavery (FOSS pimped out to corporate interests, the Linux Foundation completely owned and controlled by corporations destroying the heart of FOSS, etc.)
...
@FavoritoHJS @RL_Dane @dalias Yeah, that seems pretty hyperbolic.
@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.
@raito The only comment I made here about "user-hostile behavior" was in a subthread about dbus and tight coupling and my observations of the philosophy it developed out of, going back to the early 1990s. It's barely even related to systemd.
I could make "user hostility" complaints about systemd but that's not what I came to do because I've really gotten tired of that topic.
@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.
@dalias (and just to be clear, I do embedded systems, used musl, compiled systemd with musl, used s6, contributed to systemd and what not. I am not asking this in the void.)
@raito I don't want the softwares I'm running talking to each other. I want their behaviors to be predictable, tractable to mentally model, independent of what else I have installed/running. I want principle of least surprise. I don't want weird actions happening because I happened to plug in thing X and software Y that was running is interested in that. I don't want privacy spills from what I was doing in one app showing up in another. ...
@raito I don't want processes running as root to magically appear and become attack surface because some application I was running prodded a dbus address and dbus activation ran a daemon that happened to get installed as part of some package something else depended on.
@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?
@raito Nothing is preventing me from hacking out behaviors I don't want except time and mental energy.
The whole point was just drawing out that there is this big clash of philosophies underpinning these issues that's rarely examined.
@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 They seems to boil down to tastes and colors in system design and architectures. Yes, you eliminate classes of issues with yours, but you put under the carpet other things and retrospectively, the same can be said about the other philosophy.
@raito "Imposition of policy" was in a completely unrelated thread that has nothing to do with this.
It still sounds like you have stuck in your mind that this is supposed to be some sort of indictment of systemd that you're supposed to "accept as criticism". That is totally not the point.
@dalias Fair enough.
@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?
@raito You don't see how software avoids talking to each other. I don't see how it ever has a good reason to talk to each other in the first place. This is the difference in philosophy I was talking about.
@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?
@raito If you want an analogy with pipes, program A invoking popen("B",...) would be a very primitive form of the sort of coupling I'm talking about, but largely unobjectionable if B is just processing data and not controlling some persistent state.
The user invoking A|B is not a form this type of coupling.
But none of this is an argument about doing things with pipes. It's about whether programs are aware of each other & addressing each other with IPC/RPC.
@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?
@raito They're absolutely not of the form A|B. A|B is user-invoked or invoked by some script or controlling process that's neither A nor B.
A-does-popen(B) is the analog of the dbus shenanigans.
