Claude Code Enterprise: you pay per token

Phoenix LiveView (the inspiration) defaults to using WebSockets because it's much more efficent, but falls back to Long polling if not available.

It's very difficult to inspect a laid out chip for nefarious elements - there's too much of it to do manually. Having a secure supply chain is probably the best way to prevent that happening.

Which is not to say that I support this rule - it sounds like another import weapon trump can swing against people who aren't his friends.

Medicine is the classic example, but it's happening in the tech industry too. The FAANGs of the world took advantage of an unregulated landscape, but now that they're in the castle they're pulling up the drawbridge behind them.

(sidenote - this is why regulation like the Digital Markets Act in the EU should be great. It's only a cost to larger businesses. In practice we're not yet seeing the changes that it should create).

I think the categorisation of tests is sometimes counterproductive and moves the discussion away from what's important: What groups of tests do I need in order to be confident that my code works in the real world?

I want to be confident that my code doesn't have race conditions in it. This isn't easy to do, but it's something I want. If that's the case then your unit test might pass sometimes and fail sometimes, but your CI run should always be red because the race test (however it works) is failing.

This is also hints at a limitation of unit tests, and why we shouldn't be over-reliant on them - often unit tests won't show a race. In my experience, it's two independent modules interacting that causes the race. The same can be true with a memory bug caused by a mismatch in passing of ownership and who should be freeing, or any of the other issues caused by interactions between modules.

What you don't get much is people doing standard SPA DOM manipulation apps in WASM (e.g. the TodoMVC that they benchmarked) because the slowdown is large. By fixing that performance issue you enable new usecases.

This might be on purpose given the first words are "Work in progress" and "not ready for release", but linking as above does lose some value.

Also interesting is that in very large models, there is decoupling between sections. Lego has design rules for how large a well connected chunk of Lego can be, which are driven by the tolerances. Above that you are then loosely coupling those large "chunks".

Lego does indeed have very tight tolerance, but I don't know if the numbers are in the public domain.

I haven't seen this push? The new Lego Smart stuff is explicitly "screen free play". There is an app but it's just for firmware update and configuration and you can't even connect it unless the brick is on the charger.

Antibiotics don't help against viruses like colds. And we live a life that is has a higher degree of social connectivity than our ancestors, allowing for faster spreading of disease, so we're arguably worse off.

The issue is that they can't just close when they want if there's a child still there. So they have to have some way of enforcing these rules on parents. A "per minute" fine seems appropriate, so that it's more the later you are. And you need the fine to be enough that it is punitive enough, when considered against the income of your parents. Otherwise it provides no incentive. Ours is not $300 (more like $30), but it seems fair.

That said, I don't have an issue with using a US authored open source project for this. To use another example - PostgreSQL was originally US, but I don't have any problem with that being part of the deployment of Eurosky.

That said, I would prefer that the Open Source system we were using didn't have a profit making (US) company as principal maintainer. I think AT has some technical advantages over Mastodon, but I prefer the governance of ActivityPub/Mastodon.