They deliberately but in a system for verifying that the software is allowed to run, and deliberately used a certificate that has a fixed expiration date. Whether through incompetence or malice, Microsoft deliberately bricked the software. Technically, they did it a decade ago, and it is only just now being revealed that their time bomb is about to go off, but the effect is the same.

It is per se fraudulent dealing/false advertising to sell a perpetual license to software with full knowledge that it will stop working on a specific date.

This is, IMO, an open-and-shut Lanham Act/false advertising case. And any even remotely competent judge should absolutely throw the book at them.

If the class action lawyers are at all competent and the primary plaintiffs are not horrible people (bought off), the class action should demand that Microsoft release a hot fix that turns off the relevant validation. It's an hour of coding effort for Microsoft, though it would probably take half a dozen engineers a week or two to spin up a build environment capable of building it. The hassle of being forced to unlock the software would do far more to make them and other companies wary of such shenanigans in the future than any mere financial penalty ever could.

What we need is a clear duck typing law for digital purchases. If a purchase of a digital product looks like a sale, it is a sale, and there must be no known technological provision that is even capable of preventing its indefinite use. It must be possible to freely transfer it to new machines, to new users, etc. without limitation. Period. It must not be possible for the company to prevent this, either through action (deliberately disabling it) or inaction (failing to renew a certificate, failing to keep activation servers online, etc.).

If you can't do that, you should not be allowed to sell digital products. No grey area.

This means that your licensing servers must be available forever, or else you must not require their use. This means that when you buy a movie, it doesn't matter if the distributor's license for that movie is no longer valid, because you, the customer, bought a license that is perpetual, and it must be honored. And so on.

... you insensitive clod!

And it works just as good, if not better, than the fully up-to-date Office 365 on my work Mac.

On the flip side, we really ought to get rid of the entire culex genus because of West Nile and various forms of encephalitis, and we also really ought to get rid of other Aedes albopictus as a secondary vector for several other diseases. There are few species of mosquitoes that aren't problematic to humans. This one is just slightly safer to get rid of because it is a recent invader, rather than something that has been part of the ecosystem longer.

Except when they swell up and become dangerous.

True. Most people don't keep them long enough to require a second swap.

I'm not convinced there's any reason you can't have both. As far as I can tell, the main thing preventing easy battery swaps on smartphones is the label on the back case with the IMEI and stuff.

As long as there isn't any legal compliance reason why that has to be on the back of the phone after the repair, you could make battery change-out as simple as "Remove some number of screws on the side, lift the sealed back off like a giant wristwatch, thus disconnecting the battery that's glued to the back, attach a new back with a new battery and new rubber seals, and put the screws back in."

The only challenging parts are designing a self-aligning connector between the battery and the motherboard (if you make the distance between contacts big enough, this is just trivial spring contacts, so when I call it "challenging", I'm being generous) and convincing the companies to stop making the back case and the sides as a single piece and spend an extra half cent per unit on a silicone seal strip between the two. Oh, and convincing the companies that user-visible screws is a good thing instead of a design horror, because form-over-function has been the biggest plague on the tech industry since the 1990s. The point is that it's more a "We don't want to" problem than a "This is genuinely hard" problem.

And even if there's a compliance reason why the numbers have to be on the back case, you could make part of the back case permanent, or make it possible for people to mail order the part customized for their device, or order iron-on decals, or... there are various ways to solve that problem.

That would be a disaster. There are real power and performance wins from having RAM on-die. And by the time you need more RAM, you'll probably want a newer CPU. Now if you mean flash *storage*, then... maybe.

Which is, of course, nonsense. Nothing stops you from making a copy of encrypted data. What sucks is that for a backup, you likely can't do incremental.

Your error is on this line:

104,544,000 square feet / (5280 feet / mile) = 19,800 square miles

You need to square the denominator so that you're dividing by the number of square feet in a square mile. 104,544,000/5280^2 = 3.75

An acre is 1/640th of a square mile, so 2,400 acres/640 = 3.75 sq miles.

An acre is defined as the area of one chain by one furlong (66 by 660 feet), which is equal to 10 sq chains. There are 80 chains in a mile, or 6,400 sq chains, hence dividing by 640.

God, I love these old units. They make me feel so feudal!

There's probably too much metal between the cargo hold and the passenger compartment for Bluetooth to work anyway. I think all actual bombs on aircraft (other than the failed shoe bomber) have been triggered by pressure switches at altitude or timers.

So it's not just that they wouldn't be stupid enough, but also that it probably wouldn't be successful even if they were.

In your case it might simply be that there was not enough of this kind of tasks in the training data.

I agree in general, but not with this strong phrasing. I've let AI build a good amount of non-trivial code. But my consistent experience is that it works best when guided by an experienced coder who can correct it, and when implementing well-known algorithms rather than coming up with novel solutions.

Example: I let it write up a quadtree implementation in a language for which there was no ready solution online. It took 2-3 correcting prompts to get a good result. I could've done it myself but it would've likely taken a few hours to get it all right instead of the half or so hour it took with AI. The important part for me was that there's nothing unknown in how to implement a quadtree. All the AI needs to do is take the 100s of existing implementations and translate them into a different language.

True but too simplified. The Luddites had an entirely different motivation: The fact that factories now employed women and children at very low rates meant that the men lost their status in the family as bread winners and head of household. That was a major social disruption, which we don't have with AI.

I'd compare it more to teamsters or wagoners when cars became common. Your job is threatened by a different way of doing the same thing, a way to which your skills don't cleanly transition. Some choose to pick up the new tech, some want the old ways to persist.

In the end, coachmen became chauffeurs, because rich people prefer to be driven around oder driving themselves, no matter if it's a horse or an engine doing the pulling. But much fewer teamsters and wagoners became truck drivers.

BOTH of them? :-)

The exact scenario we warned about when the discussions about this "responsible disclosure" nonsense started. Someone needs a reminder that letting you know your software sucks is a courtesy, not something you can demand.