How about this? I will provide a function that transparently makes a copy of, edits, and bind mounts (like the screensaver hack) on startup, so when the package is deleted, the modified file will not be bind mounted and nothing is modified.

Another suggestion: use unionfs-fuse to make COW overlays onto the root filesystem. FUSE is available and building unionfs-fuse should work fine. It's very similar to bind mounts, but it somewhat automates the copy-on-write path (but not in the first case presented next).

One option would be to have one overlay loop-mounted filesystem per package: They can be tailored specifically for the package regarding their size then. You would simply add/remove that filesystem-containing file in a special directory, let's say, "/mnt/us/overlays". Upon system boot, a single script would then be in charge of mounting each of these overlays onto e.g. "/tmp/overlays/<pkgname>" and then creating a unionfs mount to /. This gets messy however when it comes to writing.

Another option would be to have a general overlay filesystem and let packages just modify that upon installation/deinstallation.

Another option would be to have a general overlay filesystem and let packages just modify that upon installation/deinstallation.

Perhaps you could use some code from the OpenWrt project, which uses a COW file system .

The problem with a general overlay filesystem is that hacks would still have to be coordinated or they could damage each other due to namespace collisions .

Even simple launchpad key assignments risk hijacking by other apps, which is especially easy to do since the launchpad folder supports multiple .ini files. Either a .ini file could accidentally get replaced, or it could contain launch key assignments that are already in use in another .ini file. End users should not have to go in and compare and change all their .ini files to get them to work together -- that would be too much like the old days when plugging an ISA bus card into a PC meant removing all the other cards and changing their IRQ and address assignment jumper pins and DIP switches so that they could all work together (complicated by the fact that each card had a very limited supply of available settings, especially on 8-bit ISA) .

I really like Yifan Lu's idea of each hack getting its own filesystem (but some hacks might need access to other hack file spaces). I would recommend a cloop mount except in cases where a compressed loop mount uses too much CPU for the application using it .

Yifan Lu: If the kindle touch data dumps you want are in mmc, the mmc chip *could* be physically removed and read on an external computer (perhaps soldering the pins to a cheap microSD card adapter socket). Perhaps we could donate funds to get you a "sacrificial" kindle touch (I already donated $10 at your linked web page). Keep up the *great* work! .

Perhaps you could use some code from the OpenWrt project, which uses a COW file system .

The problem with a general overlay filesystem is that hacks would still have to be coordinated or they could damage each other due to namespace collisions .

Even simple launchpad key assignments risk hijacking by other apps, which is especially easy to do since the launchpad folder supports multiple .ini files. Either a .ini file could accidentally get replaced, or it could contain launch key assignments that are already in use in another .ini file. End users should not have to go in and compare and change all their .ini files to get them to work together -- that would be too much like the old days when plugging an ISA bus card into a PC meant removing all the other cards and changing their IRQ and address assignment jumper pins and DIP switches so that they could all work together (complicated by the fact that each card had a very limited supply of available settings, especially on 8-bit ISA) .

I really like Yifan Lu's idea of each hack getting its own filesystem (but some hacks might need access to other hack file spaces). I would recommend a cloop mount except in cases where a compressed loop mount uses too much CPU for the application using it .

Yifan Lu: If the kindle touch data dumps you want are in mmc, the mmc chip *could* be physically removed and read on an external computer (perhaps soldering the pins to a cheap microSD card adapter socket). Perhaps we could donate funds to get you a "sacrificial" kindle touch (I already donated $10 at your linked web page). Keep up the *great* work! .

I would try to get a serial connection going, but from what I read, it is hard to open the new kindles without breaking anything and voiding the warranty. That being said, if anyone has an already broken kindle touch, contact me.

I know how to take it apart, but everyone who has said they damaged some part of it. Even using plastic tools. I'm not going to destroy this $140 device, especially since I'm a poor student.

We should start a new "Donate for a sacrificial Kindle Touch for Yifan Lu" sticky. Put your donate button from your web site on it."

I donated $10 to you on PayPal a few days ago. Please put that in your "sacrificial kindle" fund. Hopefully you won't damage a sacrificial kindle, but at least if you do, it would not cost you anything."

*** Come on team! Go to Yifan Lu's page and donate some money so he can have a spare kindle touch to open and find his serial port:

Thank you, but knowing people, I don't think many will put in money for something like this. I still would rather get someone's already broken kindle, like one with a broken screen or something. It would also be recycling.

I would think people would be more likely to donate if this were on a sticky and it had sufficient cheerleading.

Also, getting more exposure by posting it at hackaday.com and other similar places would help (but as mentioned by moderators at hackaday, they get complaints for any hacks that cost more than a McDonald's Happy Meal).

This is a bummer for the hacking community -- I have taken time to give donations for lots of things I like (I give money to WikiPedia every year)...

Of course, the purpose for hacking is often to spend time instead of money, so supporting a cause would be difficult.

It looks like the damage at blogkindle.com was caused by prying off the glued components, rather than opening the case. The pads near the display connector that he labelled "Serial???" does look like the most promising point to connect. You could connect an oscilloscope to the pins one at a time during bootup to find the Tx line (especially if it was a "spare" kindle).

Another suggestion: use unionfs-fuse to make COW overlays onto the root filesystem. FUSE is available and building unionfs-fuse should work fine. It's very similar to bind mounts, but it somewhat automates the copy-on-write path (but not in the first case presented next).

Sounds interesting but that would involve remounting the root partition late in the boot process. I don't think that's a hassle-free operation.
You can't do it before exporting US over USB because if things go wrong due to an error in one of the hacks the user wouldn't get chance to get rid of the hack by deleting its home dir.
I'd stick to bind-mounts, it's a tested, safe and lightweight solution.
COW is not that important here giving the fact that root fs modification/substitution is not desirable and should be reduced to a minimum.