joosters

Like, if you have an image of a car, viewed at an angle, you can gauge the shape of the 3d object from the image itself. You could then assume that the hidden side of the car is similar to the side that you can see, and when you generate a 360 rotation animation of it, it will look pretty good (cars being roughly symmetrical). But if you gave it a flat image of a playing card, just showing the face up side, how would it reconstruct the reverse side? Would it infer it based on the front, or would it 'know' from training data that playing cards have a very different patterned back to them?

> But BYD is also a car maker in its own right

Yeah, it's actually the largest electric car manufacturer in the whole world.

85% -> 99.6% is an improvement, but not like a game-changer.

If Facebook didn't immediately block sales of items self-described as knockoff <whatever brand>, they'd be (rightly) criticised for allowing the sale of counterfeit goods

So? Google can do that too. They just choose not to, for profit reasons.

AI can (presumably) also do that. But will AI companies instead choose profit? Of course they will.

I don’t think either of those things are true. Both can be changed, and are often changed. Much of what we ‘know’ of the past is wrong.

[Also, to be pedantic, it should really be called "fewest requests" - but I've never seen a product call it that!]

Why are you defending a multi billion dollar company from something that the users aren’t obliged to do in the first place?

It's far cheaper (and more deniable) to find a slightly different way round the regulations, see if/when you get fined for that, then move on to something else again...

For a start, String objects are going to be different everywhere. Even in C++, one library's String object isn't going to be binary compatible with another. How is the data laid out, does it do small string optimisation, etc? Are there other internal fields?

So you won't be passing objects around. At the ABI, you'll have to pass a pointer and a length. Calling an ABI will involve unwrapping and wrapping objects to pretend you are dealing with 'your' strings. Simple C-style ABIs make memory management straightforward (n.b. but error-prone, and certainly not easy). If this new style ABI returns a 'string' (pointer and length) of some sort, you have to package it up in your own object format, and manage the memory. Will you need an extra object type to represent 'string I got from an ABI, whose memory is managed differently'?

None of these are insurmountable, but they are a complexity that is rarely thought of when people declare 'C style ABIs are terrible!'

Basically, if you have N different features (let's assume they are all on/off switches, but it works for multi-values too), in theory you'd need to run 2^N tests to cover them all, which would become completely impractical. But, you can generate a far, far smaller set of test setups that guarantee that every pair of features gets tested together. Run those tests and you'll probably encounter most feature-interaction bugs in a much quicker time.

The associated program 'ansi2txt' could also solve a similar problem for me from the other way round: I tend to have grep aliased to 'grep --color=always', simply because often I'm going to pipe the results to 'less' and I still want the colors. But this sometimes trips me up if I have a series of greps: The first grep output has color codes, making the followup greps fail. If grep could be made to strip out color codes prior to running, everything would work just as expected.

In general, if you're running a series of connected commands, it's only the last one that you want to get the colors from, with the special case exception of when the last command is 'less' - in which case, the next-to-last one should keep the colors. All ways that make this happen automatically are useful!

Unfortunately, calling it colorless would be exactly the wrong name for it!

More doublespeak from crypto fetishists.

So maybe the workers spent more money buying their lunches, but that's just extra inefficiency, and not extra economic acitivity. Just like the broken window, the workers spend more in one area and so have less money to spend elsewhere.

cron goes completely against that principle - after all, you can schedule jobs with the 'at' command, and to make a repeating task, you just make it exec 'at' again each time it is called. cron is for the lazy, no real UNIX hacker would dream of using such an extravagant single-use program. /s

Instead, they might move development away from the UK. Bad for developers, sure.

https://en.wikipedia.org/wiki/Eric_Gill#/media/File:Eric_Gil...

(In fact, you could argue that this defence is even stronger because he is Donald Trump. He has plenty of dedicated supporters who seem to stick with him regardless of his transgressions; accusations of infidelity might be less damaging to him politically than to other politicians!)

So, the prosecutors have to somehow convince a court what his intent really was, i.e. it's less about what he did and more about why he did it.

I wonder why they chose to tell the users when they registered, instead of waiting? Could they have gone ahead and let them place orders for DDOS attacks, to capture more proof of the users' criminal intent, or would that count as entrapment? Someone who 'merely' registered could try to claim that they were a researcher, but if you hit the button to DDoS someone, that's going to be more difficult to deny responsibility for.

[Edit: Now that's making me imagine a disgruntled user suing the NCA for breach of contract: "I paid money for a DDoS and they didn't provide the service!"]