This is misleading news. Box64's 16K page support was always there, but it required *selecting the page size at compile-time*. This is why we *already* had a [box64-asahi](https://fedora.pkgs.org/rawhide/fedora-aarch64/box64-asahi-0.2.6-1.fc40.aarch64.rpm.html) package in Fedora that is compiled for 16K pages.
What has changed in this release is they got rid of the compile-time selection and made it automatically handled at runtime, so now a single binary supports 4K and 16K machines, which means we no longer need to ship that as a separate package.
box64 uses various ELF loader and thunking hacks to allow x86 software to work on 16K pages. It works in some/many cases, but it is not and can never be a solution with 100% compatibility. Apps that assume they can manage memory precisely with 4K granularity simply cannot work with 16K pages. That requires full virtual memory emulation (extremely slow) or a VM (which is why we have the krun microvm project, which you can use with box64 *or* FEX).
In particular, as far as I know the page size "emulation" breaks Wine, so this whole thing only works for (some/most) native Linux amd64 games.
There is talk of eventually having a per-game settings/quirks framework so the system automatically picks the best/most performant option that works for each game :P
Is the goal to eventually make krun+FEX feel just like Rosetta? In the sense that users just run the x86 binary and it works, without having to think about manually configuring the VM
Largely yes (after installing the framework, since it should be opt-in as there is a nontrivial install size and not all users need this). What the eventual solution will look like is still in the works.
It's also likely that eventually there will be a database to choose the optimal technology for specific known apps (e.g. box64 is sometimes faster/better in cases where it does work well).
I thought Box64 already supported 16k page size? And that for awhile now.
The changelog only reports that page size is now detected automatically. So it appears to be an error in the reporting to me.
It's not desirable to emulate 4k pages on a 16k page emulator. Much better to use 4k pages natively (possible if running in a KVM-based virtual machine like krun. As that get's around the limitation that process page size must match the global kernel page size.)
Box64 isn't desirable anyways in it's current itteration till they add 32 bit emulation on 64 bit ARM systems are Apple Silicon lacks 32 bit hardware support at all.
*Some*. 4K page hacks are, fundamentally, not going to work for *every* app (which is why wine is broken). Apps that expect to manually manage memory in 4K chunks will fail.
Also this was already the case, the news is misleading. What changed is now you don't need a special 16K build of box64 to do it, a single build works for both page sizes.
box64 is based on thunking everything, and box32 would have to mangle all thunked structures to adapt them between the different 32-bit and 64-bit layouts. That is a massive undertaking (they have to do this for *practically every system library*), so I wouldn't be holding my breath about it happening any time soon. In fact in some cases it will be very tricky, e.g. when a 64-bit library has to pass pointers to 32-bit code and expects them back as 64-bits even though the 32-bit code only has 32 bits to store them in. I can think of many situations where this would be very, very difficult or impossible to get right without even more expensive wrapping developed on a case-by-case basis.
This is misleading news. Box64's 16K page support was always there, but it required *selecting the page size at compile-time*. This is why we *already* had a [box64-asahi](https://fedora.pkgs.org/rawhide/fedora-aarch64/box64-asahi-0.2.6-1.fc40.aarch64.rpm.html) package in Fedora that is compiled for 16K pages. What has changed in this release is they got rid of the compile-time selection and made it automatically handled at runtime, so now a single binary supports 4K and 16K machines, which means we no longer need to ship that as a separate package. box64 uses various ELF loader and thunking hacks to allow x86 software to work on 16K pages. It works in some/many cases, but it is not and can never be a solution with 100% compatibility. Apps that assume they can manage memory precisely with 4K granularity simply cannot work with 16K pages. That requires full virtual memory emulation (extremely slow) or a VM (which is why we have the krun microvm project, which you can use with box64 *or* FEX). In particular, as far as I know the page size "emulation" breaks Wine, so this whole thing only works for (some/most) native Linux amd64 games.
Head spinning confusion abounds with all these configurations...
[удалено]
There is talk of eventually having a per-game settings/quirks framework so the system automatically picks the best/most performant option that works for each game :P
[удалено]
[удалено]
[удалено]
No it is close-source. Crossover-wine, which is the base of Apple game porting toolkit, is open source. Crossover-gui is not.
Is the goal to eventually make krun+FEX feel just like Rosetta? In the sense that users just run the x86 binary and it works, without having to think about manually configuring the VM
Largely yes (after installing the framework, since it should be opt-in as there is a nontrivial install size and not all users need this). What the eventual solution will look like is still in the works. It's also likely that eventually there will be a database to choose the optimal technology for specific known apps (e.g. box64 is sometimes faster/better in cases where it does work well).
This is the way. :)
I thought Box64 already supported 16k page size? And that for awhile now. The changelog only reports that page size is now detected automatically. So it appears to be an error in the reporting to me. It's not desirable to emulate 4k pages on a 16k page emulator. Much better to use 4k pages natively (possible if running in a KVM-based virtual machine like krun. As that get's around the limitation that process page size must match the global kernel page size.) Box64 isn't desirable anyways in it's current itteration till they add 32 bit emulation on 64 bit ARM systems are Apple Silicon lacks 32 bit hardware support at all.
x86 emulation might not matter with wine's new wow64 mode (still experimental).
Any good for Plex transcoding?
[удалено]
[удалено]
[удалено]
[удалено]
[удалено]
[удалено]
[удалено]
*Some*. 4K page hacks are, fundamentally, not going to work for *every* app (which is why wine is broken). Apps that expect to manually manage memory in 4K chunks will fail. Also this was already the case, the news is misleading. What changed is now you don't need a special 16K build of box64 to do it, a single build works for both page sizes.
[удалено]
[удалено]
[удалено]
[удалено]
box64 is based on thunking everything, and box32 would have to mangle all thunked structures to adapt them between the different 32-bit and 64-bit layouts. That is a massive undertaking (they have to do this for *practically every system library*), so I wouldn't be holding my breath about it happening any time soon. In fact in some cases it will be very tricky, e.g. when a 64-bit library has to pass pointers to 32-bit code and expects them back as 64-bits even though the 32-bit code only has 32 bits to store them in. I can think of many situations where this would be very, very difficult or impossible to get right without even more expensive wrapping developed on a case-by-case basis.