Flameeyes
Which is exactly why this particular problem is a lot more annoying for hobbyists rather than actual industry players.
Firstly, it appears a few people have not actually went through and read what I wrote and suggested, well pretty much the same thing I suggested on the article! If you can get away with 5V, I link to 6p connectors that are indeed very easy to use, and even provided links to my own projects [1] using them! Please, have a read of the article, maybe there is something I missed, but it's not that.
Secondly, I made this very clear that what I'm writing about is for hobby projects. Of course a lot of the energy I'm spending looking at options here is not going to be a worthy RoI if you're doing this professionally. That's the point of a hobby project! [2] But it also means that I'm looking for things that are easy to source and to modify for different uses. If the answer is "Use that one module, that only one manufacturer makes" or "Get a cheap AliExpress thing that maybe will exist in two years and maybe not", then I feel like it's all for nothing. When I looked into this (which admittedly by now is _months_ ago!) finding the components for the fpx board [3] (which someone linked to down in the thread already) was basically impossible as the STUSB4500 was out of stock everywhere.
Thus, trying to find alternatives and trying to "pay the development price" once, and have others be able to pick up some code for ESPhome or Zephyr and build upon it. I'm sure there's plenty of closed-source implementations of these in ECs and similar closed-source firmwares, so why not get it in hands of more people?
Also, honestly, I enjoy the challenge, when it's not frustrated by manufacturers publishing outright lies in their datasheets (more on that in the next few months!) and since I had some additional spare time for a couple of months, I connected it with a fundraiser [4] not for me but for Diabetes UK. Y'all are welcome to donate to Diabetes UK if you want to read more on this topic. Some of it is written down already, but other stuff has been basically stalled.
[1] https://flameeyes.blog/2023/07/30/acrylic-lamps-finally-work... [2] https://flameeyes.blog/2020/01/19/unnecessary-but-required/ [3] https://blog.oxplot.com/fpx/ [4] https://tiltify.com/@flameeyes/gone-with-the-wind
Giving up on understanding and documenting it is not going to improve the situation, we'll just end up relying on a handful of manufacturers that are the only ones able to supply what everyone else built upon… and the chip shortage of 2020/2021 pretty much has shown how bad that can get.
But as it's visible above, my artistry leaves a lot to be desired. So for something like this I commissioned it.
The artist is https://twitter.com/FurryViza and she did a great job.
Indeed, as others noted already, I clarified that everything I'm writing is from the point of view of my niche, which (as the title implies) is systems engineering. In the SRE/PE/DevOps meaning of the name, since that's also an adopted job title that has quite different semantics in other fields.
I'm glad _someone_ keeps track of where bits and bobs of jargon come from, because they'll make great trivia in a future episode of QI, but to be perfectly honest, I'm not profoundly interested in the philology of our terms as much as I have an interest on providing a quotable reference to explain specific work.
There's a significant drift in its meaning, and there's also dissonance between different areas in the same industry. That's why I wanted to define how this jargon ends up used by me and my peers, and provide a reference point.
(There's a bigger point about value judgement -- I tried not to give too much negative or positive connotations to the whole yak situation, because I don't believe there's an objective mode for it.)
Since I grew up with Italian Disney comic books, an anthropomorphic yak sounded perfect, so I turned to a friend for suggestions on artists, and eventually contacted FurryViza (https://twitter.com/FurryViza).
I just gave her a prompt of what I had in mind and let her take it from there. I'm absolutely stunned by how it turned out!
You see, my employment _is_ with Meta now, and was with Google before — it never was with Alphabet, of which Google is a fully owned subsidiary of.
I think the distinction makes sense, among other things because with few exceptions, going from one Alphabet subsidiary to another requires a full interview cycle, not just a transfer request.
Yup, there's also the more common approach of implementing extensions in C (or equivalent), possibly with an intermediate language.
For example, Cython is a much more scalable approach, in my experience, than attempting to describe the interface in Python and using a libffi-style binding.