krschultz

In my experience as a VT homeowner we have relatively frequent short outages. It's pretty rural and the weather is brutal. I think the grid doesn't have as much redundancy as denser areas. We had one 3 day outage 2 years ago in the middle of winter which got quite dangerous, but otherwise I haven't had anything more than a few hours.

Also we have propane heat - but I need electricity for the blower and control board. So the electric consumption is pretty minimal, but it is critical.

I tried to signup for this program but the building code gets in the way. You need 3' from both edges of the battery to a window or door. I don't have a wall with 8-9' between windows. The alternative is to build a fire proof room in your house which takes up a lot of space. Ultimately it was not worth it even with all the financial incentives. The rules might seem innocuous but they're a dealbreaker. It's far easier to get a propane or diesel generator installed.

You don't make breaking changes. You provide the new API and the old API at the same time, and absorb the additional complexity as the library owner. Best case scenario everyone migrates to the new API and eventually remove the old one. This sounds onerous, but keep in mind at a certain scale there is no one commit in production at any given time. You could never roll out an atomic breaking change anyway, so going through this process is a reflection of the actual complexity involved.

Because they make more money using their servers for their own products than they would renting them to other people. Meta has an operating margin of 41% AFTER they burn a ton on Reality Labs, while AWS has a 21% margin with more disciplined spending. Social media is a more profitable business than infrastructure.

That's not universally true. The sewer system in my town was overbuilt in anticipation of a development that fell through. That's why sewer / water bonds are typically up for vote separately from property taxes because there's such an interplay with development.

Huh? You have to pay property taxes now and those could end up being too high for subsequent generations to afford. That happens all the time and is a common reason why property gets subdivided. This is simply a question of whether the value of structures on that land should be included.

If anything a pure land value tax should be more predictable than a property tax, I got hit with a major property tax increase and looked into it, the town had calculated the new property tax based on an incorrect square footage and number of bedrooms for my house. After filing an appeal and going to court I got it fixed, but that was a more capricious process than if it was simply based on the value of the land under the house.

Threads is already GDPR compliant, that's not the only regulation the EU has made that covers these kinds of apps.

I would heavily consider this type of system once build times become a major pain point. That often happens somewhere around 20-50 people working in one codebase. So I think this is a problem space for medium sized companies. Truly small companies probably don't need this and should use the standard ecosystem tools, BUT if your team knows how to use it there's little downside in started from a Buck / Bazel. Especially since you get most of the benefit if you have a nice clean DAG of your modules, and that's easy to build at the beginning and hard to refactor into later.

IMO one of the nice things about Buck or Bazel is that once you learn it, switching languages doesn't require you to learn a completely new tool. Obviously the cost of learning it the first time is high and if you are used to one ecosystem may not be worth it. But I'm now on my 3rd different ecosystem that uses Buck/Bazel (Android, iOS, C++) and it's nice to not worry at all about the underlying tools.

It's honestly hard to measure at the scale of Meta. Just making everything compatible with Bazel would be a non-trivial undertaking.

Also that seems an interesting thing an independent person could write about, but whatever claims Meta made on a topic like that would be heavily scrutinized. Benchmarking is notoriously hard to get right and always involves compromises. It's probably not worth making a claim vis a vis a "competitor" and triggering backlash. If it's significantly faster than Bazel that will get figured out eventually. If not the tool really is aimed at Buck1 users upgrading to Buck2 so that is the relevant comparison.

At the time that FB started writing Buck, Bazel was not open source. I believe it did exist as Blaze internally at Google before FB started writing Buck. Facebook open sourced Buck before Google open sourced Blaze as Bazel.

Over time Facebook has been working to align Buck with Bazel, e.g. the conversion to Starlark syntax so tools such as Buildozer work on both systems. I believe Buck2 also now uses the same remote execution APIs as Bazel, but don't quote me on that.

There are fewer forced sellers now that remote work is more common.

I don't think they balked, they failed.