C++ Is 45 Years Old. [Stroustrup] Says You Still Don’t Get It!

February 9, 2025 by Al Williams 117 Comments

We were surprised when we read a post from C++ creator [Bjarne Stroustrup] that reminded us that C++ is 45 years old. His premise is that C++ is robust and flexible and by following some key precepts, you can avoid problems.

We don’t disagree, but C++ is much like its progenitor, C, in that it doesn’t really force you to color inside the lines. We like that, though. But it does mean that people will go off and do things the way they want to do it, for any of a number of good and bad reasons.

Continue reading “C++ Is 45 Years Old. [Stroustrup] Says You Still Don’t Get It!” →

Software In Progress

February 8, 2025 by Elliot Williams 69 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.

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” →

Freedesktop And Alpine Linux Looking For New Hosting

February 4, 2025 by Maya Posch 37 Comments

A well-known secret in the world of open source software is that many projects rely on donated hosting for everything from their websites to testing infrastructure. When the company providing said hosting can no longer do so for whatever reason, it leaves the project scrambling for a replacement. This is what just happened for Alpine Linux, as detailed on their blog.

XKCD's dependency model — Modern-day infrastructure, as visualized by XKCD. (Credit: Randall Munroe)

Previously Equinix Metal provided the hosting, but as they are shutting down their bare-metal services, the project now has to find an alternative. As described in the blog post, this affects in particular storage services, continuous integration, and development servers.

As if that wasn’t bad enough, Equinix was also providing hosting for the Freedesktop.org project. In a post on their GitLab, [Benjamin Tissoires] thanks the company for supporting them as long as they have, and details the project’s current hosting needs.

As the home of X.org and Wayland (and many more), the value of Freedesktop.org to the average user requires no explanation. For its part, Alpine Linux is popular in virtualization, with Docker images very commonly using it as a base. This raises the uncomfortable question of why such popular open source projects have to depend on charity when so many companies use them, often commercially.

We hope that these projects can find a new home, and maybe raise enough money from their users to afford such hosting themselves. The issue of funding (F)OSS projects is something that regularly pops up, such as the question of whether FOSS bounties for features are helpful or harmful.

Writing A RISC-V OS From Scratch

January 9, 2025 by Al Williams 15 Comments

If you read Japanese, you might have seen the book “Design and Implementation of Microkernels” by [Seiya Nuda]. An appendix covers how to write your own operating system for RISC-V in about 1,000 lines of code. Don’t speak Japanese? An English version is available free on the Web and on GitHub.

The author points out that the original Linux kernel wasn’t much bigger (about 8,500 lines). The OS allows for paging, multitasking, a file system, and exception handling. It doesn’t implement interrupt handling, timers, inter-process communication, or handling of multiple processors. But that leaves you with something to do!

The online book covers everything from booting using OpenSBI to building a command line shell. Honestly, we’d have been happier with some interrupt scheme and any sort of crude way to communicate and synchronize across processes, but the 1,000 line limit is draconian.

Since the project uses QEMU as an emulation layer, you don’t even need any special hardware to get started. Truthfully, you probably won’t want to use this for a production project, but for getting a detailed understanding of operating systems or RISC-V programming, it is well worth a look.

If you want something more production-ready, you have choices. Or, stop using an OS at all.

Programming Ada: Atomics And Other Low-Level Details

January 2, 2025 by Maya Posch 6 Comments

Especially within the world of multi-threaded programming does atomic access become a crucial topic, as multiple execution contexts may seek to access the same memory locations at the same time. Yet the exact meaning of the word ‘atomic’ is also essential here, as there is in fact not just a single meaning of the word within the world of computer science. One type of atomic access refers merely to whether a single value can be written or read atomically (e.g. reading or writing a 32-bit integer on a 32-bit system versus a 16-bit system), whereas atomic operations are a whole other kettle of atomic fish.

Until quite recently very few programming languages offered direct support for the latter, whereas the former has been generally something that either Just Worked™ if you know the platform you are on, or could often be checked fairly trivially using the programming language’s platform support headers. For C and C++ atomic operations didn’t become supported by the language itself until C11 and C++11 respectively, previously requiring built-in functions provided by the toolchain (e.g. GCC intrinsics).

In the case of Ada there has been a reluctance among the language designers to add support for atomic operations to the language, with the (GNU) toolchain offering the same intrinsics as a fallback. With the Ada 2022 standard there is now direct support in the System.Atomic_Operations library, however.

Continue reading “Programming Ada: Atomics And Other Low-Level Details” →