lolinder

An equivalent argument to yours could be made to defend the introduction of async/await to a language that has previously not had it (edit: like Rust): if you don't like async/await, just don't use it! What does it hurt you to have another feature added?

The answer is obvious in the programming language case: for those who do not want async, the addition of async/await begins to poison the ecosystem. Now they have a growing list of libraries that they cannot use if they want to avoid async, so the effort involved in picking a library goes up and the odds get increasingly high that they're locked out of some of the key tools in the ecosystem because new libraries without async become harder and harder to find.

For those who really hate colored functions, the addition of async is the removal of a feature: colorless functions are replaced with colored functions.

The same can be said of NPM compatibility. Sure, I can try to avoid it and stick to Deno imports and inspect each library that I use for NPM dependencies. But it gets harder and harder as time goes on, because a key feature of Deno has been removed: it's no longer an ecosystem reset.

It misses the frontend/backend symmetry and has too large a coupling to Microsoft and Windows in my head. I know that these days it's supposed to be cross platform, but every time I've tried to figure out how to install it I get lost in the morass of nearly-identical names for totally different platforms and forget which one I'm supposed to be installing on Linux these days.

That doesn't mean there's anything wrong with it and I've often thought to give it another shot, but it's not a viable option right now for me because it's been too hard to get started.

For me Go doesn't even come close. It's way too restrictive in what I can and can't do with it.

I might feel differently if I worked with a large number of people who I didn't trust, but on small to medium teams composed of very senior people using Go feels like coding with one hand tied behind my back.

Yep. Honestly, the pivot to Node/NPM compatibility was the moment I lost interest in Deno. I know why they did it, and as you say from a financial perspective it makes complete sense, but they had the chance to be a fresh start to the whole ecosystem and they gave that up.

I really like coding in TypeScript and think that most of people's irritation with JavaScript isn't actually related to the language so much as the ecosystem of NPM. The exponentially growing web of dependencies and the constant churn of deprecations are exhausting, detracting from a core language that is now pretty solid.

Deno set out to change that and be something new, but they squandered that chance because it was too risky for their investors. And again, that's totally fair—resetting an ecosystem is risky and probably wouldn't have yielded the return they needed! But giving up on that was giving up on what made Deno different and interesting. If I'm going to use NPM anyway why not stick with Node while I'm at it?

Because out of all the languages that stand a chance of being adopted at most workplaces, TypeScript is in my opinion the single most enjoyable to code in. It has an extremely expressive type system that gets out of your way and allows you to model almost anything you can come up with, it has great IDE integrations on both VS Code and JetBrains, it has strong first-class support for functional programming patterns. On top of all the things the language itself has going fit it, it allows me to write the same language on frontend and backend, which in my experience actually does make a huge difference in avoiding context switching and which also helps with avoiding code duplication.

People like to sneer at TypeScript, but let's be honest: people like to sneer at anything that's popular enough. The fact is that no language that I enjoy better than TypeScript (which is already not a very long list) stands any chance of adoption in an average workplace.

In the same spirit if "it depends", there are other options that may work for people with different Linux/Windows balance points:

* Wine is surprisingly good these days for a lot of software. If you only have an app or two that need Windows it is probably worth trying Wine to see if it meets your needs.

* Similarly, if gaming is your thing Valve has made enormous strides in getting the majority of games to work flawlessly on Linux.

* If neither of the above are good enough, dual booting is nearly painless these days, with easy setup and fast boot times across both OSes. I have grub set to boot Linux by default but give me a few seconds to pick Windows instead if I need to do one of the few things that I actually use Windows for.

Which you go for really depends on your ratio of Linux to Windows usage and whether you regularly need to mix the two.

In some cases, sure, but not here—neither option had more risk associated with it than the other, it was just an optimization problem. The first answer that the model gave to my wife was just wrong about the math, with no room for subjectivity.

Yeah, I first thought of Hedy too. It doesn't keep them within the ecosystem but it does address the gradual intro problem and the localization problem.

That probably would work most of the time, but that's also an example of the phenomenon that TFA is talking about: you can't safely just use these tools without becoming an expert at least in the tool. The way they're currently being sold as totally accessible to everyone is dangerous.

Given the topic I'm unfortunately not comfortable sharing the details in a public space like this, but the answer that it gave was not just a misinterpretation of the question, it was actually entirely wrong on the merits of its own interpretation.

And even if it were a misinterpretation the result is still largely the same: if you don't know how to ask good questions you won't get good answers, which makes it dangerous to rely on the tools for things that you're not already an expert in. This is in contrast to all to people who claim to be using them for learning about important concepts (including lots of people who claim to be using them as financial advisors!).

