dperfect

Thanks for the context. That makes sense.

That sounds like two separate things then. Could you not have people select a destination without locking in an elevator?

(I've never encountered destination dispatch myself, so I'm not really sure how it works in practice)

Destination dispatch should be no worse than standard up/down buttons, right (at least in theory)? It provides additional information about the destination, but it should be possible for that information to be interpreted as if it were just an up/down button press, so RSR could still be used. I have a feeling a better algorithm could in fact make destination dispatch slightly better than RSR... or am I missing something?

Of course, user error is also a factor, so this isn't accounting for people not understanding how to use it and making things worse that way.

Overdiagnosis can be a problem. On the flip side, I wonder if adding the time dimension to the data (i.e., you could realistically have scans from every few weeks over the course of years) could significantly change that.

Instead of looking at a single snapshot of a person, you're now looking at trends over time. We probably don't have the analytical tools to effectively evaluate medical imaging with that time dimension at such scale (because I assume it would be rare for someone to get MRIs so frequently), but maybe with more data and study, we'll be able to more definitively distinguish benign quirks from real concerns.

Rather than a human comparing a couple of scans five years apart, you're talking about computationally identifying outlying regions in the data (a motion picture of the entire body) that are trending towards areas of concern.

I love my X1C. It's way ahead of any other 3D printer I've owned or built. I stuck it in a VLAN from day 1. Have had it in LAN-only mode for years. Works great. I haven't followed the company's PR statements, but seems a little strange that they would tell people not to get a Bambu Lab printer for any reason.

I'm sorry your experience has been so terrible or that you thought you were buying an open-ecosystem printer. I never got that impression, so I never expected it.

And in 2026, I wouldn't trust access controls on their own even if Bambu Lab did keep them enabled in this situation (who's to say they don't include a back door of their own?). I prefer security at the network level, enforcing access controls before any untrusted hosts can even see a machine that I want to protect on the network.

It sounds like they're doing what people want. People seem to be ascribing a lot of mal-intent to actions that don't seem malicious to me.

> completely exposes your printer by removing existing access controls

If these printers are in LAN-only mode and you want to point 3rd-party software at them, don't you kind of expect the existing access controls (which are probably at least in part tied to cloud services) to be removed? Behind a LAN with developer mode on, you're generally going to (1) not be exposed to the internet anyway, and (2) probably know what you're doing and would be implementing access controls yourself anyway.

If you want a completely open (hardware and software) 3D printer, don't get a Bambu Lab machine I guess? A big part of the value of their printers is that they've managed to make everything so seamless. Some of that relies on a somewhat closed ecosystem. They're the Apple of 3D printers, but everyone keeps expecting them to be the Linux, just because their slicer (or parts of it anyway) is open-source. If openness is more important to you than those conveniences, go with a different brand. It's a good thing we have choices as consumers :)

> they're deliberately working towards removing any other form of access to our hardware

Maybe I'm mistaken, but I don't think that's what is happening. They aren't doing anything to block OrcaSlicer or any fork from working with the printer using LAN-only mode. It's only if you want to use Bambu Lab's servers for essentially a remote-access solution (which, by the way, kind of defeats the privacy-oriented purpose of running some of these forks) that they're saying you should use their own software.

Thought experiment: the core of macOS (Darwin) is open source. Does that mean everyone running Darwin or a fork of it should be able to use iCloud services for free?

All this outrage essentially sounds like "since Bambu Lab's slicer is open-source, the open-source community should be able to point any slicer at Bambu Lab's servers to get free remote monitoring services". And I don't think that's right.

Bambu Lab has made plenty of mistakes, but I don't think this is one of them. And I'm a big supporter of open-source software.

Their cloud infrastructure obviously has real costs associate with running it, and I don't understand why any software other than their own should be entitled to use those resources.

If you buy something and then significantly modify it, you generally tend to void the warranty - and that's not because companies are just greedy; there are real limitations when it comes to a company's ability to support the endless ways a product could be modified.

Publishing something as open-source does not imply that you must operate an optional-but-complementary service at a loss for charity.

That's true if we're correcting OCR of actual output text. In this case, it's operating on the base 64 text, trying to produce chunks that form valid zlib streams and PDF syntax so the file can be intact enough to be opened. "Just accepting errors" would mean not seeing any content in the file because it cannot be read.

So yes, the "fixed" output has errors, but it’s not hallucinating details like an LLM, nor is it trying to produce output that conforms to any linguistic or stylistic heuristics.

The phrase "correcting similar OCR'd PDFs" should have been "correcting similar OCR'd base 64 representations of PDFs".

It looks like this does make some things easier, but I'm not sure if it's actually better.

From what I can tell, any time you use this to check something like the customer's subscription state (or anything else payment-related) - either from the front end or the back end - it's going to perform an API request to Flowglad's servers. If you care about responsiveness, I'm not sure that's a good idea. Of course, you can cache that state if you need to access it frequently, but then it kind of defeats the purpose of this layer.

Stripe integration can be tricky, but if you don't want to store anything locally, you might as well just hit Stripe's APIs without the middleman. For the payment systems I've worked on, having cached state in the database is actually really nice, even if it's a bit more work. Want to do a complicated query on your customers based on payment/subscription state and a bunch of other criteria? It's just a DB query. With this, I think you'll be hoping they expose an API to query what you need and how you need it. Otherwise, you'll be stuck waiting for a thousand API requests to fetch the state of each of your customers.