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

[user468362 at 0w.se]

On Tue, Oct 27, 2015 at 12:36:22PM +0100, Denis 'GNUtoo' Carikli wrote:
> > 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.

This was mentioned in my original letter: Galaxy S2.

> > 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

Ok! Then tell me how to set up the environment from scratch for building
just the boot.img of Replicant 4.2 for Galaxy S2 :) I do not think such
a document exists nor that it is feasible to maintain, because of the
multitude of SDK and devices's versions, generations and formats.

> unsure how easy it is to use the SDK to compile
> userspace binaries, but it might be possible.

I am pretty sure the threshold to learn the details necessary to
be able to cherry-pick the necessary parts is much more than the hours
I needed to arrange the "build the whole" thing. Luckily I had suitable
hardware at hand.

> > 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).

This would be nice for proper use of mobile devices, to get rid of the
dependency on proprietary and insecure data services. That's why I
do not think this matter is totally OT here.

For better clarity, Coda and Tahoe-LAFS aim at different targets.

Coda is a Posix-compatible file system, based on replicated trusted
servers with server-local storage, with a global name space and
(non-Posix, more consistent) ACLs.
It provides disconnection resiliency both against servers going down and
the clients losing connectivity, maintaining a consistent and persistent
client-side data cache.

Tahoe-LAFS is a distributed data storage protocol which does not rely
on trust to storage servers. It offers non-replicated gateways and an
optional Posix-like API, without a global file name space or cache
consistency guarantees. The gateways have to be trusted.

The global name space (in Coda) makes some great things possible,
like putting on it directly runnable Posix software, usable everywhere,
or sharing paths as easily as URLs (but with much better access control!).
Another crucial property is of course the capability of disconnected
operation.

(Conceptually, if correspondingly modified, Coda servers could put their
data on an encrypted bulk storage platform, then their need of trust
would correspond to the one of Tahoe-LAFS gateways)

Just for completeness, another architecturally related product is orifs,
it merges the server and client roles (compared to Coda) but these
hosts and their storage still have to be trusted.

A product combining the positive features of those three would be of course
best of all, but nobody took the challenge yet. :)

Anru