Self-Hosted Chatbot Focuses On Privacy

Large language models (LLMs) have been all the rage lately, assisting from all kinds of tasks from programming to devising Excel formulas to shortcutting school work. They’re also relatively easy to access for the most part, but as the old saying goes, if something on the Internet is free the real product is you (and your data). Luckily there are ways of hosting LLMs on your own to avoid your personal data getting harvested, as well as taking advantage of open-source solutions, but building these systems takes a little bit of effort. [Stephen] and a team from Mozilla walk us through this process and show us a number of options currently available.

Working from the ground up, the group first decides on hosting, which (unsurprisingly) involves using Mozilla hosting services. The choice of runtime environment was a little bit more challenging. The project was time constrained, so they looked at two options here: Hugging Face and llama.cpp. Eventually deciding to move forward with llama.cpp largely due to its ability to run on more consumer-oriented hardware (especially Apple silicon) and the fact that it doesn’t need a powerful GPU, the next task was to choose the model. Settling on the LLaMa model that Facebook recently open-sourced, this model works well with the runtime environment and is essentially the only one that does.

From there, the team at Mozilla wanted to make sure their chat bot would be able to provide other Mozilla employees with information more readily pertinent to their jobs, so they trained their model with some internal Mozilla data as well as other more generic information. This doesn’t mean the job is done, though, there are a number of other factors that went in to designing this system before it was finally complete. Even then, since they built this in a week it’s not perfect; there are some issues with non-permissive licensing of some of the components and many of the design choices may not have been ideal. It’s impressive what’s out there if you’re hosting your own system, though, and while this might be a little more advanced for a self-hosted project, take a look at some other more beginner-friendly projects you can try if you’re just starting out on the self-hosted path.

The ESP32 Doesn’t Need Much

For those looking to add wireless connectivity to embedded projects or to build IoT devices, there is perhaps no more popular module than the ESP32. A dual-core option exists for processor intensive applications, the built-in WiFi and Bluetooth simplify designs, and it has plenty of I/O, memory, and interoperability for most applications. With so much built into the chip itself, [atomic14] wondered how much support circuitry it really needed and set about building the most minimalist ESP32 development board possible.

Starting with the recommended schematic for the ESP32, the most obvious things to remove are a number of the interfacing components like the USB to UART chip and the JTAG interface. The ESP32 has USB capabilities built in, so the data lines from a USB port can be directly soldered to the chip instead of using a go-between. A 3.3V regulator eliminates the need for many of the decoupling capacitors, and the external oscillator support circuitry can also be eliminated when using the internal oscillator. The only thing [atomic14] adds that isn’t strictly necessary is an LED connected to one of the GPIO pins, but he figures the bare minimum required to show the dev board can receive and run programs is blinking an LED.

Building the circuit on a breadboard shows that this minimalist design works, but instead of building a tiny PCB to solder the ESP32 module to he attempted to build a sort of dead-bug support circuit on the back of the ESP32. This didn’t work particularly well so a tiny dev board was eventually created to host this small number of components. But with that, the ESP32 is up and running. These modules are small and compact enough that it’s actually possible to build an entire dev board setup inside a USB module for a Framework laptop, too.

Continue reading “The ESP32 Doesn’t Need Much”

A Deep Dive On Battery Life

There are all kinds of old wives’ tales surrounding proper battery use floating around in the popular culture. Things like needing to fully discharge a battery every so often, unplugging devices when they’re fully charged, or keeping batteries in the fridge are all examples that have some kernel of truth to them but often are improperly applied. If you really want to know the truth about a specific battery, its behavior, and its features, it helps to dig in and actually take some measurements directly like [Tyler] has done with a vast array of embedded batteries in IoT devices.

[Tyler] is a firmware engineer by trade, so he is deeply familiar with this type of small battery. Battery performance can change dramatically under all kinds of scenarios, most important among them being temperature. But even the same type of battery can behave differently to others that are otherwise identical, which is why it’s important to have metrics for the batteries themselves and be able to measure them to identify behaviors and possible problems. [Tyler] has a system of best practices in place for monitoring battery performance, especially after things like firmware upgrades since small software changes can often have a decent impact on battery performance.

While working with huge fleets of devices, [Tyler] outlines plenty of methods for working with batteries, deploying them, and making sure they’re working well for customers. A lot of it is extremely useful for other engineers looking to develop large-scale products like this but it’s also good knowledge to have for those of us rolling out our own one-off projects that will operate under battery power. After all, not caring for one’s lithium batteries can have disastrous consequences.

Serious Vulnerability In European Trunked Radio System

Trunked radio systems can be difficult to wrap one’s mind around, and that’s partially by design. They’re typically used by organizations like police, firefighters, and EMS to share a limited radio frequency band with a much larger number of users than would otherwise be able to operate. From a security standpoint, it also limits the effectiveness of scanners who might not know the control methods the trunked systems are using. But now a global standard for encrypted trunked radio systems, known as TETRA, has recently been found to have major security vulnerabilities, which could result in a lot more headache than disrupted voice communications.

