Maybe they did. Maybe they didn't. If their users are so unhappy with the change that they are making other arrangements, does it really matter? The result is still the same.
If you work in the business world you inevitably have to deal with MS Word documents and MS Excel spreadsheets and MS Powerpoint sludge.
This is a lot less true than it used to be. None of the day-to-day data that I deal with has been in any of those formats for a long time.
The sad thing is, it still only needs one or two exceptions -- say, exporting a spreadsheet to send to your accountant or a contract for review and markup by your lawyers -- to make it worth the cost of buying MS rather than risking data loss in translation. Fortunately, for us it's only things like legal/finance work where any avoidable risk is highly undesirable because of the potential costs of even small errors, which also means it's only MS Office where this applies. Keeping around the odd pre-365 copy we already bought is sufficient here.
Although it is an annual rent which is going to turn off a lot of people I now consider it a regular business related sense such as dry cleaning or a commute-capable car or for that matter taxes on income. If you want to be a grown up there are things you have to pay for.
From a business point of view, what it costs is just a business expense and is either worth it or it isn't.
The bigger reason we won't rent software for anything truly essential to our business operations is that it can be changed, made more expensive, or even entirely turned off, at any time, according to nothing but the whims of the software developer. Given the track record of the software industry collectively and of some of these big name developers in particular for shipping updates that their customers don't actually want, interrupting functionality due to downtime, or even discontinuing entire product lines that are no longer strategically convenient, that's far too much risk for business to take with anything that actually matters, IMHO.
Interesting, thanks. That's the second report I've seen of Dell still selling machines with 7 preinstalled, so maybe they've somehow forced MS to back off the policy of only supplying 7 via downgrade rights by now.
To answer your question: neither, we just kept a careful eye on exactly which KBs were related to Windows 10 or other unwanted junk like the backported telemetry, and avoided installing those options at update time. Seemed to work OK for us without relying on anything else, though I expect the tools you mentioned were a useful alternative for some.
Thanks for the link. I wonder how they're getting away with that one. Someone else mentioned buying a new Dell with 7 preinstalled last week, so I'm assuming this isn't just a database glitch or similar.
I don't really see Linux as a viable competitor for the desktop business market, at least not in the typical distro-based model we see today.
For one thing, the long tail of business software applications isn't there. The chicken and egg problem has never been resolved.
Even if the applications were available, the admin tools and usability aren't there either.
With my "running a business" hat on, I don't have time for messing around. I buy computers to get stuff done, and I need them to just work, from hardware support through admin tasks to using the real business software. Current Linux distros are so far from just working in this context that I see no realistic prospect of getting there before the 2020 Windows 7 cliff.
A more promising long-term option involving Linux might be using the kernel and related tools as a reasonably solid foundation but then building a totally new style of UI on top. Think Android or maybe SteamOS. However, as Android has shown, it takes a while to establish such a platform and build the ecosystem, and the business world is much more demanding in its software requirements than the consumer world where Android mostly lives.
Really? IME Apple's reputation for prematurely obsoleting hardware through OS updates is worse than probably any other major brand. It certainly seems to be around these parts. Some of that might be earned by the way they keep borking iOS updates for mobile devices, but I've also heard a few horror stories about the desktop OS being worse after upgrading than it used to be, even on not-that-old MacBooks.
That said, I was actually talking about Apple more generally, not just about the longevity of their systems. Almost everything they've released, both software and hardware, for at least the past couple of years seems to have ranged from mediocre to downright disappointing. I work in the world of small businesses, where quite a few places run Apple instead of Windows, and right now they appear to be little happier with their situation than we are with ours in Microsoft land.
Interesting. I wondered whether the big suppliers would accept that constraint or force MS to allow them to continue supplying what a lot of their customers actually want to buy. Last I saw, the official MS policy was that purchasers would now have to exercise some variation of downgrade rights if they wanted Windows 7 on a new PC.
That said, at least on the Dell UK site I'd be using here and the Dell US site, I can't immediately find any options to buy anything in their workstation or laptop ranges with Windows 7 preinstalled any more. Where did you see that possibility?
We did prevent this. We're still quite happily running on Windows 7, even on machines purchased just a few months ago.
Of course, Microsoft has also rigged the system so you can no longer buy a new PC with Windows 7 preinstalled. So now we're not buying any new PCs for a while and will make do with what we've got. We're assuming something has to give before the 2020 cliff, whether it's MS providing a version of Windows 10 without the major downsides for non-enterprise customers, Apple getting their act together again so MacBooks are a viable alternative, or some other platform becoming more attractive to software developers so alternatives to the key programs we depend on are available elsewhere.
Thanks for the warning, but as someone who doesn't routinely commit robbery or grand theft auto, I'll take my chances.;-)
Being serious, I have never actually had this happen to me in however many decades I've been using these things now. Maybe it's just that I tend to keep my phone in a jacket pocket or bag rather than somewhere I'm going to sit on it...
Good advice, next time I go to a building fire I'll be sure to take my old Nokia with me.
As stubborn old guy with Nokia phone who has called emergency services recently, can confirm this works.
Everyone keeps telling me I need a smartphone, but as someone who mainly does use his phone for calls or maybe the occasional text message, I've never really seen the point. They're bigger, less reliable, riddled with security and privacy issues, and often can't even hold a single day of charge. Of course, being a Slashdot-reading geek, when I need to do something more demanding than my trusty Nokia can do, I've often got something more suitable like a laptop with me anyway.
Ironically, I've been considering getting a OnePlus 5 (because decent spec + dual SIM could be useful for me) but was holding off over concerns about new phone reliability, plus the usual security and privacy issues. This sort of story, on top of the reports about jelly because they can't even put the basic hardware together the right way, isn't exactly turning me into an enthusiastic customer...
I have been running software businesses and working in fields where high reliability is important for many years, and we have sometimes achieved things that (as far as I'm aware) no-one else working in the same area has, in part thanks to this careful and systematic approach. This is why I have quite strong views on this issue.
Of course, just because we've done OK, that doesn't mean I can't encourage other developers and their customers to share in the benefits as well. Nor, sadly, does it make me immune to the consequences when I use or depend on software written by people who didn't. It's in everyone's interests for the software development industry as a whole to become more aware of some of these ideas and up its game.
Well, that's not entirely true. To summarise my arguments from this discussion:
1. There is ample evidence of real and serious costs due to software failures. The NHS fiasco is a clear example, and hardly the only one in recent times.
2. There is ample evidence that we can build high quality software if we are willing to adopt alternative methods and tools. Many safety-critical areas already do. (Note that this point has no reference to cost.)
3. There are techniques that can self-evidently be adopted with negligible cost and still make some improvement. C, and by extension C++, are languages that have many fundamentally dangerous elements that have literally no benefit, and which are often avoided by more modern languages.
(To expand on this point with a few more examples, there is no need for null-by-default, or ubiquitous types like enumerations and void pointers that aren't type safe, or standard library functions to deal with null-terminated strings that have no mechanism to prevent buffer overruns, or allowing silent confusion of = and == in a conditional expression. These things have caused countless bugs over the years, that would be entirely avoidable in new software today.)
4. So far, we have established that serious problems are caused by poor software quality, that much better quality is achievable without reference to cost, and that some improvements can be achieved with negligible cost. What remains is the question of what the cost/benefit curve looks like between those established extremes. How far to go for any given software development project would then necessarily depend on the nature of the software and the risks associated with its failure.
5. The human cost of software failure may be extremely high in individual cases and is certainly high in aggregate, but the developers of that software are often relatively unaccountable for those failures. One way to promote improvements in quality is to increase that accountability to more realistic levels in line with other products and services. This would encourage developers to experiment with better development processes and tools rather than staying in their comfort zone, which in light of the above is not an unreasonable strategy if our goal is to reduce those human costs.
The insurance industry is based on estimating risk. Sometimes they get it spectacularly wrong and lose huge amounts of money following a catastrophic event. Sometimes they get it subtly wrong due to not fully understanding the situation, and lose still quite large amounts of money without really understanding why. Those costs are still there, whether or not the industry collectively knows about them or has any awareness of better alternatives.
And of course, to the insurance industry, even a human life is just a dollar value, and anything you can't be sued for has little if any value at all. People with ethics might take a different view.
That's not entirely fair. Among other visible changes, Windows 7 had much better support for later hardware than Windows XP, faster boot times, and UI improvements like the task bar and jump list arrangement and the various preview-like features. It also introduced new networking protocols, security features, performance improvements and other internal or developer-facing benefits. The cost was a loss of compatibility with some older hardware because of the changes in the driver model, but overall it was a significant win for most users.
The sad thing is that reportedly Windows 10 would bring many similar incremental improvements in terms of better hardware support, improved security, and so on. It's just that the costs in terms of reliability, security, privacy and usability are so much higher that many potential users just aren't interested.
We have some reasonable ideas for producing very high quality, money-no-object software, I agree. However, in most cases, money is going to be a relevant factor. Unless we're talking about things like safety or privacy issues, where significant and unfixable physical or mental harm may result, the question is often going to be a trade-off between accepting some level of risk voluntarily in return for keeping costs down.
I don't think we have as much experience as an industry with this very wide middle ground yet. In particular, I think there are a lot of improvements that could potentially be implemented at very modest extra costs and with significant resulting benefits, but relatively few developers are even aware of them and so relatively little software is being developed using them to learn about what does and doesn't work both in absolute terms and in terms of cost-effectiveness.
Mainstream programming is bad because of bad programmers.
Sometimes, yes, but mainstream programming is also worse than it could be because generally decent programmers who would like to do a good job aren't necessarily aware of the tools and methods available to help them do so.
This isn't a failure of skill or attitude, it's a failure of education. That problem can be solved, but the first step to solving a problem is acknowledging that it exists.
Actually, it turned out that the XP issue was mostly a red herring, and most of the NHS systems affected were running Windows 7 anyway. They were within a regular support period, and the relevant bug fix had been available for a few weeks. Unfortunately, as so often seems to be the case, that fix hadn't been installed in timely fashion, leaving the systems vulnerable when the attack hit.
But all of that is irrelevant to the main point here. WannaCry spread by using the EternalBlue exploit, which is based on a remote code execution vulnerability on receipt of data in a certain format from an attacker. That vulnerability was present -- and, controversially, known to certain people but not disclosed to Microsoft -- long before the patch was available. Obviously a more defensively structured system would not admit such a vulnerability or need patching in the first place, and that is exactly the sort of area that formal methods can help with.
There is absolutely no reason that C/C++ cannot have a "safe" mode and maintain the familiar and relatively sane syntax that millions of software professionals know.
Draconian punishment has a poor record of effectiveness. We used to execute people for stealing bread, yet people still stole bread.
I don't think that's a fair comparison. People stole bread anyway because they needed to eat to survive. Businesses tend to optimise for whatever is cheapest given their other constraints, and so typically they do respond to making undesirable behaviours more expensive. Indeed, short of piercing the corporate veil and imposing criminal sanctions on the senior executives personally, financial incentives are arguably the only thing to which businesses will reliably respond.
Additional costs will be passed on to consumers, who are unwilling to pay for it.
You return to this point multiple times, but the underlying assumption is that working more carefully and so reducing failures in the longer term will be significantly more expensive. I don't see much evidence anywhere in this discussion to support that assumption, though. Nor is it self-evident that, to pick a very simple example, coding in a language that requires nullability to be explicitly declared would take significantly longer than coding in a nullable-by-default language, other things being equal. (Personally I would be comfortable extending that same argument to much more powerful types of case analysis as well, but for now I'll stick with an example that will be familiar to almost everyone.)
As for security being a significant threat, the problem here is that humans are very bad at evaluating the risk from low-probability, high-damage events. "It would never happen to me," said no-one who had ever actually been the victim of identity theft and spent the next 3-6 months of their lives trying to recover the financial losses and repair their reputation, yet most people don't spend even a very small amount of time and money to check their credit record every now and then.
Similarly, I suspect most non-geeks have little idea how much damage might be caused by some of these security and privacy failures, and are often harmed without even realising it. To pick a familiar analogy again, consider this: do you know what proportion of your car insurance premium is only there because of insurance fraud? I don't; I have no data to determine a precise figure. But certainly insurance fraud appears to be a significant problem, because from time to time insurance companies mention figures like 5% or 10% changes in premiums just in response to specific trends in fraudulent claims. Now extend that principle to every software system you depend on, knowingly or unknowingly.
Why replace it at all? Why not just introduce new features into the c compilers, language, and libraries that just identify and correct bad patterns and practices?
Because at some point, you can't keep building skyscrapers on shaky foundations. If the underlying programming model in your language doesn't provide some useful guarantee in relation to the correctness of your code, there is only so much you can do. Even modern C and C++ are very far into the not-providing-guarantees area compared to many other languages that have been designed with correctness in mind and the benefit of decades more collective experience in the industry.
Until then, the hurdle of learning a new syntax and switching between them as you maintain existing C code and write new Rust code is too much of a productivity hit for most developers working in a commercial environment.
People have been making this argument forever, yet today a huge amount of commercial code is written in languages that just a few years ago didn't have a large supporting ecosystem if they even existed at all. Apparently the millions of professional programmers now writing code in those languages managed to make the switch just fine, and the organisations they work for managed to find the time and money to support those switches without their projects failing.
In the specific context of languages that support newer and safer ways to build software, maybe developers who can't or won't learn to use better tools and techniques and so to achieve better results simply need to find another career, just like obsolete workers with out-of-date skills in many other professions.
Slashdot Mirror
You did it wrong.
Maybe they did. Maybe they didn't. If their users are so unhappy with the change that they are making other arrangements, does it really matter? The result is still the same.
That sounds pretty harsh. What exactly do "have to buy" and "force to upgrade" mean here?
If you work in the business world you inevitably have to deal with MS Word documents and MS Excel spreadsheets and MS Powerpoint sludge.
This is a lot less true than it used to be. None of the day-to-day data that I deal with has been in any of those formats for a long time.
The sad thing is, it still only needs one or two exceptions -- say, exporting a spreadsheet to send to your accountant or a contract for review and markup by your lawyers -- to make it worth the cost of buying MS rather than risking data loss in translation. Fortunately, for us it's only things like legal/finance work where any avoidable risk is highly undesirable because of the potential costs of even small errors, which also means it's only MS Office where this applies. Keeping around the odd pre-365 copy we already bought is sufficient here.
Although it is an annual rent which is going to turn off a lot of people I now consider it a regular business related sense such as dry cleaning or a commute-capable car or for that matter taxes on income. If you want to be a grown up there are things you have to pay for.
From a business point of view, what it costs is just a business expense and is either worth it or it isn't.
The bigger reason we won't rent software for anything truly essential to our business operations is that it can be changed, made more expensive, or even entirely turned off, at any time, according to nothing but the whims of the software developer. Given the track record of the software industry collectively and of some of these big name developers in particular for shipping updates that their customers don't actually want, interrupting functionality due to downtime, or even discontinuing entire product lines that are no longer strategically convenient, that's far too much risk for business to take with anything that actually matters, IMHO.
Though rumour has it that it's something of a legend among Japanese business executives.
Interesting, thanks. That's the second report I've seen of Dell still selling machines with 7 preinstalled, so maybe they've somehow forced MS to back off the policy of only supplying 7 via downgrade rights by now.
To answer your question: neither, we just kept a careful eye on exactly which KBs were related to Windows 10 or other unwanted junk like the backported telemetry, and avoided installing those options at update time. Seemed to work OK for us without relying on anything else, though I expect the tools you mentioned were a useful alternative for some.
Thanks for the link. I wonder how they're getting away with that one. Someone else mentioned buying a new Dell with 7 preinstalled last week, so I'm assuming this isn't just a database glitch or similar.
I don't really see Linux as a viable competitor for the desktop business market, at least not in the typical distro-based model we see today.
For one thing, the long tail of business software applications isn't there. The chicken and egg problem has never been resolved.
Even if the applications were available, the admin tools and usability aren't there either.
With my "running a business" hat on, I don't have time for messing around. I buy computers to get stuff done, and I need them to just work, from hardware support through admin tasks to using the real business software. Current Linux distros are so far from just working in this context that I see no realistic prospect of getting there before the 2020 Windows 7 cliff.
A more promising long-term option involving Linux might be using the kernel and related tools as a reasonably solid foundation but then building a totally new style of UI on top. Think Android or maybe SteamOS. However, as Android has shown, it takes a while to establish such a platform and build the ecosystem, and the business world is much more demanding in its software requirements than the consumer world where Android mostly lives.
Really? IME Apple's reputation for prematurely obsoleting hardware through OS updates is worse than probably any other major brand. It certainly seems to be around these parts. Some of that might be earned by the way they keep borking iOS updates for mobile devices, but I've also heard a few horror stories about the desktop OS being worse after upgrading than it used to be, even on not-that-old MacBooks.
That said, I was actually talking about Apple more generally, not just about the longevity of their systems. Almost everything they've released, both software and hardware, for at least the past couple of years seems to have ranged from mediocre to downright disappointing. I work in the world of small businesses, where quite a few places run Apple instead of Windows, and right now they appear to be little happier with their situation than we are with ours in Microsoft land.
Interesting. I wondered whether the big suppliers would accept that constraint or force MS to allow them to continue supplying what a lot of their customers actually want to buy. Last I saw, the official MS policy was that purchasers would now have to exercise some variation of downgrade rights if they wanted Windows 7 on a new PC.
That said, at least on the Dell UK site I'd be using here and the Dell US site, I can't immediately find any options to buy anything in their workstation or laptop ranges with Windows 7 preinstalled any more. Where did you see that possibility?
Or you can get the parts, but only from an approved dealer at X times the market price otherwise.
If you don't think vehicle manufacturers with increasing reliance on software are salivating at this prospect, you're crazy.
Fortunately, the right-to-repair movement does seem to be gaining some momentum, and may win first.
We did prevent this. We're still quite happily running on Windows 7, even on machines purchased just a few months ago.
Of course, Microsoft has also rigged the system so you can no longer buy a new PC with Windows 7 preinstalled. So now we're not buying any new PCs for a while and will make do with what we've got. We're assuming something has to give before the 2020 cliff, whether it's MS providing a version of Windows 10 without the major downsides for non-enterprise customers, Apple getting their act together again so MacBooks are a viable alternative, or some other platform becoming more attractive to software developers so alternatives to the key programs we depend on are available elsewhere.
Thanks for the warning, but as someone who doesn't routinely commit robbery or grand theft auto, I'll take my chances. ;-)
Being serious, I have never actually had this happen to me in however many decades I've been using these things now. Maybe it's just that I tend to keep my phone in a jacket pocket or bag rather than somewhere I'm going to sit on it...
Good advice, next time I go to a building fire I'll be sure to take my old Nokia with me.
As stubborn old guy with Nokia phone who has called emergency services recently, can confirm this works.
Everyone keeps telling me I need a smartphone, but as someone who mainly does use his phone for calls or maybe the occasional text message, I've never really seen the point. They're bigger, less reliable, riddled with security and privacy issues, and often can't even hold a single day of charge. Of course, being a Slashdot-reading geek, when I need to do something more demanding than my trusty Nokia can do, I've often got something more suitable like a laptop with me anyway.
Ironically, I've been considering getting a OnePlus 5 (because decent spec + dual SIM could be useful for me) but was holding off over concerns about new phone reliability, plus the usual security and privacy issues. This sort of story, on top of the reports about jelly because they can't even put the basic hardware together the right way, isn't exactly turning me into an enthusiastic customer...
I have been running software businesses and working in fields where high reliability is important for many years, and we have sometimes achieved things that (as far as I'm aware) no-one else working in the same area has, in part thanks to this careful and systematic approach. This is why I have quite strong views on this issue.
Of course, just because we've done OK, that doesn't mean I can't encourage other developers and their customers to share in the benefits as well. Nor, sadly, does it make me immune to the consequences when I use or depend on software written by people who didn't. It's in everyone's interests for the software development industry as a whole to become more aware of some of these ideas and up its game.
Well, that's not entirely true. To summarise my arguments from this discussion:
1. There is ample evidence of real and serious costs due to software failures. The NHS fiasco is a clear example, and hardly the only one in recent times.
2. There is ample evidence that we can build high quality software if we are willing to adopt alternative methods and tools. Many safety-critical areas already do. (Note that this point has no reference to cost.)
3. There are techniques that can self-evidently be adopted with negligible cost and still make some improvement. C, and by extension C++, are languages that have many fundamentally dangerous elements that have literally no benefit, and which are often avoided by more modern languages.
(To expand on this point with a few more examples, there is no need for null-by-default, or ubiquitous types like enumerations and void pointers that aren't type safe, or standard library functions to deal with null-terminated strings that have no mechanism to prevent buffer overruns, or allowing silent confusion of = and == in a conditional expression. These things have caused countless bugs over the years, that would be entirely avoidable in new software today.)
4. So far, we have established that serious problems are caused by poor software quality, that much better quality is achievable without reference to cost, and that some improvements can be achieved with negligible cost. What remains is the question of what the cost/benefit curve looks like between those established extremes. How far to go for any given software development project would then necessarily depend on the nature of the software and the risks associated with its failure.
5. The human cost of software failure may be extremely high in individual cases and is certainly high in aggregate, but the developers of that software are often relatively unaccountable for those failures. One way to promote improvements in quality is to increase that accountability to more realistic levels in line with other products and services. This would encourage developers to experiment with better development processes and tools rather than staying in their comfort zone, which in light of the above is not an unreasonable strategy if our goal is to reduce those human costs.
The insurance industry is based on estimating risk. Sometimes they get it spectacularly wrong and lose huge amounts of money following a catastrophic event. Sometimes they get it subtly wrong due to not fully understanding the situation, and lose still quite large amounts of money without really understanding why. Those costs are still there, whether or not the industry collectively knows about them or has any awareness of better alternatives.
And of course, to the insurance industry, even a human life is just a dollar value, and anything you can't be sued for has little if any value at all. People with ethics might take a different view.
"Sir, please step out of the vehicle. You have 20 seconds to comply."
That's not entirely fair. Among other visible changes, Windows 7 had much better support for later hardware than Windows XP, faster boot times, and UI improvements like the task bar and jump list arrangement and the various preview-like features. It also introduced new networking protocols, security features, performance improvements and other internal or developer-facing benefits. The cost was a loss of compatibility with some older hardware because of the changes in the driver model, but overall it was a significant win for most users.
The sad thing is that reportedly Windows 10 would bring many similar incremental improvements in terms of better hardware support, improved security, and so on. It's just that the costs in terms of reliability, security, privacy and usability are so much higher that many potential users just aren't interested.
We have some reasonable ideas for producing very high quality, money-no-object software, I agree. However, in most cases, money is going to be a relevant factor. Unless we're talking about things like safety or privacy issues, where significant and unfixable physical or mental harm may result, the question is often going to be a trade-off between accepting some level of risk voluntarily in return for keeping costs down.
I don't think we have as much experience as an industry with this very wide middle ground yet. In particular, I think there are a lot of improvements that could potentially be implemented at very modest extra costs and with significant resulting benefits, but relatively few developers are even aware of them and so relatively little software is being developed using them to learn about what does and doesn't work both in absolute terms and in terms of cost-effectiveness.
Mainstream programming is bad because of bad programmers.
Sometimes, yes, but mainstream programming is also worse than it could be because generally decent programmers who would like to do a good job aren't necessarily aware of the tools and methods available to help them do so.
This isn't a failure of skill or attitude, it's a failure of education. That problem can be solved, but the first step to solving a problem is acknowledging that it exists.
Actually, it turned out that the XP issue was mostly a red herring, and most of the NHS systems affected were running Windows 7 anyway. They were within a regular support period, and the relevant bug fix had been available for a few weeks. Unfortunately, as so often seems to be the case, that fix hadn't been installed in timely fashion, leaving the systems vulnerable when the attack hit.
But all of that is irrelevant to the main point here. WannaCry spread by using the EternalBlue exploit, which is based on a remote code execution vulnerability on receipt of data in a certain format from an attacker. That vulnerability was present -- and, controversially, known to certain people but not disclosed to Microsoft -- long before the patch was available. Obviously a more defensively structured system would not admit such a vulnerability or need patching in the first place, and that is exactly the sort of area that formal methods can help with.
There is absolutely no reason that C/C++ cannot have a "safe" mode and maintain the familiar and relatively sane syntax that millions of software professionals know.
And yet no such "safe" mode exists. QED.
Draconian punishment has a poor record of effectiveness. We used to execute people for stealing bread, yet people still stole bread.
I don't think that's a fair comparison. People stole bread anyway because they needed to eat to survive. Businesses tend to optimise for whatever is cheapest given their other constraints, and so typically they do respond to making undesirable behaviours more expensive. Indeed, short of piercing the corporate veil and imposing criminal sanctions on the senior executives personally, financial incentives are arguably the only thing to which businesses will reliably respond.
Additional costs will be passed on to consumers, who are unwilling to pay for it.
You return to this point multiple times, but the underlying assumption is that working more carefully and so reducing failures in the longer term will be significantly more expensive. I don't see much evidence anywhere in this discussion to support that assumption, though. Nor is it self-evident that, to pick a very simple example, coding in a language that requires nullability to be explicitly declared would take significantly longer than coding in a nullable-by-default language, other things being equal. (Personally I would be comfortable extending that same argument to much more powerful types of case analysis as well, but for now I'll stick with an example that will be familiar to almost everyone.)
As for security being a significant threat, the problem here is that humans are very bad at evaluating the risk from low-probability, high-damage events. "It would never happen to me," said no-one who had ever actually been the victim of identity theft and spent the next 3-6 months of their lives trying to recover the financial losses and repair their reputation, yet most people don't spend even a very small amount of time and money to check their credit record every now and then.
Similarly, I suspect most non-geeks have little idea how much damage might be caused by some of these security and privacy failures, and are often harmed without even realising it. To pick a familiar analogy again, consider this: do you know what proportion of your car insurance premium is only there because of insurance fraud? I don't; I have no data to determine a precise figure. But certainly insurance fraud appears to be a significant problem, because from time to time insurance companies mention figures like 5% or 10% changes in premiums just in response to specific trends in fraudulent claims. Now extend that principle to every software system you depend on, knowingly or unknowingly.
Why replace it at all? Why not just introduce new features into the c compilers, language, and libraries that just identify and correct bad patterns and practices?
Because at some point, you can't keep building skyscrapers on shaky foundations. If the underlying programming model in your language doesn't provide some useful guarantee in relation to the correctness of your code, there is only so much you can do. Even modern C and C++ are very far into the not-providing-guarantees area compared to many other languages that have been designed with correctness in mind and the benefit of decades more collective experience in the industry.
Until then, the hurdle of learning a new syntax and switching between them as you maintain existing C code and write new Rust code is too much of a productivity hit for most developers working in a commercial environment.
People have been making this argument forever, yet today a huge amount of commercial code is written in languages that just a few years ago didn't have a large supporting ecosystem if they even existed at all. Apparently the millions of professional programmers now writing code in those languages managed to make the switch just fine, and the organisations they work for managed to find the time and money to support those switches without their projects failing.
In the specific context of languages that support newer and safer ways to build software, maybe developers who can't or won't learn to use better tools and techniques and so to achieve better results simply need to find another career, just like obsolete workers with out-of-date skills in many other professions.