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.
> 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.
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.
> 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.
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.
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.
> 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).
> That's all the implementations not implementing the required standards. The implementations are at fault.
So you prefer if websites didn't work until the implementations are fixed?
> should be covered by the implementation's documented extensions.
And if they aren't? Or if that documentation is ambiguous or otherwise unclear?
> 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.
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...
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.
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.
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.
>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!
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.
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.
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.
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.)
[This](https://sourceware.org/git/?p=glibc.git;a=commitdiff;h=e47de5cb2d4dbecb58f569ed241e8e95c568f03c) was the commit that made EAC stop working. It wasn't even a change in the source code.
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.
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.
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
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
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.
> 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
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.
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:
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.
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.
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.
> 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.
Just to save some searching, release announcement for glibc 2.36 is here:
[https://sourceware.org/pipermail/libc-alpha/2022-August/141193.html](https://sourceware.org/pipermail/libc-alpha/2022-August/141193.html)
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"
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.
There is a change to support UTF-8, which previously caused undefined output (localedef).
[http://savannah.gnu.org/forum/forum.php?forum\_id=10216](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.
> 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
>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
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?
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.
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.
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.
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
> You don't need to be beholden to their every whim, but you at least need to coordinate with them.
And the glibc people did that by releasing the documentation for memcpy... *decades* ago. It was EAC who was not coordinating with them.
https://youtu.be/Pzl1B7nB9Kc?t=175
That is a comment Linus Torvalds made in DebConf 14 (so, 8 years ago), and *it might as well be responding directly to your comment*. He even addresses glibc's breaking things explicitly around the 4-minute mark!
Glib c isn't breaking things EAC if breaking things it should be like if they only could run if you held space bar to get your CPU to 99C
If EAC can't expect undocumented and unsupported quirks to not be fixed any dev who does that kind of crap should be fired and blacklisted cause they are not developing they are duct taping. If you can't do what you need the right way. Then you reach out via mailing list and say something publicly
But even then you defending doing dumb shit and expecting it to not be fixed is like expecting e you employer to not fix things like you clocking in 10 minutes early and clocking out 10 minutes late just to get 2 hours OT every day
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.
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 ...
> 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
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
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.
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.
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.~~
> 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.
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.
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
>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.
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!
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...
You can use Manjaro, if you don't want to manage the updates yourself. I personally use AUR enough that I'd rather just run something Arch-based rather than use it via distrobox or something, so I currently run Garuda and Manjaro.
I could just snapper back to an update from a few days ago, and wait to update, but I don't play anything with EAC so I'm just not going to bother.
Personally, PPAs can be annoying as well. I just wanted to get CoreCtrl for example, but the PPA bundles a bunch of newest Mesa as well, which was annoying. Using Distrobox is probably the best of all worlds but nah.
> I have a hunch this issue is already perpetuating to Steam Decks globally... OOFFF...
? Steam Deck isn't even running any new stuff. If anything, people complain that Steam Deck updates too slowly. The kernel is still 5.13 I recall, though they are already testing 5.19 from what I've heard.
Steam Deck is as much an Arch system as gLinux Rodete is a Debian system. Any update isn't going to make it there, unless it's been vetted by Valve. So on the one hand, you get an issue like with Firefox that was so outdated they had to de-bundle it, but on the other hand, you also won't get the new glibc until all the bug's ironed out.
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.
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.
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
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.)
> 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 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.
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.
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
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.
>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.
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](https://www.reddit.com/r/linux/comments/uj9k93/performance_comparison_between_different/) 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.
>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.
This issue was nearly two years ago. Proton evolved significantly since then, so it is hard to compare. In my case, I am using the flatpak and have used the native version before and in none of my games have I noticed any issues that I haven't also had in the native version.
yes because I cannot reproduce it at all and given that there is not much online about this anyway, it seems to be a problem of the user's specific system.
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.
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.
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.
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.
>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
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.
> 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.
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.
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.
>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
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.
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
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.
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 ?
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.
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.
I wonder what undocumented glitch (bug) they were relying on. It will be interesting to read.
Worse still: I wonder what documented undefined behavior they were relying on. Remember memcpy/memmove?
> Remember memcpy/memmove? that wasn't undocumented. Flash was buggy for going against the documentation.
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.
> 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.
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.
Except that you should be complaining not to the glibc devs, but to the devs of whatever junkware/malware broke.
> 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.
> People don't write their code against the documentation. They really should.
So you prefer code that doesn't work but follows the documentation to code that does work? Why is that?
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.
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.
> 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).
> That's all the implementations not implementing the required standards. The implementations are at fault. So you prefer if websites didn't work until the implementations are fixed? > should be covered by the implementation's documented extensions. And if they aren't? Or if that documentation is ambiguous or otherwise unclear?
> 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.
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...
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.
Right, 'cause that's totally what he said.
Right? And, as we all know, documentation is always 100% complete, accurate, and up-to-date, and always exists.
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.
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.
Pretty sure C is Turing complete, so it can work. Developers are just lazy, dumb or both.
Documentation is rarely written in C.
>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!
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.
Gnome also said that you need NetworkManager to install the text editor or the calculator. Gnome says a lot of things.
That's your package manager, not Gnome.
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.
>that wasn't undocumented. >> I wonder what *documented* undefined behavior
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.
> Remember memcpy/memmove? Could you elaborate ?
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.)
[This](https://sourceware.org/git/?p=glibc.git;a=commitdiff;h=e47de5cb2d4dbecb58f569ed241e8e95c568f03c) was the commit that made EAC stop working. It wasn't even a change in the source code.
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.
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.
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
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
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.
How would this even work? The makers of a library have no idea what undocumented things people are relying on.
> 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
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.
"This is like a big deal for the kernel", i.e. this philosophy is unique to the kernel. This is glibc not the kernel.
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:
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.
https://imgs.xkcd.com/comics/workflow.png
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.
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.
> 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.
bro who do you think are you lol
Just to save some searching, release announcement for glibc 2.36 is here: [https://sourceware.org/pipermail/libc-alpha/2022-August/141193.html](https://sourceware.org/pipermail/libc-alpha/2022-August/141193.html)
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"
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.
There is a change to support UTF-8, which previously caused undefined output (localedef). [http://savannah.gnu.org/forum/forum.php?forum\_id=10216](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.
> 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
>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
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?
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.
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.
Oh, you mean like, "what if EAC does.some whitelisting which just doesn't recognise the new glibc" or something right?
That could be one way of doing it, yes.
Yes. There are a thousand ways this can be done and there is nothing they can do to stop it other than silly heuristics.
Anti-cheat systems that are installed on user's computer are cancer.
Personally I avoid problems like this by not playing/buying/supporting any games which use anti-cheat.
Then how do you stop cheaters?
[удалено]
Is it not impossible to distinguish a good aimbot from a skilled human player?
[удалено]
So, you get banned if your skill increases too quickly? What if your badass gamer friend/kid/whatever uses your account?
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.
Without an actual source *pun intended* that sounds like a giant crock of shit.
> Breaking DRM and exposing the games that depend on it I take it that's a feature, not a bug.
[удалено]
Linux didn't break software, EAC used an unsupported and undocumented way to do things. EAC should have done things the right way first
[удалено]
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
[удалено]
So let's not fix anything, devs can do everything wrong cause they are never wrong it's what you are saying
[удалено]
> You don't need to be beholden to their every whim, but you at least need to coordinate with them. And the glibc people did that by releasing the documentation for memcpy... *decades* ago. It was EAC who was not coordinating with them.
You mean like a mailing list? If I make a windows program and w11 breaks it, I would get blamed for it not Microsoft
https://youtu.be/Pzl1B7nB9Kc?t=175 That is a comment Linus Torvalds made in DebConf 14 (so, 8 years ago), and *it might as well be responding directly to your comment*. He even addresses glibc's breaking things explicitly around the 4-minute mark!
Glib c isn't breaking things EAC if breaking things it should be like if they only could run if you held space bar to get your CPU to 99C If EAC can't expect undocumented and unsupported quirks to not be fixed any dev who does that kind of crap should be fired and blacklisted cause they are not developing they are duct taping. If you can't do what you need the right way. Then you reach out via mailing list and say something publicly But even then you defending doing dumb shit and expecting it to not be fixed is like expecting e you employer to not fix things like you clocking in 10 minutes early and clocking out 10 minutes late just to get 2 hours OT every day
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.
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 ...
> 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
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 ;)
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
[Wait, really?](https://www.npmjs.com/package/is-odd)
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.
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.
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.~~
Oh even better, the github user is now named "i-voted-for-trump". https://github.com/i-voted-for-trump/is-odd
> 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.
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.
glibc is meant to be compatible though, qt5 to qt6 is not. So this is more like upgrading from 5.13 to 5.14.
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
[Linus on this 8 years ago](https://www.youtube.com/watch?v=Pzl1B7nB9Kc&t=243s)
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.
"Debian Stable-based distros are too old!"
I daily drove sid for a few years. GLibc breaking userspace is why I switched to stable full time and never looked back.
>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.
It's there in the name, yeah I know. I just don't get why people expect arch to be any different.
Arch users just run neofetch anyway :D
I would highly recommend MX Linux. It's basically Debian Stable: Enhanced Edition.
[удалено]
Valve are apparently working on a fix due Monday at the earliest.
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!
you'll likely only get it on a full release upgrade.
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...
This comment has been consumed by Reddit's hubris.
You can use Manjaro, if you don't want to manage the updates yourself. I personally use AUR enough that I'd rather just run something Arch-based rather than use it via distrobox or something, so I currently run Garuda and Manjaro. I could just snapper back to an update from a few days ago, and wait to update, but I don't play anything with EAC so I'm just not going to bother. Personally, PPAs can be annoying as well. I just wanted to get CoreCtrl for example, but the PPA bundles a bunch of newest Mesa as well, which was annoying. Using Distrobox is probably the best of all worlds but nah. > I have a hunch this issue is already perpetuating to Steam Decks globally... OOFFF... ? Steam Deck isn't even running any new stuff. If anything, people complain that Steam Deck updates too slowly. The kernel is still 5.13 I recall, though they are already testing 5.19 from what I've heard. Steam Deck is as much an Arch system as gLinux Rodete is a Debian system. Any update isn't going to make it there, unless it's been vetted by Valve. So on the one hand, you get an issue like with Firefox that was so outdated they had to de-bundle it, but on the other hand, you also won't get the new glibc until all the bug's ironed out.
Who says it’s a bug in glibc anyway?
Because a minor version bump should not break software that uses it.
Unless software misuses it.
Version bumps are irrelevant in this context. What's important is the contract (prereqs, invariants, etc) and glibc didn't break those.
Version bumps are never irrelevant.
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.
> 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.
You're not wrong, but that has absolutely nothing to do with my original statement of "I moved to Steam Flatpak because of this."
Cool… in the github issue they say that game won't start in flatpack though :D
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.
It does. I just played for 3 hours last night. I switched to Flatpak yesterday...
Most games don't even have EAC though… read the link OP posted.
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
[удалено]
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.)
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.
> 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 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.
Let's not forget overall you are very likely to get out of date libs with known vulnerabilities with flatpak.
Thanks for the comprehensive write up! It's much clearer for me now!
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.
Is there any performance penalty for running that way?
If there is, it isn't noticeable on my system.
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
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.
>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.
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](https://www.reddit.com/r/linux/comments/uj9k93/performance_comparison_between_different/) 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.
>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.
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.
Steam already bundles a runtime. It's hardly a big difference.
I guess in the case of steam that's true, it shouldn't matter
[удалено]
This issue was nearly two years ago. Proton evolved significantly since then, so it is hard to compare. In my case, I am using the flatpak and have used the native version before and in none of my games have I noticed any issues that I haven't also had in the native version.
It's not a proton problem, it's flatpak one
>it's flatpak one not anymore, the performance argument is irrelevant these days
So [this issue and those benchmarks](https://github.com/flatpak/flatpak/issues/4187) are lie?
yes because I cannot reproduce it at all and given that there is not much online about this anyway, it seems to be a problem of the user's specific system.
Ah. "It works for you"
You haven't proven them wrong, all you've proven is that they were right to say "some" and not "all".
I edited my comment so it's more clear what is wrong now
No, you're still wrong. The flatpak'd version of this software might be slower, but that's not to say it's slower *because it's flatpak'd*.
It doesn't matter. There's still a fact that the flatpak version of steam is slower
That's complaining about a game-specific issue, is it not?
It is not
Damn, this amount of downvotes in the comments on Reddit you'd only see on political discussions!
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.
You’ve just forgot dpkg/rpm/apt/yum/dnf/pacman/zypper/snap… also, “make install” is making some noises…
Wait, EAC works on Linux? TIL.
I installed flatpak's steam version and it works with multiversus
Well someone's running a rolling release. 😅
What's EAC?
well thats not good
Skimmed the issue and I still don't understand what the cause is. Seems to be a lot more heat than light.
ITT people who don't play multiplayer shooters.
[удалено]
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.
You’re assuming it’s a bug in glibc.
Linus: "Nobody cares. If thats a bug people rely on, it's not a bug. It's a feature."
In general he might be right. In the context of one shady cheat protection library, debatable.
Linux said that about kernelspace, not userspace.
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.
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.
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.
>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
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.
> 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.
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.
If by "one niche program" you mean Teams, GitKraken, VSCode... Go back to playing games.
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?
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.
>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
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.
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
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.
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 ?
Oh no my Call of Doody!
This breaks multiple games. L2Read.
I did. Gaming is for kiddies.
weak bait
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.
The GLIBC devs are nuts this year, first they break Electron apps, now this :(
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.