When we think about sending an STL off on the Internet for processing, we usually want someone to print it for us or we want mesh repair. But [Chuck] found an interesting project on GitHub from [Andrew Sink] that will let you add a variable amount of twist to any STL and then return it to you for printing or whatever else you use STLs for. If you don’t get what we mean, check out the video below.

The site that does the work initially loads a little gnome figure if you are too lazy to upload your own model. That’s perfect, though, because the little guy is a good example of why you might want to twist a model. With just a little work, you can make the gnome look in one direction or even look behind him.

[Chuck] shows how to use the tool for artistic effect by twisting his standard cube logo. The result is something that looks like it would be difficult to create, but could hardly be easier. The tool lets you rotate the object, too, so you can get the twist effect in the right orientation for what you want to accomplish. A great little tool for making more artistic 3D prints without learning new software. If you want some fun, you can try the version that uses sound from your microphone to control the twist.

If you’d rather twist in CAD, we can help. If you really want artsy 3D printing, you probably need to learn Blender.

Bug reporting doesn’t usually have a lot of visuals. Not so with the visionOS bug [Ryan Pickren] found, which fills a user’s area with screeching bats after visiting a malicious website. Even better, closing the browser doesn’t get rid of them! Better still? Doesn’t need to be bats, it could be spiders. Fun!

The bug has been fixed, but here’s how it worked: the Safari browser build for visionOS allowed a malicious website to fill the user’s 3D space with animated objects without interaction or permission. The code to trigger this is remarkably succinct, and is actually a new twist on an old feature: Apple AR Quick Look, an HTML-based feature for rendering 3D augmented reality content in Safari.

Leveraging this old feature is what lets an untrusted website launch an arbitrary number of animated 3D objects — complete with sound — into a user’s virtual space without any interaction from the user whatsoever. The icing on the cake is that Quick Look is a separate process, so closing Safari doesn’t get rid of the pests.

Providing immersive 3D via a web browser is a valuable way to deliver interactive content on both desktops and VR headsets; a good example is the fantastic virtual BBC Micro which uses WebXR. But on the Apple Vision Pro the user is always involved and there are privacy boundaries that corral such content. Things being launched into a user’s space in an interaction-free way is certainly not intended behavior.

The final interesting bit about this bug (or loophole) was that in a way, it defied easy classification and highlights a new sort of issue. While it seems obvious from a user experience and interface perspective that a random website spawning screeching crawlies into one’s personal space is not ideal, is this a denial-of-service issue? A privilege escalation that technically isn’t? It’s certainly unexpected behavior, but that doesn’t really capture the potential psychological impact such bugs can have. Perhaps the invasion of personal space and user boundaries will become a quantifiable aspect of bugs in these new platforms. What fun.

The venerable Intel 486 was released in 1989 as the successor to the extremely popular Intel 386. It was the minimum recommended processor for Windows 98.  (Surprisingly, the Windows 95 minimum was a 386!)  But by the time XP rolled around, you needed at least a 233 MHz Pentium to install. Or at least that was the case until recently when an extremely dedicated user on MSFN named [Dietmar] showed how he hacked the XP kernel so it could run on the classic chip!

The biggest issue preventing XP from working on earlier processors is an instruction introduced on the Pentium: CMPXCHG8B. This instruction compares two 8-byte values and takes different actions depending on an equality test. It either copies the 8 bytes to a destination address or loads it into a 64-bit register. Essentially, it does what it says on the tin: it CoMPares and eXCHanGes some values. If you want to dig into the nitty-gritty details, you can check out this info on the instruction taken from the x86 datasheet.

Without getting too technical, know that this instruction is vital for performance when working with large data structures. This is because one instruction moves 8 bytes at a time, unlike the older CMPXCHG instruction, which only moves a single byte. Essentially, [Dietmar] had to find every usage of CMPXCHG8B and replace it with an equivalent series of CMPXCHG instructions.

On a side note, the once well-known and devastating Pentium F00F bug was caused by a faulty encoding of the CMPXCHG8B instruction. This allowed any user, even unprivileged users, to completely lock up a system, requiring a full reset cycle!

