2025 had a bunch of bits of fun mathematical trivia:

45² = 45 x 45 = 2025

Also,

9² x 5² = 2025

40² + 20² + 5² = 2025

My favourite?

1³+2³+3³+4³+5³+6³+7³+8³+9³ = 2025

Ha! I really should have known that last one, given that I once wrote a paper about the sum of cubes. https://dl.acm.org/doi/abs/10.5555/1378446.1378486

I imagine pink is considered too close to red tail lights.

Honestly, if I was writing some code that depended on dicts being ordered I think I'd still use OrderedDict in modern Python. I gives the reader more information that I'm doing something slightly unusual.

Same. Usually if a language has an ordered map, it's in the name.

One key point that people overlook with that paper is that they were applying the coding standards retroactively. Taking an existing codebase, running compliance tools, and trying to fix the issues which were flagged. I think they correctly identified the issue with this approach in that you have all the risks of introducing defects as part of reworking the existing code. I don't think they have much empirical evidence for the case where coding standards were applied from the beginning of a project.

In my opinion, the MISRA C++ 2023 revision is a massive improvement over the 2008 edition. It was a major rethink and has a lot more generally useful guidance. Either way, you need to tailor the standards to your project. Even the MISRA standards authors agree:

"""

  Blind adherence to the letter without understanding is pointless.

  Anyone who stipulates 100% MISRA-C coverage with no deviations does not understand what the are asking for.
  
  In my opionion they should be taken out and... well... Just taken out.
    - Chris Hill, Member of MISRA C Working Group (MISRA Matters Column, MTE, June 2012

"""

Back in my undergrad days I built a similar clip out of a broken clothes peg, hot glue, and some 2.54mm headers. It worked well.

I think the web itself would be stronger if it was served in pure HTML and not 95% created by JS SPAs.

Stoke Space[1] uses a similar system, letting people write arbitrary code to generate a static configuration for their launch vehicle. It means you get all the power of something like Python during development but also a deterministic, bounded config for the critical flight systems. I think their config files are just TOML that is consumed by Rust.

I'll try dig out a link to the talk one of their Flight Software Engineers did on the concept.

[1] https://www.stokespace.com/

I've only had a cursory look at Varlink, but it almost felt too simple. In particular the lack of unsigned or sized integers.

This might enf up being be fine, but it gave me pause when I looked at it previously.

Varlink exists only to be extremely simple.

The Linux ecosystem was using D-Bus for basically everything. But there was some need for IPC in early boot, before any D-Bus brokers were started.

Varlink was the answer, as a simple direct (vs DBus's broker mediated) IPC.

It's JSON with some simple idea of RPC added to it. With the main idea apparently being that it is human-readable.

We've been using Varlink for one project, but I've never found myself in a situation where I had any benefit from the data being JSON. You rarely read the raw data. But compared to gRPC or CapnProto, you lost compile-time type checking and now you need 10mins of testing a vending machine before you get a "key not found"-error because you missed one spot on renaming.

Also, I've written varlink-cpp building on asio and nl-json at some point: https://github.com/wolletd/varlink-cpp. But as our varlink usage declined, it never found much usage and isn't maintained.

"you lost compile-time type checking" makes it sound like you haven't been using code generation? Varlink has an interface definition language which makes everything type-safe.

I found Hillel Wayne's series of articles about the relationship between software and other engineering disciplines from a few years fairly insightful [1]. It's not _exactly_ the same topic but a lot of overlap in defining wht is "real engineering".

[1] https://hillelwayne.com/post/are-we-really-engineers/

Wasn't there a phenomenon with the GPUs being retired from crypto mining operations being basically cooked after a couple of years. Likely because they weren't keeping temperatures in check and just pushing the cards to their limits.