Re: Hurd Projects

[Lars Weber]

mike burrell <mikpos@shaw.ca> wrote:
> anyway, i was thinking further about how to regain this "plausible
> deniability".  unfortunately Hurd doesn't offer namespaces a la Plan9, as
> that would make things easier.  i guess you could just have the Freenet
> translator run as its own user, and run the data store with o-r (but still
> o+w and o+x) permissions.  i don't know if "it would be kind of annoying to
> change the permissions" would count as "plausible deniability" in the legal
> sense :), but i'm sure paranoid people (or people living in China, etc. for
> that matter) could figure something out.

If the freenet system itself allows content in the datacache to be
identified then a freenet translator should IMHO simply allow listings,
too.  If there is a problem with this then I don't think it's the
translators authors job to fix.

> the downsides of gutting the networking code from web browsers are that:
> (1) it's very difficult to do :).  try to take networking code out of
> mozilla, for example, and i expect that half of the code will be #ifdef's :)

Or one could then use my idea of a proxy for such legacy applications :)

> anyway, it all kind of fits into my philosophy i guess.  for a while people
> have realized that not all forms of code re-use can be implemented
> practically with pipes (and even shared memory to a point).  "components" a
> la CORBA seemed a bit ugly, as they're kind of opaque to the user (which
> makes them not as flexible as they could be) and vaguely un-Unix-like.  i
> figure if lots of stuff gets exported to virtual filesystems, though, we get
> all the benefits of code re-use, and plus get to continue on working in
> traditional Unix form :).

After thinking this over from scratch again it really starts to make
sense.  Until now I've mostly seen translators as useful from an end users
point of view only, but seeing it your way a http-translator (caching or
not) would also seamlessly integrate into and extend the development
platform itself.

As for caching, maybe it would be possible to provide the networking and
the caching functionality by different translators.  This way the httpfs-
and ftpfs-translators would simply use a cachefs-translator for caching.
(And maybe even a freenet translator could simply use cachefs to manage
it's datacache!?)  There might pop up other uses for a cachefs in the
future, but I don't know if there can be several translators on the same
node.

> and i don't know enough about version-control to say exactly how it would
> work :).

What I have in mind is a translator that sits on a directory (say: /etc or
~/source/foobar) and simply records all the changes (date and kind) that
are made to files inside of it.  Simply opening a file always returns the
latest version, but through some kind of "virtual" interface (by opening
/etc/.vcfs-history/2001-07-02/motd for example) it would be possible to
access files as they were at earlier points in history.

> anyway, if you look in /usr/lib or wherever on your machine, you'll see
> tonnes of symlinks and files like:
[...]

Ah ok, so this at least I did now!  I didn't see this fit in with my idea
of a version-control translator which got me wondering :)

Regards,
Lars

-- 
[ Lars Weber ]-------< me@lars.in-berlin.de >-----[ GPG-ID: 1383B42E ]
+++ fingerprint: 44B1 1D23 DD53 E6B2 4AAB 4C36 0323 9141 1383 B42E +++
[ Using GNU ]----< www.gnu.org | www.debian.org >---[ Running Debian ]