Xylakant

The comparison to Berlin is interesting because notably Berlin only has remainders of it Team network due to the east/west split. West Berlin did as Hamburg did and ripped out all tracks, replacing them with buses. East Berlin kept the tram. If you look at today’s public transport network you’ll still see the split.

That’s pretty easy - all major providers have public lists of IP ranges, usually as json files.

The other thing is the squared taper-off of speed when braking and I used to not think about this until someone showed the math. If you're going 30km/h and a kid jumps out 10 meters in front of you, you can just barely come to a stop. If you're going 50 km/h, you'll run them over with 30km/h remaining speed and come to a stop about 10m further down.

No. They are driving unsafely, not you. Even if the speed limit doesn't seem to make sense for you, it may be there for a reason that's not obvious to you. It may also be there for non-safety reasons, such as noise reduction for the people living close by.

This is a very weird argument. How can a car be dangerously slow if all the other cars stick to the speed limit as well? Any danger can only come from a difference in speed. So the danger is actually not the car observing the speed limit, it is the other cars that do not. Notably, any reduction in danger that flows from breaking the speed limit is only for the car and other cars breaking the speed limit, in no case it is for pedestrians, cyclists or other non-vehicle participants in traffic.

Certainly, as long as it’s on the car and there’s enough of it.

It’s really hard to loosen supply side restrictions on “this somehow became a hip neighborhood.” You can in general make more housing available, but not prevent rising prices in specific neighborhoods.

A major problem with property taxes on owner-occupied housing is that the value the owner derives from the house is not dependent on the resale value of the house. An owner occupied house is not primarily a financial investment in most cases. Any increase in housing value (and thus property taxes) is mostly an increase in the cost of living. Any gain in value cannot easily be realized since it’s not a liquid asset. This leads to a fear of being driven out just because the value of the surrounding neighborhood rises doesn’t mean that the owner’s income rises in lockstep.

One way out could be to tax the value gain at the time of sale, or when the house gets rented out, thus no longer being “owner occupied”.

Or pay for a nebula subscription and watch there.

My Ankarsrum Assistent mixer has a detachable power cord with a standard C13 connector.

It seems to be possible, but it’s likely cheaper to have fixed connectors.

> equation because deteting errors

should be

> equation because detecting errors

Thanks for the catch, did the edit.

Quite to the contrary to what you write, many people pushing for Rust explicitly recommend to be very restrictive about touching existing, battle tested code and only rewrite it if you're substantially refactoring it anyways, or if it is a critical exposed piece of functionality - such as media codecs for example, which have a long history of being broken. The winning strategy that for example the google android team pursues is to not rewrite existing code, but write all new code in Rust, because real-world data shows that vulnerabilities in existing code follow a decay curve - most issues are detected in the early life of the code. That's the strategy that Firefox uses, too. (Though I'm curious about how LLMs change that equation because detecting errors in rarely used code path' seems to be what they're doing well)

And indeed, this is very much what Rust was designed to do with the ability to interface with existing C/C++ code in both directions. So this is the strategy that the designers of the language had in mind from the early days. It's a deliberate choice to offer this, and not an emergent property that was later discovered.

In any practical application there'll be a known set of errors and I'm generally fine merging code that has known deficiencies. But personally, I'd not condone merging anything that causes UB. It undermines such a fundamental guarantee of the language that it should be detected and eliminated. And bun certainly rises to the level of software where I'd expect that the project runs all available tooling to detect such cases. Especially if you LLM - code it. "Do not cause UB" should be part of the test harness.

That is not Rusts guarantee. The guarantee is that safe rust cannot in itself introduce UB - UB can only ever be introduced in unsafe blocks, but it can then materialize in safe code.

Indeed. My point is that just using the standard tools in the Rust ecosystem - like miri - would have trivially uncovered this error before it made it to the mainline.