// COMPLETE THREAD

info assembly line, "flits" (long)

4 expanded posts ยท every known parent and child

NODE e262909binfo assembly line, "flits" (long)
these are a few ideas I've been working on intermittently for
some time on the possibility of an "information assembly line"
of the future.

Alvin Toffler was one of the first futurists to predict the
"third wave" or information economy. we are very steadily moving
our way into this new shift, with numerous signs attesting to
it, and reactionary forces ("Buchananism", see recent Wired)
arising as well.

however, we are only at the tip of the iceberg. even state-of-the-art
information economies like Silicon Valley I would not consider full
implementations of the idea. what would it really mean to have
an entire economy that is related to information? (caveat: I 
certainly am not saying that we will no longer have physical goods,
this is a misunderstanding of Toffler's thesis, and anyone who wants
more info on this point should consult his writing).

Moore's law comes to my mind, the trend that computer capability has
been doubling approximately every 18 months ever since chips were
first invented. what could this power have on a future information 
economy (henceforth abbreviated IE)? I tend to think that the future 
IE will make the current world wide web look like child's play, although it
will be built on top of it. we are far from implementing the full
capabilities of information technology in our economy.

==

first, I think the use of microcurrency is going to play a very
major role in the future IE. it will allow people to easily own
mini-businesses in much the same way the web has allowed everyone to
own printing presses. I've written elsewhere on cybercurrency, but
I also tend to think it will have the effect of creating new
monetary standards. whereas in our current economy, wealth is
typically tied to major world economies, particularly the US
through dollars, I've said how I think stocks will come to be
thought of as a kind of currency, and that any company that sells
stock is essentially circulating its own currency. I think the
short term effect of cybercurrency is going to be a grafting on
top of existing government cash schemes, but that much to their
chagrin they are going to eventually realize it tends to make
their own regulatory and supervisory role obsolete-- or at least
displace it.

==

now imagine taking the cybercurrency concept and applying it
to an information economy. what you will tend to see is that 
cash transfers will increasingly be automated. cash will be
like the blood flow of society. you will see companies automating
their payment processes so all the man-labor associated with
handling the paperwork will tend to evaporate. you will of
course still have verification systems that prevent payment
when payment is unjustified, but the massive frameworks and
bureacracies inside companies today that are used to deal with 
cash flows will tend to be automated and diminished in size.

==

the idea that strikes me most about an information economy
is that you're going to see systems that are similar to the
concept of the assembly line for the industrial economy. 
I believe we will literally see information assembly lines
in the future. what kind of form would they take?

we already have "information assembly lines" in companies today
but they are abstract concepts of flow of work that are
not fully automated. parts of the assembly line involve people
moving around documents, sending letters, having conversations,
etc.  I tend to think that much of this will be increasingly
encoded in cyberspace. a company will see its role as an
information processing component. 

let's say this sample company gets a work order. the primary 
means of transfer will be through cyberspace. today cyberspace
is seen as an adjunct to paperwork-- the paperwork is primary,
but you can put the paperwork in cyberspace file cabinets, 
send it via cyberspace, etc.  I believe this will exactly flip
in the future, so that the paperwork is seen as an adjunct to
cyberspace. the documents will be freely transportable in 
cyberspace, and one can always track their location, just like
one can always see where some object is on an assembly line.
the work order will be thought of as primarily a document 
existing in cyberspace, with it taking various forms in
different places on the assembly line based on actions of the
information workers, who process it and tie it with other
documents, etc.

==

what does today's cyberspace lack to pull off this vision? after
a bit of thought I think one word to describe it might be
"continuity" or "persistence". there are so many obstacles in cyberspace to
transporting documents. it requires too much manual effort
on the part of each person to translate documents into particular
formats, send them via email, etc.  what we need is the cyberspatial
equivalent of continuity: people anywhere can look at the same
object and see the same thing, and that thing can be moved around
in cyberspace without ever losing its identity.

the problem is that today the concept of a "document" in "cyberspace"
is merely a concept. I can't point to some "place" in cyberspace
when I want someone to grab a document from me. I can't say, "here
it is". I have to go through an artificial series of steps to
encode the document, such as emailing it, ftping it, 
uuencoding it, or whatever.

