911 karma · joined November 1, 2011
I think we are well past (1) but (2) could be mitigated by tighter controls on AUR accounts and potentially additional safeguards from AUR helpers. Maybe show a big scary warning if the package has changed owners recently. I know there will still be people that will "y" their way forward but it's better than nothing.
Or just avoid AUR helpers altogether and inspect/build the packages you need yourself from their PKGBUILDs directly.
Nothing about Android is open except the absolutely minimum amount of linux kernel that's required to boot the thing. Then it's blobs and restrictions all the way to the screen.
That being said, I'm not against removing features but neither this or the original post provide any substantial rationale on why it should be removed. Uses for XSLT do exist and the alternative is "just polyfill it" which is awkward especially for legacy content.
I'm afraid (2) will probably never work properly :-(
[0] https://gitlab.freedesktop.org/xorg/xserver/-/issues/1317
[1] https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests...
[2] https://github.com/NVIDIA/egl-wayland/pull/104#issuecomment-...
[0]: https://weasyprint.org/ [1]: https://www.princexml.com/
There are standards that have never been fully accepted by Mozilla [0] or WebKit (famously webusb for instance, because of security implications) but they are still in Chrome and now Firefox or Safari are effectively a "worse" browser because they don't support "standard" X that never reached consensus but Chrome implemented anyway. It always starts as an "experimental" feature under a config flag while the supposed discussion is taking place "just to see how it works, promise" before Google decides to remove the experimental flag and ship it. WEI started to play out exactly in the same way but given the massive outrage they decided it was too damaging to keep pursuing it (they still sneakily implemented it in Android WebViews).
So although I don't disagree that, yes Google has certainly improved on some things when it comes to standard processes they have abused their powerful position and continue to do so to push forward whatever they think it benefits them.
"There seems to be something wrong with your request, try reloading this page"
Good luck getting this ad infinitum you are on an environment that Google doesn't approve.
You do not and you cannot. It was written in stone once Chrome dominated the browser market. What Chrome (Google) wants, Chrome (Google) gets. Despite all the good engineering Google wants to sell ads, that's all there is to it. And the result is this proposal.
> The saving grace here might be that Firefox won't implement the proposal.
It's irrelevant and we are an irrelevant minority. Unless people switch to FF in droves the web is Chrome. And they won't because at the end of the day people just want to get home from their shitty jobs and stream a show. As long as that works everything else is a non-issue.
https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests...
Although definitely more technical than most distributions the perceived difficulty of Arch is mostly a meme at this point. The last large possibly-system-breaking change was almost 10 years ago [1]. And even then, the solution was quite trivial. Now if you are forcing updates that conflict without reading the news then you're in for a bad time, but that's true for all distributions. In general pacman is very conservative and won't leave your system partially updated. Now there is a chance upstream updates break things, but that's the nature of the rolling release model.
Manual compilations are not necessary if you stick to the official repositories. If you need a package in the AUR then a ports-like setup is required. I have packaged stuff for both RPM and DEB-based distributions, nothing really beats the simplicity and flexiblity of the Archlinux packaging tools.
[0]: https://archlinux.org/news/
[1]: https://archlinux.org/news/the-lib-directory-becomes-a-symli...