So [Dietmar] was successful, and now you can run the German version of Windows XP on either a real 486 or an emulated one. The installer is available on the Internet Archive and there’s a detailed video below demonstrating installing it on the 86Box virtual machine host.

Thanks to [DosFox] for the tip!

Markdown has become an extremely popular way to document source code and other projects, thanks in no small part to how well web-based services like GitHub render it. Just sprinkle a few extra characters into a regular text file, and all of a sudden it looks like you know what you’re doing. Unfortunately, there are some places where markdown won’t actually render, and you’ll be stuck looking at those extra characters.

But thanks to MarCLIdown, the terminal doesn’t have to be one of those places. Written by [NihaAlGhul], this simple tool takes a given markdown file and spits out a fairly impressive rendering — and you don’t even need to have one of those fancy new GPU-accelerated terminals. Most impressively, the whole thing is implemented as a single Bash script.

How does it work? Some would say it’s magic. Others would point out the inline Perl, conditionals statements, and line after line of regular expressions. Ultimately, we’d argue they’re the same thing.

As you can probably imagine not everything is supported by MarCLIdown, but the list of what’s currently working is already quite impressive. Headers, check boxes, lists, block quotes, links, all work and look pretty much as you’d expect. The biggest omission at this point is probably tables, but even that isn’t really a deal breaker.

MarCLIdown isn’t the first tool to try and visualize markdown in the terminal. Readers may already be familiar with glow, which is more mature and admittedly has the edge in terms of capability. But the fact that [NihaAlGhul] managed to get this far with just a single Bash script is a proper hack, and one we think worthy of some special consideration.

Voxels are effectively like 3D pixels, and they form an integral part of what is commonly referred to as a ‘retro 3D’ look, with pixelated edges sharp enough to cut your retinas on. The problems with modeling a scene using voxels come in the form of creating the geometry and somehow making a physics engine work with voxels rather than conventional triangular (or quad) meshes.

The approach demonstrated by [Daniel Schroeder] comes in the form of a Voxel Displacement Renderer implemented in C++ and using the Vulkan API. Best part of it? It only requires standard meshes along with albedo and displacement maps.

These inputs are processed by the C++-based tools, which generate the voxels that should be rendered and their properties, while the GLSL-based shader handles the GPU-based rendering step. The pre-processing steps required make it a good idea to bake these resources rather than try to process it in real-time. With that done, [Daniel]’s demo was able to sustain a solid 100+ FPS on a Radeon RX 5700 XT GPU at 1440p, and 60+ FPS on a Steam Deck OLED.

In a second blog post [Daniel] goes through his motivations for this project, with it originally having been intended as a showpiece for his resume, but he can imagine it being integrated into a game engine.

There are still questions to be resolved, such as how to integrate this technique for in-scene characters and other dynamic elements (i.e. non-static scenery), but in terms of easing voxel-based rendering by supporting a standard mesh-based workflow it’s an intriguing demonstration.

While most of us have likely spun up a virtual machine (VM) for one reason or another, venturing into the world of containerization with software like Docker is a little trickier. While the tools Docker provides are powerful, maintain many of the benefits of virtualization, and don’t use as many system resources as a VM, it can be harder to get the hang of setting up and maintaining containers than it generally is to run a few virtual machines. If you’ve been hesitant to try it out, this guide to getting a Docker container up and running is worth a look.

The guide goes over the basics of how Docker works to share system resources between containers, including some discussion on the difference between images and containers, where containers can store files on the host system, and how they use networking resources. From there the guide touches on installing Docker within a Debian Linux system. But where it really shines is demonstrating how to use Docker Compose to configure a container and get it running. Docker Compose is a file that configures a number of containers and their options, making it easy to deploy those containers to other machines fairly straightforward, and understanding it is key to making your experience learning Docker a smooth one.

While the guide goes through setting up a self-hosted document management program called Paperless, it’s pretty easy to expand this to other services you might want to host on your own as well. For example, the DNS-level ad-blocking software Pi-Hole which is generally run on a Raspberry Pi can be containerized and run on a computer or server you might already have in your home, freeing up your Pi to do other things. And although it’s a little more involved you can always build your own containers too as our own [Ben James] discussed back in 2018.

