rkangel

>> with CNC and robots we can achieve far superior results for a fraction of the cost.

> This is only true for mass production, where the set-up costs are spread across thousands of units. For small batches, the cost of automation often exceeds the cost of the batch itself. CNC machines are not magic; they require qualified and competent staff.

This isn't right.

CNC machines aren't magic and they do require skilled people to design for them and operate them.

BUT: they are an enormous advance on capability compared to 30 years ago and are absolutely not limited to mass production. 3D CNC milling is how most prototyping of metal parts is done and can be done to extraordinary precision, repeatably. It was always a low volume technology - it was Apple that started applying it in volume as part of mass manufacture.

The problem is that it ISN'T a fee for services as it should be. Their platform power means that they can levy a tax, and they don't feel the need to do anything on exchange for that.

I (as someone British and from an Army family) read that as - "You know you screwed up right? Please reassure me you know that and won't do anything like it again". Followed by an admission that we all screw up sometimes (implied by the stories).

GPDR fines in the EU are NOT trivial.

If you're happy with API billing then just use OpenRouter: https://openrouter.ai/google/gemini-3.8-flash

Makes it easy to switch between models and I like it for exactly the reason that you're saying - I prepay and so can't accidentally spend my food budget.

These companies have displayed zero respect for everyone's intellectual property getting these models trained.

I think not giving them your complete trust is reasonable! I'm not saying zero trust, and ZDR is fine for most things but I understand the people who don't want to stream their whole codebase out token by token.

It is absolutely not worth buying hardware to run models for purely (long term) cost reasons. For open weights models the economies of scale means the cloud beats local significantly and your payback time is like 10 years.

However there are other reasons (e.g. privacy) that might make it worth running locally for some people.

The performance of the recent open weight models is making it harder for the bug players to justify their pricing.

It's the domestic policy version of "commoditise your complement".

Thinkstation PGX maybe?

Got the recommendation from these articles: https://www.xda-developers.com/qwen-3-8-27b-reverse-engineer... https://www.xda-developers.com/lenovo-thinkstation-pgx-revie...

But haven't had a chance to try it myself.

Yeah, and Stripe is "just" a payments platform.

Openrouter is easy, reliable and performant (like Stripe).

Yes this is how jj does it, except that jj is more powerful because it does automatic rebase of all the downstream commits.

If you have any descendants of the gir history split (i.e. it's not the most recent) you'll have to do some more work (a rebase) to get back to a useful history. I think you can do this in the middle of an interactive rebase which is ok, but still not as easy.

Anyone got any thoughts on which Worms I should be buying on Steam?

Worms Armageddon is on there, which is the one I remember from my childhood. Or am I better off with Worms WMD?

There are actually periodic tests for people over 40 in the UK. The GP comment is wrong.

Cynically - this sounds like an opportunity to sell you more medical care.

The NHS isn't perfect, but one of the things it does well because of it's structure is minimise costs holistically. It's cheaper to treat conditions early, so usually implements appropriate screening to catch things. If they don't do regular checkups like this it's because they're of minimal value.

Does the 7 day turnaround hold up for more complex boards (8-12 layers, laser drilled, blind micro-vias etc.)? Not looking for a detailed quote - just a hand waving answer.

I'm in the UK and we have our own electronics assembly but the actual PCBs are made elsewhere. Lead time on a bare board almost seems to be a direct multiple of the number of layers, however much you are willing to pay. Our ability to design and build prototypes has got faster and faster on some projects, but having the board made is the limiting immovable factor.

Yeah, maximum concurrent clients being 50 is nothing and you're already seeing a large gap. That is the whole point of the BEAM - it scales well with concurrent stuff which is important with web in general and very important for LiveView.

But that's the right lever!

That gives the local voting population the ability to decide how much they're willing to put up with data centres. And a state that has excess water and electricity can have tax breaks and then that's where more data centres go.

It is genuinely useful on its own. I have enjoyed discovering the things I want and adding them bit by bit.

I'm doing quite well with just a "todos" extension, and a "plan" prompt template (doesn't enforce read only tool usage, but prompts to build todos and discuss before doing anything).

