Back to the main page

Mailing List Logs for ShadowRN

Message no. 1
From: shadowrn@*********.com (Allen Smith)
Subject: UMS Matrix Icons
Date: Sun Jun 10 19:30:01 2001
Hi. Other than the material on Matrix page 41, are there any official
data on what UMS icons look like? If not, how do people generally
describe them? I'm particularly wondering about the standard persona
icons, since there are quite a few places in Target: Matrix where it
talks about standard UMS persona icons being needed in order to blend
in... From reading Snow Crash (I note some material in CC being from
there, BTW - namely the Victory Rapid Transit line) I'm somewhat
imagining a basic "Icon Construction Kit", so even standard UMS
persona icons might have some variation, though, simply in order to be
able to tell people apart.

Yours,

-Allen

--
Allen Smith easmith@********.rutgers.edu
Message no. 2
From: shadowrn@*********.com (Tzeentch)
Subject: UMS Matrix Icons
Date: Sun Jun 10 20:05:01 2001
From: "Allen Smith" <easmith@********.rutgers.edu>

> Hi. Other than the material on Matrix page 41, are there any official
> data on what UMS icons look like? If not, how do people generally
> describe them? I'm particularly wondering about the standard persona
> icons, since there are quite a few places in Target: Matrix where it
> talks about standard UMS persona icons being needed in order to blend
> in... From reading Snow Crash (I note some material in CC being from
> there, BTW - namely the Victory Rapid Transit line) I'm somewhat
> imagining a basic "Icon Construction Kit", so even standard UMS
> persona icons might have some variation, though, simply in order to be
> able to tell people apart.

Virtual Realities 1 has the most information on UMS and what it looks like
outside of the books (which aren't particularly consistent in their
treatment of anything, much less the Matrix). If you need information more
detailed then that I can probably paraphrase VR1/SR2.


Kenneth Peters
Backup Lead Playtester for GURPS Transhuman Space: High Frontier

"We create an environment where it is alright to hate, to steal, to cheat,
and to lie if we dress it up with symbols of respectability, dignity and
love."
-Whitney Moore, Jr.
Message no. 3
From: shadowrn@*********.com (Allen Smith)
Subject: UMS Matrix Icons
Date: Sun Jun 10 20:20:01 2001
On Jun 10, 8:15pm, Tzeentch wrote:
> From: "Allen Smith" <easmith@********.rutgers.edu>
> > Hi. Other than the material on Matrix page 41, are there any official
> > data on what UMS icons look like? If not, how do people generally
> > describe them? I'm particularly wondering about the standard persona
> > icons, since there are quite a few places in Target: Matrix where it
> > talks about standard UMS persona icons being needed in order to blend
> > in... From reading Snow Crash (I note some material in CC being from
> > there, BTW - namely the Victory Rapid Transit line) I'm somewhat
> > imagining a basic "Icon Construction Kit", so even standard UMS
> > persona icons might have some variation, though, simply in order to be
> > able to tell people apart.
>
> Virtual Realities 1 has the most information on UMS and what it looks like
> outside of the books (which aren't particularly consistent in their
> treatment of anything, much less the Matrix). If you need information more
> detailed then that I can probably paraphrase VR1/SR2.

Given that Virtual Realities 1 is rather hard to find, and the SR2
info isn't that much, I'd greatly appreciate it. I find having an
appearance in mind regarding a character helps distinctly in putting
them together...

> Kenneth Peters
> Backup Lead Playtester for GURPS Transhuman Space: High Frontier

Allen starts kicking himself for not having remembered to check in on
the playtests, as he discovers that In The Well has finished
playtesting... ah, well, with the FASA mess going on, Shadowrun seems
to need the help in regard to my field(s) of expertise (genetics et
al) a bit more.

Thanks,

-Allen

--
Allen Smith easmith@********.rutgers.edu
Message no. 4
From: shadowrn@*********.com (Tzeentch)
Subject: UMS Matrix Icons
Date: Sun Jun 10 22:00:01 2001
From: "Allen Smith" <easmith@********.rutgers.edu>
> > Virtual Realities 1 has the most information on UMS and what it looks
like
> > outside of the books (which aren't particularly consistent in their
> > treatment of anything, much less the Matrix). If you need information
more
> > detailed then that I can probably paraphrase VR1/SR2.
>
> Given that Virtual Realities 1 is rather hard to find, and the SR2
> info isn't that much, I'd greatly appreciate it. I find having an
> appearance in mind regarding a character helps distinctly in putting
> them together...

No problem. BTW here is what I wrote for VR3 (my long delated netbook...).
It adapts and expands on the material from VR1 and SR2.

UNIVERSAL MATRIX SPECIFICATIONS
UMS is the universal data communications protocol developed in 2039 to
exploit the amazing advances in both computer technology and infrastructure
realized after the Crash of 2029. Over a three month period, the UMS quickly
erncompassed every major standard of the time. Every year the specifications
became more all-inclusive, until by 2049 it was almost impossible to even
conceive of the dark times of data incompatibility that existed before UMS.

STANDARD FOR A NEW DAY
In addition to codifying the network protocols that are still used on the
Matrix to this day, the UMS also described standard data protocols for
everything ranging from home appliances to mainframe interconnects. With a
broad and extensible structure, UMS kickstarted the amazing growth of
telecommunications to the modern day.

ICS
Part of UMS's success was its implementation of the Identifier Code Series.
The ICS is an block of data that tells other machines how the system it
comes from works, what data formats it uses, and in the case of users with
virtual reality-interfaces, how to model the objects data in 3d and apply
behaviours to it. This ICS is sent as part of the initial "hand shake" of
data between two communicating devices. If the devices do not know how to
talk to each other then each one can load an interface driver on the other
machine so they can communicate. All of this is made possible by the broad
structure of the UMS.

