Stuff like this will happen more and more. We treat software driven systems rather recklessly.
Basically at the market open all the requests to buy and sell get matched at the same "open" auction price, then (a second later) the orders get sent to the order book, where the price can go up and down based on size. Because the system didn't think there was an opening, there wasn't the opening auction, the prices went straight to the book and there were large swings in price.
- William E. Vaughan https://quoteinvestigator.com/2010/12/07/foul-computer/
It's clearly not optimized for efficient use of personnel, but the personnel complement will have been designed to provide sufficient people at all times and the cost of getting it wrong can be very large indeed.
Though in that state it can't do much more than fly: combat capabilities are strongly diminished, maintenance doesn't happen, post-combat repairs are out of the question, science missions would be much harder. On occasion the Enterprise has transported 150 passengers, so I imagine there's a lot of kitchen staff, security, etc. You only need 5 people to fly the ship, maybe 40 to fly sustainably with maintenance, but to actually accomplish their reglar mission you need the other 300 people.
On the other hand, the Enterprise won't even warn anyone when command staff are injured, cloned, mind-controlled or vanish from the ship altogether unless a human asks the computer where a specific person is first.
Of course there are Doylist reasons for all of this but I do like the premise of a general fear of AI and possible weird space BS being a factor.
The canon explanation is that automation-in-charge was experimented with and went really badly, though periodically they try something approaching it again.
https://memory-alpha.fandom.com/wiki/The_Ultimate_Computer_(...
(AI, human genetic engineering, and a number of other areas of technology are affected by variants of this issue in the Trek canon.)
I disagree. When the sub sinks, all these people die. That's far more inefficient use of personnel.
It feelf like you're putting more emphasis on the material cost ("the cost ... can be very large indeed") than on what actually matters.
In wartime you would care about efficiency, build the largest number of subs staffed with the minimum crew. And since training crew quickly becomes the bottleneck you would probably go for the highest degree of automation that doesn't impact production times too much. In peacetime, efficiency isn't as important. What is important is the bad PR of losing one of your submarines in a training excercise or on patrol, so crew safety becomes a much bigger concern.
Losing those sailors in war would have been a noble sacrifice for the cause, losing them to the exact same accident in peacetime is a national tragedy.
Losing one during wartime can cost you the war.
An inefficient one that probably won’t sink due to combat damage can stay in the fight long enough to matter.
As a former naval officer I can only say that technically losing any vessel could be the one that loses a war, just as any soldier lost could be the straw that breaks the camel's back. But if your navy is so rickety that the loss of a single vessel is enough to lose then the main deficiency was in planning rather than any specific warship loss. Losing one in peacetime should never happen but is not unheard of even in modern times. See eg the Kursk or the Fitzgerald.
It could also be argued that the Romans capturing a single Carthaginian warship turned the tide for their entire empire.
It was “too important to automate” so a trading assistant keyed it in every morning. One morning he typed the wrong number and the mistake was in the billions digit.
At 2:45 “the cage” called the repo desk and said “You know you guys are still short a billion, right?”
There was then a flurry of activity as traders got on the phone to try to borrow a billion dollars in in fifteen minutes, while also trying to not let on we were kind of over a barrel. The head of fixed income prepared his explanation to the Fed about why we needed to borrow a few hundred million overnight.
The number got automated in our next release, and the open procedure was changed to the trading assistant verifying the number against the “cage” report.
Process changes that people have to remember or more systems to prevent the issue. So I don't get your statement related to this article
Shutdown and wake-up time in bios of server and switch ;)
We will simply create a second system (B) to monitor the first system (A). Now we have two systems to maintain. System B will not be capable of steering A by itself. So we still need to know how to diagnose and repair A, and we also need to know about B too. Maybe system B can talk to a Prometheus/Grafana stack (if it's up). And that can put alerts into Slack (which we ignore because there's always alerts in Slack). And after standup we can take turns looking at graphs with consternation.
> Stuff like this will happen more and more. We treat software driven systems rather recklessly.
That sentence is where I go when I hear the word 'automation'.
More people -> more entropy -> much more things to go wrong
I did last year, and my company is in the process of de-automating certain processes that can endanger that company if they go wrong.
There are many things in tech that are too important to automate.
I'd even posit that the more experience you have in tech, the more you've seen how things go wrong, and the more you realize that automation is a tool for humans to use, not a replacement for humans doing a task.
Much much much more due to human error......but hey maybe you are the worst programmer ever..but even then i would say your programs are more reliable then a human.
You'd have to have more than 1 person involved to forget that DR is still active when completing these failover exercises and tests off-hours.
Well, they are a tenent at the Cermak data center. It’s a truly massive building with huge amounts of connectivity and colo opportunities. Probably also the only 100+ year old data center building on the US register of historic places, lol (it’s a former catalog printing facility, built to hold insanely heavy printing presses on 8 or 9 really tall floors, so it has no problems with densely-packed server racks)
It seems to have multiple purposes - DR, customer software testing, etc.
You'd be surprised how many manual processes there are in places like this. It's a combination of legacy systems / processes, and a general paranoia around automation going wrong. I wouldn't be surprised if they always have someone there to shepherd the system along.
We had hundreds of jobs and upgrades happening over each weekend. It definetly needed an eye casting over it regardless of the automation.
And the AU orders going through is a good sign, but it's far from guaranteeing a free monday, as Japan, Korea or Shanghai can fuck it up, each in their own little ways. Hong Kong is the best, low regulatory crap, invested regulator, high volume low latency traffic everyday (relative to the region), I cant recall a time it broke.
Once, someone fat fingered an excel import at close, and we lost our trading license for that entire country for 18 months. And we're not small. But the amount mismatched at settlement was super tiny. High attack surface, low holistic understanding (it works despite us, we honestly have no clue sometimes), heavy consequences on screwup.