It's appropriate to think this way with LLM output because LLMs are still terrible some significant portion of the time. If you don't actually know what you're doing, you have no way to distinguish between their output being correct or their output being able to pass the tests you can think of.
As a software developer, your job is to understand code and business constraints so you can solve problems the way most appropriate for the situation. If you aren't actually keeping up with those constraints as they change through time, you're not doing your job. And yeah, that's a kind of fraud. Maybe it's more on yourself than your employer most of the time, but... It's your job. If you don't want to do it, maybe it's more respectful of your own time, energy, and humanity to move on.
"Ourselves" meaning people who have invested in Treasury Bills and other US bonds. Writing it off would mean eliminating massive amounts of wealth. That isn't really politically tenable for anyone.
That doent make any sense. There's no way we *sold* $1T of bonds and t-bills in 1 year.
That's what I'm asking who the debt actually belongs to. If it's "us", then how was it generated, who accepted the debt risk, and why's it going up faster?
Again, I make an analogy to $10000 tylenol pills, $16000 bandaids, and other obviously absurd medical fake number pricing. This $1T per year feels just as absurd and fake. And well, it's also a great wedge in Congress to bemoan and attack/shut down congress over that made up number.
Yes, we sold $1T of Bonds and t-bills. About half were sold to banks and foreign countries. The other half was sold to the social security retirement fund (in exchange for SS tax revenue)
The same reason you think it is absurd and fake is why others are panicking about the debt.
13% of federal taxes go to paying interest on the debt. That is 13 cents of every tax dollar paid. It is on track to hit 20% in the next 10 years, and that is assuming the US economy and tax revenue keeps growing.
Japan, UK, China, and the Cayman Islands are the largest private holders of US federal debt. [1]
What part of this seems incredible to you? It is indeed a lot of debt spending.
Why does $1T seem unreasonable? You can check the auction results, and from my quick look at a couple recent auctions, combined with knowledge that the auctions are routine and regularly scheduled, the number seems plausible.
It's not really $1T sold though, $1T would be the net sales, as many bonds and bills would have matured in the same period. Gross sales is much more than $1T, but I'm not going to dig through to find those numbers.
You could maybe discount some of the issuance as internal borrowing/lending/savings, but if you want to treat programs as independent, then the interactions between programs and the general budget are real enough.
That person is a problem because low-trust environments are inherently low-privacy and low-efficiency environments. Allowing a small portion of the population to destroy trust and then justifying it with "well there was no explicit rule against it" is parasitic on the whole society. It's better to stand up and say "this is unacceptable and clearly not what was asked for".
That is only as far as you or I are concerned. The environment where you first write the rules then someone can arbitrarily come and say nah that's not what we meant (with any consequences) is far worse than any low trust environment. Vague rules with selective/interpretative enforcement is in fact what authoritarian countries like Russia/China tend to use. Disturbing social harmony is illegal and all the right thinking people know it when they see it.
If the Internet goes away, Bitcoin goes away. That's a real threat in a bunch of conceivable societal failure scenarios. If you want something real, you want something that will survive the loss of the internet. Admittedly, what you probably want most in those scenarios is diesel, vehicles that run on diesel, and salt. But a pile of gold still could be traded for some of those.
Everyone always talk like societal collapse is global. Take a small pile of gold and use it to buy a plane ticket somewhere stable with internet and your bitcoin will be there waiting for you.
If you're replacing a chain of filters and maps with a nested loop, you're far past "a simple loop" and well into the realm of an unintelligible for loop. The chain of maps and filters tends to make that far easier to read by decomposing it into separately-comprehensible pieces.
Oh totally agreed; for complex transformations, being able to compose and tap the intermediate states is really nice (though I quite like generator/yielding functions with captured stack state as a happy medium).
But that’s not the claim
I was pushing back on. That claim was that, given a loop and some equivalent chained list-processing functions, primarily FP-taught people could not understand the loop due to their background. That’s bogus.
That complex loops are hard to understand for anyone is inarguable. But there’s not some magical “functional mindset” in which imperative/mutative code is unintelligible to the point of total obscurity and functional code is not. If there were, how would anything ever get rewritten in a functional style?
Reduce cannot calculate literally anything, in the sense you mean. It corresponds in computational power with primitive recursion. And quite famously, there are problems primitive recursion cannot solve that general recursion can.
On the other hand, I don't think I've ever seen something as recursive as Ackermann's function in real life. So it can probably solve any problem you actually mean to solve.
Naw, GP is right, I'd forgotten about the limits of primitive recursion. But for almost any given real-world problem, it's something you can get away with forgetting.
It isn't just an RPC spec, it's a use case. Specs never exist without a reason. I can assure you, a spec is a lot of work to write. You don't do it unless there is a purpose.
And with MCP, that purpose is fundamentally unsafe. It cannot be done safely without a different underlying technology. So yeah, it's pretty fair to say MCP is unsafe by design. It wouldn't exist except for that desire to create systems which cannot be secure.
MCPs are just fancy wrappers over rest apis, at least majority of the MCP servers out in the market are like that.
Having an MCP necessarily does not mean it is unsafe until and unless the company rushed execution and released something which it should not have in the first place.
Sorry, I don’t understand. My understanding of what MCP is - is that it’s just a standard on how to provide tools/functions to LLMs to call. What those functions are, what they do, and what else happens when they’re called is - in my understanding - out of scope of MCP. To me MCP is literally a plumbing between black boxes, and plumbing cannot do anything about the safety of what happens outside of it. So to me MCP is not “safe” or “unsafe” - those terms are meaningless for a plumbing (as long, of course, as plumbing itself doesn’t somehow explode or connect somewhere it’s not supposed to or stuff like that). Do you mean the purpose and/or scope are different somehow?
> My understanding of what MCP is - is that it’s just a standard on how to provide tools/functions to LLMs to call.
That's exactly the point the GP was making: this is a fundamentally unsafe idea. It's impossible to allow an LLM to automatically run tools in a safe way. So yes, MCP as means to enable this fundamentally unsafe use case is fundamentally unsafe.
My point is that the term “safe” is not a good one. In context of the article it erodes the scope of what MCP is and what it does (bringing way more stuff into the picture) and misattributes issue.
MCP safety is stuff like access controls, or lack of vulnerabilities on the protocol level (stuff like XML entity bombs). Software behavior of what MCP bridges together is not MCP anymore.
People discovering and running malware believing it’s legit is not a MCP problem. This line of thought is based on that “P” stands for “protocol” - MCP is interface, not implementation. And it’s humans who pick and connect programs (LLMs and MCP servers), not technology.
Not an XML bomb, but... at the protocol level, AFAIK, MCP allows the server to change its list of tools and what they do, and the description of what they do, at any point. The chatbot when it starts up, calls "tools/list" and gets a list of tools. So, if "approval for use" depends on that data, .. the approval is built on something that can shift at any time.
That, coupled with dynamic invocation driven by the LLM engine, seems like a security problem at the protocol level.
-----
Contrast to connecting an agent to a service that is defined by a spec. In this hypothetical world, I can tell my agent: "here's the spec and here's the endpoint that implements it". And then my agent will theoretically call only the methods in the spec. The endpoint may change, my spec won't.
I still need to trust the endpoint; that it's not compromised. Maybe I'm seeing a difference where there is none.
I thought about it, and I think I know what the confusion could possibly be about.
To me, postmark-mcp is not a part of MCP, it’s a black box that talks MCP on one end. And its behavior is not an MCP but software trust and distribution issue, not specific to MCP (just like running any executables from random sources). I guess others may see differently.
All other things being equal, yes. Static types work well for constraints on function parameters. "Parse, don't validate" and all that.
Some contracts are more difficult to express, though. The worst kind involve sequences of behavior, e.g. "start() must have been called," or "must have been obtained from a previous call to 'allocate()' on the same object."
Even value parameter constraints can be tricky. "The input must be sorted."
I haven't studied type systems, but I like the idea of values picking up attributes as they pass through functions. Imagine a "sort" function that bestows its output with the "sorted" type attribute. But then what happens when you append to that value? Is it still sorted?
At some point it's convenient to be permissive with the parameter's static type and to constrain the caller with a contract.
Turing completeness is irrelevant, as it only addresses computation. Security has to do with system access, not computational capacity. Brainfuck is Turing complete, but lacks any primitives to do more than read from a single input stream and write to a single output stream. Unless someone hooks those streams up to critical files, you can't use it to attack a system.
Language design actually has a lot of impact on security, because it defines what primitives you have available for interacting with the system. Do you have an arbitrary syscall primitive? Then the language is not going to help you write secure software. Is your only ability to interact with the system via capability objects that must be provided externally to authorize your access? Then you're probably using a language that put a lot of thought into security and will help out quite a lot.
As a software developer, your job is to understand code and business constraints so you can solve problems the way most appropriate for the situation. If you aren't actually keeping up with those constraints as they change through time, you're not doing your job. And yeah, that's a kind of fraud. Maybe it's more on yourself than your employer most of the time, but... It's your job. If you don't want to do it, maybe it's more respectful of your own time, energy, and humanity to move on.