NERPS
The ICS itself is not part of the low-level protocols that govern data
transfer on the Matrix however, that is handled by what is generally called
just the "stack" - a small suite of programs that interpret and route data
on the Matrix through the "persona" - a helper application that loads onto
the host. The protocols technical name is New Environmental Routing Protocol
System (NERPS), and it is the most fundamental part of modern
telecommunications.

VIRTUAL REALITY IS ITS OWN REWARD
ICS is essentially a high-level "interpretive" standard, it is designed to
run on any architecture as long as the system possesses the necessary
interpetive software. In essence it is the future version of late 20th
century interpetive languages as Java, Jini, and certain scripting languages
such as Perl. When two devices that do not know how to communicate with each
other make contact, each machine can send an ICS packet to the other that is
stored in the other machines buffer and is executed. The two machines have
then essentially loaded an device driver that allows then to communicate
between each other. This is all handled automatically, and is the basis of
all modern computing devices. You simply plug a device (even if its brand
new) into a network and the network will automatically update itself to
communicate and use the device.

One use of the ICS was found to be virtual reality. Instead of data for
communicating with a device the ICS blocks were instead used to transmit
behaviors, iconography, and interface specifications for virtual
environments. At first, computers had to download the entire set of virtual
reality blocks then the specific data for the host. This proved to be highly
impractical, and soon most computers came built-in with the standard ICS
series for using virtual environments.

This high-level interface was based on much earlier work with the original
networking virtual reality modelling language VRML (Virtual Reality
Modelling Language). The Fuchi-developed EMS (Environmental Modelling
Script) proved to be highly superior to the other protocols competing for
the standard and it as adopted soon after.

EMS
Every object in a virtual reality is coded as an EMS "entity". For example,
in a virtual reality consisting of a room, a chair, and a lamp there will be
entities for the room itself, the ambiant light source, the lamp object, and
the light object tied to the lamp. Each object will have its icon, behaviors
(such as modelling the movement of the chair if it is pushed), and physical
properties (its surface texture, color, radiosity, sheen, etc). The systems
graphics rendering engine could then "draw" the scene and have every object
interact in at least a semi-realistic manner.

As time went on EMS became more advanced and was extended to allow for even
greater object detail, more capable enity programming, and even methods of
embedding simsense into the environment. The standard icongraphy set for the
Matrix was introduced by Fuchi in early 2041 as a way to bring
standardization to the various virtual reality user interfaces that began to
appear around that time, greatly easing user familiarity and ease of use.

Reality Filters
Since EMS is an interpretive system, it was not long before "hacked"
interpreters appeared. Many of these were hobbyist projects, and typically
only modified certain aspects of the EMS data they received - such as
rendering the entities as icons instead of 3d objects. More advanced
software quickly appeared on the scene, including software toolkits that
allowed users to modify every aspect of the interpreter to their liking.

As simsense (first as simsampling, then later as ASIST interfaces began to
hit the market) begain to be incorporated into the EMS standards the editors
changed along with the new technology, forming the basis for modern custom
interfaces.

Since EMS is essentially no different from a 20th century block of HTML code
it is typically a trivial matter to ignore the visual representations, or
assign a new one based on the underlying ICS data. This is anologous to
looking at the source code for a 20th century web page - its easy to ignore
bogus links or spot things that may be hidden after the data is interpreted
and rendered.

UMS COMPLIANT ICONOGRAPHY
Most grids and hosts are UMS complient, that is, they generally do not stray
past the basic EMS standards for Matrix icons. A typcal host will look much
like any other anywhere in the world. This is starting to change, but even
many sculpted systems still have old-style EMS compliant system maps for
users with old systems.

User Actions
By 2055 it had become painfully obvious that the old UMS standard for system
operations was broken. So by 2057 most hosts had switched over to the much
more user-friendly ESR (Extended Symbolic Representation) system that most
are now familiar with. But a few systems still use the old standard.

UMS HOSTS
Hosts that still use the old user-interface standard are typically known as
"sandpit" hosts, so named for the excess effort that is required to get any
work done on them. By and large they are very unpopular architectures since
even users with pared down interfaces must work there way slowly from node
to node in order to accomplish their tasks.

Nodes
All systems of this type are built as "nodes" - discreet symbolic
representations of various system functions. These nodes are connected to
each other by datalines, which are simply reprsentations of data flow
between the systems.

System Operations
Because of the design of these systems it is not possible to perform every
system operation in a specific node. A user must be in the correct "part" of
the system in order to execute certain operations.

As a general rule, the standard Subsystem Tests do not apply in these kinds
of systems.

Connections
Because of the way systems of this type are laid out, some nodes cannot to
connect to other types of nodes. This was perhaps one of the biggest
limitations of the standard, and a primary reason it was abandoned.

Perception
Another odd part of the standard was the intentional "shortening" of
perceptions in the system. It was not possible to access systems as a whole
in the old standard. One could only "see" the nodes directly connected to
your own. Even systems running non-virtual interfaces are limited to
accessing one node at a time, like an old style dungeon-crawl game. Only a
successful Analyze Host operation from the CPU node will reveal the entire
"system map".

For this reason, on an unknown system the gamemaster should keep the actual
system map to himself. As the decker moves from node to node the gamemaster
reveals which nodes are connected - but that is all.

Movement
Switching to a connected node requires a Simple Action and a successful
Computer (Security Rating) Test. Failing this test has no effect unless the
host is running Probe IC (see Intrusion Countermeasures, below).

Range
For purposes of cybercombat programs can only target other personas or
software located in the same node.

