Posts by Martin Gregorie 1455 publicly visible posts • joined 10 Apr 2007
Don't forget that it wasn't just Fujitsu that deserves a kicking: at worst Fujitsu appears little more than just plain incompetent: its the Post Office that deserves a Rugby boot applied as hard as possible to their flabby arses: after all its the Post Office, not Fujitsu, that committed fraud in its dealings with the Postmasters.
IIRC slide rules were OK in exams for the top level three years of secondary school (this was in NZ, not the UK, and was before electronic calculators were available: I'd graduated and was programming ICL 1900s before I first saw a portable electronic calculator), but my best subject was Chemistry, which I later majored in for my MSc.
Consequently, my unofficial exam help was to memorise the Periodic Table, and to write it on the blank sheet of blotting paper that was on every desk in the exam room, as soon as I sat down. This was a really useful trick because it made quite a lot of the questions a lot faster and easier to answer, and wasn't considered cheating since I'd not carried any written material into the exam room. I never asked around, but I' be very surprised if nobody else did the same. There was no need to remember atomic numbers, etc because these could be easily deduced by scanning across a properly laid out Periodic Table.
Same thought here, though mine has CAT emblazened on it. Its been a good, reliable phone for the several years I've had it.
The worst I can say about it is that its built-in camera's viewfinder image is too small and dark to be much use, but then I never need to use it as a camera because I also have a Panasonic DMC-TZ70 camera, 9 years old and still working as well as when it was new.
... and always remember that the R101 airship (the one that was going to fly to India but only barely made it across the Channel before crashing in France) was built on public sector wages with Civil Service management.
Meanwhile its twin (R100) was built by a private company Vickers), made a very successful transatlantic flight to Canada and back before being scrapped soon after the R101 disaster, and at least partly because its success embarrassed those who'd mismanaged R101 so badly.
If you want to know more, read "His Majesty's Airship" to get the dirt on R101 and Neville Shute's "Sliderule" to see how a successful airship should be designed and built.
Possible hazards:
- there are generally a lot of birds around Indian cities, and fairly big ones too: think Indian Vultures, and Brown Kites which I'd guesstimate at about half the size and weight of Indian Vultures: very similar to the Red Kites that are now fairly common in the UK.
- however, Indian Vultures largely disappeared during the early '80s due to the introduction of a bovine medicine or ointment that was poisonous to vultures, so by 2010 or so vultures were pretty rare in Indian skies and brown kites became the common replacement in the scavenger food train.
- In any case, although ingesting a fully grown Indian Vulture would be about as lethal to a modern passenger jet engine (think of the jet that landed in the Hudson after meeting the flock of Canadian Geese), Brown Kites are a lot smaller and could quite possibly go through a large, modern jet engine without wrecking it.
- However, Brown Kites are quite chummy, and often fly round in gaggles. If there was a gaggle on the climb-out path it should have shown up in at least one of the videos of the crash, but there's no sign of that in any of the videos I've seen.
- Given that the flight path looks very stable and under control, except that it descends after a normal-looking, if relatively flat, takeoff and initial climb, my guess is that the problem is connected with the engines (and possibly fuel contamination) rather than with the rest of the aircraft or the aircrew.
I've driven extensively in India and still remember the low and variable quality of Indian petrol (easily the worst to be found East of the English Channel in 1977/78) as well as other industrial contamination disasters (Bhopal), so I won't be surprised if the crash turns out to fuel related.
"The ONE good thing that could come out of slashing NASA is nuking SLS and its rancid bacon ilk of acronyms and Greek mythology. These aren't small savings on a yearly basis. And they really add up when the zombies have been shuffling along to little purpose as long as this lot."
Couldn't agree more.
Seems to me that there is still a need for a Shuttle replacement, sized somewhere between the original Shuttle and the Boeing X-37 and redesigned as needed to improve its performance while making it fully reusable and human-rated.
* fully reusable should, done properly, should make it nearly as reusable as SpaceX/s smaller rockets and nearly as cheap to operate too.
* this would also make the current fleet of non-reusable spacecraft needed to maintain manned Low Earth Orbit satellites obsolete.
* their existence would most likely help drive the development of future Low Earth Orbit satellites as well as simplifying the design of Lunar and Mars transport vehicles.
In my experience, the best way to get a correct description of what a new software system must do and how its interfaces (to both people and other computer systems) must be structured is to start by collecting a group of people who understand what the new system must do: those who will be using it as well as those who will be designing and implementing, it in front of a *large* wall-mounted white board and enough felt-tipped pens. The first task is to ensure that everybody understands the notation that will be used to diagram the new system. That done, its best to nominate one of the designers as 'sketcher in chief', to keep the whiteboard from becoming a scribbled mess, and then everybody contributes to making sure that the whiteboard becomes a complete description of the data that the system needs to handle and its internal relationships. This stage of the design is complete when everybody agrees that all necessary data entities and their relationships have been correctly captured on the board.
At this stage, and not before, it is appropriate to specify the system's human interface(s) and the way people will interact with them. I've found James Martin's "Design of Man-Computer Dialogues" to be very useful here. It may be old but it is still well worth keeping as a reference because it describes a large number of ways to represent data and, equally important, the advantages and disadvantages of each.
This is the way we specified, designed and built Orpheus, the BBC's Radio 3 Music Planning system, which manages probably the most complex database I've ever worked with, because it contains catalogues of all the performers, composers, and separately playable pieces of music that Radio 3 has broadcast since 1982, as well as the complete broadcast history of every musical piece played on Radio 3 since Orpheus went live.
Other projects I've been involved in since then have used similar approaches and by and large have been similarly successful: others, which used other design principals, have been less so.
I once spent a month or two at SWIFT (great office, set in a small park containing a lake and a deer herd and with easily the best canteen and coffee of anywhere I've worked). However, as it's on the outskirts of Brussels all the keyboards were AZERTY. This was not the problem I'd expected: just somewhat annoying for about the first week then I got used to it.
Is this due to a lack of people who understand the software development process as a whole and can make good decisions about managing it?
While its true that almost any form of incompetence can be found in application development workplaces worldwide, some places are noticeably worse than others,
For instance, while HORIZON is probably very near the bottom of the worldwide application development competence table, I've had contracts in a bank or two that weren't much better, and UK Government Departmental Management is only just just above these examples, In my experience of UK Government the EOs and HEOs in these departments have been pretty competent but anybody above that level, i.e. in management, could safely be sacked without anybody ever missing them.
(I don't think it was supposed to be the whole of it but when it proved possible to crash it it really was)
That was typical for a 1904 running George 3, which was the set-up for the 1904s I was sysadmin on.
George 3 and any jobs it was running all had separate address spaces, each containing its own set of accumulators, address pointer, entry points, etc. and any job could have additional subordinate address space(s) containing the G3 scripts and/or binary programs it controlled.
There was another process that managed task switching, creating/destroying jobspaces, etc but this was essentially invisible to both users and operator unless George 3 was being started, stopped or reporting a system crash.
That sounds about right if you're unable to control the size and content of the "preload" list. If the preload list's size and content is predefined by M$ or automatically extended by automatically adding programs as the user loads them for the first time, then I predict it will be soon removed unless it has a built-in ability to edit the content of the preload list and/or to kill the preload process.
Don't forget that IBM's founders were salesmen and that this path to high office in the company has never changed: if or when you're trying to work out what IBM will do next, remember this and you're unlikely to be far wrong; their engineers, technical people, etc are very unlikely to be found in senior managerial roles.
Indeed. From the material I've seen about Horizon, it appears that:
The Post Office never issued even a Provisional System Requirement for Horizon, let alone a definitive System Requirements document.
In fact the material I've seen seems to indicate that the only system requirement definition was a single Post Office Sales Terminal implementation that was shown to Royal Mail executives at the beginning of the project. This was apparently never documented or used to generate system documentation for the central financial and stock control databases.
Similarly, no Acceptance Test scripts seem to have been written or used before Horizon was released for live operation.
In short, its difficult to see how anybody could have expected Horizon to have been bug-free, since almost every one of the generally accepted rules of computer systems design, documentation, implementation and testing seems to have been ignored.
Well said.
Just go and work and/or live in the USA for a few months and you'll see that the post I'm replying to is substantially true. I went to New York and worked there for a year in the mid '70s: the original post applied then and has mostly seemed to apply each time I've I've been there since. Deviations from the above norm have been:
* Beer sold in NYC in the mid '70s was uniformly flavourless and weak except for that in Guiness pubs, but they were out of bounds to anybody with a British accent because they were full of rabid IRA members. The west coast and Denver beer used to be almost as dire until the '90s when decent beer started to appear on the West Coast up in Washington State.
* Back in the '70s and 80's meat in general and steak in particular was excellent pretty much everywhere in the USA, and then some prick invented feed-lot raising for beef cattle and so the last few times I've been over there the only decent steak dinners have been at Outback joints and even there I've had their waitresses look surprised and comment about the cost when I ordered a traditional US steak dinner.
* I've yet to drive a rental car in the USA that was built there and that I enjoyed driving: a Ford LTD I had in the '70s had an unexpectedly manky interior. Correction I've driven one good rental there, a red Mustang, in which I enjoyed cruising route 405 in LAX with the radio playing 'Born in the USA', but I only got that because the only other car they had available wouldn't start. IIRC every other rental car I've had there was made in Japan or Taiwan.
At last: a plausible reason for the Moon to disintegrate in Neal Stephenson's "Seveneves" SF novel. I like the book but have always thought its weak point was that it begins with the moon just breaking up for never stated reasons in the first paragraph of page one, part one. Fortunately that's about its only obvious weak point.
Highest point: Word 8.2 - because it's screen layout and use of command keys beat the crap out of contemporary Word perfect versions with their three shifts needed for control keys and frequent need to drop into macro display mode to edit formatted documents.
Lowest point: Windows 8 and SQL Server are pretty much in a dead heat here.
From the Wright brothers on the prime rule of aerospace design has been "Simplicate and add lightness", but if you're interested in finding out just how good the Wright brothers' development methods were, I'd recommend getting hold of a copy of Harry Combs book "Kill Devil Hill". Its the only book about them to be written by a man who has himself designed, developed, manufactured and flown aircraft.
Quite apart from being a good author, Harry Combs knew what he was talking about: he was founder of Combs Aviation and president of Gates Learjet Corporation. He was also a pioneering soaring pilot who "lived and breathed the Golden and Jet Ages of aviation." and was inducted into the National Aviation Hall of Fame in 1996. He was also pioneering soaring pilot who "lived and breathed the Golden and Jet Ages of aviation". He was also inducted into the US National Aviation Hall of Fame.
Back when I was the George 3 'guru' in the Wellington ICL Service Bureau, I'd barely sat down one Monday AM before a a Sales droid rocked up and told me that, since our chief client instructor was off sick and I was the only bod in the office who knew George 3 well enough to run a course on it, I was the weeks course instructor with immediate effect.
Explaining that I wasn't a qualified ICL instructor didn't get me off the hook, but did at least get me the morning to read the sick instructor's notes. That, and the G3 manual and previous Undergraduate experience from giving a seminar on graphite intercalation compounds (my MSc topic, which had required experience with X-Ray crystal analysis, Mossbauer spectroscopy, and [of course] wet chemistry proved to be just enough background to get me through giving the week's George 3 course. Of course, it also helped that I knew one or two of the people on the course and that they knew that I was a last-minute replacement for the regular guy. Of course it also helped that by then I'd been the Service Bureau's George 3 guru for almost a year.
I've used (mercifully only briefly) a few IBM mainframes as well as the AS/400 - hated the mainframes and rather liked the AS/400, if only because the way its screens worked was surprisingly simliar to ICL's 2900 systems (I'd virtually grown up with George 3 on 1900's and then in the late '70s designed built a couple of computer systems for the BBC (COBOL with the IDMSX database) on their 2900s.
There were remarkable similarities between the AS/400 command language and VME/B (the ICL 2900's command language), such as both having a long form and a short form for all system commands and both supporting a full-screen prompt for both system and user-defined commands. The main differences were that VME/B long-form commands were much more readable than AS/400 equivalents and that the AS/400s I used only supported RPG and PL/1 (I don't like either) while at least I had COBOL and the IDMS database (itself written in COBOL) on the 2960.
You've obviously never used an ICL 1900 lineprinter: these could print at 160 characters per line at up to 1300 lines per minute. The mechanism was based round a hollow drum the full width of the paper with 160 rings of characters, each containing the complete character set. These were organised so that each embossed row had the same character in every position. The embossed drum was installed behind a row of 160 hammers and a inky ribbon the full width of the paper: both paper and ribbon scrolled vertically, though not at the same speed. The print hammers were driven off a very latge capacitor in the printer's body.
The printer was loud enough when printing invoices, etc, but George 3's print driver could easily outdo it. It separated documents by outputting, IIRC, a page throw, a job title, 10 full width lines of 160 asterisks and another page throw: when this happened the printer almost jumped off the floor and made a noise similar to a short burst from a machine gun.
These ICL printers were much louder than any IBM lineprinter I've ever heard running. That's because IBM used train printers: the character set formed a rotating chain running across the paper path and were designed so that only one character could hit the paper at a time.
FWIW my Logitech M105 mouse tracks movement perfectly up to an above-desk altitude of about 1.5mm. However, it freezes if I try to use it any higher.
However, this is a fairly useless discovery since its quite difficult to use the mouse at this height unless some of the fingertips of the mouse-holding hand are touching the desk to keep the mouse at a relatively constant altitude.
Written off as a curious but ultimately useless experiment of the "Is it lunchtime yet?" variety.
..but my first programing experience was with Algol 60 of Wellington Universitiy's Elliott 503, back in 1968 before I joined the ICL Service bureau in Wellington.
In 1967 I was supporting George 3 on the British Steel Lab's 1904 in Battersea when we installed the RSRE Algol68R compiler, so of course I had to learn enough of the language to check the compiler out out. I soon found out that I liked A68R a lot and found it was very little harder to write than Algol60.
Soon after that we discovered that the George 3 Job Accounting program was getting crashed by some of the jobs the Lab was running: because these job logs were so long that they caused the G3 job accounting system program to overflow RAM, at which point its execution pointer would wrap to zero before overwriting the accounting job's accumulators, address pointer,etc and crashing the accounting job, which was, like most 1900 G3 support utilities, written in PLAN. My solution was to rewrite the job accounting program in Algol68, which resulting in a fairly small and rather quick program which solved could handle the longest job logs at that time.
Shortly after that the contract ended and I hopped in my series 2 Landrover station wagon, together with my GF, her daughter, and an Australian nurse and headed for Kathmandhu in Nepal (via the Hippy Trail and Kanyakumari - the southernmost point in India, Calcutta and Darjeeling and then back after some Himalayan trekking and the HippyTrail again. This got us back to the UK after 10 months and an estimated 40,000 miles of travelling. The return trip happened soon after the first Afghan revolution and almost exactly 12 months before the Shah got tossed out of Iran (and his secret police switched allegance to the Ayatollah).
Once back in London, I revisited friends in the Battersea Lab to discover that there had been a bug in the Algol68 accounting program. This was never fixed because my G3 replacement guru couldn't or wouldn't learn Algol68R and had also accidentally(?) erased my A68 program's source!.
As well as building wooden houses in forests and then wondering why their houses are destroyed when the forest burns, kindly add in the stupidity of quite a lot of suburban Californians. IIRC about 30+ years ago there was a spate of grass fires in southern LA due to a city-wide water shortage during which the city authorities attempted to preserve drinking/cooking/washing water by making it an offence to fill swimming pools or to water gardens and lawns. The result, after a week or three, was a steep increase in house fires.
Why? Simple: many house-owners couldn't bear the sight of bare earth where grass and flowers had previously grown in their gardens and were fixing that problem by buying paint and painting their lawns a nice green before using more green paint as well as other bright colours on former flower beds. Unfortunately the cheap paints these idiots all used were oil-based, and had to be used in large amounts before enough remained on the surface to show pretty colours and turn a dry, dead lawn into a nice green one.
Consequence? Since these paints were oil-based, they all burnt super well, just like the wooden house they surrounded. Fire departments soon learnt that painted gardens were much harder to extinguish than ones that were merely dry, and the painted gardens also burnt rather well when helped along by dropped cigarettes. In addition, fire turned out spread rather easily between adjacent gardens and sometimes got ignited by lightening too.
Spot on.
First I learnt to program in Algol 60, which was OK because that was a well-organised language and, within its expected use (writing programs to solve scientific and mathematical problems) it was easy to use. I also tried to self teach myself how to program the machine (an Eliott 503 scientific system) but failed miserably.
Post Uni, I joined ICL and was immediately taught to write ICL 1900 assembler (to say nothing of the joys of punching the program I'd just written using a 12 key card punch and using same punch to correct the program after the compiler had reported my errors: to be repeated until it clean compiled and the process of finding and fixing run-time errors could be added to the cycle.
The above basic training was what made me first a programmer and eventually a developer and then a systems analyst, to say nothing of providing a solid basis for writing and testing code in a variety of languages (COBOL, PL/1, Pascal, Java, SQL,...).
Seems like only yesterday I was wondering whether AI bit-barn building would need to be restricted due to national electric grid and generation capacity (or lack of same), and now suddenly the current generation of GPU based AI servers are about to be scrapped as power-hungry junk,
Result!
It would be most interesting to know who designed and implemented the Horizon system, if only because, in my experience, the ICL Dataskill project managers and implementation bods were pretty much top notch: FWIW I was one of the 80 contractors involved in the rescuing the Naval Dockyard Project back in 1975: That was 10 years late and around 10 million over budget when ICL Dataskill replaced the useless civil service management and we contractors replaced the poorly trained civil service programmers. Collectively, we had that project up, tested, and running in 18 months.
Consequently, I've always wondered exactly who was responsible for Horizon: I'd be completely gobsmacked to find that anybody from Dataskil had a hand in it!
The ICL 2903 was built using 2900 hardware: it was actually a 2900 DFC (disk file controller) hardware emulating a 1900 CPU. This ran one of the George 1 OS variants that managed the operator's console, an integrated printer, card reader and a disk drive spindle carrying one 5MB fixed disk platter and one removable 5MB disk platter. In addition it could support green-screen user terminals and at least one standard 1900 EDS 60 disk drive - not too dusty for a machine the size of a managing director's desk and running in a standard office environment.
I don't remember the 2903 throwing any wobblers during the 12 months my team was using it, but the EDS 60 drive was another issue: it was fine during the NYC summer when the aircon was on, but it was most unhappy during the winter because, like many NYC offices, there was no cooling available for it during the winter when the office heating was on.
The 2903 ran all the standard 1900 software we needed for the project including COBOL and PLAN compilers and utility programs.
Thanks for your link to "https://www.theregister.com/2023/12/30/solar_radiation_management/": thats a most interesting read.
The solution proposed in "Termination Shock" is essentially SAI, implemented by injecting finely divided elemental sulphur into the stratosphere by using a very large automatic gun. The finely divided elemental sulphur is claimed to be stable in the upper atmosphere, though no supporting evidence is given, probably because the book is an SF novel rather then a scientific paper.
Well said!
I've just been reading Neal Stephenson's "Termination Shock" - a well-written piece of SF and an enjoyable read, but I'm left wondering about his anti-global warming device, which deploys sulphur dust as a high altitude sun-screen - an idea I've never previously seen discussed. So, does anybody know if its a possible approach or just BS?
That was normal for system building in the office, which tended to be the norm for new projects. If we were working away from our usual office, the personal structure depended on how many were on-site for that project and whether there was a local office there. For instance, I once spent six months in HK, back in 1990 before the Chinese took over, documenting a client's systems/databases and reporting to a local project manager. We had several projects running there and so projects were managed much the same as London-based projects.
Conversely, several of us were supporting financial networks in Abu Dhabi but were only out there as required, typically for just 3-4 weeks at a time and reporting to our usual managers in London - we only needed a single permanent guy in Abu Dhabi to act as our rep and contact man.
...which were (in chronological order) an ICL service bureau, the BBC and Logica, all had a management bias against employee performance monitoring.
Sure, if you couldn't handle the tasks you got assigned you would be let go, but this didn't involve any performance monitoring that I was aware of: just the usual annual review. However, Logica had an unusual management requirement: project and business managers and/or their deputies were always in the pub on Friday evenings to buy beer and listen to suggestions and gripes.
I haven't read 'Cold Comfort Farm' for so long that I can't recall anything about it. So I probably didn't like it.
I've never liked Lovecraft either: I've just never liked anything in the ghosties and goulies wu-wu category, just as I've never much liked Asimov and now won't read much of his stuff apart from "The Gods Themselves" and some of the stand-alones like "Pebble In The Sky" or "The Stars Like Dust": def. not the "Foundation" series or for that matter most of Iain M Banks SF novels, which I thought got very repetitive after the half dozen and Feersumm Endjinn.
My tastes have changed: these days I prefer the likes of Poul Anderson, Harry Harrison, Neal Stephenson, David Brin, Ken Macleod, Sturgeon, Zelazny and Fred Hoyle.
Not so minor quibble: get your authors nationalities right in future.
Its quite easy: just look up the author in Wikipedia or any good encylopaedia.
"Brave New World" WAS NOT American science science fiction. As any fule kno it was written by British author Aldous Huxley in 1931 and published in 1932.
Its nearest rival in the dystopian novel stakes, George Orwell's "Nineteen Eighty-Four", who was also a British author, was published in 1949.
BTW neither Huxley nor Orwell considered themselves to be SF authors.
Seems to me that it would be a good idea for Starmer & Brains Trust to add a section to their "AI everywhere" manifesto that requires a considerable AI energy saving: i.e. to develop and use much more power-efficient reasoning devices rather than simply grabbing a sackful of the cheapest chips they can lay their hands on and throwing them into the cabinet. Something like a mandatory limit for all future AI kit of no more than 20-50% of the power consumption of any AI kit available in Feb 2025 would seem like a reasonable starting point.
As an ex-Free Flight model flier and glider pilot since 2000, I'm in favour of geo-fencing restrictions on drones. However, I might have been lucky because I've never seen drones or RC models near our club airfield, though I wouldn't object if drones and RC models were encouraged to carry FLARM-compatible beacons. Fortunately, the only common hazards around our field are small hawks (which never seem to keep a lookout when thermalling) and flocks of thermalling seagulls.
However, once when thermalling near our airfield, I was joined by a full-grown sea eagle, despite being over 50 miles from the nearest coastline. It was no problem: joined me at about 2500 ft, positioned itself on the far side of the thermal from me and left at 4000 ft. A really impressive sight: shame I didn't have a camera with me.
I know that John Deere kit is fairly widely used outside the USA, but now I'm wondering whether the same limitations on spares, diagnostic tools and The Right To Repair also apply in other countries.
So, does anybody know what the situation for Jon Deere spares and repairs is in, say, Australia, Canada, NZ, the UK or the EU ?
The radar transparency of a wooden satelite should be easy enough to fix: just cover its exterior with a suitable reflective material: very thin aluminium foil, a coat of bright white paint, or a coat of thin epoxy, cellulose lacquer or clear varnish containing aluminium powder should work equally well, though the white paint or aluminium powder paint would be easier to apply than the foil sheet would be.
Using any of these structures should result in satellites that are light, cheap, durable when in space and more or less guaranteed to fully disintegrate when re-entering the atmosphere.
The Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2025
