Posts by ChrisC 1622 publicly visible posts • joined 2 Jul 2009
Ah yes, the "form over function" problem that plagues so many aspects of modern life, and where those in the position of authority to make the decision are, far too often, biased in favour of the "form" answer because they don't get to then suffer from the resultant lack of "function" their decisions have created, unlike all of the poor minions under their control who just have to deal with it as best they can...
Given that displays like this will play at best a minimal role in providing core functionality of the lift (i.e. at most, they might be used to provide the audible and visible indication of which floor the lift is on/heading to), with all of the serious stuff required to ensure the lift actually does function correctly and safely being handled by devices with far more attention paid to their design re reliability/stability/etc, then my only reaction to seeing this might be a raised eyebrow or a wry smile, as I happily used said lift to convey me to my chosen destination. It's no more of a safety issue than, say, having the in flight entertainment system reboot mid-flight. or having your car stereo lock up during a drive. Inconvenient, perhaps, unsafe, no.
"This is a screen in a lift. It will be showing only a select number of images that the owner/operator of the screen wants it to show"
Not always - one of the reasons we're seeing larger/higher quality displays appearing in lifts is precisely because the building owners want to push multimedia to lift passengers, so the idea that a screen (and the backend system driving it) like the one in this article would be ticking over on idle power just cycling through a handful of carefully curated still images is somewhat outdated.
e.g. https://www.dewhurst-global.com/emea/product-category/displays-directional-indicators/multimedia/
Yup. Almost cost our son his chance to complete this years college course, because every time he submitted his final written report it kept being flagged as AI. Although they didn't actually tell him this at the time, they simply kept rejecting each version and asking for a rewrite.
Fortunately, after the 3rd or 4th (we lost count) such attempt to submit as normal, they then asked him to come into the college in person and verbally create another report, answering questions on the fly in the process to determine his true knowledge of the subject, by dictating it into a college PC to be transcribed into text for analysis. Even THIS version of the report still tripped their AI detector, however as they now had cast iron proof that it HAD been written by him with no outside assistance, they finally had to admit that his work was simply at a level far enough above what they were expecting from students at his stage of the course, and therefore above whatever trigger threshold they'd set for the AI detector, and that this was also the reason why all of the previously submitted versions of the report had also been rejected...
My opinion of the mindless dive into adopting AI everywhere it possibly can be adopted, some places you wouldn't expect it to be, and some where it absolutely should never EVER be used, was pretty low even before this, so this personal example of how AI itself can not only get things badly wrong, but also how the blind acceptance of AI answers by people who ought to know better then makes it harder for the genuinely aggrieved to get the correct result at the end of the day, was just the very sour tasting cherry atop the rancid cream cake of AI sloppery.
Like any tool, AI *can* be useful, but only when wielded with care and thought, and only as part of a wider array of tools and techniques. Blind acceptance of it is a mugs game, and anyone who chooses to embrace AI so wholeheartedly is someone to treat with the utmost of caution. Especially if they hold any sort of power over your personal or professional life.
If I woke up tomorrow and learned that AI had ceased to exist overnight, never to return in any way, shape or form, I genuinely wouldn't care, and I'm struggling to think of any other technology where I'd be able to say the same thing.
"These nukes can't be launched unless the USA gives its permission to use them."
https://www.chathamhouse.org/2025/03/uks-nuclear-deterrent-relies-us-support-there-are-no-other-easy-alternatives
"In day-to-day operations, the UK’s Trident programme is completely independent from the US. The British Prime Minister can launch the missiles without any external input."
Other credible reference sources are available which will say the same thing, so I suspect your assertion that we can't launch unless the US gives us the nod is based on ignoring these sources and relying on those which are rather less credible...
"An adversary carried out attacks with chemical weapons on UK soil - clear violations of international law. The allegedly independent nuclear deterrent deterred nobody."
That's really not the purpose of a nuclear deterrent though, is it...
"BTW Ukraine's capability to destroy Russian oil refineries and pipeline infrastructure wasn't much of a deterrent when Putin decided to invade."
What capability do you think Ukraine possessed at the start of the 3 day SMO which might have acted as a deterrent? Their ability to NOW wreak havoc almost unchecked on targets increasingly deep into Russia is something that's been developed as a result of the war, it wasn't something they already possessed beforehand.
"I have software on floppies, CDs and DVDs that I can load and run from decades ago."
All well and good right up to the point where completing the installation of said software requires it to phone home to a server to authorise the install in some way, or to enable use of the software (e.g. games which in theory could be played entirely offline, but which still need to check in with an active server for updates etc, and which are therefore rendered useless the second said server is EOLd)... The key point here isn't so much the method by which the necessary data reaches your system, it's whether you can then make use of it without the need for any further assistance from the original provider.
So physical originals or backups are a good idea, sure, but ensuring access to the files is increasingly only part of the problem we've been starting to face for some time now, and which will only get worse as more companies rely in some way on server-side tie-ins.
"My ISP is rolling out 2.3Gbps internet for £25/month. 2Gbps! Faster than a HDD! Who besides a server host could possibly need that eh? 20 years ago 2Gbps was the backbone for my entire university, and that was considered fast."
20 years ago we still bought games, music, video etc on physical media. 20 years ago our digital cameras weren't routinely generating GB's of image/video data during a single shooting session. 20 years ago we weren't having to download GB's of patch data for stuff we already had installed on our systems (and 20 years ago, the definition of "systems" in this context was rather less expansive). 20 years ago, the average user didn't need that sort of bandwidth, because the average user didn't have a use for it.
It was 26 years ago when I got my first home broadband connection, a 512Kbps ADSL link, which was genuinely more than fast enough for my needs at the time. These days I wouldn't even bother trying to get online if I knew my connection was that severely constrained, because it'd be an exercise in extreme patience and ultimately futility in trying to achieve anything of use.
Times have changed...
Thanks for the first hand experience clarification - I couldn't quickly find any references to it online, and it's been so long since I last heard the story, I honestly wasn't even sure if my memory was just playing tricks on me and it was nothing more than something I'd imagined...
"I had to reluctantly retire the Amiga as they went out of fashion"
They may have gone into hibernation for a bit, but they've never really gone out of fashion, at least not with those of us who were either big Amiga users back in the day, or who now want to experience what a well designed retro system is like...
Whilst this now sounds more like an urban legend rather than a true story, back in those days I recall talk that some Amigas would be DOA because their socketed custom chips had been shaken slightly loose due to speed bumps on the road leading away from the Westchester loading dock, and the fix was to turn them upside down and drop them, to encourage the chips back into place.
Yeah, having used the same technique some years ago (though not *quite* as far back as HP were doing it) to use a LCD backlight as an ambient light sensor in the "off" periods within the PWM switching cycle that controlled its brightness, in order to adjust said brightness, I was struck by the opening "Traditional pixels generally do one or the other – illuminating a display screen or capturing light in a camera sensor" comment as sounding like a massive oversimplification...
...though admittedly, as this then made me all the more curious to read on and see what the researchers actually HAD come up with, I guess it served its purpose to lure me in, like every good tabloid headline/intro paragraph these days.
"in a couple of years we'll start to see the consequence of battery powered smart gas meters stopping the supply of gas (when the battery fails they disconnect supply: far better that consumers should freeze than the industry lose a few quid of revenue)."
Citation please - various searches have failed to elicit any results indicating this being one of the effects of a gas smart meter battery failing, and instead elicited several results indicating gas supply would be maintained...
"The 640 x 480 pixels of the Video Graphics Array (VGA) standard might be scoffed at by modern engineers"
And yet, fire up an emulation/virtualisation environment running an older system with that sort of resolution, and more often than not it *won't* feel anything like as cramped as the numbers suggest - yes, we have larger screens running at higher resolutions, but as with memory, drive space and CPU cycles, the software of today has simply bloated out to fill the available capacity whilst offering little in return.
When you *had* to squeeze your UI into 640x480 (or even lower if we're going a bit further back in time), you made damn sure that every last pixel was put to good use. Blank space was wasted space, so there was little or no thought given to making the UI look like a graphic designers dream - function over form every single time.
I think back to how much work I was able to get done on a single 14" screen running Workbench at 640x256, and I think about how much time these days I spend juggling windows across dual 24" 1920x1200 displays, and I realise just how much I miss those good old days of personal computing...
That might justify the continued existence of the CCZ and, to a lesser extent, the newly introduced tunnel charges, though even then the question is still entirely relevant - just how keen are TfL to *actually* reduce congestion, vs making use of its ongoing existence as a revenue stream.
It's however not an argument for maintaining *all* of the road user charging schemes currently in operation, because they're not all aimed at reducing congestion in those parts of Greater London where congestion actually is a problem, nor is it an argument as to why such charging schemes are treated as the *only* means to address the problem.
In order for TfL to merely break even here, these road user charging schemes have to bring in an average of £182 million every year for the next 5 years.
So either they expect to still be raking in a *lot* of standard daily charges, or not quite as many but still what ought to be considered an unacceptably high number of penalty charges, across all of these schemes, which begs the question as to just how interested they actually are in encouraging drivers to change their behaviours in order to avoid having to pay these charges/penalties in the first place...
"The days when literally every byte counted"
Those days have never gone away for people still working in the embedded systems area - a decade after your anecdote took place, I was tasked with completing a design based around a controller with 1KB of program memory, and even just a few months ago I was working on a design with a relatively paltry 16KB.
"well written" != "perfect"
Also, even if it genuinely was perfect, with no possible means by which it could be improved by so much as the slenderest of margins, then merely asking for an intelligence (whether real or artificial) to improve it SHOULD have resulted in an answer along the lines of "I'm sorry Dave, I'm afraid I can't do that", though preferably without the murderous undertones...
What it absolutely SHOULD NOT have resulted in was said intelligence adopting an illogical interpretation of "improve" which led to the modified version performing, even by so much as the slenderest of margins, any less effectively than the original. Because that really isn't an improvement, no matter which way you try and sell it.
Less the name per se, more the fact that the name is being used in this way whilst he's still el Presidente.
If he'd still just been a reality TV show host and occasionally successful businessman, choosing to slap his name across everything like this in order to extract more cash from the gullible, then so be it. But to be doing so, knowing full well that his name currently has even more sway/power/whatever you choose to call it because of his privileged position at the top seat of US government, THAT'S the real problem IMO. He's cashing in whilst *still* in office, rather than having the decency to at least wait until his term ends before raking it in based on the still lucrative position of being a former President.
"if you impose an artificial limit on project size"
For those of us working in sectors where these limits are entirely real, and where failing to adhere to them means your code literally cannot run at all, so much of the sentiment here isn't just wistful longing for the good old days, it remains an utterly integral and essential part of our everyday lives.
Right now I have the relative luxury of developing code to run on an ARM core microcontroller with a positively expansive 512KB of non-volatile storage, and an equally impressive 128KB of SRAM. By the standards even of an old school PC, such figures would sound laughably small, yet this is a far from atypical level of memory/storage resource limits that modern embedded systems developers work with. And note how I've described this particular device as being quite spacious, because compared with many of the other devices also currently available, it genuinely is. Another project I'm currently involved with uses a device with 16KB storage/2KB SRAM, and even that is an order of magnitude bigger than the most constrained of devices I've worked with so far.
So yes, as someone who not only remembers how efficient old school desktop code used to be across the myriad of systems I had experience with back then, but who is constantly reminded how much can *still* be done with some efficiently written code, I'm absolutely onboard with any and all criticism of how little effort is now paid to writing stuff that takes full advantage of the hardware capabilities for the good of the end user, as opposed to taking full advantage of it for the benefit of the coder - i.e. allowing them to write underoptimised crap that only runs as adequately as it does because of how much raw power the host system is able to throw at it.
Also an early example of a fidget toy - held between thumb and middle finger, leaving the side of the shutter nicely within reach of my index finger, allowing it to be slid open and then let it go with a satisfying click, to be repeated as often as required during a late night coding session in front of my Amiga...
I'm convinced all the various sensory feedback (the sounds, the tactile sensations, even occasionally the smells) provided by these earlier systems is one of the reasons why we now look back on them so fondly in comparison to the rather more sterile and anonymous systems we have these days. I mean, sure, I love the performance improvements things like SSDs have brought to the table, but I also find myself sometimes missing the way my older HDD based systems would sound and feel depending on what level of drive activity was taking place, and as for the very satisfying sensation of pushing a floppy or Zip disc into the drive slot, or a cassette into a tape deck, nothing about a modern system comes even remotely close.
The problem for the Ukranians is that the present incumbent of the Kremlin (or wherever it is he currently chooses to hide out) seems entirely disinterested in allowing Ukraine to remain an independent nation no matter how neutral it might be, and has made it pretty damned clear he wants to bring it back into the welcoming arms of the motherland as part of Russia itself, because he's never regarded it as ever being a truly independent nation in the first place.
So if you think for a nanosecond that, were Ukraine to sign a cast iron agreement to never ever join NATO, the EU, or any other organisation that so much as gives off the merest whiff of being anti-Russia, and promises to remain entirely neutral until the end of all eternity, that this would suffice Putrid and he'd withdraw his forces leaving Ukraine well alone for a similarly lengthy period of time, then I'd urge you to think again, and keep on doing so until you realise just how utterly unlikely such an uneventful outcome would actually be.
2018 is in with a good shout here, when your bestie in the Kremlin decided to deploy nerve agents in public areas... It might have been a quite targeted attack intended only to target one specific individual, but between the fact that using chemical weapons is abhorrent in its own right, and the fact that the haphazard way in which they were used meant an entirely innocent person lost their life, it very much WAS considered a hostile act against the UK generally, and one which likely played a part in how willing we were to support Ukraine in the early days when so many other nations were dithering around.
But on the other hand, the lack of any larger scale attacks against us isn't necessarily the smoking gun you're making it out to be - is that lack of attacks because no-one really wants to attack us, and therefore our defensive expenditure has been a complete waste of money, or is it because we HAVE spent so much on making ourselves a less desirable target...
The threat to the land based nuclear deterrent was the driving factor in the development of ballistic missile submarines, which Russia has several of in active service - it's *those* which are now responsible for maintaining the MAD concept, because unless you do something remarkably stupid whilst operating them, or unless your enemies have managed to come up with a way to reliably track them at all times such that, in the event of said enemies wanting to initiate a first strike against you, they'd also be able to guarantee the destruction of every one of your missile boats, then no matter what happens to the motherland, you'll always be able to deliver a retaliatory strike, i.e. MAD...
And if Ukraine joining NATO is genuinely a cause for concern due to how close NATO could then position missiles to Moscow, then why weren't the Baltic states of similar concern when they joined? Right now, the closest part of NATO to Moscow is around 580km, whereas if Ukraine joined this would come down to around 450km - i.e. Ukraine being part of NATO makes the square root of diddly squat difference to NATOs ability to initiate a surprise strike against Moscow, and if we're considering other targets such as St Petersburg, Murmansk, Vladivostok etc, then adding Ukraine to NATO would provide no benefit at all.
And all of THAT presumes you're willing to accept that NATO actually would want to initiate a surprise strike, in complete contradiction to the reason it exists - i.e. as a defensive organisation aimed at deterring against attacks on member nations via the "an attack on one of us will be treated as an attack on all of us, so think VERY carefully about your next move..." doctrine.
So nope, the whole "ooh, we can't allow Ukraine to join NATO because of how much danger that would put Russia in" argument is a load of hooey. It's a convenient excuse Putrid can trot out to deflect criticism of his unwarranted invasion of Ukraine, but that's all it is. We managed to get through decades of the cold war without NATO making any efforts to attack Russia, so why would we want to upset the apple cart now? Russian paranoia is no justification for attacking a country in order to prevent it joining a military alliance that has shown throughout its entire existence a noted lack of desire to poke the bear.
So basically, your argument seems to be that, because all wars are pointless and could be brought to an end quickly if only people would bother to talk to one another, there's no need to spend any resources on providing an effective means of defending yourself against whatever crap is thrown your way in that brief period between someone deciding to attack you, and your figuring out what you need to say to them (and just how much you'll have to then give over to them as a result...) in order to stop them doing that?
Nope, no thanks. Negotiations are one thing, but until they bear fruit I damn well want the people entrusted with running a country for the good of its citizens, to have the ability to at least *defend* the country and said citizens against attack.
The advantage of using high performance fighters as the launch vehicle for the lower cost missile is that it buys you more time to get into a more effective firing position as soon as you become aware the drone is inbound. So unless you've been caught by surprise and the only opportunity you have is for a head on shot, then the more desirable option would be to loop around behind the drone and set yourself up for a tail chase intercept.
Also note that currently it's 14 shots per Typhoon - all the publicity images which show the full loadout rather than a close-up of just one pod, show there's a pod under each wing - though I haven't seen anything to suggest whether that's all that can *ever* be carried, or if there's scope (either now, or with additional integration testing) to swap out the normal load on other hardpoints to fit additional pods if needed.
"For office drones (which is the bread and butter of Windows client editions), the best way to go is to have the taskbar in a fixed location, ease of training, ease of documentation, ease of screenshoots, ease of support, ease for two people huddled in front of one screen"
One could use that line of reasoning as justification for having Windows provide a *fully* locked down interface guaranteed to be identical on every system running a given version of Windows. Which would be utter hell even for those "office drones", because describing them like that ignores the very real point that each of them are individual humans with their own personal set of requirements for a user interface.
So yes, on the one hand I get the whole "keep it consistent" argument, but on the other hand there's a fine line between keeping it consistent for ease of training etc, and preventing users from being able to make reasonable adjustments that help them be more productive based on how they actually work as individuals, and whenever I hear comments like yours which, intentionally or not, imply there are lower classes of users who don't need/deserve to be given the ability to fine tune their working environments to suit their personal preferences, it makes me shudder. Because whether or not YOU intended it to come across that negatively, you can be damn sure that SOMEONE, typically in a position of authority within the corporate ladder, WILL be only too happy to enforce such restrictions without any thought for the effects it has on the minions they command to do their bidding.
"this is almost certainly MS giving users what MS think they need instead of what they actually want."
I'd suggest it's more like MS giving users what *MS* want to give the users - the likelihood of them actually taking any sort of time to stop and think about their users here, when they've got an entire graphic design team just champing at the bit to prove to the world just how awesome their ideas as to what a UI should look and behave like, feels rather slender.
I've not had any dealings with MS in this context, but I have ended up banging my head against a brick wall trying to get through to the designers of another UI I make heavy use of, just how user-hostile their proposed new design was going to be for users like me with colour vision deficiencies. I started off all nice and friendly, trying to be genuinely helpful in the feedback I was providing as part of the open beta test program they were running to - supposedly - elicit feedback like this, providing links to reference materials which could go into far more detail as to why certain colour choices were bad, etc. Only after those initial friendly efforts fell on completely deaf ears did my level of frustration/ire/anger start to rise, as it became increasingly clear with every subsequent interaction that they had no intention whatsoever of changing their design.
That's when I first realised that, in the battle between scientific facts, and the egos of designers who can't accept their vision for what a UI should look like might in any way be even slightly flawed, the latter is far more likely to come out the victor, and those of us negatively affected by the resultant shitshow of a UI which might be genuinely unuseable without the assistance of whatever vision-based adjustment are available within the host environment, and perhaps not even then, are just expected to put up and shut up, how dare we question the work of the graphic designer, for they are all-knowledgeable about such things whilst we are mere users who simply don't understand all the subtle nuances required to make a UI good and proper...
TL:DR: my opinion of modern UI designers now rarely lifts itself above "meh" level, and on those rare occasions when I stumble across a recently designed UI which actually *does* perform as a user interface, rather than merely looking nice in the static screengrabs used in the marketing blurb, it's now a genuine and pleasing surprise.
At work I've got a box of phone cables that came with some old PBX units, each of which has been supplied with a deliberately shortened catch lever which is just long enough to act as a latching mechanism when you plug the cable into the socket, but doesn't then protrude out at all beyond the face of the socket thus preventing easy removal.
As a way to deter random fiddling from people who shouldn't be able to get anywhere near the PBX once installed, if the addition of the screw-down socket cover wasn't enough of a deterrent, it works really well, but as a way to really annoy anyone who *does* need to move the cables from one socket to another, it works even better... So yeah, for these cables I've taken to just cutting the entire catch off and using them as latchless plugs, making sure to pay attention during system testing to make sure they remain in place.
And even though this kit follows the current trend for Lego generally not being cheap in absolute terms, given the way the article started off, I thought the price tag was going to be comfortably into the low 3-figure region - i.e. not even cheap by Lego standards. So to get all the way to the end and then be hit with the reveal that it's scraped in just under the 100 quid mark really was a surprise.
The fact that I *am* keeping them, and adding to the collection every so often by actively seeking out older maps, means that yes, I genuinely do treasure them as items in their own right, not merely as utilitarian things to help me get around that particular part of the world. After having been somewhat dismayed to learn that my parents had discarded our old street atlas of my hometown - something I'd spent countless hours poring over as a map-obsessed child - I was very pleased many years later to have been able to acquire an almost identical copy via the bay of E's. As a practical item it was next to useless, but as a reminder of how my place of birth looked like all those years ago (long before StreetView or publically available satellite/aerial imagery had captured any of it) the price I paid for it was a fraction of it's value to me, and it now has a special place in my collection alongside the growing pile of one inch series OS maps that are genuine works of art with a particular visual character later editions of OS mapping are lacking with their overly clean and precise appearance (though that's not to say I don't collect those as well...)
So if you had been able to go to the effort of trying to give/sell them on, you might have been surprised at the level of interest they received from people like me, because old maps, even ones that might not seem old in the grand scheme of things, really are quite collectible.
I'd say it's in part because of the lack of *off the shelf* variety, and in part because of how damned complicated modern systems now are.
Off the self variety is important, because whilst you're right that there is still a fair bit of variety both of hardware and OSs, the days of being able to walk into a computer store and be faced with a myriad of genuine choice, where most of the machines on display genuinely were different, are just a fading memory. These days you walk into a computer store (assuming you still have one that's open - another aspect of modern computing which differs from those early days of wonder) and whilst you're likely going to be faced with an even larger number of different machines vying for your attention, they'll almost all be nothing more than either a Windows or MacOS box at heart. Unless you put in the effort to go hunt down those alternative platforms, they might as well not exist.
And then there's the issue of complexity. In those early days, computers were simple enough that it was possible to understand every last aspect of how they worked, both at the hardware and the software levels. And this remained, to at least a suitable extent, true as systems started to become more complicated through the 16 and 32-bit eras. You could still reasonably grasp how it all hung together, how it all worked, and what effect doing *this* would have on *that*.
These days, despite all my decades of experience as an electronics and software engineer, I look at a modern PC and think "nope, might as well be a black box". That's not to say I no longer understand *anything* about what they're doing, because fundamentally much of it remains the same as it always was, even if the modern implementations are different. The problem I now have is similar to the problems I now have in my day job dealing with microcontrollers - back when I started on this career path in the mid/late 90s, I was dealing with devices whos *entire* reference manuals required fewer pages than just the chapter relating to *one* of the peripherals on the devices I'm using today. The fundamentals might be more or less the same, but the total amount of knowledge you now need to *fully* understand the entire system, how each part works, how it all interacts with one another, is so significantly higher than it used to be, that it's damn near impossible for one person to hold it all in their head.
And then there's the point that, back then, every single new release brought something genuinely impressive, something that had us going "wow". The pace of change was immense, and it was a thrilling time to be riding that change. These days it's harder to get even remotely interested in the latest news from Intel, nVidia etc about their performance upticks compared with the previous generation of hardware, because whilst things are still improving, the rate of change is generally not only slower, but we're also now at the point where most of us don't really need more than we've already got. Back then, even an extra couple of MHz of CPU power, an extra few hundred KB of disc space, or whatever, was a huge deal not only because of how significant a change it was relative to what we currently had, but also because of how limited we knew we were by what we currently had - we'd take *any* level of performance increase and still be thirsting for more, because we knew we weren't yet at the point where we could do all the stuff we imagined we could be doing.
And sure, some people today still have that feeling - e.g. look at the way those involved in AI are gobbling up as much memory and processing power as they can lay their hands on to facilitate the developments they're making. But for most of us that's no longer the case. Systems are now good enough, there's far less motivation for us to want to spend time and money on pursuing the relentless upgrade paths we once were eager to proceed along as quickly as the manufacturers could churn out new stuff to keep those paths going, and if we do upgrade it's more likely prompted by our current stuff simply being worn out and *needing* to be replaced, than because we've outgrown it and actively *want* to replace it.
Disagree, the information it contains is knowledge as to what *was* being presented to the public as truthful/accurate between the time the page was first uploaded through to the time it was withdrawn, regardless of how truthful/accurate any of it might have been...
Similarly with provisional releases of upcoming changes to information, where there may also be inaccuracies between what's proposed and what eventually makes it into the final version, there are reasons why making these non-current versions can still be useful to users. So as long as all non-current versions are marked up in a way which makes it clear they aren't the current version, then there shouldn't be any problem in allowing them to remain readily available rather than being hidden away in a myriad of different offline archives requiring more effort to access.
But he didn't, he lost access to the phone he STILL had in his possession, solely because Apple pushed an update rendering useless certain previously valid passwords...
Yes, as several of us pointed out in the comments for the original article, it's not unreasonable to use this as another real world example of where having good backups would have helped, but please let's not continue falling into the trap so many others did in those comments of focussing *solely* on the lack of any backups and ignoring the rather significant part Apple played in this user losing access to their data. Because this is a rather salient point - even if you ARE performing good backup policy, there's a good chance access to your data will STILL be at the mercy of the manufacturer of whatever system is required to access the backup.
So unless your backups are being made in a form that you can guarantee will remain readable no matter how badly someone else might mess things up, then are they actually backups at all?
True, we shouldn't necessarily refuse to *ever* implement new features just because we're overly precious about declaring something finished, but the general sentiment is sound.
So perhaps rather than thinking about it from the perspective of "finished" equating to "once we've done correctly implementing all the stuff we originally said we'd do, then that's it, no more changes ever", we should be thinking about it from the perspective of "finished" equating to "until we're done correctly implementing all the stuff we originally said we'd do, then we won't even think about adding more stuff".
That said, sometimes you really DO want to say "no more changes, THIS is exactly as much functionality as THIS code needs, anything more would be better provided as a seperate app/module/etc" - knowing when to stop adding more features is as important as ensuring all the features you've already got work correctly. Otherwise you end up with tools which used to be absolutely ideal for their original purposes being ruined because they've become bloated, overly complicated swiss army knives far removed from their core requirements - better to throw all of those new features into a new tool to placate those calling for the new features, whilst keeping the original tool lean and mean so that it can continue to fulfil the role it was designed for and which many of its users will still be relying on it being able to do.
No, it's still an anti-Russian aggression against Ukraine thing. Otherwise, as soon as you start considering where the weapons systems originated, as opposed to who they were sold/donated to and put to use by, then you open up a big old can of worms regarding who's fighting who.
Iran have supplied Russia with actual drones plus the IP needed to allow Russia to build their own versions, but Iran themselves are not attacking Ukraine, therefore anything we and other allied nations might do to support Ukraine here is similarly at the level of supplier rather than active participant in the war.
I'd suggest the timing of this announcement might have more to do with the corresponding news from Ukraine of Russia appearing to be getting more reliant on drones rather than cruise/ballistic/hypersonic/unstoppable wonderweapon types of missiles more often used earlier in the war.
Whilst I don't mind the responses pointing out how foolish he's been for not having these seemingly important photos backed up somewhere, to act as a reminder to anyone reading the comments just how important it is to have a good backup/recovery plan for stuff like this, like you I do mind how many of these responses seem to be solely focused on this aspect of the story, completely ignoring the IMO far more important point of this story...
...namely that Apple have, knowingly or otherwise, released an update which removes the ability to enter passwords if they contain a certain character previously deemed entirely acceptable to include in a password, and without (so it would appear) any forewarning to the user that once their phone reboots after applying this update, they're at risk of being locked out forever.
Because despite all the comments in those shaming posts along the lines of "well, if your phone had been lost/stolen/damaged even further, then you'd be in the same position you are now", the simple, inescapable fact is that he ISN'T in this position because one of those other things has happened. He still has his phone, it still works well enough to be accessible, and had it not been for the actions of Apple themselves in releasing an update which has bricked his phone, then he wouldn't be in this position now.
So yeah, sure, if he'd just backed up those photos then this would be a non-issue. But that doesn't mean the role Apple played in it becoming anything other than a non-issue for him should be so quickly glossed over.
"Standard Apple design philosophy"
FTFY - Apple may have pioneered the concept, but sadly far too many others have drunk the koolaid, hopped aboard that graphic-designer-led train, and foisted upon the world an ever increasing series of products with user interfaces which, not to put any sort of fine point on it, suck.
Depending on the nature of the feedback control loop, combined with the operational mode, used by the HVAC system, programming a setpoint some distance the "other side" of the desired temperature relatie to the current temperature *can* result in the room reaching that temperature faster than it would if the setpoint were set to that temperature.
From the control loop perspective, these will typically be designed to avoid overshoot, so as you get closer to the setpoint, the more the system will back off the level of heating/cooling effort applied to achieving the target temp. If the setpoint is placed t'other side of the desired temp, you're giving the control loop carte blanche to continue running at full chat up to and probably a little beyond that temp, before it starts to back off to avoid overshooting the temp it's been told to reach, as opposed to the temp you actually want it to reach...
From the operational mode perspective, if the system is designed to save energy, then it may not even attempt to hit the setpoint temp, and might be satisfied to simply settle on a temp within a few degrees of it - IIRC from back in the days when I used to design such systems, we had a default tolerance of +/- 2 deg.C for our eco mode setup - such that the time taken to reach the desired temperature may become infinite unless you similarly force the issue by programming a setpoint further above/below the desired temp such that *your* desired temp is one the system would have to reach/pass through on the way towards the range of temps *it* thought would fulfil your desires based on the setpoint value.
So whilst it's correct to say that changing the setpoint can't improve the fundamental capability of the system to change the temperature if it's running at full chat, it's not correct to ridicule the idea that doing so would result in the system being able to reach the desired temperature faster than if you just leave it at the desired temperature and let the system do its own thing. Some systems *can* be positively influenced by doing so, others might not be, so if someone has had first-hand experience of seeing beneficial effects of tweaking the setpoint, it'd take a brave person to suggest they're wrong unless they have intimate knowledge as to the characteristics of that particular system configured in that particular environment...
*Some* pilots will have already had experience with the Texan, *others* would have trained back in the Tucano days, and *none* will have had any experience (other than perhaps on exchange postings with other air forces) with the Wolverine variant, so either way there'd need to be at least a certain level of type training.
Whilst I agree it'd be easier to get a brand new pilot through training and qualified for anti-drone ops in a Wolverine than in a Typhoon, that's all they'd then be able to do, and right now the requirement for providing anti-drone defence doesn't justify creating a cadre of pilots capable of performing that role and that role only. So realistically it's going to come under the broader umbrella of air defence, which means the pilots who'd be flying anti-drone missions will need to be trained on Typhoon anyway...
