Is this a EU-specific thing? In North America I've never installed a banking app, don't even know if my institution even has one.

The US is way, way behind in banking P2P technology / fintech adoption. In many parts of Asia, even uneducated street vendors now accept digital payments via mobile phones (that's how easy it is). See - https://www.forbes.com/sites/pennylee/2024/04/17/the-us-lags... and

I would rather not have the kind of "financial innovation" that requires non-free apps running on non-free operating systems on locked down hardware. These apps, by design, track how people spend their money.

I cannot stress how much I do not care. Nor does anyone else.

I want to be able to run software on my device, not fulfill some nuts low-rent fantasy that they're a rebel against the government.

Traditional banks have about as much data about how you spend your money as any modern fintech. The banking system is non-free, locked down and centralized to begin with. How you access it is just a matter of cosmetics and policies.

> These apps, by design, track how people spend their money.

That depends - In India, for example, I am free to use either (1) a private company's app (like PayTM, Google Pay, PaisePe etc.) (2) a Government app or (3) my Bank's app to make digital payment using the Unified Payment Interface (UPI) (or all 3). And, if I don't want to use any mobile app, I can still make offline payment through my mobile phone over USSD - https://razorpay.com/blog/how-to-make-offline-upi-payments/ ...

(You are right though that it is prone to abuse in the absence of strong privacy and data protection laws - digital payment does allow new form of surveillance capitalism to the corporates and new avenues of authoritarian control to the government).

These things are amazing for maintenance programming on very large codebases (think, 50-100million lines of code or more, the people who wrote the code no longer work there, it's not open source so "just google it or check stack overflow" isn't even an option at all.)

A huge amount of effort goes into just searching for what relevant APIs are meant to be used without reinventing things that already exist in other parts of the codebase. I can send ten different instantiations of an agent off to go find me patterns already in use in code that should be applied to this spot but aren't yet. It can also search through a bug database quite well and look for the exact kinds of mistakes that the last ten years of people just like me made solving problems just like the one I'm currently working on. And it finds a lot.

Is this better than having the engineer who wrote the code and knows it very well? Hell no. But you don't always have that. And at the largest scale you really can't, because it's too large to fit in any one person's memory. So it certainly does devolve to searching and reading and summarizing for a lot of the time.

Good on the Arduino folks for getting acquired, then. They still have a niche and a brand with name recognition, even if that niche might be stable at best, collapsing at worst.

Quite a few radar systems are in the 8-10GHz range and satellite communications just above that. The general idea when using a SDR for these things is to have a separate frequency converter & amplifier at the antenna feed itself, then have an intermediate frequency <6GHz fed via cable to the SDR. Tends to be much easier and cheaper this way.

The threading model is still difficult, and it's still enough slower that thinking you're going to be comparable to custom silicon that's been designed for a particular protocol is silly.

It's great fun for doing signal analysis, but I'd never want to try and implement a full-duplex communication system in production with it.

If I were doing SDR-based comms in production, a custom C (or C++) application would be on the table, and nothing else.

The more fine-grained you make a capability system, the more you have an explosion of the number of permissions required by an application, and the chance that some combination of permissions grants more access than intended.

It also requires rewriting all your apps.

It also might require hardware support to not be significantly slower.

"Just sandbox each app" has much fewer barriers to entry, so people have been doing that instead.

And systems like Android have been working with discrete permissions / capabilities, because they were able to start from scratch in a lot of ways, and didn't need to be compatible with 50 years of applications.

LLMs are approximately your employees on their first day of work, if they didn't care about being fired and there were no penalties for anything they did. Some percentage of humans would just pull the nearest fire alarm for fun, or worse.

A good simplification of what's going on is this little loop:

1. LLM runs using the system prompt + your input as context.

2. Initial output looks like "I need more information, I need to run <tool>"

3. Piece of code runs that looks for tool tags and performs the API calls via MCP.

4. Output of the tool call gets appended as additional context just as if you'd typed it yourself as part of your initial request.

5. Go back to step 1, run the LLM again.

So you can see here that there is no difference between "content" and "prompt". It's all equivalent input to the LLM, which is calling itself in a loop with input that it generated/fetched for itself.

A lot of safety here happens at step #3, trying to look at the LLM's output and go "should I actually perform the tool call the LLM asked for?". In some cases, this is just spitting the tool call at the user and asking them to click Approve/Deny... and after a hundred times the user just blindly presses Approve on everything, including the tool call called "bash(sudo rm -rf /)". Pwned.

Ah, thanks for that break down, makes perfect sense now.

Putting aside the "LLM" part, it seems very similar to the situation where we don't just "exec" stuff from inside code that takes user input, because you're opening up a can of security worms.

1. If you want to advance the state of the art as quickly as possible (or have many, many experiments to run), being able to iterate quickly is the primary concern.

2. If you are publishing research, any time spent beyond what's necessary for the paper is a net loss, because you could be working on the next advancement instead of doing all the work of making the code more portable and reusable.

3. If you're trying to use that research in an internal effort, you'll take the next step to "make it work on my cloud", and any effort beyond that is also a net loss for your team.

4. If the amount of work necessary to prototype something that you can write a paper with is 1x, the amount of work necessary to scale that on one specific machine configuration is something like >= 10x, and the amount of work to make that a reusable library that can build and run anywhere is more like 100x.

So it really comes down to - who is going to do the majority of this work? How is it funded? How is it organized?

This can be compared to other human endeavours, too. Take the nuclear industry and its development as a parallel. The actual physics of nuclear fission is understood at this point and can be taught to lots of people. But to get from there to building a functional prototype reactor is a larger project (10x scale), and then scaling that to an entire powerplant complex that can be built in a variety of physical locations and run safely for decades is again orders of magnitude larger.

Where it really has value is if what you work on is like 33% extremely difficult and 66% boilerplate/tedious. Being able to offload the tedious bits can make more senior engineers 2-3x more productive without the coordination effort of "find a junior engineer to do this, schedule their time, assign the work, follow up on it".

(The problem of course is you still need these junior engineers to exist in order to have the next generatino of senior engineers, so we must now also think about what our junior folks should be doing to be valuable AND learn).