https://www.gamingonlinux.com/2024/05/microsofts-new-recall-ai-will-take-screenshots-of-everything-you-do-freaky/

https://www.microsoft.com/en-gb/windows/copilot-plus-pcs#faq2

I don’t play TF2, but I thought basically all hl2 -family games were updated to 64bit ages ago… apparently this wasn’t the case :o

Any of the other games running the same engine still in 32bit land?

amd cpu, but nvidia gpu, so as far as I’d understand, not using ACO then?

yep, I’m aware. I just haven’t observed* any compilation stutters - so in that sense I’d rather keep it off and save the few minutes (give or take) on launch

*Now, I’m sure the stutters are there and/or the games I’ve recently played on linux haven’t been susceptible to them, but the tradeoff is worth it for me either way.

well, I do have this one game I’ve tried to play, Enshrouded, it does do the shader compilation on it’s own, in-game. The compiled shaders seem to persist between launches, reboots, etc, but not driver/game updates. So it stands to reason they are cached somewhere. As for where, not a clue.

And since if it’s the game doing the compilation, I would assume non-steam games can do it too. Why wouldn’t they?

But, ultimately, I don’t know - just saying these are my observations and assumptions based on those. :P

turning it off will wipe the cached shaders. That cleaned up like ~40 GB (IIRC) for me, without any noticeable difference in performance, stability or smoothness. Though my set of games at the time wasn’t all that big: path of exile, subnautica: below zero, portal 2 and some random smaller games.

Overall I’m still getting used to the Steam “processing vulkan shaders” pretty much every time a game updates, but it’s worth it for the extra performance.

That can be turned off, though. Haven’t noticed much of a difference after doing so (though, I am a filthy nvidia-user). Also saving quite a bit of disk space while too.

doesn’t seem like there’s any assets in there (textures, music, sounds, videos…), just the code, so the footprint of it is fairly small just because of this.

Exactly that. Awesome and thanks.

Now, aggressive waiting for the updates begins

am I correct to assume this is the thing that’ll fix eg. Steam going full seizure mode under wayland + nvidia?

It’s not even limited to nvidia, I also get it on intel igpu (i5-2320, ancient, I know).

no arguments there. Still, I kinda feel that raising the limit high enough to effectively turn off the limit is probably bit overboard. But, if it works, it works, but the kernel devs probably put the limit in place for a reason too.

On one hand, I’d assume Valve knows what they’re doing, but also setting the value that high seems like it’s effectively removing the guardrail alltogether. Is that safe, also what is the worst that can happen if an app starts using maps in the billions?

Hastily read around in the related issue-threads and seems like on it’s own the vm.max_map_count doesn’t do much… as long as apps behave. It’s some sort of “guard rail” which prevents processes of getting too many “maps”. Still kinda unclear what these maps are and what happens is a process gets to have excessive amounts.

That said: https://access.redhat.com/solutions/99913

According to kernel-doc/Documentation/sysctl/vm.txt:

• This file contains the maximum number of memory map areas a process may have. Memory map areas are used as a side-effect of calling malloc, directly by mmap and mprotect, and also when loading shared libraries.
• While most applications need less than a thousand maps, certain programs, particularly malloc debuggers, may consume lots of them, e.g., up to one or two maps per allocation.
• The default value is 65530.
• Lowering the value can lead to problematic application behavior because the system will return out of memory errors when a process reaches the limit. The upside of lowering this limit is that it can free up lowmem for other kernel uses.
• Raising the limit may increase the memory consumption on the server. There is no immediate consumption of the memory, as this will be used only when the software requests, but it can allow a larger application footprint on the server.

So, on the risk of higher memory usage, application can go wroom-wroom? That’s my takeaway from this.

edit: ofc. I pasted the wrong link first. derrr.

edit: Suse’s documentation has some info about the effects of this setting: https://www.suse.com/support/kb/doc/?id=000016692

I’m kinda amazed it wasn’t DOOM again. Damn cool project!

worked fine on my android phone, using Connect.

worked fine on firefox & linux, the file shows as .webp to me.

Decided to investigate this a bit: when opened to new window, the image url has ?format=webp query argument, if I change that to ?format=jxl then it breaks as the server actually provides a .jxl file. At least I had to TRY to break it :P

% file c6ca4c8c-20a2-4105-8e6c-833d8c7d3e52.*
c6ca4c8c-20a2-4105-8e6c-833d8c7d3e52.jxl:  JPEG XL codestream
c6ca4c8c-20a2-4105-8e6c-833d8c7d3e52.webp: RIFF (little-endian) data, Web/P image, VP8 encoding, 623x700, Scaling: [none]x[none], YUV color, decoders should clamp

hunter2

Its pretty close, but ideally I'd want to have it fit fin/swe layout without using modifiers to type ö and ä, and have them more or less where they'd be on normie layout. (I can live without å, so that already gives 1 key more leeway).

So far pretty much no ortho split allows this, I think. Unless I move enter key to the thumb keys or so. But then again that might be the default for eego/split keebs anyway, I dunno.

Going to have to read up on these a bit more.

oh wow. I have preonic, but I've more or less given up on learning to type with it. It's way too narrow. I like the concept but a split ortho would be better, as I wouldn't have to "hunch down" on it so much.

Fairly common to use en/us-layouts with highend mechanical keybards, as parts for those are more readily available.

But outside of the mech keebs or other niches, yea, people use the regional keyboard variants. Because it's just easier if you can see the weirdo ümlâuts/etc regional characters on the keycaps when you're not a touch typist. Over here (finland) it's actually pretty hard to even get ansi/us layout keyboard unless you really go about your way and seek one out, basically all keyboards in stores are fin/swe iso layout. I'd assume the same is true to most euro countries.