We recently got a note in the tips line from [Tavis Gustafson], who is one of the developers of Tronbyt — a replacement firmware and self-hosted backend that breaks the Tidbyt smart display free from its cloud dependency. When they started the project, [Tavis] says the intent was simply to let privacy-minded users keep their data within the local network, which was itself a goal worthy enough to be featured on these pages.
But now that Tidbyt has been acquired by Modal and has announced they’ll no longer be producing new units, things have shifted slightly. While the press release says that the Tidbyt backend is going to stay up and running for existing customers, the writing is clearly on the wall. It’s now possible that the Tronbyt project will be able to keep these devices from ending up in landfills when the cloud service is inevitably switched off, especially if they can get the word out to existing users before then.
What’s that? You say you haven’t heard of Tidbyt? Well, truth be told, neither had we. So we did some digging, and this is where things get really interesting.
It doesn’t matter if its a Vespa or a Peterbilt truck — if you ignore the maintenance needs of your vehicle, you do so at your own peril. But it can be difficult enough to keep track of basic oil changes, to say nothing of keeping records on what parts were changed when. Instead of cramming more receipts into your glove box, maybe give LubeLogger a try.
This free and open source software tool is designed to make it easy for individuals to keep track of both the routine maintenance needs of their vehicles, as well as keep track of any previous or upcoming repairs and upgrades. Released under the MIT license, LubeLogger is primarily distributed as a Docker image that makes it easy to self-host the tool should you wish to keep your data safe at home rather than on somebody’s server out in the Wild West of the modern Internet.
Recently Raspberry Pi publicly announced the release of their new rpi-image-gen tool, which is advertised as making custom Raspberry Pi OS (i.e. Debian for specific Broadcom SoCs) images in a much more streamlined fashion than with the existing rpi-gen tool, or with third-party solutions. The general idea seems to be that the user fetches the tool from the GitHub project page, before running the build.sh script with parameters defining the configuration file and other options.
The main advantage of this tool is said to be that it uses binary packages rather than (cross-)compiling, while providing a range of profiles and configuration layers to target specific hardware & requirements. Two examples are provided in the GitHub project, one for a ‘slim’ project, the other for a ‘webkiosk‘ configuration that runs a browser in a restricted (Cage) environment, with required packages installed in the final image.
Looking at the basic ‘slim’ example, it defines the INI-style configuration in config/pi5-slim.cfg, but even when browsing through the main README it’s still somewhat obtuse. Under device it references the mypi5 subfolder which contains its own shell script, plus a cmdline.txt and fstab file. Under image it references the compact subfolder with another bunch of files in it. Although this will no doubt make a lot more sense after taking a few days to prod & poke at this, it’s clear that this is not a tool for casual users who just want to quickly put a custom image together.
This is also reflected in the Raspberry Pi blog post, which strongly insinuates that this is targeting commercial & industrial customers, rather than hobbyists.
Cloudflare has gotten more active in its efforts to identify and block unauthorized bots and AI crawlers that don’t respect boundaries. Their solution? AI Labyrinth, which uses generative AI to efficiently create a diverse maze of data as a defensive measure.
This is an evolution of efforts to thwart bots and AI scrapers that don’t respect things like “no crawl” directives, which accounts for an ever-growing amount of traffic. Last year we saw Cloudflare step up their game in identifying and blocking such activity, but the whole thing is akin to an arms race. Those intent on hoovering up all the data they can are constantly shifting tactics in response to mitigations, and simply identifying bad actors with honeypots and blocking them doesn’t really do the job any more. In fact, blocking requests mainly just alerts the baddies to the fact they’ve been identified.
Instead of blocking requests, Cloudflare goes in the other direction and creates an all-you-can-eat sprawl of linked AI-generated content, luring crawlers into wasting their time and resources as they happily process an endless buffet of diverse facts unrelated to the site being crawled, all while Cloudflare learns as much about them as possible.
That’s an important point: the content generated by the Labyrinth might be pointless and irrelevant, but it isn’t nonsense. After all, the content generated by the Labyrinth can plausibly end up in training data, and fraudulent data would essentially be increasing the amount of misinformation online as a side effect. For that reason, the human-looking data making up the Labyrinth isn’t wrong, it’s just useless.
It’s certainly a clever method of dealing with crawlers, but the way things are going it’ll probably be rendered obsolete sooner rather than later, as the next move in the arms race gets made.
Surely by now you’ve at least heard of RTL-SDR — a software project that let’s cheap TV tuner dongles work as a software-defined radios. A number of projects and tools have spun off the original effort, but in his latest video, [Tech Minds] shows off a particularly unique take. It’s a Web browser-based radio application that uses WebUSB, so it doesn’t require the installation of any application software. You can see the program operating in the video below.
There are a few things you should know. First, you need the correct USB drivers for your RTL-SDR. Second, your browser must support WebUSB, of course. Practically, that means you need a Chromium-type browser. You may have to configure your system to allow raw access to the USB port, too.
Watching the video, you can see that it works quite well. According to the comments, it will work with a phone, too, which is an interesting idea. The actual Web application is available as open source. It isn’t going to compete with a full-fledged SDR program, but it looked surprisingly complete.
These devices have grown from a curiosity to a major part of radio hacking over the years. Firefox users can’t use WebUSB — well, not directly, anyway.
Do you like high-detail 3D models intended for resin printing, but wish you could more easily print them on a filament-based FDM printer? Good news, because [Jacob] of Painted4Combat shared a tool he created to make 3D models meant for resin printers — the kind popular with tabletop gamers — easier to port to FDM. It comes in the form of a Blender add-on called Resin2FDM. Intrigued, but wary of your own lack of experience with Blender? No problem, because he also made a video that walks you through the whole thing step-by-step.
Resin2FDM separates the model from the support structure, then converts the support structure to be FDM-friendly.
3D models intended for resin printing aren’t actually any different, format-wise, from models intended for FDM printers. The differences all come down to the features of the model and how well the printer can execute them. Resin printing is very different from FDM, so printing a model on the “wrong” type of printer will often have disappointing results. Let’s look at why that is, to better understand what makes [Jacob]’s tool so useful.
Rafts and a forest of thin tree-like supports are common in resin printing. In the tabletop gaming scene, many models come pre-supported for convenience. A fair bit of work goes into optimizing the orientation of everything for best printed results, but the benefits don’t carry directly over to FDM.
For one thing, supports for resin prints are usually too small for an FDM printer to properly execute — they tend to be very thin and very tall, which is probably the least favorable shape for FDM printing. In addition, contact points where each support tapers down to a small point that connects to the model are especially troublesome; FDM slicer software will often simply consider those features too small to bother trying to print. Supports that work on a resin printer tend to be too small or too weak to be effective on FDM, even with a 0.2 mm nozzle.
To solve this, [Jacob]’s tool allows one to separate the model itself from the support structure. Once that is done, the tool further allows one to tweak the nest of supports, thickening them up just enough to successfully print on an FDM printer, while leaving the main model unchanged. The result is a support structure that prints well via FDM, allowing the model itself to come out nicely, with a minimum of alterations to the original.
Resin2FDM is available in two versions, the Lite version is free and an advanced version with more features is available to [Jacob]’s Patreon subscribers. The video (embedded below) covers everything from installation to use, and includes some general tips for best results. Check it out if you’re interested in how [Jacob] solved this problem, and keep it in mind for the next time you run across a pre-supported model intended for resin printing that you wish you could print with FDM.
Some slicers have introduced brick layers, and more slicers plan to add them. Until that happens, you can use this new script from [Geek Detour] to get brick layer goodness on Prusa, Orca, and Bambu slicers. Check out the video below for more details.
The idea behind brick layers is that outer walls can be stronger if they are staggered vertically so each layer interlocks with the layer below it. The pattern resembles a series of interlocking bricks and can drastically increase strength. Apparently, using the script breaks the canceling object functionality in some printers, but that’s a small price to pay. Multi-material isn’t an option either, but — typically — you’ll want to use the technique on functional parts, which you probably aren’t printing in colors. Also, the Arachne algorithm option only works reliably on Prusa slicer, so far.
The video covers a lot of detail on how hard it was to do this in an external script, and we are impressed. It should be easier to write inside the slicer since it already has to figure out much of the geometry that this script has to figure out by observation.
