scottbez1

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…

https://github.com/scottbez1/FaderBuddy

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?

More strictly than firearms, in fact.

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.

It’s rough but I understand it.

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!

Heh, many years ago I actually started writing a dedicated diff viewer app for Android [0] that specifically had synchronized horizontal scrolling between the two sides, and I remember finding it relatively usable in landscape, and I’m sure modern phones with larger and higher density screens would be even better.

But yeah, you definitely need a native experience to make side by side diffs viable on mobile.

[0] https://github.com/scottbez1/superdiff — I wish I had recorded some videos of the app back then. My code review workflow back then eventually stopped including diff attachments on code review emails, so I abandoned development on it.

I’d love this, if only for improved diff reviews possible compared to a terminal window! Would also work better for intermittent connectivity.

How do I use a laptop while standing on a train each day? It sounds like a laptop is sufficient for you, but I suspect (based on myself and other responses in this thread) that a laptop is not always viable for many people; this tutorial appears targeted toward those people.

I’ve actually considered a neck/shoulder support for a laptop in the past but decided against it because it’d be cumbersome and make me a theft target.

As for AI, personally speaking I use AI coding tools to allow me to continue enjoying some hobby side projects with less free time available with a kid. It’s been a massive boost to my happiness in a generally low stakes area. I’m curious to see if I can get a similar unlock on my short and interrupted commute times as well, which is why I (personally) find this article interesting.

It’s a simple idea but one that hadn’t occurred to me yet.

I spend hours each week riding transit, and use Claude for a bunch of side projects and have Tailscale set up already, so looks like I’ll be giving this a try this week!

Doom coding might be doomed while I’m in the transbay tube though, with awful cell service…

How’s the diff review? I rely heavily on the vs code integration for nice side by side diffs, so losing that might be a problem unless there’s some way to launch the diffs into a separate diff viewer app on the phone.

Similar for cooktops - I’ve seen IR-reflectance-based touch controls go haywire due to dimmable overhead lights, and heard of frustration with capacitive controls going haywire from liquid splatters.

There are some very real benefits to touch interfaces in cooking (primarily ease of cleaning a solid flat surface, and manufacturers don’t need to worry about moisture ingress), but it’s pretty hard to make one that actually consistently works in a way that won’t accidentally burn your house down when your cat walks across the cooktop in the middle of the night. I’m personally going to stick to knobs and buttons in the meantime.

Can you be more specific about these “mandates” you take issue with?

IIHS doesn’t have any mandate power over manufacturers (they are not a regulatory body) but they do align with insurance company interests, whose goals are to pay out less for damages from vehicle incidents, and therefore IIHS logically would theoretically be focused on actuarial data-driven analysis. If you have specific examples of where this has not been the case, I’d love to learn more.

Very different standards - in its current form of emergency autoland it just needs to be proven to result in equal or better outcomes as a plane with no rated pilot onboard; the best case is another person that knows how to use the radio and can listen to instructions but the more likely case is a burning wreckage when the pilot is incapacitated.

To always auto land it needs to be as good as a fully trained and competent pilot, a much higher standard.

Latency makes this hard even with local connections, it’s essentially impossible due to physics to do it offshore.

And I believe Waymo remote access only allows providing high level instructions (like pull over, take the next right, go around this car, etc) precisely because full direct control with a highly and variably latent system is very hard/dangerous.

And in an emergency situation you’re likely to have terrible connectivity AND high level commands are unlikely to be sufficient for the complexity of the situation.

Yeah, the correlated risk with AVs is a pretty serious concern. And not just in emergencies where they can easily DDOS the roads, but even things like widespread weaknesses or edge cases in their perception models can cause really weird and disturbing outcomes.

Imagine a model that works real well for detecting cars and adults but routinely misses children; you could end up with cars that are 1/10th as deadly to adults but 2x as deadly to children. Yes, in this hypothetical it saves lives overall, but is it actually a societal good? In some ways yes, in some ways it should never be allowed on any roads at all. It’s one of the reasons aggregated metrics on safety are so important to scrutinize.

This doesn’t seem that crazy to me - a broadly applicable coordinated OTA zero day applied across cars during US rush hours has the potential to result in likely hundreds of thousands of deaths in a few hours if safety critical systems like airbags can be tampered/inhibited by OTA-capable systems.

The scale of car travel plus the inherent kinetic energy involved make a correlated risk particularly likely to lead to a mass casualty event. There are very few information system vulnerabilities with that magnitude of short-term worst case outcome.