CompactGUI VS rage

You can chuck compact.exe at it by hand (use the /exe option), or if you'd prefer to avoid the command line there's my Compactor tool, or the venerable CompactGUI.

Look into compact. Or the tool compactGUI. It uses windows inbuilt compression which doesn't impact performance noticably. The less well optimised a games files are the more space you get back. For many games you get nothing, maybe couple mb per gb. But for things like Ark? Install went from 186.5gb to 68.8gb. Runs just as fine no problems. But takes up a third of the size so it's absolutely noticable and demonstrateable that filesizes are in certain circumstances a result of lazy dev work

You can also just use compactGui smaller filesizes without having to remove dialogs or cutscenes or anything. Obviously how much space is regained depends on how well it was compressed originally. With triple A titles perhaps getting 10% back, while things like ark can literally be shrunk by hundreds of gigs.

> This claim needs some real world evidence to back it up (and usually it's not about a performance impact, but instead a perceived image quality impact).

We're talking lossless compression here, so image quality is not the issue.

Fortunately someone else has already done this research. There's a tool for Windows to control the compact.exe behavior for individual folders called CompactGUI: https://github.com/IridiumIO/CompactGUI

They maintain a database of compression results here: https://docs.google.com/spreadsheets/d/14CVXd6PTIYE9XlNpRsxJ...

Reductions in storage use of greater than 50% are so common that they're hardly even worth remarking on. My experience with compressing a bunch of games is that the biggest gains come from compressing bloated asset packs. Hard to know what else could be taking up more than 50% of the storage space in a particular game.

*For anyone curious, using CompactGUI is the easiest way for average users

You can claw back a lot of it by marking the folder as compressed, or using Compactor/CompactGUI periodically.

I have already built this into a small feature in my app, but I do plan to integrate it deeper and bake it into the core functionality soon. Which should be another interesting problem to solve as the app has integrated client-side encryption using Age (rage (rage-wasm)). But that's for another day...

_o/ hi all, age author here!

The OP link is the spec, here's a few other things you might find interesting

- the Go reference implementation https://age-encryption.org

- the Go library docs https://pkg.go.dev/filippo.io/age

- the CLI man page https://filippo.io/age/age.1

- an interoperable Rust implementation by @str4d https://github.com/str4d/rage

- a YubiKey plugin by @str4d https://github.com/str4d/age-plugin-yubikey

- the draft plugin protocol specification (which we should really merge) https://github.com/C2SP/C2SP/pull/5/files?short_path=07bf8cc...

- a Windows GUI by @spieglt https://github.com/spieglt/winage

- a discussion of the authentication properties of age https://words.filippo.io/dispatches/age-authentication/

- a discussion of a potential post-quantum plugin https://words.filippo.io/dispatches/post-quantum-age/

- a password-store fork that uses age instead of gpg https://github.com/FiloSottile/passage (see also: how I use it with a YubiKey https://words.filippo.io/dispatches/passage/)

I just added rage (https://github.com/str4d/rage) support, which does support pinentry, see https://github.com/anticomputer/age.el#known-issues for an example of how to use rage instead.

Really appreciate this article. It's a little snarky but it hits the mark and encourages people to try Age, which is a pretty awesome little tool.

https://age-encryption.org/v1

I'm not convinced that whole-disk encryption is sensible for most threat models, but I use the built-in FileVault on macOS (under the reasoning that, at the very least, it can't really hurt).

On Linux, I use age[1] (specifically, rage[2]) to encrypt sensitive files. I wrote a secret manager that uses the latter as an encryption backend[3], and I use `rage-mount` to mount (read-only) views of encrypted archives.

[1]: https://github.com/FiloSottile/age

[2]: https://github.com/str4d/rage

[3]: https://github.com/woodruffw/kbs2

I will admit that the "market" for this software is relatively saturated, that's why Dexios aims to stand out. Everything of interest is covered in the documentation, and the codebase itself is relatively easy to read (trying to understand the source of a tool such as rage will probably give headaches).

Anyone have any thoughts on choosing between this and rage?