> A court still might rule that all AI-generated code is in the public domain, because there was not enough human input in it. That’s quite possible, though probably not very likely.
Its not only likely, it is in fact the current position, at least in the US.
> gws doesn't ship a static list of commands. It reads Google's own Discovery Service at runtime and builds its entire command surface dynamically.
What is the practical difference between a "discovery service"+API and an MCP server? Surely humans and LLMs are better off using discovery service"+API in all cases? What would be the benefit of MCP?
Nothing. MCP and HTTP APIs and CLI tools without the good parts. They lack the robustness of the OpenAPI spec, including security standardization, and are more complex to run than simple CLI utilities without any authentication.
I have done it many times, using the swagger.json as a "discovery service" and then having the agent utilize that API. A good OpenAPI spec was working perfectly fine for me all the way back when OpenAI introduced GPTs.
If we standardized on a discovery/ endpoint, or something like that, as a more compact description of the API to reduce token usage compared to consuming the somewhat bloated full OpenAPI spec, you would have everything you need right there.
The MCP side quest for AI has been one of the most annoying things in AI in recent years. Complete waste of time.
Benefit of mcp is that it exists and kinda works, and a lot of tools are available on it. I guess it's all about adoption. But inherently yeah it's a discovery service thingy. Google will never embrace mcp since it's invented by anthropic
I consider it a good first attempt, but indeed hope for a sort of mcp2.0
Right, but surely swagger/openapi has been providing robust API discovery for years? I just don't get what LLMs don't like about it (apart from it possibly using slightly more tokens than MCP)
MCP is like "this is what the API is about, figure it out". You can also change the server side pretty liberally and the agent will figure it out.
Swagger/OpenAPI is "this is EXACTLY what the API does, if you don't do it like this, you will fail". If you change something, things will start falling apart.
in a lot of sphere, MCP is still the hype. And it was the hype in even more sphere some month ago.
Because of FOMO a lot of higher up decided that "we must do a MCP to show that we're also part of the cool kids" and to give an answer to their even-higher-up about "What are you doing regarding IA ?"
The project has been approved, a lot of time has been sunk into the project, so nobody wants to admit that "hmmm actually now it's irrelevant our existing API + a skill.md is enough"
I've seen that in at least 4 companies my friends work in, so I would be surprised if it's not something like that here too.
On the contrary claude code, in my experience, has been perfectly able to use `stripe` `gh` and to construct on the fly a figma cli (once instructed to do it).
As a windows power user myself, many of my workflows don't translate that easily. If you are an experienced Windows user, you probably have programs that you use on Windows and that aren't available for Linux. It's not that you couldn't theoretically translate that workflow into Linux, but boy, it would be a headache.
To give an example: I use AutoHotkey, it's a scripting language for Windows that allows you to do a bunch of things. You can customize the keyboard, mouse, you can create menus and toolboxes, you can target specific applications inside. It's a fantastic tool. But it isn't available for Linux for obvious reasons; Linux is much more fragmented. You need like 3 or 5 different programs to achieve the same result in some cases, depending on your given script.
In other words: debloating Windows and customizing it is considerably easier than installing Linux. Let alone some really good software you end up finding along the way: Everything, which is an amazing search program that allows you to create custom categories and the like. EmEditor, which is really good software to open and visualize really large text files, like it can open a 4GB txt with no problems.
About the last sentence:
>If customisability is important
People value both things: customisability but also they value their time (of not having to come up with a new workflow), they value the programs and workflow they already learned to use through the years, and so on and so forth.
It’s less work on Windows for many things, and the system of UI events, hooks, and controls is more amenable to universal customization/automation than on Linux, which is more heterogeneous between applications, window managers and desktop environments.
Yep - I remember working at a staunchly Linux company many years ago (they were all about saving money), but the two most senior people in technology both used Windows for this exact reason.
Ok, do tell: how do you customize Linux to get instant folder sizes in your file manager (a mod mentioned in the comments above)?
Where is Autohotkey for Linux?
And let's not forget about all the apps that just don't run. You simply can't customize your OS to the same level of overall comfort, so you start with a better base and tweak away
You can make the most popular GUI file explorers on Linux like thunar do this automatically, it's just not enabled by default usually.
The concept for something that combines AHKs scripting/automation functionality with the key remapping doesn't really exist on linux, because there isn't any need for it. You achieve the same result by calling the functionality present in a variety of different programs via a script or small program that links everything - this is the (superior) UNIX way.
Key remapping daemons such as keyd exist, as do a wide variety of extensible/scriptable window-managers/desktop-environments. Almost all of these will contain well documented interfaces and IPC methods which allow you to build anything you can imagine in the context of GUI window manipulation/management. If you're lazy, or don't have time to learn the syntax, any recent AI code helper will most likely oneshot your request - my 16 button mouse has various common GUI window management actions assigned to it(that you might expect something like AHK to handle), and only a couple took longer than a few minutes to implement.
> I have strong signal that Dario, Jared, and Sam would genuinely burn at the stake before acceding to something that's a) against their values, and b) they think is a net negative in the long term.
Sure, but what happens when the suits eventually take over? (see Google)
Given that most of the utility of Typescript is to make VSCode play nice for its human operator, _should_ we be using Typescript for systems that are written by machines?
> The reason Message-ID is SHOULD rather than MUST? Mail clients
> sometimes send messages without one to their submission server, which
> adds it on their behalf. As for why Google enforces it anyway:
> spam. Messages with minor RFC violations are far more likely to be
> spam, so rejecting them is a reasonable heuristic. In practice, Google
> and Microsoft have become the de-facto standards bodies for email —
> what the RFCs say matters less than what their servers accept.
Surely the problem is on Google's end? And a metaproblem is that we are allowing corporations to change or ignore standards for critical infrastructure?
The email landed in the spam folder. A bounced email means it didn't find the inbox. If it didn't find an inbox there would be no log for him to check. Technical knowledge of emails and what the terms mean out him instantly as a liar. The fact this is still up on the front page is an embarrassment for the tech community in my opinion.
Are you going to apologize for being confidently wrong? Or confess your own incompetence and embarrassment?
> Update 1: Google Workspace Email Log
> Some commenters questioned whether I could reliably determine why Google rejected the email. Here's the screenshot from Google Workspace's admin email log search, showing the exact bounce reason . . .
I'll give you the benefit of the doubt and assume this wasn't in the original version rather than that you didn't actually read TFA, but it says straight up that it didn't make it to spam.
> Google's mail servers reject the message outright. It doesn't even get a chance to land in spam.
Dude, you keep on just believing a blog post even though it makes no technical sense. That's why none of the hardcore nerds are even approaching this and why Viva are going to sue.
An email bouncing means it was rejected because it did not find an inbox or a recipient. You AI to question if that is true. So if the email service provider says we don't know who that belongs to, why would they provide logs.
And what email service provider is rejecting an email over a RFC thing when millions of emails a day because most devs don't care about the RFCs and only an idiot would have two different mail infrastructure and code versions running for gmail and workspaces. Especially on the sending and receiving part.
So are you going to apologies for being confidently wrong? Because I'm technically and confidently right. Again, which is why the hardcore nerds are leaving this the fuck alone because they saw me wreck the post in minutes of it being posted.
Its not only likely, it is in fact the current position, at least in the US.
reply