The problem is, what's ambiguous or precise is subjective. Your devil's advocate needs to reflect all of the possible readers, and that isn't possible.
There's a good reason we use jargon in professions, or more constrained and less ambiguous languages for maths/coding
While I understand the spirit of this comment, if you look at the fossil record you’ll see that’s objectively not true.
Roughly half of the shifts in the last 11 evolutionary periods, over the last 500 million years, were caused by changes that occurred in a-few-hours-to-a-few-thousand-years with 75%-90% species lost.
You are tautologically saying that massive shifts resulted from massive changes, but that doesn't contradict the statement about evolution--which is about far more than such "shifts" (not an aspect of nature but rather changes large enough for humans to perceive)--operating over long time periods. Every single instance of offspring is a "shift" from its progenitors.
Also talking about evolution failing to work is a category mistake--evolution is an ongoing process that is the inevitable result of imperfectly replicating biological mechanisms and there's no "succeed" or "fail" about it.
Only if our explicit goal is to preserve the exact environment that was in place when humans showed up and gained enough knowledge to decide change wasn't allowed anymore
>With RL, models no longer just learn what sounds correct based on patterns they've seen. They learn what words to output to be correct. RL is the process of forcing the pre-trained weights to be logically consistent.
How does Reinforcement Learning force the weights to be logically consistent? Isn't it just about training using a coarser/more-fuzzy granularity of fitness?
More generally, is it really solving the task if it's given a large number of attempts and an oracle to say whether it's correct? Humans can answer the questions in one shot and self-check the answer, whereas this is like trial and error with an external expert who tells you to try again.
The underlying feature of FIAT money creation is debt. And debt is a very natural thing (existing before money) that will just manifest in the crypto system instead.
How do you know it's safe to redeploy? If your entire operation may be compromised, how can you trust the code hasn't been modified, that some information the attackers have doesn't present a further threat, or that flaws that allowed the attack aren't still present in your services? It's a large company so likely has a mess of microservices and outsourced development where no-one really understands parts of it. Also, if they get compromised again it would be a PR disaster.
They're probably having to audit everything, invest a lot of effort in additional hardening, and re-architect things to try and minimise the impact of any future attack. And via some bureaucratic organisational structure/outsourcing contract.
You literally have some of your team buy new laptops and hang out in a temporary wework to set it up on entirely new infra, air-gapped from your ongoing forensic exercise. You just need to make sure none of the people you send are dumb enough to reuse their password. You need to take the domain name, but they will be using one of the high end domain companies so that can be handled.
Bear in mind that this is a company which still sells physically and has retail and warehouse staff. All that the e-commerce side needs to do is issue orders of what skus to send to what addresses, and pause items that are out of stock. M&S is not Amazon and doesn't have that many SKUs, 5 people could probably walk round the store in a few days and photograph all of them for the new shopping site.
Sure, customers will need to make a new account or buy as a guest. But this stuff is not hard on the technical side. There is no interaction between customers like a social media site, so horizontal scaling is easy.
Now I get that there are loads of refinements that go into maximising profit, like analytics, price optimization, etc. But to get in revenue these guys don't even need to set up advertising on day one because they have customers that have been buying from them for decades. The time to set up all that stuff is when your revenue is nonzero
> M&S is not Amazon and doesn't have that many SKUs, 5 people could probably walk round the store in a few days and photograph all of them for the new shopping site.
I can't speak about M&S buy all big physical retail brand which started selling online are exactly operating as Amazon with SKUs coming from various third party entities. The offering is much bigger than what is sold at the physical shops.
I had the impression that M&S wasn't, but if that's the case then yeah, that would invalidate my analysis. Especially if even their retail stock goes through that route when bought online.
In the UK and Ireland (and maybe elsewhere?), a kettle lead is actually C13. I guess you need a beefier cable/pins in the US, as you're drawing more current at a lower voltage.
Most kettles now have a base with an integrated cable though, so the name doesn't really correspond with the cable's most common usage any more.
>I guess you need a beefier cable/pins in the US, as you're drawing more current at a lower voltage.
No, we just accept slow-as-piss kettles.[1] (Our plugs aren't great, either, it's pretty common for a spark to jump the gap of the leads while you're plugging it in.)
High wattage appliances here have an effective max of like 1.8kW on a single-phase 120V outlet, it makes for pretty useless space heaters and kettles. You could probably beat our kettles with an induction cooktop just by virtue of the stove being able to use two phases.
Truly it's a tragedy for those of us addicted to our hot beverages.
>it's pretty common for a spark to jump the gap of the leads while you're plugging it in.
how are you plugging it in? Are you plugging the mains end into the wall before you plug the kettle end? That's truly bizarre to me, and goes against everything
> it's pretty common for a spark to jump the gap of the leads while you're plugging it in
If you’re referring to seeing a spark while plugging something in, that’s just current jumping from the socket to the pin that’s entering it - it’s nowhere near possible for current to jump between the pins on a single plug (in air, at least). The distance between pins was specifically designed to prevent that possibility at the given voltages.
Not saying our plugs aren’t poorly designed, just that that’s not one of their problems.
I had a friend who was easily teased by this, but he was quite right, and you are wrong. Kettle leads in the U.K. have never been C13, and "kettle lead" for a C13 power lead is a misnomer just as much in the U.K. as it is elsewhere.
When kettle power cords weren't captive, as they are nowadays, they weren't C13. Non-captive kettle cords from the middle 20th century were round pin, for starters, and not like the (later) IEC standard at all. Here's a round-pin electric kettle from the 1960s, for example:
That first link doesn't support your point. No one would claim that all kettles ever sold in the UK have C13 cables. (No one would even claim that none use C15 – after all, some companies will surely just use the same design across all markets if possible.) This particular kettle is before C13 and C15 were even standardised.
The website it's from has a fair number of kettles from the relevant time period (1980s and early 90s). These two (which seem to be variants of the same model) [1,2] have an OKish view of the power connector and look more likely to fit C13 than C15 from what I can make out (no notch). This one [3] is clearly for C15 though, but as I say it's not a surprise that some exist.
On the contrary, it supports exactly the point made in the preceding paragraph, which even pointed out that the IEC standard came later.
The phrase "Should have gone to Specsavers!" comes to mind. All three of your examples clearly have notched connectors. Two have the notches at the top, and the Russell Hobbs one has the notch at the bottom. Their kettle leads were not C13.
So to repeat: When kettle power cords weren't captive, as they are nowadays, they weren't C13. I've already given an example of a kettle preceding the standard that didn't take anything like a C13 connector, and in vainly arguing against that you've ironically produced three more examples of kettles from later decades whose kettle leads were also not C13.
Here's yet another one, where the lead itself is in the picture. It's not C13.
If there had been examples of kettle leads that were C13, I'd have long since used them to really tease my late friend. But kettle leads in the U.K. have never been C13, and my late friend was right that "kettle lead" for a C13 power lead is a misnomer in the U.K..
I think its just the UK and Ireland where there's a demand for "high performance" kettles. The rest of the world is condemned to waiting longer boiling periods due lower-wattage kettles. I've had a British expat audibly exasperated by my kettle.
the reasoning is about correctness and program behavior
Haskell is still the only mainstream language that truly delivers on "understand the part without needing to consider the whole." Others can with work and discipline. With Haskell, you usually have to work hard to get in that level of quagmire (and I've seen and fixed plenty of quagmires. I've seen people complain about code too and just be wrong when I got my hands dirty for like an afternoon.)
The rules do work on the AST but the current cookie rule is not as advanced as it could/should be. For example, we really should treat encryption as sanitizing the value.
We'll take another look at the rules with this in mind. If you are able to share the (rough) approach you take to build the cookie string it would help us to ensure we're covering the specific case(s) you have.
Thanks for your questions. Yes we do perform dataflow analysis:
1. Not yet but we are exploring ways to support that
2. The analysis part is sound. False +ves (mainly) come from limitations with what you can specify in the rule language. We're working on this however.
3. We don't make that distinction in the rules language currently. Sensitive data detection (which is built-in) is effectively treated as a source. But we need to allow rules to specify sources. I don't think the limitation matters to finding issues, but more to how well they are reported (you effectively only get the sinks reported at the moment).
4. We plan to add other languages but are mindful of the balance of depth vs breadth of support. Is there a particular language you'd like to see support for?
5. There is no support for these currently unfortunately.
6. As it's intra-procedural, we take quite a basic approach to these (with some special cases in the engine). In terms of dataflow, we treat unknown function calls as identity functions (assume the output is somehow influenced by all the inputs). Obviously this is not ideal in terms of false +ves, but we need to work on inter-procedural support first to do a good job of this. In terms of type analysis, we will try to infer unknown types locally from field/property access.
There's a good reason we use jargon in professions, or more constrained and less ambiguous languages for maths/coding