2026-01-10 08:00:06
After initially announcing that Bose will completely turn off all ‘smart’ features in its SoundTouch series of speaker products, the company has seemingly responded to the wave of unhappy feedback with a compromise solution. Rather than the complete shutdown and cut-off that we reported on previously, Bose will now remove cloud support as its servers shut down, but the SoundTouch mobile app will get an update that gets truncated to just the local support functions. Bose also made the SoundTouch Web API documentation available as a PDF document.
The shutdown date has also been extended from the original February 18 to May 6th of this year. Although these changes mean that the mobile app can no longer use music services, features like grouping speakers and controlling playback will keep working. Features such as presets which were cloud-based will naturally stop working.
With the web API documentation made public it remains to be seen how helpful this will be. From a quick glance at the PDF documentation it appears to be a typical REST API, using HTTP on port 8090 on the SoundTouch device, with an SGML-style tag system to format messages. In so far as the community hasn’t already reverse-engineered this API it’s at least nice to have official documentation.
2026-01-10 05:00:40
You can hear sound, of course, but what if you could see it with a laser? That’s what [Goosetopherson] thought about, and thus a new project that you can see in the video below was born.
The heart of the project is an I2S chip and an ESP32. Sound energy deforms a plastic film that causes a mirror to move. The moving mirror alters the course of the laser’s beam.
An important part of the project is the 3D printed enclosure designed in Fusion. Some wires are routed through during printing, and there are heat-set inserts.
If you haven’t run into it before, you can think of I2S as I2C for stereo audio. It uses a synchronous protocol to push audio data using three wires. The board in question takes the digital data and decodes it to drive the speaker.
This is a simple project that would lend itself to lots of substitutions if you decide to replicate it. In fact, we’ve seen a version of this that is nothing more than a Bluetooth speaker, some plastic film, a mirror, and a laser.
2026-01-10 03:30:26
If you’re building a project on your ESP32, you might want to give it a fancy graphical interface. If so, you might find a display library from [dejwk] to be particularly useful.
Named roo_display for unclear reasons, the library is Arduino-compatible, and suits a wide range of ESP32 boards out in the wild. It’s intended for use with common SPI-attached display controllers, like the ILI9341, SSD1327, ST7789, and more. It’s performance-oriented, without skimping on feature set. It’s got all kinds of fonts in different weights and sizes, and a tool for importing more. It can do all kinds of shapes if you want to manually draw your UI elements, or you can simply have it display JPEGs, PNGs, or raw image data from PROGMEM if you so desire. If you’re hoping to create a touch interface, it can handle that too. There’s even a companion library for doing more complex work under the name roo_windows.
If you’re looking to create a simple and responsive interface, this might be the library for you. Of course, there are others out there too, like the Adafruit GFX library which we’ve featured before. You could even go full VGA if you wanted, and end up with something that looks straight out of Windows 3.1. Meanwhile, if you’re cooking up your own graphics code for the popular microcontroller platform, you should probably let us know on the tipsline!
Thanks to [Daniel] for the tip!
2026-01-10 02:00:44
Food poisoning is never a fun experience. Sometimes, if you’re lucky, you’ll bite into something bad and realize soon enough to spit it out. Other times, you’ll only realize your mistake much later. Once the tainted food gets far enough into the digestive system, it’s too late. Your only option is to strap in for the ride as the body voids the toxins or pathogens by every means available, perhaps for several consecutive days.
Proper food storage and preparation are the key ways we avoid food poisoning today. However, a new development could give us a further tool in the fight—with scientists finding a way to actively hunt down and destroy angry little pathogens before they can spoil a good meal.
Food poisoning cases tend to boil down to two categories—those involving toxins, and those involving bacterial pathogens. In either case, affected food must be destroyed. Particularly in the latter case, as bacteria reproduce—even the tiniest contamination will quickly spiral in size.
However, new research published in Scientific Advances may have a solution to the problem of bacterial-based food poisoning. It involves using patches to deliver specially-crafted viruses to fight and kill the bacteria that would otherwise infect and sicken a human who eats the food. The patches are to be applied to the food itself—attacking and killing the bacteria before the food is eaten.
The viruses in question are bacteriophages—specifically, viruses that can infect bacteria and reproduce within them from its own genetic material. When a bacteriaphage virus comes into contact with certain bacteria, it breaches the cell’s wall, typically with a syringe-like motion in which the viral genetic material is injected into the cell. Once inside, the genetic material is processed by the bacteria and reproduces more phages that can then go on to infect further bacteria. In the specific case of lytic phages, the bacterial cells are quickly destroyed as the virus reproduces inside, spreading the new phages quickly and killing the original host.
Two bacteriophages were used in this research. The T7 phage was chosen for its ability to infect and kill Escherichia coli bacteria, which are a common foodborne pathogen. The S.enterica phage was in turn chosen as it readily infects and kills Salmonella enterica bacteria, which are similarly a common cause of food poisoning.
To get the phages into food items, the research team developed a novel “patch” delivery system. This involved creating patches out of food-compatible polymers that were covered in tiny microneedles that could penetrate the surface of common foods. Once the microneedles penetrate the food, passing bacteria would interact with the bacteriophages, producing more phages as they burst open and die. This has the effect of propagating phages further to other bacteria in the food. The most successful microneedle patches were crafted out of PMMA polymer, after researchers investigated a wide range of other materials including PVA, PDMS, and gelatin. The microneedles are dosed with bacteriophages by simply incorporating the bacteriophage solution with a PMMA solution prior to casting in molds.
The patches proved effective in testing. One test involving contaminated cooked chicken saw 99.9% of E. coli bacteria wiped out in the sample. A similar test on raw beef saw a similar reduction of E.coli by 99%. These samples could effectively be considered decontaminated from the bacterial threat. The use of microneedles is key to the technique’s effectiveness. By penetrating up to a centimeter into the meat, it allows the bacteriophages to best get into contact with pathogens inside the food. In comparison, flat patches without needles performed less well, only reducing bacteria levels by three-quarters.
The research around using patches to deliver bacteriophages to food was only just published in October this year. However, the use of phages as a food safety measure actually goes back quite some time. The FDA first approved the use of bacteriophage products in 2006, initially for killing bacteria in ready-to-eat poultry and meat products. The same techniques can be applied to all sorts of foods, though use thus far has been limited. The US has actually been a leader in approving these food treatment methods; as a contrast, the European Union is yet to approve any use of bacteriophage products for food use.
As to whether these patches could enter wider use, that remains to be seen. There are some limitations with the technique. For one, it involves punching many small holes in food, which isn’t super attractive to those going to eat it later. There are also concerns about the effectiveness of phages in real-world use, and whether it would be practical to dose patches with a wide range of phages to counter the many strains of foodborne pathogens out there. It also depends on the perception of the tecnnology—we’d all rather eat food free of bacteria, but whether we want to eat food that is full of viruses is another thing entirely.
It will be a while before this technology reaches the mainstream food processing world, if it does at all. Regardless, the researchers can see a future where food packaging regularly includes a microneedle pad or membrane to take out any nasty bacteria before the product reaches the customer. That could promise to land better, safer food on our tables even if a few nasty bacteria did try to get involved in the action.
Featured image: microneedle array image from “Nanoparticle-infused-biodegradable-microneedles as drug-delivery systems: preparation and characterisation“.
2026-01-10 01:00:40
This week, Hackaday’s Elliot Williams and Kristina Panos met up over coffee to bring you the latest news, mystery sound results show, and of course, a big bunch of hacks from the previous seven days or so.
On What’s That Sound, Kristina had no idea what was going on, but [Flippin’ Heck] knew it was a flip dot display, and won a Hackaday Podcast t-shirt! Congratulations!
After that, it’s on to the hacks and such, with not one but two ways of seeing sound. We also take a look at benchmarking various Windows releases against each other on 12-year-old hardware.
We also talk about painting on floppies and glitching out jpegs in a binary text editor. Finally, we discuss the history and safety of autopilot, and take a look at the humble time clock.
Check out the links below if you want to follow along, and as always, tell us what you think about this episode in the comments!
Download in DRM-free MP3 and savor at your leisure.
2026-01-09 23:00:50
In today’s Chromed-up world it can be hard to remember an era where browsers could be extended with not just extensions, but also with plugins. Although for those of us who use traditional Netscape-based browsers like Pale Moon the use of plugins has never gone away, for the rest of the WWW’s users their choice has been limited to increasingly more restrictive browser extensions, with Google’s Manifest V3 taking the cake.
Although most browsers stopped supporting plugins due to “security concerns”, this did nothing to address the need for executing code in the browser faster than the sedate snail’s pace possible with JavaScript, or the convenience of not having to port native code to JavaScript in the first place. This led to various approaches that ultimately have culminated in the WebAssembly (WASM) standard, which comes with its own set of issues and security criticisms.
Other than Netscape’s Plugin API (NPAPI) being great for making even 1990s browsers ready for 2026, there are also very practical reasons why WASM and JavaScript-based approaches simply cannot do certain basic things.
One of the Achilles heels of the plugin-less WWW is that while TCP connections are easy and straightforward, things go south once you wish to do anything with UDP datagrams. Although there are ugly ways of abusing WebRTC for UDP traffic with WASM, ultimately you are stuck inside a JavaScript bubble inside a browser, which really doesn’t want you to employ any advanced network functionality.
Technically there is the WASI Sockets proposal that may become part of WASM before long, but this proposal comes with a plethora of asterisks and limitations attached to it, and even if it does work for your purposes, you are limited to whatever browsers happen to implement it. Meanwhile with NPAPI you are only limited by what the operating system can provide.
With NPAPI plugins you can even use the traditional method of directly rendering to a part of the screen, removing any need for difficult setup and configuration beyond an HTML page with an <embed> tag that set up said rendering surface. This is what Macromedia Flash and the VLC media player plugin use, for example.
These limitations of a plugin-less browser are a major concern when you’d like to have, say, a client running in the browser that wishes to use UDP for something like service discovery or communication with UDP-based services. This was a WASM deal breaker with a project of mine, as UDP-based service discovery is essential unless I wish to manually mash IP addresses into an input field. Even the WASI Sockets don’t help much, as retrieving local adapter information and the like are crucial, as is UDP broadcast.
Meanwhile the NPAPI version is just the existing client dynamic library, with a few NPAPI-specific export functions tagged onto it. This really rubs in just how straightforward browser plugins are.
With one’s mind set on implementing an NPAPI plugin, and ignoring that Pale Moon is only one of a small handful of modern browsers to support it, the next question is where to start. Sadly, Mozilla decided to completely obliterate every single last trace of NPAPI-related documentation from its servers. This leaves just the web.archive.org backup as the last authoritative source.
For me, this provided also a bit of an obstacle, as I had originally planned to first do a quick NPAPI plugin adaptation of the libnymphcast client library project, along with a basic front-end using the scriptable interface and possibly also direct rendering of a Qt-based GUI. Instead, I would spend a lot of time piecing back together the scraps of documentation and sample projects that existed when I implemented my last NPAPI plugin back in about 2015 or 2016, back when Mozilla’s MDN hadn’t yet carried out the purge.
One of the better NPAPI tutorials, over on the ColonelPanic blog, had also been wiped, leaving me again with no other discourse than to dive into the archives. Fortunately I was still able to get my hands on the Mozilla NPAPI SDK, containing the npruntime headers. I also found a pretty good and simple sample plugin called npsimple (forked from the original) that provides a good starting point for a scriptable NPAPI plugin.
At its core an NPAPI plugin is little more than a shared library that happens to export a handful of required and optional functions. The required ones pertain to setting up and tearing down the plugin, as well as querying its functionality. These functions all have specific prefixes, with the NP_ prefixed functions being not part of any API, but simply used for the basic initialization and clean-up. These are:
NP_GetEntryPoints (not on Linux)NP_InitializeNP_ShutdownDuring the initialization phase the browser simply loads the plugin and reads its MIME type(s) along with the resources exported by it. After destroying the last instance, the shutdown function is called to give the plugin a chance to clean up all resources before it’s unloaded. These functions are directly exported, unlike the NPP_ functions that are assigned to function pointers.
The NPP_ prefixed functions are part of the plugin (NP Plugin), with the following being required:
NPP_NewNPP_DestroyNPP_GetValueEach instance of the plugin (e.g. per page) has its own NPP_New called, with an accompanying NPP_Destroy when the page is closed again. These are set in an NPPluginFuncs struct instance which is provided to the browser via the appropriate NP_ function, depending on the OS.
Finally, there are NPN_ prefixed functions, which are part of the browser and can be called from the plugin on the browser object that is passed upon initialization. These we will need for example when we set up a scriptable interface which can be called from e.g. JavaScript in the browser.
When the browser calls NPP_GetValue with as variable an instance of NPPVpluginScriptableNPObject, we can use these NPP_ functions to create a new NPP instance and retain it by calling the appropriate functions on the browser interface instance which we got upon initialization.
Registration of the MIME type unfortunately differs per OS , along with the typical differences of how the final shared library is produced on Windows, Linux/BSD and MacOS. These differences continue with where the plugin is registered, with on Windows the registry being preferred (e.g. HKLM/Software/MozillaPlugins/plugin-identifier), while on Linux and MacOS the plugin is copied to specific folders.
It’s somewhat tragic that a straightforward technology like NPAPI-based browser plugins was maligned and mostly erased, as it clearly holds many advantages over APIs that were later integrated into browsers, thus adding to their size and complexity. With for example the VLC browser plugin, part of the VLC installation until version 4, you would be able to play back any video and audio format supported by VLC in any browser that supports NPAPI, meaning since about Netscape 2.x.
Although I do not really see mainstream browsers like the Chromium-based ones returning to plugins with their push towards a locked-down ecosystem, I do think that it is important that everything pertaining to NPAPI is preserved. Currently it is disheartening to see how much of the documentation and source code has already been erased in a mere decade. Without snapshots from archive.org and kin much it likely would already be gone forever.
In the next article I will hopefully show off a working NPAPI plugin or two in Pale Moon, both to demonstrate how cool the technology is, as well as how overblown the security concerns are. After all, how much desktop software in use today doesn’t use shared libraries in some fashion?