One of the vulnerabilities in this radio system was a known backdoor, which seems to have been protected largely via a “security through obscurity” method. Since the system has been around for about 25 years now, it was only a matter of time before this became public knowledge. The backdoor could allow non-authorized users to snoop on encrypted radio traffic. A second serious vulnerability, unrelated to this backdoor, would further allow listening to encrypted voice traffic. There are a few other minor vulnerabilities recently uncovered by the same security researchers who found these two major ones, and the current recommendation is for anyone using a TETRA system to take a look to see if they are impacted by any of these issues.

Part of the reason this issue is so concerning is that these systems aren’t just used for encrypted voice among first responders. They also are used for critical infrastructure like power grids, rail networks, and other systems controlled by SCADA. This article from Wired goes into much more detail about this vulnerability as well, and we all know that most of our infrastructure already needs significant help when it comes to vulnerabilities to all kinds of failure modes.

Thanks to [cfacer] and [ToniSoft] who sent these tips!

Photo via Wikimedia Commons.

No Fish Left Behind

For hundreds of years, Icelanders have relied on the ocean for survival. This is perhaps not surprising as it’s an isolated island surrounded by ocean near the Arctic circle. But as the oceans warm and fisheries continue to be harvested unsustainably, Iceland has been looking for a way to make sure that the fish they do catch are put to the fullest use, for obvious things like food and for plenty of other novel uses as well as they work towards using 100% of their catch.

After harvesting fish for food, most amateur fishers will discard around 60% of the fish by weight. Some might use a portion of this waste for fertilizer in a garden, but otherwise it is simply thrown out. But as the 100% Fish Project is learning, there are plenty of uses for these parts of the fish as well. Famously, cod skin has been recently found to work as skin grafts for humans, while the skin from salmon has been made into a leather-type product and the shells of crustaceans like shrimp can be made into medicine. The heads and bones of fish can be dried and made into soups, and other parts of fish can be turned into things like Omega-3 capsules and dog treats.

While we don’t often feature biology-related hacks like this, out-of-the-box thinking like this is an important way to continue to challenge old ideas, leave less of a footprint, improve human lives, and potentially create a profitable enterprise on top of all of that. You might even find that life in the seas can be used for things you never thought possible before, like building logic gates out of crabs.

Thanks to [Ben] for the tip!

Debian Officially Adds RISC-V Support

As time goes on, more and more computer manufacturers are moving towards the ARM architecture and away from the bloated and outdated x86 instruction set. Apple is the most prominent producer to take this step, but plenty others are using ARM for its flexibility and efficiency. The only problem with ARM is that it’s licensed, so if you want to go even further down the open-source path the RISC-V instruction set is the next logical step. Now at least one mainline Linux distribution will officially support this architecture.

While Debian did have some support for RISC-V before this as a Debian port, which was not officially part of Debian. However, the official support will begin with the release of Debian 13, which is currently in the testing phase and hasn’t seen a stable release yet. To that end, the current state of this official version is extremely limited, being described as “almost empty” but with planned support for an initial 90 packages in the coming days. Most users working on a RISC-V platform will most likely to continue to use their Debian ports version.

It might be a little while before the RISC-V version is as full-featured as the ARM or x86 versions of this Linux distribution, but we are happy to see it move in this direction at all. And don’t think that RISC-V is limited to embedded systems or otherwise limited computing platforms, either. We’ve seen full Linux desktops with RISC-V processors since at least 2019.

Car Security System Monitors Tiny Voltage Fluctuations

As the old saying goes, there’s no such thing as a lock that can’t be picked. However, it seems like there are plenty of examples of car manufacturers that refuse to add these metaphorical locks to their cars at all — especially when it comes to securing the electronic systems of vehicles. Plenty of modern cars are essentially begging to be attacked as a result of such poor practices as unencrypted CAN busses and easily spoofed wireless keyfobs. But even if your car comes from a manufacturer that takes basic security precautions, you still might want to check out this project from the University of Michigan that is attempting to add another layer of security to cars.

The security system works like many others, by waiting for the user to input a code. The main innovation here is that the code is actually a series of voltage fluctuations that are caused by doing things like turning on the headlights or activating the windshield wipers. This is actually the secondary input method, though; there is also a control pad that can mimic these voltage fluctuations as well without having to perform obvious inputs to the vehicle’s electrical system. But, if the control pad isn’t available then turning on switches and lights to input the code is still available for the driver. The control unit for this device is hidden away, and disables things like the starter motor until it sees these voltage fluctuations.

One of the major selling points for a system like this is the fact that it doesn’t require anything more complicated than access to the vehicle’s 12 volt electrical system to function. While there are some flaws with the design, it’s an innovative approach to car security that, when paired with a common-sense approach to securing modern car technology, could add some valuable peace-of-mind to vehicle ownership in areas prone to car theft. It could even alleviate the problem of cars being stolen via their headlights.

Continue reading “Car Security System Monitors Tiny Voltage Fluctuations”