Would you mind getting back in to your bottle?
371 posts • joined 17 May 2012
I used a box containing a network of Transputers in something called a Computer Surface. We used it to model results from seismic modelling on a Cray. We eventually turned a system running on an IBM 3090 where we generated one image every 3 minutes, to one that generated 30 images per second. It was truly amazing.
It is a shame that no-one really understood it, it was way ahead of its time.
It was an employee training record system, called Training Information Tracking System. Can you see where this is going. I came in late to the project, to take it from a VB6 incarnation to a fully fledged mainstream app on SQL Server. But I was sitting with the team, getting their user stories, when one of the ladies on the desk found a record that wasn't it the database. She went to tell the boss (male) who promptly shouted out "Well get it on your TITS then".
Just as his boss walked by. Big boss WAS NOT AT ALL AMUSED, said so, and asked who was responsible, to which they all looked at me.
That caused me no end of grief with HR getting involved for "my gross profanity" until the IT director had the decency to say I had taken over the project, and it was the now ex-contractor who was responsible.
Having your apps on the cloud is really having them on someone else's computer. You trust that person to do the right thing, all day, everyday. Exporting your business to the cloud does save you an IT department, but it does not alleviate you from risks: business, technical or human.
I use Atlassian on the cloud. The biggest issue is that we can't back it up ourselves. There is no "Export and download" function.
Sunguard to customers: Regardless of your contract, you have to pay more because we have to pay more and we have to pass on to you these increased costs.
Sunguard to Leaseholder: Look, we have no money so you are going to have to take a haircut.
Do these two statements sum up their position?
I keep saying that the cloud is just a different way of spelling "someone else's computers".
Back in the day when our Uni had an IBM 360/158, as did the company where I worked as a summer intern. When I was the intern I ran a JES2/HASP job that failed, but did so in a very interesting way - it printed a message on the system console. So, as students we decided to try this out on the Uni's computer to see if it did. And yes it worked.
So we managed to print "Big Brother Is Watching" on the system console.
And that is how we caused the unionised system operators to walk out and how we all looked at one another when questioned and said, "no, not me".
Fortran on an Elliot 903, using paper tape. Feed in the compiler program, feed in your program, and it spewed out a paper tape of compiled code. You fed this in to a second machine that would execute the program. And it was exciting!
The on to the Universities IBM 360/158 running MTS. Which was great, because we found out how to work around the security (thats what happens when you give the students the source code to the O/S!) Again it was fun.
Then on to Vaxen. My all time favorite operating system. The joys of DCL. The power in a properly written system service calls. Hey, being able to add your own system service calls. Macro-32 and Bliss.
So a faster version of what we already have is, yeah, a bit meh.
If this password policy is 10 alphanumeric characters, does that include upper and lower case characters and the numerics 1-0? If so that means that are 62 possibilities for each character cell. We have to have a character at the start, so the number of possibilities is
26 x 62^9 = 7E17.
which is quite a lot. If you can try 100 Million a second, that works out to around 200+ years.
Even if we don't allow lowercase characters, and if the first character has to be a letter, that still leaves 36 possibilities for each other character cell. So the number of possibilities is 26 x 36^9 = 2.6E15, which is a sizeable number. Or at 100 Million tries per second, 300 days. Not perfect by any means, but not a day.
To achieve cracking the password in a day, the cracker would have to do 30,000 Million tries per second. Thats only going to be possible with a network of quite beefy computers, and will result in a DDOS attack on Virgin Media. Some may say that they deserve this, I couldn't possibly comment.
Besides which, modern systems recognise when random attempts are being tried to guess a password and should simple disable the password and text or call the subscriber.
That would be the one who turned up 2 weeks after installing a massive double fronted rack of disks, sliding in front and back. His job was to note the serial numbers down. Only he knelt down and knocked the master cabinet power switch. Only for a moment mind, he switched back on immediately, hoping no-one would notice. However, the Oracle clustered database which was using the array did, and crashed. And took out one of the table spaces which refused to recover.
No problem. We had a backup, written by the system manufacturer, so we just loaded up the tapes and found .... that tablespace wasn't backed up. Because it was a read-only table space.
So, we handed the whole thing over to the supplier. Tapes, disks, computers, backups, and told them - Recover That.
They failed, obviously. But the called a meeting to say that they had fixed the problem. Where they handed me, in front of the Director of IT, an envelope. Inside was a single sheet of paper. This was an official change to the manual that said that the configuration they had spec'd, installed, setup and handed over was no longer supported, so they weren't liable.
Strangely they got knocked off the preferred supplier list that morning.
Oh, yes. I was there 77-80 doing a Joint Honours in Computing and Electronics. The fun we had on that mainframe. We did do a bit on punch cards but mainly we used the terminals upstairs in the computing room. Having only previously used punch cards and paper tape I do recall being rather scared the first time I had to use a terminal. But we did learn PL/1 on a terminal.
And APL. The only language which was write once and hope. Because if you ever had to come back to it a week or so later it was impossible to understand.
Later moved on to programming Motorola 6800 series in assembler.
Heady days indeed!
It's not just electrical wiring. I worked in one office that had two wings. Each wing had a thermostat, which controlled a heating system.
Yes, you are way ahead of me, the left side thermostat was wired to the right side heating. So as one side was cold and turned the heating up, so the other side would get hot, and someone would turn the thermostat down. This went on for months, with the heating engineers coming in, getting the system balanced with everyone happy for a day or two, before the system just went in to chaos mode and the feedback loop either froze or boiled the office.
Eventually a new bright spark figured out what was wrong. He asked if he should correct it. But the office manager was in a third building. "Naaa, leave it as it is - it's just too much fun fielding the complaints of these people". We eventually told both sides that if they felt cold, turn the heating DOWN, and it will get warmer. That worked. We explained that the heating controls were made for Australia and hence were upside down!
"We don't use paper charts at all," Severn's captain, Commander Philip Harper,
Actually, commercial vessels have used n Electronic Chart Display and Information System (ECDIS) for some time. No one in the commercial world has used charts for decades.
What would more helpful is if Royal Navy ships actually use AIS (Automatic Identification System) whilst they are manoeuvring in port, so that other vessels see them on their ECDIS systems and can take avoiding action when the Navy Lark pulls some damn fool stupid turn without notice, expecting everyone else to scatter out of their way.
Ahoy, Skipper:our very large cargo ship/oil tanker does not exactly spin on a six-pence when it comes to turns, and we need 1/2 nautical mile (that's 37 Olympic swimming pools) to stop.
My best one is when I inherited a complete trading and logistics system written in VBA with an Excel front end. Oh, and with approx 20 inter-linked spreadsheets.
Nightmare. It was still running when I left, because the team that used it actually loved the fact that it was built for them, by a contractor they employed directly. The first IT knew of it's existence was when the contractor left and they had to ask IT to take on support. My attempts to have it rewritten in to something more supportable where not accepted.
The beauty and evil of standards is that there are so many to choose from.
We don't use K8 or Docker here either. It just seemed to us to be overly complex for the deployment of a simple JAR. We use a script to build the jar and deploy to a staging area. It works well. We are in total control, and there are no unnecessary layers.
Of course, as with any projects, the STO reserves the right to change his/her mind at any future point in time, with out notice or explanation. So by the time you read this we could be on AWS using Elastic Beanstalk. Exciting being in devops.
similar story. We had built the first image for a power control plant that was to hook up and manage a number of nuclear power stations. Thanks to the local telecoms muppets we were way behind schedule and hadn't started our clone of the standard image on to the workstations. Until one evening, the system came online, and we started doing a long suite of tests with the power station. And left for the night.
When I got in next morning all hell had broken lose. People were going mental and the site managing director wanted to rip me a new one. It seems that we had sent a "SCRAM" command to the reactor. For those not knowing, this shuts down the reactor hard and fast, and can take months to recover from. I asked for an hour to find out what was going on.
With the hour up, we went back in to the meeting for round two of lets beat up the IT techies. Where I asked if "Jerry" was joining us (not his name). Jerry was there. He was from the company building the reactor control equipment that we connected to. His work was behind schedule, caused by our work being behind schedule. So I asked him how come all the PC's in the control office were all up and running. He then somewhat sheepishly admitted that he had, over night, cloned our working machine that was doing tests and installed the image over all the new machines that we had not yet configured. He then started doing some commands to see if the reactor was behaving.
The problem was that he had not changed the unique addresses of the workstations. This is pore internet, so they were sort of like IP addresses but exactly the same. The protocol allowed the boxes to come up. So Jerry booted all 8 boxes. And sent a command to the reactor.
Now the protocol was: Send a command. Reactor sends the command back for confirmation. The PC then replies, yes, that's what I want, and the reactor says OK, here is the result. Trouble was, one PC said yes, that's fine but 7 said - no, we didn't ask for that. So the reactor does another round of checks. And agsin 1 says yes and 7 say no. The reactor then assumes it's under attack and shuts itself down. Hence the scam command.
Fortunately we didn't cause too much damage as we were only talking to the control test rig, not the actual reactor. But it did get me the missing lock on our computer room and Jerry a flight home. Oh, and we got our names on rather splendid mural at the entrance hall for having saved the say!
The explosion icon, well, its obvious.
At what was once described as Europe's Biggest Data centre . have no idea if this was true, but as a 23 year old, it was pretty damn big. Think a large aircraft hanger filled with mainframes, tapes, printers and drum storage. The local power builders managed to put a JCB through the heavy duty three phase power supply, which mist have brought tears to the operator.
We ran a motor-generator set, with a large fly wheel to keep the generator going until the diesel kicked in. Which it duly did, coughed spluttered and died. We had forgotten that diesel can wax, which ours, unused for years, duly had. So the injectors clogged and the thing refused to work. The embarrasing thing is that we were an oil company, and we were supposed to know about such things!
I thought I would look at Fastly to see if they could host my companies website,
eCommerce - Check
Small business - Check
Savings of £150,000 over a three year period. Sound good, that £35,000 savings per year,
WAIT ONE - we aren't spending anything like that to manage a web server, three app servers and a database server. With associated firewalls, routers, etc. Its costing us a LOT less than this.
People need to understand that the "cloud" should really be pronounced "someone else's computers"
If I understand this correctly, two co-operating processes can communicated over a hardware side-channel. The speed that this happens at is, frankly, irrelevant The fact that it happens is the real worry.
However, if this is on IoS you have to either get the app from the app store, or jail break the iPhone/iPad. If you jailbreak it then you're very much on your own. If its apps from the app store then you are downloading compromised applications. If you have a compromised app then I am not sure whether the CPU bug matters at all, given that you have, however inadvertently, downloaded something nefarious.
On an iMac or MacBook (and I am in the market for a new M1 MacBook, so this does matter!) then the problem is more serious. You can download apps from anywhere.
There is no saving grace (not even, there are so many other points of intrusion that this doesn't matter). Nor that similar problems plague Intel and AMD.
I do recall when I was Application Support Manager for a sizeable telecoms company and found, quite by accident, that the installation engineers had deliberately installed a support line in to the main switch. The switch it self was HUGE, thing mainframe and add extra cabinets. These forward thinkingguys had put this modem in so they could remote dial in to the system and patch any faults. But they hadn't thought of any security. None whatsoever. You dialled in to the number and you had a console, albeit at 9600 baud, directly in to the internals of the switch operating system. From this you could do anything you wanted: Want a new number? Easy. A free-for-life phone line? Simples. Whats more, this went in at such a high level nothing was even logged so we never knew if this was hacked.
Which brings to mind a story of another system. This was to track oil tankers used in commodity trading. The name was "Tanker Information Tracking System".
Which was actually used, until one young female analyst found a new trading route, and promptly announced it with glee, only for someone to yell across the desk, "Then get it on your T*TS".
Management heard, and the name was changed that afternoon!
Can't remember them all? Do what a team I worked with did. Get the secretary to type up all the passwords on to sheet, in a large easy to read font. Then laminate it it and sellotape to a convenient printer in the middle of the team.
When I pointed out that this included several passwords to trading systems and data systems, and that it was easily readable from the lift lobby, which was public access, there was a collective gulp.
Their solution? No, your wrong. Taking it down would be to easy. They had a new blank bit of card put over the list of passwords, hinged at the top, so they could lift it up and read the password out (normally, shouted across the desk in a large open plan office.
Any suggestion of a shared password manager was treated with derision.
... is that the data predates wide spread rollout of relational databases. Its not just a case of restoring the rows to the tables. This is a hierarchical data store which uses record offsets to link to the next record in the set. What this means in practice is that once the erroneous delete happened there are only two ways back:
1) Stop the database and recover from backup. But that would wipe out any active ongoing investigations.
2) Restore the backup to a spare machine, run some scripts to compare the restored backup to production to see whats missing, and then manually re-enter the missing data by hand. The fun part is (re)establishing the links to all the 3rd party agencies that connect to the PNC.
Well, I suppose (2) could be improved by writing a program. But then you would want to test that VERY carefully, sort of like, much more carefully than the original script was tested!
Its not that simple, because of the links to distributed system. Having to restore and roll forward one system is bad enough. I've done it on mainframes and fun is not the word I would use. Add in that this is not a relational system, its ADABAS, and you have a whole new circle of hell to navigate.
Then, its not one database. Its many, with the PNC at the heart. You would have to restore and roll forward all the linked database. Now you REALLY are in the dark and smelly stuff.
Unless you have inside knowledge that you are not sharing, I am calling bullshit.
The database at the core of the PNC is not the complete system. It is linked to a wide number of ancillary databases, such as DNA database, Fingerprint Database, etc. It is quite possible that the PNC was backed up. However, when the purge job goes ahead it will tell each of these other databases to delete the records as well. So they go ahead, in the sure and certain knowledge that the "Are you sure?" question has already been answered by the PNC operator.
Probably about a second after saying "Yes", the PNC operator has that "oh shit" moment we have all had in our past. Normally we would fake some form of error, shit the system down, restore the last backup and roll forward to about a minute before the mistake. Simples.
This is a real problem in any distributed system. Because now you have to get each of those system to restore and roll forward to the same point in time. And this almost never happens because the backups, transaction logs, even the timebase, is not synchronised across all these system. So you get left with dangling references between systems.
Its a problem for distributed systems. Its a real problem when you have distributed systems run by different organisations, on different hardware, OS, databases, and most probably with different backup strategies.
I agree is a monumental cock up. But a backup would probably not have been the simple solution you suggest.
I worked in a computer room in the early 80's when Halon was all the rage. This was a VERY large computer room, the equivalent of several large aircraft hangers, with multiple main frames, tape room, printer rooms, etc. It was fitted with the "state of the art" fire suppression system. There was a control panel that prevented the halon from going off when people were in the room - well it gave you 45 seconds to get the flock out of there when the alarm went off.
The system was to have bulbs of halon in both the ceiling and floor voids. These bulbs had pyrotechnic devices to shatter them when triggered. Translations - a small explosive charge. They were wired in series with a trickle charge to show that the circuit was complete. It all showed up on the control panel outside the doors. What could go wrong?
Well, when the control unit has a hissy fit and fails dangerous, it sets off the charges. Which it did. Without any warning whatsoever. Some, but not all, the globes of halon exploded. Some didn't which from a fire protection point of view was a problem. However, a bigger problem for two of the operators was when they did go off close to a person. One of the main frame controllers was sat at his desk when the globe above him blew. He was thrown out of his chair and broke his arm.
Worse was to come. A lady in the tape room was reaching in to a tape unit (remember those ones with 2400' tapes?) when the globe beneath here exploded. She survived but here dress didn't. She ended up in her underwear!
Everyone had a ringing in their ears from the bangs, made worse by the rather belated sirens going off warning us to get out.
Icon - well obviously!
Biting the hand that feeds IT © 1998–2022