I considered it, but given the personal nature of the topic I want to keep the details off the public internet. I realize that makes my observation less specific than it could be, but I think the result should be relatively unsurprising to anyone familiar with the tools—this is just a natural consequence of the way the stats fall out.

An example of the prompt engineering phenomenon: my wife and I were recently discussing a financial decision. I'd offered my arguments in favor of one choice and she was mostly persuaded but decided to check in with ChatGPT to help reassure herself that I was right. She asked the financial question in layman's terms and got the opposite answer that I had given.

She showed me the result and I immediately saw the logical flaws and pointed them out to her. She pressed the model on it and it of course apologized and corrected itself. Out of curiosity I tried the prompt again, this time using financial jargon that I was familiar with and my wife was not. The intended meaning of the words was the same, the only difference is that my prompt sounded like it came from someone who knew finance. The result was that the model got it right and gave an explanation for the reasoning in exacting detail.

It was an interesting result to me because it shows that experts in a field are not only more likely to recognize when a model is giving incorrect answers but they're also more likely to get correct answers because they are able to tap into a set of weights that are populated by text that knew what it was talking about. Lay people trying to use an LLM to understand an unfamiliar field are vulnerable to accidentally tapping into the "amateur" weights and ending up with an answer learned from random Reddit threads or SEO marketing blog posts, whereas experts can use jargon correctly in order to tap into answers learned from other experts.

To have a good mental model for modern AI agents you have to understand both the LLM and the other stuff that's built up around it. OP is correct about the behavior of LLMs, and that is valuable information to keep in mind. Then you layer on top of that an understanding that some implementations of agents will sometimes automatically feed search results into context, if you ask them to or are paying for an advanced tier or whatever the extra qualifications are for your particular tool.

If you skip this two-part understanding then you run the risk of missing when the agent decided not to do a search for some reason and is therefore entirely dependent on statistical probability in the training data. I've personally seen people without this mental model take an LLM at its word when it was wrong because they'd gotten used to it looking things up for them.

Ah, that makes sense. My brain inserted a "to" before "it".

Yeah, definitely don't do turn off auth for things that matter, if only because I'm not perfectly disciplined at keeping my guests off my main network. I'm talking about tiny services that do one thing—ollama, tts/stt, and similar. Stuff where the worst case scenario is someone using up some processor cycles, not data leaks.

You're right, but since when has long-term thinking been a feature of the average American business?

> it’s a waste of resources for seniors to be doing the work that the juniors and 2s can do. Hunting down infrequent or low priority bugs, fixing small layout issues, etc.

These are tasks that in the current environment often get pushed back for "later" indefinitely. These tasks aren't un-resourced because the company isn't hiring juniors, the company isn't hiring juniors because they no longer have the funds for small fixes.

Any serious approach to security begins with a reasonable and clearly defined threat model, and my threat model for my home network doesn't currently include a team of superheros targeting my file backups in an effort to save the world. But I'll definitely keep your advice in mind when I do decide to start executing on my evil plots.

For now my threat model consists of script kiddies and abusive corporations. Self-hosting gets me away from the corporations and keeping my stuff off of the public internet keeps me away from script kiddies.

A stochastic pattern to generate language-like text in the early 1400s is a lot more interesting than gibberish.

I'm not running a business, I'm running a home. The threat models are totally different and I adjust my security posture accordingly.

Besides, I don't bother with auth for simple services, not stuff that actually hosts data. If someone unauthorized is inside my network they're not going to be interested in using my TTS/STT service or in finding out the last barcode I scanned or in using my tiny consumer GPU to generate tokens on an LLM—there are way worse things they could be doing at that point than fiddling with the many tiny services I have set up.

Also: I couldn't set up so many silly, inconsequential services if I didn't have a VPN. With my setup, every new idea I have can be a quick service on my network accessible by me anywhere in the world. If I had to expose each of these things to the internet I wouldn't bother running them at all lest they have an exploit that ends up being an entrypoint into my network.

> Since my PKMS is hosted online to manage notes across devices, I have multiple layers of security to ensure my notes are kept private. {Screenshot of a login form}

The biggest life hack I can recommend for a self hoster is to set up a VPN on your local network and then just never expose your services on the public internet unless you're specifically trying to serve people outside your own household.

Before I did this I was constantly worried about the security implications of each app I thought about installing or creating. Now it's not even worth setting up auth on a lot of simple services I build because if someone is able to hit their endpoints I'm already in deep trouble for many other reasons.

Statistical analyses such as this one consistently find patterns that are consistent with a proper language and would be unlikely to have emerged from someone who was just putting gibberish on the page. To get the kinds of patterns these turn up someone would have had to go a large part of the way towards building a full constructed language, which is interesting in its own right.

