SoylentNews is people
SoylentNews
US Customs and Immigration computers went down at various airports around the US yesterday, causing some havoc for travelers returning from holidays. It left hundreds of folks stuck in lines for a couple of hours in a part of the airport where there's normally not a lot to do. The agency didn't say what caused the problem, but said "there is no indication the service disruption was malicious in nature."
As Reuters notes, a similar outage occurred at the same time last year, so it might be that the customs systems were slammed with Christmas travelers and couldn't handle the excess traffic. Agents were still able to process passengers using an alternative system, albeit at a much slower rate.
Source: https://www.engadget.com/2018/01/02/a-us-customs-computer-snafu-caused-major-airport-delays/
(Score: 4, Informative) by DannyB on Wednesday January 03 2018, @02:35PM (1 child)
I'm sure mainframes use the latest advances in tech. In fact, from what I see, they even use more exotic tech than in the most insanely insanefully insane gamer systems. Cabinets with cool decorative design features and lights which serve no actual compute function.
But there are two problems.
First, a non technical problem. You can't do anything without someone there holding their hand out for money. It's worse than friggin' Microsoft, if you can imagine that. Not only do you pay to activate software features that you already have code for, you pay to activate hardware features that you already have. (So I am led to understand.) Any way you want to configure your workload, there is a representative there to squeeze out every last nickel and dime.
Second, the architecture is all wrong. The now industry standard way is to use cheap, unreliable, commodity hardware in large clusters running Kubernetes. Kubernetes is (was) a $2.7 billion market in 2017. It's the current buzz. Lots of articles. It's also surprisingly simple to set up and play with on a couple of VMs on a laptop. Your workload is built as Docker containers, using whatever Linux technologies, and languages that you want. Once you package up a container, many instances of it can run on Kubernetes. (Obviously, you have to design your workload to run in this parallel fashion.) An entire infrastructure, including mass storage (such as Gluster FS) is designed to support all of this. It's the product of "google thinking". The realization that instead of focusing on super fault tolerant hardware, you focus on hardware that you know absitively posolutely will fail. You can run the Netflix provided open source Chaos Monkey to randomly reek havoc across your cluster, taking out processes, containers, storage nodes, network connections, etc, to ensure that your system (is properly designed) to continue to run smoothly despite these failures.
Gigantic scalability. Start small. Add more compute nodes or storage nodes (gluster fs) as needed to scale linearly or add more redundancy.
You can use more expensive nodes that are fault tolerant. You can use RAID arrays. But you don't have to. You could use gluster fs on cheap commodity boxes and commodity hard drives. When a drive or node fails, you can replace it and bring it back into the cluster. A storage node will in time, be rebuilt automatically and then be back online.
What I've said here is the result of dabbling in kubernetes in the last couple months, and only reading about how to set up and configure gluster fs, but not actually setting it up yet. It is impressive stuff.
It makes me wonder what would be the motivation to use a mainframe instead? (Or similarly, why use a Microsoft OS.)
To transfer files: right-click on file, pick Copy. Unplug mouse, plug mouse into other computer. Right-click, paste.
(Score: 2) by Nerdfest on Wednesday January 03 2018, @03:53PM
The people that work on them generally have worked on little else, and they have brand loyalty. "Nobody ever got fire for buying IBM". On top of that, a very large percentage of the code running on these pigs is some of the ugliest, decrepit, patched-over 50 year old code. COBOL code. So wordy that it's a nightmare to debug even when well written, which it almost *never* is. It makes spaghetti look well organized. It's even difficult to pull common interfaces out of much of that crap reliable to port at least some portions to other solutions.
It's the sort of code everyone is afraid to even touch.