Of course also in this case it helps - sandbox it so it does not leak info between sessions. Global agent memory is like sharing your browser cookies over all domains.
It's not that hard: Do not rely on your agent to behave when it comes to security, ever. Do not trust your agent to not access your files. Do not trust your agent to not drop your tables.
Just treat it as untrusted software: sandbox it. It takes some effort, but really, just sandbox it. Always.
Not really that surprising: all logic that used to be in the code is now in the model; the only code that is left is some glue to connect the outside world to the number crunching, just like Llama2 runs your LLMs with only 700 lines of C.
They're eating the code. They're eating the algorithms.
What works pretty well for me is the "i don't care about cookies" extension for firefox; my default privacy policy is to throw away cookies when the browser restarts, which I do a few times per day anway.
Assuming your flash allows XIP (execute in place) so all that memory is available for your lua interpreter data, you should at least be able to run some code, but don't expect to run any heavy full applications on that. I don't know Berry but it sounds like a better fit for the scale of your device.
But sure, why not give it a try: Lua is usually easy to port to whatever platform, so just spin it up and see how it works for you!
I have been developing Lua-heavy embedded products as a freelancer for about 20 years now, including VoIP devices, home automation controllers, industrial routers, digital video recorders, and more. These systems typically consist of a Linux kernel, some libc implementation, the lua interpreter and a few 3d party libs support libs to help building the app. The Lua apps ranges from 30k to 100k lines of code, depending on the application. Some of these devices can be considered 'small' in 2025 terms: 8MB of flash, 64MB of ram. Lua is doing great here.
All of these products are still alive today, actively supported and making my customers good money.
Some things come very natural to Lua: Lua <=> C interfacing is a breeze, and while some modern languages are still struggling to figure out how to do proper async, Lua has been able to do this for decades. The language itself is minimal and simple but surprisingly powerful - a few smart constructs like coroutines, closures and metatables allow for a lot of different paradigms.
For new projects at this scale, I would still choose Lua + C/C++ as my stack. Over the last few years I have been visiting other ecosystems to see what I'm missing out on (Elixir, Rust, Nim), and while I learned to love all of those, I found none of them as powerful, low-friction and flexible as Lua.
I'm afraid it would: in 2002 I was involved with the development of a very early wifi AP implementation at Freehosting; this was running uclinux on an ARM7 with a pretty bare kernel and the whole OS fitting in under a megabyte. Booting was already pretty much instantaneous then.
This article is partly wrong, and partly nonsense. Apples and oranges. But still:
> Work with only 3 files [...] Boot in under 5 seconds [...] Use commands without spaces [...] Run CPU opcodes natively [...] Be real
I have a little PCB here on my desk that runs linux with 2 files: vmlinux and busybox. It boots in about two seconds and yes, it runs CPU opcodes natively.
I'm not sure how being able to use commands without spaces or running in real mode is considered better or worse than the alternatives.
So, what will be the proper technology to apply here? I have no problem with verification of my age (not the date of birth, just the boolean, >18yo), but I do have a problem with sending any party a picture of my face or my passport.
I might be mistaking, but I don't see how this is novel. As far as I know, this has a proven DSP technique for ages, although it it usually only applied when a small amount of distinct frequencies need to be detected - for example DTMF.
When the number of frequencies/bins grows, it is computationally much cheaper to use the well known FFT algorithm instead, at the price of needing to handle input data by blocks instead of "streaming".
“we’re back where we started four years ago, hard coding everything, except now in a much crappier language.”
Not sure if I agree with this. A proper designed DSL has the advantage of being much closer to the domain of the problem it is supposed to solve. Your code written in the DSL now might end up as 'hard coded' part of the application, but it likely conveys much more meaning in much less code because it is tailored to the core functionality of the application.