I couldn't care less about Anthropic or MCP—as I noted, I'm a critic of MCP—but pedants bug me quite a bit especially when they're wrong.

> The API is fed into the LLM as context, the response is part of the output.

So you implement tool use by feeding an API into the LLM as context in order to get it to produce call parameters. Got it.

> Whether you pass that output through another layer of LLM is trivial. And even if you do, the "context" in that case would be only the response

So the output of the tool when called with those parameters can be fed back into the LLM as further context. Got it.

Given the above, it seems that we agree that tool use is implemented entirely by giving selected bits of context to the model.

With that in mind, if one were to design a protocol that makes tool use plug-and-play instead of something that has to be coded by hand for each tool—a protocol designed to allow a model to discover tool APIs that it might want to bring into context and then use those APIs to bring their outputs into context—it would be reasonable to call said protocol the Model Context Protocol, because it's all about getting specific bits of Context into a Model.

I'm not sure why the word "context" is the hill you decided to die on here when there is so much else to pick on with MCP, but it's time to get off the hill.

> But that's not what MCP does. It is a tool created by anthropic ( 2nd most used LLM) to provide portabiliry and vendor neutrality between different LLMs. It's like terraform for LLMs.

Given that your only contributions in this thread are to acknowledge your ignorance of MCP [0] and to post the summary dismissal upthread that shows your ignorance of it, it would probably behoove you to actually learn about MCP more before confidently making assertions about it. Suffice it to say that this is inaccurate and others have already explained in your "WTF is it" thread what MCP actually is.

> Also providing data through function calls/tool use is not context, you are overloading the term. Context is LLM context, if you fetch from a db it's something else

If you believe this then you don't understand how tool use is implemented. It's literally accomplished by injecting a tool's response into the context [1].

As a general life tip: most pedants are wrong most of the time. If you find yourself being pedantic, take a few steps back and double check that you're not just wrong.

[0] https://news.ycombinator.com/item?id=44011320

[1] https://platform.openai.com/docs/guides/function-calling

I mean, if you're paying for the subscription but never use it that's effectively a donation, right?

OP explains their motivation for not accepting small donations in another comment:

https://news.ycombinator.com/item?id=44014822

It's a pretty bad spec that has a lot of artifacts of having been generated by an LLM. But at least it exists!

I'm saying that as long as websites use the username/password model alongside passkeys with no way to turn off the former, you're just as at risk of phishing with passkeys as I am with domain-bound autofill.

Either one of us would have to choose to manually copy our logins into a phishing form in order to get phished.

I'm in a similar position to the author—running NixOS on a Framework 13 for about a year—and while I agree with some of their points I think I disagree with others.

> However, this means that your projects end up populated with Nix files, which is particularly annoying when you want to submit PRs to upstream projects

This is a legitimate gripe, but it does have a mitigation, which is to add those files to your global gitignore. The trade-off you make here is that you have to explicitly add the files to repos that actually do need them, but that's a one and done cost.

> I'm now responsible for configuring this entire system. I am also responsible for updating this system.

On the contrary, I have felt much less responsible for configuring and updating my whole system since switching to NixOS. Most of my system is just whatever the upstream channels are doing. My whole system config is maybe 300 lines long, and most of that is a list of the programs I want installed, which is something that I've always wished I could have on other distros but can't.

On other distros I have felt much more responsible for controlling my whole system because random crap would break all the time and I had to learn how it was configured. That has never happened to me on NixOS.

Also, containers are totally available on NixOS and I use them all the time. I've avoided flatpak so far not because it's not available but because I want to try to do things the NixOS way and I haven't felt the need to move away from fully declarative.

None of which is to say that NixOS is right for you or anyone in particular, but so far my experience has been that there is a very steep initial learning curve that you do get over. Maybe someday I'll give Fedora Bluefin a shot, but in the meantime I'm definitely not regretting leaving behind the traditional distro model.

This is a really shallow dismissal, and I say that as someone who is outspokenly critical of MCP [0].

As you yourself say, the context is the text that is fed as input at runtime to an LLM. This text could just always come from the user as a prompt, but that's a pretty lousy interface to try to cram everything that you might want the model to know about, and it puts the onus entirely on the user to figure out what might be relevant context. The premise of the Model Context Protocol (MCP) is overall sound: how do we give the "Model" access to load arbitrary details into "Context" from many different sources?

This is a real problem worth solving and it has everything to do with the technical meaning of the word "context" in this context. I'm not sure why you dismiss it so abruptly.

[0] https://news.ycombinator.com/item?id=43949503

That's what TFA is arguing we should do.