Originally posted by far-trader:
<snip>
Add in the fact that it's a system that doesn't need any maintenance (i.e. never crashes or fails except when abused, like by firing a a ship mounted weapon at it) and it's easy to make an argument for it being too small.
Ah, massive redundancy . . . that's an interesting supporting idea.
Originally posted by far-trader:
IMTU the "actual" computer is about half the listed volume with the rest taken up by access to and around it and the various control circuit conduits throughout the ship.
Comparing a fib model, as RainOfSteel does, you need to recall that the size is doubled because you are adding a full redundant backup for everything, one that is resistant to ship size nuclear weapons going off just outside the ship.
I believe that silicon based computers would be quite vulnerable to EMP, and I'm familiar with the effect of radiation on computers.
However, at TL-11 and up, we have synaptic and positronic systems (both handwavium systems). Neither of these are semi-conductor systems (they're handwavium systems, AFAICT), so there's no reason to suspect they'd be vulnerable to radiation or EMP (other than an artificial one we create for it).
But I'm prepared to concede that redundancy and armoring may well require substatial extra mass. But not as much as is listed.
Additionally, I was always interested in the fact that the fib-side backup was "immune", effectively, to radiation damage. I couldn't figure out why both primary and backup weren't fib computers, especially since the full fib backup of Model 9 was only 60 MCr more . . .
A Model 9 Fib/Fib computer . . . wouldn't it cost only 120 MCr?
Originally posted by far-trader:
As for computer techs in the crew, it's a good idea but not really needed on small ships (less than 1,000 tons). I figure the additional crew for the larger ships includes electronics technicians.
On a small ship, no. On a big ship, yes.
An "electronics tech" is not a computer systems administrator or computer programmer. The OS systems that are deployed aboard such large systems often come with built-in bugs that even the systems programmers who came up with it can't track down (you should see the lists of obscure technical bugs and issues that affect the various editions and successors of the mainframe OS, MVS; I'm sure its only two pages shorter than the bugs list for Windows). An Electronics tech couldn't hope to track down many problems.
Imagine: The gunners of a capital ship file in and sit down in their assigned seats in a lengthy control room in the bowls of the vessel, ready to direct their batteries. The bridge signals that the excecise is about to get under way, and fire-control comes online in prepartion for the weapons-free order.
Now, the sensors in each battery's fire control feed data into the Ship's Computer, which in turn displays it at the gunner's workstations.
This time, the gunners take hold of their fire-direction controls, only to discover that the fire-control sensors won't track.
The Senior Electronics Tech of the ship spends a minute examining the diagnostics programs, all of which tell him nothing has gone wrong.
A team of Electronics Techs spends several hours tracing every electronics component and connection between the batteries and the computer and the gunner's workstations, but to no avail.
I hope one of them has Computer-3 or better (not a certainty in a ship that doesn't require that specialty; and even if there were some, if such persons weren't officially identified, they may not get the chance to do the job).
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?
Trust me, the Captain will
not sit still for, "It'll take twelve weeks round trip to get an update, plus a delay of between 1-2 weeks to program the solution."
Captain says, "You have twelve hours." I hope the hapless soul has Computer-6.
Anyway, what I'm really getting at is that a hugely complicated computer needs a dedicated professional computer staff on hand to make sure the above doesn't arise constantly (and even if they're there, if my existing experience is any indicator, it'll still happen, just less frequently . . . ok, it depends on who you have taking care of the systems). Only, if they are present, and professional, they'll have the skillset necessary to produce their own solutions.