Sorry, but even just high speeds are dangerous. They mean a slight twitch of your muscles and you're headed off the road faster than you can correct. It probably differs from person to person, but for me 70 mph was too fast, and I could tell that it was too fast. 65 was ok, but it was impossible to keep safe stopping distance. Fortunately, that *is* strongly affected by relative speeds, but you need to be able to handle incursions from this or that (say a deer).

If that happens frequently, then it's a serious problem that needs to be addressed. It doesn't matter if it's a really stupid mistake if a lot of people tend to make it.

"Video unable to load"

Once upon a time I'd suspect it had been "slashdotted" , but I doubt Slashdot generates the sort of firehose of traffic it once did. Which means this things just fallen on its arse in normal traffic. Not a good way to launch a ..... startup... or whatever this is supposed to be?

The vine people must be pretty bitter they gave up the ghost and then a year or three later tiktok did more or less the exact same thing and turned into one of the biggest gen z sites on the planet.

I think its important to think about the context of a decade ago. At that point language models where pure research. Things that generated absolute gibberish outputs and maybe might one day be useful in spam detectors, search engines, grammar checkers and translation apps, and the "Attention is all you need" paper that basically changed everything was 3 years in the future. You could be forgiven if one of your investors said "Hey, mind if I scrape your site? We're doing some research on language processing" thinking it was pretty harmless.

He used to win these market timing games because no one was paying attention to huge short positions. You could quietly bet against a company, or, better yet, you could quietly amass a short position and then release stunning negative news that you had uncovered and watch the stock price tank.

These days it is more likely that online investors will notice a large short, and drive the price of the stock up until the person holding the short gets margin called and loses all of their money. The shorters then provide the liquidity you need to get out of the position. There used to be good money in shorting terrible companies, but in an age where hordes of armchair investors can drive the price of GameStop to the moon that strategy is just too risky.

So true. Sadly these days the market can stay irrational almost indefinitely. The factors that helped constrain this irrationality, like actual government oversight and discipline of equities and debt, willingness to let large corporations fail, and investor discipline in discerning real growth from financial games have all been eroded.

I have no idea when valuations will fall, and I wouldn't want to be better on a market that has no basis in fundamentals at all.

Not saying this is a good idea, but I don't think the gig worker would know if you're paying $6.99 or $2.99 for the delivery, which is what would tell them if you have more than $100k in assets.

In general data owned by app A is not readable/writable by app B. This is a pretty important security feature. There are ways for apps to choose to share data, but by default every app's data is private to that app.

I can see how that might inconvenience you, but I think it's Really Good Idea.

No, that would be you.

Some people are so obsessed with how great AI is in their mind they can't take it when others point out obvious problems. You would be one of those people. You need to recognize the technology isn't what it's sold as, and you shouldn't be worshipping a technology like a God anyway.

Except the Amiga. Obviously. That was perfect.

Nah, their previous plan already provided the bare minimum, since it didn't restrict sideloading of unverified apps via ADB. This is just an attempt to calm the complaints by offering an even easier sideloading option. Unfortunately, it will probably make the whole scheme pointless, since malware authors will just train users to click through the scary warnings.

This is sadly true. They're going to attempt to throw up a lot of warning dialogs to dissuade users, but we know from long experience that users will click through anything to get to cat videos.

This is actually not a change, really, since they were already going to leave sideloading via ADB open, so their plan already included an "advanced user option" which users could be trained to do. This new thing must presumably be easier than ADB. My guess is that it will feature more scary warnings than enabling ADB, but will allow sideloading without using a USB cable to connect to another computer so that on balance it will be approximately as hard.

During another discussion of this I posted a story that an Android OEM related to me when I worked on Android security, when they asked me when we were going to "close the USB vulnerability", i.e. disable ADB.

How so? The developer verification does not require compliance with any of the Play store policies or anything at all other than the rule "don't distribute malware", since distributing malware would result in the developer account (and signing certificate) being revoked, which is the point of the whole thing, to enable Google to shut down malware authors. Or at least to slow them down, since they'd have to register for a new account, with a different government ID.

This does leave determination of "what is malware" up to Google, but they've been doing that for a long time and I've yet to see any case where people disagreed with their assessment. Note that I'm talking about designation of malware, not about removal from the Play store. Identified malware is removed from the Play store, but there are lots of other policy violations that can trigger Play store removal.

This is not correct. Per the information on Google's developer console sideloading of unverified apps via ADB was not going to be disallowed:

Q: If I want to modify an app and install it on my own device, or if I'm a power user, is there a way to turn this verification requirement off?

A: We understand that's an important use case for many developers and power users. While the verification requirement itself is a core OS feature to help protect the broader ecosystem from malware and can't be turned off, developers and power users can still use Android Debug Bridge (ADB) to continue to build, test, and install modified or unverified apps on their own devices.

(Emphasis mine)

This information has been up since shortly after the announcement.

For example?