what I am getting at is that we need a kind of virtual reality to
pull off the information assembly line to its utmost potential. I
believe we literally need to create a visual metaphor for the 
information assembly line that transcends the concepts of email,
different computers, etc.  I should be able to "pick up" and "move"
a document in cyberspace as easily as I move a piece of paper in
the real world. the whole system of different servers, different
software packages, different protocols, all this should 
be *invisible*  to me in the same way it is invisible on the current
WWW.

imagine that one actually created a total virtual reality 
information assembly line. what kind of form would it take? you
would see different things that can be done to documents
as "tools" that can be applied to them. you would see their
locations as simple visual metaphors that ignore the concepts
that segregate information. for example, you might see a single
file cabinet that represents every record in an entire company,
regardless of its location anywhere in that company. tough to
pull off? of course, but this is what we are headed towards, in
my opinion.

===

I've written multiple times about Negroponte's ingenious concept
of "bits vs. atoms". in the above spirit, 
I think we need a slight additional paradigm
shift on the concept of bits, something I call a "flit". 

the concept of a bit is too abstract for me. for a virtual reality
and an assembly line, I would prefer to say that information has
two additional components other than a binary true/false value:
a *location*, and a *time* that it is at a location. in this way
information better matches our reality that we deal with every
day. I would say the "flit" concept is a pivotal missing link
in creating an information assembly line.

I would say that an information assembly line document is
actually composed of "flits" instead of bits. each "flit" can
have a different location at different times in cyberspace.
it is a sort of "fleeting bit", a bit that can move around to
different places.

this requires a somewhat radical shift in current technological
thinking. currently we see data as stationary stuff that sits
in some place, and people come along and run programs that
churn up the bits and spit out new bits. but the new bits are
not nicely tied to the old bits except through our own memories.

==

instead I would say that the key concept of information is to
say that it has a content and a state at some time. a document
composed of a bunch of "flits" can be broken up into its 
component "flits", and the "flits" can be sent in different
directions and recombined into different documents. but because
they are "flits", I can *trace* their destinations over time.

what does this mean? it is the concept of debugging applied to
information technology. imagine that I once had a document, and
I want to know what happened to it. because it is made of 
"flits", I could say, "where did the flits that comprise this
document go?" I would get an answer about their entire history--
what programs the moved through, how they were recombined, 
where they now reside. I could trace backwards too. "where did
this flit come from?" -- the system would trace the origination
of the flits.

what the flit concept does is introduce a *context* to a bit.
a bit has no "context".  where did a bit come from? the situation
with information is that it always has a *context* and is tied
with other information. (so in addition, I might like to suggest
that "flits" can be "tied together" with each other).

when today's software spits out some document, there is nothing
necessarily tying that document with the original input except
the memory of the humans. I would suggest that the information
assembly lines of the future will replace this concept. nothing
will be left to the imagination. things that are part of people's
memory today will be made explicit in the systems of tomorrow.
the abstract concepts we have of systems being "tied" together
will look very embryonic and impoverished compared to these
new techniques.

"flits" would have an identity irrespective of companies. one
could track them moving through different companies if necessary.
(the "flits" might therefore also have security aspects associated with
them.)  the point is that the data must not be disconnected, it
must be seen as continuous, and I think a flit-like concept is key
to accomplishing this.

==

notice today how much our systems diverge from the flit concept.
we are always losing bits, and not tying them together. whenever
a system goes down, all those bits evaporate. this would not
be acceptable in a flit universe-- it would be like an object
suddenly blinking out of existence. obviously we don't consider that
an acceptable behavior of objects in our current reality, why
should we allow it in cyberspace? cyberspace has a long ways to
go. today's cyberspace is barely sufficient for what is required.

in a flit universe, I would like to see flits "pile up" in a
queue when a machine breaks, like what happens in a real 
assembly line. the assembly line metaphor is really crucial
here. imagine that on some assembly line, all your objects
suddenly disappear when a machine anywhere on the assembly
line breaks. you have to then run other machines to "bring
back" the flits. a ridiculous concept. instead, I'd like to
see flits pile up when some machine goes down on the assembly
line. once you get the machine running, it automatically starts
back going through the flits.

