Since the pool identifiers are static, how do you actually fail over?

Oh, you need a custom domain that presumably routes if the primary dies.

I have to look a bit, but it could probably replace Cassandra now as well.

"Herd size is down, but U.S. beef production is steady"

So the author talks about all this stuff, but probably the three big cost drivers are:

1. Input costs are higher

2. Possible price fixing by meatpackers

3. Lack of Mexican imports due to screwworm. Although it sounds like Mexican imports would increase the herd size, not the amount of beef on the market.

Not sure why people haven't been importing more beef. The article mentions tariff cuts for Argentina, but there are other places that export beef. Possibly the market is tight all over the world?

Every architectural decision is a tradeoff between something and another. Every technology choice is also a tradeoff. If you understand the reasons for the choices you'll start understanding architecture.

Sometimes it starts with requirements (ie: what you're trying to do), or what your deployment environment looks like, your hosting provider, or even what technology static you'd rather use.

For example, I'd never use Java for a project ever again; it's unclear what it really brings to the table, and it's more difficult to deploy on AWS. And if I was going to use Java I wouldn't pick Spring or any other dependency injection framework because they inevitably lead to impossible-to-debug performance issues. I wouldn't use an ORM for the same reason. No Ruby as well, due to issues with migrations and active record. No postgres unless there was a specific feature of it that works better than other, due to RDBMS management overhead and inconsistencies.

Of course, now that I write this my next project is going to be some random Java/Spring/pgsql thing with a Ruby engine attached (aargh).

What helps actually is reading the "why you should use this tool" parts of each tool. You can start building a mental model/checklist of the good/bad things of each one and why would you use one instead of the other. There's almost always more than one tool available, and the way you deploy/scale/manage/backup each one will tell you a lot about when you would (or wouldn't) use it.

In general don't worry about scale until you're at the point you can test for scalability. I mean, some architectures are better than others, but all of them will be performant at 10 users. Even flat files, a bash web server, and bash-based CGIs can handle 10 users.

Who's buying? It could be their customers were boomers, who are dying. What are they doing to bring in new customers?

The answer: nothing.

The book industry is surprisingly bad at marketing, given how big it is/was.

In golf, strength is overrated until you get to the pros.

https://law.stackexchange.com/questions/37491/is-it-truly-il...

Back in the Pepsi days there were always free cups around from people that didn't like Pepsi. Now - nada.

I've run mysql for years in production and have spent probably 30 minutes thinking about managing it. Unless there's some psql feature you need (unlikely), it'll just become a severe pain in your ass down the road because you set something up "wrong."

Just vacuuming can barf completely, leaving you dead in the water.

TL;DR: if you aren't a DBA and don't want to play one on TV don't bother with psql.

The issue is there's a lot of lore and esoterica required to get it to scale.

Every time there's an issue with Postgres there's someone that's all "just do xyzzy, it's super obvious that this undocumented setting fixes it."

Just look at the slowdown/big pages problem.

If it works for you, use it.

It makes me wonder how undetectable we really were when we smoked up when we were kids. I mean dang, I can smell the weed half a block from Chipotle after 9pm.

How that will work will be unclear, because technically marijuana is still a controlled substance. That said, pharmacies can bank, so at some level dispensaries can bank. Maybe only medical dispensaries can bank, and the recreational ones will piggyback off of them?

Though at some point they'll just start using random MAC addresses Then you have to ensure that you block all external access for stuff that didn't get an IP from your DHCP server. Which probably won't work with IPv6 because it could just assign itself an IP and go.

How would you block a random device on IPv6 that's generating its own IP?