regularfry

Slightly difficult to disentangle is that they might be using the verbalisation as a way to explore depth, rubber-duck style, in a way that they wouldn't over the board.

Well yes, but you're still talking ~5 years versus 40. If the desire is for the state to step in somehow and smooth the transition (which it is, in a "UBI maybe?" discussion) then that's still providing an additional 700% training capacity. I don't think we've got a good example from history of that working in a way that lends itself to "Keep calm. Carry on." Certainly not outside military build-ups or post-war reconstruction.

Efficiency and resilience are always in trade-off. Even if there was no other argument it would be worth having local inference as a guard against systemic SPOFs in the big providers.

> I disagree. They had to attend class and pass a test to get a CDL. They were trained to drive a truck, they can be trained to perform another task. Truck drivers are not lobotomized.

I don't think the difficulty is with the drivers, more with the logistics of retraining them all at once. As a cohort they came up through their class and training nicely spread out over, what, a 40 year period? Making sure there are that many training spaces for other trades over a much more condensed period is non-trivial.

"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.

Push-to-talk?

It's more literal than that. The prospect of reward is very literally not motivating. It does not provide motive force. It does not make us move.

We consciously want the thing, but that isn't enough for executive function to kick in, so "I need to get off the sofa so I can make tasty dinner" results in not having moved two hours later.

As long as that company doesn't expect me to continue in their employment if I stop enjoying it, then we understand each other.

Total compensation includes fun.

We have people who want to fill those positions because there are enough people who find it rewarding enough. Take away reasons why they would find it rewarding and you will have fewer theories and results that will advance our civilisation.

And yes, fun counts. Nobody said this had to be only a hardship.

SBCL can produce very fast code. It's really slept on from that point of view.

A couple of years back there was a paper doing the rounds about software execution efficiency, which a lot of people in my neck of the woods got interested by because of the potential for environmental impact at the sort of scale we operate at. SBCL ranked disturbingly highly for something that is culturally never going to happen for us.

I got downvoted to oblivion on a reddit thread where someone was asking how they could handle the massive context that an agent needed to load to understand their codebase when I suggested that exactly the same techniques which let humans manage it would work on an LLM.

Models aren't good at this by default, so you end up with spaghetti mess. But if you tell them that you want strong interfaces, isolation, and types, they can work that way.

Yeah, I've got a 10 Pro, jumped up from an 8. Looked briefly at upgrading to the 11 but it's clearly not worth it.

> What evidence do we have that code review is good for spotting bugs?

There are papers that show positive results for Fagan inspection (1976 onwards) and I'd put good money on there being a straight line between IBM having good results with that method and more recent devs believing that code review is good for finding bugs, despite the loss of a formal structure.

> we think that code review is good for spotting bugs but what it's actually good for is knowledge sharing.

It can be both! I'm not sure it is, but there's nothing contradictory in that.

> Ask engineers why they review code, and most will say they do it to find bugs. In 2013, Alberto Bacchelli and Christian Bird studied code review at Microsoft and classified 570 review comments. 44% of developers ranked finding defects as their top reason for reviewing. Only 14% of the actual comments were about defects. Five years later, Caitlin Sadowski and her colleagues looked at nine million reviewed changes at Google and reached the same conclusion.

Proportion of comments tells you nothing about whether it's a good technique for finding bugs. It just tells you what the spread of comments is across the different purposes for which the channel is being used.

There was a music editor I remember getting on a late Your Sinclair edition cover tape which displayed proper music staves and gave you 4-note chord output. Blew my mind a bit at the time.

Just going to nitpick on one thing:

> "Can you review this" [link to PR] is getting a rubber stamp because humans have never been good enough at "just spotting bugs" to make this worth it and now any LLM is better than a human.

Spotting bugs is the one thing we do have evidence that code inspection is good for. But there's a massive difference between the type of code review there's good evidence for and a github-style PR review, so it's mixed but not entirely without foundation.

That's fine if the interaction with the service is within the scope of your code. If you want to, say, mock out terraforming a bunch of IAM permissions to least-privilege a lambda such that you can check it actually works, you don't have a seam where any app-level tests can go in.

That's where the difficulty is, where the round trip to testing this stuff on live services is painfully slow and error feedback is mixed at best.