Apple's Weather app has an animated background, glassy views, and nice animations like water droplets on the glassy views when it's raining. So rendering all that on a 4k or more display at 10bit depth is going to consume a bit of RAM. However I guess it can surely be improved to make it consume less RAM.
Snow Leopard shipped a new 64-bit Cocoa Finder too, but no one noticed because it was almost a pixel perfect and behaviour perfect copy of the previous one.
Of course, but that works only if the files are already in the same partition. A dmg is a virtual image, even if it's stored in the same partition, once mounted it acts like another partition.
SteamOS leverages namespaces via pressure-vessel already. The problem exists exclusively on Windows. Paravirtualized drivers introduce API incompatibility issues and decades of cumulative engine infrastructure made for Windows using the Win32 API means nobody wants to swap over to using UWP and thus AppContainers are a non-starter (and that's without getting to sacrificing Wine/Proton compatibility).
The native isolation mechanisms like silos are things that require wrangling by professional sysadmins, I didn't even know they existed until I started writing this post. The real question to be asking is why is sandboxing so bad on Windows? Despite some searching, I still have no conclusive answer as to how to go about filesystem isolation in Win32-space, or if it's even possible.
Sandboxing is quite easy (user-wise), once you install the sandbox system. By default it allows only a single sandbox, and with small `.wsb` file you can drive what's visible from the host, whether the GPU should be active, etc. - https://learn.microsoft.com/en-us/windows/security/applicati...
It's great for testing, and Sandbox is just the tip of the iceberg of what Windows Containers support
- e.g. maybe someone can come up with "launcher" that goes through it (somehow).
Ummm, yeah, but Windows Containers is windows Pro and Enterprise only (security is an optional, paid extra on windows), and only for these using Hyper-V (meaning Virtual Box users are excluded).
They are? Games need pretty much all the performance they can possibly get. Can you sandbox them without having a performance impact?
Consider that people pay a $300 premium to get ~10% better performance (buying an RTX 5080 instead of a 5070 Ti).
Personally I know that sometimes closing the web browser in the background makes my game run better - that web browser doesn't even interact with the game! Would a sandbox have a smaller impact?
Buying a better GPU improves your graphics performance and that's basically unrelated to the area where a sandbox impacts performance.
Killing your web browser is probably just lowering memory pressure?
Sandboxes add overhead to syscalls. It's kind of similar to running under Wine, which also adds significant syscalls overhead. Wine also has a much more impactful DirectX translation layer, so your sandbox performance would be probably be much better than the Wine performance.
PC games tend to be the reverse: they demand control over the machine, in order to try to detect or prevent being run alongside various forms of cheating software.
They also need low-latency access to the GPU, which I suspect is a fertile vector for privilege escape exploits.
Only a relatively small (but popular) subset of games use anticheat. Most games -- including the one in this article -- could theoretically run in a sandbox.
Even games with strong anticheat could benefit from sandboxing, as the anticheat mechanisms that need access outside the sandbox represent a much smaller surface area for exploits than the entire game.
In theory, sandboxing mechanisms could even be used to improve anticheat.
What I always sort of assume the endgame could be for highly competitive Windows games is something akin to cartridge or bootable floppy games from the 8-bit era, where games would install into or be supplied as disk images containing locked-down Windows installations that only permit signed (and possibly whitelisted) drivers and whitelisted applications, which would include the game and a small number of other approved applications like Discord, MS Edge and possibly selected third-party browsers, and support software for hardware like GPUs and gaming input devices, which Windows would then boot to run the game, either on bare metal or in an isolated VM.
Proton is just emulation, and it will happily expose the underlying host system to the running game software. In particular the filesystem and some peripheral devices. However, Valve is moving towards sandboxing in Steam. You can already run the whole thing with a flatpak sandbox, and valve themselves are using ostree. With srvio is possible to run the whole thing in a throwaway windows vm while the graphics card is passed through
Anything that wants to traverse your filesystem could do so trivially from a wineprefix, but stuff like sniffing your browser extensions might be harder depending on the technique.
I've formally studied gamedev, but haven't done anything in over a decade, but even before you get to the thorny issue of anti-cheat sustems, games rely on running at a(n often very) low level and doing unconventional things. I imagine they're one of the hardest things there are to sandbox without causing massive levels of breakage. But someone more knowledgeable about either side of the equation (sandboxing and/or game development) might be able to shed more light.
Windows has a lot of powerful sandboxes. A lot of them Windows maybe made too easy to opt-out from and/or defaulted them to opt-in rather than opt-out which makes them things that developers need to learn or developers try to avoid or developers don't think they need.
Safari, or better, macOS and iOS include a software AV1 decoder (libdav1d), but it's used only to decode avif, and to generate file previews in Finder.
It's still middle-click in my muscle memory from the Windows XP days!
God, I used to be _really_ into Minesweeper.
One of the earliest games I made back in college was a 3D Minesweeper cube. I remember being really proud of one little detail – the detection and automatic resolution of ambiguous clues that would require guessing, which always annoyed the heck out of me in every other version of Minesweeper.
Oh, I see - double clicking only works when you have already marked the correct number of adjacent mines. I didn't remember that's how it worked in the original.
I also never knew it was called "chording", that's worth an explanation.
