Earlier quoted context omitted.
> This is practically the most useless project becuase you can not run it without sudo permissions Well, you could whitelist the tool in sudoers. This would let LLMs use it too.
Y’all aren’t running your agents as root?
F* file system – file search that reads SSD directly bypassing OS kernel
21–30 of 54 posts
Re: F* file system – file search that reads SSD directly bypassing OS kernel
#22Earlier quoted context omitted.
> This is practically the most useless project becuase you can not run it without sudo permissions Well, you could whitelist the tool in sudoers. This would let LLMs use it too.
Y’all aren’t running your agents as root?
Re: F* file system – file search that reads SSD directly bypassing OS kernel
#23Dumb title. 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 assume the author just meant SSD as a synonym for "main internal disk", since that is usually an SSD these days.
Re: F* file system – file search that reads SSD directly bypassing OS kernel
#24Earlier quoted context omitted.
Y’all aren’t running your agents as root?
Has anyone run a study on how long you can run an agent as root before irreparable damage is done to the VM? A sort of gambler's ruin for the YOLO LLM Age.
For me, it took a bit over six weeks of Claude running unattended perpetually.
Re: F* file system – file search that reads SSD directly bypassing OS kernel
#25> 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 :)
Re: F* file system – file search that reads SSD directly bypassing OS kernel
#26Re: F* file system – file search that reads SSD directly bypassing OS kernel
#27Earlier quoted context omitted.
Y’all aren’t running your agents as root?
Has anyone run a study on how long you can run an agent as root before irreparable damage is done to the VM? A sort of gambler's ruin for the YOLO LLM Age.
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.
Re: F* file system – file search that reads SSD directly bypassing OS kernel
#28This is practically the most useless project becuase you can not run it without sudo permissions, but it was insanely fun to work on it 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
When they can't run sudo, they'll user docker to give themselves root. https://twitter.com/i/status/2060746160558543217
Re: F* file system – file search that reads SSD directly bypassing OS kernel
#29This is practically the most useless project becuase you can not run it without sudo permissions, but it was insanely fun to work on it 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
Do you mean the harnesses prevent it? Or it can't type a password or something?
I've been running mine as root on a disposable VPS. (Finally I have a dedicated linux guy!)
Re: F* file system – file search that reads SSD directly bypassing OS kernel
#30Earlier quoted context omitted.
Has anyone run a study on how long you can run an agent as root before irreparable damage is done to the VM? A sort of gambler's ruin for the YOLO LLM Age.
I gave Sonnet 4.6 root access to my Android via adb and it wrote frida scripts to help me recover the encryption keys from SwiftBackup 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 back…