Do you remember AIM? It may suprize you to hear that AOL’s instant messanger was actually supported all the way up to 2017– two years after Discord launched. Unlike Discord, AIM is a protocol, not a platform. Everything on your favourite Discord server is at the mercy of the corporate masters of said server; you can’t just spool up your own. Not so for AIM, as [Veronica] explains, both on her blog and in a YouTube video that we’ve embedded below.

The key is the fact that the AIM protocol isn’t locked into AOL’s now-defunct servers; it was reverse engineered in its prime for open-source messengers like Pidgin. You can host your own server, too, using the OpenOscarServer by [mk6i]. Even better, it’s not just AIM, but ICQ! In the sort of irony you only get in real life, the OpenOscar community does all its support on a Discord server. But then, they couldn’t hardly do it over AIM or ICQ these days.

For those of you who were too old or too young to get sucked into the 90s instant messenger craze, these protocols don’t just create chat rooms, that would be the even older Internet Relay Chat protocol, but usually worked more like SMS text messages. You have a contact list, and you send messages to your contacts via a server that acts as a hub. Once upon a time, that server was AOL’s, but now thanks to the OpenOscar project, it can be anybody’s computer. Of course, like texting, you can rope all of your contacts into one big group chat, and the protocol does support images and VOIP. (Which is starting to sound a lot like Discord.)

If you’re tired of your friend-group being at the mercy of American tech companies, [Veronica]’s blog post serves as a good guide to get you started running OpenOscarServer on a Linux system; she used a virtual private server but figures a Raspberry Pi ought to have enough grunt if you don’t have a huge number of people signed up.

For completeness, we should mention that while AOL pulled the plug on AIM nearly a decade back, ICQ, the other protocol supported by OpenOscarServer, lasted straight through until 2024.

Thanks to Keith Olson for the tip! Our tipsline is based on decentralized “electronic mail” technology that anyone can access.

youtube.com/embed/VDQTuJWST4M?…

hackaday.com/2026/07/14/aim-in…

A few years ago, France introduced a mandatory repairability score for consumer goods like laptops and tablets. It involves five criteria that range from documentation and availability of spare parts to ease of disassembly, with the manufacturer using a government-provided checklist to determine their score.

Recently Asus determined that their Asus ROG Flow Z13 – model GZ302EA – scored a 10 out of 10 using this system. This led [iFixit] to run the same tablet/laptop hybrid through their own rating system.

You can find the filled-out spreadsheet for this device here, with this Asus-provided site showing a list of devices that all score a 10/10 or a measly 9.9/10 according to this system. As a self-reported score it is hard to take it as the objective truth, as there is every incentive for the manufacturer to tweak the truth to their own benefit and gloss over inconveniences. This is where it’s interesting to compare it with [iFixit]’s 7/10 score.

On documentation, Asus gives itself a perfect score but [iFixit] finds it to be incomplete. Removal of one fan requires the disassembly of the cooler with its liquid metal thermal interface on the CPU. The wireless card, and most ports, are soldered to the mainboard. On the bright side, after you get the screen off, the insides are quite modular, which is a plus.

[iFixit] dings three points: for documentation, soldered-down components, and a fan accessibility glitch. Parts accessibility outside of France is also significantly harder, but one can hardly blame the French system for that. Overall the French self-reported rating would seem to be a fair start, but depending on which criteria you define as required you may find yourself disagreeing with the score.

In the case of LPDDR5 RAM one could argue for example that with LPCAMM2 modules soldering RAM onto the mainboard ought to be a thing of the past, and Wi-Fi modules should always be removable as well. You can take that up with the French regulators.

youtube.com/embed/1rTzEE3qyNk?…

hackaday.com/2026/07/14/benchm…

Full body tracking in VR applications involves attaching sensors to one’s body, and [Jaki] has a DIY method to do it on the cheap: the Vive Tracker Lite project repurposes Vive controllers as lighthouse-based trackers, no hardware modifications required.

