I think I’d argue that the models are still a limiting factor for these kinds of tools - but there’s still also plenty of competitive space outside of models. The context you gather, the way you gather it and your prompting matters.
> The context you gather, the way you gather it and your prompting matters.
But your API provider gets to see most of that because you send it to them along with your prompts. I don't know what the ToS for these AI providers are like, but it seems like they could trivially copy your prompts.
Uhhh, no they don't? They see the results of RAG but there's very little to distinguish what is context you gathered vs. what isn't. On top of that, there's nothing in the prompt that indicates what decision was made before inserting something into a prompt. Let's say my retrieval pipeline used a mix of semantic search and keyword-based search, and I used some mechanism to decide which results from which search to include for this specific request. Nothing in the prompt will say that, and so the differentiating behavior is still kept "secret" if you will.
But I think this line of thinking is a bit ridiculous. Yes, if you send your data to a database service, that provider has your data and theoretically use it to run you out of business. Except they kinda can't, both as a matter of practicality and legality. OpenAI, Anthropic, and others have SOC II compliance. The easiest way to ensure you run yourself out of the market is to start violating that stuff.
In this context, it means that I (a hobbyist) get to enjoy copilot at a discounted rate because there are some feature (context exclusion) which were costly to implement that I am not using. So it makes sense for me to take a less expensive plan which only includes the core features without the cruft. If there is any of these additional feature that I need, then I just need to pay for the engineering time that went into them, which takes less than a few seconds, it's just a button to click on. Fair and square.
I’ve given up on using iCloud Drive, despite having Apple everything, because I find the sync so unreliable and undebuggable. I never had any issues like this with OneDrive or Dropbox.
I found OneDrive would crash a lot amd couldn’t deal with file names that weren’t valid windows file names.
The google drive for Mac crashes a lot, and no matter how I adjust the settings often refuses to download the full remote system unless I click on the cloud icon next to the file name. They really want you to use a web browser, which I don’t like to do (prefer native apps, thanks).
Dropbox seems to have gotten it right, it seems. I guess that’s why they’re still in business even though their business is built around a feature, not otherwise a product.
> Dropbox seems to have gotten it right, it seems. I guess that’s why they’re still in business even though their business is built around a feature, not otherwise a product.
That criticism never made sense to me, especially from Steve Jobs, as a moderate sized team putting their all into an excellent product will be competitive against a larger team putting in a half-hearted effort. As he himself demonstrated.
I don’t know about Steve Jobs and iCloud, but Dropbox is the kind of thing that can become table stakes, requiring a large surface of interface (esp relative to its core functionality) vs someone else fitting it into their existing infrastructure (e.g. authentication and other tools). That’s basically the definition of a feature.
They only survive at all bc so many competitive alternatives can’t be bothered to invest in doing a good job.
Like I said a moderate sized team putting their all, going above and beyond, etc..., however you want to phrase it, will be competitive even against a much bigger company putting in a half-hearted effort.
Of course if they slip and only start putting in a 1.5x effort or something then they won't be competitive.
Excel pivot tables won’t work if the file banner is invalid in Windows, too. This happens a lot for me when I open an Excel attachment, because macOS will put brackets in the file name.
Really? I have had horrible issues on OneDrive if my connection is bad. Including extremely frustrating things like reverting files to older versions and completely deleting all of my local work. Admittedly, that was ~3 years ago before I switched to GDrive.
Author here. We plan to publish a blog post in the next few months that explains how we do this under the hood. We have some pretty nice abstractions and tooling to make it as maintainable as possible.
Author here. You've hit the nail on the head on why we default to 2022-11-28 - it's all about protecting the hundreds of thousands of of existing GitHub integrations that rely on our current behavior.
Author here. I think it's a pretty nice idea to include deprecation information in the response headers as another way to keep API integrators informed - alongside written forms of communication like blog posts, changelog entries and emails. We'll discuss that internally.
As @xavdid noted, the reality is that most people won't see these headers, but it's a nice power user feature.
Author here. I think this is an interesting suggestion, and one we'll have a chat about internally.
I definitely see the benefit of being able to easily hit the URL from a browser - although I think it's probably only relevant for unauthenticated GET requests.
Supporting many API versions in parallel definitely has an overhead from an engineering perspective - but, as the blog post says, we thought it was crucial that we unlock the ability for us to evolve our API whilst still providing consistency to existing integrators. Some form of versioning was the only way we could see to do that.
We've built some pretty neat tooling and abstractions internally to make it easy for teams across GitHub to build and test multiple API versions. We hope to publish a blog post about that in the near future.
