> I wish the order of presentation were different, because it starts with incorrect and misleading claims and then only later fixes its trajectory.
I wouldn't hold my breath, every inch of this article is evidently AI-generated - you can tell not only from the meandering narrative but also from the "Not because X, but Y", the short punchy sentences to reiterate the same point, the really strange cherry-picked examples for head-to-head comparisons, and the sincere concern over simplified generalisms.
> Yeah, ok. This is what they should lead with. It's an important message.
Is it? Your optimism in hoping to find some point to all this restores some of my faith in humanity, but I think it's misplaced here. The entire premise of the article is bizarre - why should it be surprising or bad that historical figures from 1000s of years ago, regardless of their historical importance, don't have proportionate representation in contemporary discourse?
This seems like a pretty surprising process failure for a mature company like Grubhub, for such a marketing campaign to be greenlit without any guardrails. Wouldn't this be the kind of mishap you might expect from a startup or a 2-year old company?
Edit: I stand corrected. Per the Buzzfeed article, their spokesperson seems to be spinning this as an unexpected hit. So it wasn't a mistake, they were genuinely convinced it was a good idea?
It looks like it could be a binary intended to be snuck in with third party package dependencies and such that you might unintentionally execute within your lambda runtime. It's one thing doing mining at a slow trickle within the free tier of a single account, and another thing altogether when potentially millions of lambda functions in the wild are mining for you.
But agreed, it's not necessarily functionally different from any other crypto-mining malware hidden in public repos, save for the focus on runtime. Presumably Lambda provides a standardized enough runtime for reliable execution.
A more poignant elegy to the modern landscape of compliance theater I have never seen:
> Security Standards. Okta's ISMP includes adherance to and regular testing of the key controls, systems and procedures of its ISMP to validate that they are properly implemented and effective in addressing the threats and risks identified. Such testing includes:
> a) Internal risk assessments;
> b) ISO 27001, 27002, 27017 and 27018 certifications;
> c) NIST guidance; and
> d) SOC2 Type II (or successor standard) audits annually performed by accredited third-party auditors ("Audit Report").
I don't think storing AWS keys within Slack would comply to any of these standards?
Likely some stressed out buyers paid for overpriced homes given the sharply rising prices across the market (although completely by their choice), and the sellers probably loved it - but that's already par for the course with the housing market at the moment. Zillow probably didn't help but isn't the sole contributor by any means.
> A more innocent, but also unproven, theory is that those who got sick suffered from a mass condition brought on by some stressful underlying situation.
One could argue that we are doing the followup even to this day (with the China CLEP programme, India’s Chandrayaan, USA’s ongoing Artemis campaign and others). The deed was done, the minimum bar was set and humanity has been as determined as ever to breach the peak it had achieved back in the sixties even as government funding waxes and wanes. Public interest has not changed in the least.
Is this referring to Alexa, or some other product? Have there been any major notable reports about spying happening with Echos?
With regards to data collection for ads, personalized recommendations and such, are there any major concerns that don't also extend to ex:- visiting a website with a tracking cookie on?
(Don't get me wrong, I'm very wary of this product after Sidewalk [0] which I don't trust from a security perspective wherein as a bug could allow _third parties_ to snoop on me, but I'm just missing what people are talking about w.r.t. surveillance by Amazon itself)
This is a good principle in terms of reducing the overall blast radius of exploits. But to do this the implementations should genuinely be independent.
In practice we may find a monoculture within a hidden layer of the stack than we're optimizing for, such as an OS kernel method, TLS library or chipset which coincidentally has captured the entire market. When a clever enough exploit on a common resource is found, then the problem transforms to one of coordinating patching for the same, wherein a broad ecosystem of higher level components (like Android or PCs) becomes nearly impossible to thoroughly cover. As such malware authors may potentially still get away with writing a single version of their software so long as they target low-level enough. With sufficient fragmentation they don't even need to invent their own exploits, just use publicly known CVEs that they can brute-force against older devices.
(Not saying you're wrong, your recommendation may still be better in the long-run. We're after all weighing the risk level of black swan events, such as a zero-day on a low level of the stack, or a high level of the stack on a high-volume vendor)
The pricing appears to be static per model with a ceiling on the monthly request count, not charged per request.
Edit: Actually, I didn't spot the free tier of 1000 requests. I wonder how you avoid the problem of a lot of users leaving defunct/disused models running while still keeping them hot - presumably some kind of limit to the model count?
Yeah, given that the article started off establishing how an Estimator was basically an interface with simple rules about supporting "fit" and "predict" and how it could contain anything or do anything, I thought the argument laid out here would be about how these derivative implementations broke these rules.
The rest of the article instead seems to have lost the plot though, somehow finding fault with various derivative or concrete implementations of this interface, for A) being inextensible implementations and not transitive interfaces themselves, as though "be anything do anything" no longer applied; or B) not being perfectly aligned with sklearn estimator details that the author didn't really identify as essential, like not following some sklearn-specific parameter naming rule or not being serializable via pickle (like seriously, pickle support is often not appropriate for production, why should this be a required pattern! It's not even a requirement of the interface unless you read between the lines like the author implies is essential to be at parity.) As other commenters outlined here, it assumes that sklearn's contract is absolute, as though other libraries couldn't reinterpret the core principles.
The arguments against Tensorflow or Sagemaker's interfaces especially stretch quite a bit - what exactly is so offensive about these implementations given the very rules that the author establishes in this article? All "fit" is supposed to do is update internal state as the author asserts, but what precludes implementations of this interface from using cloud-based compute resources to achieve this end? And what about the fact that a docker container is deployed to the cloud by this command makes "fit" a lie? And honestly, what does the author have in mind for an estimator implementation that uses cloud resources like GCP TPUs or AWS EC2 that is also somehow more correct or pure than these implementations?
More than anything, the author's dismissal of the value that GCP and AWS's implementations bring in eliminating infrastructure management via their Estimator implementations (equating it to "simply" writing Dockerfiles or running Docker containers on the cloud like there's no setup involved) implies that they're thoroughly disconnected from the realities of ML devops on the cloud. They're free to run their purist single-core sklearn estimators on their laptops as much as they'd like though (unless Dask somehow gets a pass from these arbitrary rules around how estimators can and cannot be used).
What does a yearly installment plan even mean in the context of a cloud subscription-based service, as opposed to one for which one has already received goods?
And first of all, as the OP noted in the twitter thread, they believed they were doing a monthly subscription as advertised; the "yearly plan" interpretation is Adobe getting creative in the terms of service.
I wouldn't hold my breath, every inch of this article is evidently AI-generated - you can tell not only from the meandering narrative but also from the "Not because X, but Y", the short punchy sentences to reiterate the same point, the really strange cherry-picked examples for head-to-head comparisons, and the sincere concern over simplified generalisms.
> Yeah, ok. This is what they should lead with. It's an important message.
Is it? Your optimism in hoping to find some point to all this restores some of my faith in humanity, but I think it's misplaced here. The entire premise of the article is bizarre - why should it be surprising or bad that historical figures from 1000s of years ago, regardless of their historical importance, don't have proportionate representation in contemporary discourse?