I'd guess it's because of the general attitude of the project's community, specifically GNOME people and their “my way or highway” style of answering questions e.g. about CSD or other non-critical stuff, not directly related to core protocol. If they were a bit more accommodating to reasonable requests from outside, they'd get less backlash in comments. There's plenty of exemplar behaviour elsewhere in adjacent communities, they could have taken hint multiple times.
That they provide this stuff for free would be a good argument if the stuff wasn't pushed down people's throats with no working alternative and Xorg being discontinued.
And how would they be able to "push stuff down people's throats" if people could walk away towards alternatives? When such alternatives don't exist, that's exactly how "they do stuff for free and nobody else is putting in the work to make something else" looks like.
The problem isn't they "pushing stuff down your throats", it's nobody else (including you) making alternatives that you like better. You are voluntarily ingesting their stuff because your only alternative is starving.
> And how would they be able to "push stuff down people's throats" if people could walk away towards alternatives?
It's a forcing of their narrow opinion on what should be allowed onto the ecosystem at large, because all of these things are connected. You can leave to a different DE/distro, but if every DE is doing its own thing for global hotkeys or whatever, then software in the ecosystem is going to be hacky/bespoke or have an unreasonable maintenance burden.
Even if you in particular can move elsewhere the ecosystem is still held back. We only recently got consensus on apps being able to request a window position on screen, which is something x11, macos, and windows all allow you to do. CSD and tray icons are other examples of things found everywhere else that they did not want to support. Some applications are just broken without tray icon support.
This bleeds over into work for folks releasing software for Linux in general. By not supporting SSD they were pushing the burden of drawing window decorations onto every single app author, and while most frameworks will handle this, it's not like everyone is using qt or gtk. App authors will get bug reports and the burden of releasing software on Linux needlessly climbs again.
Hard to convey how unreasonable I feel their stance was on tray icons / SSD. It should be the domain of the DE from a conceptual but also practical point of view, even from just the amount of work involved. It reminds me of LSP's enabling text editors to have great support for every language. And again, Gnome was the odd man out in this, they want extra attention and work when Linux is the lowest desktop marketshare by far, and they themselves are not the overwhelming majority but they are large enough that you really do need to make sure your software runs well on Gnome even if you want to support Linux.
People think Gnome push stuff down your throat because they have the power and influence to impact the ecosystem, and they use that power and influence to die on absolutely absurd hills.
I dunno, I think tray icons support is kind of the absurd hill to die on. They're a Windows 95-ism and generally extremely horrible in terms of usability. Apps use them and desktop environments support them mostly out of a lack of imagination, and they are frankly extremely overused.
I'm personally a KDE user, but I'm with the GNOME folks on this one.
They may have been introduced in Windows 95, but they didn't actually become particularly common until years later. They weren't originally intended as a long-term feature and, in Win 2000, Microsoft started recommending that people use custom Control Panel objects or MMC console snap-ins instead. But the MMC wasn't an option in Win98/Me and, by the time MS finally managed to produced a consumer variant of NT, use of the system tray had become entrenched.
I'm not sure what Windows is like these days, but in MacOS they're patently absurd. My corporate Mac laptop has twelve of the fucking things, and I've never actually had genuine need to click on any of them (and 5 of them are from Apple and so of course use 4 different corner radii between them - the 3rd party ones are at least a little more consistent).
Not OP, but that post clearly was alluding to Hitler coming to power democratically. That they don't need to worry was a very dark joke. Anyway, it's just history.
There are more recent examples in Europe, like Putin, Orban and Vucic. All of them got elected fairly, and all of them engaged in the process of slowly but surely breaking democratic institutions and checks and balances down. The guidebook is actually exactly the same. Putin is now 25 years in power, Orban 16 years and Vucic 14 years.
You could say that those Eastern European democracies were fragile to begin with, but what MAGA is so far very much successfully doing is fully matching the existing proven guidebook.
If Polymarket were legal in my country I'd actually consider betting on it.
If they wanted, they absolutely can distrust LE. The trick is to distrust only certificates issued after specific date (technically: with „NotBefore” field after specific point in time), so the certs already issued continue to work for the duration of their validity (until „NotAfter”). That way they can phase out even the biggest CAs. Moreover, they have infrastructure in place and playbook well rehearsed on other CAs already.
Even then, is the message "stop using chrome after this date because half the internet will break" (because where will all those non-paying people go to?), or "stop using LE and start paying someone for a free service"?
I bet google themselves would be scared of anti-trust lawsuits over this. Even if they weren't, i don't think they'll really go so far as to compromise the security of half of the internet just to get their way on this one small improvement.
The point about antitrust lawsuits I concur, but LE is not the only free-as-in-beer ACME. For one, there's ZeroSSL, then Actalis, SSL.com. For some time BuyPass offered free certs, but it does no longer. Last but not least Google itself has Public CA that offers certs over ACME, a fact that I think would be a huge fulcrum for antitrust suit. I would also expect that all other CAs would deploy ACME endpoints to attract at least some part of the cake (note they're in business of being vultures already). So the message will be „go find another CA, here are three examples, sorted randomly like the European first boot UX, just change the URI in certbot config".
Perhaps this shouldn't be left to the CA/B board, it has critical economic impact on many countries, it should be regulated by them?
Either way, I think LE has enough power to at least push-back and see where things fall. continuing to support users can't hurt them, until they truly have no other choice.
> [...] it has critical economic impact on many countries, it should be regulated by them?
This was exactly the point of recent (2024) eIDAS update, which introduced EU Trusted Lists. The original draft was that the browsers were mandated to accept X.509 certs from CAs („TSP”s) accredited in EU by national bodies. Browsers were supposed not to be free to just eject CAs from their root programs for any reason or no reason at all, but in case of infractions they were supposed to report to CAB or NAB that would make the final decision.
Browesers responded by lobbying, because the proposal also contained some questionable stuff like mandatory EV UI, which the browsers rightfully deprecated, and also it wasn't clear if they can use OneCRL and similar alternative revocation schemes for mitigations of ongoing attacks. The language was diluted.
Interestingly though, doesn't this threat become less credible the shorter certificate lifetimes get? Back in the day they could just do this and server admins would figure out how to switch to a new CA the next time they got around to renewing their certificate. Now though that's all automated, so killing a CA will likely nuke a bunch of sites.
This is good point. I think it would still be discounted in favour of suggesting another CAs that users can switch to, but you're right, the promise was that cert management would be hands off, and changing CAs is not hands off in any ACME client that I know of. Best Google could do would be to shift the blame to LE/ISRG, because it was ISRG that promised this automation.
They can do this with certificate transparency other wise CA can sign whatever date they want. But if they collude with CT that can issue rouge certificates for targeted attacks.
Yes, that's all right, there's already a requirement that they submit to one Google CT log and one non-Google CT log. They thought about it already. The playbook I mentioned they've been rehearsing contains specific threat against backdating certs, they say they'll distrust immediately if they detect, and they have means of detecting backdating on significant scale (esp. for LE, where they submit 100% issued certs, not just the subset that is intended for consumption with Chrome).
No, of course not. They want to also measure response in the physical aspects (like electricians thot would have to drive some time to arrive on site). They're testing end-to-end, so to say. There's no testing like testing in production.
The traditional Polish categories of sorting rubbish is „to the burner” and „to the forest”, optionally „to be burned during the day” and „to be burned during the night”.
Fyi a lot of the unrecyclable waste is burned in other countries too (like most plastic types) but it's done in special facilities with proper filters installed
That they provide this stuff for free would be a good argument if the stuff wasn't pushed down people's throats with no working alternative and Xorg being discontinued.
reply