zevv

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.

So many "Look what my LLM did now" posts.

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.

Halt And Catch Fire!

... which is from now on used by AI song generators to make sure their songs are not marked as AI generated by said tool.

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.

Which is is, vi or emacs?

Oooh, now I see. it's for harvesting robots, not for harvesting robots! Silly me.

Oh boy, I feel you, having no buttons is such a PITA. I've mapped my caps lock and windows button to LMB and RMB for years, works like a charm!

Could you summarize the contents of this video so we don't have to watch it?

And now try to load the same website over HTTPS

Well, there you are: https://github.com/MicroLua/MicroLua

That sounds like something the size of an ESP32.

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.

Or Snake on a Plane!

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.

Yes. This.

Sure, I own a smartphone, it runs just plain android but without any google accounts or services because I do not agree to Googles terms of services. I never did, and as an European citizen especially with recent developments I feel that has been the right choice.

The thing is, without google account there is no play store, and without play store I am not able to install the majority of apps - no banking, no parking, and all the other services people complain about in these threads.

This is my choice, and I stick to it. I'm also pretty vocal about it and complain when needed. Doctors office informs me I only can get medicine with the app? Apparently they can make exceptions when you complain, because I'm allowed to get medicine with a simple phone call. My bank tried to force me to use their app, but apparently they still do have an alternative login method when you complain. Sure, I know it's a fight I will lose in the long run, but I enjoy it while it lasts.

Summary: X is bad. How to do something without X? Don't do X

And monads. But I've heard they're just like burritos, so how hard can it be.

I've been a (professional?) embedded software engineer for 25 years. I tried rust a few times, but did not particularly enjoy the experience.

MY_GPIO.borrow(cs).borrow().as_ref().unwrap().odr.modify(|_, w| w.odr1().set_bit());

Congratulations. You have re-invented Forth.

The good thing is that you do not require a new language.

> he wants to be able to express programs, and even an operating system, as a directed acyclic graph of logical binary operations, so that you can have consistent and deterministic runtime behavior.

So how is this different from digital logic synthesis for CPLD/FPGA or chip design we have been doing over the last decades?

There is the excellent CAD sketcher plugin for Blender; this adds a basic 2D parametric/constraint based editor into your workflow, which can convert it's output into a mesh to integrate into your blender model. For more complicated models I typically make 2 or 3 2D constraint models, and use the blender boolean tools to combine this into the final 3D model.

https://www.cadsketcher.com/

One recurring pattern I have seen at multiple customer sites is that scaling makes the engineers lazy to optimize. One production performance calamity requires the team to add CPU as a quick fix, and from that time on the baseline for the product's requirement has been set to the new number of CPUs.

"Back in the olden days", if your product was slow but the number of CPUs was fixed (or could not be increased instantly), the solution was to go and fix your code.

Basic system level skills are now no longer taught or practiced at the appropriate levels, so teams end up without engineers who actually know how to profile and optimize.

The cloud providers are the big winners here.

It actually still scares the hell out of me that this is the way even the experts 'program' this technology, with all the ambiguities rising from the use of natural language.

Sure, so this clearly disrupts the transmission. But since there is strong encryption and authentication used in the Zigbee protocol, the chance of a mangled frame ending up at higher level in the protocol stack is approximately zero - anything messing up the frames will invalidate any hash so the receiver will discard these frames.