Anyone know of something like the ratgdo, but for motorized swing gates (like DoorKing)? I'd love to check the status as well as actuate open/close, but some of the "upgrade" quotes I've seen are $5k USD. It seems like I should be able to get this thing integrated with either WiFi or Z-wave...
RIPE Atlas is an amazing project. I remember getting 3 probes at a NANOG and telling my coworkers about it. They couldn't believe that it was a free project, and that I didn't have to pay anything for the probes. Great stuff from RIPE, for free! (Anchors cost dough but probes were free)
I've yet to make it out of the lab. The failover solutions seem to be A-B rather than A-B-DR. That is, you can have a primary and a replica (probably in the same DC/AZ), but you can't do a primary, a replica, and another replica in another datacenter that can function on its own (in a DR capacity).
Citus uses physical replication for worker and coordinator nodes, and things start getting complicated when you're trying to monitor the status of all the replicas. With vanilla PostgreSQL, you don't have this issue. I'm guessing that they solve this in Azure with block-device primitives at the storage level or something along those lines? It's probably not insurmountable to do it yourself, but we're not yet at the grip-n-rip enterprise offering.
Making HA easier while self-hosting is definitely something that's high on our list of future improvements. I wouldn't be surprised if there will be some announcements regarding this in the coming year. One of the main issues (imo) is configuring HA for PG isn't easy, even when using regular PG. And this becomes even more complicated in the case of Citus, because you're effectively running multiple PG servers, all of which you need to configure HA for.
For my understanding about the multi-region DR capability you would want: Do you want to be able to write to the DR region all the time? Or do you want to be able to switch over to the DR region in case the main DC is down?
Backup on site and store tertiary copies in a cloud. Storing all backups in AWS wouldn't meet a lot of compliance requirements. Even multiple AZs in AWS would not pass muster as there are single points of failure (API, auth, etc).
Depending on OS, you might need to actually put the interface name in there? As you can have fe80::1 on multiple interfaces...it being link-local. Maybe browsers are holding it back?
"Why was iron low?"
"We don't know."
"It's better now?"
"Yes we fixed it!"
If they don't know what's wrong, how did they know what to fix? This is still fishy to me. Also, shame on the author for using the term "ratted out" when this company was selling a substandard product to Americans.
Those "standards" likely don't mean very much. As the original article (from December) points out, the standards were developed in the 1940s to make it harder for Japanese noodles to compete, not because of any real nutritional lack. People in other countries eat pasta that doesn't meet American "standards" and they seem to do just fine.
If you read the original article it tries for a long time to figure this requirement out and it's just arbitrary and apparently rarely ever checked (so also not checked for other pasta products, imported or not). The requirement also doesn't match those in other countries, e.g. in the EU you probably can't sell this product as its not allowed to be enriched (same as all US products have to black out their ridiculous and evidence-free health claims when selling in the EU; any "American food" section will have stickers over these parts of the packaging).
So while you are technically correct that the product is substandard, you could well argue that the issue is the arbitrary standard rather than the actual product.
My understanding is that there’s nothing objectively substandard about it - this is an arbitrary protectionist trade regulation that shouldn’t exist in the first place.
> If they don't know what's wrong, how did they know what to fix?
Pure speculation, but for example if they did design a process to enrich their pasta with iron, tested it initially, but then never tested it again (who cares if there's iron in pasta...), and then it stopped working for some reason (or possibly never worked reliably in the first place). And then instead of trying to find out what made this process not work, they just came up with a new process that did work.
As I said, it's speculation.
Another option is of course "I perfectly know, but I cannot tell you, because if I did, we'd be in legal trouble".
It sounds like PayPal isn't actually buying Bitcoin, but instead created their own proxy bookkeeping instrument. Speculation, but that's what it sounds like to me if you can't have Bitcoin's utility and only its store/speculation.
That sounds extremely risky for PayPal. They're effectively shorting bitcoin by doing that. If the price rises dramatically they have to just come up with that money out of their own coffers. If they buy bitcoin they can merely liquidate it and pay you the proceeds when you sell your paypalcoins.