With the performance of modern CPU cores plateauing recently, the main performance gains are with multiple cores and multithreaded applications. Typically, a fast GPU is only so mind-bogglingly quick because thousands of cores operate in parallel on the same set of tasks. So, it would seem prudent for our applications to try to code in a multithreaded fashion to take advantage of this parallelism. Or so it would seem, but as [Marc Brooker] illustrates, it’s not as simple as one would assume, and it’s very easy to end up with far worse overall performance and no easy way to fix it.

[Marc] was rerunning an old experiment to calculate the expected number of birthdays in a shared group of people using brute force. The experiment was essentially a tight loop running a pseudorandom number generator, the standard libc rand() function. [Marc] profiled the code for single-thread and multithreaded versions and noted the runtime dramatically increased beyond two threads. Something fishy was going on. Running perf, [Marc] noted that there were significant L1 cache misses, but the real killer for performance was the increase in expensive context switches.  Perf indicated that for four threads, the was an overhead of nearly 50% servicing spin locks. There were no locks in the code, so after more perf magic, the syscalls taking all the time were identified.  Something in there was using a futex (or fast userspace mutex) a whole lot.

After delving into the glibc source code, a comment said it all:

/* POSIX.1c requires that there is mutual exclusion for the `rand' and
`srand' functions to prevent concurrent calls from modifying common
data. */

__libc_lock_lock (lock);
 (void) __random_r (&unsafe_state, &retval);
 __libc_lock_unlock (lock);

By replacing the call to rand() with random_r(), the program’s performance with four threads improved dramatically. The runtime was reduced to a theoretical quarter of the single-thread version. As Marc summarizes, multi-threaded programming is not always as straightforward as one might think. While performance can be significantly worse in some cases, improvements are possible. However, this is not guaranteed to be the case in every situation.

The art of debugging and profiling code is complex, so here’s how to use Valgrind to look for problems you might not even know about. Even the humble Linux pipe needs to be thought out to get decent performance. What a surprise!

The radio hackers in the audience will be familiar with a spectrogram display, but for the uninitiated, it’s basically a visual representation of how a range of frequencies are changing with time. Usually such a display is used to identify a clear transmission in a sea of noise, but with the right software, it’s possible to generate a signal that shows up as text or an image when viewed as a spectrogram. Musicians even occasionally use the technique to hide images in their songs. Unfortunately, the audio side of such a trick generally sounds like gibberish to human ears.

Or at least, it used to. Students from the University of Michigan have found a way to use diffusion models to not only create a spectrogram image for a given prompt, but to do it with audio that actually makes sense given what the image shows. So for example if you asked for a spectrogram of a race car, you might get an audio track that sounds like a revving engine.

The first step of the technique is easy enough — two separate pre-trained models are used, Stable Diffusion to create the image, and Auffusion4 to produce the audio. The results are then combined via weighted average, and enter into an iterative denoising process to refine the end result. Normally the process produces a grayscale image, but as the paper explains, a third model can be kicked in to produce a more visually pleasing result without impacting the audio itself.

Ultimately, neither the visual nor audio component is perfect. But they both get close enough that you get the idea, and that alone is pretty impressive. We won’t hazard to guess what practical applications exist for this technique, but the paper does hint at some potential use for steganography. Perhaps something to keep in mind the next time we try to hide data in an episode of the Hackaday Podcast.

While we don’t see it used very often these days, BASIC was fairly revolutionary in bringing computers to the masses. It was one of the first high-level languages to catch on and make computers useful for those who didn’t want to (or have time) to program them in something more complex. But that doesn’t mean it wasn’t capable of getting real work done — this classroom management software built in the language illustrates its capabilities.

Written by [Mike Knox], father of [Ethan Knox] aka [norton120], for his classroom in 1987, the programs were meant to automate away many of the drudgeries of classroom work. It includes tools for generating random seating arrangements, tracking attendance, and other direct management tasks as well as tools for the teacher more directly like curving test grades, tracking grades, and other tedious tasks that normally would have been done by hand at that time. With how prevalent BASIC was at the time, this would have been a powerful tool for any educator with a standard desktop computer and a floppy disk drive.

