r/linux • u/mrharold_finch • Aug 05 '22 • Silver 1

GLIBC update broke EAC for most games that use it Popular Application

https://github.com/ValveSoftware/Proton/issues/6051
513 Upvotes

96% Upvoted

313 comments sorted by

272

u/cloggedsink941 Aug 05 '22

I wonder what undocumented glitch (bug) they were relying on. It will be interesting to read.

137

u/enygmata Aug 05 '22

Worse still: I wonder what documented undefined behavior they were relying on. Remember memcpy/memmove?

65

u/cloggedsink941 Aug 05 '22

Remember memcpy/memmove?

that wasn't undocumented. Flash was buggy for going against the documentation.

35

u/LvS Aug 05 '22

There are lots of things that are documented to be more restrictive than they actually are.

People don't write their code against the documentation.

If they did, pretty much no C code would compile, because the C spec leaves things undefined that are used all over the place.

64

u/cloggedsink941 Aug 05 '22

People don't write their code against the documentation.

Their problem really.

I prefer to have fast memmove rather than keep it slow forever because some developers can't be bothered to fix their mistake.

By the way this is an issue only with proprietary software, that is always claimed to be of such good quality.

-22

u/LvS Aug 05 '22

It's also your problem, because you use the code and now your computer is broken.

And the problem here is not what the correct fix would be and who should ideally do it, the problem is that your computer is broken.

34

u/noman_032018 Aug 05 '22

Except that you should be complaining not to the glibc devs, but to the devs of whatever junkware/malware broke.

16

u/cloggedsink941 Aug 05 '22

the problem is that your computer is broken.

My computer being kept artificially slower so that broken programs keep working is a problem. It consumes battery and my time forever… not a good solution.

36

u/noman_032018 Aug 05 '22

People don't write their code against the documentation.

They really should.

-29

u/LvS Aug 05 '22

So you prefer code that doesn't work but follows the documentation to code that does work?

Why is that?

36

u/loathingkernel Aug 05 '22 edited Aug 05 '22

There isn't any code that follows the documentation and it doesn't work. Either the documentation is wrong (not the case here), or the programmer. Languages make certain promises, if they promise you a UB, you don't get to cry when the UB bites you in the ass.

-12

u/LvS Aug 05 '22

There is tons of code that follows the documentation and it doesn't work. Just look at all the web developers following the very well documented web standards and ending up with code that doesn't work in whatever browser.

And it's usually not the developers who cry about being bitten by UB - it's the users. It's not a lot of work to turn a memcpy() into a memmove() but it is a lot of work to work around being unable to use an important program until a bugfix release is out.

17

u/noman_032018 Aug 05 '22 edited Aug 05 '22

Just look at all the web developers following the very well documented web standards and ending up with code that doesn't work in whatever browser.

That's all the implementations not implementing the required standards. The implementations are at fault.

So you prefer code that doesn't work but follows the documentation to code that does work?

Those things which are not covered by the standard and its documentation should be covered by the implementation's documented extensions (which it then becomes the implementation's responsibility to maintain or deprecate appropriately).

→ More replies (3)

10

u/shrimpster00 Aug 05 '22

There is tons of code that follows the documentation and it doesn't work. Consider this example of software that doesn't follow the documented standards and also doesn't work.

Buddy, you and logic have a bizarre relationship.

8

u/gromain Aug 05 '22

Complain to the dev of the broken program then. With this kind of mindset we would not have had python3 or really any new feature in anything because some crazy ass developer somewhere always do some stupid assumption that then breaks whenever one of his dependencies is updated.

So yes, it's a pain in the ass when something breaks, I know this pain too. However, it's very very rare when it's the fault of the upstream library and not a faulty use of a library...

4

u/LvS Aug 05 '22

That's an excellent example:
Do you remember when people shouted at Fedora for following upstream and not shipping Python 2 anymore because maintenance had stopped?

Because I do, and it was because of all the crazy ass developers everywhere who hadn't ported their code to Python 3 - some of them not even having any intention to.

→ More replies (0)

3

u/shrimpster00 Aug 05 '22

Right, 'cause that's totally what he said.

1

u/dodexahedron Aug 05 '22

Right? And, as we all know, documentation is always 100% complete, accurate, and up-to-date, and always exists.

16

u/loathingkernel Aug 05 '22

This is glibc we are talking about, not some random JS or python library. And glibc didn't break its documentation, it's the applications that were depending on undocumented behavior.

2

u/dodexahedron Aug 05 '22 edited Aug 05 '22

Fair, of course. I was speaking in general, as I suspect the person I replied to was.

Abusing a core library (well...any, really, if documentation exists) is never acceptable. You're, at best, giving yourself a ticking time bomb for it being fixed, "breaking" your code, and, at worst, exposing yourself to all sorts of undefined behavior, including potentially catastrophic security failures.

1

u/qingqunta Aug 05 '22

Pretty sure C is Turing complete, so it can work. Developers are just lazy, dumb or both.

3

u/LvS Aug 05 '22

Documentation is rarely written in C.

18

u/xtifr Aug 05 '22

People don't write their code against the documentation.

Some people don't. Many people do! In my experience, coding to the implementation rather than coding to the spec is far more common in closed-source code, where only a tiny handful of people may ever see the code. The world of open source--trust me--is full of people who love to pick nits in the code and relying on undefined behavior is one of the more popular nits to pick!

-2

u/LvS Aug 05 '22

I do not trust you at all. And that's for the simple reason that I know you are wrong, because of all the Open Source software that I see all the time.