I will probably try out some subagent systems soon, but I'm doing surprisingly well without them.

I use OpenRouter, currently Kimi K3 which has been extremely effective.

I and my team did a full set of documentation for handing over a codebase to the client. A large complex codebase with accumulated history and subtle reasons why things were done.

Diataxis was fantastic. It took a bit of effort to work out what the page titles were to cover everything we needed, but then when you were writing a page it was glorious.

It was so clear what you were saying and what "voice" you were writing in. If it's a Reference page you're all descriptive, with diagrams and bullet points. When it's a guide you're more discursive, but you know you're just imparting information not trying to teach. It made it so much easier to be coherent and clear about everything.

Had some fun! One suggestion:

Track generation needs a slightly longer bit at the start that is straight, wide and has no obstacles.

The reason for this is the way the touchscreen controls work (exclusively played on phone with touchscreen). They are surprising to at least me, but possibly to a lot of people who have played mobile games. I was expecting it to be like a virtual joystick - wherever you put your finger down is the reference and then you are steering relative to that. The problem I'm having is that it's really hard to put my finger down at the start of the run and not have an immediate swerve of the ball. When you're on narrow track (or effectively narrow track due to an obstacle) like today a large proportion of the time I immediately died before I was in control of my ball.

AFTER that the controls work well and I really like them. They give more precision than a "virtual joystick" would. But I think they need explaining ("ball goes towards finger") and allowance to get in control at the start.

Lots of issues with that:

Communicating from buoy to an underwater sub is hard (ULF antennas are 100s of metres long) and more importantly would give away there was a vessel there somewhere.

Also that would only locate where the buoy is, not the sub and the sub probably needs more precise location than that. They want to be able to manoeuvre around underwater terrain features and things.

Again, this is what we know about the state of the art 20 years ago:

For receiving (very very slowly) there is VLF, as the other comments have said. Can be done underwater. Think 160 character tweets that take minutes to arrive.

One option is to release a buoy that floats to the surface, waits a while and then transmits the payload. This allows the submarine to be out of the area when the transmission happens. This gets you "don't know where the sub is" but doesn't necessarily get you "didn't know there was even a sub there".

Alternatively, the submarine can come to periscope depth - so underwater but able to raise an antenna above the surface (or maybe close to it). Then something sophisticated like direct laser communication to a satellite can happen, allowing for high data rate bidirectional comms. Assuming you aren't detected by coming up, then this SHOULD allow for completely undetectable comms.

Can you provide a citation to this fairly major claim?

Very classified so we only know bits and pieces. "Inertial navigation" is part of it - basically very precise dead reckoning. Using specialist equipment like laser ring gyros to get precise measurements.

Then also some other equipment like a magnetometer and magnetographic maps of the world to provide references to counteract the drift in any inertial navigation.

> First, because it promotes an "us vs them" mindset

I was always intrigued by the maturity about how the Rust team approached this sort of thing. IIRC years ago you and I had a back and forth on me thinking it would be helpful to have a "Why Rust is better than C++" type page.

Seeing an alternative approach from Andrew Kelley in recent weeks has really hammered home the value of the approach the Rust team took in terms of community building.

I think that in addition to the cost you would also have a corrosion problem. That's usually the reason that silver isn't used as an engineering material.

> My intuition is that npm, cargo, zig build etc are all “wrong”. And that Bazel/Buck are architecturally correct.

Arguably yes. The fundamental issue is that Bazel etc. are "hermetic" build systems - every build step they run is in a sandbox with only the inputs (source files and tools) that you have explicitly specified - nothing implicit everything explicit. And relies on the output you get from those inputs being the same every time.

This gives a wonderful property of knowing exactly which steps need performing and being able to cache everything - your whole build DAG is a merkle tree.

The downside is that many build steps do not fit into that mould - they make arbitrary network calls, or want to be able to access corners of your filesystem, or produce slightly different outputs each time due to multithreading etc. So you need to work around this in some way to make the larger system work.

(FYI, this is exactly the same as the Nix and Guix build systems except that for them the granularity of a step is "build one package" rather than "build one C file")

I'm not saying that people should talk about this all the time, but are you saying you don't want people to feel able to mention key details of their personal life?