A common method of doing body tracking is to strap on some Vive trackers. Those are extremely hacker-friendly pieces of hardware, but [Jaki] observed that older Vive VR controllers can be had for cheap, and already contain everything a tracker needs. Some new firmware and a custom mount is all it takes to turn them into perfectly usable body trackers.

But what about a wireless receiver? [Jaki] has that covered as well with the $5 Viva Dongle, which uses a Pro Micro NRF52840 to act as a cheap DIY alternative to the official dongle hardware.

We appreciate the effort put into making this project accessible to everyone, even novices. [Jaki]’s put effort into a Python program with a full GUI to make the flashing of firmware as easy as possible for both projects. Experimenting with body tracking in VRChat or games with mods is just some recycled hardware away.

Granted, a Vive controller is not the slimmest piece of hardware, but all it takes is a firmware change and a 3D-printed fixture to make a perfectly serviceable tracker. That being said, we’re sure an enterprising hardware hacker may crack a controller open and embark on a serious rebuild, or even interface to some of the inputs in a clever way. If you’ve done that or know of someone who has, drop us a note on our tips line because we’d love to see it.

hackaday.com/2026/07/14/full-b…

Demonstration of the DoomGeo port of Doom to the Neo Geo. (Credit: Sabino, GitHub)
Perhaps the most ridiculous statement that anyone can make is that a computer system with clearly enough processing power ‘cannot run DOOM‘. This is why we accept the premise that a PDP-11 cannot run this game, but something on the order of a Neo Geo gaming console with its 68000 processor and for the time impressive GPU definitely ought to be able to.

The stated problem here is a lack of RAM for a framebuffer, with the CPU only having 64 kB to play with. This limitation now has seen two different approaches to try and circumvent it, as covered by [Modern Vintage Gamer].

The first project here is Doom64kB, which as the name suggests tries to somehow work with this system RAM limitation. It uses the Doom8088 port for the original IBM PC and similar Intel 8088-based systems. This had to massively reduce the feature list, including the lack of texture mapping for floors and ceiling, no saving or loading, and no music.

The other project is DoomGeo, which doesn’t try to bend the Neo Geo hardware to its will, but accepts the Neo Geo way of doing things: involving sprite strips, pre-baked graphics, fix-layer UI, and a minimum of runtime data. This of course drastically changes how the Doom game engine normally works, with its framebuffer-based rendering.

From this we can thus conclude that it’s not so much the processing power that limits where DOOM can run, but more of how framebuffer-friendly the system architecture is, yet with some ingenuity and a complete rewrite of the game engine even that is no major obstacle.

(Top image: Neo Geo AES console. Credit: Evan-Amos, Wikimedia)

youtube.com/embed/VJwffCeo4jU?…

hackaday.com/2026/07/14/the-ne…

Can you call it a bandsaw if it has neither band nor saw? [WeldingRod1] does, with his entry in the laser contest — a manually-controlled laser cutter that he’s dubbed a Laser Bandsaw. Some might quibble that it’s not actually sawing with the beam, and others will inevitably find the safety implications rather frightening. We think it’s a fun project and that [WeldingRod1] can call it what he wants, as long as he follows his own advice and keeps his laser goggles firmly on his precious vision orbs.

He has actually put some thought into what started as the physical manifestation of a joke in a podcast. The blue diode laser — a NUBM44 diode rated at 7 W — got a custom-made copper heatsink. It’s also got a hefty beam dump in the form of a stack of box knife blades. That’s very necessary to keep the beam from reflecting where it shouldn’t, especially when you consider this operates like a regular band saw: you turn it on, and it’s ready to cut. With only 7 W of laser power it can’t cut that much, mind you, but apparently it’s great on balsa wood and blasts black paint off like nobody’s business.

Now if this was our shop we’d probably want to put the laser diode onto some kind of CNC platform, be it Cartesian or SCARA. But we’ve seen that done many, many times and if you’ve got the motor skills this might be just the tool for you. There’s a pinout and STLs for the 3D printed frame on the project page if you’re interested. If not, why are you still here? The article is finished. Go make something lase and send it in. The deadline for the 2026 Frikkin Laser Contest is fast approaching!

