scottbez1

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.

Flashing can be easy, sure. Compiling that binary, including library management, is not, unless you’re using something like micropython. CMake is not hobbyist/student-friendly as an introductory system. (Arduino isn’t either, but platformio with Arduino framework IS! RPi refuses to support platformio sadly)

Arduino took over for 3 reasons: a thoughtful and relatively low cost (at the time) development board that included easy one-click flashing, a dead-simple cross-platform packaging of the avr-gcc toolchain, and a simple HAL that enabled libraries to flourish.

Only the first item, and a bit of the second), is really outdated at this point (with clones and ESP32 taking over the predominant hardware) but the framework is still extremely prominent and active even if many don’t realize it. ESPHome for example still will generally use the Arduino HAL/Framework enabling a wide library ecosystem, even though it’s using platformio under the hood for the toolchain.

Even folks who “don’t use Arduino any more” and use platformio instead are often still leveraging the HAL for library support, myself included. Advanced users might be using raw esp-idf but the esp-idf HAL has had a number of breaking API changes over the years that make library support more annoying unless you truly need advanced features or more performance.

None of those bullet points are contradictory though?

They are all completely aligned with a policy reducing non-essential public exposure, with a tiered approach for transport that limits public exposure where better alternatives exist.

Lock-in usually just refers to a situation where switching costs are (perceived to be) higher than the net benefit, within some reasonable payoff period. It can include things like high cost to extract data, but it can also include things like network/social effects.

The latter is a huge reason companies strive to establish "platforms" and suites of connected apps - even if competition is cheaper/better in a vacuum, it still may not be worth the effort to switch if you're already established within an ecosystem. The goal is vendor lock-in even if they're not holding your data hostage (though they might do that too).