IC
When the systems security tally rises enough to trigger IC, it will
automatically appear in the same node as the intruder. If there are multiple
intruders it will appear with the one chosen by the gamemaster. IC can move
from node to as a Free Action.

Security Deckers
Most security deckers will appear in the CPU node when they jack in. A
security decker can perform the Locate Decker operation from anywhere in the
host, and if successful will reveal the deckers location in the host.
Security deckers can change nodes as a Free Action.

NODES
The basic types of nodes are listed below. The description includes its
basic UMS iconography, system operations possible in the node, and what
nodes it can connect to.

Central Processing Unit (CPU)
Every system has only one CPU. It functions as the heart and brain of the
system.

Iconography: The CPU node appears as a huge octagonal room, built of circuit
boards, and pulsing with energy. Screens displaying the status of various
nodes throughout the system are placed throughout the construct.
System Operations: Any
Connections: The CPU can connect to any other node.

Dataline
Datalines are simply the representation of connections between nodes.
Essentially they "teleport" users between nodes. Datalines are not nodes and
it is not possible to be "in"a dataline for game purposes.

Iconography: Datalines appear as transluscent tunnels of energy, with
pulsing sparkles representing data travelling over the line.
System Operations: None
Connections: Datalines connect two nodes together.

Dataline Junction (DLJ)
A DLJ exists soley to route data to and from the various datalines that
connect to it.

Iconography: The DLJ appears as a a small yellow pyramid.
System Operations: None
Connections: A DLJ can connect to a SPU or CPU.

Datastore (DS)
Datastores hold information. They are the "library" section of the system.

Iconography: Datastores appear as a roughly rectangular area filled with
blocks of energy. With each block representing a datafile. Each block is
filled with swirling letters and numbers of various colors.
System Operations: Analyze Subsystem, Download Data, Edit File, Locate File,
Upload Data
Connections: Datastores can connect to other datastores, SPUs, or the CPU.

I/O Ports (I/OP)
An I/OP is a limited-access node that connects the host to various slave
devices. Most I/OP nodes represent connections for dozens, or even hundreds,
of individual devices. I/OPs can only control fairly simple devices (simple
terminals, soykaf makers, etc).

Iconography: The I/O port node is a pyramid-shaped white chamber. Typically,
the walls of the construct will have readouts and status displays for all of
the items that the node controls.
System Operations: Analyze Subsystem, Control Slave, Edit Slave, Locate
Slave, Monitor Slave
Connections: I/Ops can connect to SPU's, or rarely, to the CPU.

Sub-Processor Units (SPU)
An SPU is a "subdivision" of the host tasked with performing a limited array
of tasks. Some SPUs are simply "traffic cops" for multiple datalines while
others perform other functions on the host that may not be readily apparant.

Iconography: The SPU node appears as a large chamber filled with pulsing
banks of circuits and sizzling energy.
System Operations: Analyze Subsystem
Connections: SPUs can connect to any type of node.

System Access Node (SAN)
A SAN is the actual port that connects the host to the Matrix or another
host.

Iconography: SANs always apepar as doorways or access locks.
System Operation: Logon to Host (if connects to another system), Logon to
LTG (if it connects to an LTG or PLTG).
Connections: SANs can connect to an SPU, or rarely to an CPU

Slave Node (SN)
Slave nodes control complex physical processoes or devices, typically items
such as building elevator systems, factories, or security cameras.

Iconography: SNs appear as small, cubical rooms. The walls are covered with
various control terminals
System Operations: Analyze Subsystem, Control Slave, Edit Slave, Locate
Slave, Monitor Slave
Connections: SNs can connect to SPUs and the CPU



> Allen starts kicking himself for not having remembered to check in on
> the playtests, as he discovers that In The Well has finished
> playtesting... ah, well, with the FASA mess going on, Shadowrun seems
> to need the help in regard to my field(s) of expertise (genetics et
> al) a bit more.

The High Frontier playtest just started and we could really use another look
at some of the new clades and items like the "Rust." Commentary on the Void
Dancer templates and the like would also be cool ;)~ And don't forget that
Fifth Wave is coming up after HF finishes playtest...

Myself and John Freiler will be switching off for LP on the entire TS series
of books, I really think the books are going to kick MAJOR ass and be useful
to almost any science fiction game out there. In particular the main
Transhuman Space book and High Frontier are VERY useful to any Shadowrun
campaign dealing with space at all. In the Well (mars sourcebook) is less
useful since it deals with an partally terraformed Mars...

Oh, and GURPS Atlantis is also very cool ;)~

Kenneth "GURPS Pimp" Peters
Message no. 5
From: shadowrn@*********.com (Allen Smith)
Subject: UMS Matrix Icons
Date: Tue Jun 12 15:30:01 2001
On Jun 10, 10:10pm, Tzeentch wrote:
> From: "Allen Smith" <easmith@********.rutgers.edu>
> > Given that Virtual Realities 1 is rather hard to find, and the SR2
> > info isn't that much, I'd greatly appreciate it. I find having an
> > appearance in mind regarding a character helps distinctly in putting
> > them together...
>
> No problem. BTW here is what I wrote for VR3 (my long delated
> netbook...).

Understand on the long-delay!


> VIRTUAL REALITY IS ITS OWN REWARD ICS is essentially a high-level
> "interpretive" standard, it is designed to run on any architecture
> as long as the system possesses the necessary interpetive
> software. In essence it is the future version of late 20th century
> interpetive languages as Java, Jini, and certain scripting languages
> such as Perl.

I'm not sure as to the distinction you're making here between Java and
Perl. Perl is bytecode compilable like Java, and indeed is - on a beta
basis - translatable into easily-optimized C.

