2025-12-12 00:30:17
Looking for an educational microcontroller board to get you or a loved one into electronics? Consider the tinyCore – a small and nifty hexagon-shaped ESP32 board by [MR. INDUSTRIES], simplified for learning yet featureful enough to offer plenty of growth, and fully open.
The tinyCore board’s hexagonal shape makes it more flexible for building wearables than the vaguely rectangular boards we’re used to, and it’s got a good few onboard gadgets. Apart from already expected WiFi, BLE, and GPIOs, you get battery management, a 6DoF IMU (LSM6DSOX) in the center of the board, a micro SD card slot for all your data needs, and two QWIIC connectors. As such, you could easily turn it into, say, a smartwatch, a motion-sensitive tracker, or a controller for a small robot – there’s even a few sample projects for you to try.
You can buy one, or assemble a few yourself thanks to the open-source-ness – and, to us, the biggest factor is the [MR.INDUSTRIES] community, with documentation, examples, and people learning with this board and sharing what they make. Want a device with a big display that similarly wields a library of examples and a community? Perhaps check out the Cheap Yellow Display hacks!
We thank [Keith Olson] for sharing this with us!
2025-12-11 23:00:00
After you have written the code for some awesome application, you of course want other people to be able to use it. Although simply directing them to the source code on GitHub or similar is an option, not every project lends itself to the traditional configure && make && make install, with often dependencies being the sticking point.
Asking the user to install dependencies and set up any filesystem links is an option, but having an installer of some type tackle all this is of course significantly easier. Typically this would contain the precompiled binaries, along with any other required files which the installer can then copy to their final location before tackling any remaining tasks, like updating configuration files, tweaking a registry, setting up filesystem links and so on.
As simple as this sounds, it comes with a lot of gotchas, with Linux distributions in particular being a tough nut. Whereas on MacOS, Windows, Haiku and many other OSes you can provide a single installer file for the respective platform, for Linux things get interesting.
For all the flak directed at Windows, it is hard to deny that it is a stupidly easy platform to target with a binary installer, with equally flexible options available on the side of the end-user. Although Microsoft has nailed down some options over the years, such as enforcing the user’s home folder for application data, it’s still among the easiest to install an application on.
While working on the NymphCast project, I found myself looking at a pleasant installer to wrap the binaries into, initially opting to use the NSIS (Nullsoft Scriptable Install System) installer as I had seen it around a lot. While this works decently enough, you do notice that it’s a bit crusty and especially the more advanced features can be rather cumbersome.
This is where a friend who was helping out with the project suggested using the more modern Inno Setup instead, which is rather like the well-known InstallShield utility, except OSS and thus significantly more accessible. Thus the pipeline on Windows became the following:
.exe based installer.Installing applications on Windows is helped massively both by having a lot of freedom where to install the application, including on a partition or disk of choice, and by having the start menu structure be just a series of folders with shortcuts in them.
The Qt-based NymphCast Player application’s .iss file covers essentially such a basic installation process, while the one for NymphCast Server also adds the option to download a pack of wallpaper images, and asks for the type of server configuration to use.
Uninstalling such an application basically reverses the process, with the uninstaller installed alongside the application and registered in the Windows registry together with the application’s details.
Things get a bit weird with MacOS, with many application installers coming inside a DMG image or PKG file. The former is just a disk image that can be used for distributing applications, and the user is generally provided with a way to drag the application into the Applications folder. The PKG file is more of a typical installer as on Windows.
Of course, the problem with anything MacOS is that Apple really doesn’t want you to do anything with MacOS if you’re not running MacOS already. This can be worked around, but just getting to the point of compiling for MacOS without running XCode on MacOS on real Apple hardware is a bit of a fool’s errand. Not to mention Apple’s insistence on signing these packages, if you don’t want the end-user to have to jump through hoops.
Although I have built both iOS and OS X/MacOS applications in the past – mostly for commercial projects – I decided to not bother with compiling or testing my projects like NymphCast for Apple platforms without easy access to an Apple system. Of course, something like Homebrew can be a viable alternative to the One True Apple Way
if you merely want to get OSS o MacOS. I did add basic support for Homebrew in NymphCast, but without a MacOS system to test it on, who knows whether it works.
The world of desktop systems is larger than just Windows, MacOS and Linux, of course. Even mobile OSes like iOS and Android can be considered to be ‘desktop OSes’ with the way that they’re being used these days, also since many smartphones and tablets can be hooked up to to a larger display, keyboard and mouse.
How to bootstrap Android development, and how to develop native Android applications has been covered before, including putting APK files together. These are the typical Android installation files, akin to other package manager packages. Of course, if you wish to publish to something like the Google Play Store, you’ll be forced into using app bundles, as well as various ways to signing the resulting package.
The idea of using a package for a built-in package manager instead of an executable installer is a common one on many platforms, with iOS and kin being similar. On FreeBSD, which also got a NymphCast port, you’d create a bundle for the pkg package manager, although you can also whip up an installer. In the case of NymphCast there is a ‘universal installer’ built into the Makefile after compilation via the fully automated setup.sh shell script, using the fact that OSes like Linux, FreeBSD and even Haiku are quite similar on a folder level.
That said, the Haiku port of NymphCast is still as much of a Beta as Haiku itself, as detailed in the write-up which I did on the topic. Once Haiku is advanced enough I’ll be creating packages for its pkgman package manager as well.
There is a simple, universal way to distribute software across Linux distributions, and it’s called the ‘tar.gz method’, referring to the time-honored method of distributing source as a tarball, for local compilation. If this is not what you want, then there is the universal RPM installation format which died along with the Linux Standard Base. Fortunately many people in the Linux ecosystem have worked tirelessly to create new standards which will definitely, absolutely, totally resolve the annoying issue of having to package your applications into RPMs, DEBs, Snaps, Flatpaks, ZSTs, TBZ2s, DNFs, YUMs, and other easily remembered standards.
It is this complete and utter chaos with Linux distros which has made me not even try to create packages for these, and instead offer only the universal .tar.gz installation method. After un-tar-ing the server code, simply run setup.sh and lean back while it compiles the thing. After that, run install_linux.sh and presto, the whole shebang is installed without further ado. I also provided an uninstall_linux.sh script to complete the experience.
That said, at least one Linux distro has picked up NymphCast and its dependencies like Libnymphcast and NymphRPC into their repository: Alpine Linux. Incidentally FreeBSD also has an up to date package of NymphCast in its repository. I’m much obliged to these maintainers for providing this service.
Perhaps the lesson here is that if you want to get your neatly compiled and packaged application on all Linux distributions, you just need to make it popular enough that people want to use it, so that it ends up getting picked up by package repository contributors?
With so many details to cover, there’s also the easily forgotten topic that was so prevalent in the Windows installer section: integration with the desktop environment. On Windows, the Start menu is populated via simple shortcut files, while one sort-of standard on Linux (and FreeBSD as corollary) are Freedesktop’s XDC Desktop Entry files. Or .desktop files for short, which purportedly should give you a similar effect.
Only that’s not how anything works with the Linux ecosystem, as every single desktop environment has its own ideas on how these files should be interpreted, where they should be located, or whether to ignore them completely. My own experiences there are that relying on them for more advanced features, such as auto-starting a graphical application on boot (which cannot be done with Systemd, natch) without something throwing an XDG error or not finding a display is basically a fool’s errand. Perhaps that things are better here if you use KDE Plasma as DE, but this was an installer thing that I failed to solve after months of trial and error.
Long story short, OSes like Windows are pretty darn easy to install applications on, MacOS is okay as long as you have bought into the Apple ecosystem and don’t mind hanging out there, while FreeBSD is pretty simple until it touches the Linux chaos via X11 and graphical desktops. Meanwhile I’d strongly advise to only distribute software on Linux as a tarball, for your sanity’s sake.
2025-12-11 20:00:37
It’s happened to all of us: you find the perfect model for your needs — a bracket, a box, a cable clip, but it only comes in STL, and doesn’t quite fit. That problem will never happen if you’re using Iteration3D to get your models, because every single thing on the site is fully-parametric, thanks to an open-source toolchain leveraging 123Dbuilds and Blender.
Blender gives you preview renderings, including colors where the models are set up for multi-material printing. Build123D is the CAD behind the curtain — if you haven’t heard of it, think OpenSCAD but in Python, but with chamfers and fillets. It actually leverages the same OpenCascade that’s behind everyone’s other favorite open-source CAD suite, FreeCAD. Anything you can do in FreeCAD, you can do in Build123D, but with code. Except you don’t need to learn the code if the model is on Iteration3D; you just set the parameters and push a button to get an STL of your exact specifications.
The downside is that, as of now, you are limited to the hard-coded templates provided by Iteration3D. You can modify their parameters to get the configuration and dimensions you need, but not the pythonic Build123D script that generates them. Nor can you currently upload your own models to be shared and parametrically altered, like Thingiverse had with their OpenSCAD-based customizer. That said, we were told that user-uploads are in the pipeline, which is great news and may well turn Iteration3D into our new favorite.
Right now, if you’re looking for a box or a pipe hanger or a bracket, plugging your numbers into Iteration3D’s model generator is going to be a lot faster than rolling your own, weather that rolling be done in OpenSCAD, FreeCAD, or one of those bits of software people insist on paying for. There’s a good variety of templates — 18 so far — so it’s worth checking out. Iteration3D is still new, having started in early 2025, so we will watch their career with great interest.
Going back to the problem in the introduction, if Iteration3D doesn’t have what you need and you still have an STL you need to change the dimensions of, we can help you with that.
Thanks to [Sylvain] for the tip!
2025-12-11 17:00:21
The age of cheap and powerful devices is upon us. How about a 20 EUR handheld game console intended for retro game emulation, that runs Linux under the hood? [Luiz Ferreira] kicks the tires of a R36S, a very popular and often cloned device running a quad-core RK3326 with an Ubuntu-based OS, and shows us how to write and cross-compile a simple app for it using Rust – even if you daily drive Windows.
Since a fair bit of the underlying Linux OS is exposed, you can quickly build even text applications and have them run on the console. For instance, [Luiz]’s app uses ratatui to scan then print button and joystick states to the screen. Perhaps the most important thing about this app is that it’s a detailed tutorial on cross-compiling Rust apps for a Linux target, and it runs wonders using WSL, too.
Installing your app is simple, too: SSH into it, username ark and password ark. Looking for a Linux-powered device with a bright screen, WiFi, a fair few rugged buttons, and an OS open for exploration? This one is quite reassuring in the age of usual portables like smartphones getting more and more closed-off to tinkering. And, if the store-bought hackable Linux consoles still aren’t enough, you can always step it up and build your own, reusing Joycons for your input needs while at it.
2025-12-11 14:00:00
The Dutch word for sundial, zonnewijzer, can be literally translated into “Sun Pointer” according to [illusionmanager] — and he took that literal translation literally, building a reverse sundial so he would always know the precise location of our local star, even when it is occluded by clouds or the rest of the planet.
The electronics aren’t hugely complicated: an ESP32 dev board, an RTC board, and a couple of steppers. But the craftsmanship is, as usual for [illusionmanager], impeccable. You might guess that one motor controls the altitude and the other the azimuth of the LED-filament pointer (a neat find from AliExpress), but you’d be wrong.
This is more like an equatorial mount, in that the shaft the arrow spins upon is bent at a 23.5 degree angle. Through that hollow shaft a spring-steel wire connects the arrow to one stepper, to drive it through the day. The second stepper turns the shaft to keep the axis pointed correctly as Earth orbits the sun.
Either way you can get an arrow that always points at the sun, but this is lot more elegant than an alt-az mount would have been, at the expense of a fiddlier build. Given the existence of the orrery clock we featured from him previously, it’s safe to say that [illusionmanager] is not afraid of a fiddly build. Doing it this way also lets you read the ticks on the base just as you would a real sundial, which takes this from discussion piece to (semi) usable clock.
2025-12-11 11:00:26
For as long as there have been supercomputers, people like us have seen the announcements and said, “Boy! I’d love to get some time on that computer.” But now that most of us have computers and phones that greatly outpace a Cray 2, what are we doing with them? Of course, a supercomputer today is still bigger than your PC by a long shot, and if you actually have a use case for one, [Stephen Wolfram] shows you how you can easily scale up your processing by borrowing resources from the Wolfram Compute Services. It isn’t free, but you pay with Wolfram service credits, which are not terribly expensive, especially compared to buying a supercomputer.
[Stephen] says he has about 200 cores of local processing at his house, and he still sometimes has programs that run overnight. If your program already uses a Wolfram language and uses parallelism — something easy to do with that toolbox — you can simply submit a remote batch job.
What constitutes a supercomputer? You get to pick. You can just offload your local machine using a single-core 8GB virtual machine — still a supercomputer by 1980s standards. Or you get machines with up to 1.5TB of RAM and 192 cores. Not enough for your mad science? No worries, you can map a computation across more than one machine, too.
As an example, [Stephen] shows a simple program that tiles pentagons:
When the number of pentagons gets large, a single line of code sends it off to the cloud:
RemoteBatchSubmit[PentagonTiling[500]]
The basic machine class did the work in six minutes and 30 seconds for a cost of 5.39 credits. He also shows a meatier problem running on a 192-core 384GB machine. That job took less than two hours and cost a little under 11,000 credits (credit cost from just over $4/1000 to $6/1000, depending on how many you buy, so this job cost about $55 to run). If two hours is too much, you can map the same job across many small machines, get the answer in a few minutes, and spend fewer credits in the process.
Supercomputers today are both very different from old supercomputers and yet still somewhat the same. If you really want that time on the Cray you always wanted, you might think about simulation.