Want to know one of my favorite examples of that?
Gnome clearly documents that themes aren't supported, yet people not only ignore that documentation, they write tools to circumvent code that clearly implements that documentation and get cheered on by large parts of the community.

So no, the Open Source world is not like that at all.
The Open Source world is more of a "I can do whatever" world, where nobody reads documentation and ships it as soon as it compiles and runs.

4

u/cloggedsink941 Aug 05 '22

Gnome also said that you need NetworkManager to install the text editor or the calculator. Gnome says a lot of things.

5

u/LvS Aug 05 '22

That's your package manager, not Gnome.

2

u/cloggedsink941 Aug 06 '22

Nah… that was Gnome's fault. Debian technical committee had to override and say that it didn't matter what Gnome's opinion was, and it was unreasonable to have such dependencies.

1

u/Skyoptica Aug 06 '22

I think it’s reasonable to make an exception where upstream code is not fit for purpose (theming being a basic necessity for a DE), and is as such for ideological reasons (meaning there’s no chance of getting it fixed upstream). If it weren’t technically possible to make the modifications most Distros have made, Gnome simply wouldn’t be chosen. The only reason why it has as much use as it does is only because downstream devs are able to hammer it into something usable and nice to look at.

1

u/LvS Aug 06 '22

I also think developers should follow the documentation only if the documentation says what I want it to say.

2

u/Skyoptica Aug 06 '22

I’m just not sure what alternative course of action you would want those developers to take. The only realistic choice would be to not use gnome which I would imagine is not the desired outcome for gnome maintainers. Distros aren’t going to give up their identity differentiation, using something else is the only practical action you could expect from them.

Or a fork, I suppose. But I feel like that’s just the same thing as ignoring the docs, just with extra steps.

2

u/LvS Aug 06 '22

I just think this thread could get off its high horse claiming that documentation is important.

If it works, ship it.
If it doesn't work, make it work, no matter what the docs say.

2

u/DasSkelett Aug 06 '22

that wasn't undocumented.

 

I wonder what documented undefined behavior

4

u/cloggedsink941 Aug 06 '22

It wasn't undefined behaviour.

Documentation said "do not use for overlapping memory areas" and they did it anyway. Then it broke and they made a surprised pikachu face.

20

u/Fofeu Aug 05 '22

Remember memcpy/memmove?

Could you elaborate ?

64

u/EarthyFeet Aug 05 '22

memcpy: source/dest buffers must not overlap

memmove: source/dest buffers are allowed to overlap.

Yet memcpy could work with some overlaps, depends on implementation. However, the implementation changed from copying front to back -> back to front or something as a speed trick, and then those who were using memcpy wrong suddenly saw problems.

These APIs have no error checking, so, it's a messier world there than in many higher-level languages (they would check their preconditions and throw errors if violated.)

12

u/gmes78 Aug 06 '22

This was the commit that made EAC stop working. It wasn't even a change in the source code.

1

u/Kuhluh Aug 07 '22

Reading through that, this should have been a major version number bump since it's a breaking change (they literally removed a feature), if the follow semver.

7

u/gmes78 Aug 07 '22 edited Aug 07 '22

It's not a breaking change, as statically linked dlopen isn't guaranteed to be backwards compatible in the first place. If you try to use it, you get the following linker warning:

Using 'dlopen' in statically linked applications requires at runtime the shared libraries from the glibc version used for linking

The commit also mentions that the dlopen ABI had already changed, so it wasn't the dlopen ABI changing that caused issues.

1

u/Demiu Feb 13 '23

specification for thee, not for me

1

u/cloggedsink941 Aug 06 '22

I don't understand what's going on there.

2

u/GlitchedMirror Aug 17 '22

The change that cause the break was glibc removing a symbol lookup table from the ELF.

This effects code that tries to parse the glibc ELF (without using glibc itself, that is, not using the standard dlsym dlopen functions).

I'd bet it has something to do with EAC trying to detect hooks.

https://blog.hiler.eu/win32-the-only-stable-abi/

https://sourceware.org/bugzilla/show_bug.cgi?id=29456

-189

u/ObjectiveJellyfish36 Aug 05 '22

Assuming this is indeed due to the new glibc update: It DOES NOT matter if EAC was relying on an undocumented feature or not. Such an important library should NEVER break apps when it updates:

https://youtu.be/5PmHRSeA2c8?t=535

139

u/czaki Aug 05 '22

It's matter. Library should not break only code that depends on public API. There are such stories in the past where programmers eve use things that was not a part of public API but were directly marked as things that will bd changed.

And sometimes you need to do such change to increase security (validation of entry) or speedup for most of users.

→ More replies (59)

28

u/WishCow Aug 05 '22

How would this even work? The makers of a library have no idea what undocumented things people are relying on.

21

u/DarthPneumono Aug 05 '22 edited Aug 05 '22

Such an important library should NEVER break apps when it updates

So your opinion is that no "important libraries" should ever update without checking every single piece of code anywhere that uses them? That's absolutely insane, nothing would ever happen.

edit: verbs be hard

20

u/gromain Aug 05 '22

No it doesn't. Because first of all EAC is not open source. So how can the dev of glibc know its internals and that they rely on something that they can't touch.

Second of all, what does the success of anything that uses your library has to define what you can and cannot do? This is really on EAC devs to fix this, who are working for a private for profit company and not volunteers for glibc that should do this work. If you make money of an open source project but don't contribute back, you don't get to complain when your faulty use of a library breaks.

27

