The normalised version is what gets redirected to trash, according to GP's proposal. Legitimate senders who do not normalise have their mail delivered to the inbox.
The article does not clarity whether the OP ordered via the app. Only that the menus were accessible via a QR code.
OP either ordered in person after looking at the online menu (no app) or ordered via the app/website but the system bundled together the bill for the whole table despite receiving separate orders (bad implementation).
In the story, even though people used the QR code separately to see the menu, the bill was combined. Either the order itself was done via a human, or the bill was charged against the table rather than the unique user.
When the whole ordering and paying happens as a single event, none of the problems presented in the story occur, other than the initial problem of scanning the QR code.
If closed-source AGI wins, it is not going to be much different from a safety perspective anyway, because AI capability research is advancing faster than safety research.
It looks like it is the number of consecutive days with no incident. If you look at 31 Dec 2025, that corresponds to an 8-day period with no incidents.
What can people do? Systems like these are mandated by companies that provide services that people need, and they are hard to avoid. In-person verification is sometimes an option but not always.
Apple cancelled their deal with YMTC (Chinese RAM company) after the US sanctioned the latter. I don't know whether that is directly because of the sanctions, or indirectly (e.g. if Apple thought sanctions would hamper YMTC's ability to supply the goods), but they have had the same effect.
I am glad someone is putting in this effort. Many years ago, there was another project called GIMPshop to make GIMP's interface more accessible to Photoshop users.
> They also cannot prevent a developer from rehosting AGPL code, but they are trying to do that. And it's kind of the actual issue.
I agree. I think the argument they are going for is similar to that from Google against yt-dl, but unlike in that case, Bambu is obligated to allow this codebase.
Interesting question. In the first case, where you install your own build from unmodified source code, although AGPLv3.0 still allows discontinuing support, I see no explicit carve-out in the licence to restrict network access.
However, the AGPL comes with no right to such network access to begin with. Permission to access the network would usually come separately from the AGPL; I suppose you could potentially bundle it as an additional permission under section 7, but I don't think Bambu is doing that.
To take it a step further, even if you use the latest official software, installed by the vendor (and not by you), they can still refuse you access to their network. That might violate some other agreements or laws (e.g. contract to provide a service), but it does not violate the AGPL itself.
What they cannot do is prevent you from running your modifications on your hardware.
> They have no rights to prevent people modifying and using AGPL software however they want.
AGPL software can be used and modified within the limits of what the AGPL permits. People can do that with their Bambu software running on their own hardware.
That does not extend to using their proprietary BambuNetwork cloud service (somebody else's computer). The AGPL specifically mentions this scenario in section 6. There are open source alternatives to that like the third-party Bambu-Farm and bambuddy that people can self host instead.
Interestingly, Bambu's own initial approach to the AGPL was more in line with "modifying and using AGPL software however they want" (and potentially violating their section 6 obligations), until customer backlash forced them to adhere to the terms of the licence.
You can run modified software per the GPL but that does not include the right to connect to Bambu's servers with your modified software. That is entirely reasonable (especially since this is not some social/messaging application). If I release a client as open source, that doesn't mean it's OK for modified clients to connect to my server. I expect you to use it offline or set up your own server to connect to.
I don't know if that is what is happening here because the article is talking about a fork that is bypassing Bambu's servers entirely (which is permitted under the AGPL) and Bambu is not happy.
Edit: On re-reading, it seems to me the fork is still calling Bambu's servers. It's just bypassing some things.
LinkedIn: joshuaissac
Twitter: Joshua_Issac
Website: joshuaissac.com