It’s a small board with a ATtiny1616 and motor driver that mounts to the bottom of Behringer MF60T replacement faders and provides an I2C interface for reading the position, moving to a specific spot, and even setting up haptic detents, like a linear version of my SmartKnob project.

Perfect for making an intuitive smart light dimmer switch or a macropad.

Just need to find some time to finish making a proper video about it…

https://github.com/scottbez1/FaderBuddy

In aviation, commercial pilots have very strict and extensive training and monitoring and as a result are generally able to utilize automation effectively while keeping up their manual skills. There are very rarely CFIT incidents in major commercial airlines.

The opposite is true in general aviation (small private Cessnas, etc), where it’s extremely common for pilots to buy more plane than they can handle and then rely on automation to bridge their skill gap. CFIT is much more common in general aviation, along with incorrect actions in response to real system failures that should have been recoverable. Automation complacency regularly kills in general aviation.

A key thing to notice is that automation isn’t outright prohibited in either commercial or general aviation, but there are distinct regulatory frameworks based on potential impact.

We accept looser rules for general aviation because the failures are societally less severe and because the population is much larger so effective training and enforcement would be significantly harder. In commercial airliners where failures are catastrophic, we have much stricter policies and require training and testing regularly to avoid automation complacency.

Will we start to see this practice in software? Probably, but only if/when the societal cost of NOT doing it becomes more clear. We regulated aviation because crashing planes are obviously bad. We license structural engineers because collapsing bridges are obviously bad. Will automation-induced software failures hit a similar tipping point?

Some of the proposed 3d printer laws will require printers being sold to be capable of evaluating what you are using them for and blocking “bad” usages. I’m not aware of any such legislation around firearms.

From Bambu’s historical and continued actions, specifically including the orca slicer actions that this blog post was about, there is additional signal that LAN mode backpedaling was more likely an appeasement action than a shift in principles to embrace a more open ecosystem.

They ARE however deterrents to bad actions from less-than-scrupulous entities, and enforcement mechanisms against fully-unscrupulous entities.

I suspect (but will admit I am just guessing here) that Prusa would prefer not to get to the enforcement stage because it is both costly and annoying, but having that in your back pocket is, sadly, necessary in a litigious society with some number of unscrupulous actors, and the deterrent effect alone is likely enough to achieve most of their goals.

You can be entirely in favor of the open source ethos, even as a commercial entity, but then certain actors can take advantage of that ethos and just directly commercialize your R&D investment and take all the proceeds of your investment, whether or not they comply with attribution or share-alike requirements.

It’s tough seeing an open source project you’ve poured tons of care and effort into (and WANT people to share and remix and build cool things) get more or less “extracted” for profit without contributing back (code or money).

At the end of the day, none of it really matters unless you’ve got money and time to actually try to enforce your licenses, or have enough customer mindshare to effectively change the behavior of bad actors without needing legal action.

I’ll probably use licenses like Prusas in the future for similar reasons, even though I generally prefer to use less restrictive ones. Bad actors, or even just non-benevolent actors, can really sour the open source ethos, and it sucks but there’s no way to legally enforce “don’t be a jerk” without restricting a legal document in slightly unpalatable ways.

Sure, a manufacturer that didn’t need to course correct yet doesn’t mean they won’t change their stance in the future, but the same is true for one that already course-corrected.

We see this with privacy eroding laws continually - legislators will “listen” and course correct if there’s pushback, only to reintroduce the bill in the next legislative session, repeatedly, until it gets passed.

I’d prefer the one that hasn’t yet signaled a desire to do something negative in the past to one that has, even if they walked it back later.

They rubbed people the wrong way launching the CC2 with multi-color support before they developed the multi-color add-on that was promised for the original CC. I didn’t plan on multi-color with the CC, so that didn’t personally bother me too much.

I recently got a Snapmaker U1 for multi-toolhead prints and love it so far - much less waste than a filament changer and I’m using it for more exotic prints like a mix of conductive and regular PLA in a single part that wouldn’t work well in a filament changer single toolhead printer.

And I still use my CC for occasional single color prints (recently it’s been dedicated to TPU but I’m probably going to move that over to the U1 so I can do “over molded” TPU+PLA prints).

In short, if you’re willing to spend more I’d highly recommend the U1 if you know you’d benefit from the toolchanger. CC is probably a fine budget machine but there are a lot of other similar budget corexy machines to consider these days as well (I got CC when it was groundbreaking for features at its price but competition has caught up by now).

And it’s not just wireless that’s inefficient; with a usb connection you’ll typically lose at least 15% in a good buck/boost stage and there’s 2 involved in a usb battery pack: one in the battery pack itself to step up/down from pack voltage to the negotiated PD voltage, and then another lossy stage in the phone stepping down to 3.7v.

Only drop off in a separated bike lane if you have disabled or elderly customers who require direct access to the curb  You may only pick up in a separated bike lane if the dispatcher tells you that the customer is disabled and must be picked up at a location that is next to a separated bike lane.

Taxi drivers often intentionally misstate this regulation because it’s more annoying to follow the law and find a legal place to stop so they pretend they are allowed to use bike lanes for any reason.

Unfortunately for those of us who just want to eat a nice filling meal at the fixed price all you can eat buffet of AI subscriptions, a minority of customers keeps paying for the all you can eat buffet and staying for hours and bringing containers to sneak food out when they leave. And they keep wearing disguises to try and evade detection.

It’s a losing battle for the provider, which ultimately means the subscription pricing model can’t work, which hurts the majority of customers that just want to use the system as intended and no longer have a subscription model available.

I have plenty of frustrations with Anthropic as a paying customer, but this specific false positive abuse detection doesn’t strike me as all that awful, just some annoying collateral damage. I’d rather have that than no subscription model at all.

It was also nice trying out some RTL-SDR apps as soon as I got it without having to figure out how to build and install the Debian packages from source first.

It drives me nuts every time I have to switch from Firefox to Chrome to use webusb or webserial.

Things that I’d consider table stakes that Phabricator had in 2016 - code movement/copying gutter indicators and code coverage gutters - are still missing, and their UI (even the brand new review UI that also renders suggestion comment diffs incorrectly) still hides the most important large file changes by default.

And the gutter “moved” indicators would be more useful than ever, as I used to be able to trust that a hand-written PR that moves a bunch of code around generally didn’t change it, but LLM refactors will sometimes “rewrite from memory“ instead of actually moving, changing the implementation or comments along the way.

And the system is designed to set up drivers for failure.

An HCI challenge with mostly autonomous systems is that operators lose their awareness of the system, and when things go wrong you can easily get worse outcomes than if the system was fully manual with an engaged operator.

This is a well known challenge in the nuclear energy sector and airline industry (Air France 447) - how do you keep operators fully engaged even though they almost never need to intervene, because otherwise they’re likely to be missing critical context and make wrong decisions. These days you could probably argue the same is true of software engineers reviewing LLM code that’s often - but not always - correct.

There are always systemic factors that can be improved, for example working on street design to separate dangerous cars from children, or transportation policy by shifting transportation to buses, bikes, and walking where the consequences of mistakes are significantly reduced.

Cars are the #2 killer of children in the US, and it’s largely because of attitudes like this that ignore the extreme harm that is caused by preventable “accidents”