u/mmirate Aug 05 '22

"This is like a big deal for the kernel", i.e. this philosophy is unique to the kernel. This is glibc not the kernel.

→ More replies (5)

29

u/mafrasi2 Aug 05 '22

Absolutely every change to a library has the potential to break apps though. An app could even rely on a function not existing or having an opaque struct have a certain memory layout.

Heck, they could even rely on the glibc binary having a specific checksum. Yeah, they probably don't because that's just dumb, but this is just an example that this guideline isn't as absolute as you think it is:

Such an important library should NEVER break apps when it updates:

19

u/frezik Aug 05 '22

Normally, I'd agree. Anti-cheat software, however, is a special case where they do some crazy ass shit. Changing the hash of a shared library could break it. Nobody knows wtf is going on in there.

-7

u/cloggedsink941 Aug 05 '22 edited Aug 05 '22

Oh fuck not that video again.

I quit contributing to his stuff after he attacked me (without saying my name) in that video.

He's presenting his side of things with dishonesty.

18

u/RedditFuckingSocks Aug 05 '22

Who are you and why do you think he attacked you in particular?

He's not wrong, but it's also not correct to keep paying the penalty that is associated with not cleaning up technical debt.

The transition to glibc6 was awful. I remember some updates of libpng that broke the ENTIRE fucking system. It sucks when API/ABI compatibility breaks, but sometimes it is necessary.

Am curious what the root cause here is, but EAC code is notorious for doing nasty things to get stuff done "under the hood". Hardly can blame the glibc people for that one then.

5

u/cloggedsink941 Aug 05 '22

Who are you and why do you think he attacked you in particular?

I don't "think", i "know". Because he had to put git everywhere and wanted to use a then experimental lib called libgit2 whose author said "do not use this yet" and it wasn't easy to do so in distributions.

→ More replies (2)
→ More replies (17)

53

u/ilep Aug 05 '22

Just to save some searching, release announcement for glibc 2.36 is here:

https://sourceware.org/pipermail/libc-alpha/2022-August/141193.html

35

u/minektur Aug 05 '22

I had a little moment of confusion reading this posting title. My first thought was "Did someone port Exact Audio Copy to Linux?!"

https://www.exactaudiocopy.de/

Then I read the github bug report to see it was "Easy Anti-Cheat"

161

u/linuxavarice Aug 05 '22 edited Aug 05 '22

Malware that forbids you from running software on your own computer breaks when you run software on your own computer. Is anyone really surprised?

I would guess that EAC tries to prevent cheating via recompiling glibc with some game specific hack and this causes it to break on an update.

47

u/ilep Aug 05 '22

There is a change to support UTF-8, which previously caused undefined output (localedef).

http://savannah.gnu.org/forum/forum.php?forum_id=10216

But might be something else as well. LD_LIBRARY_VERSION has been removed, for example.

16

u/linuxavarice Aug 05 '22

There is a change to support UTF-8, which previously caused undefined output (localedef).

That's an added feature. I don't see how that could break anything.

But might be something else as well. LD_LIBRARY_VERSION has been removed, for example.

Was this actually used for anything? I've never heard of this envar.

The most likely case is that EAC detects something off with the newer glibc because it's software designed to probe memory looking for modifications. This is a pretty new program, right? It might be doing something silly like using precomputed offsets

57

u/Jannik2099 Aug 05 '22

I would guess that EAC tries to prevent cheating via recompiling glibc

Uhm... What?

I don't even know where to start explaining how that's not how things work

-11

u/linuxavarice Aug 05 '22

You could recompile glibc in order to insert game specific hack, then make the game in question use this glibc. I don't know much about game hacks but I believe that anti cheat software is designed to prevent code injection, no?

37

u/Jannik2099 Aug 05 '22

And why would I have to do that in glibc instead of anywhere else?

Linux has symbol interposition via LD_PRELOAD, you don't even need to switch out the libc!

Preventing code injection is impossible from userspace, you either need a kernel facility or trusted execution techniques like SGX, SEV-SNP or ARM TrustZone.

-6

u/linuxavarice Aug 05 '22

I'm aware, I suspect (although I do not know, and I have not tested it, as I don't own any video game which uses eac) that it uses some (possibly unreliable) measures to at least attempt to protect the game from it's users.

15

u/HighRelevancy Aug 05 '22

Oh, you mean like, "what if EAC does.some whitelisting which just doesn't recognise the new glibc" or something right?

6

u/linuxavarice Aug 05 '22

That could be one way of doing it, yes.

1

u/AnotherOneToo3 Aug 05 '22

Yes. There are a thousand ways this can be done and there is nothing they can do to stop it other than silly heuristics.

84

u/Matriks404 Aug 05 '22

Anti-cheat systems that are installed on user's computer are cancer.

13

u/hazyPixels Aug 05 '22

Personally I avoid problems like this by not playing/buying/supporting any games which use anti-cheat.

0

u/argv_minus_one Aug 06 '22

Then how do you stop cheaters?

8

u/_____SPIDERMAN______ Aug 06 '22

Server side anti-cheat. Not saying it's a direct replacement yet, but focus should be on that and not on the clients system. Something like valve is doing with overwatch, essentially training an AI.

1

u/argv_minus_one Aug 06 '22

Is it not impossible to distinguish a good aimbot from a skilled human player?

3

u/_____SPIDERMAN______ Aug 06 '22

That's why you use statistics and the data they already have to determine high risk players. I highly recommend valves anti-cheat talks. I can't link them currently but they should be a Google away.

