[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Hurd Projects

From: mike burrell
Subject: Re: Hurd Projects
Date: Sat, 22 Dec 2001 13:47:57 -0700
User-agent: Mutt/1.2.5i

Lars Weber ( said:
> mike burrell <> 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.

yes, from a technical stand-point, the best solution would be to just
provide clear listings of the datastore.  even with the current "reference"
implementation of Fred, one can obtain a listing via a dictionary attack
(it's a bit of work, but it is do-able).

from a legal stand-point, though, some people might not like that.  of
course different translators could be used in conjunction with the Freenet
translator so to obfuscate the datastore from other processes (if that's
what the user wants).  i'm not sure there are even any lawyers on the
Freenet project, though, so all this worrying about legal "plausible
deniability" could be misplaced :).

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

well, especially in the land of Unix, the line between user and developer is
sometimes fuzzy.

plus, code re-use saves on hard-drive space and RAM-space, which is
definitely pro-user ;)

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

several translators on the same node would be immensely useful, especially
if you could sort of 'pipe' a node from one translator to another.

there are certainly other uses for cachefs (though maybe it would need a
different name).  one thing i thought of was an FS sort of like Microsoft
Windows' Recycle Bin (except much cleaner).  instead of 'rm'ing a file, you
'mv' it into a trash directory -- if the trash FS is full, then in it
(silently) deletes the oldest file on there.  i actually have something kind
of like this on my GNU/Linux machine, where i have a crontab entry that
deletes the trash daily, but a TrashFS would be much cleaner.  of course,
anything that caches could make great use of it.

but, i think if we were to get this thing working well and quickly, the
proper order of operation would be:
(1) get squid working under the Hurd (has this even been done yet?)
(2) turn it into a translator
(3) slowly work at getting it to export a human-usable datacache
(4) once that's working, take out squid's conventional non-human-usable
(5) work at trying to separate network code from cacheing code and
eventually break it into two translators

i know that the Hurd (or most of its developers) is more design-focused than
implementation-focused, and a clean break between cacheing and networking
would be the best design to use, but i'm maybe a bit impatient.  and seeing
how squid already exists, and works very well, and has decided to lump http,
ftp and cacheing code all into one big program, i think that's where
development should start.  it's the path of least resistance :)

anyway, i'll see if i have any time after Christmas.  i've got the Hurd
installed, but i can't get networking working with it right now ("ls
/servers/socket" requires a hard reboot -- not good).  once i get some new
blank CDR's, i'll get the latest Debian Hurd ISO and re-install it and then
see if i can get any useful work done :)

 /"\                                                 m i k e   b u r r e l l
 \ /     ASCII RIBBON CAMPAIGN                      
 / \      AND NEWS TOO, dammit

reply via email to

[Prev in Thread] Current Thread [Next in Thread]