[Replicant] the minimal effort needed for a minimal change in initramfs?

Denis 'GNUtoo' Carikli GNUtoo at no-log.org
Tue Oct 27 11:36:22 UTC 2015


On Tue, 27 Oct 2015 11:47:10 +0100
user468362 at 0w.se wrote:

> Hello Denis,
Hi,

> I did find various tools with these names :) but they seemed
> to address images of a format other than I had at hand.
That's probably because I forgot to ask which device you had and
assumed that you were talking about the android boot.img format.

For instance, the GTA04 boot.img is probably not in the android format.

> I sacrificed 60GB disk space (and quite a few [MG]bytes net traffic)
> and several hours x86_64 CPU time, to replace a handful of tiny files.
> 
> This is apparently the threshold to be able to tinker with Replicant.
If you don't need to compile userspace binaries, the threshold is much
lower. Also, I'm unsure how easy it is to use the SDK to compile
userspace binaries, but it might be possible.

> Nevertheless, the effort was worth it, now I have got Coda file system
> accessible on Replicant (global name space, consistent caching,
> protection, disconnected operation).
> 
> In other words, Coda when properly used removes the need to "sync"
> data between the multiple devices - you just use the same data under
> /coda/...../something and Coda gives you the same view, no matter
> which computer or phone you use for the moment.
Wow nice, I should look at it. I've this issue for my laptops, but I've
also strong security requirements. Tahoe-lafs seem to be great for
remote storage and security, but I didn't try it yet. The point here is
that the client(laptop) don't have to trust the storage provider(like
my home server).

Denis.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 819 bytes
Desc: OpenPGP digital signature
URL: <http://lists.osuosl.org/pipermail/replicant/attachments/20151027/560c6e40/attachment.asc>


More information about the Replicant mailing list