andrew0

Get llama.cpp and try Qwen3.6-35B-A3B. Just came out and looks good. You’ll have to look into optimal settings, as it’s a Mixture of Experts (MoE) model with only 3B parameters active. That means that the rest can stay in RAM for quick inference.

You could also try the dense model (Qwen3.5-27B), but that will be significantly slower. Put these in a coding harness like Oh-My-Pi, OpenCode, etc. and see how it fares for your tasks. Should be ok for small tasks, but don’t expect Opus / Sonnet 4.6 quality, more like better than Haiku.

There must be something that ensures the response is legitimate. Otherwise, if it’s client-side and fully offline, I can just spoof the app to return the response “Yes, over 18”. If it’s not the government doing the verification, it’s Google or Apple, which will give them access to all the “adult” websites you visit. Also, another reason for the EU to push for strict device attestation, without any DIY stuff (i.e., no more GrapheneOS, LineageOS, etc).

I couldn’t find a desktop app on the EU’s GitHub (another red flag, btw, using GitHub for this). All that seems to be available is code for the Android or iOS apps. Could you share it, if you can?

Even with the Zero Knowledge approach, you will still run an app on a phone (what if I don’t have one) that will make some call to the government’s servers, which will most likely know what website you’re trying to access. We’re moving the data mining from some third party to the government, which can be wrongly used later if some idiot comes into power. If it’s not making a call to a government’s servers, I would be surprised, since you could imagine someone just bypassing this to always return “Over 18”.

Even funnier (read “sad”), this initiative will probably rely on Google and Apple to keep it robust, and will likely have no availability on rooted phones or non-Google Play Services ones. It’s premature at best to deploy this in a meaningfully safe way.

I have a friend who set up a Dreame L10s Ultra. I helped them solder the breakout board, and was there when they flashed the new firmware. Relatively straight forward! Just follow the guide on the website and you should be good.

The robot is now accessible only on the local network, and they got it working in Home Assistant. The only feature that is missing now is direct camera view, which the original robot had. Basically, you could get a live feed of the robot’s camers at any time. Looked fun, but it was not necessary.

This article just screams rage-bait. Not that I am against making people aware of this kind of privacy invasion, but the authors did not bother to do any fact checking.

Firstly, they mention that the vacuum was “transmitting logs and telemetry that [the guy] had never consented to share”. If you set up an app with the robot vacuum company, I’m pretty sure you’ll get a rather long terms and services document that you just skip past, because who bothers reading that?

Secondly, the ADB part is rather weird. The person probably tried to install Valetudo on it? Otherwise, I have no clue what they tried to say with “reprinting the devices’ circuit boards”. I doubt that this guy was able to reverse engineer an entire circuit board, but was surprised when seeing that ADB is enabled? This is what makes some devices rather straight forward to install custom firmware that block all the cloud shenanigans, so I’m not sure why they’re painting this as a horrifying thing. Of course, you’re broadcasting your map data to the manufacturer so that you can use their shitty app.

The part saying that it had full root access and a kill-switch is a bit worse, but still… It doesn’t have to be like this. Shout-out to the people working on the Valetudo project. If you’re interested in getting a privacy-friendly robot vacuum, have a look at their website. It requires some know-how, but once it’s done, you know for sure you don’t need to worry about a 3rd party spying on you.