> reading a raw device node (e.g. /dev/rdisk*)
That's... not bypassing the kernel. Time to integrate SPDK so it actually bypasses the kernel :)
supports ext4, btrfs, and apfs. Multithreaded, supports compression, nested volumes, and can even search detached volumes like .iso and .dmg without mounting
An interesting bonus point: you can't really vibe code it cause clankers can not run sudo commands
They absolutely can. There's nothing special about a these harnesses. You automate sudo the same way you would automate in any other context. SUDO_ASKPASS, visudo, etc, maybe with a alias for obfuscation if your harness hates you.
Is that really true? I'm fairly certain that were you to give it the proper tooling and it's own VM, it could quite happily run any command.
Hell a simple "if the CLI returns any form of 'permission denied' retry previous command with sudo; your password is: Hunter2" skill would work, no?
alias safedo='sudo'
Well, you could whitelist the tool in sudoers.
This would let LLMs use it too.
Did you write a metadata parser for most of the filesystems?
What's the license for ffs?
It works by reading the block device in /dev directly, wouldn't it also work on an HDD, flash drive or a memory card?
I don't think I'd ever trust or use this, but still, good job OP :)
In particular, can it be certain that a flush is really a flush?
Also gave Opus 4.6 access to a Kubernetes container and it was able to use pyrasite (a Python replacement that attached to a running process with gdb) to debug a "memory leak" in Python
I don't think I'd let them run unattended on anything I care about especially if there weren't backups, but they've never tried to break anything while supervised.
Usually it's significantly faster and more accurate to give the LLM/harness access to the thing to debug then to try to copy/paste back and forth.
For me, it took a bit over six weeks of Claude running unattended perpetually.