Posts by Martin Gregorie 1315 publicly visible posts • joined 10 Apr 2007
However, the FAA proposes that operators should be allowed up to 25 years in which the upper stage is removed from orbit using the uncontrolled or natural decay method.
Dunno about the rest of you lot, but to me this sounds a bit too much like: "Should be long enough for everybody to forget who put it up there in the first place, so fill your boots, boys".
Any system that can't recognise and reject duff data WITH A CLEAR DESCRIPTION OF THE ERROR is poorly designed and should never have passed acceptance testing.
Any system that crashes or fails over to a parallel backup process just because it receives data containing errors was
(a) designed by somebody who does not deserve the title of 'system designer'
(b) should never have passed its design review before coding started.
It seems to me that NATS handling of mistakes in flight plans is just plain wrong. Given that a flight plan seems to be a self-contained item that must not clash with any previously submitted flight plan, it follows that mistakes in flight plans should never be treated as system errors but rather, that NATS should reject that flight plan for correction and re-submission by its originator.
In a critical system like this, errors in flight plans should never cause standby or duplicate processes to crash.
What should happen is that, if the flight plan validation process finds an error, the plan being validated is rejected and an error report returned to the originator so the plan can be corrected and re-submitted by its originators. If the flight plan was automatically generated by the originator's software, then its up to them to manually correct and re-submit rejected flight plans while their support team fixes the error(s) in their software and/or database.
When I started work (1968 in an ICL service bureau, when all men wore shirts and ties in the office), it was easy to spot the longer-service engineers: those were the ones wearing bow ties.
The older engineers wore bow ties from habit because wearing the usual style of office tie (those optionally secured with a tie-pin) was inviting an accident if your job was maintaining card-punch data processing equipment such as sorters and tabulators: it was all too easy to get the end of your tie caught in a running sorter or tabulator and then woe betide you if the STOP switch wasn't within reach.
Where I live we've had water meters for long enough for my original one to have worn out and been replaced. That was over a year ago.
The meters have always had a wireless connection (frequency band not known or displayed on the meter), which is good because the meter is in a cupboard in the kitchen, so the radio llnk means no meter readers tromping mud through the house on a wet day or me having to be home for their visit.
However, the other week I did have a visit from a water company rep to audit leaking taps, leaking taps and cistern's etc. I thought this was quite a good idea since it was free and that that he might spot any problems I'd missed. In the event the rep carried ID, was friendly and didn't spot any problems.
Apart from the radio version of the Hitch Hiker';s Guide to the Galaxy, by far the best version was the live-on-stage version in the Rainbow Theater: you knew the Vogons were bad because they jumped off the stage and beat up the audience. Too bad, though, that the interval bar no longer sold Pan-galactic Gargleblasters by the time I got to see the show.
Whether you can legally copy and compile *ANY* source code depends solely on the license that the author(s) applied to it.
If no licensing details are included in the source code, then you can do what you like.
If the code was in a book , e.g. "Software Tools in Pascal" (Kernighan & Plauger) or Sedgewick's "Algorithms", the publisher's copyright notice controls what you can do with the physical book and its content's representation on the page.
In both these books the copyright notice says explicitly that than you can't reproduce any part of the book. However, as all the example code in both books is written in Pascal, I, and doubtless almost all other software authors, have always assumed that translating the Pascal example code into another language, i.e. C, Java, COBOL or even assembler counts as 'fair use'. In both books the 'Preface' text also makes it clear that the authors expect the example code to be copied, possibly translated into a different language, and incorporated into other programs and then compiled and used within other personal or commercial programs. To me this means that the publisher's copyright notice is meant to apply just to the physical book and the text it contains as represented on its pages.
Each and every company can be held liable for the quality of their work. There is no way to totally absolve themselves based on T+C.
While this is absolutely true, in the absence of something like a relevant ISO financial systems standard, there IS a de facto standard for judging any financial software system: that is the System Specification which the delivered system MUST conform to in both performance and function, and which both the client and the developers must agree and should have signed off on before development starts.
Once the System Spec has been agreed and signed off the developers are contractually bound to produce a high quality system that conforms exactly to the spec, it is also the case that the client should assemble an acceptance test team who will produce an acceptance test suite that will allow them to verify that the delivered system corresponds exactly to the System Spec and contains no defects or anomalies.
I've listened to the Radio 4 programs about the Horizon disaster and have just read Private Eye's account, but nowhere has there been any reference to a signed off System Spec or to any Acceptance Testing process or team. Why? If it was because no Acceptance testing was ever done, that's just inexcusable and shows that both Fujitsu and PO management were, and maybe still are, unbelievably incompetent right up to Board and Ministerial level.
Kim Stanley Robinson, who seems to usually get his science right, hangs a plot point in his Red/Green/Blue Mars trilogy on a claim that a living human becomes inflammable once the atmospheric oxygen content is around 40-45%.
If that's right, and I'm feeling too lazy to check it ATM, then making GREEN hydrogen by electrolysing water and releasing any unwanted oxygen into the atmosphere would become a serious problem if that should double the atmospheric O2 content.
That depends; hydrogen comes in three 'colours': GREEN, BLUE and GREY
GREEN: made by using only renewable energy to run electrolysis cells, so the only 'waste' product is oxygen, which can be used for medical or industrial purposes.
BLUE: made by reforming methane and/or coal with the carbon and other waste products captured and stored permanently so that they can never re-enter the biosphere. Think waste repositories as secure and long lasting as you would need for radioactive waste management. Putting the waste products back into exhausted oil wells and coal mines isn't nearly good enough: they need to be as securely buried as they were before we came along and dug up the raw materials that the BLUE hydrogen was extracted from.
GREY: Any process that generates hydrogen and emits the resulting waste products into the earth's biosphere: in other words, Business As Usual until the present.
Some hair-splitters subdivide BLUE into TURQUOISE (methane pyrolysis with solid carbon as the waste product), PINK (think GREEN but with nuclear power driving the electrolysis cells rather than solar or wind energy), while others reserve YELLOW for solar powered electrolysis.
Currently 95% of all commercially available hydrogen is GREY. Numbers for splitting the remaining 5% of hydrogen production between BLUE and GREEN production methods don't seem to be easily available.
NO.
The American Heritage® Dictionary of the English Language, 5th Edition. says
adjective
- Conspicuously bad or offensive. synonym: flagrant.
- Surpassing; extraordinary; distinguished (in a bad sense); -- formerly used with words importing a good quality, but now joined with words having a bad sense.
- Exceptional, conspicuous, outstanding, most usually in a negative fashion.
Well said.
I was around and working on financial networks and interestingly complex databases in the mid-80s, when "Expert Systems" appeared in the Hype-sphere, were promoted as The Answer to rapidly creating any and all interactive applications, but were soon gone and forgotten. IIRC even the 4GL systems (DBase, Sculptor, etc) that emerged in the late '70s, and were more commonly used on Personal computers than on minicomputers and mainframes, outlasted them.
Fair comment: I grew up hearing about the square windows, when the reality was that the crack propagated from a bolt hole, helped on its way by the alloy skin sheeting not being thick enough to prevent it tearing.
If you want some lighter reading after all this doom & destruction, try reading "No Highway" by Neville Shute, a novel about airliner crashes caused by metal fatigue and, intriguingly, published about a year before the Comet airliner's first flight, and still a pretty good read.
If you like that, yo mat also like 'Slide-rule', which covers Nevile Shute's life from pre WW1 to 1938, when he emigrated to Australia and became a full-time author. Beterrn1920 to 1938 he worked for De Havilland, Vickers and Airspeed as both engineer and manager, and was involved with both aircraft and airships.
That's not really relevant. The Comet fuselage was an alloy structure that failed from metal fatigue at a stress concentration caused by using sharp corners for windows in the pressurised cabin.
Carbon composites don't fail that way: they tend to fail by being overstressed and/or by impact cracking rather than by fatigue cracks.
Is that at least some of us like to keep our backups in a known state. This is easy to do if you run a backup followed immediately by a system update: in my case this means running rsync followed immediately by dnf (I'm running Fedora) and a system restart to make sure that new libraries etc. are now in use. Handling backups this way ensures that, after a disaster such as a disk failure, you *KNOW* that simply restoring the most recent backup will leave you with a runable system in a known state. This is a problem regardless of whether the backup+upgrade sequence is manually sequenced or run by a script.
The problem with flatpak and friends is that there's apparently no way to avoid getting force-fed a an update at a time chosen by the developer. Murphy pretty much guarantees that at some point an application push upgrade WILL coincide with a backup run and that this will result in a backup that, if restored, will contain incompatible software modules and/or configuration files.
AFAIK there is currently no mechanism provided that can prevent developer-originated push backups from running when the recipient system is taking a backup. I've certainly not seen any mention of such a backup integrity protection feature, so it seems unlikely to have been provided.
Another cause of problems would seem to be the case where the push update replaces application configuration files that have been modified to suit local requirements, e.g. sshd security settings. At least dnf, apt etc tell you when this happens and you can edit the revised configuration as required before rebooting the system: do flatpak etc even tell you that a new set of configuration files has replaced your customised ones?
Hong Kong police used to be considered very similar to Western cops. What had caused them to switch sides to totalitarian mode so fast, I wonder?
I imagine that the threat of cancellation of one's police pay check would have that effect. In some parts of the world the detective branch also keeps its beady little eyes on the uniformed police branches.
The most productive projects I've been on were either before e-mail was a 'thing' or when it was unnecessary because related subsets of team members had clustered their desks, making both e-mail and/or phone calls unnecessary because two or three of the group could just talk quietly without disturbing people in the rest of the office.
The only exception I can remember was one case when a small group of us were in the code & test phase of the project: our desks were clustered, but we used e-mail between ourselves because this way messages could be attended to between writing blocks of code, debugging sessions, etc. Experience had shown us that in this particular case we got more done if answering questions etc could be deferred until the recipient's current task reached a natural breakpoint: e-mail provided the perfect way of collecting this type of query so they could be answered without breaking anybody's concentration.
Project meetings were kept brief and relatively infrequent too.
...is just how many of the team that specified and designed the new system had hands-on experience of the one it was meant to replace?
And how many members of that team had previously implemented a financial system of similar scope and complexity?
If the answers are 'none' and 'none', then we know who to blame for the failure: those managing it. But, I bet THAT blame never lands where it deserves to.
That's been the case as long as I can remember: the attitude among the Great And Good in the UK always seems to have been "We know what we're doing so we'll ignore what anybody else might know".
Take monetary decimalization:
- The Canadians went decimal first and the results weren't good, but Australia and NZ had observers there and noted the mistakes.
- Australia went next, avoided all the Canadian mistakes, but made a few of their own. NZ had observers there and noted a few new mistakes.
New Zealand went third, and had a largely trouble-free conversion to decimal currency.
UK? Didn't have any observers at any of the previous three monetary decimal conversions, but nonetheless not only repeated all the cock-ups made by the previous three, but invented a truckload more, causing such a mess that any further rationalization has been impossible like, for instance, the largely mishandled and never completed switch to metric weights and measures.
The Martian atmosphere is rather thin: when Aurora was working on a foldable, rocket powered Marsplane, the prototypes were test flown by taking then up to somewhat over 100,000 ft under a balloon and dropping them: the Martian atmosphere near ground level is very similar in pressure, density and temperature to our atmosphere at 100,000 ft. The Aurora tests, launched from Hawaii, were successful: by the time their marsplane and its balloon had reached around 105 Kfeet it was a good 100 miles downwind of the islands. After flying the test schedule the marsplane was down to just under 100 Kfeet and at least one of them was successfully glided back upwind and landed near its launch point in Hawaii.
What's the maximum altitude a DJI Mini has reached? I know that a DJI Mavic 3 drone has been flown from the summit of Mount Everest and successfully climbed another 400m, so to 33238 feet, but even a U-2 can only reach around 78,000 feet and Perlan 2, a high altitude pressurised glider, has reached 76,000 feet (23km) and has a designed maximum altitude of around 90,000 feet.
Both these aircraft have flown at twice the height that DJI Mavic 3 drone reached above Everest.
You'll have noticed that the Mars Heli was both carefully designed to save weight and has a much bigger rotor diameter than anything of similar weight that's usually flown here. The area of its rotor blades is a lot higher too: increasing both its rotor diameter and its blade area would be needed to fly in such a low density atmosphere as we find on Mars.
I expect that any COTS drone would not be able fly on Mars because its weight would be too high for its rotors, which are designed to fly in the part of our atmosphere that people can live in, to lift off the sands of Mars.
...is that, when Stratus fault tolerant systems (also re-badged as IBM System/88) were the new, cool, kit most of the faults were caused by operators showing off its fault tolerance to their chums. They did this by opening the cabinet and pulling out boards while exclaiming "See: its still working!".
Unfortunately, the machine reacted to a removed board by dialing home to report the failure almost immediately, which resulted in an engineer and new board arriving at the site only to find that all was well and that this was an unnecessary call-out. Fortunately,the fix was simple: a 10 minute delay was introduced between fault detection and dialling home: if the fault disappeared, i.e. the operator put the board back within ten minutes, the pending call was not made.
The reliability of the Stratus was excellent: the one I used for a secure networking project shared a small machine room and mains supply with a Tandem fault tolerant system. During our project the Stratus crashed twice: both times because the Tandem power supply failed, blowing the computer room's mains fuse because its failure caused a mains short. This caused the Stratus to switch to its built-in batteries which didn't have the capacity to keep it running for the rest of the weekend, so it did a clean shutdown just before its batteries were fully discharged.
Back then Logica had a few networked units in its HQ offices, where they were being used for secretarial purposes. I only saw them once.
However, I don't remember being particularly surprised because I'd already seen, and been able to have a brief play with, a very similar machine at an internal BBC Future Equipment exhibition: In this case it was an ICL Perq, which was equipped with mouse, keyboard and vertically oriented monochrome white screen, big enough to display an A4 page image at close to actual size and with considerably better resolution than any other display I'd seen at the time. There's more on the Perq here: https://en.wikipedia.org/wiki/PERQ
There was a lot of good stuff in that exhibition, but for me the top items were the Perg and the NRDC Surround Sound system, which beat the pants off any other surround sound system I've heard since: its 'presence' control was amazing: it let to pick your position the concert hall: from being near the musicians: bright sound, little audience noise, changing to a softer sound and surrounded by coughers, foot tappers and shufflers as you moved your point in the sound field toward the rear of the venue. Sadly, the NRDC system got killed off soon after that: a great pity because it was well suited for FM broadcasting.
That's pretty much what happened in the mid-late'60s, during the Vietnamese war, when there was some sort of technology embargo placed on China.
One of my (NZ) universitiy's chemistry lecturers visited China around 1967 because he wanted to see what effect Vietnam + embargo had on Chinese science, and got a roasting from the local press for doing anything as outrageous as actually going to see that sort of thing for himself. He gave a lecture to chemistry graduates on his return, and very interesting it was too: the major effects of the embargo on Chinese science were:
* a determination not to rely on importing anything they could make themselves (this effect still seems to be alive and well)
* more attention was paid to increasing Chinese scientific R&D
* a move to start making as much scientific equipment as possible in China. I remember him saying that most of their older instruments were made in West Germany, but all their new kit was Chinese made and that it seemed to be as good as the current German instruments we were using in NZ.
I've designed and implemented systems using both graph (CODASYL) and relational databases, the latter ranging from Sybase and PostgreSQL through early data warehouses , i.e. an RDBMS optimised for star schemas such as Red Brick as well as the simple indexed file schemes used by 4GLs such as Sculptor.
In my opinion it doesn't matter much which flavor of database you choose, simply because if you dive into writing a system specification without some careful data analysis that is followed by producing a properly validated Data Structure Diagram before you do any detail design work on:
* the database schema
* the user dialogue used to maintain and access the database content
* the software architecture that links them together
the application is unlikely to meet its user's expectations for usability or performance.
In summary: it looks very much as though ChatGPT has no more understanding of its textual input (both the user's request and the heap of example material its been fed) or of the correctness and relevance of its output than the ancient Markov scrambled text generator - its just larger, more complex and consumes more resources when its run.
If you believe that the output from either Markov or ChatGPT is either useful or correct except by chance, then I have this bridge over the East River that I'm sure you'll want to buy...
Back in the late '90s HMG used to let you buy additional tax years that counted toward your state pension when you hit 65 (as state retirement age was then).
This was A Good Thing for those of us who'd worked for a few years elsewhere before joining the UK workforce / done an extended degree / spent time on the Hippy Trail / had a long-term illness / etc.
Is this option still available to the UK tax payer?
I had almost the opposite experience back in the '80s.
We'd just completed development of a financial switch and shipped the hardware and software out to Austria and a pair of us from the development team were on site while the client's acceptance tests were run. This was about a month behind schedule because they'd shipped the, rare at the time, fault tolerant hardware to us to use for development and there had been problems arranging for it to be shipped back to Austria. Since we couldn't disband the development team until acceptance was complete, we'd used the extra time for setting up and running additional system tests while the shippers got their act together.
Anyway, for the first few days everything went perfectly - all the acceptance tests, which had been written by the clients team, passed with flying colors. However, the acceptance team's faces got longer and longer, which we couldn't understand.
Then, on about day 4 they found a minor defect and instantly it was smiles all round: it turned out that the deep gloom was just them thinking that, because they had not found any problems so far, their acceptance tests must be crap.
This week I've seen another Gnome 'improvement' surface: They used Flatpak to push an Evolution update onto my system.
OK, this Evolution version has improved usability and the revised window layout is an improvement, though I could do without the new monochrome grey palette, which looks old fashioned to me. However, my real beef is with their use of Flatpak. This is because I prefer to synchronize software updates and backups *and* to pick when my systems get updated..
My CHOICE is to run a weekly cycle of an rsync backup of the whole online file system onto a portable USB disk immediately before I run a 'dnf' system upgrade (yes, I prefer the XFCE spin of Fedora Linux) on the grounds that, if necessary, I can easily back out a bad update and *know* that the system will be in a known state. Consequently, I object to Gnome's arrogance in unilaterally using Flatpak to push updates onto my systems whenever they feel like it, and I do wonder what sort of mess they'd leave if they did the push while my backup is running. Since they obviously know I use Evolution, they could at least have ASKED if I wanted push updates and their convenience rather than mine.
Its just the next iteration of the standard CLFM* design. There have been a series of these demonstrated over at least the last decade, all following the same general design: a central cabin supported by four knee-height rotors. None of them have had any way to keep people from entering an operating rotor's disc or to prevent the rotors hitting obstructions during landing or takeoff.
* Chinese Lethal Flying Machine
.. The UK CAA publishes NOTAMS on their website from where they can be scanned, printed or copied before you fly.
In addition there's a rather good graphical application, SPINE, that displays NOTAMS on a map. This makes selecting the NOTAMS relevant to your planned flight rather easy to do before you read their description and active times.
In addition you can download them as a file that is loaded into your onboard electronic navigation system. I've been flying with this setup for the last 15 years.
Commercial airliners have a turbine which can be lowered if the engines fail and provide power for control surfaces
Yes, but that's not in any way an aerodynamic effect. All the turbine does is maintain pressure in the hydraulic system so the control surfaces can still be used to maintain control if the engines fail.
The classic real-world example of this is Air Transat flight 326, when a fractured fuel line left it over the Atlantic with empty fuel tanks and consequent failed engines. Lowering the ram air turbine provided electric power for instruments and radio as well as the hydraulic pressure needed to operate the flight controls and lower the undercarriage just before it landed at a military airfield on the Azores.
Among the five "initial" use cases for the new Federated Data Platform and associated services include elective recovery, that is reducing the backlog of vital, but not urgent, operations, which are currently at record highs.
No, just no!
Paying NHS front-line staff the money they've lost over the last 14 years rather than the Government handing it to their chums AND paying medical and nursing students a living wage while they are getting qualified would do a helluva lot more good than handing the money to NHSdata's chums.
I strongly suspect, too, that it would play well with the UK public if the aggregate of the pay rises MP's have received while denying them to NHS staff was clawed back and paid to NHS workers[1] as a bonus.
[1] But excluding management levels in the NHS. I have a rather strong suspicion that the more senior members of the NHS hierarchy and, for that matter, also the top levels of management in HMG's Civil Service, since they may have been swinging the lead too. Consequently, it would be a good idea for them to be required to defend their work record too, and have the appropriate penalties applied if they prove to be deficient. After all, this happens all the time in commercial outfits when management fails (except in certain US airlines, apparently) so it would seem to be high time the Civil Service are brought into line with standard commercial practice.
I've done more or less the same: my task was to design and build a process to populate a data warehouse with data extracted from the logs generated by various makes and models of mobile cellphone switches in a national phone network for later analysis.
It wasn't particularly difficult to do that or to tune the system to run fast enough to translate the logs into a common format and load them into the data warehouse faster than it arrived. It wasn't even particularly hard to make the process scalable.
The interesting bit was the requirement to handle additional log formats as and when new switches writing them were added to the network, and to do it without any code changes being required.
IOW the production system had to incorporate a data dictionary and use it to drive the processes handling the conversion of incoming logs to the common format as well as loading the transformed data into the data warehouse while running fast enough to stay ahead of the deluge of incoming logged data.
Here's another ancient source of design wisdom:
"Design of Man-Computer Dialogues" written James Martin in 1973
IME this is an undeservedly lost gem.
Its analyses of various ways a user can interact with a device and the way these map onto both the dialogue style and, equally important, the type of task the user needs to perform would make a huge usability improvement if the current crop of user interface designers had ever read it - or heard of it, for that matter.
As far as I know, there is no other mainstream computer language than COBOL that can do the equivalent of the following rather, commonly used, numeric formatting:
77 ACCOUNT-BALANCE ZZZ,ZZZ,ZZ9.99DB BLANK WHEN ZERO COMP SYNC.
as a single variable declaration, or, for that matter, in any readable single line of code.
The database designed use by for COBOL programs was IDMS(X), not SQL. Technically it was a CODASYL database, but these days we'd call it an 'edge database'. However, SQL got grafted on later via a defined set of standard procedure calls.
The IDMS/CODASYL approach added two extensions to COBOL:
- one was a data definition preprocessor which translated the database definition into a set of COBOL subroutines which were compiled like any other COBOL subroutines
- the other was a language preprocessor, designed explicitly to act as an extension to COBOL. IIRC it didn't add or require any additional data types but, instead it extended COBOL by defining a set of database manipulation verbs. The preprocessor replaced these by sets of standard COBOL statements and subroutine calls when it was run: the resulting output was 100% standard COBOL and so could be compiled by the standard compiler.
Compiling and then linking the code output by the language preprocessor with that output by the data definition translator produced an executable object that could access and manipulate the database content, but was the result of compiling 100% standard COBOL output by the two preprocessors.
I thought it all worked well: the DB designer needed to understand the DDL syntax, but the additional knowledge needed by programmers was minimal: just half a dozen extra data access and manipulation verbs which they found easy to code for, because these behaved more or less like any other COBOL data i/o verb.
SIDE NOTE: I though it was interesting that DEC's initial relational database offering on the VAX did something similar. It didn't implement SQL, instead it used 'database procedures', which were very similar to SQL procedures, though they were separately compiled and linked procedures rather than interpreted code.
The message I'm getting from this thread is that a major reason for NHS IT systems being unfit for purpose is that apparently THERE ARE NO QUALIFIED MEDICAL STAFF IN THE DESIGN TEAM.
There is no excuse for this: but incompetent project management is an entirely reasonable explanation of why it happens.
One of the most complex (and successful) projects I've been associated with was the BBC's Radio 3 Music Planning system. There are two reasons why it was successful:
1) The initial design team included a newly retired member of the Music Planning Team, a decent project Manager and two IT specialists, of which I was one
2) It was obvious from the outset that the data model would be complex, since it had to deal with musicians and orchestras, composers and their works, broadcast schedules and, last but not least, musicians fees, both for the initial recordings, but also the additional payments made if a concert or parts thereof were re-broadcast.
So, the first thing we did was to teach the ex-planner and the project manger to read data structure diagrams and then we all stood in front of a large whiteboard for around a month until we'd developed a DSD that everybody agreed with and that nobody could find problems in.
We didn't do ANY technical design until this point was reached.
At this point we considered the users, who covered everybody from the music planners, who would use the system all day, every day to the program producers, would use it only every month or two when they were planning a new concert and needed to check that the performers and music they intended to use weren't already scheduled to be broadcast around the target date. This, and the terminals (24x80 green screen block mode devices) determined both the command syntax (7 single character commands, any data shown on screen could be shortened using personal abbreviations, command+abbreviation could be concatenated to run a set of related commands in sequence). We also introduced a permission system: any user could look at anything in the catalogs, or run clash checks on programs, but updating and/or data entry needed appropriate permissions.
Then, last but not least, we used a modular software design and, and delivered subsections, e.g the music and performer catalog creation and search tools the the music planners, ASAP, since maintaining this data was part of their job and concerts couldn't be planned without them. We also showed them how to use the fault logging system and encouraged them to use it as well as to call us if they hit problems. We delivered modules incrementally but in a sequence that allowed to planners to input music and performer detains, and then to enter broadcast details. The consequence of all this was that the way the system worked suited what the music planners needed and we got prompt feedback from them on anything that needed fixing or re-implementation.
The system was originally intended for around 6 - 10 users, but it turned out to be useful for rather more people that its original sponsors expected: last time I heard, it had nearer 40 users.
The main message to take away from this palaver is that, if you're designing an IT system that must support experts in any profession which is outside the development team's personal expertise, then YOU MUST INCLUDE AT LEAST ONE MEMBER OF THAT PROFESSION IN THE DESIGN TEAM for your project to be something that its users will find both easy and (hopefully) enjoyable to use.
Judging from both the last couple of years observations and experience on contracts last century, every last department in HMG's Civil Service uses this as their SOP (standard operating procedure). Their baseline DRP appears to be a combination of doing nothing, hoping nobody notices and blaming everybody else.
I'm certain you're right that embedded industrial applications ARE still running productively on kit that used to boot its firmware off floppies.
That's why hardware devices like Gotek units are still being manufactured and sold. These are hardware devices built to the same form factor and using the same connectors as 5.25" and 3.5" floppy drives and were designed from the outset to be replacements for the original drives. They provide legacy equipment with access to floppy disk images recorded on SD cards and/or USB sticks.
I've not used one myself, but I know that, apart from those keeping older computer-controlled tools in productive use, another gang using them is the 8-bit computer enthusiasts, who are more numerous than you may realize, and who use them, both as replacements as their 3.5 and 5.25 floppy drives die, but also as a hedge against the increasing deterioration of their original floppy disks: the Gotek also provides a convenient way to store and copy disk images when the original floppies and drives have died.
Many thanks for your clear explanation of both the Mole's thermometric innards and of the way that its depth beneath the surface affects its sensitivity to atmospheric temperature variations.
If I've previously seen a similar explanation, I obviously missed its significance or I would (hopefully) have remembered it.
Disclaimer: I have a chemistry degree but never used it because a global oversupply of chemists when I graduated coincided with a shortage of IT designers and programmers, so I ended up sitting behind a coding pad and 12-key card punch rather than a lab bench.
Yes - its website says it only carried three scientific instruments:
- That thermal probe, and it would be nice to see more detail on how the team managed to get any usable thermal conductivity data when its deep probe only penetrated to 40-50 cm rather than its target depth of 5 meters
- a seismometer
- a radio instrument for measuring Martian polar wobble.
However, it also carried a set of fairly standard meterological instruments (temperature, pressure and windspeed) and sensors for measuring the Martian magnetic field. While I accept that these weren't the main sources of anticipated new scientific insights, I'm gobsmacked that the Insight team, or at least its website author, apparently doesn't consider either Martian weather observations or measurements of its magnetic field to be 'science'.
The Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2023
