I’ve been building a plug-and-play controller to use motorized faders with ESPHome and other microcontrollers easily, called FaderBuddy.
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…
I think the big question here is how effective can you make training and monitoring across a widespread population in practice?
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.
You are conflating two things: appeasement and actual change in principles. Externally it can be hard to distinguish these, but it is easier to get a sense of it with more signals.
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.
What you’ve said is true but also misses the point. Licenses have never been about stopping bad actions because a bit of text can’t prevent someone from buying materials and building things, just like a speed limit sign has never stopped someone from speeding (unless they crash into it).
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.
Correction is one of many signals, and it’s better than ignoring pushback, but it’s still usually worse than not needing the correction in the first place.
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.
I have the original CC. It’s a fine budget machine for single color - plenty fast and good quality prints.
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).
I wouldn’t recommend this outright without recommending some research first. Some brands put the over-discharge protection into the tools instead of the batteries, so using one of those batteries in other tools may permanently kill the battery pack.
They’re incredibly wasteful due to inefficient power transfer which is a huge issue with wireless charging.
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.
This is false. It is only legal in the rare event that a passenger requires curb-side access for accessibility/ADA reasons; any other use is still illegal. To quote SFMTA taxi training:
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.
It definitely would make sense, especially if they are capacity constrained, but it’s also a losing PR move for whoever moves first in the space unless the big players all shift at the same time.
Subscription models only work when marginal costs are low and/or there’s a good variety of usage that roughly averages out. Or, you need to be able to kick out abuse.
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.
I was surprised that incident didn’t seem to get as much attention since that was a pretty major data corruption bug, but I guess it was a much smaller scope of impacted repos/customers than a lot of these availability issues?
Yep, I’ve bought a few thermal printers recently and webusb support (marketed as Chromebook support) was a major deciding factor. Thermal printers aren’t well supported by built in printer drivers, so it’s nice to not have to install some questionable driver software with access to my whole computer and instead have a sandboxed chrome extension with enumerated permissions. I’ve also poked around the extensions’ minified js source out of curiosity and as a basic security audit
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.
How does the security of userspace drivers compare to having drivers within a sandboxed web environment with access to only the devices you’ve explicitly allowlisted?
GitHub seems entirely uninterested in improving the code review experience (except maybe the stacked PRs thing if that ends up shipping) for well over a decade now.
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.
Yeah, Tesla gets to blame the “driver”, and has a history of releasing partial and carefully curated subsets of data from crashes to try to shift as much blame onto the driver as possible.
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.
The US commercial aviation industry did not get to its excellent safety record by simply shrugging and accepting a “no-fault accident”.
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”
I’ve found that adafruit usually includes a cuttable solder pad for the power led when there’s real estate available. Just cut one of those traces this week in fact!
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