This made me think of https://e4rat.sourceforge.net/, which moves boot files into sequential runs, which was helpful on spinning disks where seeks were slow but sequential reads were fast.
Just as an idea for a feature your defragmenter could have.
(Also this is a side thought; but I wonder if AWS AMIs and EBS volumes will boot faster if also organized sequentially.)
> Also this is a side thought; but I wonder if AWS AMIs and EBS volumes will boot faster if also organized sequentially.
Probably a measurable, but small, difference. I would expect it's not worth the effort unless you're spending a lot of time booting, and even then, there's probably better things to work on in the boot process, such as reducing the amount of things that run or reducing the size of them.
My understanding is that the harness is the set of function calls (or tool calls) that let the LLM interact with your codebase. It's independent of the IDE or CLI.
The tool calls will be, among other things, something like ReadFile, RipGrep, PatchFile, Shell.
When people talk about the value of different harnesses, they're also implicitly talking about the quality of the system prompt.
The same exact model, when given a different set of tools and a different system prompt, can behave differently.
Even if your files are properly encrypted, if you keep them on, say, Google Drive, then you might lose access to them if your account gets inadvertently blocked.
I think GP is trying to say something along those lines. Not that encryption isn't trustworthy, but that even with homomorphic encryption you still give up autonomy.
That’s not a problem solvable by cryptography. Your ISP can’t read your traffic, but can cut off your traffic. You can use end-to-end encryption to encrypt your files to upload to Google Drive, but Google can choose to delete your files.
I believe it's a reference to a joke meme that goes something like "Write Windows 12 from scratch. Make no mistakes." At least that's the first context I heard it in.
Just as an idea for a feature your defragmenter could have.
(Also this is a side thought; but I wonder if AWS AMIs and EBS volumes will boot faster if also organized sequentially.)