> When two devices that do not know how to communicate with each other
> make contact, each machine can send an ICS packet to the other that
> is stored in the other machines buffer and is executed. The two
> machines have then essentially loaded an device driver that allows
> then to communicate between each other. This is all handled
> automatically, and is the basis of all modern computing devices. You
> simply plug a device (even if its brand new) into a network and the
> network will automatically update itself to communicate and use the
> device.
>
> One use of the ICS was found to be virtual reality. Instead of data
> for communicating with a device the ICS blocks were instead used to
> transmit behaviors, iconography, and interface specifications for
> virtual environments. At first, computers had to download the entire
> set of virtual reality blocks then the specific data for the
> host. This proved to be highly impractical, and soon most computers
> came built-in with the standard ICS series for using virtual
> environments.

That makes sense... and is likely to be the mechanism of a lot of the
attack programs!

BTW, I do find the rules in Matrix for having really old hosts which
aren't VR-compatible rather weird. As I recall, the major influence
for having cyberdecks, deckers, etcetera, and conversely IC, was that
deckers were capable of going straight through defenses on old-style
systems without VR-compatible IC. If it's possible to have a host for
which only tortoise mode will work, then that idea falls by the
wayside...

> UMS COMPLIANT ICONOGRAPHY Most grids and hosts are UMS complient,
> that is, they generally do not stray past the basic EMS standards
> for Matrix icons. A typcal host will look much like any other
> anywhere in the world. This is starting to change, but even many
> sculpted systems still have old-style EMS compliant system maps for
> users with old systems.
>
> User Actions By 2055 it had become painfully obvious that the old
> UMS standard for system operations was broken. So by 2057 most hosts
> had switched over to the much more user-friendly ESR (Extended
> Symbolic Representation) system that most are now familiar with. But
> a few systems still use the old standard.

These representations would, however, by default look the same? As
would things within them, such as persona icons?

> UMS HOSTS
> Hosts that still use the old user-interface standard are typically
> known as "sandpit" hosts, so named for the excess effort that is
> required to get any work done on them. By and large they are very
> unpopular architectures since even users with pared down interfaces
> must work there way slowly from node to node in order to accomplish
> their tasks.

Overall, these rules for UMS hosts do make sense to me (at least as
much as other SR computer rules do!).

> NODES
> The basic types of nodes are listed below. The description includes
> its basic UMS iconography, system operations possible in the node,
> and what nodes it can connect to.
>
> Central Processing Unit (CPU)
> Every system has only one CPU. It functions as the heart and brain
> of the system.
>
> Iconography: The CPU node appears as a huge octagonal room, built of
> circuit boards, and pulsing with energy. Screens displaying the
> status of various nodes throughout the system are placed throughout
> the construct.
> System Operations: Any

This would imply that the main CPU node (which may well involve
mutiple processors, realistically, although other processors
(including in networked-together computers) may very well be under its
governance (e.g., for assigning parts of parallel programs, managing
shared memory access, and running kernel threads)) is going to be the
best-protected one under any sensible security architecture.

> > Allen starts kicking himself for not having remembered to check in
> > on the playtests, as he discovers that In The Well has finished
> > playtesting... ah, well, with the FASA mess going on, Shadowrun
> > seems to need the help in regard to my field(s) of expertise
> > (genetics et al) a bit more.
>
> The High Frontier playtest just started and we could really use
> another look at some of the new clades and items like the "Rust."
> Commentary on the Void Dancer templates and the like would also be
> cool ;)~ And don't forget that Fifth Wave is coming up after HF
> finishes playtest...

OK, I'll try to do so after finally finding time to read over the
earlier TS books and/or playtest files (depending on publishing
schedules).

Yours,

-Allen

--
Allen Smith easmith@********.rutgers.edu
Message no. 6
From: shadowrn@*********.com (Tzeentch)
Subject: UMS Matrix Icons
Date: Tue Jun 12 15:45:01 2001
From: "Allen Smith" <easmith@********.rutgers.edu>
> Understand on the long-delay!

I posted a 60 page excerpt on my webpage but the complete lack of feedback
means I've placed the project in nanostasis for the time being.

> > VIRTUAL REALITY IS ITS OWN REWARD ICS is essentially a high-level
> > "interpretive" standard, it is designed to run on any architecture
> > as long as the system possesses the necessary interpetive
> > software. In essence it is the future version of late 20th century
> > interpetive languages as Java, Jini, and certain scripting languages
> > such as Perl.
>
> I'm not sure as to the distinction you're making here between Java and
> Perl. Perl is bytecode compilable like Java, and indeed is - on a beta
> basis - translatable into easily-optimized C.

<shrug> My friend programs in Perl and thats what he wanted me to say. Not
particularly critical to the point I was trying to make ;)~


> > When two devices that do not know how to communicate with each other
> > make contact, each machine can send an ICS packet to the other that
> > is stored in the other machines buffer and is executed. The two
> > machines have then essentially loaded an device driver that allows
> > then to communicate between each other. This is all handled
> > automatically, and is the basis of all modern computing devices. You
> > simply plug a device (even if its brand new) into a network and the
> > network will automatically update itself to communicate and use the
> > device.
> >
> > One use of the ICS was found to be virtual reality. Instead of data
> > for communicating with a device the ICS blocks were instead used to
> > transmit behaviors, iconography, and interface specifications for
> > virtual environments. At first, computers had to download the entire
> > set of virtual reality blocks then the specific data for the
> > host. This proved to be highly impractical, and soon most computers
> > came built-in with the standard ICS series for using virtual
> > environments.
>
> That makes sense... and is likely to be the mechanism of a lot of the
> attack programs!
>
> BTW, I do find the rules in Matrix for having really old hosts which
> aren't VR-compatible rather weird. As I recall, the major influence
> for having cyberdecks, deckers, etcetera, and conversely IC, was that
> deckers were capable of going straight through defenses on old-style
> systems without VR-compatible IC. If it's possible to have a host for
> which only tortoise mode will work, then that idea falls by the
> wayside...