Since most people likely don’t have an 80s-era x86 machine on hand capable of running this code, [Ethan] has also included a docker container to virtualize the environment for anyone who wants to try out his father’s old code. We’ve often revisited some of our own BASIC programming from back in the day, as our own [Tom Nardi] explored a few years ago.

There are two types of people in the world: those who have no idea what a regular expression is, and those who not only know what they are but can compose them on the fly and tend to use them in situations where they’re clearly not called for. And it’s that latter camp, of which we consider ourself a proud member, that is rejoicing with the announcement that Microsoft is adding regular expression support to Excel.

Or perhaps not rejoicing so much as wondering what took so long. Yes, regular expressions have been part of VBA for a while now, but the new functions allow you to use regexes right in the spreadsheet grid. There are plenty of caveats, of course. The big one is that this is still in beta at this time, so you have to do some gymnastics to enable it, if you’re even allowed to in the first place. Second, support appears limited to three functions at the moment: REGEXTEST, which provides a logical test of pattern matching; REGEXEXTRACT, which returns a substring that matches a pattern; and REGEXREPLACE, which substitutes a string for a pattern. The video below walks through how to use these functions within spreadsheets.

What’s also unclear now is what flavor of regular expressions is supported. There are a bewildering number of entities in the regex bestiary — character classes, positional indicators, quantifiers, subexpressions, lazy and greedy matches, and a range of grouping constructs that perplex even regex pros. One hopes these new functions will support one of the existing regex standards, but Microsoft is famous for “extending and enhancing.” Then again, regex support has been in the .NET Framework for years and is pretty close to the Perl standard, so our guess is that it’ll be close to that.

If you fall into the “What’s a regex?” camp but want to change that, why not get your grep on?

For plenty of computer users, the operating system of choice is largely a middleman on the way to the browser, which hosts the tools that are most important. There are even entire operating systems with little more than browser support, under the assumption that everything will be done in the browser eventually. We may be one step closer to that type of utopia as well with this software tool called CADmium which runs exclusively in a browser.

As the name implies, this is a computer-aided design (CAD) package which looks to build everything one would need for designing project models in a traditional CAD program like AutoCAD or FreeCAD, but without the burden of needing to carry local files around on a specific computer. [Matt], one of the creators of this ambitious project, lays out the basic structure of a CAD program from the constraint solver, boundary representation (in this case, a modern one built in Rust), the history tracker, and various other underpinnings of a program like this. The group hopes to standardize around JSON files as well, making it easy to make changes to designs on the fly in whatever browser the user happens to have on hand.

While this project is extremely early in the design stage, it looks like they have a fairly solid framework going to get this developed. That said, they are looking for some more help getting it off the ground. If you’ve ever wanted something like this in the browser, or maybe if you’ve ever contributed to the FreeCAD project and have some experience, this might be worth taking a look at.

When you think about virtualization, you usually think about making some CPU pretend to be another CPU. However, there are sometimes advantages to making a computer pretend to be the same computer.

That’s the case with [oldvcr]’s KIMplement, which emulates a KIM-1 with a 6502 using a Commodore 64, which also uses a 6502.The reason this makes sense is that you have total control over an emulated CPU. If a program, for example, writes to a critical memory location or tries to take over the screen or keyboard, you can easily make the emulator do something more appropriate. Things like breakpoints and single stepping also become trivial.

The virtual machine at the heart of it is 6o6 (6502 on 6502), and it seems to perform well. By virtualizing, you can easily protect the system from programs that try to, for example, take over an interrupt vector. This is similar to how x86 protected mode can run old real-mode code in a virtual environment and intervene for certain instructions. The emulation is good enough that the emulator can run the emulator, which then runs the emulator to actually run the real target. That’s wasteful, of course, but it does speak to the completeness of the pretend CPU.

If you want a KIM-1 (and an 1802 Elf) but only have an Arduino, you can emulate a different way. At least an emulated KIM-1 doesn’t develop bad memory chips.