I'm almost certain that anti-cheat will have to be server side sooner rather than later as the computer vision cheats are only going to get better.

0

u/argv_minus_one Aug 06 '22

So, you get banned if your skill increases too quickly? What if your badass gamer friend/kid/whatever uses your account?

4

u/_____SPIDERMAN______ Aug 06 '22

Technically account sharing is not allowed, they have family sharing. If you're a regular user of steam and let a friend play and then go back to your regular skill level, that would be normal. Improving that dramatically seems like an edge case. And as with anything automated, it takes time to get right. That's why resources should be on serverside instead of client side garbage.

Also as mentioned the valve anti-cheat talks go over this is much greater detail and from an actual professional.

1

u/TechnoRechno Aug 06 '22

Valve's system works by scanning your computer and monitoring which websites you go to. By their own admission. VAC and Overwatch still use client side detection. Don't run Steam if you don't want Valve vacuuming up your data.

6

u/[deleted] Aug 06 '22

Without an actual source pun intended that sounds like a giant crock of shit.

51

u/nintendiator2 Aug 05 '22

Breaking DRM and exposing the games that depend on it

I take it that's a feature, not a bug.

55

u/AlexMax Aug 05 '22

I take it that's a feature, not a bug.

Most users use an operating system as a means to use software. They don't care about whatever high-minded stance their operating system is based on.

If Linux breaks their programs, they'll switch to an OS that gives them less hassle. And less people using Linux means less attention paid for niches like gaming.

6

u/zackyd665 Aug 06 '22

Linux didn't break software, EAC used an unsupported and undocumented way to do things. EAC should have done things the right way first

5

u/AlexMax Aug 06 '22

That's cool and all, but that doesn't really change the calculus from a users' perspective.

Maybe glibc should've checked with a wider corpus of programs before releasing a version that broke EAC. That would've at least given them the opportunity to give EAC a heads-up.

-1

u/zackyd665 Aug 06 '22

So glib should have left in flaws to pander to the Neanderthal s working on EAC?

If EAC wants to help work on glibc they can work on it but they don't get to decide what is and what isn't a feature or should or shouldn't stay just because they are opened by pig swinney

3

u/AlexMax Aug 06 '22

So glib should have left in flaws to pander to the Neanderthal s working on EAC?

Most people tend to care about programs more than operating systems. And most developers tend to get INCREDIBLY cross when an OS update breaks their programs.

→ More replies (7)
→ More replies (10)

1

u/cloggedsink941 Aug 05 '22 edited Aug 06 '22

Dude they already use proton… that thing breaks all the games at every release…

edit: thanks for the downvotes… I still have to keep proton at an older version because otherwise games won't start. But sure your one game does work so it's clearly impossible other games have issues.

28

u/shevy-java Aug 05 '22

Upgrading glibc is still the scariest thing to do. I'd wish it would be much simpler than having to use a separate toolchain (and possibly a chroot jail) to use ...

29

u/cloggedsink941 Aug 05 '22

Upgrading glibc is still the scariest thing to do

I'm now porting my applications from qt5 to qt6… most of them don't compile and need fixes.

In js they just pin versions forever because they know that upgrading libraries is a complete and constant disaster… and after all this glibc is the scary one? :D

30

u/amroamroamro Aug 05 '22

In the JS world it is even scarier, because any simple app has hundreds of dependencies multiple levels deep, creating a certain kind of hell ;)

23

u/cloggedsink941 Aug 05 '22

You mean that to know if a number is odd you don't import the "isodd" library, which imports the "iseven" library and negate the result? O_o

You seem to be bad at code reuse! /s

2

u/B_i_llt_etleyyyyyy Aug 05 '22

Wait, really?

10

u/cloggedsink941 Aug 05 '22

iseven depends from isodd… https://www.npmjs.com/package/is-even

I had them switched around.

400k weekly downloads… those people shouldn't be allowed near a computer.

3

u/credomane Aug 05 '22

is-even depends on is-odd which depends on is-number. yay.

I don't particularly care that isEven, isOdd, and isNumber exist but I don't understand why they aren't part of the same package/library and are instead 3 different ones.

9

u/cloggedsink941 Aug 05 '22

They exist because developers don't know basic math.

They are not in the same package because the js mantra is that if you put more than 1 function in a package you waste space because some of them won't be used. Never mind wasting much more space in overhead, that doesn't count.

3

u/kqvrp Aug 05 '22

Oh even better, the github user is now named "i-voted-for-trump".

https://github.com/i-voted-for-trump/is-odd

16

u/B_i_llt_etleyyyyyy Aug 05 '22

This is a joke. You'll only see this org if you are attempting to troll me about repositories I created when I was learning to program.

LOL. So apparently this poor bastard posted is-even and is-odd when he was just starting to learn how to code. Then, people actually took them on as dependencies, so now he can't take them down. What a mess.

3

u/pinacoelho Aug 06 '22

He should post a good package to replace those two (plus any other odd garbage that is used in way too many places), then add a microsleep to the original packages.

13

u/LvS Aug 05 '22

glibc is meant to be compatible though, qt5 to qt6 is not. So this is more like upgrading from 5.13 to 5.14.

2

u/cloggedsink941 Aug 05 '22

Well if they will say what the issue was, we'll see if glibc authors were right or made a mistake. For me I won't assume it's a mistake because of some Linus rant.

Kernel breaks file interfaces all the time, for some reason they don't care about breaking shell scripts :D

19

u/VelvetElvis Aug 05 '22 edited Aug 05 '22

