Data Storage Media?

[Straybow]

Answer. The driver responsible for allowing the ship's computer to communicate with the battery fire control sensors had a license expiration. There was no one on board assigned to or qualified to take care of it, and so an update was never installed. And that's an easy one. There can be much more complicated issues.

Perhaps a new set of drivers were installed, updates for the Jump Drive, which can't be backed out due, say, to an unacceptable danger arrising from a recently discovered flaw in the driver that raises misjump chances. And then these Jump Drive drivers turn out to be incompatible with the battery fire-control sensor drivers. Now what?

First, any military that uses time-licensed software deserves to get its clock cleaned. Second, the idea with OTU tech stagnation is that all such bugs got worked out of computer/control designs centuries ago. Vilani valued reliability above innovation, and Solomani influence only diluted that to a limited degree.

 

[RainOfSteel]

Originally posted by Straybow:
</font><blockquote>quote:</font><hr />Answer. The driver responsible for allowing the ship's computer to communicate with the battery fire control sensors had a license expiration. There was no one on board assigned to or qualified to take care of it, and so an update was never installed. And that's an easy one. There can be much more complicated issues.

Perhaps a new set of drivers were installed, updates for the Jump Drive, which can't be backed out due, say, to an unacceptable danger arrising from a recently discovered flaw in the driver that raises misjump chances. And then these Jump Drive drivers turn out to be incompatible with the battery fire-control sensor drivers. Now what?

First, any military that uses time-licensed software deserves to get its clock cleaned. Second, the idea with OTU tech stagnation is that all such bugs got worked out of computer/control designs centuries ago. Vilani valued reliability above innovation, and Solomani influence only diluted that to a limited degree. </font>[/QUOTE]True.

I think, though, that if a society valued reliability so much over innovation, that eventually someone else who did value innovation would come along and clean their clocks.

 

[RainOfSteel]

As for the time license software, that was just what I came up with at the spur of the moment. It was inappropriate for a military vessel's computer system.

 

[MR TEK]

Do recall that the navy, (all services today) contract the LOW bidder. Systems are often speced so that the only company that CAN meet the spec is the one you happen to be getting a kickback from (cash, job offer, job for a relative or whatever), both of which lead to less than state of the art systems that tend to be buggy.

It is also a time honored tradition in mil spec purchasing to by components with a definite shelf life, so that the corporation feeding at the public trough gets a second, (3rd, 4th, etc ) shot at resupply contracts.

Add in that purchasing people seem top be blissfully ignorant of even the most basic issues of software licensing, that time limited software is the LEAST of your worries.

to the military folks: How many systems have failed miserably, because during design and test with a few targets they seem fine, but on the battle field, with many multiple times the targets used in testing, they either go tits up completely, or mis-identify friend and foe. (Sac early warning systems, and Patriot are just the two most publicized.)

Let’s not even talk Star wars. Even with one specific target, AND knowing the time and place of launch and it's course, to date has ZERO successful tests, Few successful Sims, and only has a couple of tests, where they were able to REDIFINE success( justify the failures as due to causes beyond the test parameters,) enough to CLAIM partial successes.

Yes, an out of license, or potentially not the correct revision, and/or incompatibility with another application, is not only extremely plausible, but suggestions are such events are routine.

Remember, NASA, probably the most anal retentive organization ever created, lost a probe because the design team assumed measurements in SI units, (meters, etc) and the telemetry gear reported the measurements in English units.

Also remember APLLO 13. The motor used to drive the unit to "stir" the oxygen tanks to keep them from pooling in microgravity was designed to use one voltage, and the control system used a different voltage. The motor arced because it was not designed for the voltage applied. (if I recall, the different voltage was used during testing, and burned away insulation, so when the pump was switched on inside an oxygen tank, the wiring was exposed and arced.) the rest as they say is history.

In short, any organization as large and spread out as a large military should count on purchasing folks not understanding the mission specs well enough to to catch software bugs, application incompatibilities, sunset dates, upgrade schedules, patches, or any of the million and one issues that make "mission-critical" software systems such a joke right now.

