regularfry

"A tad messy" really undersells it. You need a solid process to manage the (sticky, carcinogenic, smelly) liquid resin both as an input and waste product, along with having to dispose of (carcinogenic, smelly, flammable) cleaning solvent.

The problem isn't so much the process of a successful print as how you deal with a failed one. At that point you've got a vat full of resin with some solid parts stuck to the bottom, so you need to filter and clean the damn thing which means taking it out of whatever containment you've got. And that step you can't use the usual solvent for because it damages the sheet. But you'll have ample time to figure all this out because you'll get loads of failed prints as you figure out how slicing and supporting for resin works: it's different to FDM, some knowledge carries over but not that much.

Focusing on the 10-30 minute curing process ignores the part prep step: SLA is much more reliant on supports than FDM in general, so there will be either rough surfaces hopefully out of sight, or (if it's not a model that orients well) scraping/sanding/filling. And you want to do support separation and get that as clean as possible before curing, while the resin is still a bit soft, but that means it's only partially cured and you need to be PPE'd up.

When I'm doing anything with my resin printer I don't even go into the room without a breathing filter, don't touch anything without gloves. It really is a very different experience to FDM.

Not the GP but the experience of being on the wrong end of a vociferous false positive is not great, and there are enough readers to make that not an unlikely outcome.

A trace is basically a sequence of states. If you're using TLA+ or something built on it (quint in my case) then you can get it to dump out valid sequences that you can then compare to output produced by your implementation. You have to explicitly instrument where the implementation performs the updates, so it's not free and there's potential for error there, but it clearly signals "this bit of code is responsible for that bit of the model".

I'll probably get a kiosk panel next time. But this time, yeah, I've just not configured the network. All content comes from the console. Which is a different bundle of problems and no better in a lot of ways, but it's more of a known quantity.

Positive note from me: one thing I've had good experience with is following the path from a project that does something similar to what I want; extract a tech-neutral prose spec from the source; convert that prose spec into a formal spec; use that spec to generate valid traces, a language-specific interface layer, and conformance checks to test whether an implementation of the interface generates good traces. Once you've got that, implementing the system is a matter of colouring the interface in by numbers, which is really easy for a model.

The bonus here is that you can cut in at the prose spec stage and change it to whatever you need, as well as being able to target it at specific technical choices at the last couple of steps.

Where I've seen this work really well is with privilege escalation management, where you do actually want to be careful about the states the system can get into, and the APIs available for managing privileges in a system might be super specific to that system. But I can imagine the workflow being quite a useful one any time you've got anything state-machine flavoured.

The point is that even if we did get to net zero today heating would continue to rise for another 15 years. That's what the lag is. Whenever we get there, add 15 years.

Depends on the parameters of "acceptable", but they do offer inference in non-US zones. If the company is already on AWS for meaningful workloads with sensitive data (which is not uncommon), they've already been through the hard part.

That being said it's not quite as simple as would be ideal, you do need to check whether there's an additional EULA on your specific model choice.

The other choice is AWS Bedrock, if it happens to have the model you're interested in. They do have GLM-5.3. They don't have DS-4 or 4.1 yet, and updates are intermittent at best, but they're already on the trusted provider list for anywhere large enough to be interesting.

> It's like comparing DigitalOcean with AWS.

As someone who has to professionally deal with AWS's feature breadth, this does not hit the way you expect.

That's pushing the timelines a bit. I had more than one early Ubuntu completely hose itself on dist-upgrade pre 16.04, despite it being based on Debian for which such things have never been a problem for me. Until 22.04->24.04 my rule was always to reinstall as a result.

I can also respect the mastery that results in every keg of Heineken being functionally identical. I don't have to like the stuff. Or, heaven forbid, drink it.

The trap is the ratchet towards attested hardware and closed-source-only implementations.

Arguably the customer gains the option of not paying, which has some value. Whether that option value is close to the extra they pay through the subscription is left as an exercise for the reader.

I can't justify this at all, but it feels like there's headroom in the currently-available hardware, which the current shortage will increasingly force us to optimise into. Then when the choke-point relaxes the upper bound of what's achievable will be even higher than it would have been.

us-east-1 is all you need, surely.