Tried box64 on a Raspberry Pi 5 the other day and it worked above expectations. Except for a minor glitch with OGG audio, I got about 60 FPS in Xonotic (x86_64 emulated on AArch64).
For games in particular, the best performance comes if you use a dedicated GPU [1]. Though the CPU emulation can still be a limiting factor.
I'm able to play most 5-10 year old games that aren't tied to DRMs at 30-60 fps on a Pi [2] (and certainly on Ampere) using box64 and an AMD GPU (or Nvidia on an Ampere system), haven't spent much time with FEX-emu though.
I spent some time testing Steam with FEX on the Orion O6 using an AMD RX570. Really surprised it worked as well as it did.
Portal 2 was hitting over 100 FPS. Half-Life 2 and DOOM 2016 hovered around 60 FPS. Shadow of the Tomb Raider and Control mostly stayed above 30 FPS, while The Witcher 3 and God of War usually hung out in the low to mid 40s.
Orion O6 has so much potential, just wish Radxa had a little more focus on just getting one product launched really nicely, instead of spraying out more hardware every couple months.
Indeed, the rollout of the O6 has been disappointing. At least we have two additional companies releasing SBCs with the CD8180, so development won’t be limited to one board.
God of war runs great on my snapdragon 8 v2 or whatever x13s laptop...but gots so hot the GPU clitches since I don't think that laptop has active cooling
If it's the AxCrypt I think it is, it doesn't even run on Linux, never mind Raspberry PI or Milk-V for instance. And it's not free either. So it doesn't meet many of my requirements, unfortunately.
I'm the original author of AxCrypt. There's a new compatible iteration of it based on the original cryptography code called Xecrets, with several components. Xecrets Cli is the main fully featured command line engine, free open source GPL on https://github.com/xecrets/xecrets-cli . Xecrets Ez is a simple GUI frontend, single executable, portable. Runs on Linux, macOS and Windows. There are several more components available as nuget packages.
Very interesting! Thanks for the link, I didn't know about it and I'll have to check it out.
It still falls slightly outside of my zone of preference, though, as it's a .Net application, which limits which platforms it can be run on (I'm aiming for a tool that can readily be used on most of my devices, including on an old Raspberry Pi or a router).
Fair enough, that's a little out of main scope for Xecrets Cli.
Just for fun, I tested now to build and publish for an ARM processor running Linux (linux-arm) and the build worked fine. I don't have a device to test it on though.
So... as long as it runs Linux and has an ARM or ARM64 processor and sufficient storage & memory it could work! (It's not tiny like a pure C-program unfortunately).
Can you use PGP in the same way (I haven't tried)? Basically, symmetric file encryption based on a secret password and optionally a secret pepper file (effectively a secret key).
age is definitely more mature, and as you say, it should probably say somewhere that ezcrypt is still a hobby project (albeit a serious one).
Some motives (some of which may sound strange, but mattered to me):
* Completely public domain.
* Without any third party dependencies (not even openssl or similar).
* Don't rely on a single cipher (low trust).
* Extremely portable (should easily build for and run on anything from an M4 Mac to a Raspberry Pi to an old OpenWRT MIPS router with 32 MB RAM for instance).
* Should be easy to use (e.g. no key management, unless you want to), and composable in standard Unix ways (pipes etc).
* Security focused, obviously. E.g. software architecture-wise, minimize dependencies, properly manage files, processes and secrets, etc.
* Personally: To learn and to build something that I trust.
In a way: When the dust settles after the nuclear apocalypse, if you manage to dig out a C compiler, this is your tool. ;-)
"Don't rely on a single cipher" is an anti-goal, and a reason your hobby project won't be taken seriously. You'd be better off striking it from the list.
"Zero dependencies" is also not especially reassuring, as it implies you're using your own cipher implementations (or reference implementations).
If unanticipated issues are discovered, end users may not receive the updates in a timely fashion if, for example, the repo owner is the only committer and they're on vacation when the next Heartbleed 0day hits.
I am confident and trust the OpenSSL and LibreSSL projects each have multiple folks capable of merging and releasing critical updates.
Amazing as he is, Filippo is a single person who presumably has human needs. If he's a Terminator, though, swell, do let me know.
Ah. I was thinking the critique was about combining different crypto methods in serial; I've heard people say this is a bad idea but have never understood why.
"also known as a dependency" - There are different kinds of dependencies. The ones I'm usually concerned with are the ones that cause you headaches when you try to get the software working on an exotic platform ten years from now. I've developed software for 30+ years, and along the way I have grown a strong disliking to external dependencies (be it Python packages, Boost C++ libraries, 3rd party C libraries or a hefty Mono or Java runtime).
Thanks for the reference to BearSSL - it appears to be very much in line with my own preferred design principles.
No, I realize that (I was thinking that ssh-keygen could be used as a poor-man's authentication for some use cases - basically share a secret between sender & receiver that can be used to ensure that the message has not been tampered with). One of the reasons that I haven't implemented authentication yet is that I want to better understand the differences and nuances of different methods and use cases before deciding on a method. Recommendations are welcome.
Get rid of the weird cipher cascade and replace it either with XAES-GCM or ChaPoly. Do some research into how to handle large ciphertexts with a chunking construction. Use a well-defined construction; don't invent your own.
I have been planning to look into authentication. I didn't need it for my use cases, yet, but as you say that should be an integral part of any serious tool. I added a ticket: https://codeberg.org/ezcrypt/ezcrypt/issues/3
In the meantime, signing and verification can be done separately, e.g. with ssh-keygen, although that is a bit inconvenient (which kind of defeats one of the key points of the tool).
The idea isn't really to make the encryption stronger or to widen the key. It's a classical case of trust - if one cipher is compromised, there are others to cover for you. Also, I wanted to learn the different ciphers, and speed wasn't a top priority.
Yeah, that's why everyone writes cipher cascades. There's a reason you don't see them in any mainstream vetted cryptography. The bigger problem is that none of this is authenticated.