Well that was something of a sop to the critique that only the insane would
have secure data on an VR hosts as defined by Shadowrun. Tortoises are so
hamstrung in capability (far beyond what I think is warranted) that I don't
see it as being a huge game balance hole.


> > UMS COMPLIANT ICONOGRAPHY Most grids and hosts are UMS complient,
> > that is, they generally do not stray past the basic EMS standards
> > for Matrix icons. A typcal host will look much like any other
> > anywhere in the world. This is starting to change, but even many
> > sculpted systems still have old-style EMS compliant system maps for
> > users with old systems.
> >
> > User Actions By 2055 it had become painfully obvious that the old
> > UMS standard for system operations was broken. So by 2057 most hosts
> > had switched over to the much more user-friendly ESR (Extended
> > Symbolic Representation) system that most are now familiar with. But
> > a few systems still use the old standard.
>
> These representations would, however, by default look the same? As
> would things within them, such as persona icons?

By default all UMS hosts look identical yes. I assume you can do limited
sculpting but you have to pay the LTG for the privelage of them storing your
iconography.


> > Central Processing Unit (CPU)
> > Every system has only one CPU. It functions as the heart and brain
> > of the system.
> >
> > Iconography: The CPU node appears as a huge octagonal room, built of
> > circuit boards, and pulsing with energy. Screens displaying the
> > status of various nodes throughout the system are placed throughout
> > the construct.
> > System Operations: Any
>
> This would imply that the main CPU node (which may well involve
> mutiple processors, realistically, although other processors
> (including in networked-together computers) may very well be under its
> governance (e.g., for assigning parts of parallel programs, managing
> shared memory access, and running kernel threads)) is going to be the
> best-protected one under any sensible security architecture.

It was implied that the nodes of a host did not have to be physically
contiguous. Of course they also added lameness like one-way datalines so I
am not sure there was any sort of systematic approach to the old Matrix
rules.


> > The High Frontier playtest just started and we could really use
> > another look at some of the new clades and items like the "Rust."
> > Commentary on the Void Dancer templates and the like would also be
> > cool ;)~ And don't forget that Fifth Wave is coming up after HF
> > finishes playtest...
>
> OK, I'll try to do so after finally finding time to read over the
> earlier TS books and/or playtest files (depending on publishing
> schedules).

See you there ;)~

Kenneth Peters
Backup Lead Playtester for GURPS Transhuman Space: High Frontier

"We create an environment where it is alright to hate, to steal, to cheat,
and to lie if we dress it up with symbols of respectability, dignity and
love."
-Whitney Moore, Jr.
Message no. 7
From: shadowrn@*********.com (shadowrn@*********.com)
Subject: UMS Matrix Icons
Date: Tue Jun 12 16:05:00 2001
--part1_84.17420fdb.2857d13a_boundary
Content-Type: text/plain; charset="US-ASCII"
Content-Transfer-Encoding: 7bit

In a message dated 6/12/01 3:40:07 PM Eastern Daylight Time,
easmith@********.rutgers.edu writes:


This would imply that the main CPU node (which may well involve
mutiple processors, realistically, although other processors
(including in networked-together computers) may very well be under its
governance (e.g., for assigning parts of parallel programs, managing
shared memory access, and running kernel threads)) is going to be the
best-protected one under any sensible security architecture.
---------

Indeed, it usually is. From what I've seen, where black IC is used,
you can expect it'll be on the CPU at the very least. I think the CPU in SR
is something of a misnomer; I've always seen the SPUs as running specific
processes, while the CPU monitors and adjusts overall resource allocation
within a system. And as per Tzeentch's point on not having contiguous
hosts...you bet. Shadowland Seattle, I believe, has its nodes hidden in
various places across Seaatle, with the "connecting" node to the Shadow
Matrix being hooked up to an old US Military backbone.

On that note....if the Shadow Matrix runs off an old DOD backbone
(possibly the WWMCCS or GCCS backbones?), where in the hell is the NY
Shadowland node? A misnomer for a site at Camp Evans? Ft. Monmouth? Ft. Dix?
NAS Lakehurst/McGuire AFB? I don't remember there being any deployable bases
in NYC that were in service long enough to see the backbone (The Navy Yard
died with the advent of nuc-powered craft and NYC's refusal to allow basing
of said craft out of said yard, if I remember right), and I doubt they'd call
Ft. Drum as being in New York City, since it's nearish Buffalo or so.

John

--part1_84.17420fdb.2857d13a_boundary
Content-Type: text/html; charset="US-ASCII"
Content-Transfer-Encoding: 7bit

