Certified

This would force everyone using a VPN to submit ID verification in one fell swoop

I contend that is impossible to make an unbiased AI. I did an AI image recognition project several years ago. It used yolo to categorize rust into grade 1, 2, and 3 for offshore platforms. When creating our training dataset, we had different rust inspectors from different parts of the world drawing different lines in the sand between what was category 1, 2, and 3. We had to eventually pick which bias we wanted to roll out worldwide. The advantage for a giant corporation was that now the same consistent bias was being used worldwide and fewer people had to be safety trained to go on the offshore platforms. If that incredibly dull and basic application can’t be unbiased, I don’t think it is possible to avoid bias in anything produced with a training dataset. The very word “training” implies it. Someone somewhere decides A is in the training and B is not, and a bias is born, intentionally or not.

So the task is really to find the AI with the bias that works best for your application, not to try and remove bias.

Apple A series CPUs and now M series CPUs have consistently been top of the benchmarks in single core performance for most of the last decade. This even holds true when pitted against desktop Intel and AMD chips. For someone who works with workloads that struggle to be very multithreaded, I do watch this. I must be that 0.1% of the audience

Vindication! I’ve spent over a decade of my life putting physical interactives into museums. I have preached (sold) many museums on the stance that they should put unique experiences into museums that can’t happen on an iPad at home, to varying degrees of success. The museums that have listened are the ones that continue to be wildly successful to this day.

They are hard to do right though. I used to compete in combat robotics and the stresses put on museum exhibits is higher. I tell my new engineers that if their exhibit can be dropped into a gorilla enclosure and survive, they are about half way strong enough. Little makes up for raw experience in the art of building bomb proof exhibits, and many companies have failed before getting good. The amateur hour exhibits from the low bid newcomers that inevitably fail and/or need a lot of expensive maintenance has left a sour taste in a lot of museum’s mouths. A lot of those museums have knee jerk reactioned the opposite direction to touchscreen exhibits, only to see their ticket sales slowly drop. Thankfully, i’m seeing the pendulum of the industry swinging back towards physical interactives again.

They are probably referring to the much larger driver facing curved touchscreens for carplay/android auto that merges with the screen used for the instrument gauge. Also, the driver assist tech on the newer kia/hyundais is very good, especially for highway traffic, needing very little driver intervention.

Embrace, Extend, Extinguish.

Microsoft knew they would never get significant market share unless they offered open source alternatives that let you circumvent the telemetry in the early days of VScode. Embrace. The acquisition of github was part of this strategy. They made an ecosystem that sucked a lot of plugin developer talent into their ecosystem. Extend. Now the market share is firmly in their grasp and competitors have become weaker. Extinguish.

Thanks for pointing that out. I realized I called out the wrong chip. I was actually trying to call out the Max6818.

Edit: I meant to call out the MAX6818, not MAX 3218

I guess I should rephrase. It saves all the interrupts except the one triggered at 40ms delay. For every button press without hardware debouncing, you can have 10s - 100s of 1to0 and 0to1 transitions on the microcontroller pin. This is easily verified on a oscope, even with "good" $50+ honeywell limit switches. Every single one of those transitions triggers an interrupt and robs cpu cycles from other things the microprocessor is doing. The code in the interrupt gets more complex because now it has to do flag checks and use timers (bit bashing) every time they are triggered instead of just doing the action the button is supposed to trigger. None of this is to say one way is the "right" or "wrong" way to do it, but putting the hardware debouncing complexity into hardware specifically designed to handling it, and focusing on the problem I am actually trying to solve in firmware is my personal preferred way of doing it.