@icedquinn spontaneous freezes and lockups, insistence to make it required by everything, it's not easier to maintain, leaves services in failure state spontaneously, crashes services on its own, insecure defaults, unable to remove dnsresolver, sometimes systemd and associated programs modify their config on their own, dns 8888/8844 hardcoding, lack of modularity (made worse with dependency hell), Red hat crap, nsa/spy crap, everything poettering makes is crap, root should stay root, pid0 shenanigans, crond misfires, default insecurities, insecurities in general, cve list is enormous, NOTABUG WONTFIX crap, bloat bloat and more bloat, systemd and assorted poetteringware assumes and only supports one real configuration, making any attempt at modularity with linux a thing of the past, ssh insecurity and spyware... I'm sure there's more but I just remember dealing with this
@icedquinn a) systemd was forced down my throat b) systemd gave me enough bullshit issues over the years by reinventing wheels bady c) systemd has bad design decisions like auto-restarting things d) poettering
@slash i don't feel like wayland came with much rapidity. wayland to me feels more like people really wanted to use it, and were held back by it sucking, and it just eventually didn't.
systemd to me feels like it came on heavily by IBM fiat
@icedquinn I don't hate it, I even use it- but I am still wary of how fast it grew into the roles of other projects, enveloped their functions and made interoperability more of a headache. I feel that way about a lot of projects that behave this way- gnome, wayland, etc. I might still use them, but I don't like when there are too many of them it changes the nature of the ecosystem they're in. Sometimes those changes can be gamed by commercial interests as well, through the allocation and diversion of funding to nudge certain initiatives and starve others- and decisions like that can be made without input from or regard to the community too.
@slash freedesktop's egoism is certainly a problem. the mask off from "people just don't want to work on that" to clearly expressing an active desire to tank a maintainer was... something.
not real sad to see x go though. the BSDs haven't been anti-wayland per se either. its more the failure to provide a working event pipeline that has caused issues with porting that one
@icedquinn I agree with you- the way that wayland is similar is instead in the way that it's being used to starve X from continuing to exist- and that, too, is largely at the mercy of IBM, which is potentially a huge problem in the long term. Earlier this year when the Xlibre stuff started, it turned into a giant drama campaign suspiciously quickly, because it just started out as someone pointing out "my change commits to fix X code are being ignored, so I'll fork" which is totally ordinary behavior in open source. It very quickly snowballed into an attempt to stomp any continuation of X into the ground- and when you look at the plans to naturally drop X support, and how much time and effort is invested into Wayland, I get why.
I think its hard to ignore that through that funding and effort, there are multiple biases to keep in check. There's economic- you draw a paycheck from this work, you've spent years on it, your career or perceived expertise is kinda staked on it, you don't want to admit if early decisions out of your hands might've gone the wrong direction, or if something needs more work and will cost more money to the boss. Then there's also just the personal bias where you've committed so much time and energy, that it's really unpleasant to admit that something just isn't working still. So there's both an economic bias with the power of a company behind it, supercharged by the emotional bias of anyone who has committed all their time to it and just doesn't want to see that work go to waste.
That's kind of what I'm talking about- strong personalities deciding to do things another way and create solutions they haven't seen can be a great thing in open source, but at some point without care they can become a gear in an economic machine with attached interests that don't actually benefit the project it started as. When competition is healthy, and in particular when scope is narrowed and designed for interoperability with other projects, that is less likely to occur, so my bias is against projects seeking that level of influence/irreplaceability so quickly, or ever.