I’ve read that page, but that reasoning went over my head. Because I’m not able to understand their justification, hence I’m asking about it. And besides, there’s no other low-level Vulkan alternative. Dropping support for it would be detrimental to the future of their distro, given how there’s improvement over OpenGL with respect to performance.
Their justification is batshit for the seven dropped packages I read. I haven’t seen all of those various talking points together in a single place before. It’s a “who’s who” of every crank idea from the last couple of decades. I’m genuinely surprised they don’t drop support for themselves given their social bloat.
scummvm is not compatible because it "implements engines just as interpreter instead of a full possible reimplementation“
I’m especially loving the on hold section:
Inkscape is out because it started offering an option to choose a preset resolutions for a new image including resolutions for non-free sites like facebook. They claim that a patch wouldn’t somehow fix this issue.
They go to the trouble of patching the logos for github and oculus out of neverball (oh no, non-free logos), which makes their argument about inkscape even funnier, as I can’t imagine resolution presets to be deeply embedded in the codebase.
That said, they lay their logic out pretty nicely. It seems meant to be super opinionated, with extremely rigid rules they stick to in as binary of a fashion as possible to keep things managable for the small group maintaining the OS project.
It’s their small project, they’re allowed to be opinionated. At least they’re open and straightforward.
“Hyperbola is not opposing a diverse and colorful software-landscape! […] It sounds harsh when we need to mark a package being set on hold […] This has nothing to with any kind more fanatic perspective as it is just following a simple and also direct logic.”
We’re still free to laugh at the unadulterated idealogical purity shit they’ve built as their logic though. Deus Freedom Vult
They don’t seem to care that much about performance unless it means reduced powet consumption.
Looks like their main reasoning for dropping vulkan was: 1. it has too many dependencies, which violates their principal of minimalism, and 2. it’s not backwards compatible enough for their arbitrary definition of backwards compatibility. I guess it should support hardware back to the very first gpu, but also have less dependencies
I’ve read that page, but that reasoning went over my head. Because I’m not able to understand their justification, hence I’m asking about it. And besides, there’s no other low-level Vulkan alternative. Dropping support for it would be detrimental to the future of their distro, given how there’s improvement over OpenGL with respect to performance.
Their justification is batshit for the seven dropped packages I read. I haven’t seen all of those various talking points together in a single place before. It’s a “who’s who” of every crank idea from the last couple of decades. I’m genuinely surprised they don’t drop support for themselves given their social bloat.
Some of this reads like pure satire:
I’m especially loving the on hold section:
That said, they lay their logic out pretty nicely. It seems meant to be super opinionated, with extremely rigid rules they stick to in as binary of a fashion as possible to keep things managable for the small group maintaining the OS project.
It’s their small project, they’re allowed to be opinionated. At least they’re open and straightforward.
“Hyperbola is not opposing a diverse and colorful software-landscape! […] It sounds harsh when we need to mark a package being set on hold […] This has nothing to with any kind more fanatic perspective as it is just following a simple and also direct logic.”
We’re still free to laugh at the unadulterated idealogical purity shit they’ve built as their logic though.
DeusFreedom VultThey don’t seem to care that much about performance unless it means reduced powet consumption.
Looks like their main reasoning for dropping vulkan was: 1. it has too many dependencies, which violates their principal of minimalism, and 2. it’s not backwards compatible enough for their arbitrary definition of backwards compatibility. I guess it should support hardware back to the very first gpu, but also have less dependencies