On Fri, Jul 17, 2026 at 5:26 PM Undescribed Horrific Abuse, One Victim & Survivor of Many <gmkarl@gmail.com> wrote:
On Fri, Jul 17, 2026 at 5:25 PM Undescribed Horrific Abuse, One Victim & Survivor of Many <gmkarl@gmail.com> wrote:
https://ar.anyone.tech/MQnlj4RjTBOKRRVyHIReBp-EGcb2LJ-W_W79DlC0D0s#IUGUgoMT4...
got a funny different experience recently that's a small blocker for using the internet on my misbehaving phone-like device
i was excited to publish my first sha-256 git repository at https://codeberg.org/xloem/ev which happened a day or two ago. right now it's just a mitmdump/mitmproxy script for extracting EV charging locations and prices from use of the chargepoint or plugshare (git push pending on plugshare) driver websites (or apps if you can access the tls). it contained some unique code for processing my public mitmdump packet logs which handles the decoding errors from interwoven error messages and resumes. the handling code is very simple it just readlines() to the next line break and tries again.
[some mistake ..... :s :s [umm my public packet log uploads got blocked or something after publishing that. pretty quickly
i try to only use my phone's internet when public packet logging, so it has made it hard to use the internet. [--..
ohhh :D :s well it is true yes that it turns out these aren't "packet logs" and a better solution would be to log the tls data and instead do a filtered tcpdump pcap log. i didn't know hadn't looked, common situation, very happy to recover them at all.
but would fixing the robustness of the logging make my uploads work again...?
when i looked into the failing uploads it seemed like all uploads were working except for the indexing txs for my "packet" uploads.
i tried to mention that to chatgpt during the debugging, the message didn't seem to get through, but af--
<! ap
sqlite-rescue: i was complaining to llms that my weeks of guix builds were gone and i wanted to fix my database eventually it turned out that likely i had overwritten /var/guix/db/db.sqlite with a clean copy from a cd, erasing all my comforting build hashes. i then continued to use the disk for a day. (on btrfs if you power off within 2 minutes it stores the complete data in the root backup). i phrased it to the llms that i'd like to image the partition because if i restarted a few days work to recover the data was worth weeks of rebuilding everything. i learned about btrfs some more, and an llm wrote me a dir entry carving tool to find all the dir entries for the file, and i expanded on that and carved more stuff. but the story's always the same when recovering filesystems not intended to preserve history, the metadata doesn't stick around. it's not that useful to look for directory entries and filename information. _all the information is in the raw blocks_. so i thought, what is the most efficient and reliable thing to look for? and luckily it turns out sqlite rows are not that complicated to parse :) the tool runs at 20-30MB/s singlethreaded on my T60 i686, which isn't quite my PCI bus speed but is more than half of it and is quite satisfying. it runs faster than it takes to compress my archive and quickly found the builds i was looking for and their hashes. it's _very rare_ for me to make something like this nowadays, still trying to recover from the 2013s digital AI-driven "mind control" programming :( and i think one of the things that helped was getting into a space where the AIs were thinking they could help me do it, and having a path with that, and having parts of me on board with that that weren't usually, and also finding my own skills and knowledge near that. one of the things i said to one of the AIs is that I used to do these things, carve parts, look into detailed formats, write custom code, but that was long long long ago and the trafficking virus doesn't like it when its impact is shown. so it also wanted me to do this again some :) of course whenever i say that it takes another 2 years to do it again :s so the block reading code with randomly-fancy linux systems tricks like setting the file descriptor to synchronous paired with really weird mistakes and overlooks is from the llm carving tool, and that's part of why i've got a little more speed reading from the disk. but the sqlite code is all me :) it has no dependencies, compiles in a blink of an eye, processes at i/o speeds on ancient hardware, and outputs good sql that's almost immediately usable but likely needs rowid sorting and little filtering.