hackaday.com/2026/07/14/2026-f…

At the current rate of robotics development, you might assume that we’re close to Skynet taking over. However, while we likely wouldn’t do well in a physical fight against a robot, we can at least keep the bragging rights of having the cooler actuators. Or at least, that was the case before a new actuator came into town — introducing “Electrofluidic Fiber Muscles”.

Traditional robotic actuators use motors of some kind with a variety of gearboxes or linkages to turn rotational movement into usable movement. This isn’t always the most effective way to run some robotics movements, especially when modeling humans. This is why many have turned to pressurized modes of actuation. Though most don’t show quite the promise of the new player.

Electrofluidic Fiber Muscles use pressure to shorten muscle strands, similar to past actuators. However, these are a tad different, taking advantage of electrofluidic pressure. A small current under high voltage is able to drive a pressure gradient in a long tube. This tube can then be connected to both an extensor and flexor portion of an actuating circuit, similar to a biological mechanical system. Better yet, this driving pressure pump can be spun around the fibers themselves, making a tight package.

Unfortunately, it will probably be a bit till we see this inside a hobbyist robot. Until then, make sure to check out some other actuator feats!

youtube.com/embed/8h4UEZTyres?…

hackaday.com/2026/07/14/fibrou…

In the previous installment on UDP broadcasting and service discovery, the basics of both were explored, including an implementation in the form of NyanSD and its protocol. Contained in the comment section was a very good demonstration of why one of the most exciting aspects of software development is the opportunity to share your latest creations with other people. This being the ability to get solid feedback on all the points – including any potential boneheaded omissions – that you really should address, whether intentional or accidental.

The most pertinent point raised was definitely that of broadcast addresses and IPv4 subnets, with the latter topic especially being something that the sysadmins at the office would talk about all the time, but which us software developers were always happy to ignore as something that didn’t concern us. Turns out the joke was on me and everyone else – like our esteemed readers – who thought that they could escape the fascinating world of subnets, as today we’ll take an in-depth look at what subnets are and how they are relevant to the world of UDP network discovery.

I somewhat alluded in the first article to the topic of ‘which broadcast address to use’ as being somewhat of a rough topic to figure out, which is clearly why I just stuck to a blatantly ‘works for me’ /24 subnet that usually will work on networks, until it does not.

Subnet And Conquer

Basic subnetting concept. (Credit: Michel Bakni, Wikimedia)
The short version of ‘what is a subnet’ is to point at the subnet mask that we have been mostly mindlessly mashing into networking configuration dialogs along with the IPv4 address for many decades now. Usually this takes the form of 255.255.255.0, which is just the human-readable version of the actual bitmask. Here the loopback interface already tends to use 255.0.0.0 as its netmask, which is a detail that tends to be easy to gloss over as this is just one of those local OS things.

Putting netmasks in the crudest and simplest terms, they are a bitmask that is used to identify how an IPv4 pool of addresses is split up by defining which bits of the 32-bit IPv4 address identify a subnet. Normally we call the trailing part of an IPv4 address (the .123) the host identifier, with the preceding section the network identifier.

By masking part of this host ID and using it to create a subnet identifier, we can then use this for additional routing, just at the cost of a reduced number of possible host IDs within that subnet.

As an example, the common 255.255.255.0 mask identifies the first 24 bits (3 bytes) of the 32-bit (4-byte) IPv4 address, hence the mask being referred to as /24. With this mask, the remaining host ID bits allow for 256 hosts, of which two are not used for hosts: the first (e.g. 192.168.0.0) and last (e.g. 192.168.0.255) in the range. The last host ID in the range forms the broadcast address for that subnet.

This is why, for a /24 subnet, you can generally get away with just slapping a .255 on the end of an interface’s address, but also why for other subnet configurations it’s likely to explode violently.

