Software In Progress

February 8, 2025 by Elliot Williams 74 Comments

Open source software can be fantastic. I run almost exclusively open software, and have for longer than I care to admit. And although I’m not a serious coder by an stretch, I fill out bug reports when I find them, and poke at edge cases to help the people who do the real work.

For 3D modeling, I’ve been bouncing back and forth between OpenSCAD and FreeCAD. OpenSCAD is basic, extensible, and extremely powerful in the way that a programming language is, and consequently it’s reliably bug-free. But it also isn’t exactly user friendly, unless you’re a user who likes to code, in which case it’s marvelous. FreeCAD is much more of a software tool than a programming language, and is a lot more ambitious than OpenSCAD. FreeCAD is also a program in a different stage of development, and given its very broad scope, it has got a lot of bugs.

I kept running into some really serious bugs in a particular function – thickness for what it’s worth – which is known to be glitchy in the FreeCAD community. Indeed, the last time I kicked the tires on thickness, it was almost entirely useless, and there’s been real progress in the past couple years. It works at least sometimes now, on super-simple geometries, and this promise lead me to find out where it still doesn’t work. So I went through the forums to see what I could do to help, and it struck me that some people, mostly those who come to FreeCAD from commercial programs that were essentially finished a decade ago, have different expectations about the state of the software than I do, and are a lot grumpier.

Open source software is working out its bugs in public. Most open source is software in development. It’s growing, and changing, and you can help it grow or just hang on for the ride. Some open-source userland projects are mature enough that they’re pretty much finished, but the vast majority of open-source projects are coding in public and software in progress.

It seems to me that people who expect software to be done already are frustrated by this, and that when we promote super-star open projects like Inkscape or Blender, which are essentially finished, we are doing a disservice to the vast majority of useful, but still in progress applications out there that can get the job done anyway, but might require some workarounds. It’s exactly these projects that need our help and our bug-hunting, but if you go into them with the “finished” mentality, you’re setting yourself up for frustration.

A Programming Language For Building NES Games

February 8, 2025 by Tom Nardi 27 Comments

Generally speaking, writing your own games for retro consoles starts with C code. You’ll need to feed that through a console-specific tool-chain, and there’s certainly going to be some hoops to jump through, but if everything goes as expected, you should end up with a ROM file that can be run in an emulator or played on real hardware if you’ve got the necessary gadgetry to load it.

But NESFab takes things in a slightly different direction. While the code might look like C, it’s actually a language specifically tailored for developing games on the Nintendo Entertainment System (NES). The documentation claims that this targeted language not only compiles into considerably faster 6502 assembly than plain C on GCC or LLVM, but is designed to work around the strengths (and weaknesses) of the NES hardware.

Looking deeper into the example programs and documentation, NESFab offers quite a few quality of life features that should make developing NES games easier. For one thing, there’s integrated asset loading which automatically converts your image files into something the console can understand. One just needs to drop the image file into the source directory, open it in the code with the file function, and the build system will take care of converting it on the fly as the ROM is built. The nuances of bank switching — the organization of code and assets so they fit onto the physical ROM chips on the NES cartridge — are similarly abstracted away.

The obvious downside of NESFab is that, as with something like GB Studio, you’re going to end up putting effort into learning a programming environment that works for just one system. So before you get started, you really need to decide what your goals are. If you’re a diehard NES fan that has no interest in working on other systems, learning a language and build environment specifically geared to that console might make a certain degree of sense. But if you’d like to see your masterpiece running on more than just one system, working in straight C is still going to be your best bet.

Retrotechtacular: Point-of-Sale Through The Years

February 8, 2025 by Dan Maloney 12 Comments

In days gone by, a common retail hack used by some of the less honorable of our peers was the price tag switcheroo. You’d find some item that you wanted from a store but couldn’t afford, search around a bit for another item with a more reasonable price, and carefully swap the little paper price tags. As long as you didn’t get greedy or have the bad luck of getting a cashier who knew the correct prices, you could get away with it — at least up until the storekeeper wised up and switched to anti-tamper price tags.

For better or for worse, those days are over. The retail point-of-sale (POS) experience has changed dramatically since the time when cashiers punched away at giant cash registers and clerks applied labels to the top of every can of lima beans in a box with a spiffy little gun. The growth and development of POS systems is the subject of [TanRu Nomad]’s expansive video history, and even if you remember the days when a cashier kerchunked your credit card through a machine to take an impression of your card in triplicate, you’ll probably learn something.

Continue reading “Retrotechtacular: Point-of-Sale Through The Years” →

Who’d Have Guessed? Graphene Is Strange!

February 7, 2025 by Al Williams 3 Comments

