Just open-sourced Apex, an experimental adaptive compressor / .apx archiver.
It picks transforms + engines per block (tournament), with optional dedup, recovery, and encryption. Still early.
In local testing on a dual-core Ryzen 3 laptop, a 12.3 GB mixed toolchain compressed in ~53s.
Day-one review caught real issues. Next:
• Atomic writes (temp file → rename)
• Cryptographic full-block hashes before dedup refs
• --exclude for paths like .git / node_modules
• Honest benchmark defaults + license metadata
• Portable encryption (no OpenSSL-path fallback mismatch)
WIP, but the core engine is real.
Site: https://t.co/uc4Vczyflp
GitHub: https://t.co/A9NVq5V2t0
Feedback, reproductions, and PRs welcome.
@ex_deus3125@shengzheyao Actually it's for running it locally on a phone but the user base for running agy on a termux terminal is non existent or very small
@ceonors@shengzheyao Not really. The web UI is more than enough for it and it runs flawlessly on old phones and we really don't need a seperate app for it. Though it would be nice but we really don't need it.
@opynrijal@shengzheyao It runs on the phone itself i suppose. We already have remote control on agy cli since v1.2.7. I don't understand why anyone would even use this to code on a phone but i suppose it's something good to have.
A backup should be a file you can copy, not a service you log into.
Apex 1.3.0 packs mixed folders: photos, dumps, source, files that are already compressed and chooses a method per chunk. One .apx on a disk, an SFTP host, or a bucket.
Open a single path out of a large archive, or mount it read-only. A second run with --base reuses unchanged chunks; the new file still extracts if the old disk is gone.
Encryption and repair stay inside the file. A 2-core laptop is enough.
https://t.co/Wy7lEQsaJ8
You do not need another cloud. You need a backup you can open by path.
Apex 1.3.0: folder → one file. Pull a single path out of a multi-gig archive. Mount it like a disk. Yesterday’s backup can seed today’s without locking you to a vendor repo.
v1.3.0 → https://t.co/Wy7lEQsaJ8
You do not need a new codec. You need the right one on each block.
Apex tries delta, BCJ, RLE, zstd, store — per block — and writes one .apx.
Cheap laptop. Fast mode. Mixed trees.
https://t.co/QVXxHm2DXj
Most archivers pick one codec and hope. Apex races the block.
2-core laptop. 12.3 GB Xcode → 4 GB in 53s. 282 MB Canterbury → 4.4 MB in 2.4s.
If your tree is mixed, one algorithm is a guess.
https://t.co/rRinNHJ1uj
I got tired of archives that lie when you Ctrl-C them.
Apex: per-block tournament compression, FastCDC dedup, atomic replace.
12.3 GB → 4.0 GB in ~53s on a dual-core Ryzen 3.
Not a benchmark war. Just a working .apx container.
https://t.co/QVXxHm2DXj
Shipped Apex v1.2.0.
Last week the ask was atomic I/O, real block hashing, --exclude, portable crypto, and cleaner benches. That is now in main!!!!!
Compress writes a sibling temp, fsyncs, then os.replace. Extract and repair only promote after CRC-32 + stream SHA-256. Kill the process mid-run and the old archive is still intact.
Also in this release:
• FastCDC gear-hash chunking (--cdc)
• BLAKE2b-256 before any dedup ref
• --exclude / -e for .git, node_modules, globs
• ChaCha20-HMAC in-process, no OpenSSL CLI
• apex benchmark --full (no 16 MB cap)
Same dual-core box as before: 12.3 GB / 142k files, \~53s compress, \~45s extract, 4.0 GB out.
Binaries for macOS, Linux, Windows.
Site: https://t.co/uc4Vczyflp
Release: https://t.co/kqlHyiPGV0
Feedback and stress tests welcome.
@sattyyouneed Prompting AI, if you don't know how to prompt it, it's like telling a architect build a house for me, and when he finishes, building, it turns out completely the opposite of what you expected!