In the wake of the recent Glibc API breakage fiasco, I'm left wondering why Valve cares so much about upstream Glibc breaking the API? As far as I understand they are deploying the Steam client on Flatpak.
Do the games/anti-cheats installed by the WINE living inside the flatpak escape the sandbox and use host system's Glibc? Otherwise why would EAC break?
Personally I use flatpak and never experienced any breakages in Elden Ring recently. Or ever, for that matter.
Other urls found in this thread:
phoronix.com
anyforums.com
twitter.com
Valve only provides a .deb file, everything else is unofficial.
bruce the australian sex offender that was banned from reddit forgets:
> bloated as all fuck. hundreds of megabytes for small programs
> no security at all
> implicit trust in -EVERYTHING- that's in the flatpak.
anything bruce3434 has to say about any topic goes straight into the trash. that user is an absolute low iq fucking loser that needs to kill himself.
>In the wake of the recent Glibc API breakage fiasco,
valve and associated trash should do the right thing and fix their shit instead of acting like fucking bitches and doing absolutely nothing except cry. they want everyone to work for them FOR FREE while valve etc. make billions.
>Otherwise why would EAC break?
laziness and incompetence.
>> no security at all
Flatpak is more secure than legacy package. See the picture.
>valve and associated trash should do the right thing and fix their shit
EAC does not target Linux. It's not their job. Valve does not have access to EAC's codebase. It's closed source.
>Flatpak is more secure than legacy package. See the picture.
see:
> anything bruce3434 has to say about any topic goes straight into the trash. that user is an absolute low iq fucking loser that needs to kill himself
you must be new to this website and aren't familiar with this ultimate failure of life? sad.
> It's not their job
> as they cry about how it broke
truly amazing levels of cope.
This guy must have given you some kind of weird PTSD. What happened?
>truly amazing levels of cope.
Not an argument.
Flatpak is not secure at all
Imagine the dll hell problem on windows
Softwares using a version of a lib that has a major security problem, how feasible would it be to the owner of the flatpak do something about it?
It will be the same as windows, billions of users using something that has a major security problem and an exploit that everyone knows about, not even counting the 0 days
Compare that to Linux where every package is updated along with the security problems
>why Valve cares so much about upstream Glibc breaking the API
because they've made the genius decision to base their distro on fucking Arch, like it wouldn't bite them in the ass
Modern build systems already warn the developers about potential security issues. What flatpak does is an added layer of security so if User 1 installs an app with vulnarable library, user 2 will not be affected, because flatpak apps can install per user, whereas legacy packages install vulnerable libraries globally which sits in /usr/lib
>muh bruce muh bruce muh bruce muh bruce muh bruce muh bruce
>muh bruce muh bruce muh bruce muh bruce muh bruce muh bruce
>muh bruce muh bruce muh bruce muh bruce muh bruce muh bruce
>muh bruce muh bruce muh bruce muh bruce muh bruce muh bruce
>muh bruce muh bruce muh bruce muh bruce muh bruce muh bruce
>muh bruce muh bruce muh bruce muh bruce muh bruce muh bruce
The thing is do you think the normies will care to update their software that has a major vulnerability?
User1 will keep using the install not giving a shit about it, just like it's in windows
It you think uac is secure you are too new to be posting here
>The thing is do you think the normies will care to update their software that has a major vulnerability?
Developers are not normies.
>polkit
polkit always existed
>valve should fix code it doesn't own and doesn't have access to
>btw we will break everyone else's code whenever we feel like, deal with it
This is your brain on loonix cultism.
but never enforced
...
I'm sorry how is it even possible to achieve anything similar to DLL Hell in Flatpak? It's literally sandboxed.
Every software on windows is sandboxed too
I'm talking about the library. It's sandboxed from the system and vice versa. Flatpak doesn't use distro glibc and distro doesn't use flatpak glibc.
There is no way for a flatpak app to override the distro glibc loaded into the memory. DLL hell is not possible in flatpak.
>inb4 how about two separate flatpaks using the same flatpak runtime
Permission denied.
Legacy packages can create dll hell though.
>the dll hell problem on windows
Literally does not exist
>wtf software might not include important lib updates!
Correct: software WILL NOT be maintained indefinitely, even when it's FOSS and there are maintainters that are supposed to do their job.
That's why sandboxing is necessary, to limit risk.
Also
>implying Linux is in any way secure when major distros knowingly ship packages years out of date
>he uses a fucking alternative OS but has to run a shitty clone of Windows because boohoo my alt OS doesn't have all my GAIAAEEMMMZ and PHOTOSHIT and other trash no sane person needs
Please, Microsoft, kill Wine. It's infringing on your IP and copyright even if it is a "reimplementation". It's still pretending to be Windows and they have to install tons of your fucking libraries still, a clear violation of your EULA.
I'm not letting this shit go until MS does the right thing. Fuck Wine. If Linux wants to be big, they need to stop pretending systemd and wayland is good, and they need to stop making this pseudo-Windows copyright violation be the main way people use certain programs.
>flatpak bad
>arch bad
>Linux bad
None of that is even relevant. The real problem is people still using glibc despite its inability to stay compatible across minor version updates.
from phoronix.com
>The breakage stems from the DT_HASH section being dropped in GNU C Library
>EAC being among the few software still expecting that section rather than DT_GNU_HASH.
>DT_GNU_HASH is better structured than DT_HASH although DT_HASH for ELF object hash tables for run-time symbol resolution
>DT_GNU_HASH has been around for a decade and a half
>Most Linux distributions and open-source software have been happily using DT_GNU_HASH for years.
so, basically EAC uses DT_HASH instead of DT_GNU_HASH, reasons for that are unknown but i assume that reason is "it ain't broken, i ain't fixin' it"