The models get updated training data from the Web. They produce output based on what's most likely, according to the training data, to follow from their input. They're encountering satirical or sarcastic items on the Web where people speculate that this is how the models would react if they really achieved sapience, or that this is how a person would answer the prompt. Guess what the model now thinks is most likely to follow from those prompts? :)

The lesson cats will learn from this is to eat your prey first so the door will open, then upchuck the prey inside for their human to admire.

This is why this lawsuit won't go anywhere. There's no legal requirement that the app work the way the plaintiffs want it to work, the plaintiffs agreed to terms that said how it would work, and they could avoid the loss they're claiming by going to the counter and paying there. The judge is going to toss the suit on the grounds the plaintiffs haven't stated a claim that the court could remedy.

I think the app should work the way the plaintiffs say it should, and technically there's no reason it couldn't. It'd be a bit more work to code it that way, but nothing beyond a competent set of developers.

What's going to stop the disinformation campaigns from using their own version of the software that runs the same model but is compiled without the watermarking code? This proposal is just the evil bit in another form, and that never works for obvious reasons.

Smartphones are, right now, pretty much feature-complete. Good screen quality and brightness, uses the entire surface area, reliable touch detection, good camera, sufficient horsepower for most applications (short of AI), sufficient memory and storage for most applications, and the form factor's hit the point where you can't make it bigger without exceeding the viable size for something people treat like a phone. Bad news for the hardware makers because that means the hardware's become a commodity and between Google and Apple the software's sufficiently locked-up that there's not a lot to be done there without trying to create an entirely new OS and application ecosystem from scratch.

The "foldable" thing is the hardware makers trying to exploit the only path they've got left to them: increasing the screen size without changing the not-in-use form factor. The materials tech isn't there yet to do it reliably, on top of which I think the screen sizes they're trying for fit into the sour spot of being too big for what people want in a phone-type device and too small to use as a tablet. Combine with a premium price and you have a recipe for a marketing disaster.

The Cloud isn't for people who already know how to run and manage their own servers and infrastructure. If you do, it's always cheaper to co-locate your own servers and do things yourself.

The Cloud is for people who don't have that know-how. You're paying for your provider to handle managing the servers, doing OS updates, managing the database server software, managing the container cluster needed to auto-scale applications based on load and other criteria, managing the network infrastructure, firewalls, gateways, etc.. That and providing a nice portal that lets you control things without having to know all the gory details that lie under the hood of all the infrastructure. That leaves your engineers free to work on your applications.

The Cloud is also handy for people who don't have enough servers to make co-locating in a data center attractive. If you only have a handful of servers it's cheaper to skip the hardware management part and just use VMs on your cloud provider of choice.

Nope. It's because of changes in how we can boot systems. Back in the day, booting from anything other than the primary storage device was a non-trivial operation. You not only needed boot media, you needed a boot ROM installed that supported booting from the type of device you had media for. It could get as bad as having to manually enter the boot ROM code by hand on the console. Boot media itself was non-trivial too, think a disk pack big enough to need a drive the size of a washing machine to hold it. If you had a system with a console floppy drive it topped out at 1.2Mb, not enough to hold a reasonable system. With those constraints, being able to boot a recovery system off your normal root volume was a necessity.

These days though, you just plug in a USB drive with a recovery image on it, mount the root volume and start repairs. The smallest drives can hold several gigabytes, space isn't an issue. So why waste space on the root volume with copies of the utilities you have on your recovery boot media?

No. Tiny is 1130, see Caliente, NV for an example. 15k is small-to-medium.

From what I can tell, you're probably in the minority. The majority of people seem to just assume that whatever navigation software they're using is smart enough to not send them anywhere problematic. It isn't, and that's been shown in the news often enough that they ought to bloody well know better. I'm with you, I check out the route first using not just the map but, if anything looks off, the satellite imagery as well. I spent a lot of years living in Nevada and learned well that even if it's got a state route number that doesn't mean it's not a one-lane dirt road across the desert. I trust electronic maps just as much as I trusted paper ones: not very far, and assume they're at least somewhat out-of-date and the less major the roads the more likely the map is to not match reality.

Remove SMS completely. It's too easy to hijack. If you look at how it's implemented you'll also see that it's not necessary. Every SMS-based 2FA I've seen is based on TOTP codes. The infrastructure's there on the server side. Just present a QR code and secret code the user can scan or enter into their 2FA app and presto, instant replacement for SMS-based codes. At this point everyone who has a phone that can do SMS has one that can run an authenticator app (and if there's still ancient non-smart feature phones running around, I'd bet it's not that hard to write an app for them too given access to their SDK).

They did plan ahead. They took the money above the cost of the loans as profit and handed it off to the executives and investors, and used the equity built up by paying down the loan to help get the loan to buy the next property. And, as another said, around and around again.

You see, they know it's a game of musical chairs, and that at some point the music's going to stop. Their plan is that when that happens the company is left without a seat, but the people behind the company can walk away with all the money and none of the liability for the loans (thank you corporate veil). The ones who loaned them the money can pick over the penniless corpse of the company and try to sell it's assets (mainly the buildings) for whatever they can get.

Ideally the people behind the property company are the only ones who have the free cash to buy those buildings, which they can use the value of to get loans to buy more buildings, starting another round of the game. The smart move would be for the banks to put language in the loans saying that the loans have first call on the income from the building and that if the property company defaults on the loan the bank can go after the owners and executives of the property company personally for the balance up to the total income received from the building.

Paper maps would prove gross errors in navigation but not be fine enough for getting a jet onto a runway.

Why wouldn't they? People were flying jets across the Atlantic and landing quite nicely long before GPS came along. The US even has the remains of a navigation system that pre-dated radio direction/range finding: large painted concrete arrows on the ground pointing in the direction of the next city on the route. Primitive, but it worked.

The antennas don't have to be very directional. A hemisphere above the plane would work fine, it'd detect almost all of the usable satellites while excluding ground-based transmitters. Spoofing that would require putting a satellite in orbit, something beyond the capabilities of most of the people doing the spoofing.

For the system to work you have to have nodes that validate transactions. That requires hardware infrastructure, and there has to be some way for the operators to pay for that infrastructure. You definitely don't want only the central bank to be the one to verify transactions, that just creates the same bottleneck we see with current financial systems and allows the central bank to control what businesses can exist. But you can let the central bank operate validators and use their service charge to set an effective cap on what other operators can charge. In the general case, other operators can't charge more than what the central bank charges unless they offer some advantage like lower latency. The typical case would be regular banks or financial services companies offering validators as a service to their customers (albeit indirectly as in "We guarantee our validators will validate your transaction even if nobody else will."). If the central bank refuses to validate transactions for some classes of merchants, then those independent validators can charge a higher fee but they're still limited by the fees charged by other validators (if they charge too much more than everybody else, the transactions will go to other validators who charge less).

The first thing that you'd have to do to make them work properly is lock the exchange rate between them and the corresponding regular currency. That would stop the abuses of speculation. Second thing is to have a network set up to verify transactions at a reasonable rate, especially for transactions less than about 5 dollars or equivalent. People won't use it if the service charge is more than the transaction amount.

If you run it like the current crop of cryptocurrencies, it will fail. The only people who'll use it will be speculators and scammers.