My enjoyment is shifting from this to having a well designed, tested, good looking, and very usable hobby SW, with features I need and can play with or do fun or useful stuff with. :)
I can also work on very fun things with computers now, that I'd just not even think of previously. I just love the idea of the program, but I'm not interested in learning details of how to implement it. Last such thing is teaching computer to dance and improvise Bachata to music. :) Yeah, I can spend months on details of 3D, or physics simulation, or skeleton animation, or things like that, but that's not what I'm interested in. I'm interested in the dance aspects itself and matchin to music, and lead-follow simulation (where the computer plans the lead actions to some extent, and follow is just a reactive machine with some degrees of impovisational freedom) and all the details of how the actual skeletons are visualized on screen I literally can care less about. All I care about is impairing knowledge of freedom of movement of lead and knowledge of freedom of what can be led while hands are connected or visually by what follow can observe and lead can signal through intentional movement, and not how the program will execute this.
Nothing like that existed previously, and I would not be able to get to fun interesting things without wading throught shit ton of uninteresting parts. But now I within a span of 24 hours have something that I can have a base implementation of a 3D dance lead/follow emulator with weight transfer, balance skeleton joint lead-follow hand connection weight trasnfer and ground connection based emulator that I can paly with emulating the dance on top of, and I can focus on the actual dance/music conenction, and tiny details that make the emulated dance look fun, surprising, natural, and fit Bachata style and playfulness.
I delete all comments (except one liners that explain meanings of non-obvious constants / register values, etc.) from actual code, and just keep a plaintext README of overall current concepts/design in the given directory that has to read as a human useful prose (eg. have a defined audience, describe unfamiliar concepts first, then goals, how they are achieved, benefits/drawbacks, quirks).
Code is easier to look at/read that way. I skim the README, then read the code.
Otherwise code comments are just nuts and unmanageable, because there's no hard/enforcing feedback loop on those. They can contain anything, even non-sensical things, old information/decisions, history of development, wrong information, contradictory information, and code still compiles. There's no pressure to keep them in check.
Lint step that fails build if code contains long comments is also useful as a hard-constraint.
Slightly larger switch() statement and you'll run into peephole optimizer just eating away at jump target instructions without telling the jumper to adapt the destination address for the case. Of course the result is completely random code execution. Things like that. :)
But I wrote non-trivial code with sdcc regardless. My favorite 8051 targets are FX2LP USB boards from aliexpress. :)
Microchip XC compiler has support for those. They recently dropped the licensing requirement, so while it's not FOSS, it's freeware now, without limits.
I don't like attestation. That is dangerous to user freedom. I don't mind other parts of this technology.
Attestation already destroyed user freedom in mobile app ecosystem. You can't just implement your version of some mobile banking app or whatever just by using original app's API, because dark overlords of gated app comunities allowed app authors to prevent this on OS level by giving them attestation tools.
That's actually a good use case for HW keys. Since untrusted computers are much more likely to have keyloggers/malware, etc. So you don't need to reset password and invalidate all sessions after each such login on an untrusted computer.
I can back up my FIDO2 (non-)resident keys too. In the end it's just a piece of HW with some secret material inside. non-resident FIDO2 keys are easier to back up, because the master secret seed is fixed and shared for all origins and there's nothing stored on the key.
I'm in the process of optimizing a bootolader for my various SoC/SBCs and even the cheapest, oldest least powerful SoC from 15 years ago can manage AES-CBC via crypto accelerator at 50 MiB/s. There's no excuse.
You can achieve 50MiB/s if that's all that you're doing. I've worked with some DSPs (TI's DaVinci line) where some operations would abort if DDR was overwhelmed.
For example, passing a frame of video (YUV) into the peripheral which can resize the overall image, would fail if the system was busy with other DMA transfers. You could attempt to resize again, but there were no guarantee that it would complete successfully. Your options are to reduce overall DDR utilization or drop frames. In an application like Flock's, dropping frames is likely something they need to avoid.
The system in question is doing similar tasks, and I don't think that what I'm suggesting is out of the question.
They can choose the SoC that would be able to fill the requirements. Eg. almost all Rockchip SoCs have NoC with configurable QoS on master ports (even the cheapest IP camera targetted SoCs that cost like 2-3$), or some other interconnect mechanism that can make it so that SDRAM controller gets tasks in some user selected priority order (eg. you deprioritize CPU in favor of camera interface and other things). This is not a new tech. It already existed when Flock was founded.
And in any case. Passing compressed video streams or pictures through HW encryption engine will not saturate 1.5+ GiB/s or whatever even the lousiest 16-bit DDR3 at 400MHz would give you, not even close. It would be like a fraction of a percent of total bandwidth.
I can also work on very fun things with computers now, that I'd just not even think of previously. I just love the idea of the program, but I'm not interested in learning details of how to implement it. Last such thing is teaching computer to dance and improvise Bachata to music. :) Yeah, I can spend months on details of 3D, or physics simulation, or skeleton animation, or things like that, but that's not what I'm interested in. I'm interested in the dance aspects itself and matchin to music, and lead-follow simulation (where the computer plans the lead actions to some extent, and follow is just a reactive machine with some degrees of impovisational freedom) and all the details of how the actual skeletons are visualized on screen I literally can care less about. All I care about is impairing knowledge of freedom of movement of lead and knowledge of freedom of what can be led while hands are connected or visually by what follow can observe and lead can signal through intentional movement, and not how the program will execute this.
Nothing like that existed previously, and I would not be able to get to fun interesting things without wading throught shit ton of uninteresting parts. But now I within a span of 24 hours have something that I can have a base implementation of a 3D dance lead/follow emulator with weight transfer, balance skeleton joint lead-follow hand connection weight trasnfer and ground connection based emulator that I can paly with emulating the dance on top of, and I can focus on the actual dance/music conenction, and tiny details that make the emulated dance look fun, surprising, natural, and fit Bachata style and playfulness.
reply