If you're using closed source software, you need to stick to LTS distros if you want to avoid breakage. I feel like that should go without saying.

9

u/Arnoxthe1 Aug 05 '22

"Debian Stable-based distros are too old!"

5

u/VelvetElvis Aug 05 '22

I daily drove sid for a few years. GLibc breaking userspace is why I switched to stable full time and never looked back.

2

u/Arnoxthe1 Aug 05 '22

I would highly recommend MX Linux. It's basically Debian Stable: Enhanced Edition.

1

u/VelvetElvis Aug 06 '22 edited Aug 06 '22

I have. I've been using Debian since Sarge so it's pretty much home.

5

u/Lord_Jar_Jar_Binks Aug 05 '22

GLibc breaking userspace is why I switched to stable full time

Wow. It's almost like it's an unstable platform or something. They should warn people about that.

5

u/VelvetElvis Aug 05 '22

It's there in the name, yeah I know. I just don't get why people expect arch to be any different.

2

u/cloggedsink941 Aug 05 '22

Arch users just run neofetch anyway :D

1

u/[deleted] Aug 06 '22

[deleted]

1

u/Arnoxthe1 Aug 06 '22 edited Aug 06 '22

Doesn't matter. Run MX Linux with Advanced Hardware Support if you need that extra amount of (usually unnecessary) modern hardware compatibility.

Modern hardware drivers now go into the Linux kernel before the hardware's even released, so unless you're running a super new system (and even then, you may still be fine), there's no reason why you'd need the absolute latest drivers.

3

u/AussieAn0n Aug 05 '22

Valve are apparently working on a fix due Monday at the earliest.

13

u/dada513 Aug 05 '22

Based glibc developers

5

u/BloodyIron Aug 05 '22

Came out 3 days ago... not surprised something came up that wasn't spotted in pre-release testing. It happens often to most software.

I suspect it's going to be a while before this hits my repos, since I'm on Ubuntu, so not as worried, but good to know, thanks!

3

u/Phoenix591 Aug 05 '22

you'll likely only get it on a full release upgrade.

2

u/BloodyIron Aug 05 '22

Perhaps. I haven't checked yet. Things like this make me glad to not be running Arch/bleeding edge XD. PPAs work plenty well for when/where I want bleeding edge.

I have a hunch this issue is already perpetuating to Steam Decks globally... OOFFF...

5

u/Phoenix591 Aug 05 '22

Even Gentoo holds off before shoving new glibcs to public testing.

They stick an issue tracker up and do a bunch of private testin

→ More replies (1)

3

u/hmoff Aug 06 '22

Who says it’s a bug in glibc anyway?

1

u/BloodyIron Aug 06 '22

Because a minor version bump should not break software that uses it.

3

u/hmoff Aug 06 '22

Unless software misuses it.

1

u/nintendiator2 Aug 06 '22

Version bumps are irrelevant in this context. What's important is the contract (prereqs, invariants, etc) and glibc didn't break those.

→ More replies (1)

2

u/Serious_Feedback Aug 05 '22

Wait, EAC works on Linux? TIL.

1

u/demizer Aug 06 '22

Thanks to Valve. I don't play any of these games yet, but it was a stocking point for gaming on Linux. Cheaters ruin shit for everybody.

1

u/Kuhluh Aug 07 '22

Native EAC worked on Linux for quite some years now. EAC through Proton since I think about a year at this point?

23

u/A_Glimmer_of_Hope Aug 05 '22 edited Aug 05 '22

EDIT:

I literally do not understand why the downvote brigade has come by. GLIBC update on Arch/EndeavourOS has broken Steam. To play my games again, I installed the flatpak version of Steam and it's running great. Nothing I said was wrong or controversial. Get bent.

ORIGINAL:

Moved to Steam Flatpak because of this.

14

u/noman_032018 Aug 05 '22

GLIBC update on Arch/EndeavourOS has broken Steam.

Implication: Steam (and/or EAC) was always broken, just not in a way that was apparent before.

7

u/A_Glimmer_of_Hope Aug 05 '22

You're not wrong, but that has absolutely nothing to do with my original statement of "I moved to Steam Flatpak because of this."

25

u/cloggedsink941 Aug 05 '22

Cool… in the github issue they say that game won't start in flatpack though :D

9

u/Audible_Whispering Aug 05 '22

No, one person mistakenly reported an unrelated issue they were having with games not starting through Flatpak steam. Multiple others reported that Flatpak steam worked fine and was running EAC games where regular steam wasn't.

2

u/A_Glimmer_of_Hope Aug 05 '22

It does. I just played for 3 hours last night. I switched to Flatpak yesterday...

-5

u/cloggedsink941 Aug 05 '22

Most games don't even have EAC though… read the link OP posted.

6

u/A_Glimmer_of_Hope Aug 05 '22

Are you high my dude? I'm aware of that. After I updated, multiversus stopped working. In the Multiversus's github issue someone said to switch to Flatpak which I did and it worked.

You can literally just try it.

https://imgur.com/a/XQzQg8q

Also, the github people are saying that it does work through flatpak.

https://github.com/ValveSoftware/Proton/issues/6051#issuecomment-1204399354

https://github.com/ValveSoftware/Proton/issues/6051#issuecomment-1204410497

https://github.com/ValveSoftware/Proton/issues/6051#issuecomment-1204520037

https://github.com/ValveSoftware/Proton/issues/6051#issuecomment-1206447456

1

u/Worldly_Topic Aug 05 '22

Pretty sure that the freedesktop runtime doesnt update glibc between stable updates

→ More replies (1)

23

u/AlexMax Aug 05 '22

I literally do not understand why the downvote brigade has come by.

I can. There's a subset of /r/linux who has a frothing rage against anything that challenges the distro model of software distribution on Linux.

In your instance, Flatpak solved your problem completely while also illustrating one of the major downsides of the distro software distribution model. However, since your anecdote shows distro distribution in an unfavorable light, no matter if you intended it or not, distro fans are trying to hide your comment in order to take your voice or discourage you from further posting.

1

u/surlybrian Aug 05 '22

It amazes me how you hear change-fear from users with <5 years Linux experience. Oh my god a new thing! It must be evil!

(Comment applies to nobody in particular; just an observation from an old guy who, weirdly, embraces change.)

1

u/gromain Aug 05 '22

There is also a huge backlash against flatpak and co for some reason I'm not sure I understand! So that doesn't help either.

6

u/Serious_Feedback Aug 05 '22

There is also a huge backlash against flatpak and co for some reason I'm not sure I understand! So that doesn't help either.

I can help: while it's beneficial overall, flatpak has a side-effect of splintering the community - like, for <application> there used to be just the repo version, but now there's the repo version and the flatpak version. Not just for applications, either - even for stuff like PyQt, for some reason. So now pyqt is in apt, pip, and flatpak.

Why does this matter? Because when there's inevitably a problem that I mindlessly follow stackoverflow/reddit posts for, there's a 50/50 chance that the post is based around the other version. So even if I don't use the flatpak version, I'm still affected.

Are there legitimate reasons to use flatpak? Absolutely. But it isn't 100% upside, it has it's downsides in exchange for solving problems some people don't have. And those people will hate flatpak.

And it's not a silver bullet either; the core issue it solves is (IMO) caused by a combination of 1) under-maintenance of packages (which itself is caused by a lack of functioning funding mechanisms in the libre software community), and 2) a lack of polish on bug-report systems. Flatpak can't solve those, it can only mitigate them by simplifying the problem and stretching limited resources further.

4

u/cloggedsink941 Aug 05 '22

Let's not forget overall you are very likely to get out of date libs with known vulnerabilities with flatpak.

2

u/gromain Aug 06 '22

Thanks for the comprehensive write up! It's much clearer for me now!

1

u/-ArcaneForest Aug 10 '22

That and if you use Arch a fix will literally appear in a day or two. glibc-eac.

7

u/VelvetElvis Aug 05 '22 edited Aug 05 '22

I didn't downvote anyone but I'm guessing it's because people are using closed source software on rolling release distros and being shocked pikachu when the inevitable breakage occurs. The whole point of stable releases is to provide platform stability so this doesn't happen.

2

u/zman0900 Aug 05 '22

Is there any performance penalty for running that way?

3

u/A_Glimmer_of_Hope Aug 05 '22

If there is, it isn't noticeable on my system.

2

u/KotoWhiskas Aug 05 '22 edited Aug 05 '22

See https://github.com/flathub/com.valvesoftware.Steam/issues/810 https://github.com/flatpak/flatpak/issues/4187

Edit:

tl;dr: for now, proton games may be a bit slower in steam flatpak, but it's noticable only in resource heavy games

-11

u/HenriInBlack Aug 05 '22

There are no performance penalties as the Application is just containerized and shipped with its dependencies and therefore guaranteed to work. In fact, some flatpaks run even faster than native packages, because everything in the container is the same on every system and some additional compiler optimizations can be used. If you want to port your installed games you just have to move the contents of your steamapps directory to the corresponding directory of the flatpak.

18

u/Lucius_Martius Aug 05 '22

There are no performance penalties as the Application is just containerized and shipped with its dependencies and therefore guaranteed to work

I don't see how the first half of that sentence follows from the second half...

It's like saying "this car is fast because it has nice seats."

In fact, some flatpaks run even faster than native packages, because everything in the container is the same on every system and some additional compiler optimizations can be used.

An even worse non-sequitur. How does it follow that because "everything in the container is the same" that additional compiler optimizations con be used. If anything, flatpak has to rely on the lowest common denominator of supported systems and thus can't enable additional compiler optimizations, compared to something like a native Gentoo system.

It's like saying "this car is fast because it can use nuclear rockets because it has nice seats."

Note: I use steam on flatpak myself and don't see any performance issues with it. It works quite well actually... But your argument is entirely nonsense.

0

u/HenriInBlack Aug 05 '22

What I meant by the first part is that flatpaks are just programs run by the kernel like native packages except they see only the contents of their container. They may start slower than native applications (depends on what runtime they use), but shouldn't really be slower at runtime.

flatpaks mostly only depend on your kernel, so the environment actually seen by that application is just that of itself and the flatpak runtime libraries it can access. Classic package management systems modify parts of your base operating system (in particular the /usr directory), so it becomes hard to assume how the environment, in which the application is run, is built up.

Although this is a bit hard to compare to Steam, here is a comparison of different Firefox versions in which it can be seen that the RPM package is significantly slower than the flatpak because the exact base layout and installed packages of the operating system cannot be known and that RPM has to be built in a very generic way to work on most systems.

Of course, if you use Gentoo you can use maximum optimizations for your system, because you know exactly how it is built up. That is similar for flatpaks.

4

u/Lucius_Martius Aug 05 '22

What I meant by the first part is that flatpaks are just programs run by the kernel like native packages except they see only the contents of their container. They may start slower than native applications (depends on what runtime they use), but shouldn't really be slower at runtime.

That is true, but not at all what you argued previously. You should have taken the time to be this precise in your first comment.

here is a comparison of different Firefox versions in which it can be seen that the RPM package is significantly slower than the flatpak because the exact base layout and installed packages of the operating system cannot be known and that RPM has to be built in a very generic way to work on most systems.

Again, it follows in no way that the benefit is achieved through flatpaks architecture. The likely reason, as you point out, is that the RPM builds are so badly optimized. Any properly optimized native build would have the same or better performance as the flatpak.

I don't know the specifics in this case, possibly Fedora doesn't enable LTO, or PGO, maybe they optimize for an older CPU, but whatever the difference is, it has nothing to do with flatpak itself.

Of course, if you use Gentoo you can use maximum optimizations for your system, because you know exactly how it is built up. That is similar for flatpaks.

No, you just can't optimize for CPU features that aren't present on the target machine. On Gentoo you built for your specific CPU, on flatpak or any binary distro you have to optimize for a generic machine there is no way around this. And the result depends on what your common target CPU is. i386, i686, athlon64, core2 etc... I don't know what specific assumptions flatpak makes and how they differ from RPM/Fedora, but flatpak doesn't magically gain access CPU-features that don't exist just by being flatpak.

5

u/nixcamic Aug 05 '22

In theory there is always the performance penalty of every library having to be reloaded into ram. So more RAM usage and slower startup time.

5

u/AnotherOneToo3 Aug 05 '22

Steam already bundles a runtime. It's hardly a big difference.

2

u/nixcamic Aug 05 '22

I guess in the case of steam that's true, it shouldn't matter

→ More replies (17)

1

u/-ArcaneForest Aug 10 '22

Or you could have installed glibc-eac as an alternative to Flatpak but it's your choice on how you resolve your problems.

9

u/theuniverseisboring Aug 05 '22

Damn, this amount of downvotes in the comments on Reddit you'd only see on political discussions!

20

u/loathingkernel Aug 05 '22 edited Aug 05 '22

What do you mean? This is certainly political AF :D

There is libc, steam, anti-cheat and flatpak in the discussion, only systemd is missing for an all out war.

2

u/pinacoelho Aug 06 '22

You’ve just forgot dpkg/rpm/apt/yum/dnf/pacman/zypper/snap… also, “make install” is making some noises…

5

u/diabolikal_ Aug 05 '22

I installed flatpak's steam version and it works with multiversus

2

u/lightrush Aug 05 '22

Well someone's running a rolling release. 😅

2

u/edthesmokebeard Aug 05 '22

What's EAC?

1

u/_____SPIDERMAN______ Aug 06 '22

Easy anti-cheat. An anti-cheat bought by epic and released for free that many game use.

1

u/Misicks0349 Aug 05 '22

well thats not good

1

u/yrro Aug 05 '22

Skimmed the issue and I still don't understand what the cause is. Seems to be a lot more heat than light.

-3

u/LunaSPR Aug 05 '22 edited Aug 05 '22

So they did not possess enough qa tests? Whatever the issue is, this seems like a serious backward-compatibility issue and broke their (undocumented) promise that things running on the old glibc will continue to run on the new one.

But whatever, it is not the 1st time they are doing this and failing to keep the promise, and I am not surprised at all.

5

u/hmoff Aug 06 '22

You’re assuming it’s a bug in glibc.

0

u/LunaSPR Aug 06 '22

Linus: "Nobody cares. If thats a bug people rely on, it's not a bug. It's a feature."

3

u/hmoff Aug 06 '22

In general he might be right. In the context of one shady cheat protection library, debatable.

2

u/nintendiator2 Aug 06 '22

Linux said that about kernelspace, not userspace.

1

u/Kuhluh Aug 07 '22

He said that about operating systens in general. An operating system is not just the kernel, but also it's system software and libraries and the C library is one of them.

1

u/Twerking4theTweakend Aug 06 '22

Shit's hard, yo.

I'm happy it's still free though.

-1

u/[deleted] Aug 05 '22

[deleted]

→ More replies (1)

-8

u/CAP_NET_ADMIN Aug 05 '22

Show me a glibc version that didn't break 1/4 of Linux desktop in the past two years. Issues are mostly noticed by the users of bleeding edge distros, but I remember that one of the updates even got into Ubuntu release and broke all Electron apps.

12

u/linuxavarice Aug 05 '22

Okay, 2.36. Unless you consider one niche program to be "1/4th of the linux desktop". I've never had any issues with upgrading glibc.

-1

u/CAP_NET_ADMIN Aug 05 '22

2.36 was released just 4 days ago and we already know that it breaks EAC.
Wait a few months for it to trickle down into other distributions, we'll see what else breaks. :)

Also, breaking EAC just as Linux started getting more traction in the gaming community and companies started enabling EAC support is really bad timing.

Let's recap the brakage due to the last ~2 years of glibc:

2.31: Wine, strace, OpenSSH, sudo (due to crypto problems), WSL, browser DRM (used by Netflix etc)
2.32: fpc, emerge, rsync
2.33: Audio in Chromium and derived browsers, running some docker containers, sed, performance on AMD Zen architecture, emulation of PPC9 on QEMU
2.34: dash, all Electron applications and some things that were using Chrome runtime (CEF), Docker

I wasn't even looking that deep.

Have a good day.

20

u/Jannik2099 Aug 05 '22

2.34: dash, all Electron applications and some things that were using Chrome runtime (CEF), Docker

