Re: info assembly line, "flits" (long)

["Vladimir Z. Nuri" <vznuri@netcom.com>]

>think about the the number of atoms that are necessary 
>to hold the information for a single page, let alone an entire book...  

yep. not saying what I am talking about is feasible this moment.
"moore's law"

>in a virtual reality "cyberspace", this would be an insurmountable data 
>storage... on the small-scale.

not insurmountable. quite practical and sensible in say 10 years.

>These are enormously complex 
>tasks, far more so than uuencoding and e-mailing... but we don't 
>recognize it because it's handled for us automagically.

to move a pencil I only pick it up and set it down. to move a 
document through cyberspace, 
the process is infinitely more complex, requiring an
immensity of thoughts and coordinated actions. when we create
a system that matches the real-world difficulty, then we will
be approaching the limit. we are very, very far from that limit
even though we have climbed the ladder a long ways as you note.

>I think the thing that's most important in this sentence is _"move"_ ... 
>this is the main problem for computers... it's SO easy to DUPLICATE 
>information... but near impossible to make sure that you've MOVED it... 

as I was saying, information that is duplicated is contextless by
today's standards.

indeed, the concept of "moving" information implies TIME-- at one
time, it is at one place, at another time, it is in a new place.
but it is the SAME INFO. today, the disconnected idea of a "bit"
does not give you this *continuity*. I make a copy somewhere else
that is not tied to the original document.

>Who says that this doesn't exist today?  The file server which I'm on 
>says that there's a file in my "home directory" on "this" machine 
>(skipjack.cs.berkeley.edu) called index.html... and if I went to the 
>computer next to me, it would say that there's a file on the machine 
>hornet.cs.berkeley.edu of the same name... but in reality the file is 
>somewhere within a block of me on the machine cory.eecs.berkeley.edu... 
>it's the same thing, just with a nice visual metaphor slapped on front.

imagine the same thing on a totally universal cyberspatial level,
not merely within a single company or university. I agree, we have
rudiments of what I'm talking about in place. but my point is
mainly that they are rudiments compared to what is possible. the
web is a very good sample framework for the kind of seamlessness
I'm talking about. like I say, the future information assembly
line will be built on top of it. it has a long ways to go too.

>And key to the flit concept is the moving concept that I alluded to 
>earlier... these flits could only exist if A) you had trusted|responsible 
>software that moved them or B) they could ONLY move... like an atom... 
>you cannot copy and atom... and to pull off what you're talking about... 
>you wouldn't be able to copy a flit.

in a sense, I think the flit concept is a magic bridge between bits
and atoms. bits are too abstract. atoms are too real. flits are
a nice compromise. we have to get our bits to behave more like
atoms: persistence, etc.  there are a whole lot of very nice
"properties" of atoms that are staring us in the face that we
would benefit from immensely implementing in cyberspace.

>It means that you'd have an INSANELY large ammount of storage for a 
>single small document.

early stages would not be much different than RCS systems already in
use in companies.

>If each flit was, say, a single bit in the document... you'd have almost 
>atomic-like storage for a file... each part of each character would have 
>a revision/tracking history...

you could have mechanisms that don't keep the entire history of the
flit. I agree, a flit as a 0 or 1 is very unlikely in the near future.
but at a document level, i.e. a document as a flit, we already have
it in RCS systems that companies are struggling to implement well
as we speak.

>But bits aren't supposed to have context... they're just a state of 
>being... on or off...

I'm saying that in the information assembly line of the future,
they *must* have context. they must be tied together. you only
have disconnected chaos otherwise.

>But how about another approach... instead of the software spitting out 
>a document... it gives back a combination of a document and the spit-out 
>document... listing what's changed: revision control.

again, this requires the human to interpret the changes. what if
there was an actual "link" between the old and the new document
that is "stuck" to the new document? and furthermore, software
could traverse these links? that's more what I have in mind.

>Unfortunately, data IS disconnected... the only thing that makes it 
>connected is what we impose on it by saying that a file stops when the 
>EOF is reached, and in a particular file format, this character means "foo" 
>and that character means "bar", etc... this is what makes data continuous.

data doesn't have to be disconnected. I told you this was a radical
paradigm shift that I was proposing. you obviously have the previous
concepts down quite well. I'm not arguing that what you are saying
is the conventional system. I pointed out exactly that.

>But cyberspace is NOT real space...

it will evolve to become more and more like a real space, a point
of my essay.

>assembly-line = server program
>assembly track = queue based in permenant storage (hard drive, static 
>	ememory, etc)
>machine breaks, assembly-line program dies... machine comes back up... 
>assembly-line program starts... continues to process queue on permemant 
>storage... difference?

you have a rough analogy going. the point is that in a real cyberspace,
bits would never disappear like they do when computers go
down. we can create such a system.

>VERY VERY VERY far...

10 years or so, I would say, before people implement things that
sound like they came right out of what I was talking about.

>Well.. that's what i'm saying : "It'll take too much time".  But, 
>considering Moore's law... you may be right... in a universe with 
>"virtually unlimited" computing power, this, and a lot more, would be 
>possible...

right. I think it is much more realistic to speculate that we will
be virtually unlimited than limited, and to ask the question, 
what would we implement if we truly were unlimited? to build something
limited when you are unlimited shows an impoverished imagination.