a lot of this implies "transaction tracking" by conventional
standards. I would suggest that "transaction tracking" and
integrity assurance are only the barest rudiments of what is
required to pull off an information assembly line. the 
belief that these are now considered incredibly cutting-edge
and state-of-the-art technologies
is a good indication of how far we have to go.

==

I mentioned Moore's law above because I think it takes care of
all objections that "so and so that you are proposing would take
too much time". imagine that we have virtually unlimited 
computational capabilities-- what could we then do with this
kind of power? tracking "flits" would be an excellent use
for all this power, imho.

in future essays I may explore further the properties of flits
and give more examples.
NODE c9af6676Re: info assembly line, "flits" (long)
On Sat, 22 Jun 1996, Vladimir Z. Nuri wrote:

> what does today's cyberspace lack to pull off this vision? after
> a bit of thought I think one word to describe it might be
> "continuity" or "persistence". there are so many obstacles in cyberspace to
> transporting documents. it requires too much manual effort
> on the part of each person to translate documents into particular
> formats, send them via email, etc.  what we need is the cyberspatial
> equivalent of continuity: people anywhere can look at the same
> object and see the same thing, and that thing can be moved around
> in cyberspace without ever losing its identity.

The problem is that all that today is handled through the very complex 
laws of physics... think about the the number of atoms that are necessary 
to hold the information for a single page, let alone an entire book...  
in a virtual reality "cyberspace", this would be an insurmountable data 
storage... on the small-scale.

> the problem is that today the concept of a "document" in "cyberspace"
> is merely a concept. I can't point to some "place" in cyberspace
> when I want someone to grab a document from me. I can't say, "here
> it is". I have to go through an artificial series of steps to
> encode the document, such as emailing it, ftping it, 
> uuencoding it, or whatever.

Yes, but you have to go through the same steps in the real world... you 
just don't see it... it's all handled through physics and the properties 
of electron repulsion between an object and your fingers (holding 
something) and light coming from a light-emiting source, being 
absorbed (in part) by an object and reflected toward your eye, 
which interpretes it (seeing something).  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.

> what I am getting at is that we need a kind of virtual reality to
> pull off the information assembly line to its utmost potential. I
> believe we literally need to create a visual metaphor for the 
> information assembly line that transcends the concepts of email,
> different computers, etc.  I should be able to "pick up" and "move"
> a document in cyberspace as easily as I move a piece of paper in
> the real world. the whole system of different servers, different
> software packages, different protocols, all this should 
> be *invisible*  to me in the same way it is invisible on the current
> WWW.

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... 
if it was easy or even possible to MOVE something on a computer, 
the whole double-spending ecash argument would be kaput, as would the 
"wiping" a file vs. deleting it... I think that's what you're getting at, 
rather than the visual metaphor... which could be EASILY created.

> imagine that one actually created a total virtual reality 
> information assembly line. what kind of form would it take? you
> would see different things that can be done to documents
> as "tools" that can be applied to them. you would see their
> locations as simple visual metaphors that ignore the concepts
> that segregate information. for example, you might see a single
> file cabinet that represents every record in an entire company,
> regardless of its location anywhere in that company. tough to
> pull off? of course, but this is what we are headed towards, in
> my opinion.

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.

> the concept of a bit is too abstract for me. for a virtual reality
> and an assembly line, I would prefer to say that information has
> two additional components other than a binary true/false value:
> a *location*, and a *time* that it is at a location. in this way
> information better matches our reality that we deal with every
> day. I would say the "flit" concept is a pivotal missing link
> in creating an information assembly line.

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.

> this requires a somewhat radical shift in current technological
> thinking. currently we see data as stationary stuff that sits
> in some place, and people come along and run programs that
> churn up the bits and spit out new bits. but the new bits are
> not nicely tied to the old bits except through our own memories.
[snip]
> instead I would say that the key concept of information is to
> say that it has a content and a state at some time. a document
> composed of a bunch of "flits" can be broken up into its 
> component "flits", and the "flits" can be sent in different
> directions and recombined into different documents. but because
> they are "flits", I can *trace* their destinations over time.
> 
> what does this mean? it is the concept of debugging applied to

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

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

But, if you're thinking on the document level... all you'd really need is 
a good compound-document technology (similar to OpenDoc) with a great 
revision history (similar to OpenDoc) that not only tracked revisions 
done by humans... but also revisions and handling done by programs.