A good amount of hacks can be done with off-the-shelf hardware – what’s more, it’s usually available all over the world, which means your hacks are easier to build for others, too. Say, you’ve built something around a commonly available portable router, through the magic of open-source software. How do you make the fruits of your labour easy to install for your friends and blog readers? Well, you might want to learn a thing or two from [Albert], who shows us a portable DLNA server built around a GL-MT300N-V2 pocket router.

[Albert]’s blog post is a tutorial on setting it up, with a pre-compiled binary image you can flash onto your router. Flash it, prepare a flash drive with your media files, connect to the WiFi network created by the router, run the VLC player app, and your media library is with you wherever you go.

Now, a binary image is good, but are you wondering how it was made, and how you could achieve similar levels of user-friendliness in your project? Of course, here’s the GitHub repository with OpenWRT configuration files used to build this image, and build instructions are right there in the README. If you ever needed a reference on how to make commonly available OpenWRT devices do your bidding automagically, this is it.

This is an elegant solution to build an portable DLNA server that’s always with you on long rides, and, think of it, it handily beats a typical commercialized alternative, at a lower cost. Want software upgrades? Minor improvements and fixes? Security patches? Everything is under your control, and thanks to the open-source nature of this project, you have a template to follow. There won’t always be a perfectly suited piece of hardware on the market, of course, as this elegant dual-drive Pi-based NAS build will attest.

It may be a very long time since some readers have installed a copy of Windows, but it appears at one point during the installation there’s a step that asks you which OS version you would like to install. Normally this is populated by whichever Windows flavours come on the install medium, but [Naman Sood] has other ideas. How about a Windows installer with Alpine Linux as one of the choices? Sounds good to us.

You can see it in action in the video below the break. Indeed Alpine Linux appears as one of the choices, followed by the normal Windows licence accept screen featuring the GPL instead of any MS text. The rest of the installer talks about installing Windows, but we can forgive it not expecting a Linux install instead.

So, the question we’re all asking is: how is it done? The answer lies in a WIM file, a stock Windows image which the installer unpacks onto your hard drive. The Linux distro needs to be installable onto an NTFS root partition, and to make it installable there’s a trick involving the Windows pre-installation environment.

This is an amusing hack, but the guide admits it’s fragile and perhaps not the most useful. Even so, the sight of Linux in a Windows installer has to be worth it.

When coming from the world of Autodesk and kin’s proprietary CAD solutions, figuring out which FOSS 3D CAD solution is the right one can be a real chore, as none of them are on the same level. This is what the author of the Horizon EDA software – [Lukas K.] – struggled with as well when he decided to make his own 3D CAD package, called Dune 3D. Per the documentation for Dune 3D, it’s effectively the solver and workflow from SolveSpace, the Open CASCADE geometry kernel and the user interface from Horizon EDA wrapped up into a single package.

So why not just use FreeCAD or contribute to it? [Lukas]’s main gripes appear to be the issues with the topological naming problem (TNP) in FreeCAD, as well as the modal sketcher that’s limited to 2D, with no constraints in 3D for extrusions. With the recent version 1.1 release it seems to be picking up new features and fixes, and installing it is very easy on Windows with an installer. For Arch there’s an AUR package, and other Linux seems to get a Flatpak if you’re not into building the software yourself.

As for the UI, it’s got a definite MacOS vibe to it, with most of the functionality hidden from the main view. Fortunately some tutorials are available to get you started, but it remains to be seen where Dune 3D lands compared to FreeCAD, OnShape and others. As a sidenote, the name is probably not going to help much when asking Google for answers, courtesy of a certain vaguely well-known book with associated movies and series.

There should be rejoicing among fans of the original ARM operating system this week, as the venerable RISC OS received its version 5.30 update. It contains up-to-date versions of the bundled software as well as for the first time, out-of-the-box WiFi support, and best of all, it can run on all Raspberry Pi models except the Pi 5. If you’ve not encountered RISC OS before, it’s the continuing development of the OS supplied with the first ARM product, the Acorn Archimedes. As such it’s a up-to-date OS but with an interface that feels like those of the early 1990s.

