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.

Update: The hyper backend was removed.

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.

Alessandro Pignotti writing on the Leaning Technologies blog:

WebVM is a full Linux environment running in the browser, client-side. It is a complete virtual machine, with support for persistent data storage, networking and, as of today’s release, Xorg and complete desktop environments. In an instance of WebVM, everything executes locally within the browser sandbox.

WebVM runs on any modern browser, including mobile ones, thanks to WebAssembly, HTML5 and CheerpX: a novel x86 virtualization engine for browsers, developed by us at Leaning Technologies.

You may have seen other sites that run operating systems in the browser. Typically these compile an emulator to WebAssembly and host that in the browser. This works quite well with the light demands of older systems but can be a bit slow for more demanding systems.

WebVM takes a different approach. The CheerpX engine is a JIT compiler from x86 to WebAssembly and is able to run Linux binaries unmodified. WebVM adds a browser based Linux syscall implementation that allows it to run binaries, including graphical ones in the browser, much faster than using a whole system emulator.