<HTML><FONT FACE=arial,helvetica><FONT SIZE=2>In a message dated
6/12/01 3:40:07 PM Eastern Daylight Time,
<BR>easmith@********.rutgers.edu writes:
<BR>
<BR>
<BR>This would imply that the main CPU node (which may well involve
<BR>mutiple processors, realistically, although other processors
<BR>(including in networked-together computers) may very well be under its
<BR>governance (e.g., for assigning parts of parallel programs, managing
<BR>shared memory access, and running kernel threads)) is going to be the
<BR>best-protected one under any sensible security architecture.
<BR>---------
<BR>
<BR> &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Indeed, it usually
is. From what I've seen, where black IC is used,
<BR>you can expect it'll be on the CPU at the very least. I think the CPU in SR
<BR>is something of a misnomer; I've always seen the SPUs as running specific
<BR>processes, while the CPU monitors and adjusts overall resource allocation
<BR>within a system. And as per Tzeentch's point on not having contiguous
<BR>hosts...you bet. Shadowland Seattle, I believe, has its nodes hidden in
<BR>various places across Seaatle, with the "connecting" node to the
Shadow
<BR>Matrix being hooked up to an old US Military backbone.
<BR>
<BR> &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;On that note....if
the Shadow Matrix runs off an old DOD backbone
<BR>(possibly the WWMCCS or GCCS backbones?), where in the hell is the NY
<BR>Shadowland node? A misnomer for a site at Camp Evans? Ft. Monmouth? Ft. Dix?
<BR>NAS Lakehurst/McGuire AFB? I don't remember there being any deployable bases
<BR>in NYC that were in service long enough to see the backbone (The Navy Yard
<BR>died with the advent of nuc-powered craft and NYC's refusal to allow basing
<BR>of said craft out of said yard, if I remember right), and I doubt they'd call
<BR>Ft. Drum as being in New York City, since it's nearish Buffalo or so.
<BR>
<BR>John</FONT></HTML>

--part1_84.17420fdb.2857d13a_boundary--
Message no. 8
From: shadowrn@*********.com (Damion Milliken)
Subject: UMS Matrix Icons
Date: Wed Jun 13 02:30:05 2001
DemonPenta@***.com writes:

> On that note....if the Shadow Matrix runs off an old DOD backbone
> (possibly the WWMCCS or GCCS backbones?), where in the hell is the NY
> Shadowland node? A misnomer for a site at Camp Evans? Ft. Monmouth? Ft. Dix?
> NAS Lakehurst/McGuire AFB? I don't remember there being any deployable bases
> in NYC that were in service long enough to see the backbone (The Navy Yard
> died with the advent of nuc-powered craft and NYC's refusal to allow basing
> of said craft out of said yard, if I remember right), and I doubt they'd call
> Ft. Drum as being in New York City, since it's nearish Buffalo or so.

