Meta, Microsoft SQL Server make strange bedfellows on a couch of cyber-pain When two stories from opposite ends of the IT universe boil down to the same thing, sound the klaxons. At the uber-fashionable AI end of tech, Meta has grudgingly complied with a ruling not to feed European social media crap into its training data. Meanwhile, in the industrial slums, 20 percent of running Microsoft SQL Server …
..the response of big tech to proposed regulation of data and IT security? They'd spend their vast lobbying and legal budgets to block any such obligation, because unlike the food supply chain, the digital supply chain is dominated by vast firms that make huge profits giving them the resources to go lobbying, and hire top dollar lawyers. And as important as the means, their motive is simplky that they regard all forms of regulation and consumer rights as an unwelcome hinderance to their operations.
Looking at what a shallow swamp of vested self-interest legislatures are now in most countries, who will the politicians listen to - the forked tongues of big business bearing gifts, or the broader public interest?
> unlike the food supply chain, the digital supply chain is dominated by vast firms
I think that you will find (if you're less lazy than I, and look up the ownership network) that there are a few very large food companies that comprise quite a large proportion of the UK food supply chain. Associated British Foods, and the Arla Group come to mind immediately.
In most sectors there's large companies - but not with the relative sector dominance we see in software and tech. Moreover, during most of the hundred year odd journey of food regulation there weren't any companies of that scale.
I might also add that ABF aren't making the huge margins of a large software house, nor do they engage in the heavy and expensive lobbying the tech sector indulges itself in. Take a look at top corporate lobbying spend, and it always topped by tech, pharma, and energy. Food growers or processors don't feature in any of the free to web sources I've found.
I up voted you, but the American food system is, in fact, dominated by a few enormous agri-business conglomerates who have engaged in decades of regulatory capture to ensure that reforming the food system is well-nigh impossible. As a result, finding cheap, high-calorie, low-nutrient ultra-processed food in America is incredibly easy, while finding the sort of high-quality food that Europeans take for granted is more difficult. Capitalism and regulatory capture have led to the proliferation of both junk food and junk technology (and junk media), and any call for restraint or reform is denigrated as job-killing regulation or worse (gasp), socialism.
As an actual American I'm going tp burst the bubble of half-truths about what Europeans (wrongly) think of the American food system and how you are deciding to misinterpret statistics. Lies, more lies, and statistics.
My mate constantly got food poisoning. I, on the other hand, have only had food poisoning once in the past 15 years and it was my own hand (ate my own food that I failed to notice the condition of).
The difference? He constantly ate from buffets.
The reason Americans get more food poisoning is NOT from the food source quality, it is from HANDLING and PREPARATION. Buffets and pre-prepared grab-and-go food is far more common in the U.S. than Europe and (as I'm sick and tired of complaining to various managements about) 1/3 of the time the food is served or kept at below proper temperature. I'm so sick of eating 'cold' (to me) food around here I can't stand it. I *constantly* have to, consciously, ask for food "extra hot" just to get the food up to ' warm' temperature. A well-known sandwich shop chain will actually serve me patties that are still cold in the middle unless I rile them for "extra extra hot"...and then it comes out warmed (but still not hot!).
My mate kept going back to the same late night buffet for chicken until he got sick for the third time and I razzed him for continuing the same self abuse pattern.
It's the cheap-ass crap management, poor training, cutting corners, poor hygiene, low temperatures, not willing to throw out expired food, etc, that is causing all too much of three food poisoning in America.
The premise that software is "spoiled" when it is past an arbitrary "good before" date is a preposterous preposition.
Food (biology) and software are not the same, even though there are striking similarities on a meta-analysis level. The primary reason for end dates on (commercial) software is the lack of income it generates. It is seen as a burden. Why support a good-enough system when you can make a boatload of money selling the latest-and-greatest and obsoleting the previous incarnation?
But in a wider software garden, the comparison and conclusions fall apart. A major part of software is based on not-for-profit created software. The fact that some make a living out of that does not change that. An enormous amount of code must be changed, today, because there are incorporations, within that code, of unsupported parts. Maybe not unsupported as a library, but there is a body of code that nobody looks at in depth. It is simple used and reused. This body of code is, by all practical means and definitions, unsupported. The conclusion would be that we must rip it out and put in something new.
The problem we have is one of economics in the software world. It is cheaper to abandon than to support. That goes for commercial just as for non-commercial. Like, who supports the volunteer in the corner who simply solved an interesting problem? When (s)he stops, will the world come to an end?
I think you've missed the point, which isn't that software is perishable, it is that software design and implementation is barely regulated, and that is a major contributor to putting data at risk.
In any reasonably well regulated sector (could be food, could be product safety, could be weights & measures, etc) the system imposes costs on suppliers, but delivers net benefits for consumers. A similar situation is the right to repair regulations for manufacturers. Software design and implementation exists as a wild west sector where the nearest statement of consumer rights is caveat emptor, that's a shocking anomaly, and needs to change.
How software and data can be properly regulated, that's a big challenge because of the complexity (and it still won't get around all forms of cyber crime). The usually extremely profitable software houses see it as "uneconomic" to properly write or maintain software, and they've got away with it for half a century. The motor industry used to be like this too. But it now has a shed-load of regulations around product design, compliance, sales, support, safety recalls, & spares - you can argue the toss about compliance, but there's rules, there's consequences. In the software world there's a circa $1 trillion a year market that thinks it has no obligations other than its own best interests.
But the point is, software is perishable. There are two terms accompanying software that make it perishable: bitrot and (planned) obsolescence.
The former happens when all knowledge vanishes and you work in the "it-works-but-I-don't-know-why" territory until you reach "it-does-no-longer-work". The latter is the usual problem with commercial software. Also, the latter translates into the former in due time.
I would argue there is one other. The software in question has had so many modifications, plug-ins, and other bits stuck to it over the years it becomes nigh unusable. Any update or minor fix causes a cascade of unexpected and unknowable new bugs to take care of, each one with it's own cascade ready to go. Now you have a business running on software that shouldn't be running anywhere, with all that is left is to take it for a long walk to a farm somewhere.
Of course, that's not what the software company says. They can keep it going forever, no worries. However, they do expect us to pay for new features, then the fixes for the bugs in the new feature, then the the fixes for the bugs in other parts of the software caused by fixing the bugs caused by the new feature, then the fixes for bugs caused by the fixes for the bugs caused by the fixes for the bugs caused by the new feature....
Not to worry, though, thy think they have a new feature that will make the software at least 12% better, as soon as we pay them for it...
Ripping and replacing working code is not without cost. It's not for nothing that we keep saying "If it ain't broke, don't fix it."
Just because nobody's updated a library for a long time doesn't mean it's in need of updates; it may mean it's not in need of updates. Your "unsupported" might be someone else's "finished".
"Just because nobody's updated a library for a long time doesn't mean it's in need of updates; it may mean it's not in need of updates. Your "unsupported" might be someone else's "finished"."
Well, so long as a competent authority will sign off the example library as properly secure and without vulnerabilities, that'll be fine. We use similar approaches in automotive, aviation, product safety, etc why should software continue to rely on the idea that because nothing has so far gone wrong everything is awesome?
Looking at the routine data breaches at large corporations, they all are fully paid up to your mantra of "if it ain't broke, don't fix it". For them security vulnerabilities are not evidence that the code or design is broken. And why would they - it's mostly customers data being spilled.
Name a competent authority.
Tell me if this is in need of a fix. Apart from a documentation update this year it was last updated in 2016: https://repo.or.cz/nvi.git
My view is that it comes under the heading of "finished", "complete" or whatever you might wish to call it as opposed to vim which never seems to be finished.
Software that is finished? That would mean a program that has been proven to be valid. But that is not practically possible because that only works for small programs (for some arbitrary value of small).
Finished in the meaning "we stopped working on it because it works as expected". That is more likely. But that is hardly a universal or correct measure of "finished" in terms of CS validity. Therefore, it can be "finished" and full of bugs and daemons. Hell awaits when the program/library is used in a new project and may expose old wounds or hidden defects.
A competent authority is one who has formally demonstrated the necessary capabilities, and in this context it also needs somebody prepared to amend code if needed, akin to the approvals process for aircraft. As for your link, I wouldn't have scooby about it, but I don't need to, in the same way you wouldn't have a clue about the code I wrote or used when I was actually doing such stuff (many years ago).
We make car makers jump through the most unbelievable hoops for homologation. For product safety standards we require that makers use recognised standards, and have their compliance checked by approved conformity assessment bodies, and then there's regulators to check and enforce that they are compliant. The same for pharmaceuticals. With software increasingly at the heart of genuinely safety related systems and equipment, or supposedly safely handling our data, it's time the whole industry grew up. Yet software and IT in general continues to operate according to no adequate quality infrastructure. Push the code out through a sphincter, and when you've got a big enough pile on the floor, shovel it out on unsuspecting users. Then maintain that any faults aren't your fault, and that the code is a secret sauce that nobody else can touch.
Quality, security, maintenance? Choose any none.
"in the same way you wouldn't have a clue about the code I wrote or used when I was actually doing such stuff (many years ago)."
Many years ago I, too, was writing code. I was also, from time to time, installing latest versions of commercial S/W. If anything was going to go wrong with the running systems those were the most likely situations.
Such as the version requiring just a bit more memory but enough to push it into thrashing when presented with a live workload. (At least I got the memory upgrade I'd been requesting.)
And the long hours while the new version of an ERP was doing a database reorg while thinking "If this runs out of space we're never going to complete a restore by Monday morning".
Maintenance to fix bugs, fine - providing it doesn't introduce more. maintenance to add features nobody asked for, not so good. If something appears stable over a long period of time there's a prima facie reason to believe is is stable. Taking it apart become some "competent authority" doesn't like the way it's structured or not written in their favoured "safe" language or whatever is very likely to result in problems where none existed previously.
There is an assumption being made here that isn't true : that old software decays like food, whereas new software is good because it's "fresh".
Old software can benefit from having had its problems identified and fixed over time, a benefit that new software doesn't yet have. Of course, all software contains bugs, but brand new stuff tends to have more and bigger bugs than something that has become more robust over time. And the idea of banning "out-of-date" software is going to inexorably lead to the domination of a cloud based, subscription world where software is always new because of the cult of continuous delivery, which in fact continuously delivers new problems.
So, this idea is not going to solve the problem. Proper testing, problem reporting and good old fashioned bug fixing, combined with a sensible measured approach to software upgrades are still the right path to go down here. It might also help to point out that choosing to run SQL Server, which has been developed in typical shonky Microsoft style, might also be the problem when there are more robust alternatives available.
"So, this idea is not going to solve the problem. Proper testing, problem reporting and good old fashioned bug fixing, combined with a sensible measured approach to software upgrades are still the right path to go down here."
And how do you propose to get industry to go down the right path? They've been able to do this of their own accord for years, and clearly have chosen not to.
I think you're correct in that there is an unspoken assumption being made, but I disagree that it's "old software decays like food", unless you unpick that statement a bit more. Why does your food decay like food? Because it's under constant threat of being consumed by something other than you. Bacteria, yeasts, fungi, fruit flies, mice, rats, locusts and about a thousand others. The analogue (somewhat strained) in the digital world, then, is cyber-criminality. It's trying to exploit your software shortcomings, and if it can, then your software is spoiled, decayed, and needs to be replaced.
This leaves aside the continuous software improvement that goes on in a well-maintained product. Not just hardening against threats, but better features, better implemented for speed and efficiency.
A company shouldn't be penalised for running inefficient software any more than they should be penalised for, say, not upgrading their transport fleet. If the transport vehicles are unsafe, though, and put customers and others at risk, then certainly, the insurance companies are going to decline to insure them.
I think that when the author here is talking about "fresh" software, they mean freshly *updated* software, not freshly written software. Software that hasn't been updated in 10 years is probably full of bugs that were discovered five years ago but never fixed.
And if it *was* updated recently, but you're still using the version from 10 years ago...
Also food safety is not just the best before label. The best before date is only valid if a plethora of conditions are met, starting from preparation and using ingredients of a certain standard, through transport and finally correct storage. Don't focus on that single consumer facing label.
For software this would mean things like having certain standard when coding and testing the software (you do demand that interest rates or your taxes are calculated correctly, don't you), installation, hardware requirements, security aspects (physical and IT, like ISO 27001, please don't argue about specific standards, the point is we need a standard), and then also patch regimes, and testing of those, ... the list is long.
So, like in the food industry we need standards covering the whole chain from preparation to consumption. Currently only the final service provider needs certifications (like the mentioned ISO, depending on the industry). The company providing the software faces no real world dangers of getting into trouble if their product is not fit for consumption (the post office scandal?).
One of the biggest risks with old software is not bitrot or bugs but security. Vulnerabilities are found in software on a frequent basis that allow unauthorised access, privilege escalation, defeating of encryption and so on.
Software that isn't regularly patched is vulnerable and putting data at risk. There is a reason that the UK cyber essentials certification for example insists that all applications run on supported versions and platforms (or have appropriate mitigations to isolate and minimise risks). This shouldn't be about keeping the upgrade cycles running.
It matters not whether it be Oracle, Microsoft, Google or Bobs Best software inc. Even Apple these days don't try to pretend security issues don't apply to them. It doesn't matter if it is open or closed source, see LogforJ debacle.
Software requires support and requires patching as and when vulnerabilities emerge. Someone has to pay someone to do this, the mindset that it is simply faulty or should be done for free forever is not sustainable.
Obviously some software is better than others, some companies have better practices and quality control. And in these parts, 90% of folk believe all software developwers incompetent and themselves Omnipotent. That doesn't change the basic facts that all non trivial software is at risk and security requires supported software.
Its about time all of us, especially those in the IT industry, woke to the reality and seriouness of the threat.
El Reg» Worse, neither do one in five of sysadmins in here.
As a DBA, the problem isn't the sysadmins, we upgrade our SQL Server instances every 6 years. We have gone from 2008 to 2016 and now we are starting moving them all to 2022.
The problem lies with managers who don't want to pay for new licences (although ours are, it has to be said, quite agreeable).
On a side note, if a database server is running behind a nice tight firewall, has no Internet access, is reasonably well-secured and ain't broke, is there a need to fix it? I'm thinking primarily of machines running a particular program or a particular piece of hardware and these tend to be very niche. Replacing it when it breaks will certainly be the problem to solve.
I prefer the Cloister Bells as they less jarring on the nerves when awaiting the end of the world. :)
not because of fastidious personal hygiene in the old country.
Not going to get an argument there. I suspect the average pom is inured to anything that might lurk in his food after a lifetime of post midnight, intoxicated consumption of questionable tandori chicken. After salmonella eggs and prionic mad cows nothing short of C.botulinum poisoning is likely to ruffle a briton's feathers.
Curiously I noted that the US has recently had a number of cases of botulism. The FDA site a while ago had particular providore's wares listed for the presence of rocks and other contaminants which is possibly the provenance of the glue and rock pizza toppings peddled by ChatGPT.
I have noticed over the last ~2 years in the US Gov. CISA mailing lists that the requirements for govt entities have become more prescriptive and mandatory which hopefully would be pushed out to non govt entities with supporting legislation.
I would like to see the day when a telco (say) running an insecure, substandard site leaks my identity details (which they should never have retained) is prosecuted for such reckless negligence and unlawful retention of client data.
Although more likely to happen in AU/NZ/UK/CA/EU than ever in the US, I suspect.
the "out of support" includes every version of SQL/Server up to 2017, since then Microsoft has been pushing clients to cloud subscriptions.
Unless you're using graph tables (doesn't really work) or ledger tables (me-too demo searching for a use-case), the main difference is scalability, security patches (even EOL SQL/Server has less issues than Oracle) and in-place version upgrade (page table format)
Y'know back in the day whole systems were often frozen for years or even decades because they were stable and the hazards well-mapped and mitigated.
Relational databases are particularly sensitive to version updates, a lot of performance and even correct results goes bye-bye when you upgrade to a service pack much less a new version. SQL Server Azure was making updates on the fly when I was on it a few years back, and this was a very very dangerous practice for larger-scale, performative systems. Upgrading the version needs to be done first in dev, then test, and finally production, with a lot of turbulence for weeks or months after introduction to production.
It just ain't cartons of milk.
The Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2025
