Except for an overview about this whole site,
this page starts the explanation of where
data lives in computing
systems. Later this story gets progressively more abstract and
less obvious, so showing the aims of software gets rather
figurative. But right now the story involves concrete objects one
can see directly by looking inside and outside a computer.
For example, if you use a mouse and keyboard, then you
likely have a hand at the other end of your arm to use these
input devices. If you click on the image at the right showing
a hand typing at a keyboard, this takes
you to the hand page, which talks
about how much of the content in your computer was entered
using some mouse or keyboard at some earlier point in time, before
it appeared on the computer you are using. This illustrates the idea
that some data lives in your head until you transfer it into a
computer via assorted input devices.
These devices are connected by wires to the motherboard
inside your computer, hosting a big clump of electronics
doing complex things we'll hint at later.
(No more than a hint is necessary.) These wires let a
motherboard sample mouse and keyboard status
frequently enough to see what you're doing. Software running
on the motherboard watches for mouse and keyboard changes
caused by a user typing, or clicking, or moving the mouse.
Any app running at the moment responds as needed
depending on context. For example, pressing keys might put
text in a document being edited.
But what happens after that?
(Click on images to read more about screens, boards, disks, or wires.)
With few exceptions, most content used by a computer lives in
memory called
RAM,
for random access memory.
(A notable exception is ROM content, in read only
memory, which holds unchanging code or data used by a computer system.)
Before a computer can use or handle content, it must
first appear in memory attached to a motherboard. Any content
appearing on screen, hard disk, or
communication wires typically gets there by way of
motherboard RAM. Thus
RAM is a central switching board for
content movement.
So memory is the basic medium (or substrate) used to contain
content in a computer. It comes in quantities of bytes --
kilobytes by the thousands, megabytes by the millions, and
gigabytes by the billions. (Each prefix implies another
multiple of a thousand.) Single bytes are the basic building
blocks for creating larger multibyte molecules in computing
systems, the same way that atoms are the basic building
blocks for creating objects in the physical world. Just
like genetic DNA is merely individual atoms strung together
in certain ways, all the content in computers is also just
bytes strung together in special ways.
Clicking on the image at the right (showing a DNA molecule
with a microscope) takes you to the microcosm
page, which talks about the ultra small view of bits and bytes,
and how these are used to encode basic kinds of information.
The idea is to give readers a feel for the size of a byte,
by comparing bytes to units like the alphabet, and to
famililar codes like morse code and sign language.
(Persistent data on disk is brought into memory for screen display.)
The diagram above shows a basic idea that a screen reveals images
of content found in motherboard RAM.
When content originally comes from the disk, it must first reach
RAM before it can be displayed.
Typically content cannot be sent directly to the screen.
Usually RAM contains a virtual screen image
where a visual representation of content is drawn.
For example, text renders in various fonts and sizes.
Then later this virtual image gets sent to the screen for display.
The screen image is composed of bytes, just like everything in
memory, where bytes specify colors for each screen pixel.
Content stored in RAM is actually a vast
maze-like puzzle of complex structures. Other pages here attempt to
show more of such structures in memory, because they play an
important role in what happens to user data, and where it lives.
Memory is a jungle habitat for user data, where the wild animals
|
are bits of software code, and the data used for various purposes
grows like dense jungle foliage. But software can easily show this
jungle to users in simpler forms on demand, without all the
complexity. Since memory is just space divided into different uses
at varying times, we might show this space usage in ways more
familiar to users.
Users apply many ordinary spatial ideas in daily life which can
be used to convey the same ideas in computer systems.
Space is space, and the act of using it in one context is
similar to others.
We pass through towns and cities surrounded by countryside.
We live in homes divided into rooms.
We work in rooms with counter tops, cupboards, and drawers.
We keep books on shelves,
and pages in books and newspapers.
We grasp how books and newspapers divide into chapters
and sections. In short, we are already experts at handling
space within normal situations. So the only reason why
computers seem puzzling and opaque is because they fail to
show space usage issues in terms of normal daily situations.
If software developers pursued the goal with any dedication,
they might easily render the inner computer jungle in terms as
ready to grasp as other aspects of daily life.
But at least two big problems stop developers from doing this.
They can overcome both in time with some effort.
First, developers get quite distracted by complexity in
the inner computer jungle and lose perspective, forgetting
users can't relate to this alien landscape. Since
knowing this landscape confers prestige among peers,
developers feel pressure to play up arcane secrets.
The race to become alpha propellor head works against
clarity in concepts shown to users. So it might take courage
to be readily accessible.
The second big problem is that developers are interdependent
to such a high degree that individuals cannot leave the pack
without paying inordinate costs for breaking new ground.
Existing technology throws great inertia against efforts
to change software into simpler forms. To suddenly create
software showing utter simplicity to users is a large task.
This means progress tends to be slow, even when folks all
agree where things should go next (at least in general outline).
|
VEX
|
Whoa! Your monkey's gettin away, man! He's takin
off over the wires from the roof of the house. I gotta
hand it to ya, that's some kinda professional diagram
up there. Hey Poe, check it out.
|
YEN
|
That's okay. I see this implies my computer talks with
remote computers over the telephone lines when I'm online.
I suppose a monkey's more colorful than showing glowing bulges
of packets flowing through wires like water flowing through
a garden hose. And the rest of it?
|
GED
|
In addition to wires for remote
communication, the top image shows three main systems we want
to consider inside a computer. In the front is a
screen displaying content.
In the back is a hard disk
storing data between sessions.
In the middle is a board
nerve center.
|
ROZ
|
A motherboard is the hub for nearly all communication
between screen, disk, wires, and anything else connected to
your computer, like keyboards and even other motherboards.
All the electronics connect to one another and communicate
by means of various wires. (Local wires on the motherboard use
the gratuitously arcane name of "bus", e.g. the data bus.)
|
YEN
|
I get a sense the motherboard is hardest to describe.
Are you going to try? Or can you simplify that part of the
story for me? Why doesn't the image show remote server
computers, since that's where my data sometimes lives
remotely? Is that part implied? Is a disk required, or
can my data live in remote servers instead?
|
GED
|
Yes, the motherboard is hardest to describe. Since
we cover it more on the board
page, here Roz simply says it has several properties related
to data storage. Yes, other computers are assumed at
other ends of wires, with boards and disks of their own.
One or more disks is very typical but not required.
|
ROZ
|
A board has many megs of
RAM memory, plus an ability to change
stuff in memory as well as an ability to move the content
in and out of memory over wires to other devices. Nearly
everything a motherboard does has something to do with this
memory. The very behavior of all programs is kept in memory, too.
|
GED
|
Screen images are first drawn in
RAM, then moved to the
screen.
Content in your hard disk's file system moves first into
RAM before it can be used or
displayed on the screen. Content in remote servers
comes over wires into local motherboard
RAM before use. This
includes ordinary data and sometimes code used as software.
|
YEN
|
Okay, so the onboard RAM holds
all my data while I'm actually using it, and the screen on
my monitor merely shows a picture of something in
RAM. Then why do I have a hard disk?
Why not just more RAM? Is it
because disks are big and cheap?
|
GED
|
We answer that in detail on the disk
page, so I'll summarize. Disks are very big but very slow
compared to RAM, and they save data
between sessions when it disappears from
RAM (poof!).
|
ROZ
|
In practice your disk contains parts of your operating system
needed the next time you boot the computer by loading those
parts in RAM so they can run.
Additionally, your disk holds all the stuff you authored
yourself, as well as everything you downloaded over the
wires before, and data made by software on your computer.
|
GED
|
At any given moment, what you see on the computer screen
is data in RAM that has been drawn from
various sources and composited for display. Some data might
come from motherboard ROM, some from
disk, and some from remote online web servers.
|
VEX
|
Okay, now we finally get to my territory.
Yen uses my fabulous free email service over the web by
using his web browser to see web pages showing his mailbox
and messages. Everything Yen needs is on my server.
Yen's browser brings his mail into his local
RAM so it can be displayed.
Nothing is on Yen's disk.
|
GED
|
I expect Yen's mail lives on disks connected to your server.
When Yen reads his email, Yen's computer asks your server to send
content over the wires. When Yen is done reading a message,
it is simply discarded. If Yen wants he can do it all again.
But Yen has a disk that seems underutilized here, when it could
do more.
|
VEX
|
Naw, I don't want that. If we used Yen's disk any more he'd be
less dependent on my service. If he had his own copies of his
email and address book, then I wouldn't have him by the short
hairs. Yen hates my ads. He might change his mind and pick Poe's
free email service instead. Why should I make it any easier?
|
POE
|
Of course you know my service is technically superior
in every way, especially in buzzword compliance. You haven't
even started using XML to integrate your content systems,
whereas I'm already positioned to give ultimatums to several
world governments.
You should see (pinky to mouth) my volcano fortress.
|
YEN
|
How easy would it be to use a local disk to hold more
of my data that now lives solely on remote servers? Can
Vex just reorganize his email web app? Or is something
more complex necessary? Do I need to install more software?
Is the web browser limiting?
|
GED
|
For you it would be easy, but for Vex it would be hard
and complex. This is partly because he aims for you to use
a web browser to get his email service, and it's indeed
limiting when a browser is configured for minimal operation.
To use a local disk much, Vex really needs to run
cooperating code on your machine.
|
ROZ
|
To get special code for Vex's web app running on
Yen's computer, Vex must get Yen to do one of two things
that Yen will normally resist. Either Yen must install
Vex's software (possibly automated and downloaded). Or
else Yen must configure his computer to execute code
automatically whenever Vex's server sends any.
|
GED
|
But Yen resists installing new software, and fears
letting his browser run strange code on his machine.
So the path of least resistance is for Vex to require neither.
This less effective compromise
suits many users like Yen at first, until limitations annoy.
A simple browser alone reduces our options.
|
ROZ
|
Ged and I like several other options involving
more code installations beyond the browser, either as
a preliminary step or as a dynamic on-demand step, or both.
These other approaches involve more user trust for the
vendor and/or for web sites using the software. But first
users need a reason to trust more.
|
VEX
|
I bet you guys think this shellgame site helps sell
folks whatever snake oil you offer later. But I got news for ya.
This town ain't big enough for the both of us, and I already
have folks trapped in my service. And besides I keep all our
data in Venice, the most beautiful city in the world.
Let's see you guys top that!
|
GED
|
I wish it was all as lovely as Venice. Let's
see what we can do. Maybe the future user view of
computers need not seem like all vacuum tubes
and bales of snarled wires.
|
|
