Re: Hurd Projects

[mike burrell]

Lars Weber (me@lars.in-berlin.de) said:
> [ Did you send this mail to me only (and not the list) on purpose?  It's
> not that I would have a problem with this, just wonder whether this was on
> accident only.  (I'm leaving all your comments intact so that you may
> forward this mail to the list if you want.) ]

no, i pressed the wrong key in my mail program when replying.  it was
supposed to go to the list.  anyway, i'm CC'ing this reply to the list now
:)

> mike burrell <mikpos@shaw.ca> wrote:
> > yes, i've had this exact same thought, actually.  e.g. if you "mount" your
> > Freenet translator into /servers/freenet, you could do things like:
> >         $ cp /servers/freenet/KSK/gpl.txt gpl.txt
> >                 (similar to 'fcpget freenet:KSK@gpl.txt >gpl.txt' now)
> >         $ cp foo.mp3 /servers/freenet/KSK
> >                 ('fcpput freenet:KSK@foo.mp3 <foo.mp3')
> > subspace keys would be much trickier, due to current Freenet URL syntax
> > (terminating the SSK with double '/'s) and also dealing with DBR's.  both
> > the Freenet protocols are constantly being changed it seems, so i needn't
> > worry about it yet :).  anyway, you could do things like:
> >         $ cp manifesto.pdf /servers/freenet/SSK/MYPRIVATEKEY
> > or
> >         $ cp /servers/freenet/SSK/SOMEPUBLICKEY/decss.tar.gz .
> ...Commenting the following...
> > etc.  and yes, being able to list the contents of your data store would be
> > very cool :).  though it would get rid of your legal 'plausible deniability'
> > or whatever it's called.
> 
> Yes, maybe.  But if this `plausible deniability' is implemented by
> crippling the user-software (instead of implementing it in the system
> itself) then I think it's a broken design anyway.

yes, true.  actually there have been a number of design decisions that have
been made in the Freenet project that seem to deliberately dirty up the
code, like making their own datastore virtual FS, and randomly doing certain
things (passing on messages when the HTL says not to), masquerading as SMTP
servers, etc.  all in the name of security, i guess.  i agree that it's
misplaced.

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.

> > also, for a while i've dreamt about an HTTP/FTP translator that would be
> > built on top of squid.  basically it'd be squid except you could 'ls' to see
> > what you have in your cache, etc.  and you could take all the redundant
> > HTTP/FTP networking code out of your web browsers, etc. and replace them
> > with simple open()s.  e.g. in your browser you would go to
> > 'http://www.gnu.org' and it would just open("/servers/http/www.gnu.org"). 
> > it would be a lot of work, though :).
> 
> We seem to think along the same lines as I had an idea similiar to this
> one also. :) But to consider this as a possible replacement for networking
> code in browsers is IMHO over-stretching the importance of translators.
> (Or maybe not?  I'm actually not completely sure as maybe the idea is just
> to much in conflict with the current line of thinking.)  What I had in
> mind was rather a simple proxy that just redirects HTTP calls to the
> filesystem.  Likewise for FTP.  (I think it would be better to keep these
> two separate, though.)

well i just lumped HTTP and FTP together because squid happens to do both,
and i was dreaming of modifying squid to do it.

i personally think that making browsers without networking code would be the
cleanest way of doing it.  you get the same functionality (theoretically),
unless i'm gravely overlooking something.  and it's a fairly clean break,
too, as web browsers typically consist (roughly) of 3 orthogonal components:
networking code, rendering code, and UI code.  actually if i'm not mistaken,
the popular console web browser "links" was originally designed as an HTML
pager (kind of like GNU's "less"), and networking code was a bit of an
afterthought.

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 :)
(2) it makes the translator's job a little harder.  an HTTP translator can't
just look to see if a file is in its datastore, and then go and fetch it if
it's not there.  it's often got to return a different file (for the same
given name) given different environment variables or even different times of
the day.  plus, it's got to figure out things like password-protected
documents and various incarnations of CGI scripts, etc.  squid, of course,
does all of this, but one would have to do it all again when considering
exactly how to export it to a proper filesystem.

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

> > and yes, another nice thing about that you can just use symlinks for
> > bookmarks.
> > 
> [ ...version-control- and ssh-translator... ]
> > 
> > both pretty cool :).
> > 
> > i imagine the version-control translator would also be useful for keeping
> > different versions of shared libraries in /lib.
> 
> I don't know enough about shared libs to imagine how this would work.

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

anyway, if you look in /usr/lib or wherever on your machine, you'll see
tonnes of symlinks and files like:
        foo.so -> foo-4.so
        foo-4.so.4 -> foo-4.3.so
        foo-4.3.so -> foo-4.3.0.so
        foo-4.3.0.so
        foo-3.so -> foo-3.19.so
        foo-3.8.so -> foo-3.8.6.so
        foo-3.8.6.so
        foo-3.19.so -> foo-3.19.1.so
        foo-3.19.1.so
        foo-3.19.0.so
and the linker and loader have to sort through all them, and it's basically
a big mess.  with version-control, presumably you could just reduce this
down to a single file:
        foo.so
and the loader would specify a version number when it's trying to load a
binary.

i mean it doesn't really buy you any new functionality -- it's not going to
solve world hunger or anything -- it would just clean up your /lib dir a
little bit so you don't cringe whenever you do an 'ls' :)

-- 
 /"\                                                 m i k e   b u r r e l l
 \ /     ASCII RIBBON CAMPAIGN                                mikpos@shaw.ca
  X        AGAINST HTML MAIL,
 / \      AND NEWS TOO, dammit