All sorts of systems have been proposed, but as long as competitive bids and sloppy bid processes are a part of the military procurement process, someone will always try to work the system, and failures can be spectacular and catastrophic.

MR TEk

 

[EntilZha]

I was wanting to know what people in Traveller use to store data on. I wasn't expecting treatises on computing power and size (interesting though they were).

My God, what have I done???

 

[MR TEK]

Guess I started that. Long and short from my first post was some sort of molecular structure, most likly a crystal of some sort, and storage capacity almost beyound our ability to comprehend.

(on would suspect the actual memory element to be small enough taht you would handle it is a transport cntainer of some sort. A sleave or case arrangement, like a hard shell disk, at a guess.)

Mr TEk

 

[RainOfSteel]

Originally posted by EntilZha:
I was wanting to know what people in Traveller use to store data on. I wasn't expecting treatises on computing power and size (interesting though they were).

My God, what have I done???

You have caused a conversation!

 

[RainOfSteel]

My experiences with large firms (multi-billion dollar firms), tends to confirm what Mr Tek is saying about the inability of such organizations to produce or acquire working software.

Further thoughts about the Vilani (based on my reading of Vilani and Vargr), tend to indicate that the Vilani value conformance and consensus<sp>. Conformance driven groups value hard work and work done well. People in such a group are quite likely to hide any errors they create or otherwise minimize their importance, they have to, because if they reveal the problem they aren't "conforming" to the standards of the group.
This produces, shall we say, buggy software.

 

[jasper]

so the new song would be what if had a war and all the soldiers and generals came but the software was vaporware?

 

[aramis]

I often assumed traveller computers were huge racks of micro-vaccum-tube arrays... cranking away comfortably at 370-600 kelvin... since vaccum tubes only need be a few microns thick, you can get some high density stuff going.

I justified this by claiming to players that J-Space made semiconductance of silicates less reliable, but didn't interfere with vacum tubes. Since these will be big blocks, I also assumed a fairly standardized architechture for modules, and massive multi-processing. I also assumed physical state-switch program storage memory, with electronic memory for operational memory. All running a virtual machine, so that the standard software is always there in an identical format. That virtual machin is basically an old Vilani Model 0's operating system and command set....

During the T20 playtest, I bagan to figure the major chunk as terminals. (Ah, I miss that revision of the computer rules... but terminal counting WAS a pain!) I still think of an Imperial Virtual Machine as the basis for compatibility across the imperium. The IVM stadard hasn't changed since Cleon Zhunastu's proclimation to make it happen.

Most media IMTU are physical media, with standards having been established by Cleon as part of the IVM standards. As new technologies were introduced, the formats were given a decade to sort out, and then a tandard was picked, and forever after, that format was required.

So there is an Imperial Holocrystal format, a optical storage emdia format, and several other specific formats. No semi-conductor based formats are sued shipboard, for the above reasons.

 

[Evo Plurion]

FWIW, and there are other threads on this topic, Traveller computer technology seems pretty primitive for five millenia in the future. In far less time, we may be using a DNA or subatomic analogue for data storage. By Traveller's time, even assuming some periodic technological regression, the actual processing and data-storage components of a computer will be very small. Redundant systems, armour and physical access will require some extra mass, but not much. As for interface, IMTU the computers interface with users via voice and/or holographic avatars. Very little direct physical human control is needed. Most of the console-space on the bridge of a starship houses monitors and other indicators - not keyboards and disk drives.

 

[aramis]

COnsider this: a current technology: Synaptic Computing.

According to a show n the Science Channel (Discoveries this Week) synaptic processors are about 40 neruons to a chip... said chip was under 1cm by 1cm, and will interface with living neurons!

 

[EntilZha]

Originally posted by Aramis:
COnsider this: a current technology: Synaptic Computing.

According to a show n the Science Channel (Discoveries this Week) synaptic processors are about 40 neruons to a chip... said chip was under 1cm by 1cm, and will interface with living neurons!

Hmmm....shades of "Cyberpunk", "Neuromancer", and "Johnny Mnemonic"...

 

[robject]

Aren't they experimenting with silicon chips that can help the blind see and the deaf hear?