|
This glibc argument reminds me of this entertaining github issue.
|
#
?
Aug 17, 2022 18:23
|
|
|
|
| # ? May 27, 2024 01:45 |
|
|
ExcessBLarg! posted:Exactly how is glibc supposed to emit such a warning? If you're calling open(2) on the binary and manually parsing its contents, glibc doesn't know you're reading DT_HASH. I don't know exactly what EAC does here, if it's completely manually parsing ELF or if it's using libbfd for some of it, but it's entirely possible that if glibc tried to emit deprecation warnings for this they wouldn't be triggered, or would be ignored anyways. Make DT_HASH page aligned, don't map it into the address space, install a SIGBUS handler that checks for that address range and logs a warning. If it doesn't trigger, make a statement about how you attempted to diagnose malfunctioning applications but it is difficult to detect those that go out of their way to evade your diagnostics. ExcessBLarg! posted:I think it's a stretch to say that the DT_HASH section of the binary is part of the ABI in the first place. If nothing else, EAC is certainly doing things that are far out of the norm for a traditional Linux application. Which, is fine, it's a very unique piece of software, but it's also unsurprising that this kind of thing, happens. Here's the official Linux ABI reference: https://refspecs.linuxfoundation.org/, scroll down to "ELF and ABI Standards" and click on either "System V ABI Edition 4.1" or "System V ABI - DRAFT 24 April 2001", these are the ELF gABI documents and you can find the chapter on the DT_HASH ELF section on your own. ExcessBLarg! posted:It also makes me wonder what exactly EAC does with DT_HASH anyways. If it's reading the contents for attestation purposes, that could be problematic because the loader actually use DT_GNU_HASH and so it might be possible to construct a binary that behaves differently between the EAC verification pass and runtime, and potentially lead to cheat injection. Find the real, real, no for real, really real dlsym function, apparently. Since everybody and their dog supplies their own version of dlsym to inject code into applications. ExcessBLarg! posted:If it turns out the only significant modern consumer on Linux systems is EAC I don't think it's unreasonable for the glibc folks to say "fix it" and move on. The biggest consumer of EAC itself is Valve/Steam Deck, then Valve can just keep "bad" versions of glibc out of SteamOS until EAC is updated. The fix is passing --hash-style=both to ld instead of --hash-style=gnu, so, yes.
|
|
#
?
Aug 17, 2022 18:34
|
|
|
xarph posted:This glibc argument reminds me of this entertaining github issue.  Web devs
|
|
#
?
Aug 17, 2022 18:37
|
|
|
pseudorandom name posted:They work for Red Hat and by extension IBM, and Red Hat/IBM DGAF about the Steam Deck. That would be a good point if it didn't break Shovel Knight's Linux build and that libsqueeze or w/e library as well. At any rate it sounds like more of an issue with distributors' compiler settings than with glibc per se. Hopefully Valve can come up with a proper containerized Linux runtime instead of their current LD_PRELOAD hackery but the Linux landscape does not make that easy. Last I checked they used a fork of Flatpak, but Flatpak can already handle things like the nvidia proprietary graphics driver and Flatpak applications have their own completely separate shared libraries and filesystem so I don't really know what that fork is for.
|
|
#
?
Aug 17, 2022 18:40
|
|
|
I own a deck and I just spent way too long jailbreaking an original 3ds send help
|
|
#
?
Aug 17, 2022 18:55
|
|
|
ExcessBLarg! posted:Is Valve/EAC seriously suggesting they should continue to use a 16-year deprecated feature for which they're the only modern consumer, for reasons? If Linux wants to be considered a real option for binary software distribution, yes. If not, fine, but that's why binary software should target win32.
|
|
#
?
Aug 17, 2022 19:06
|
|
|
GNU/Linux will support a stable application programming interface. Starting ... now. Whoops, sorry my bad, just had to fix a little bug back there. Alright, starting ....... now Sorry sorry, just one more little fix
|
|
#
?
Aug 17, 2022 19:11
|
|
|
I just discovered how to add icons and logos to non-steam games. Basically, just follow this video: https://www.youtube.com/watch?v=kI8kSws7aS0 Also if you right click the game in steam and select properties then click the blank square next to the name you can add an icon. If you select the game through steam you can add a custom background as well by right clicking the blank background. This is all through desktop mode. Cowman fucked around with this message at 19:25 on Aug 17, 2022 |
|
#
?
Aug 17, 2022 19:17
|
|
|
I have never once given a poo poo about cheating. The anti cheat just gets in the way of me doing stuff, either because the anti cheat misfires or crashes or clashes with av or any of these other variables. This would be a suitable hoop to jump in a tournament, not when I just want to play a video game in my underwear
|
|
#
?
Aug 17, 2022 19:25
|
|
|
pseudorandom name posted:Make DT_HASH page aligned, don't map it into the address space, install a SIGBUS handler that checks for that address range and logs a warning. If it doesn't trigger, make a statement about how you attempted to diagnose malfunctioning applications but it is difficult to detect those that go out of their way to evade your diagnostics. pseudorandom name posted:Here's the official Linux ABI reference: https://refspecs.linuxfoundation.org/, scroll down to "ELF and ABI Standards" and click on either "System V ABI Edition 4.1" or "System V ABI - DRAFT 24 April 2001", these are the ELF gABI documents and you can find the chapter on the DT_HASH ELF section on your own. Details of the ELF object format and symbol resolution are primarily pertinent to the loader, not applications themselves. Yes, the ELF format was standardized as part of SysV and described in the gABI--it's a rather encompassing document which isn't fully pertinent to systems of today in many aspects. pseudorandom name posted:Find the real, real, no for real, really real dlsym function, apparently. Since everybody and their dog supplies their own version of dlsym to inject code into applications.
|
|
#
?
Aug 17, 2022 19:26
|
|
|
Subjunctive posted:I did this but I can't detect my Deck when running Steam Link on my desktop. Did you have to configure anything on the Deck side? It should just see it and offer to pair. You might need to be on the same subnet and hosts on the network will need to be able to see each other but DNS shouldn't be involved as its all on the local network. I've done it over my phones wifi hot-spot and over my home WiFi.
|
|
#
?
Aug 17, 2022 20:18
|
|
|
Sapozhnik posted:e: do these people not have jobs at whatever company pays them to maintain core infrastructure? where if you answer your boss with "but i don't want to do that, it's not ~elegant~" then the next thing out of his mouth is "you're fired"? That attitude is a great way to develop lovely software that collapses under its own weight and becomes the unusable, calcified mess that is every awful internal system you’ve ever had to use. Changes like this happen and break stuff because trying to design a system, especially in an open ecosystem, that is bug-for-bug compatible forever is prohibitively expensive unless you abuse monopoly power like Microsoft. So the only option is to say “here’s our interface, this won’t change so target this, mess with any bits outside of this and your poo poo might break any time”, then people build poo poo on the stuff you said might break any time, and get surprised and mad when it breaks. Hyrum’s Law was mentioned before, but Hyrum’s Law is only really relevant to software as a service where users don’t have any option but to use the latest version - local software can just stay on an old version as long as you need to hook into implementation details. This does require a lot of very clear communication to your users (In this case, glibc’s users, so Valve). I recognize this isn’t helpful for users but like, Valve is more in the wrong here than the glibc devs (who also should have handled this better).
|
|
#
?
Aug 17, 2022 20:21
|
|
|
xarph posted:This glibc argument reminds me of this entertaining github issue. I love how they just quote "however" and are like "yeah there is no 'however' here, gently caress off" Very matter of fact, love it 
|
|
#
?
Aug 17, 2022 20:35
|
|
|
Couldn’t EAC in theory deploy a Linux specific version of their stuff?
|
|
#
?
Aug 17, 2022 20:38
|
|
|
There's a real cost to providing bug-for-bug compatibility for every interface-related bug that has ever surfaced. Sometimes the scope of the project or the amount of software that depends on that behavior makes the compatibility worth the effort, which is precisely why Linux has such a large number of reimplemented syscalls, or why glibc has separate implementations for every function whose internal behavior has changed in subtle ways. Sometimes, though, providing bug-for-bug compatibility doesn't make sense--the cost is too high, and the number of consumers is too low. Occasionally I'll find buggy behavior in libraries I'm developing against, and when I do I try to work around them, but I also try to detect them and implement correct behavior assuming the bug will get fixed. I then file a bug report and pay attention to my email so that if the report is resolved I'm made aware that, that's done. Is the cost to keeping the DT_HASH section around particularly high? In some ways, no, but it's also duplication of information that's no longer used by fundamental components of the system and so merely its presence may give false impression of its relevance. Had it been jettisoned years ago EAC wouldn't have made use of it and we wouldn't be here today. So somewhere between "it was kept around too long" and "they didn't keep it around long enough" is people getting pissed off.
|
|
#
?
Aug 17, 2022 20:39
|
|
|
Arcsech posted:So the only option is to say “here’s our interface, this won’t change so target this, mess with any bits outside of this and your poo poo might break any time”, then people build poo poo on the stuff you said might break any time, and get surprised and mad when it breaks. The issue that I think is relatively recent is that most code is now held together with stack overflow posts from five years prior, and no one ever checks documentation or changelogs (often they don't even know where it IS). We have software that the author doesn't even understand and thus they wouldn't be able to recognize a breaking change, let alone test any of their poo poo against beta upstream libraries. So a critical security vulnerability comes in and suddenly your change surface is significantly larger, and you end up with even more brittle poo poo. Stack Overflow is a double edged sword and I'm starting to feel like the edge facing the user is sharper. But until there's a work ethic in open source involving constant documentation improvements and an easy way to find it (Google will no longer help you*) software only gets worse. I have a ticket at work with the group that manages an API because the errors returned to consumers include a URL pointing to the relevant documentation. Except the site changed owners and now all the links the API produces just 302 to the top of our developer portal, where you are at the mercy of... a google search box! "We don't have the resourcing to chase down every link and 302 it, and we also can't change the API output." * asking google where the documentation for a library that doesn't have a corporate maintainer the size of Red Hat or Facebook just gets you SEO link mill trash that plagiarizes the wrong answers from stack overflow.
|
|
#
?
Aug 17, 2022 20:49
|
|
|
MarcusSA posted:Couldn’t EAC in theory deploy a Linux specific version of their stuff? Worth noting that, thats also the reason that developers have to opt in to Proton compatibility because, Linux EAC is a pretty different thing and arguably less secure than the already kinda questionably effective Windows rootkit version.
|
|
#
?
Aug 17, 2022 21:14
|
|
|
Video games are the ultimate legacy software because they get released, updated maybe a few times in the months after release, then abandoned. That binary is now an immutable fact of life that is never going to change and you can choose to accommodate that or you can choose not to, but you're not going to be able to ask a game studio that went bankrupt ten years ago to please not depend on some implementation detail in glibc in their game's Linux port that they went out of their way to depend on. I agree that keeping some vaguely-defined set of user space system libraries' visible implementation details bug-for-bug compatible in every future release until the end of time is probably a non-starter, which is why a fully containerized game runtime would be a better way of providing a native Linux development target: Valve can release a new "edition" of their containerized Steam Linux runtime for game developers to target every few years and then maintain bug-for-bug compatibility in all of those editions until the end of time if they and their 30% cut of every sale on their platform have the manpower and resources to keep doing that. The only part of the system that cannot be containerized and co-installed side by side is the Linux kernel underpinning everything, but thankfully the kernel people have (1) a very hard interface boundary that keeps their callers at arm's length which is enforced by a CPU transition into supervisor mode and (2) an ironclad commitment to maintaining compatibility along that boundary, recent eBPF bullshit notwithstanding. Alternatively they could piggyback off the WINE project's and Microsoft's back-breaking efforts to provide an eternally stable binary programming interface that is reasonably amenable to video game development and treat the Win32-API-as-defined-by-its-actual-behavior as a development target for both Windows and Linux. Which I think is a reasonable policy and which is why I think Linux as an actual native video game development target is ultimately a non-starter. There's something of a parallel with Linux ACPI support here. There is a written ACPI specification that nobody pays the slightest attention to: the de-facto standard for ACPI is "Whatever Windows 7, 10, 11, etc does". The Linux implementation of ACPI pretends to be a recent version of Windows (10? let's say 10 for the sake of argument) and behaves exactly like Windows 10 and any behavior that does not match the behavior of Windows 10 is considered to be a Linux bug. One of those behaviors is that Linux pretends not to be "Linux" even though a lot of ACPI firmwares have (or had, at one point) OS-specific instructions for "Linux". Nobody pays the slightest attention to any written standard, they copy-paste poo poo from Stackoverflow and once they have it working they throw it over the wall and never support it again. Crying about that state of affairs does nothing to change it.
|
|
#
?
Aug 17, 2022 21:15
|
|
|
Sapozhnik posted:Video games are the ultimate legacy software because they get released, updated maybe a few times in the months after release, then abandoned. That binary is now an immutable fact of life that is never going to change and you can choose to accommodate that or you can choose not to, but you're not going to be able to ask a game studio that went bankrupt ten years ago to please not depend on some implementation detail in glibc in their game's Linux port that they went out of their way to depend on. The EAC debacle is a red-herring. The problem doesn't stem from EAC making use of a glibc-provided functional interface that has suddenly changed out from underneath it, but rather EAC trying to be entirely too clever in performing symbol lookups by parsing the binary itself. Even this is fine, as long as you specially-build your glibc to support the old style, or you run your EAC application in a container (flatpak, even) with glibc built using the compatible object format. The rest of what you say I agree with. What frustrates me is that folks are misconstruing the EAC debacle into assuming that glibc makes no effort for compatibility when it's something they very explicitly do and have taken seriously for a long time.
|
|
#
?
Aug 17, 2022 21:34
|
|
|
Okay but again, what about like, Shovel Knight's Linux build or whatever. As far as I am aware that does not use EAC, it relies on these ELF symbol tables for some other reason.
|
|
#
?
Aug 17, 2022 21:36
|
|
|
I don't know what's up with Shovel Knight either, but it would be interesting to find out. Generally speaking applications don't have a reason to parse the ELF tables themselves, that's the loader's job. Applications that need to load symbols generally use the libdl APIs (which, admittedly, can be shimmed to thwart DRM and anti-cheat software).
|
|
#
?
Aug 17, 2022 21:55
|
|
|
Disappointing Pie posted:I used emudeck to setup the emulators but no extra buttons seem to be mapped? The DS emulator I can’t swap screens, I want to be able to map fast forward and or save states for SNES and Genesis to the back buttons. Are y’all just going into the actual emulators in desktop mode and changing settings in there?
|
|
#
?
Aug 17, 2022 22:19
|
|
|
Sapozhnik posted:ELF symbol tables this sounds like some lord of the rings poo poo
|
|
#
?
Aug 17, 2022 22:50
|
|
goku i won't do what u tell me
|
Dang I put a deposit in on 5/28 and checked the thing:quote:Results: I had no idea it was that stacked  I came to the thread thinking it would be happening soon
|
|
#
?
Aug 17, 2022 23:19
|
|
|
KRILLIN IN THE NAME posted:this sounds like some lord of the rings poo poo DWARF is a popular debugging data format that was created for ELF… Of course it's a LotR reference, these are nerds.
|
|
#
?
Aug 17, 2022 23:22
|
|
|
ExcessBLarg! posted:Is the cost to keeping the DT_HASH section around particularly high? In some ways, no, but it's also duplication of information that's no longer used by fundamental components of the system and so merely its presence may give false impression of its relevance. They should take it out of the Linux Foundation spec references above, and say that there’s no uniform representation of the symbol table, before they start worrying about implying that something is relevant which is, it turns out, relevant to existing software.
|
|
#
?
Aug 17, 2022 23:25
|
|
|
Antigravitas posted:DWARF is a popular debugging data format that was created for ELF… Christ, I’ve been doing Linux poo poo since 0.99 days and I never made that connection before. Thanks, I guess.
|
|
#
?
Aug 17, 2022 23:26
|
|
|
Tenkaris posted:Dang I put a deposit in on 5/28 and checked the thing: I mean most of us waited just over a year soooo.
|
|
#
?
Aug 17, 2022 23:27
|
|
|
Disappointing Pie posted:I mean most of us waited just over a year soooo. Yeah I see that now. I think I must have read the year wrong on the page because I thought it said September or October. I waited for the raving reviews, I wasn't going to commit before it came out but I also wanted to feel comfortable I had enough savings for when I had to pay 
|
|
#
?
Aug 17, 2022 23:31
|
|
|
Tenkaris posted:Dang I put a deposit in on 5/28 and checked the thing: You might already know this, but you are not waiting 268 days for it. That number is how many days worth of pre-orders they have to go through. They fulfilled 15 "days" of pre-orders on Monday. All orders will be completed before the end of the year so worse case 4 months, but at the rate they are getting these things out I'd put a guess you'll be before October.
|
|
#
?
Aug 17, 2022 23:35
|
|
|
Athanatos posted:You might already know this, but you are not waiting 268 days for it. That number is how many days worth of pre-orders they have to go through. They fulfilled 15 "days" of pre-orders on Monday. Yeah I was surprised to see there's still like 270 days worth, but thinking more about it I guess the number per day varies, like the holiday season days will probably be bulkier, etc. but glad to know the September estimate they gave me is still a realistic hope! Soysaucebeast posted:I would double check to see what the official Steam page says. They said recently that everyone who already had their orders in by [date I can't remember but it was only a few weeks ago] would get theirs by the end of this year. I just checked mine, and I ordered the 512gig on 5/8/2022 and I'm scheduled to get it Q4 of 2022. You should be right around there too. Yes you're right, it's still projected in Q4. Great news! 
Tenkaris fucked around with this message at 01:41 on Aug 18, 2022 |
|
#
?
Aug 17, 2022 23:44
|
|
|
Installed the Hall effect sticks today. Process went great, except I forgot to remove my 512gb memory card and guillotined it. 
|
|
#
?
Aug 18, 2022 00:03
|
|
|
i think i've finally come around on streaming content. just helped someone through hemwick charnel lane using chiaki to stream from my ps5. bloodborne goty
|
|
#
?
Aug 18, 2022 00:10
|
|
|
I got my deck and so far I’m so jazzed. Alan Wake shows as great on deck but won’t launch. Arkham Asylum is supposed to work with ProtonGE but didn’t launch either. So far only Aperture desk assistant and Mark of the Ninja have worked for me.
|
|
#
?
Aug 18, 2022 00:13
|
|
|
Tenkaris posted:Dang I put a deposit in on 5/28 and checked the thing: I would double check to see what the official Steam page says. They said recently that everyone who already had their orders in by [date I can't remember but it was only a few weeks ago] would get theirs by the end of this year. I just checked mine, and I ordered the 512gig on 5/8/2022 and I'm scheduled to get it Q4 of 2022. You should be right around there too.
|
|
#
?
Aug 18, 2022 00:42
|
|
|
Subjunctive posted:They should take it out of the Linux Foundation spec references above, and say that there’s no uniform representation of the symbol table, before they start worrying about implying that something is relevant which is, it turns out, relevant to existing software. Full disclosure: I recently worked on a project that required similar libdl shenanigans and a deep dive into the .gnu sections of compiled libraries. I found the documentation lacking as well, but with the glibc source and some empirical testing was able to work my way through it pretty well. That experience may inform my opinions here.
|
|
#
?
Aug 18, 2022 00:48
|
|
|
either way it sucks that games with EAC can't be played on Deck. would like to try lost ark at some point but apparently it's broken and won't get past the title according to protondb
|
|
#
?
Aug 18, 2022 01:21
|
|
|
The 7th Guest posted:either way it sucks that games with EAC can't be played on Deck. would like to try lost ark at some point but apparently it's broken and won't get past the title according to protondb
|
|
#
?
Aug 18, 2022 01:48
|
|
|
MarcusSA posted:https://www.emudeck.com/ Cowman posted:Emudeck is what you need. It doesn't provide a BIOS/Firmware for the emulators that need it due to legal reasons but they're easy to find and not difficult to install. Thanks for all this! Very useful. Although before I get that far, I seem to be having a problem with the deck connecting to my wifi network. It connects to the hotspot on my phone just fine but the home network I keep getting a "cannot connect" error, even after resetting the network, going into developer mode and disabling the power management for the wifi, etc. Is there a useful guide for how to effectively resolve this?
|
|
#
?
Aug 18, 2022 03:05
|
|
|
|
| # ? May 27, 2024 01:45 |
|
|
You may need to set your WiFi to 2.4GHz because I've heard the Deck has problems connecting to some 5GHz networks.
|
|
#
?
Aug 18, 2022 03:13
|
|