Posts by Paul Cooper 135 posts • joined 7 Mar 2007
My Uncle was one of the head signalmen in the very important box at Newcastle! This would never have happened in his day - mainly because such electronic shenanigans hadn't been invented when he retired. In fact, his tenure was back in the day of signals being operated mechanically, with substantial skill and strength being required to operate a distant signal, connected to the box by potentially miles of rods. But in those days, when we were going to visit him, my Mum could calculate without a shadow of doubt when he'd be on a suitable shift - his shift pattern didn't change for years.
When I worked for a government research organization, doing strictly non-commercial work (it's difficult to do anything commercial in Antarctica!) I found that software companies varied enormously in what they thought non-commercial meant. A lot would say, that yes, you are wholly funded by public money, and are therefore non-commercial. Some would look at the fact that a few of our products were sold, albeit at rates that only covered the cost of printing, not the cost of the work that went into the products, and said we had to pay a commercial rate. In some cases where the software was nice to have rather than must-have, I did try and persuade the latter category to change their mind - without a great deal of success!
I should mention that as a high-profile organization, we had to be squeaky clean in our software licensing.
It won't surprise you to hear that the latter category were mostly house-hold (well, ones that read El Reg) names that wouldn't have missed the money, and the former were usually small companies that could probably have used our money, but chose to recognize our status.
I worked with a lot of prototype electronics in the 1980s; data logging for ice-penetrating radar. In those days, there were only two "standard" ways to connect equipment - RS232 or Centronics. And the vast majority worked with RS232. As others have said, "standard" isn't really a good description; there were so many variants that a breakout box was an essential tool when working with them. It wasn't just the physical connection - software things like baud rate, 7 or 8 data bits, 0 or 1 parity bit, software or hardware handshaking - the list was unending, and was often controlled by the setting of obscure DIL switches or jumpers.
That said, I was working with a bare Z80 single card computer, and once you'd got the hardware sorted out, the software (written in Z80 assembler) could be remarkable simple using an interrupt based system. I think that my code for reading an RS232 line was less than 10 instructions - I forget exactly at this distance of time, but less than ten, and perhaps only 5 or 6. For various reasons, my entire software suite was entirely interrupt-driven - the main program was simply a loop that dumped data from a buffer to an output device, with incoming data using interrupts to load data into the buffer. On one recording device, the only problem was that it was a 4 track device, and when a track was full, there was a lengthy rewind (something like 15-20 seconds), and the length of buffer required would only JUST fit in the available memory - 2 or 4 kbytes of RAM!
"It would not be difficult to make a computer controlled machine that would automatically mill the words of a document into stone slabs"I have no doubt that at least some if not most grave stones are engraved that way nowadays.
WHen I had to have several grave markers made in 2007, the stone masons ceratinly had an automatic engraving machine available. I think it was a little limited in its capabilities, but it was definitely a thing!
Agree entirely about your comments - a train a minute late is a cause for severely raised eyebrows! However, I happened to find out how they manage it when I was staying at a hotel in Interlaken while attending a conference in Thun (the hotel in Interlaken was run by people we knew well). I was commuting daily by train from Thun to Interlaken along lake Thun, and one day we were held up for about 10-15 minutes at one point along the line - long enough that there was an announcement on the train apologizing. But we STILL made it to Interlaken West on time. It turns out that the amazing time-keeping is because there's enough slack in the timetabling to allow them to make up time for almost any conceivable delay. ISTR that some years (probably decades!) ago, the Swiss railways seriously considered taking on British Rail - but backed off when they realized that they couldn't run timetables with that sort of slack in them.
In Ancient Rome, Geese sacred to Juno were kept on the Arx, the ancient acropolis of Rome. This dates back to a time when geese gave warning of invaders after the dogs had failed to do so. There was an annual festival where dogs were sacificed while the Geese were led in triumphal procession.
Given that bit of history, I don't think dogs are going to bother geese one little bit!
You say, the next time your washing machine breaks down.... (usually badly paid or unpaid)... But what did these things replace, they didn't replace badly paid jobs, they replaced repetitive jobs, they replaced jobs which could be done cheaper with machines. There is the key word, cheaper. The current automation trend is to replace repetitive tasks with machines, ones that would be cheaper to run than to pay a human. The only way to then have a job would be if you were paid less than what it would cost to replace you with a machine.
This is very apparent when you visit somewhere like Hong Kong, where the lowest salaries are very low indeed. There is a minimum wage, but it isn't very much. The result is that jobs like cleaning shopping malls are done by an army of people with dustpans and brushes rather than one person mounted on a vacuum/floor-polishing machine. Indeed, on one of my first visits there I accidentally dropped a wrapper or some-such, and naturally bent to pick it up. My wife stopped me, saying that the cleaners would see it as taking away their living!
Where I worked, we had a massive accounting system that had been developed over the years in-house. It did exactly what people wanted, and could be adapted fairly readily to cope with new needs. Unfortunately, it WASN'T Y2K compatible, and couldn't be made Y2K compatible. Therefore, our IT people spent several months identifying, procuring and migrating to a replacement system that was far less flexible, and which required many changes in working practices. As we had communications systems that ran 24/7 over satellite links, we had people manning the systems over the new year, just in case. There were, I believe, contingency plans to maintain communications in the event of something not working. As it happened all was well, but all was well because of an organization-wide drive to ensure that any software or hardware that might be affected was identified well in advance.
It was over-hyped because of hysterical press-reporting about cars failing to start, and many other things that were never an issue - cars having
ECUs etc. were a new thing back then, so the press (who are usually about a century behind) assumed that these new-fangled devices were just as likely to fall over as complex systems that depended on a continuous time measure.
"Possibly, I was thinking more that they may have a polish domain name and use a different prefix for different purposes. E.g. [email protected], [email protected], etc."
They don't.
It's a well-known trend in the design of racing yachts, dating back as far as handicapping rules have existed. You set up handicap rules for a class of yachts, with the aim of ensuring that it is the skill of the crew that wins races, not a cunning design. Immediately, designers start to figure out how they can get a better handicap without damaging the performance too much. The long overhang at bow and stern of some 1920s yachts (which are now regarded as classics) resulted from that - waterline length was penalized in the rules of the time, but length when heeled wasn't. Similarly, at one time there was a rule that sail area behind the rudder wasn't counted in the handicap rules - so you got lots of yawls (which have a second mast behind the rudder).
I worked with a 300MHz ice sounding radar measuring the depth of the ice around DYE 3 in Greenland. DYE 3 was still active at the time, pumping out classified amounts of wattage at megaHerz frequencies. As we were operating so far from their frequencies, we didn't anticipate any problems, especially as we were on the surface of the ice and they were looking for things in the air.
WRONG!
There was so much interference that the high frequency D to A kit we were using could only operate at all if we housed all the equipment in a foil-lined instrument cabin on the back of a sledge. And even then, it triggered at the wrong point (fortunately always the same point) several times during an acquisition cycle. I spent quite a while figuring out post-processing techniques to remove the problem!
We were investigating potential variations in the Gravitational Constant, so we needed good data.
Way back, in 1977 or 1978, the company I worked for brought its computing work in-house after using an IBM bureau service. We bought a spanking new minicomputer (CMC Reality) equipped with a disc drive and a tape deck. We got our data dumped onto a tape (9-track, 1600bpi - state of the art at the time!) and tried to read it in on the new machine. Didn't work - an alignment problem, and of course both IBM and CMC swore blind that their tape deck was correctly aligned. So we were stymied, until I discovered that a VERY light finger pressure on one side of the tape would bring it into alignment and allow the tape to be read. I spent some hours holding my finger in JUST the right position, and the data were safely transferred.
Low tech is sometimes the only solution!
My first programming language (in 1978) was IBM BASIC running on an IBM 360 bureau service, followed by another version of BASIC running on a CMC Reality minicomputer. I remember going to a trade show in about 1979 and looking at an Acorn Atom and wondering what it was good for.
I am married to a chinese lady, and often have to resort to Google translate when participating in WhatsApp conversation with her relatives. The results vary between being a useful guide to what was actually said and something from Monty Python. Google Translate doesn't cope well with Chinese! Fortunately my wife can intervene if I get the wrong end of whatever is being said, and my relatives tolerate my lack of understanding of their language.
I also revise English written by Chinese speaking academics.
Both are very interesting as an illustration of one of the major problems with translation, and that is that the underlying assumptions of a language can be wildly different. My academic clients make regular mistakes that arise from the totally different logical basis of chinese languages (yes, there are several and they aren't mutually comprehensible). For example, Chinese languages don't have time binding, so most of my clients apply the tenses of English without clear understanding of what's going on, with results that vary from strange to incomprehensible! And they mix colloquial English - even slang usages - with excessively formal constructions. ENglish has a clearer distinction between written and spoken language than Chinese does. And do it goes on.
Machine translation is never going to be really effective until it can take into account the different cultural bases of language, and the very different ways language can be put together. Indo-European languages are unlike Chinese languages, and no doubt the same goes for other language groups that I am not familiar with.
There's a basic flaw in IT education, at least in the UK, and that's that it isn't really IT education - it's education in using IT to carry out certain limited tasks.
On another level, it wasn't until I had to work in assembly language that I REALLY understood how computers work; the software I was using (compilers and interpreters) obscured the basics behind what was actually happening. Once I'd got into assembler, I could understand how things like shared common in Fortran could be used in all sorts of interesting ways; before it was black magic.
If I had a fiver for every time a user has said "it doesn't work", and I go through what they claim is the exact same procedure (hah!) and lo and behold it DOES work, I'd be an exceedingly rich person.
Funnily it always seems to be the same people! I suspect thay have an inbuilt "that bit doesn't matter" filter, and omit tiny but important steps in procedures without realizing they're doing it. I also suspect that they can't really take on board that computers have NO ability to think "Nah, they didn't really mean that - I'll put it right for them" - computers just do what they're told to do (at least, ones I have anything to do with do!)
In 1971, I had a pre-University job in the laboratories of the Coal Tar Research Association, now long defunct; the writing was on the wall when I was there, as coal tar is a by-product of the even then defunct coal gas industry. One of my tasks was tending a mercury still in the corner of the laboratory. This basically works by distilling mercury under vacuum. I hate to think how much mercury leaked out of it! I forget what we used mercury for, but distilling dirty mercury to recover it was part of our routine operations. That laboratory wouldn't have lasted five minutes in these H&S conscious days. After all, coal tar itself is pretty evil stuff, full of nasty carcinogenic chemicals. Of course, we handled it in the open laboratory, often heating it over open flames! We used solvents like toluene and trichlorethylene to clean things - both brought in by the 45 gallon drum! Of course, we were handling very hot equipment a lot of the time, so we wore asbestos gloves... And some of the procedures were downright dangerous - I have a scar to this day from an accident where I was lucky not to lose my little finger.
The fly-ash from coal-burning power stations would probably count as low-level waste if it came from a nuclear power station. My own view is that I'd far rather live close to a nuclear power station than a coal-burning power station; the emissions from the latter are MUCH nastier! I recall that many years ago, a TV programme tested various household items for radioactivity, and it turned out that some teabags exceeded the level for low-level waste. And as you say, lots of the UK has a high background radiation level - it isn't just Cornwall, some of the Mesozoic shales also contain a lot of radon.
Back in about 1970, during that after the A-levels doldrum of school existence, I did a little extra-curricular work on atomic physics. The school had some licensed radiation sources, and a Geiger counter, so I did the various experiments in the book. Having exhausted the "official" experiments, I took it into my head to see what the various geological samples that an old boy had bequeathed to the school in the distant past did - I had noticed that one of them was pitchblende, and knew the story of Marie Curie. Turned out that the pitchblende sample was WAY more radioactive than the carefully stored and licensed radioactive sources were! I then spent an interesting day or so making a lead box for the sample!
I was once working on a dataset provided by some Spanish colleagues. It had been created in a totally different system from ours, and I was converting it for use in our systems - theirs was Microstation; ours was ArcGIS for those who know their GIS software! And as anyone familiar with the systems will know, the differences in representation between the two are enormous. Anyway, I'd been working on it for a while when I discovered that one class of features had been duplicated in a manner that meant I was going to have to manually select and delete several hundred features. At this point, I boiled over and yelled "Bloody Spaniards!" Unfortunately, at just this point, our Spanish colleague who was visiting passed by our work area... Fortunately, I think he had a sense of humour and ignored my outburst! We collaborated many times over the years after that and got on quite well, but I learnt that day to keep my mouth shut!
In the late 70s, you pretty much HAD to program on paper; although we did have an interactive terminal (whoo-hoo!),you still had to edit things line-at-a-time, and you could only see a few lines at once. If you wanted an overview of your code, you had to keep a listing next to you, and constantly refer to it - usually making annotations on the paper as you went!
My usual development process then was to sketch a flow-chart, write the code, type it in and then test it - often on a live database as there wasn't any other kind!
I can top that one - in 1987, I was part of a team doing a physics experiment on the Greenland ice cap. We were operating round DYE 3, which at the time was still operating one of the cold war early warning radars. Our job was to measure the topography of the rock beneath the ice using a 300 MHz radar (ice is pretty much transparent at that wavelength). The early warning radar was nowhere near our frequency - but we still suffered from MASSIVE interference effects; in particular, the A-D component we were using triggered at the wrong point several times during an acquisition cycle - fortunately, always at the same point, so I could post-process the data to correct it! And there were innumerable other effects; so much so that we had to line the electronics vehicle with tinfoil to get anything going at all. And the interior of the instrument caboose got incredibly hot - you wouldn't think that getting too hot would be a problem in Greenland, but it was! We operated up to 5 km from the base, and still suffered all sorts of strange interference effects.
The early warning radar did have waveguides the size of heating ducts, and there were parts of the platform that were out of bounds while it was operating; lead underwear wouldn't have saved you!
In the organization I used to work for, the default email address was [email protected] I was one of the very few who got [email protected] because the initial version was already taken. However, there was also an address-munging system that would attempt to match any reasonable attempt at an email to a real person, so the other person and I routinely got each other's email. I did once get one promising me a rather large amount in expenses; sadly it only took me a minute or so to realize the money wasn't for me! There were several A Smiths; I presume they had the same problem, but of course don't know how they coped with it!
I'm a geologist and have to say that calling Mary Anning a scientist is a bit of a stretch. She was a gifted fossil collector who happened to have the good fortune to live next to a good fossil locality where she carried on the family business (her father also collected fossils for sale). I'm not denigrating fossil collection - it is much harder than people think, and requires a good eye; I know this as I'm no good at it! But palaeontology only starts with fossil collection, which is pretty much where Mary Anning stopped. I'd say that she bears about the same relationship to palaeontology as the lab technicians did to Rosalind Franklin. If Mary Anning hadn't been female and hence noteworthy, I doubt we'd know she'd existed.
I've mentioned it before but the IBM Fortran H optimizing compiler had a neat trick. If you wrote a loop with a rand function within the loop, and didn't change the argument of the rand function within the loop, the optimizing compiler carefully optimized the rand function outside the loop! So it became constant within the loop, which wasn't usually what you wanted.... It wasn't a very good rand function, but making it constant tended to produce odd results!
Typically, you get what you pay for.
If you hire the cheapest people available to do the cleaning, you will probably get the least capable, least interested people doing the cleaning. If you choose to pay a bit more, you stand the chance of having reliable interested people doing your cleaning.
Unfortunately, people who merit higher pay are also likely to get bored with a repetitive job that is the same every day and get creative...
I'm afraid that this sort of thing is not uncommon in the wonderful world of academia. Grants often include the purchase of big-ticket equipment, services or whatever, but the smaller, routine items come from a general overhead account or even aren't budgeted at all. Training is the obvious one. I was fortunate and worked for an organization that recognized the necessity of training, but you could find that you'd got the money to buy a vastly costly piece of equipment and then struggle to get it installed! We often found ourselves moving heavy, awkward equipment using members of our (highly skilled) team. Fortunately, H&S abolished that activity, as it was recognized that using untrained and ill-equipped personnel to move heavy equipment wasn't the safest of things!
Back in the days when 1 Gbyte was a LOT of storage, we took delivery of two SCSI 1 Gbyte disk units for our brand new workstations. Plugged them in, and turned on the power to be rewarded with pop, crackle and expensive blue smoke. Turned out they'd been shipped set to 110V, and hadn't got voltage sensing PSUs! Fortunately the supplier acknowledged the mistake...
We had to think about accessibility when considering the sites we developed to display interactive maps, and took advice on it. Under UK law, there's a reasonability clause, so we could develop sites that were unusable for blind people, as long as any FUNCTIONALITY was duplicated in a text readable form. So, for example, if we'd provided directions, they had to be in text form as well as a line on the map. However, as we didn't provide anything of that kind, and as the data that was displayed was downloadable in standard database formats, there was no onus on us to make the basically inaccessible data accessible!
I had a colleague like that. His supreme moment was leaving some expensive equipment out on an ice-floe and finding later that another ice-flow had slid over the top of the first, reducing the equipment to a smear of plastic and metal.
A different colleague managed to jam an irreplaceable drill 6 feet down a hole in the ice - JUST too far for it to be dug out by hand!
Well, there is plenty of Earth-based experience to back it up. Back in the 1980s, UK researchers (mainly at Scott Polar Research Institute) found similar evidence of lakes beneath the Antarctic Ice Cap. Lake Vostok was the big one, but many more lake candidates were identified. Of course, at the time the possibility of actually verifying that they were lake using drilling techniques was science-fiction! But there are plenty of ways of checking that the bright reflections are from a water layer:
1) Is the top surface smooth compared with surrounding areas?
2) Is the dielectric constant estimated from the strength of the echo compatible with water?
3) Is the combination of pressure (derived from the thickness of the ice column) and temperature (derived from knowledge of surface temperature plus estimates of geothermal heat flux) within the liquid part of water's phase diagram?
4) Is there a surface expression of the lake (not found until 1996 by SAR imaging)
Since then at least one of these lakes has been drilled and they are water bodies.
Finally, there's the question of what else could it be? It looks like water, it behaves like water and it's beneath a 2km column of (mostly) water!
I used to do this stuff for a living!
I suppose every organization with a public face attracts its share of strange enquiries. I fielded some of them on behalf of our PR department. The best was someone who wanted to know when an iceberg had calved so he could verify a telepathic message from a penguin... (No, it wasn't Linus!)
My technique was to explain calmly and logically why we couldn't provide the information (length of Antarctic coastline, scale differences between penguins and humans, icebergs calving at all scales from things the size of small countries down to stuff you could use in a drink).
I once worked in a place that was the offsite store for many large organizations. Not just tapes - paper records of all sorts, too, as this was in the late 70s. The data were all VERY high-value things (though there was a serious temptation to walk down one aisle with a big magnet, as it held the records of a well-known sender of junk mail!). The warehouse must have been one of the most inflammable places in the area! It was protected by a MASSIVE halon system; the warehouse was just that - a warehouse with a vast volume, filled with racks full of paper many meters high, so the volume of Halon required was enormous - I recall cylinders taller than me, and many of them. I remember that we were solemnly warned that if the fire alarm went off, we had ten seconds to get out. I was on the call-out list for night-time alarms, and the few times I needed to attend, I was fervently hoping it wasn't a fire - which it never was! The worst was a piece of loose cardboard setting off the motion sensors (which were cutting edge, state-of-the-art intruder detection in those days), and the police insisted on being in first - I certainly didn't argue!
The Register - Independent news and views for the tech community. Part of Situation Publishing
Join our daily or weekly newsletters, subscribe to a specific section or set News alerts
SUBSCRIBE
Biting the hand that feeds IT © 1998–2020