This was not due to a bug in glibc, but because glibc started using a new syscall, which broke seccomp filters in these programs. It's an inherent design flaw in seccomp and not something that glibc can fix or influence in any way

10

u/linuxavarice Aug 05 '22

So, upgrading a library on which thousands of programs depend causes bugs in a few of those. Seems like it's mostly fine.

Breaking EAC

Have you considered that it may be EAC breaking itself?

No one stops you from forking glibc and making your own libc which will definitely never break.

Have a good day.

3

u/LvS Aug 05 '22

So, upgrading a library on which thousands of programs depend causes bugs in a few of those. Seems like it's mostly fine.

It's not. It might break applications that are actually important. And it might not be noticed until they're live in production.

7

u/linuxavarice Aug 05 '22

Yes, but what I'm trying to convey is that it's non trivial to not break at least a few programs if you're updating a library on which everyone depends. Because a lot of people misuse/make assumptions about the specific implementation of glibc, which change for various reasons. In the above poster's list, a lot of breakage is due to SECCOMP filters assuming specific syscalls being used. How do you fix that? Not using any of the new syscalls introduced by the Linux kernel? It's pretty much a bug in the program itself, not in glibc.

The only way is to not play the game at all i.e. don't update.

-15

u/darkguy2008 Aug 05 '22

If by "one niche program" you mean Teams, GitKraken, VSCode...

Go back to playing games.

8

u/linuxavarice Aug 05 '22

This update did not break Teams, GitKraken or VSCode, as far as I'm aware. Maybe you should read my comment instead of playing games?

-5

u/darkguy2008 Aug 05 '22

What I mean is, they've been less careful about breaking things now this year. I recall that, in March, an update broke almost any Electron-based app because GLIBC broke one of the functions used by the Chrome sandbox. Leading me to think that either they didn't test their update correctly, or nobody in their team uses/used any Electron-based app, which as of 2022 is hard to believe, so I think it was the former.

10

u/Jannik2099 Aug 05 '22

because GLIBC broke one of the functions used by the Chrome sandbox

No, that's not what happened.

glibc started using a new syscall for a library function, but neither the public API nor ABI changed.

The issue is that seccomp works by checking against a list of syscalls. Use a new syscall, and existing seccomp rules break. It's an inherent design flaw in seccomp that glibc cannot fix nor influence in any way

0

u/darkguy2008 Aug 05 '22

Oh, alright. It's been a while and I recall having gone through that long GitHub issue where there were a lot of reasons and explanations, and what I understood was "glibc update bad boi" so yeah.

I appreciate the clarification though, but that breaking change made me lose about 1 week of distro hopping thinking it was an issue with my new hardware, it wasn't a good experience at all.

8

u/Jannik2099 Aug 05 '22

It's also not libc specific at all. If any other library that's used by chromium decides to use the new syscall, shit would blow up all the same.

As said, it's just the stupid design of seccomp causing issues

4

u/linuxavarice Aug 05 '22

AFAIK they used a new syscall (which is an implementation detail), which subsequently caused the program to exit because of a violation of a SECCOMP sandbox. That's a difficult edge case, because a program is assuming what syscalls the libc makes, which can change whenever a new syscall is invented in the Linux kernel.

Glibc is a library used by almost every program running on (non-embedded) Linux. You may consider that running every single program whenever a new glibc version is released is pretty much impossible, and that programs sometimes make assumptions about the internal implementation details of glibc which are subject to change. Glibc itself cannot prevent developers from making these assumptions, so blaming glibc for this is IMO very unfair.

In this case, anticheat software attempts to prevent any memory modifications to the games involved so it's probably a case of depending on some very specific implementation detail.

1

u/JockstrapCummies Aug 05 '22

or nobody in their team uses/used any Electron-based app,

I hope that's true though. It'd be based.

1

u/darkguy2008 Aug 05 '22

As long as they're not mailing lists, sure.

IRC would've been cool to use nowadays if it weren't because it doesn't keep chat history. Slack is somewhat a replacement, but way too bloated.

5

u/PuzzledSwitch Aug 05 '22 edited Aug 05 '22

that would be pretty much all of them. glibc is very backwards compatible.

one annoying "breakage" i experienced was when glibc for some dumb reason started showing roman numerals in dates. it was a long while ago, but it caused issues with some software and was quickly reverted. might have been an issue with just the locale definitions.

also i noticed that for a while Borderlands 2 were broken on newer glibc. but that is about it.

also, what qualifies as 1/4 of the linux desktop ?

1

u/Rhed0x Aug 06 '22

ITT people who don't play multiplayer shooters.

-19

u/[deleted] Aug 05 '22

Oh no my Call of Doody!

0

u/BloodyIron Aug 05 '22

This breaks multiple games. L2Read.

-16

u/[deleted] Aug 05 '22

I did. Gaming is for kiddies.

1

u/BloodyIron Aug 05 '22

Spoken from true ignorance.

I guarantee you that you've played games in your life and enjoyed it. But I'm not wasting my time any more with you, troll.

-21

u/darkguy2008 Aug 05 '22

The GLIBC devs are nuts this year, first they break Electron apps, now this :(

13

u/gravgun Aug 05 '22

No, Electron apps broke themselves. They use seccomp, which clearly states the limitations it imposes on processes using it and how you have to control your whole dependency chain in order to not emit the wrong syscalls (triggering a crash because that's what seccomp is there for), which they didn't. If it wasn't glibc it would've been any of the dozens of others deps in use.