> information technology. imagine that I once had a document, and
> I want to know what happened to it. because it is made of 
> "flits", I could say, "where did the flits that comprise this
> document go?" I would get an answer about their entire history--
> what programs the moved through, how they were recombined, 
> where they now reside. I could trace backwards too. "where did
> this flit come from?" -- the system would trace the origination
> of the flits.

Where would all this imformation be stored?  It's far too much for any 
filesystem or computer or harddrive in existance...

> what the flit concept does is introduce a *context* to a bit.
> a bit has no "context".  where did a bit come from? the situation
> with information is that it always has a *context* and is tied
> with other information. (so in addition, I might like to suggest
> that "flits" can be "tied together" with each other).

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

> when today's software spits out some document, there is nothing
> necessarily tying that document with the original input except
> the memory of the humans. I would suggest that the information
> assembly lines of the future will replace this concept. nothing
> will be left to the imagination. things that are part of people's
> memory today will be made explicit in the systems of tomorrow.
> the abstract concepts we have of systems being "tied" together
> will look very embryonic and impoverished compared to these
> new techniques.

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.

> "flits" would have an identity irrespective of companies. one
> could track them moving through different companies if necessary.
> (the "flits" might therefore also have security aspects associated with
> them.)  the point is that the data must not be disconnected, it
> must be seen as continuous, and I think a flit-like concept is key
> to accomplishing this.

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.

> notice today how much our systems diverge from the flit concept.
> we are always losing bits, and not tying them together. whenever
> a system goes down, all those bits evaporate. this would not
> be acceptable in a flit universe-- it would be like an object
> suddenly blinking out of existence. obviously we don't consider that
> an acceptable behavior of objects in our current reality, why
> should we allow it in cyberspace? cyberspace has a long ways to
> go. today's cyberspace is barely sufficient for what is required.

But cyberspace is NOT real space... if it was, we'd require computers the 
size of this planet to store and process eveything.  Cyberspace is a 
computer-generated space... and computers are far from powerful enough to 
keep up with what you propose... and I suspect that they will be for a 
LONG time to come.  I think a computer-generated approach is a lot better.

> in a flit universe, I would like to see flits "pile up" in a
> queue when a machine breaks, like what happens in a real 
> assembly line. the assembly line metaphor is really crucial
> here. imagine that on some assembly line, all your objects
> suddenly disappear when a machine anywhere on the assembly
> line breaks. you have to then run other machines to "bring
> back" the flits. a ridiculous concept. instead, I'd like to
> see flits pile up when some machine goes down on the assembly
> line. once you get the machine running, it automatically starts
> back going through the flits.

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?

> a lot of this implies "transaction tracking" by conventional
> standards. I would suggest that "transaction tracking" and
> integrity assurance are only the barest rudiments of what is
> required to pull off an information assembly line. the 
> belief that these are now considered incredibly cutting-edge
> and state-of-the-art technologies
> is a good indication of how far we have to go.

VERY VERY VERY far...

> I mentioned Moore's law above because I think it takes care of
> all objections that "so and so that you are proposing would take
> too much time". imagine that we have virtually unlimited 
> computational capabilities-- what could we then do with this
> kind of power? tracking "flits" would be an excellent use
> for all this power, imho.

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

Josh
NODE 5ca7e3c2Re: info assembly line, "flits" (long)
>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.
NODE 492a9d0aRe: info assembly line, "flits" (long)
On Sun, 23 Jun 1996, Vladimir Z. Nuri wrote:

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

	Think about catching a ball. Think about writing a program
convince a piece of hardware to catch a ball. Which is _more complex_
neither. Which is harder? writing the program.  

	Back to your example: moving a pencil up and down is not nearly as
complex as "moving" a document through "cyberspace". Then again moving a
pencil up and down isn't nearly as comlex as moving a pencil from Finland
to Miami. 

	Thing is, in the physcial world there is much complexity to what
we accomplish, it is just that we have already learned that complexity. It
is often less of a pain for me to ftp a file from a site half way around
the world that to dig thru the piles of paper to find the print out. 

Petro, Christopher C.
petro@suba.com <prefered for any non-list stuff>
snow@crash.suba.com