FWIW, I used gmvault a long time ago (N.B. I typically deactivated individual .eml.gz compression in favor of a more global compression with a squashfs archive of the gmvault backup). Since I found not very practical to search through that archive, I developed https://github.com/karteum/gmvaultdb in order to convert it to a local sqlite DB (I made it for personal use and chose to keep the schema simple to have simple queries for my case. If the DB was to grow bigger I'd probably use a different schema e.g. to place the contacts/from/to/cc in separate tables... I also chose to extract attachments directly on the filesystem rather than put them in the DB - which enable direct access and deduplication)
(N.B. it can also process the mbox produced by https://takeout.google.com/ with the caveat that in some case Takeout permanently losses some information because of a bug with older encodings so I'd always prefer a backup using gmvault or imap)
Google Pixels are the few devices that enable not only to unlock the bootloader but also the ability to flash your own keys and still have secure boot together with full kernel sources availability (which is why Grapheneos only support them as far as I know).
As far as I know Mediatek (and vendors that use those chips) are usually not good with regards to GPL Compliance, which means no Lineageos if kernel sources are not available...
I discovered JSON Binpack recently, which works either schemaless (like msgpack) or - supposedly more efficiently - with a schema. I haven't tried the codebase yet but it looks interesting.
Beware when relying on Google Takeout for e-mail backup if you have old e-mails in other encodings than utf-8 : it permanently breaks some characters, which are replaced by 0xEFBFBD (that issue does not occur when doing backup with IMAP or GMVault)
> Also, given that this is the author's work laptop, what's the economic justification for not investing in the primary tool you use for work?
The author explains that there are motivations not related to money (we live on a finite earth, the manufacturing of a laptop encompass a considerable amount of energy and raw materials for mining, etc).
If you want vertical tabs, built-in adblocker, and more generally are looking for a lightweight and free (as in free speech and as in free beer) browser, you may look at https://www.falkon.org/ (made with QTwebengine i.e. Blink)
I was also thinking about extracting the MPQ on-disk e.g. "foo.mpq" -> ".foo.mpq.extracted/..." (which - to my understanding - would lead to a lot of deduplication even just with jdupes).
N.B. depending on the requirements with regards to read performance, you could design a FUSE filesystem that would transparently reconstruct the MPQ on-the-fly.
Of course, I guess all of this would be much slower than being able to use inherent btrfs features as the author of the post wishes, but at least it would be independent from btrfs :)
prying apart the MPQ file into it's parts and writing them down to disk is at the moment probably the strongest contender for my solution.
it will cause the parts to be block aligned, be able to be hardlinked and cut down on metadata and improve performance (same inode when hardlinked).
only thing i need in this case is to have a script to reassamble those extracted ones into the original MPQ archives, which have to match byte-by-byte to the original content ofc.
extracting them into it's distinct parts also allows to access the contents directly, if so desired, without needing to extract them on demand (some people wanna look up assets in specific versions).
these distinct parts can then additionally be deduplicated on block level as well.
Maybe you can use it to decompress some files and assess how much disk space you can save using deduplication at filesystem level.
If it's worth the effort (1 mean, going from 1TiB to 100-200 Gib) I would consider coding the reassembly part. It can be done by a "script" fist, then can be "promoted" to a FUSE filesystem if needed.
