Notices by Bitslingers-R-Us (anachronistjohn@zia.io)

@JessTheUnstill

@SuperDicq I’d like to find a nice Miata body with a blown engine… Sigh. One of these days.

@cwebber Indeed! I have several issues with datacenters.

First, using large amounts of water for cooling is NOT required. Evaporative cooling is NOT required. The fact that every so-called journalist writes about datacenter projects without calling out the megacorps who simply don’t want to pay for non-evaporative cooling just makes things worse.

I have servers colocated in three different datacenters in three different US states. None use evaporative cooling. For years I had a quarter rack in a datacenter in Phoenix, Arizona, also without evaporative cooling. In Phoenix!

Sure, people who like to make excuses for megacorps will say that high density compute like what AI companies want to build can’t be cooled without evaporation, but that’s simply not true. It can be done, but it costs much more, and AI companies don’t care about 10+ year ROI.

The articles that don’t point out that all of these projects are bribing - er, negotiating cheaper power and water from municipal sources that are driving residential prices higher are doing everyone a disservice.

All of this is one of many failings of capitalism. When a single corporate entity can demand so much of a service’s output that it can adversely shape the costs of basic, required services, there’s something wrong. The fact that there’s no governmental protections from this kind of abuse is highly problematic.

It sure would be nice if journalists pointed out that the results of megadatacenters aren’t inevitable, but chosen based on how much hurt can be pushed on to everyone else.

@slyecho @cwebber Do you have some examples and numbers to share?

Also, it’s not “outrage” to not want your local municipal water prices to go up, for your water quality to go down, for your aquifiers to run dry and/or for your area to run out of water, or anyone else’s. Saying that someone else is doing something worse so that doing something bad isn’t as bad isn’t really a persuasive argument.

I’d rather have S100 than $100.

@ryanc My guess is Google’s nameservers caching incorrect DNS for much, much longer than the published TTL. That, at least, is what I’ve been dealing with.

Thanks, Google :P

@nina_kali_nina @libreleah @lucy I agree with Nina. Perhaps you’ve fixed more things, or in better ways than whoever originally did the pkgsrc work.

@libreleah @lucy @nina_kali_nina librewolf is in pkgsrc-wip. It’s a start, at least.

https://pkgsrc.se/wip/librewolf

@dalias Holy cow! Remember juno.com?

I have to check if RIPv6:$+ $: <$( checkv6 $&s $: FAIL $)>V6 does what I expect it to, because I got something like this not long ago:

I think I was expecting canonicalization of the IPv6 address.

@dalias Ages ago, I twisted my brain enough to learn Sendmail rules and came up with two HELO / EHLO checks: one which requires that the HELO / EHLO name resolves to the connecting IP(v6), and that the PTR for that address also resolves to the same address, and one that’s not as aggressive and just makes sure that the HELO / EHLO name resolves in DNS.

Checking that the PTR name resolves to the same address as the PTR is beyond Microsoft. I think they’re not allowed to have O’Reilly animal books. They really take “not invented here” seriously, and considering they haven’t invented shit, nothing of theirs works properly.

@dalias 2a01:111:f403:c105:0:0:0:1 would be non-canonical, and 2a01:111:f403:c105::1 would be after canonicalization. Or the other way around. Point is, they need to be consistent to properly compare.

I’ll have to take some time soon to look up new (to me) Sendmail macros!

@dalias Outlook is all over the place. Some names give a single IPv4 and a single IPv6. Some give several of one or the other, or several of each. Some give proper answers.

What EHLO errors are you specifically making overrides for, if I may ask?

@mac84tv Any chance you’re interested in a backup LaserDisc player?

@kornel @chainq

Lack of obscure/legacy things is immaturity only if you assume having them is a goal, but Rust prioritized other things

You illustrate the problem perfectly here: thinking that it’s either / or is a broken way of thinking.

Even if it were the case that prioritizing certain things precludes others (which it most certainly isn’t, unless you’re doing things incorrectly), this is precisely why Rust is inappropriate for universal adoption.

If a certain corporate led group gets to decide what is “obscure/legacy”, then people either have to maintain their own forks of Rust, or we just have to blindly accept that things that aren’t popular enough or that don’t get enough attention by corporations will be deemed, “obscure/legacy”.

@kornel @chainq This is bad for the planet. We should make good use of our computing resources and not intentionally landfill them. m68k is an example of how we can maintain support for non-mainstream if we want, yet people who know nothing about m68k would love to kill it for emotional reasons. We don’t need this at all. We’re already seeing this with Debian and i386.

So when people want to lump things in to an “obscure/legacy” category and suggest that the problem isn’t Rust, that just means you’re cheerleading for reducing sustainability.