Retrogadgets: The Ageia PhysX Card

Old computers meant for big jobs often had an external unit to crunch data in specific ways. A computer doing weather prediction, for example, might have an SIMD (single instruction multiple data) vector unit that could multiply a bunch of numbers by a constant in one swoop. These days, there are many computers crunching physics equations so you can play your favorite high-end computer game. Instead of vector processors, we have video cards. These cards have many processing units that can execute “kernels” or small programs on large groups of data at once.

Awkward Years

However, there was that awkward in-between stage when personal computers needed fast physics simulation, but it wasn’t feasible to put array processing and video graphics on the same board. Around 2006, a company called Ageia produced the PhysX card, which promised to give PCs the ability to do sophisticated physics simulations without relying on a video card.

Keep in mind that when this was built, multi-core CPUs were an expensive oddity and games were struggling to manage everything they needed to with limited memory and compute resources. The PhysX card was a “PPU” or Physics Processor Unit and used the PCI bus. Like many companies, Ageia made the chips and expected other companies — notably Asus — to make the actual board you’d plug into your computer.

Continue reading “Retrogadgets: The Ageia PhysX Card”

Hackaday Links Column Banner

Hackaday Links: May 5, 2024

It may be hard to believe, but BASIC turned 60 this week. Opinions about the computer language vary, of course, but one thing everyone can agree on is that Professors Kemeny and Kurtz really stretched things with the acronym: “Beginner’s All-Purpose Symbolic Instruction Code” is pretty tortured, after all. BASIC seems to be the one language it’s universally cool to hate, at least in its current incarnations like Visual Basic and VBA. But back in 1964, the idea that you could plunk someone down in front of a terminal, or more likely a teletype, and have them bang out a working “Hello, world!” program with just a few minutes of instruction was pretty revolutionary. Yeah, line numbers and GOTO statements encouraged spaghetti code and engrained bad programming habits, but at least it got people coding. And perhaps most importantly, it served as a “gateway drug” into the culture for a lot of us. Many of us would have chosen other paths in life had it not been for those dopamine hits provided by getting that first BASIC program working. So happy birthday BASIC!

Continue reading “Hackaday Links: May 5, 2024”

Tool-Building Mammals

It’s often said of us humans that we’re the only “tool-using mammals”. While not exclusive to the hacker community, a bunch of us are also “tool-building mammals” when we have the need or get the free time. I initially wanted to try to draw some distinction between the two modes, but honestly I think all good hackers do both, all the time.

We were talking about the cool variety of test probes on the podcast, inspired by Al Williams’ piece on back probes. Sometimes you need something that’s needle-thin and can sneak into a crimp socket, and other times you need something that can hold on like alligator clips. The infinite variety of jigs and holders that make it easier to probe tiny pins is nothing short of amazing. Some of these are made, and others bought. You do what you can, and you do what you need to.

You can learn a lot from looking at the professional gear, but you can learn just as much from looking at other hackers’ bodge jobs. In the podcast, I mentioned one of my favorite super-low-tech hacks: making a probe holder out of a pair of pliers and a rubber band to hold them closed. Lean this contraption onto the test point in question and gravity does the rest. I can’t even remember where I learned this trick from, but I honestly use it more than the nice indicator-arm contraptions that I built for the same purpose. It’s the immediacy and lack of fuss, I think.

So what’s your favorite way of putting the probe on the point? Home-made and improvised, or purpose-built and professional? Or both? Let us know!

Hackaday Podcast Episode 269: 3D Printed Flexure Whegs, El Cheapo Bullet Time, And A DIY Cell Phone Sniffer

This week, it was Kristina’s turn in the hot seat with Editor-in-Chief Elliot Williams. First up in the news — the results are in for the 2024 Home Sweet Home Automation contest! First and second place went to some really gnarly, well-documented hacks, and third went to the cutest pill-dispensing robot you’ll probably see before you hit the retirement home. Which was your favorite? Let us know in the comments.

A collection of multimeter probe extenders from Radio Shack.
Kristina’s lil’ wallet of extender probes, courtesy of Radio Shack.

Then it’s on to What’s That Sound. Kristina failed once again, but you will probably fare differently. Can you get it? Can you figure it out? Can you guess what’s making that sound? If you can, and your number comes up, you get a special Hackaday Podcast t-shirt.

Then it’s on to the hacks, beginning with a DIY cell phone sniffer and a pen that changed the world. Then we talk bullet time on a budget, the beautiful marriage of 3D printing and LEGO, and, oh yes, flexure whegs. Finally, we get the lowdown on extender probes, and posit why it’s hard to set up time zones on the Moon, relatively speaking.

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 and savor at your leisure.

Continue reading “Hackaday Podcast Episode 269: 3D Printed Flexure Whegs, El Cheapo Bullet Time, And A DIY Cell Phone Sniffer”

This Week In Security: Default Passwords, Lock Slapping, And Mastodown

The UK has the answer to all our IoT problems: banning bad default passwords. Additionally, the new UK law requires device makers to provide contact info for vulnerability disclosures, as well as a requirement to advertise vulnerability fix schedules. Is this going to help the security of routers, cameras, and other devices? Maybe a bit.

I would argue that default passwords are in themselves the problem, and complexity requirements only nominally help security. Why? Because a good default password becomes worthless once the password, or algorithm leaks. Let’s lay out some scenarios here. First is the static default password. Manufacturer X makes device Y, and sets the devices to username/password admin/new_Complex_P@ssword1!. Those credentials make it onto a default password list, and any extra security is lost.

What about those devices that have a different, random-looking password for each device? Those use an algorithm to derive that password from the MAC address and/or serial number. That may help the situation, but the algorithm can be retrieved from the firmware, and most serial numbers are predictable in one way or another. This approach is better, but not a silver bullet.

So what would a real solution to the password problem look like? How about no default password at all, but no device functionality until the new password passes a cracklib complexity and uniqueness check. I have seen a few devices that do exactly this. The requirement for a disclosure address is a great idea, which we’ve talked about before regarding the similar EU legislation.

Continue reading “This Week In Security: Default Passwords, Lock Slapping, And Mastodown”

FLOSS Weekly Episode 781: Resistant To The Wrath Of God

This week Jonathan Bennett and Doc Searls sit down with Mathias Buus Madsen and Paolo Ardoino of Holepunch, to talk about the Pear Runtime and the Keet serverless peer-to-peer platform. What happens when you take the technology built for BitTorrent, and apply it to a messaging app? What else does that allow you to do? And what’s the secret to keeping the service running even after the servers go down?

Continue reading “FLOSS Weekly Episode 781: Resistant To The Wrath Of God”

Programming Ada: Packages And Command Line Applications

In the previous installment in this series we looked at how to set up an Ada development environment, and how to compile and run a simple Ada application. Building upon this foundation, we will now look at how to create more complex applications, along with how to parse and use arguments passed to Ada applications on the command line (CLI). After all, passing flags and strings to CLI applications when we launch them is a crucial part of user interaction, as well as when automating systems as is the case with system services.

The way that a program is built-up is also essential, as well-organized code eases maintenance and promotes code reusability through e.g. modularity. In Ada you can organize subprograms (i.e. functions and procedures) in a declarative fashion as stand-alone units, as well as embed subprograms in other subprograms. Another option is packages, which roughly correspond to C++ namespaces, while tagged types are the equivalent of classes. In the previous article we already saw the use of a package, when we used the Ada.Text_IO package to output text to the CLI. In this article we’ll look at how to write our own alongside handling command line input, after a word about the role of the binding phase during the building of an Ada application.

Continue reading “Programming Ada: Packages And Command Line Applications”