Does the Shadow Matrix (by this I assume you mean Shadowland, hosted often
by the crew at the Denver Data Nexus or whatever it's called) really run off
old DOD lines? Perhaps you're right about the _Seattle_ Shadowland being
connected by such things, but what makes you think that all Shadowland nodes
are run over those old lines? It'd seem rather unlikely, in my view.

--
Damion Milliken University of Wollongong
Unofficial Shadowrun Guru E-mail: dam01@***.edu.au
-----BEGIN GEEK CODE BLOCK-----
Version: 3.12
GE d- s++:-- a24 C++ US++>+++ P+ L++>+++ E- W+>++ N++ o@ K- w+(--) O-@
M-- V- PS+ PE(-) Y+>++ PGP-@>++ t+ 5 X++>+++ R+(++) !tv(--) b+ DI+++@
D G+ e++>++++$ h(*) r++ y-(--)
------END GEEK CODE BLOCK------
Message no. 9
From: shadowrn@*********.com (shadowrn@*********.com)
Subject: UMS Matrix Icons
Date: Wed Jun 13 06:20:00 2001
--part1_11f.3931db.285898dc_boundary
Content-Type: text/plain; charset="US-ASCII"
Content-Transfer-Encoding: 7bit

In a message dated 6/13/01 2:40:20 AM Eastern Daylight Time, dam01@***.edu.au
writes:


Does the Shadow Matrix (by this I assume you mean Shadowland, hosted often
by the crew at the Denver Data Nexus or whatever it's called) really run off
old DOD lines? Perhaps you're right about the _Seattle_ Shadowland being
connected by such things, but what makes you think that all Shadowland nodes
are run over those old lines? It'd seem rather unlikely, in my view.
----------

That's what it says in Target: Matrix, Damien. Keep in mind, the US
has (or has had) bases basically everywhere.

John

--part1_11f.3931db.285898dc_boundary
Content-Type: text/html; charset="US-ASCII"
Content-Transfer-Encoding: 7bit

<HTML><FONT FACE=arial,helvetica><FONT SIZE=2>In a message dated
6/13/01 2:40:20 AM Eastern Daylight Time, dam01@***.edu.au
<BR>writes:
<BR>
<BR>
<BR>Does the Shadow Matrix (by this I assume you mean Shadowland, hosted often
<BR>by the crew at the Denver Data Nexus or whatever it's called) really run off
<BR>old DOD lines? &nbsp;Perhaps you're right about the _Seattle_ Shadowland
being
<BR>connected by such things, but what makes you think that all Shadowland nodes
<BR>are run over those old lines? &nbsp;It'd seem rather unlikely, in my view.
<BR>----------
<BR>
<BR> &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;That's what it says
in Target: Matrix, Damien. Keep in mind, the US
<BR>has (or has had) bases basically everywhere.
<BR>
<BR>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;John</FONT></HTML>

--part1_11f.3931db.285898dc_boundary--
Message no. 10
From: shadowrn@*********.com (Damion Milliken)
Subject: UMS Matrix Icons
Date: Wed Jun 13 12:30:01 2001
DemonPenta@***.com writes:

> Does the Shadow Matrix (by this I assume you mean Shadowland, hosted often
> by the crew at the Denver Data Nexus or whatever it's called) really run off
> old DOD lines? Perhaps you're right about the _Seattle_ Shadowland being
> connected by such things, but what makes you think that all Shadowland nodes
> are run over those old lines? It'd seem rather unlikely, in my view.
> ----------
>
> That's what it says in Target: Matrix, Damien. Keep in mind, the US
> has (or has had) bases basically everywhere.

Hmm, not that I know what I'm talking about, but the UCAS was formed between
2012 and 2018, and the crash of '29 happened in, well, 2029 (well duh!
<grin>). I would be wondering how all those pre-2018 US DOD lines could
handle the data bandwidth of a post-2029 communications medium...

Anyway, I'd better shut up before I show off my ever increasing lack of
knowledge ... and go and read Target: Matrix (which has been sitting on my
shelf for quite a while now gathering dust, and looking generally useless).

BTW, does anyone else find that the Target: series of sourcebooks are rather
useless? I can honestly say that I've never ever used one, and I have only
bothered to read the initial ones, and then only once. I even find the much
maligned and ill remarked place books such as London, Germany, Tir
Tairngire, and so on to be much more useful than the Target: books (I've
read all these at least twice, and have used each one at least once).

--
Damion Milliken University of Wollongong
Unofficial Shadowrun Guru E-mail: dam01@***.edu.au
-----BEGIN GEEK CODE BLOCK-----
Version: 3.12
GE d- s++:-- a24 C++ US++>+++ P+ L++>+++ E- W+>++ N++ o@ K- w+(--) O-@
M-- V- PS+ PE(-) Y+>++ PGP-@>++ t+ 5 X++>+++ R+(++) !tv(--) b+ DI+++@
D G+ e++>++++$ h(*) r++ y-(--)
------END GEEK CODE BLOCK------
Message no. 11
From: shadowrn@*********.com (BD)
Subject: UMS Matrix Icons
Date: Wed Jun 13 12:45:12 2001
> BTW, does anyone else find that the Target: series of sourcebooks are
> rather
> useless? I can honestly say that I've never ever used one, and I have
> only
> bothered to read the initial ones, and then only once. I even find the
> much
> maligned and ill remarked place books such as London, Germany, Tir
> Tairngire, and so on to be much more useful than the Target: books (I've
> read all these at least twice, and have used each one at least once).
> Damion Milliken

Well, I don't look at them every day or anything, but I find them to be a
heck of a lot more useful than the old style book, not to metion waaaaay
easier to read. Tir Tairngire, even though it's one of the better old
'place' books, gives me a headache just looking at it. I've used T:SH a
LOT, mostly for the New Orleans information. I haven't looked at T:UCAS
that much, but its time will come, and it will be plenty more palatable
than London. I'll put moeny on that :)

T:Matrix I found sort of neat in a trivial way, but it could have its
uses (it sure makes decking a little more interesting). Only recently have
I ventured into the exciting world of deckers, so I'm sure I'll get more
use out of T:M at some point.

Anyway, I like 'em much better than the old style
List-Every-Bar-And-Restaurant book. And I'm glad they're throwing many
locations into one book instead of just focusing on one; that makes the
book better, IMO, since I don't need everything spelled out for me, just
the basics.

====-Boondocker

__________________________________________________
Do You Yahoo!?
Get personalized email addresses from Yahoo! Mail - only $35
a year! http://personal.mail.yahoo.com/
Message no. 12
From: shadowrn@*********.com (shadowrn@*********.com)
Subject: UMS Matrix Icons
Date: Wed Jun 13 15:10:02 2001
--part1_c5.120bfd9f.2859154c_boundary
Content-Type: text/plain; charset="US-ASCII"
Content-Transfer-Encoding: 7bit

In a message dated 6/13/01 12:37:33 PM Eastern Daylight Time,
dam01@***.edu.au writes:


Hmm, not that I know what I'm talking about, but the UCAS was formed between
2012 and 2018, and the crash of '29 happened in, well, 2029 (well duh!
<grin>). I would be wondering how all those pre-2018 US DOD lines could
handle the data bandwidth of a post-2029 communications medium...
-------------
No, UCAS was formed in 2030. And, I doubt the actual physical wiring
has changed; DOD uses fiber optic a LOT (almost exclusively, lately), since
it's secure (generally), fast, and can support a lot higher level of
bandwidth than is currently used. IIRC, fiber optic is the main wiring used
in SR too.

John

--part1_c5.120bfd9f.2859154c_boundary
Content-Type: text/html; charset="US-ASCII"
Content-Transfer-Encoding: 7bit

<HTML><FONT FACE=arial,helvetica><FONT SIZE=2>In a message dated
6/13/01 12:37:33 PM Eastern Daylight Time,
<BR>dam01@***.edu.au writes:
<BR>
<BR>
<BR>Hmm, not that I know what I'm talking about, but the UCAS was formed between
<BR>2012 and 2018, and the crash of '29 happened in, well, 2029 (well duh!
<BR>&lt;grin&gt;). &nbsp;I would be wondering how all those pre-2018 US
DOD lines could
<BR>handle the data bandwidth of a post-2029 communications medium...
<BR>-------------
<BR> &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;No, UCAS was formed
in 2030. And, I doubt the actual physical wiring
<BR>has changed; DOD uses fiber optic a LOT (almost exclusively, lately), since
<BR>it's secure (generally), fast, and can support a lot higher level of
<BR>bandwidth than is currently used. IIRC, fiber optic is the main wiring used
<BR>in SR too.
<BR>
<BR>John</FONT></HTML>

--part1_c5.120bfd9f.2859154c_boundary--
Message no. 13
From: shadowrn@*********.com (Damion Milliken)
Subject: UMS Matrix Icons
Date: Wed Jun 13 16:00:01 2001
DemonPenta@***.com writes:

> No, UCAS was formed in 2030.

Oh yeah, good point! I should check more closely for these things, thanks.

> And, I doubt the actual physical wiring has changed; DOD uses fiber optic
> a LOT (almost exclusively, lately), since it's secure (generally), fast,
> and can support a lot higher level of bandwidth than is currently used.
> IIRC, fiber optic is the main wiring used in SR too.

Hmm, I'd still doubt very much that exisiting fibre cables would be able to
handle SR style full simsense VR bandwidth loads. And even with 1 year
between the recovery from the crash of '29 and the formation of the UCAS, I
seriously doubt that the US DOD got too many high bandwidth cables layed.
For that matter, even if they did, I rather very much doubt that cables
layed in 2030 would be able to adequately support the bandwidth for 2050+
systems.

Even though fibre cables are also used in SR, I'd liken it to saying
"silicon based processors were used in 1970, too!", when trying to make the
comparison between todays computing technology and the computing technology
of the past. Sure, they used the same basic principles, but the engineering
of it was orders of magnitude different, and the capabilities were
staggeringly different.

Anyway, ignore me, I'm just having a bit of a whinge at FASAs (pretty usual)
lack of adequate forethought for many of their published products. :-)

