Posts by Martin Gregorie 1260 posts • joined 10 Apr 2007
Couldn't agree more - the most messed-up small database projects I've been called on the optimize have all been written by people pretending to be DB designers and using Access to build their project.
Most of these gentry wouldn't have recognized a data structure diagram, let alone think of drawing one as the an essential first step in their development process.
IMO the sliding date window is ONLY acceptable for general use if entering a two digit year always means the current year: if you want to input a date in any other year, then enter four digits. This assumes the system is a financial one and is only dealing with precisely known dates that are close to the present, AND that an European/American style calendar is being used.
Outside financial circles the ways a date is represented and its (implied) accuracy can vary widely.
I once worked on a music-related system that dealt with dates that, amongst other things, needed to record the date when a piece of music was written or when a composer was alive. As a result it had to deal with dates ranging from from 55BC to the present and with varying degrees of accuracy ranging from "11th century", i.e. some time in that century, up to and including exactly known future dates, such as the projected date of a concert. Needless to say, in this system every date needed to include a code indicating its accuracy and its required format when it was being entered or displayed.
Take a look at last week's Rocket Report on Ars Technica.
That points out that the Shuttle averaged one scrubbed launch attempt for each successful one over its operational lifetime, with some launches having a many as 5 scrubs before a successful launch.
So, yes, hydrogen is difficult to handle anyway, and more difficult in bulk, but having Congress not only mandate that NASA build the SLS by reusing Shuttle technology, but prohibiting it from switching fuels or using more current technology certainly doesn't help the SLS to be more reliable than the Shuttle or to cost any less.
That's correct - step 11 should say F, not R. Spotted that myself just now (next day), which is embarrassing since I'd checked it twice before hitting 'POST'.
Thank Dog I never had to execute that process as a routine backup procedure - its far too complex to be safe.
I don't recall where we kept the system backup, but it was probably on an EDS 60 diskpack, since we needed one of those to install software updates - IIRC ICL's NYC head office system was a 1903S which only had EDS 60 disk drives.
There's a vital, but missing, bit of information, which is that the machine would seem to have just a single disk drive unit, which consists of two recordable disk volumes on a common drive shaft. Each disk volume can store 5MB of data and has its own, independently addressable set of read/write heads. Only one of the disks is removable.
Lets call the volumes F (fixed) and R (removable), and the pair of removable disks they will be backed up to, B1 and B2.
The backup operation the article describes is the only way you can back up both F and R. This requires the following set of operations:
1) remove R and replace it with B1.
2) copy F to B1. This is the backup copy of F.
3) remove B1 and put it temporarily on a desk.
4) replace R.
5) copy R to F.
6) remove R and replace it with B2.
7) copy F to B2. This is the backup copy of R.
8) remove and store B2 in the data safe.
9) replace B2 with B1 (on the desk).
10) copy B1 to F. F is now the same as it was at step 1
11) remove and store B1 in the data safe. It is the backup copy of R.
I was once familiar with these shenanigans because the ICL 2903 also had one of these fixed and removable, 5MB per volume, drives. The fixed 5MB volume was usually the system disk, with the business programs and data on the removable 5MB volume.
The one I developed a system on also had a separate 60MB removable drive, so we only used the removable 5MB volume for backups, which was good, but this rig had its own problems because, while the 2903 was happy in an office environment, the 60MB drive wasn't - and the whole system was in a normal NYC office environment.
This was fine in summer because both people and the 2903 system needed cooling, but caused fights in winter because the office could only have heat or aircon on - never both - and so the ESD60 played up in winter.
...calling Cobol a proper language is a step too far!
I disagree. Once the horrid ALTER verb had been removed from the language, the syntax for linking separately compiled subroutines had been added, and the CODASYL language standards had been adjusted to make the language a bit more portable, COBOL is a model of clarity compared with the likes of javascript, FORTH, RPG or PL/1.
Granted, COBOL is still rather verbose, but it is very well suited for the sort of programming tasks it was designed for - building business applications and handling structured data.
It does a good job reading and writing complexly formatted financial currency values and, with the IDMS(X) syntax preprocessor installed, processing transactions using what is now called an Edge database becomes quite straight forward. With this came the added advantage that, while IDMS programmers needed to learn how to read a data structure diagram, they didn't need to learn a different database manipulation language like SQL, because the IDMS preprocessor introduced a small set additional verbs that were coded using the same familiar COBOL syntax.
If you're a newbie to writing languages that use C-similar syntax, i.e. C, C++, Java, Pascal and maybe even Perl, you can do a lot worse than to beg, buy, borrow or steal a copy of "The Practice of Programming" by Kernighan and Pike. I wish it, or something like it, had been available when I was learning to write maintainable programs.
The book is well written and contains excellent advice on:
- writing well-documented programs
- choosing informative names for variables, functions, etc
- structuring programs to be both efficient and easy to debug.
...and made a spectacularly terrible job of it.
Canada, was first, with observers from Australia and NZ present. They made several mistakes that the other two spotted.
Australia went next, with NZ observing. They avoided all the Canadian problems , but discovered a few more ways to mess up.
NZ then converted, and had a pretty straight forward conversion without inventing any significant problems.
I was there at the time - by and large it 'just worked', because the sizes, shapes, colours and purchasing power of currency up to the dollar (the old ten bob note) stayed the same and the new dollar-denominated notes retained the old colours and purchasing power, e.g. the new ten dollar note bought the same amount of 'stuff' as the old fiver and was the same colour. It took most of us less than a week to feel at home with the new decimal currency.
UK? Watching what former colonies did was apparently beneath the dignity of yer average Whitehall mandarin, with the result that the UK managed to repeat most of the mistakes made by the three Commonwealth members and invented several major cock-ups of their own, chief of which were:
- retaining the pound sterling rather than normalizing the ten shilling note as a New Pound,
- inventing a new set of unfamiliar coins rather than re-purposing and retaining the old coin shapes, sizes and materials
- utterly failing to have enough inspectors to catch and deal with ripoffs
- failure to make reporting ripoffs as straightforward as possible
I've since learned that this behavior is to be expected from any UK Government and its associated civil service and watched them repeat the same routine: that of ignoring anything learnt by Johnnie Foreigner and then making a complete balls-up of their own attempt at the same thing: metrication, privatising the railways and Northern Ireland Customs arrangements being prime examples.
This type of remote manipulation system was first described by Robert A Heinlein in his short novel "Waldo", published in August 1942, so its only taken 80 years to realize. The novel is in a book, "Waldo and Magic, Inc" together with a rather different story, "Magic Inc", also written by Heinlein.
Seriously, a nice job by the team:.This is a good and useful thing to finally have up and working.
This story would have been a lot more interesting if it described where the hydrogen will be sourced from and what technology will be used to produce it, i.e. is it electrolysed hydrogen made using solar or wind turbine generated electricity or just hydrogen from a chemical plant converting hydrocarbons and powered with even more hydrocarbons?
One would hope that a well designed medical system would be rather careful to check that the person or organisation who is being asked to carry out the procedure or provide the requested medication is capable of carrying out the request in a timely fashion and *not* simply send it to a waste basket.
Dunno why you'd think either block chain or AI would fix this problem when any competent project team should be capable of designing a data structure and supporting process stream to carry out something like that.
Task specific specialist knowledge requirement? Easily fixed: just be sure to add a team member who has SUCCESSFULLY done a very similar task in a related specialty. Been there, used that approach several times. Never failed, unlike certain other projects I've been on that were managed by know-it-all MBAs and similar 'universal experts'.
I'd been using hierarchic filing systems from 1971: ICL 1900s running George 3, so not particularly rare systems.
Thw 190 series also used an secure solution for memory guarding - in a 1902/3/4 there were just two hardware registers: DATUM and LIMIT, which which pointed to the base and highest address in the running program and provided a hard limit to the addresses the program could access. The 8 registers, PC,CC etc were the first few words in the running program. This also made moving a program in memory or swapping a quiescent program to or from disk very simple - its complete state was automatically transferred because it was recorded in the first 32 words of the image being moved.
I'm certain the 1905-6,9 models did something similar despite having faster discrete accumulators, but I never used nor was admin for them.
I've used both ICL 2966 mainframes running VME/B and IBM AS/400 running OS/400. Both were very reliable and showed a refreshing unwillingness to crash.
IOW, both implemented first-class memory protection that did exactly what it said on the tin.
They had other nice similarities too, in that both had compilable job control languages and carefully thought-out command names (IOW once you know how command names are constructed you can guess seldom-used command names with good accuracy), decent source editors and well-designed program fault analysis tools that made program development easy. And both used excellent full-screen command prompting combined with an online command lookup capability.
However, both had what seemed, even then, like a major fault: neither had a hierarchic filing system, though at least VME/B used nice long names for commands and files.
I thought OS/400 blotted its copybook by restricting all names to nine characters, which made command names difficult to remember despite enforcing a consistent naming system - the PL/I compiler was called CRTPLIPGM - line noise for sure at 1st or even 2nd reading.
As title: I haven't had any SD card issues after I switched to Sandisk. I decided to use their SD cards because they are readily available at a decent price and have their own SD card foundry and so know what you're buying provided you buy from a reputable vendor. I use them in cameras, RPis and for gliding, where they are in two critical in-cockpit instruments:
- FLARM, an anti-collision device, where the SD card holds FLARM software, configuration and logs
- LK8000, a GPS-based moving map navigation system, where it stores the software, 3D maps, 3D airspace definitions and their categories, NOTAMS and, last but not least, the declared turnpoints for the task being flown.
There's also a Sandisk card in my GPS-based flight recorder, which is used used for competition and ladder flight scoring and for bragging rights, etc.
I've been picking up vibrations for a while now about there not being enough readily exploitable Lithium for the world to go BEV without a lot more virtually zero loss Li battery recycling being in place - which it ain't yet.
More recently, it seems that somebody's been doing the numbers on the wiring needed to link up all the BEV chargers needed for a 100% BEV world and finding that there's a copper shortfall though, interestingly, there was no mention of aluminium cabling on the national grid and a reasonably careful search failed to say what metal is used for national grid cabling.
...just how good the tool is for training drones (and autonomous e-cabs) to handle the sort of turbulence you'd get in mid-town Manhattan during a decent blow.
And, since it claims to be easy to use, just how easy it would be for a new customer to set up a training scenario covering building turbulence, tree-generated turbulence and microbursts for a completely new high altitude operational area like Boulder, CO or Lukla in Nepal.
A meteorologist once told me that statistically the best weather forecast for 'tomorrow' was....
I think that's a fairly well known story from the time of the first Met Office computer forecasting system.
When their first forecasting model was up and running, they ran a trial, pitting the new system against their existing 'traditional' forecasting methods and, as a control, threw in the assumption that "tomorrow will be much the same as today". The test results showed the computer and 'traditional' forecasting to both be correct around 50% of the time while the 'about the same as today' control case was right 66% of the time.
IOW, UK weather changes roughly every three days. I got that story from a friend whose brother was a Met Office man, but the computer models will have changed quite a lot since then.
The last comparisons I know about, made a few years ago, were that the Met Office was sufficiently far ahead of the US equivalent for the USAF to be using it rather than their equivalent and that the European Centre for Medium-Range Weather Forecasts was pretty good as well.
I don't blame her for hating Word Perfect. I also hated it, what with its untidy set of randomly placed set of function keys spread over three shifts, slowness when asked to scroll to the end of a document, and the necessity of using what was a effectively debugging display to fix formatting problems.
IME Word for DOS was head and shoulders above the other word processors from that era - and was also faster and easier to use than Word for Windows too. I particularly liked that way that hitting F8 once selected the whole word, hitting it twice selected the whole sentence and three times selected the whole paragraph.
Upvoted, because there are obvious hazards if the use of laser-equipped satellites becomes a free-for-all.
However, it seems likely that limits on frequency bands, transmission power and, probably, minimum elevation above the horizon (to protect pilot's eyes) would become part of Standard Operating Procedures.
I can see both advantages and disadvantages in laser-based space comms. The most obvious disadvantage vs radio is the requirement to aim a transmission very accurately at its target to communicate at all, just as the most obvious advantage is the ability of tightly beamed transmissions to reuse any frequency without causing either accidental or deliberate interference. However, this would probably require the receiver to use a suitably directional antenna, i.e. a small telescope, and this in turn would require both ends to use rather precise pointing mechanisms to establish and use a link.
Given all the above, I can see its advantages over interplanetary distances, but wonder what,if any, advantages it would have over radio for LEO communications, other than bandwidth.
I notice that, the 'Tracking data' page on the Mayflower website is severely minimal. To me, a 'course tracking' display should display both the planned course and the course actually sailed. Instead, all that's shown is the planned course and the current position, which has never coincided with the planned course when I've visited the site.
Given that it may be quite difficult to keep such a small, slow craft on a planned course on the open sea, it would be very interesting to see the whole course it has actually sailed to date. That should be easy to show too, since its a reasonable assumption that its operators will have archived its reported set of positions for later analysis. Consequently, I wonder why this detail isn't shown: it would make the site a lot more interesting to visit.
In this case, back in the mid 70s, I was on a project in NYC, building an accounting system for a Long Island toy manufacturer, under contract to ICL(USA). The system was written in COBOL and being developed on an ICL 2903.
Our team was small: two of us and two local American ICL employees, one was excellent, the other barely trained and wished on us for no apparent reason, but so inexperienced he could contribute little to the development effort apart from maintaining the COBOL copy library, doing backups and other system operational tasks. We were on a tight schedule and had no time or budget to train him. All went well for a month or two until he decided that he could 'improve' the copy library. The result was that, suddenly, our code wouldn't compile thanks to his changes. He was totally unrepentant (just like the guy who screwed with the Rainbows), so was out the door PDQ, but it took a lot of unnecessary effort to make that copy library usable again because, of course, it turned out that there was no clean backup of it.
Correct. All "AI" means at present is 'Pattern Matcher': some device or program that can report a result as 'matches requirement', 'doesn't match requirement', or more rarely 'similar to required answer' and cannot explain how it arrived at the answer it provided.
As a result, the "AI" tag is essentially meaningless.
The 'Artificial Intelligence' designation should only be applied to systems that CAN give a meaningful explanation of why they came to a particular conclusion or recommended a procedure to be carried out,
However, fat chance of THAT ever happening thanks to the money being made by selling the current fallible pattern matching systems to the gullible as 'AI' or, worse, claiming them to be reliable ways to give definitive answers that affect people or control autonomous vehicles, factories, et al.
Interesting, only because he seems not to understand the existence of Open Source and its implications.
In particular, as we've seen recently, there seems to be significant amounts of abandonware in popular shareware repositories and, worse, it is linked in as required component(s) of packages supported by other, unrelated, developers. It would be nice to know if Mr Inglis even knows that this sort of linkage exists and just who, if anybody, does he think should bear the legal responsibility for fixing buggy abandonware in such a calling sequence.
Seems to me there are four main questions that need answers:
1) what responsibility should the shareware repository owner have for providing tools that allow an author to determine who wrote shareware that his code depends on?
2) Should they refuse to accept code that's not fully documented and accompanied by a properly maintained set of unit tests with enough coverage to fully validate the shareware's operation with valid, invalid and out-of-range inputs?
3) should the abandonware author be legally responsible for removing code that they've decided not to support any longer? Who inherits this responsibility if the author dies?
4) What liability should fall on a shareware author whose product depends on buggy code written by a 3rd party and that may or may not be maintained?
Try replacing those.
Same goes for Ubikey or Bluetooth connected phone, unless there are actually three devices involved in the sign-in:
1) the Ubikey, Bluetooth-connected phone, or whatever holds the encrypted token(s)
2) the device you're using to connect to the required service
3) the server supporting the required service.
In addition the first two must have a secure way of storing something unique which can be sent to the third for validation.
I have a Ubikey and use it to access services on one of the GitXXX code suppositories, However, I know almost nothing about its anti-theft safeguards: no documentation came with it and their website is equally uninformative about how its security systems work and why they are more secure than user name and password.
IOW I'm happy to accept that the Yubikey is one factor but have absolutely no idea what 2nd factor may be or if it even attempts to be 2FA, when all I did to activate it was to stick it in my laptop's USB socket, and login normally to GitXXX. Since then I've been able to simply stick the Ubikey into the USB socket and immediately use git push/pull commands to update or access the remote repository.
To me that seem less secure than, say, a UK bank's 2FA card reader, where at least you know what both factors are and that the card reader is not one of them.
A quick look at Coshocton, OH on Google Earth shows that in Cantwell Run, which is just below the point where two rivers join to become the Muskingum River, the combined river is only 80m wide and appears to be quite slow flowing. IOW its heat removal capacity doesn't look all that large: certainly not when compared to the Mississippi, which is over 600m wide at St Louis and navigable as far north as Montana.
So, who's for precooked catfish? Looks they could become freely available just downstream of that nice, eco-friendly water cooled data centre.
A major problem is that all too many people simply don't notice or care what the weather is once the weather forecaster has told them whether they should wear something waterproof or beware sunburn.
Sadly, that describes the attitude of almost everybody who live in cities, which is most of us. These are also the people who deny climate change because they have never taken any notice of the weather or its long-term trends because they've never needed to. As a result they don't understand the effect of weather on their lives or the consequences of it changing.
The only people I know of who do notice weather are dependent on it for their livelihood, i.e. farmers and sailors, plus a few minorities such as hill walkers, some model flyers, and glider pilots whose leisure activities are critically weather-dependent.
Wafer repair is presumably not an option, unlike a conventional chassis full of replaceable system boards. As a result, if anything significant fails on a single wafer system, it seems very likely that you'd have to replace the entire wafer unless, of course, there are redundant subsystems designed into it. However, since I've seen nothing about redundancy being built into these systems-on-wafers, it seems likely that it doesn't exist. Otherwise it would be used as a selling point.
What did I miss?
I'd expect any banking/fintech system which supports direct connections from client systems to require that:
- their provided interface package or its specification which MUST be used by client systems to connect to the central system
- a validation package will be used to exercise a client's connection before it is permitted to connect to the central system. This must both confirm that supported transactions and responses perform as expected and demonstrate that the client side can successfully handle and reject invalid and spoofed transactions sent to it.
- a non-negotiable requirement that the final full functional check before a new client's connection is permitted to go live should be observed by the central system's security team, with anything less than a 100% pass being treated as a fail,
- this functional check must be repeated whenever the interface specification is updated by the central system or when client software using the interface package is revised.
Any financial network that doesn't provide such interface specifications and require these functional checks is deficient: using it should be avoided if at all possible.
I also have a copy and knew one of the people who worked on EDSAC, which the LEO was based on. Unfortunately, at the time (1968/69) I'd never heard of EDSAC.
If you're interested in computing history then, alongside "A computer called LEO", your library needs a copy of "A Brief History of the Future" by John Naughton, which described the history of the Internet. Again, I've met one of the people involved, this time Roger Scantlebury, in 1984 at Logica.
So, what's the passwordless solution ? I haven't heard of one yet and, if somebody had an actual solution, I'm sure we'd be hearing about it and seeing it implemented already.
Devices like the Yubico dongles seem to work painlessly enough, at least when used for passwordless access to sites like GitLab.
However they they do have drawbacks, such as their price and availability, being small enough to lose easily unless you've attached them to a fob of some sort, and requiring the device you use them with to have a USB socket .
What seems to have happened is that budgeted research money, or what there was of it, was given to various Tory chums who promised, but never delivered, COVID test and protective equipment and seem to have simply pocketed the dosh. Everything after that looks like doing anything they can to avoid charging said chums with fraud and to hell with science: far too many MPs don't feel any need understand science and engineering because all their degrees are in arts and politics and, you know, technical subjects are HARD.
Of course GIMP uses that dialog rather then blindly prompting you to save, because there are more ways of using it where simply saving would wipe out your last nn minutes of careful work than there are where the so-called 'simple save' is exactly what you want.
The classic example is using GIMP to make a thumbnail from a larger image. In this case blindly saving will replace your original image with the thumbnail, which is NOT what you want at all. What you actuallly want is to Export the thumbnail under a different name and then exit without saving anything. In this case the prompt about not having saved anything is a useful reminder that saving before exit is likely to do damage.
FWIW my two most frequent uses for GIMP are making thumbnails from large images and reframing captured screen shots: In both cases I'll want to export the final image and not save it.
Judging from El Reg's article, this paper doesn't tell us anything that Kurt Vonnegut's 1952 novel "Player Piano" hadn't already predicted in the way of the harmful effects of automation on society at large. Its a worthwhile, though dystopian, read.
Bezos and Amazon, and any anybody else who thinks automated micromanagement of 'fulfilment center workers' and zero hour contracted employees in general are good for anybody except their bosses, we're watching you.
This applies in spades to HM Civil Service. I've seen the results of not periodically culling the middle ranks in two major departments when on contract there: in both cases the resulting failures of middle management caused multi-year delays in implementing much-needed new systems.
Lord Agnew quoted very similar failings on the part of the Treasury, the British Business Bank and the National Audit Office in his resignation speech in the Lords yesterday, i.e. a total inability to understand or do their jobs.
By contrast, I've also worked in a major IT consultancy that used the opposite approach, with minimal bureaucracy between Galactic HQ and the business units, which were structured as small, independent companies that could easily be restructured and/or re-targeted as business needs changed. This resulted in a nice working environment and one that worked well until the founders retired and the new boss proved inadequate for the job.
Fair comment.
Its certainly true that the personal tax and pension stuff has been on ICL kit for an inordinately long time: I remember being told, around 1970, when I worked for ICL, that 1900 COBOL's then newly added ability to hold a collection of previously used overlays in memory rather than reading them from disk each time they were executed had been implemented when ICL Dataskill had been asked to implement DWP's first automated payroll & pension tax system.
The story went that, when the ICL team rocked up at DWP and the team leader asked for the project definition, the civil servants simply dumped a set of thick books, which contained the salary and pension legislation, on a desk and said 'Program all this'.
It wasn't long before the team's technical manager realized that the programs, which were to be written in COBOL, would be far too big to be loaded into even a 22AM address space (8M 24bit words), and so would have to be overlaid and that, as handling almost every taxpayer's details would require at least one overlay swap, the system would be tooth-achingly slow if each overlay had to be read from disk each time it was executed.
Hence a high priority COBOL development program to allow the most used overlays to be automatically held in memory where they could be executed without even the overhead of moving them about in memory: simply copy call data into copies of the parameters in the overlay's address space and then switch control to it. Exit from that overlay when it had done its thing was equally simple: copy the result from the overlay's output parameters into the calling program's corresponding variables and pass control back.
All this only needed changes to the COBOL compiler and its runtime support library since the required memory protection and ability to switch control between processes that were already in memory was a standard feature of 1900 architecture.
Given that back history, its scarcely surprising that what must be a pretty large complex, and frequently amended rule set might be something that people tiptoe round and avoid, whenever possible, making anything other than minimal changes to.
I remember Fujitsu announcing that ICL's VME/B OS had been ported to X86 hardware, and for certain that hardware will have more memory and be a lot faster than a 2900 OCP ever was.
In fact, VME/B and applications written for it should be relatively easy to port to modern hardware because the microcode needed to virtualise it already exists: VME/B on a 2966 sat on top of microcode executed by a 2MHz Motorola 6809 MPU, so just rewrite that for ARM or X86 hardware and job done. I got the full detail on how all that worked as part of an in-house BBC course on 2900 internals in 1978.
Bottom line: I see little excuse for the mess that Fujitsu and the other usual suspects are making of supporting HMG departmental systems, though I suppose charging for keeping the existing systems running while HMG's departmental heads endlessly bicker over priorities for implementing poorly defined system requirements is both more profitable and much easier than actually getting stuck in and doing the work needed to provide modern systems on time and to budget.
Getting to know Heavens Above:
https://www.heavens-above.com
and using it as your primary reference for finding satellites etc. would be a good start. This website has a LOT of information to help you find satellites, astronomical objects, eclipses, etc. It also tells you where and when the better known and/or bigger satellites will be visible once you've told the website where you are on the Earth. The satellites it provides data for include the ISS, Tiangong, Hubble and the X-37b (when its flying).
Obviously you still have to work out if the skies are clear enough to let you see what you're looking for, but using:
Sat24: https://en.sat24.com/en/gb/visual
Zoom Earth: https://zoom.earth/
or simply looking out the window helps with that.
I think the HHG book series was at least one book too long and Douglas Adams clearly thought so too; my guess is that's why the 5th book ended by killing everybody and destroying the galaxy just to make sure that nobody could make him write a sixth volume.
But, IMO the best HHG version was live onstage at the Hammersmith Odeon: Vogons leaping off the stage to beat up the audience, cardboard police blasters shooting real laser beams during the shootout that blew up the computer-bank, causing everybody to end up in Milliways. Yes, it was even better than the radio version. Its only downside was that by the time I saw it the bar had stopped selling Pan-Galactic Gargle-Blasters in the interval.
Zaphod was played by two actors in the same clothes, so his heads could and did argue: much better than the Beeb's patheric, obviously dead plastic second head.
... in cases where the standby system and database instance(s) are physically remote from the live instance.
Typically this type of replication means sending copies of the live system's transaction log to the backup system(s) and applying the transferred log items to the standby database(s) in as close to real-time as possible. Speeding up transaction log transfer minimizes cut-over time because a standby system must not accept the live workload until its database is fully up to date.
I'd think that depends on what the debugging code does. If it just shows the function execution sequence plus values of a few variables that select execution paths and isn't normally enabled in a production environment, then its not likely to be particularly harmful, provided that debugging activation is restricted to system supervisor level personnel and their supervisory programs.
Any harm the above enables can be further minimised if debugging output is written to a circular buffer, sized to accommodate only the tracing output associated with a single exception and where the buffer content is only ever written to a logfile when an exception occurs.
the mega-comet exhibited a coma a startling 23.8 astronomical units (AU) from the Sun – roughly 24 times the distance between the Earth and our star
We, on Earth are, by definition, 1AU from the Sun. Our orbital radius defines the Astronomical Unit, which is approximately 150 million kilometers (93 million miles).
The Register - Independent news and views for the tech community. Part of Situation Publishing
Biting the hand that feeds IT © 1998–2022