Dropbox recently broke (accidentally or intentionally) hosted images/thumbnails from their Paper docs product (which they're quietly but noncommittally killing off) and that was a good wakeup for me to stop trusting hosted storage. And I'm saying this as a former Dropbox engineer of ~6 years who has plenty of free Dropbox storage for life. The brain drain and profitability crunch is real.

Recently bought a 14TB HDD and downloaded my entire Dropbox, Google Photos, and Lightroom photos. Planning to set up an off-site copy as well, and will probably build out a proper NAS within a few years.

On the topic of small LED panels, Jason of Evil Genius Labs has been making some really small LED panels [0] with addressable 1mm x 1mm LEDs (yes, individually addressable AND only 1mm on each side!). Fitting 128 onto a 1" circle is pretty sweet.

I keep meaning to design some PCBs with them [1] but it's too far down my ever-growing list of projects to see the light of day...

[0] https://www.evilgeniuslabs.org/one-inch-fibonacci128

[1] https://www.lcsc.com/product-detail/C5349953.html

The last point I think is most important: "very subtle and silently introduced mistakes" -- LLMs may be able to complete many tasks as well (or better) than humans, but that doesn't mean they complete them the same way, and that's critically important when considering failure modes.

In particular, code review is one layer of the conventional swiss cheese model of preventing bugs, but code review becomes much less effective when suddenly the categories of errors to look out for change.

When I review a PR with large code moves, it was historically relatively safe to assume that a block of code was moved as-is (sadly only an assumption because GitHub still doesn't have indicators of duplicated/moved code like Phabricator had 10 years ago...), so I can focus my attention on higher level concerns, like does the new API design make sense? But if an LLM did the refactor, I need to scrutinize every character that was touched in the block of code that was "moved" because, as the parent commenter points out, that "moved" code may have actually been ingested, summarized, then rewritten from scratch based on that summary.

For this reason, I'm a big advocate of an "AI use" section in PR description templates; not because I care whether you used AI or not, but because some hints about where or how you used it will help me focus my efforts when reviewing your change, and tune the categories of errors I look out for.

RPi's toolchain situation is awful for beginners/hobbyists. CMake and non-manifest-versioned toolchains are a huge barrier to entry. I'd love to use the hardware but have given up multiple times because I'd rather spend my time writing code than wrestling with toolchain setup. And they won't support platformio which could make things massively easier for beginners to set up.

Here's an excellent video from Juan Browne around the challenges that wires present to aircraft operations [1]. Some of these are human factors for manned aircraft, like seeing a wire but then forgetting it's there, but one of his points is that it's simply safest to avoid flying below 1000ft AGL. That's not an option for drones today, and they presumably don't (yet) have the ability of humans to make inferences about the likelihood of cables near cranes and transmission line towers, making them particularly vulnerable.

[1] https://youtu.be/jjV_k4-DstQ

This was years ago when I was younger and had more free time. I called SFMTA traffic directly (you learn the menu tree quickly). It varied but I want to say it usually took between 20 minutes to over an hour, including multiple callbacks to check on status and ensure they knew I was serious

In some ways, yes, though not in many cities like SF, NYC, Chicago, Seattle, etc.

But it's also a chicken and egg problem: often transit is not viable or is too slow precisely because everything is devoted to cars. The SF Van Ness BRT is an excellent example - I used to routinely get off the 49 bus and walk faster than it stuck in car traffic, but after the BRT the bus is a much better and faster experience than driving could ever be.

One of the most common reasons for watering down or canceling pedestrian, transit, and biking infra projects is a refusal to negatively impact driving in any way, even if the net societal benefit (especially to lower income households who take transit at much higher rates) is far greater.

Good governance requires sometimes unpopular choices (see Paris's recent bicycle transformation, or SF's recent recall election over the creation of a new public park in place of a redundant street)

Yep! Market rate for private parking, and offering subsidized short-term commercial parking (which generally has broader societal benefit than private parking) with appropriate safeguards for abuse would be great!

In commercial loading zones! We've allocated the color yellow for this in SF.

If commercial drivers petitioned SFMTA to convert more private parking spaces into commercial zones I'd be signing petitions and backing them in their goal 100% of the way.

But generally I've found that commercial drivers would rather just violate the law and endanger others rather than engaging in activism for better infrastructure on our streets, so it's hard to feel sorry for them if they're cited and fined as a result.

Yeah, they ignore SF311 reports by policy. I've managed it by flagging down an amazingly helpful parking control officer that happened to be in the area, or else by calling and reporting an obstruction of traffic (not mentioning the bike lane) and then waiting until the PCO arrived and talking to them.

The officers have almost always been helpful, but I think they generally tend towards lower confrontation and more "efficient" violations like street sweeping or expired meters by default (or perhaps directed by management).

It caused him problems because he didn't think the law applied to him, and got charged a lot of fines due to those violations.

Incurring higher costs than revenue is a common cause of business failures.

Is it ridiculous to ticket someone who parks in the middle of Market St if there's no sign that it's illegal?

No. Driving a car is a privilege, and a dangerous one at that, which requires a competency test. It is not unreasonable to expect licensed drivers to know the statewide laws that govern that privilege without reminder signs.

Your last point is one of the most frustrating things with unprotected bike lanes - drivers will endanger bicyclists for no real gain when they park in the bike lane because the car lane is also still blocked! Somehow they prefer to block 2 active travel lanes instead of just one.

Generally to keep streets safe to drive on, and pleasant to live near.

In particular, SF receives very little rainfall for most of the year, which means that leaves and debris easily accumulate rather than being washed away at regular intervals.

Drivers also have a tendency to leave parts of their vehicles - like broken glass and plastic/metal shards - behind when they routinely crash into each other, which accumulate on the street. Without regular sweeping, those can pose hazards to other drivers and bicyclists, and risk being washed into the bay via storm drains if not swept.

Agreed, and it provides important revenue for transportation projects and helps keep our streets clean so I wouldn't want SFMTA to adjust that focus as-is.

I just wish we had proper (read: higher, accounting for real negative externalities and likelihood of citation) fines for other violations that pose active public safety concerns such that SFMTA would be incentivized to also focus on those and not just the "easy" ones. It would also disincentivize antisocial behavior by repeat offenders.

The DMV is unfortunately wrong about this, with an invalid interpretation of CVC - the DMV handbook is NOT the law (it's a simplistic layman's interpretation), and is not a valid legal defense.

That said, in SF proper it's absolutely inarguably illegal as a violation called "Obstructing traffic" in the SF transportation code. A bike lane is an active travel lane for vehicles as defined under the CVC (including bicycles), and therefore stopping in one is illegal just like stopping in a car lane. I've had drivers cited for this in the past.

Incredible work. I'm disappointed to see so many of the leaderboard items are street cleaning tickets.

I get it - street cleaning are "easy" tickets to write in bulk, and therefore efficient ROI for PCO time, but they're not the most important violations to cite compared to safety-critical things like blocked bike lanes (which SFMTA has an official policy to completely ignore citizen reports thereof), double-parking, or red zone (including daylighting) violations.

Part of the issue is improper fine structure (though I think this is at least partly controlled by the state?) - tickets for blocking a bike lane are rarely written and therefore it's a good bet to just do it and odds are in aggregate it's cheaper than paying for parking legally.

UPS, FedEx, Amazon, Uber etc rely on this as a cheap cost of doing business, externalizing their costs onto the safety of the public. SFMTA even offers bulk payment discounts to UPS, when they should be charging escalating fines for repeat offenders.

The sad thing is I think Google keeping Chrome is actually likely the better of two possible bad outcomes... Anyone else interested and willing to pay the true value of owning the entire Internet ecosystem is almost certainly going to look to extract value from that, and that's almost certainly worse than what Google does today. E.g. using everyone's browser to extract training data for AI without getting IP blocked.

This is entirely unsurprising. It's been clear that Google has been into their Android duopoly-abusive stage for a while now, with more and more of their Android changes moving into GMS or non-AOSP Google apps (like camera, messages, location services, etc) over the last decade. Graphene has been doomed to this fate for a long time, and anyone who thought otherwise was naively optimistic.

The same is clearly coming for Chromium forks, which is why I've always thought the privacy and ad-blocking forks are a joke - if they ever gain enough marketshare, or if google just tires of the public open source charade, they have no chance of maintaining a modern browser on their own.

This is all the more likely now that Google has been emboldened by not having to sell off Chrome for anticompetitive reasons.

This used to be true but was adjusted with a correction to the internation postage rates. These days things like AliExpress have stopped using local postal delivery and instead use their own local logistics partners for last mile delivery, and it's surprisingly still just about as cheap.

I'm guessing these last mile deliveries are gig workers, considering I seem to get deliveries from people in unmarked personal vehicles nowadays.

The US is already far behind the economies of scale of Chinese production, and has higher labor costs and higher regulatory costs (both good and bad), so it's fundamentally not possible to compete on price alone, regardless of any postal treaty issues, which, again, are not a huge factor these days.

The new logistics services have been pretty interesting, and don't bode well for UPS/FedEx who have been content to focus only on large packages and charge ridiculous fees for a long time without innovating.

Absolutist stances like this generally lead to undesirable outcomes as technology advances and changes the scale-per-dollar practical limitations of surveillance, which is exactly my point around our need to adjust how absolutely we consider the lack of privacy expectations in public.

The absolutist "no public privacy" stance suggests that I would be ok (legally and morally) to create a widespread camera system that tracks cellphone screens in public and automatically records any passwords that are being entered within view of the cameras and sends them to me. This is ok because, in the absolutist view, your screen and finger movements were visible in public. This feels pretty wrong to me.

It's the difference between targeted surveillance and dragnet surveillance. Technology has made things that were previously only possible through targeted surveillance to be cheaply achieved through dragnet means, both to governments and individual citizens.