Solène Rapenne:

Last month, I decided to leave the OpenBSD team as I have not been using OpenBSD myself for a while. A lot of people asked me why I stopped using OpenBSD, although I have been advocating it for a while. Let me share my thoughts.

First, I like OpenBSD, it has values, and it is important that it exists. It just does not fit all needs, it does not fit mine anymore.

Here is a short list of problems that, while bearable when taken individually, they summed up to a point I had to move away from OpenBSD.

Solène has been active in the OpenBSD project for many years. As well as contributing to the project she also wrote dozens of blogs posts on real-world use of OpenBSD on the desktop.

OpenBSD definitely has some novel ideas but has never really spoken to me or my values. The main issues for me is that it has always run hot on the devices I’ve tried it on, and the performance has been quite lacklustre. It’s good to have options though, and we’re spoilt for choice in the open-source operating system space.

Jo Hinchliffe on the FreeCAD blog:

After more than twenty years of intense and sustained development, the FreeCAD community is proud to announce the release of version 1.0. FreeCAD 1.0 is now available for download on all platforms.

In software development, version 1 usually means: our software is now stable and ready for “real work”. If you are a FreeCAD user, you know that FreeCAD has been ready for real work for years, and is used in productive, professional activity all over the world already. We in fact were tempted many times in the past to cut to the chase, and call the next version 1.0 already!

But we didn’t. Since the very beginnings, the FreeCAD community had a clear view of what 1.0 represented for us. What we wanted in it. FreeCAD matured over the years, and that list narrowed down to just two major remaining pieces: fixing the toponaming problem, and having a built-in assembly module.

Twenty years is a long time for a project to survive, especially a volunteer-led one. Congratulations to all involved on shipping 1.0.

FreeCAD is my CAD tool of choice, mostly for designing things to 3D print. When I got my 3D printer 3 years ago I didn’t really entertain using any of the proprietary CAD tools. I wanted to use something that worked on Linux and would continue to do so into the future—without a monthly cost like a lot of software these days. From what I see in YouTube videos of people using alternatives like OnShape, FreeCAD might not be the easiest or full-featured tool but for my usage it has been perfectly fine.

Sean McArthur, creator of the hyper HTTP library:

hyper in curl is nearly complete, but it needs a champion. Without a partner actively engaged that wants to enable and ship, it’s now on the path for being deprecated and removed.

But the upkeep of the feature isn’t free, in both the curl and hyper repositories. Because of that, and without a committed organization wanting to ship it, it’s planned to be removed at the start of 2025.

The hyper in curl project is an interesting case study. On the one hand, many folks want improved memory safety in their projects, but on the other I’m not sure many users of curl are keen to be the first to make the switch to the hyper backend.

Also, a lot of software that consumes the library probably isn’t in a position to control the backend—they just use what is installed on the host system. This is why Sean is asking for a backing vendor or Linux distribution that does have control over the backend.

Additionally, I imagine many projects that are in control of the backend are not keen to introduce the Rust dependency into their build, instead sticking with the devil they know. For projects that are open to Rust, I suspect they’re more likely to use hyper directly, thus the curl backend is not particularly relevant to them. Nonetheless, it would be a shame to see the hyper backend removed as this is a great opportunity in one of the most widely used libraries in the world.

The Transit app blog:

This is the holy grail of underground detection: since you can predict where a rider is, you can show them where they are on a map, update their ETA, and tell them when to get off at the right station.

What’s even more wonderful? Our station counting works completely offline. Both of our models (the motion classifier, and the mixer) have been compressed into tiny files that run on your phone, without sending any data to Transit’s servers.

No tracking. No cookies. Your vibration data is your own damn business!

Not only did they make it run offline, on your own device, but they also didn’t use the term “AI” at all in the post. When so many other companies are rushing to brand everything slightly more complicated than if-then-else as “AI” this is refreshing. Kudos to them.

xssfox:

In part one I left you with a cliff hanger regarding page calls. And I particularly like this little note:

This shouldn’t be hard

Like it’s a radio from 1993. Easy right?

That was nearly 7 months ago.

Page calls are text messages sent between radios. Essentially SMS for radios. Or I guess WhatsApp(?) messages for radios. The protocol is very similar to the selcall protocol, just with the message spliced in…. however…..

Codan decided that page calls should be locked down. My assumption here is that the 93xx series of radios were the first by Codan to be advanced enough to allow paging and to keep a market edge they wanted to make it harder for competitors to provide interoperability (pretty sad imho). So page calls include two extra bytes that are validated before receiving.

The rest of the post details the process taken to reverse engineer the generation of these two bytes, including the development of not one, but two 8051 emulators.