Graphene always sounds exciting, although we aren’t sure what we want to do with it. One of the most promising features of the monolayer carbon structure is that under the right conditions, it can superconduct, and some research into how that works could have big impacts on practical superconductor technology.

Past experiments have shown that very cold stacks of graphene (two or three sheets) can superconduct if the sheets are at very particular angles, but no one really understands why. A researcher at Northeaster and another at Harvard realized they were both confused about the possible mechanism. Together, they have started progressing toward a better description of superconductivity in graphene.

Continue reading “Who’d Have Guessed? Graphene Is Strange!” →

All You Need To Make A Go-Kart, From Harbor Freight

February 7, 2025 by Jenny List 15 Comments

The many YouTube workshop channels make for compelling viewing. even if their hackiness from a Hackaday viewpoint is sometimes variable. But from time to time up pops something that merits a second look. A case in point is [BUM]’s go-kart made entirely from Harbor Freight parts, a complete but rudimentary vehicle for around 300 dollars. It caught our eye because it shows some potential should anyone wish to try their luck with the same idea as a Power Racer or a Hacky Racer.

The chassis, and much of the running gear comes courtesy of a single purchase, a four-wheeled cart. Some cutting and welding produces a surprisingly useful steering mechanism, and the rear axle comes from a post hole digger. Power comes from the Predator gasoline engine, which seems to be a favourite among these channels.

The result is a basic but serviceable go-kart, though one whose braking system can be described as rudimentary at best. The front wheels are a little weak and require some reinforcement, but we can see in this the basis of greater things. Replacing that engine with a converted alternator or perhaps an electric rickshaw motor from AliExpress and providing it with more trustworthy braking would result in possibly the simplest Hacky Racer, or just a stylish means of gliding round a summer hacker camp.

Continue reading “All You Need To Make A Go-Kart, From Harbor Freight” →

UScope: A New Linux Debugger And Not A GDB Shell, Apparently

February 7, 2025 by Dave Rowntree 7 Comments

[Jim Colabro] is a little underwhelmed with the experience of low-level debugging of Linux applications using traditional debuggers such as GDB and LLDB. These programs have been around for a long time, developing alongside Linux and other UNIX-like OSs, and are still solidly in the CLI domain. Fed up with the lack of data structure support and these tools’ staleness and user experience, [Jim] has created UScope, a new debugger written from scratch with no code from the existing projects.

GBD, in particular, has quite a steep learning curve once you dig into its more advanced features. Many people side-step this learning curve by running GDB within Visual Studio or some other modern IDE, but it is still the same old debugger core at the end of the day. [Jim] gripes that existing debuggers don’t support modern data structures commonly used and have poor customizability. It would be nice, for example, to write a little code, and have the debugger render a data structure graphically to aid visualisation of a problem being investigated. We know that GDB at least can be customised with Python to create application-specific pretty printers, but perhaps [Jim] has bigger plans?

Continue reading “UScope: A New Linux Debugger And Not A GDB Shell, Apparently” →

When Ignoring Spam Loses You An Ice Surfacer Patent

February 7, 2025 by Donald Papp 49 Comments

Bear with us for a moment for a little background. The Rideau Canal Skateway in Ottawa is the world’s largest natural skating rink, providing nearly 8 km of pristine ice surface during the winter. But maintaining such a large ice surface is a challenge. A regular Zamboni can’t do it; the job is just too big. So the solution is a custom machine called the Froster, conceived by Robert Taillefer and built by Sylvain Fredette.

*Froster* spans almost twenty meters, and carries almost 4000 L of water. There’s no other practical way to maintain almost 8 km of skating rink.

A patent was filed in 2010, granted by the Canadian Intellectual Property Office, and later lost because important notifications started going to an apparently unchecked spam folder. The annual fee went unpaid, numerous emails went unanswered, an expiry date came and went, and that was that.

It’s true that emailed reminders (the agreed-upon — and only — method of contact) going unnoticed to spam was what caused Robert to not take any action until it was too late. We’d all agree that digital assistants in general need to get smarter, and that includes being better at informing the user about automatically-handled things like spam.

But what truly cost Robert Taillefer his patent was having a single point of failure for something very, very important. The lack of any sort of backup method of communication in case of failure or problem meant that this sad experience was, in a way, a disaster just waiting to happen. At least that’s how the Federal Court saw it when he took his complaint to them, and that’s how they continued to see it when he appealed the decision.

If you’ve never heard of the Rideau Canal Skateway or would like to see the Froster in action, check out this short video from the National Capital Commission of Canada, embedded just under the page break.

Continue reading “When Ignoring Spam Loses You An Ice Surfacer Patent” →