--
Damion Milliken University of Wollongong
Unofficial Shadowrun Guru E-mail: dam01@***.edu.au
-----BEGIN GEEK CODE BLOCK-----
Version: 3.12
GE d- s++:-- a24 C++ US++>+++ P+ L++>+++ E- W+>++ N++ o@ K- w+(--) O-@
M-- V- PS+ PE(-) Y+>++ PGP-@>++ t+ 5 X++>+++ R+(++) !tv(--) b+ DI+++@
D G+ e++>++++$ h(*) r++ y-(--)
------END GEEK CODE BLOCK------
Message no. 14
From: shadowrn@*********.com (Jeffery Green)
Subject: UMS Matrix Icons
Date: Thu Jun 14 00:00:01 2001
--- DemonPenta@***.com wrote:
> In a message dated 6/13/01 12:37:33 PM Eastern
> Daylight Time,
> dam01@***.edu.au writes:
>
>
> Hmm, not that I know what I'm talking about, but the
> UCAS was formed between
> 2012 and 2018, and the crash of '29 happened in,
> well, 2029 (well duh!
> <grin>). I would be wondering how all those
> pre-2018 US DOD lines could
> handle the data bandwidth of a post-2029
> communications medium...
> -------------
> No, UCAS was formed in 2030. And, I doubt the
> actual physical wiring
> has changed; DOD uses fiber optic a LOT (almost
> exclusively, lately), since
> it's secure (generally), fast, and can support a lot
> higher level of
> bandwidth than is currently used. IIRC, fiber optic
> is the main wiring used
> in SR too.
>
> John

I belive you are correct about that or at least in our
games we have not encountered stranded cables yet. It
all has been F.O.

__________________________________________________
Do You Yahoo!?
Spot the hottest trends in music, movies, and more.
http://buzz.yahoo.com/
Message no. 15
From: shadowrn@*********.com (Scott Harrison)
Subject: UMS Matrix Icons
Date: Thu Jun 14 02:05:01 2001
--Apple-Mail-527847497-3
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
format=flowed;
charset=iso-8859-1


On Tuesday, June 12, 2001, at 10:10 , DemonPenta@***.com wrote:

>       On that note....if the Shadow Matrix runs off an
old DOD backbone
> (possibly the WWMCCS or GCCS backbones?), where in the hell is the NY
> Shadowland node? A misnomer for a site at Camp Evans? Ft. Monmouth? Ft.
> Dix?
> NAS Lakehurst/McGuire AFB? I don't remember there being any deployable
> bases
> in NYC that were in service long enough to see the backbone (The Navy
> Yard
> died with the advent of nuc-powered craft and NYC's refusal to allow
> basing
> of said craft out of said yard, if I remember right), and I doubt
> they'd call
> Ft. Drum as being in New York City, since it's nearish Buffalo or so.

First of all, Ft. Drum is not near Buffalo, but north of Watertown which
is north of Syracuse which is East of Buffalo a good few hours by
car. :-)

I would imagine you could always use West Point as the NY Shadowland
node. West Point is close enough to present day NYC to have gotten
sucked up into its urban sprawl in the future.

--
Scott

--Apple-Mail-527847497-3
Content-Transfer-Encoding: quoted-printable
Content-Type: text/enriched;
charset=iso-8859-1


On Tuesday, June 12, 2001, at 10:10 , DemonPenta@***.com wrote:


<excerpt><fontfamily><param>Arial</param><smaller>      On
that
note....if the Shadow Matrix runs off an old DOD backbone

(possibly the WWMCCS or GCCS backbones?), where in the hell is the NY

Shadowland node? A misnomer for a site at Camp Evans? Ft. Monmouth?
Ft. Dix?

NAS Lakehurst/McGuire AFB? I don't remember there being any deployable
bases

in NYC that were in service long enough to see the backbone (The Navy
Yard

died with the advent of nuc-powered craft and NYC's refusal to allow
basing

of said craft out of said yard, if I remember right), and I doubt
they'd call

Ft. Drum as being in New York City, since it's nearish Buffalo or so.

</smaller></fontfamily></excerpt><fontfamily><param>Arial</param><smaller>

First of all, Ft. Drum is not near Buffalo, but north of Watertown
which is north of Syracuse which is East of Buffalo a good few hours
by car. :-)


I would imagine you could always use West Point as the NY Shadowland
node. West Point is close enough to present day NYC to have gotten
sucked up into its urban sprawl in the future.


--

Scott

</smaller></fontfamily>
--Apple-Mail-527847497-3--

Further Reading

If you enjoyed reading about UMS Matrix Icons, you may also be interested in:

Disclaimer

These messages were posted a long time ago on a mailing list far, far away. The copyright to their contents probably lies with the original authors of the individual messages, but since they were published in an electronic forum that anyone could subscribe to, and the logs were available to subscribers and most likely non-subscribers as well, it's felt that re-publishing them here is a kind of public service.

Thwap!