We like RISC OS here, indeed we reviewed the previous version this year, so naturally out came the Hackaday Pi 3 and an SD card to run it on. It’s as smooth and quick as it ever was, but sadly try as we might, we couldn’t get the Pi’s wireless interface to appear in the list of available network cards. This almost certainly has more to do with us than it does the OS, but it would have been nice to break free from the tether of the network cable. The included Netsurf 3.11 browser is nippy but a little limited, and just as it was during our review, sadly not capable of editing a Hackaday piece or we’d be using it to write this.

It’s great to see this operating system still under active development, and we can see that it so nearly fulfills our requirement here for a lightweight OS on the road. For those of us who used the original version, then called Arthur, it’s a glimpse of how desktop computing could, or perhaps even should, have been.

Many of us have used UARTs to spit data from one system or chip to another. Normally, for quick and dirty maker projects, this is good enough. However, you’ll always get the odd dropped transmission or glitch that can throw a spanner in the works if you’re not careful. [Jake Read] decided to work on a system that could use UARTs while being far more reliable. Enter MUDLink.

MUDLink is a library that works with an Arduino’s UART port and stacks on a bit of protocol to clean things up. It uses a packetized method of sending data to ensure that transmissions are received reliably as intended by the sender. Packets are framed using a method called Consistent Overhead Byte Stuffing, which is a nice lightweight way of doing so. The system also uses CRC16-CCITT as an error checking mechanism. There’s also an ack-and-retransmit system for ensuring any dropped transmissions are repeated and received successfully.

If you need reliable UART transmissions without too much overhead, you might want to look at what Jake is doing. It’s a topic we’ve looked at before, too.

The PlayStation 2 was a revelation when it hit the market in 2000, and yet by modern standards, it’s almost hopelessly weak. In fact, it’s so under-powered, Rockstar developers had to pull every trick in the book to make Grand Theft Auto III even work on the platform.

The story comes to us from developer [Obbe Vermeij]. He explains that the PlayStation 2 couldn’t keep the entire open-world game map in its tiny 32 MB of RAM. Instead, models had to be streamed from the DVD drive as the player moved around the world. However, even the DVD drive wasn’t fast enough. If the player moved too quickly, they would outpace the system’s ability to load new assets, and the world would fall apart. Roads would vanish, buildings simply wouldn’t appear before the player passed by them.

According to [Obbe], getting around this challenge was the job of one [Adam Fowler]. He notes that even optimizing the layout of data on the DVD wasn’t enough to help. Nifty hacks had to be employed to slow the player down. Road networks were changed to stop the player speeding towards areas that needed lots of new models. In other areas, vehicles in the game would experience a nearly-imperceptible 5% increase in air drag to dull their speed. This was chosen as a more invisible solution; cutting engine power directly was audible to players as the audio changed.

It shows you just how hard developers had to work back when resources were far more constrained than they are today!

We’re not 100% sure which phase of Microsoft’s “Embrace, Extend, and Extinguish” gameplan this represents, but just yesterday the Redmond software giant decided to grace us with the source code for MS-DOS v4.0.

To be clear, the GitHub repository itself has been around for several years, and previously contained the source and binaries for MS-DOS v1.25 and v2.0 under the MIT license. This latest update adds the source code for v4.0 (no binaries this time), which originally hit the market back in 1988. We can’t help but notice that DOS v3.0 didn’t get invited to the party — perhaps it was decided that it wasn’t historically significant enough to include.

That said, readers with sufficiently gray beards may recall that DOS 4.0 wasn’t particularly well received back in the day. It was the sort of thing where you either stuck with something in the 3.x line if you had older hardware, or waited it out and jumped to the greatly improved v5 when it was released. Modern equivalents would probably be the response to Windows Vista, Windows 8, and maybe even Windows 11. Hey, at least Microsoft keeps some things consistent.

It’s interesting that they would preserve what’s arguably the least popular version of MS-DOS in this way, but then again there’s something to be said for having a historical record on what not to do for future generations. If you’re waiting to take a look at what was under the hood in the final MS-DOS 6.22 release, sit tight. At this rate we should be seeing it sometime in the 2030s.