It's often found alongside natural gas because the rock structures that can trap methane can also trap other gasses, but the original source is different - thermal decomposition of organic matter for natural gas and radioactive decay, mostly of uranium and thorium, for helium.
I agree that the "accumulation over millions of years" is similar (and similarly a potential problem if we burn through all that accumulation).
Helium will leak out of some structures that hold methane. Shale will trap methane and let helium escape. Layers of salt trap both. Thus horizontal drilling and fracking to recover oil and methane from shale produces very little helium.
Obvious example is a corporate chatbot (if it's using tools, probably for internal use). Non-technical users might be accessing it from a phone or locked-down corporate device, and you probably don't want to run a CLI in a sandbox somewhere for every session, so you'd like the LLM to interface with some kind of API instead.
Although, I think MCP is not really appropriate for this either. (And frankly I don't think chatbots make for good UX, but management sure likes them.)
This is obviously not what it is. If I give you APIGW would you be able to implement an MCP server with full functionality without a large amount of middleware?
I’ve implemented an MCP tool calling client for my application, alongside OAuth for it. It was hard but no harder than anything else similar. I implemented a client for interference with the OpenAI API spec for general inference providers, and it was similarly as hard. MCP. SDKs help make it easy; MCP servers are dead simple. Clients are the hard part, IMO.
MCP is basically just an RPC API that uses HTTP and JSON, with some other features useful for AI agents today.
The chatbot app initiates an OAuth flow, user SSOs, chatbot app receives tokens to its callback URL, then tool calls can access whatever the user can access.
If you use the official MCP SDK, it has interfaces you implement for auth, so all you need to do is kick off the OAuth flow with a URL it figures out and hands you, storing the resulting tokens and producing them when requested. It also handles using refresh tokens, so there's just a bit of light friendly owl finishing on top.
Source: I just implemented this for our (F100) internal provider and model agnostic chat app. People can't seem to see past the coding agents they're running on their own machines when MCP comes up.
MCP really only makes sense for chatbots that don’t want to have per session runtime environments. In that context, MCP makes perfect sense. It’s just an adapter between an LLM and an API. If you have access to an execution engine, then yes CLI + skills is superior.
Only is doing a lot of work here. There are tons of use cases aside from local coding assistants, e.g., non-code related domain specific agentic systems; these don’t even necessarily have to be chatbots.
OP's point is about per session sandboxes, not them necessarily being "chatbots". But if you don't burry the agent into a fresh sandbox for every session you have bigger problems to worry about than MCP vs CLI anyway
The idea is the opposite - "nobody" can make money selling software anymore, because software can be cheaply created by an LLM, so you want to start a business that previously would have had to buy software/software engineers in order to support some other product.
However, even if that holds true (which is a big if - right now I wouldn't want to run a business backed by vibe software), and even if there are enough such business ideas to go around, there's going to be quite a lot of turmoil in the meantime.
I don't think that's true. SW that works is still expensive to produce. SW that kind of works is super easy to do. The money is in making SW that works. You still need expertise for that.
There's a fallacy here around how software is fungible. WordPress hasn't made web developers obsolete, despite everybody having access to a $5/mo WYSIWYG-and-domains-and-hosting-bundle environment; quite the opposite, in fact.
I'm seeing the parent's point along these lines: "me and all my friends are starting businesses being the middlemen between WordPress and (people who want websites)". It's not that it won't work, it's just a shit business model.
Whisper is still old reliable - I find that it's less prone to hallucinations than newer models, easier to run (on AMD GPU, via whisper.cpp), and only ~2x slower than parakeet. I even bothered to "port" Parakeet to Nemo-less pytorch to run it on my GPU, and still went back to Whisper after a couple of days.
It's interesting to me that all AI music sounds slightly sibilant - like someone taped a sheet of paper to the speaker or covered my head in dry leaves. I know no model is perfect but I'd have thought they'd have ironed out this problem by now, given how pervasive it is and how significantly it degrades the end product.
I've noticed this too. I have a few theories about this. Disclosure: I know a little about audio, and very little about audio generative AI.
First, perhaps the models are trained on relatively low-bitrate encodings. Just like image generations sometimes generate JPG artifacts, we could be hearing the known high-frequency loss of low data rate encodings. Another idea is that 'S' and 'T' sounds and similar are relatively broad-spectrum sounds. Not unlike white noise. That kind of sound is known to be difficult to encode for lossy frequency-domain encoding schemes. Perhaps these models work in a similar domain and are subject to similar constraints. Perhaps there's a balance here of low-pass filter vs. "warbly" sounds, and we're hearing a middle ground compromise.
I don't know how it happens, but when I hear the "AI" sound in music, this is usually one of the first tells.
Agreed. I find that particularly annoying, and I also seem to find that the spatial arrangement or stereo effect is muted for most instruments (or the model simply doesn't use that feature as well as a good human musician).
I suspect it's because AI generates music as a waveform incrementally not globally so it favors smoothly varying sounds, not sharp contrast. If it generated MIDI data and then used a MIDI synth to create the audio, you wouldn't get that.
Do you work for iNaturalist? If so, please clarify if this commitment is official and whether it includes the full build process to achieve replicable builds and input data not just a build artifact (which would not be replicable, and therefore not be Science under iNaturalist's public interest Science tax-shelter status).
The implication is that there is (should be) a major speed difference - naively you'd expect the MoE to be 10x faster and cheaper, which can be pretty relevant on real world tasks.
Gemma will give you the most, Gemini will give you the best. The former is much smaller and therefore cheaper to run, but less capable.
Although I'm not sure whether Gemma will be available even in aistudio - they took the last one down after people got it to say/do questionable stuff. It's very much intended for self-hosting.
reply