When water is used for evaporative cooling, its content of minerals and any other junk that's in it shoots up. It's kinda like anti-distilled water; distilled to be more polluted.

At a particular power plant near me, that water is pumped to an adjacent farm where it's used for irrigation. The cost of processing it or the damage from putting it back into the river is too high, but it's acceptable for irrigation water.

It doesn't MAGICALLY disappear, but it does evaporate. In doing so, it's effectively no longer available for common use.

It does so in cooling towers. Much of the heat rejected, by nuclear reactors and (I presume(1)) the data center cooling system, is from evaporation in the external cooling tower. The big clouds you could sometimes see over a nuke site? Water vapor from the cooling tower.

(1) I've seen evaporative cooling towers on large commercial buildings I've worked on. It reduces the load on the heat pump of the cooling system. I presume the same sort of system is often used in a data center. In a dry area like Arizona, this would be extra effective.

Need evidence to support this claim.

I sit on a consumer cable modem. Some years ago, my current email host upped the price on the two packages I had three and four fold without warning (claiming they'd made the service better, which I'd seen the exact opposite over time), so I took my business to another company. That other company was way cheaper, but completely incompetent when blocking even the simplest of spam. That was the final straw for me and I wrote enough of my own email server to block messages the way _I_ wanted to.

For anyone who would be interested, that code is here: https://github.com/marvinglenn...

Because I'm sitting on a consumer connection, I use the spam-blocking-incompetent company for my outgoing relay. My MX is directed to my dynamic DNS. My server will push messages into the IMAP package I pay for (since I haven't been motivated enough to finish writing an IMAP server or web interface).

The key thing I get with running my own incoming server is the ability to cause as much collateral damage as I want. I've had it with allowing companies to profit off spammers and not face some retribution for it. (Namecheap, Global Frag Networks, Whois Guard, ...)

Another philosophy I don't agree with is the concept of a "spam folder". While you can set up my server to tag messages for a spam folder, I don't run it that way. I've seen too many messages end up in a spam folder to only be found too late for their intended purpose. The sender thinks the message got through; the recipient doesn't know there's a message they'd want to see. I want a hard reject during the SMTP transaction. If the sender is legitimate, they should get a bounce and will know they need to use another method to contact the recipient.

So I was about to dispute the parent from knowledge of a class action lawsuit (settled circa 2012) against the big CC players, but it appears that that the settlement was thrown out in 2016. Prior to the 2012 settlement, I recall the "cash discount" angle being treated as against the terms prohibiting surcharges.

I remember following it closely at the time due to my personal interest while at a mom&pop store. A small bit I recall is Discover getting excused from the class by removing those terms from their merchant agreement. The blog WayTooHigh covered/followed it quite well, and appears to still be up, though not maintained.

http://www.waytohigh.com

2012 class action settlement: https://www.classaction.org/bl...

2016 reversal: https://www.creditcards.com/cr...

https://arstechnica.com/tech-p...

Let's not be shrill and disingenuous here. The FCC _is_ doing something about it, but we are still beset with the problem.

I've found it still somewhat useful, in that a couple of those masking companies, like "Whois Guard" in particular on my system(1), are so bad that I can reject email for purely being from a domain that uses their services.

(1) My current stats have >2300 unique domains using their service that I've rejected email from.

I believe that you are absolutely incorrect about there being a _law_ about not surcharging CC usage.

This issue was very much on my radar a couple of decades ago. There was a class action lawsuit against the biggest CC player about this. There was a blog that followed it, and while they dumped the custom domain, it appears that the content from the blog is here: https://waytoohigh.wordpress.c...

What it actually was... there was a _contract_term_ from your credit card processing bank that stipulated that you could not surcharge for CC. Some got around it by the cash discount, but eventually enough did that that they caught on to it, and forbid it by contract. And this was essentially a contract of adhesion, and every processor carried through the same restrictive terms. Didn't like the terms? Don't accept any of the big [four] CCs.

I was working at a very small retail merchant during that period, not even 'mom and pop', just 'pop'; and was very attuned to what it cost us. I remember seeing cease and desist letters from the CC company over our policy of not allowing CC payments for transactions Since the conclusion of the law suit, I've observed many more merchants declaring either a minimum transaction for a CC, or a processing fee on transactions under a threshold amount.

I have a project in the works where a future piece of it is intended to address this issue. I'm essentially waiting for the right time to publish. Since it's the current discussion here, here's the relevant part...

My intention is to use a piece of IPv6 space and encode a lat/long into it in a way that: A) you only have to make sure that no one near you is using the same lat/long, and B) for networks far away from you, you can represent many of them in a single entry line in your routing table. A network-slash-mask notation ends up encoding a rectangle laid onto the globe.

Specifically, I am intending to set up shop in 0x3FFF/16. The next 48 bits are the central lat/long (encoded in a special way) of the main control point you declare for you network. The last 64-bits are for you to spread across all the nodes in your network or managed group.

The lat/long is encoded as two 24-bit values, interleaved. With a lat or a long represented a 24-bit number, you have a granularity of about 8 feet on average. They are interleaved so that you can slice them with a netmask value and refer to large rectangle (granted it's warped by being laid onto a sphere) as a single entry. For networks far from you, most of the time all you really care about is that what direction are they (N-S-E-W), because you'll push them out a link headed that direction. For networks near you, you will store more entries.

My encoding of the lat/long is to take the -90 to +90 of lat, and -180 to +180 of long and map them across a 24-bit signed integer. The scaling of them becomes:

integer_lat_value = int(latitude / 90.0 * 2^23)

integer_long_value = int(longitude / 180 * 2^23)

The above values are then interlaced into a 48-bit value, most significant bits first, latitude first.

At least the first two, telephone service and postage, have cost/rates set by a government entity. And for at least one of those, phone service, some can get free (to you) access.

When the government sets the cost and license terms for the proprietary software necessary to interact with them, then I will accept the analogy.

They're not going for hydro-electric; they're going for where the power is cheap. Power just happens to be cheap in the middle of a major span of hydro-electric production.

Also... all the electricity they use there cannot be shipped elsewhere, even if there are transmission losses, to reduce the load on coal plants.