To get briefly back to the loopback’s /8 style netmask, this means a single subnet with a maximum of 16,777,214 hosts, which ought to be sufficient for local system networking shenanigans. Its opposite extreme would be the /31 style netmask, which with just two potential host IDs is practically useless.

IPv6 subnetting is similar, but due to the much larger address pool and differences in the protocol this is a whole other kettle of fish that is as likely to send a network administrator’s heart racing in excitement as it is to make the average software developer run away screaming. This can be a fun topic for another day, perhaps.

This overview of IPv4 subnetting also skips over details like the different classes of IPv4 subnets beyond the Class A type here, but those are happily left to sysadmins and kin for now.

Sub-casting

In order to thus obtain the broadcast address for a given network interface you need to know two things: the IPv4 address and its associated netmask. From this you can then tell three things: the subnet ID, the broadcast address in that subnet, and the current host ID. Of these we only really care about the the second item.

Although you can obtain the broadcast address yourself by applying the netmask to the address, the OS’s APIs tend to happily give you the precomputed broadcast address. If that’s not your style or not an option, a manual procedure is to:

1. Determine the number of host ID bits using the netmask.
2. Set all bits to 1 in these bits to get the highest possible host ID.
3. Use this value along with the original masked (i.e. network ID) bits to obtain the broadcast address.

If we thus start with a 192.168.0.0/24 network, we end up with 192.168.0.255, while for a 192.168.0.0/26 network with just six bits available the maximum value is 64, ergo we get 192.168.0.63, since we start counting at 0.

With this we can now broadcast UDP packets on any interface without any (major) worries.

Local Broadcast Address

A small glitch in the whole above story is that there’s actually another broadcast address, one which is always the same for each interface and can be considered to make the whole preceding explanation completely irrelevant. This being the local, or limited, broadcast address, which is either the best thing since sliced bread or the worst sin ever committed in the history of IP networking, depending on whom you ask.

This cheat code takes the form of the address 255.255.255.255 and if you send a packet on a UDP socket to it, you’ll get happy UDP responses from any service that is listening on the specified port. This raises the point of why you’d not just use this broadcast address on all interface, rather than bother with all the earlier described nonsense.

The only major difference between this local broadcast address and the earlier described directed broadcast address is that the latter can also used to target a foreign network, instead of just the local network. This makes it a very attractive option if you just want to query the local network with UDP broadcast packets.

As for why you’d not want to use a local broadcast address, I couldn’t really find any references or citations on why this would be the case. Both would appear to be perfectly valid approaches to broadcasting, each with its own pros and cons.

Bugs

One final topic was my mistaken hardcoding of a /24 style broadcast address in NyanSD. Here reader ziew helpfully pointed me towards the Poco::Net::NetworkInterface::broadcastAddress() function, which seemed perfect. Unfortunately Poco’s implementation at least on Windows 10 appears to be rather broken.

After getting only 0.0.0.0 as broadcast address from this function, I had a bit of a look at what was happening, including checking what I got as subnet mask both for the default index parameter and for the next index. Across two different Windows 10 installations and both GCC in MSYS2 as well as MSVC 2017/2022 with various versions of Poco the returned values were… interesting enough to file a bug report on the Poco issue tracker.

Clearly this isn’t going to be fixed just yet, but on the bright side the horrific atrocity that I committed by hardcoding a /24 broadcast address will still work on basically every home LAN out there that NymphCast is likely to be used on.

Maybe I could just switch to a local broadcast address and that’d be even better. Feel free to torch down this idea in the comments, just be sure to provide solid reasoning and cite your sources.

A Complex Topic

Writing out the above pretty much clarifies I think why past me got a bit overwhelmed when trying to ‘just do a UDP broadcast thing’. Even just scratching the surface of IPv4 subnets and not even venturing into IPv6 territory makes one already feel a bit antsy.

Certainly, one could totally argue that anything other than a /24 network is unlikely to be encountered outside of certain government and business networks with either very specific needs, very enthusiastic sysadmins, or both, but it’s always better to design software with such real-life scenarios in mind.

hackaday.com/2026/07/14/udp-br…