Frummidge

@andrewt one problem with git is that its designers and early users had only just barely escaped the vile clutches of other, worse version control systems and all of the early users only wanted the smallest possible filesystem mutation primitives in order to automate their workflows. The git command line interface works great in CI/CD and scripting to make efficient sequences of operations. If that's not the way you use the tool, then uh yes very much the set of operations is hard to use and remember. Otherwise you have to internally copy the understanding of the first two power users in order to use it well. I wish there was a discussion of "the trauma of using X made me design Y to be like this and that" and how it might be difficult to use Y if you didn't have those experiences with X.

@NanoRaptor@bitbang.social yesterday I radicalized a friend against HP Instant Ink

@monorail@glaceon.social I have some food items which ask to be left in the microwave for some number of minutes after heating; in this case, the reminder beep is a free timer in minute increments, since my microwave beeps once a minute for a few times after completing, unless you open the door.

@joshbressers@infosec.exchange @mweiss@infosec.exchange @WhyNotZoidberg@topspicy.social I'm currently working at $DAYJOB where we're integrating a newer ARM core into a system-on-chip. The software team is having trouble connecting an external debugger to this core because they don't know how the core's debug interface is supposed to work and what the micro-architectural preconditions for stopping code execution on the core are. The setup requirements are documented by ARM, at least, but that team doesn't have all the expertise it needs to set up the standard development toolchains on this new platform. Even in big companies, crucial digital and computing infrastructure knowledge and implementation experience are all funneled and concentrated to a very few subject matter experts. There are often issues which only one or two people know how to debug in a productive way. (When there are thousands of signals and hardware registers which might contribute to an issue, having to figure it all out from scratch is very hard.) The number one reason why people don't spend more time learning how to debug other issues or understanding the fundamental architecture and operation is that there's a LOT of testing to do and a LOT of possible issues to investigate and check when debugging, and the schedule of the hardware project ticks on by regardless. There's a certain reckless disregard for creating ultra-low-bus-factor technology at that low level of hardware technology because we still need all the possible micro-optimizations at the hardware level to get the power efficiency and performance that are the standard. Microelectronics design is also tediously cursed in this manner, though without the same hobby project burden.

@dngrs @vikxin what a post. as an electrical engineer, I am scared :ying_floof_surprised: