The lack of a corresponding announcement on their blog makes me worry about a Twitter account compromise and a malicious model. Any way to verify it’s really from them?
There was a buffer overflow or some other exploit like that in llama.cpp and the gguf format. It has been fixed now, but it's definitely possible. Also weights distributed as python pickles can run arbitrary code.
There are plenty of exploits where the payload is just "data" read by some vulnerable program (PDF readers, image viewers, browsers, compression tools, messaging apps, etc)
Yes, there's a reason weights are now distributed as "safetensors" files. Malicious weights files in the old formats are possible, and while I haven't seen evidence of the new format being exploitable, I wouldn't be surprised if someone figures out how to do it eventually.
As a REST enthusiast I was excited to read this and learn a new perspective but this section
> The “benefits” REST is supposed to introduce
Is one of the more egregious straw men I’ve seen in a while. Never once in my twenty years have I heard anyone say it’s nice because “you don’t have to read the docs” or “it works in a browser”
REST helps with lots from thinking through clean data models to helping ensure consistency within an API.
The uniform interface, which is the defining characteristic of REST according to Roy Fielding[1], is what allows clients to interact with REST-ful APIs without "reading documentation":
> "A REST API should be entered with no prior knowledge beyond the initial URI (bookmark) and set of standardized media types that are appropriate for the intended audience (i.e., expected to be understood by any client that might use the API). From that point on, all application state transitions must be driven by client selection of server-provided choices that are present in the received representations or implied by the user’s manipulation of those representations. The transitions may be determined (or limited by) the client’s knowledge of media types and resource communication mechanisms, both of which may be improved on-the-fly (e.g., code-on-demand). [Failure here implies that out-of-band information is driving interaction instead of hypertext.]"
Disclaimer up front; party in back: I'm about to discuss a freemium service that I built & operate related to this :)
I looked around for a solution like this for a while last year while building a new weekly email for Ramen[1]. I tried a bunch of services but ran up against a bunch of issues mentioned in this thread:
- GET query string character limit
- Stress around unreliability of free alternatives
- Need to be able to handle large spikes of image generation when sending emails
So I ended up building a service and turning it into a freemium product: ChartURL.com[2]
It is:
- Free for low usage w/ branding
- Based on C3.js[3] (for major flexibility)
- Supports datamaps.github.io[4]
- Has an API whereby you can POST huge datasets and get back a short URL that can be used in an img tag
- Supports retina & `srcset` via a `retina=1` option
You need to sign the URLs which means it's not a simple "just drop the data in the URL" but it's close.
I'll hang out in the comments here for a while if any of you want to ask questions about it.
All "natural" means in this context is that the person died independent of the actions of self or others, its the "not manmade" definition. Had a friend go with an aneurysm at a little younger age. Its horrifying to have those nothing you could do scenarios. Hit me much worse than the overdoses, suicides, or car accidents, and I'm not really sure why.
One of the guys who built Amplify here. We posted on Product Hunt yesterday, so some of you might have seen us there, but for those that haven't, some background:
Amplify is something that we've had in the back of our heads for a while. We built a hack version of it for our own launches, and when we told other founders, marketers, and product people about it, we got lots of "huh... yeah that's awesome... can I use it?" type responses.
While there are other services out there like that allow "group social scheduling" like Thunderclap & GaggleAmp, Amplify differentiates itself in that it focuses on the product/customer relationship.
We've had success internally with a previous version of Amplify, and now we're happy to offer it to the world.
Can you illustrate how you leveraged Amplify to amplify Amplify's launch? I bet your own launch could be used as a case study on how to best optimize a launch or to produce a good tutorial.
We had a last-minute standoff with Facebook over some permissions issues. That delay meant that we weren't able to start asking our customers far enough in advance, and we could not delay our launch of Amplify because it was tied to announcing our Segment.com integration.
However, towards the bottom of the landing page, you can see how we were able to use the technique to trend on LinkedIn back when we launched our core product a couple months ago. Unfortunately, in that campaign, we were not tracking clicks correctly, so we can't share any hard data. Anecdotally, several companies told us they came across Ramen through that campaign, which is why we were confident that building and launching Amplify was the right move.
I look forward to a day when we can provide a great case study backed by data :)
EDIT: Forgot "announcing" before "our Segment.com..."
Yeah interesting. They really fly through the product. The use of angles and animations makes it so that you don't even try to spend time trying to read what's on the screen. You just flow through everything really quick and get a holistic sense for what's possible.
