spoiler

made you look

  • 0 Posts
  • 510 Comments
Joined 2 years ago
cake
Cake day: July 27th, 2024

help-circle

  • Windows is pretty much the same as Linux, it exposes the raw events from the device and it’s up to the app to handle them. Pretty sure the overlay handles that by sitting between the OS and the game and e.g. translating everything to Xbox style controls if the game needs it (And getting out of the way if it doesn’t)

    Outside of that, well Valve added support for the controller to SDL, so anything using it will be fully supported. But then the game needs to actually be using a new enough version of SDL, otherwise it’ll just see a generic controller device, and that can be hit or miss.



  • I’ve got some numbers, took longer than I’d have liked because of ISP issues. Each period is about a day, give or take.

    With the default TTL, my unbound server saw 54,087 total requests, 17,022 got a cache hit, 37,065 a cache miss. So a 31.5% cache hit rate.

    With clamping it saw 56,258 requests, 30,761 were hits, 25,497 misses. A 54.7% cache hit rate.

    And the important thing, and the most “unscientific”, I didn’t encounter any issues with stale DNS results. In that everything still seemed to work and I didn’t get random error pages while browsing or such.

    I’m kinda surprised the total query counts were so close, I would have assumed a longer TTL would also cause clients to cache results for longer, making less requests (Though e.g. Firefox actually caps TTL to 600 seconds or so). My working idea is that for things like e.g. YouTube video, instead of using static hostnames and rotating out IPs, they’re doing the opposite and keeping the addresses fixed but changing the domain names, effectively cache-busting DNS.



  • It’s been a few years since I used a Mac, but even then resource forks weren’t something you’d see outside of really old apps or some strange legacy use case, everything just used extended attributes or “sidecar” files (e.g. .DS_Store files in the case of Finder)

    Unlike Windows or Linux, macOS takes care to preserve xattrs when transferring the files, e.g. their archiver tool automatically converts them to sidecar AppleDouble files and stores them in a __MACOS folder alongside the base file in the archive, and reapplies them on extraction.

    If course nothing else does that, so if you’ve extracted a zip file or whatever and found that folder afterwards, that’s what you’re looking at.














  • The idea is that it’s left up to the windowing toolkit itself (.e.g GTK or Qt, etc.), so the compositor can focus on just compositing, which makes sense IMO as it’s how other platforms handle it (Except they have a single OS provided windowing implementation). Problem is, that leads to massive fragmentation of functionality, every app has different toolbars and features based on the toolkit they use, and requires each app to handle it, which sucks and shouldn’t be the case.

    Like in the Factorio case, it uses SDL for windowing, and SDL actually supports handling titlebars itself. But Factorio just wasn’t including the dependency that enabled it at that point, so all it took to fix it was including it and everything started working. But that’s still extra work that had to be done just to get minimum functionality, which wasn’t needed on e.g. KDE.

    I mentioned in my other response, it’s the inflexibility that’s the actual problem. Lots of apps do want CSD, or at least control over how their windows are presented, but Gnome going “you’re on your own” is the worst outcome.