gregable

Jobs like archeology could probably also be automated further. Somewhat limiting this is possibly the fact that the "market size" for automation here is small.

In a similar bucket is the Aptera I'd say, but also more expensive.

This assumes supply is perfectly inelastic. Even assuming, it also ignores the fact that the money is only dumped in one nation.

This really only applies to POW coins, not so much stablecoins

I suspect it's backed by loans to bitfinex.

Basically tether mints a bunch of USDT, 'loans' it to bitfinex which then creates an asset on tether's balance sheet of the loan. Bitfinex then goes and buys BTC with the USDT raising the price of BTC.

The problem here is that there is no actual USD anywhere in this system. Net, the system is just one where tether is getting minted out of thin air and then sold to the public for BTC or whatever coins.

1. The author points out that txn fees are tiny, 1% of the revenue. And they are unlikely to be significant during the depreciation period of the machines.

2/3. Sure, but see #1.

4. Sure, but the author is pointing out that the cost of buying BTC exposure via these companies is higher than just buying BTC by a lot. It almost seems like a short position of these companies combined with a long position on BTC is a solid bet over a long term horizon.

Yes, but. There are few places that need heating 100% of the year and fewer people living there. During the non-heating hours/days, that's just waste heat.

Depending on where the bulbs are located, they may be emitting into a ceiling cavity that exits the building's envelope more quickly than the location of the heating coil. Some bulbs are actually outside the building.

And of course, the heating system can supply 0.5kW for less than 0.5kW of power with heat pumps or (net including generation and transmission) natural gas.

That was once true but it's no longer a real issue: https://youtu.be/GiYO1TObNz8

I've been looking at the Toronto real estate prices a bit, and I'm convinced the real issue is primarily interest rates, not immigration, or construction. Don't take my word for it, ofc:

Immigration:

- Rent has not increased like real estate: https://www.zumper.com/rent-research/toronto-on

- In 2020, immigration dropped by half to 184,500. Real Estate prices went up. https://www.canada.ca/en/immigration-refugees-citizenship/ne...

Construction constraints:

- This is probably hyper-local, but in Toronto for example, they are building over 1 new housing start per year for every 100 residents (https://ycharts.com/indicators/toronto_on_housing_starts). That's not bad, it's not the CA Bay Area's situation.

- Anyone in Toronto can tell you there is a lot of home building going on with construction everywhere.

Canadian mortgages don't have the typical 30-year fixed rate that a lot of US mortgages do. Instead, typical mortgages reset every 5 years, and in fact many are month-to-month variable rates. In fact, the percentage of new mortgages originating as these variable rates in Canada has been rising and recently broke 50%. The majority of homes are now financed using a month-to-month variable rate which is set to some profit above Bank of Canada prime rate.

Until March, it was possible to get a mortgage with a 1% or even lower interest rate in Canada. Take a look at the average: https://www.ratehub.ca/5-year-variable-mortgage-rate-history

In Mar 2020, Canada dropped the short term bond rate from 1.75% to 0.25% overnight. In 2008, they did something similar from 4% down to nearly zero, and had only just started raising them back towards 1.75% right before Covid. Only in March 2022 did we see the first rate hike and it was very mild.

Canada Real estate is basically a bubble driven by aggressively low interest rates. The problem now is that inflation is causing the interest rates to rise, and that could pop this bubble, so we might be seeing some of these laws designed to shift the blame.

More sources:

- https://en.m.wikipedia.org/wiki/Canadian_property_bubble

- https://www.bloomberg.com/news/articles/2021-06-15/world-s-m...

- https://betterdwelling.com/the-toronto-real-estate-bubble-no...

- https://seekingalpha.com/article/4477223-canadian-housing-ma...

- https://financialpost.com/executive/executive-summary/postha...

Folks here lean Bay Area, but I don't think Canada has the same issue of preventing construction.

For example, in Toronto, you get about 30-40k new housing starts a year in a city of 3M. https://ycharts.com/indicators/toronto_on_housing_starts. >1% / year isn't terrible.

Your statement isn't wrong, but I don't know how much it applies to Canada Real Estate particularly.

The demand for the housing drives the price, modulo short-term speculation. The investor buys it with an eye towards the cash-flow from renting, and by definition, it's rented to someone living there.

Not doing something about it eventually ruins the community and then takes the life savings away in an even more dramatic crash.

Canadian Real Estate is pretty clearly in bubble territory. Something can happen now or later, but it only gets worse with time.

I'm not sure why "amount over reserve / list" is a meaningful metric. It's clear that in a lot of cases the list prices are intentionally below market to attract more bidders and produce the appearance of more competition at open houses and the like.

It's a very manipulated and manipulable metric.

Electricity Demand Response / Micro Grids. Right now, most electrical systems, even internet connected ones, don't have any awareness of electrical supply and demand. Most of the grid is designed for power to flow one direction.

As we bring more intermittent power supplies onto the grid, things get harder. The batteries in electric cars are a small, but growing storage capacity that currently can't flow "backwards". Hardware will be a large part of this, but software will be needed too.

Yes, and this would really be awful in the short term, but in the medium term medicine companies would just spin up more production until the "very wealthy people" demand has been met and medicine becomes available again at some reasonable price.

The fact that this is very likely prevents most of the speculation in the first place.

The difference with real estate is that the owners get to determine production levels, via local zoning laws.

Sure, there is some natural scarcity: Land cannot be created, but in most cases artificial scarcity is the issue.

Eventually, but at current prices existing hardware mines at well above electricity prices, so that won't happen any time soon.

There is no "displacing" going on. The amount of hashing going on is independent of the amount of BTC mined or transactions verified per unit time.

Until such time that the hashrate rises to the point that BTC mining costs more than the power to run the same miners, nobody will be turning off the machines. Unfortunately that hasn't happened and won't for years ( barring BTC price drops).

I used https://pypi.org/project/appdaemon-testing/. You can write a simple test file which does things like sets a device state, then asserts that services were called or whatnot.

It doesn't test that the service calls are correctly written, just that they were made. So, very useful for unit testing syntax / logic, but not a full end-to-end integration test solution. Still, with python being an interpreted language, this is super useful. I don't want to have to wait for it actually to be sunset to determine I have a syntax error in that branch of the code, for example.

I don't actually have the tests running on the HA device. I have them on my desktop where I develop the appdaemon scripts, and then I copy only the scripts over to HA. I'm sure there are multiple ways to do it.

For folks here I strongly recommend installing the appdaemon integration and just writing python scripts. The downside is there is a good bit of learning curve and time investment just to get the hello world going (turn on a light at sunset?).

Once you are there, you can write shared libraries, abstract away whatever you want, have legit tests, and just do anything you would normally want in your coding environment (vscode, auto-formatters, source control, etc). Obviously not the right recommendation for a consumer system, but if you are like me and feel more comfortable with a programming language, it's the way to go.

It depends on your definition of efficiency. Electric heat is considered 100% efficient as 100% of the watt hours that go into the device eventually get turned into the same amount of heat.

A heat pump moves heat from outdoors to indoors. The outdoor heat lost is ignored in the efficiency calculation (as it should be), and thus the efficiency question is how many watt hours of electricity does it take to move a watt hour of heat (joules) from outside to inside. Depending on the temperatures involved, it's usually a multiple, for example, 1 wH of electricity moves 4 wH equivalent of heat indoors, ie: 400% efficient.

If you consider the whole system, much of the electricity for a heat pump may come from burning natural gas elsewhere, which involves losses along the way. This is still usually better than 100% overall efficiency.

Direct natural gas heating is less than 100% efficient too. Most furnace systems are about 20% loss in exhaust, though they can be much better. This is still usually better than burning the gas at a plant, converting to electricity and then heating with resistive electrical in your home.

The issue with this is that in the limit it just makes the insurance premium exactly equal the payout + some margin. Some of the point of insurance is cost sharing of extreme events.

It's perhaps a little better when we are talking about behaviors that are entirely under the driver's control, but gets potentially ugly if for example someone has slower reaction time due to genetics or health and thus gets priced out of insurance.

Does this mean that Netflix has to have a private TLS key in the box? I wonder how the security of these keys is usually maintained. Interesting engineering/cryptography problem.

This problem might also be an interesting use case for Signed HTTP Exchanges. Sign the video files, then push them to the caching server. The caching server then never possesses the private keys for the connection and also cannot modify the content.

True for the C from food, but the production process is energy intensive. Fertilizer production, tractors, etc all burn oil C which would otherwise have been left in the ground.

I'll be honest, it seems reasonable to me in a lot of cases. I'm not enamored with steak, and chicken/pork can work just as well as beef for a lot of other dishes. A chicken sandwich is just as good as a burger to me.

I know there are people where that doesn't work, but there may be many where it does too with minimal nudging.

Ive just gotten started, but what I like so far is based on node-red but only using HA triggers, functions, and HA call service nodes.

Essentially I use the trigger blocks to schedule my function calls. The function then ignores the inputs entirely and just inspects the variables from home assistant that it cares about, it then sends this output to any devices I want to toggle.

This way, I'm just writing code. This works naturally for me, since it's my day job. But I can use node-red for visually organizing input output tuples, and the debugging data that it shows as things activate.

I also add one manual trigger and one debug output node on each end of the function so I can just run it manually if desired.

So far it's pretty goos, but I'm missing stuff like writing tests, which means I test my functions by turning on/off devices or something which isn't ideal.

It's in a weird space. It's kinda a pure electric.

My memory (might be incorrect) is that both Twitter and LinkedIn use the Google cache directly, rather than running their own.

I did some hacky analysis and roughly half of the PRs originated in GitHub and the majority of those are not google employees.

Most changes have a github issue attached with discussion, all of the changes have descriptive commit messages regardless of who authored them and there is significant effort to document the decisions and decision process throughout.

I can't speak for the release frequency for other organizations' production that consumes this code. That includes many publishers, as well as other AMP caches such as Bing and webmail clients like Yahoo.

The repo is for all of AMP, not just the validator. The validator related issues are handled by the "caching" working group (since caches are the consumer of the validator) and you can search for them with this query: https://github.com/ampproject/amphtml/issues?q=is%3Aissue+is...

I won't try to address every part of this writing, but there is one claim that I feel is false: namely that the AMP validation rules are not open source.

Here is the code: https://github.com/ampproject/amphtml/tree/main/validator

All of the rules are written in human-readable config language. Here are the rules for common HTML elements (https://github.com/ampproject/amphtml/blob/main/validator/va...) and there are rules per-amp-tag (example: https://github.com/ampproject/amphtml/blob/main/extensions/a...)

You can build it, run it locally, etc. There are open-source implementations that run in the browser, in a vscode plugin, on the command line via NPM, etc. Other entities can and do use the same code for their validation of AMP. Pull Requests are accepted from anyone and those changes land in Google production and all of the aforementioned tooling targets within a few days. There is documentation on how to contribute to and edit these files (https://github.com/ampproject/amphtml/blob/main/docs/compone...).

That's a common response. The problem is that it ignores the fact that San Francisco needs those people to fill jobs that need doing. https://nyti.ms/3yuq3nX

The common response to that then is then we should just raise the pay in an area until every job pays enough to afford to live there, or if not those jobs are clearly not important enough. The problem is that the number of these jobs is growing faster than housing stock. Market forces can't solve the problem of more jobs than homes unless you can build homes or destroy jobs. Take a look at https://bit.ly/36ySeFS - Santa Clara County added 300,000 jobs between 2010 and 2020 while building around 6,000 homes per year (5 jobs per home).

SF is the same story: total housing units in San Francisco increased by about 23,000 from 2010 to 2018 (https://commissions.sfplanning.org/cpcpackets/1996.0013CWP_2..., slide 6). Total employment in San Francisco during the same period grew by almost 300,000.

Seattle: total housing units in Seattle from 2010 to 2019 grew by about 59,000 homes (https://www.seattle.gov/opcd/population-and-demographics/abo...). Total employment (labor force) in Seattle during the same period grew by 243,000 (https://data.bls.gov/timeseries/LAUDV534264400000006?amp%253...)