rkangel

I think they have gone for turboprop for a few reasons:

There's an economy of scale with turbofans to some degree. Large high bypass turbofans are extremely efficient, particularly at their cruising mode.

Smaller regional aircraft have more of their fuel consumption dominated by takeoff - the cruising altitude portion of the flight is smaller in proportion.

When doing something experimental, do it on something small to start with. Then scale up when you've got it working.

I believe that they're safe, but I don't understand how.

My circuit breaker is specced to be a bit lower than the capability of the downstream wiring. For the sake of argument let's say that the breaker is 16A and the circuit wiring is good for 20A.

Now the panel injects 8A into the circuit and suddenly I can pull 24A (16 from the circuit plus 8 from the panel), but that's through wiring that's only rated for 20A.

Does it rely on the fact that the actual amount of current from the panel is small (but continuous) and so we're likely to not push anything over the line?

I think two reasons:

Character and history - they tend to be more individual and different, and have more character than the cookie cutter modern mass builds.

Solidity - they tend to be more stone and brick, instead of the timber framed buildings that are more common in new builds.

In my area of the UK at least, the house layouts of houses built last year aren't appreciably different from those built 200 years ago. That's specifically comparing detached and semi-detached houses. Terraces are a bit different now.

> then use wood and plasterboard for room walls and floor

One of the things I LIKE about older houses is that the interior walls are more solid than plasterboard. There is zero plasterboard in my house and brick gives far better noise insulation than anything timber framed.

There are some downsides, but most people on the UK would prefer houses that were 100+ years old. In the village I live in the houses immediately around me are "only" 50 years old. Most of the ones on the main street are well over 100 years old.

Housing tastes don't really change that much. Yes over the years we've had to fit things like double glazing and better insulation but that's a whole lot cheaper (and better for the environment) than building a whole new building.

A broader view of this point would be "the economic structures in some countries do not allow for investments with a long payback".

In general, in the UK, labour costs dominate. How do people not understand that?!

This is what's interesting with AI pricing at the moment - it has gone from "a fraction of the equivalent labour cost" and so people have tried to cut staff, and is moving to "on par with labour cost" and all the calculations change.

The Erlang thing is different though - that's a userspace scheduler, scheduling userspace tasks onto one-thread-per-core. Classic M:N scheduling in a similar way to go.

It works extremely well at scale - you can handle 10k connections on a normal machine with very little thought, and WhatsApp has reported handling 1 million. Yes everything has some point at which it won't scale, and apparently that approach (or at least that implementation) struggles at 100 cores. That's not a normal machine.

> has become highly stigmatized in society

When making claims like this, please remember that this is a very international group of people and scope your point appropriately: "has become highly stigmatized in the US"

This is not a problem in large parts of Europe (can't comment about elsewhere). The reason this scoping is important is because the solutions are different for "this is a problem in all of society" compared to "this is a problem in the US".

I don't think it's too bad, but I also don't think it's good.

I also don't think Andrew can claim at the end "I actually don't have any personal criticisms of Jarred" when the post includes the sentence "Jarred was already writing slop well before he had access to LLMs".

The big thing for me is that the lifetime of a car is a lot longer than the technology development lifecycle.

I just bought a 10 year old Toyota estate (station wagon). It's got a reasonable screen and Bluetooth implementation etc. But I'm never going to want to use the built in navigation because it's just not as good as what my phone will do. And the audio integration isn't as sophisticated as it might be - I have to choose the app on my phone.

Whereas CarPlay/AndroidAuto is generic from the car point of view, and as phone features and software improve your car capability evolves too.

The Android Auto experience is very smooth and fundamentally exactly the same.

I worked in a US office for a while (but with a few other British people as well). I didn't feel the need to edit my sense of humour luckily, but I purposefully switched to saying things like "sidewalk", "elevator" and "bathroom" because it made interactions a lot easier.

I believe it's the ISO standard because it is obviously distinguishable from both the MM-DD-YY (US) date order and the DD-MM-YY (UK/EU/Others) date order and so is unambiguous.

https://www.iso.org/iso-8601-date-and-time-format.html

The fact that they are then sortable is a nice side benefit!

Claude Code personal or Team: you pay a flat fee

Claude Code Enterprise: you pay per token

Keeps saying "no websocket required" like it's a good thing. The JS client (https://github.com/anzellai/sky/blob/main/docs/design/sky-li...) seems to rely on long polling.

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

IIRC for Enterprise, using /feedback or /bug is an exception to the "we promise not to use your data" agreement.

Not all of the functionality is in the firmware though. You can put stuff in the silicon itself that allows backdoors.

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.

It's a whole lot easier to store the keys in a special hardened location than it is to store your whole storage.

It is VERY different. One company now has complete control of the activities of the team developing these tools. Contributing to Python (money or time) gets you some influence, but doesn't allow you to dictate anything - there's still a team making the decisions.

I'm amazed no-one has used the term "Regulatory Drawbridge". It's a classic thing that happens in a number of industries - the big players push for more and more regulation. It costs them money and time, but it makes a massive barrier for new incumbents who don't have the cashflow and manpower to work through the regulatory process.

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

> Assuming that we're talking about a unit test here

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're describing is the every day reality but what you WANT is that if your implementation has a race condition, then you want a test that 100% of the time detects that there is a race condition (rather than 1% of the time).

Your logic is circular though. You are saying that there won't be much speedup for the sort of things people already do in WASM - but the reason they're doing them in WASM is because they're not slowed down too much.

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.

If I missed with tone, that's on me. I was going for "helpful constructive feedback".

Are you aware that your Github README doesn't actually tell us anything about Roc is or why we might be interested?

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.

The tolerance for interference fit ("clutch power" in Lego terminology) is important, but that's fairly simple. It's the cumulative tolerance when you assemble large structures that's important. Knockoff bricks can be fine for the first few you assemble, and then as the structure gets larger things don't quite fit together.

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

I agree, it doesn't say a lot. It also very confidently specifies a series of tolerances with no citations.

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

> the push towards smartphone-dependent toys feels weird

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.

> That’s modern people with access to antibiotics etc.

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.