From what I can deduce from the release notes and the linked documentation, it can still be enabled?

And it relates to Windows and Linux only, and using the TPM.

My guess is that unreliable TPMs made it risky to have this enabled by default.

> it can still be enabled?

Yes, just like >= 1.86, you set a flag during install.

But that's not the point.

The point is that >= 1.90.2 it became enabled by default.

The point is that most people would expect that "by default" to be a permanent fixture, i.e. a sane secure-by-default config.

This means that people with automated deployments based on >= 1.90.2 can no longer rely on the "by default" and this now needs to be flagged.

If your threat profile has you worried about tailscale + tpm, you probably shouldn't be running talescale unless you're also running headscale...

Just a thought.

Inside the pods it makes no sense, but I do enable it on some memory-constrained worker nodes. Note that the kubelet by default refuses to start if the machine has any swap at all.

Getting it from source is as easy as `go install github.com/minio/minio@latest` if you have a recent Go.

In addition your favorite Linux distribution probably has it as from-source builds already.

For a container image you could try making one from Alpine or Wolfi.

I wrote this guy a few years back. It's lock free for both consumers and producers. Blocking variants are also available, but with significantly poorer performance.

https://github.com/asgeirn/circular-buffer

Ah, DigiCash! I was really optimistic on this concept in my student days - one local bank even had a PoC with digital cash.

This is exactly how the physical representation of money works as well.

The central bank controls how many bills are in circulation, and the central bank regularly expires old bills and coins.

Only unstable third-world countries do that.

The Bank of England honors all of its old banknotes: "There is no deadline to exchange old banknotes with the Bank of England." https://www.bankofengland.co.uk/banknotes/exchanging-old-ban...

The United States has never demonetized any of its coins or banknotes. All of them are honored and are in fact still legal tender to this day -- even the $100,000 bill! https://en.wikipedia.org/wiki/Obsolete_denominations_of_Unit...

Although Canada has revoked legal tender status for some of its older bills, "The Bank of Canada continues to honor them at face value" https://www.bankofcanada.ca/banknotes/about-legal-tender/

In contrast, all of Europe has demonetized its old currencies (Deutschmark, French Francs, Italian Lira, etc.) when switching to Euros, and a few times before that. I've just looked it up and one Napoleon Franc is currently worth ~20€.

So, it's not that uncommon.

You can still convert old DM into Euros at the initial rate in Germany (https://www.bundesbank.de/de/aufgaben/bargeld/dm-banknoten-u....)

The majority of EU member set a limit date: https://www.ecb.europa.eu/euro/exchange/html/index.en.html

I don't think the majority in that list has set a limit for bills, only for coins

Uhm, i guess you are right. (9 vs 11). Sorry I guess I didn't pay enough attention.

No worries, you were right that a majority put time limits on at least some exchanges into Euro.

Europe is an unstable third world country, haven't you heard?

Denmark must be an unstable, third-world country, then:

https://www.al-bank.dk/presse-og-nyheder/nyheder/2023/1000-k...

Yeah, I know of one example where idea was actually created and pitched to media outlets.

They did not like the idea. They very much more like the idea of owning the customer and keeping the customer paying subscriptions.

I also know of a media outlet which incentivizes customer to go from credit card payment to automated bank transfers, since credit cards expire every x years but the bank transfer goes on forever.

Wow. Betcha keyboards with the Official Copilot key®™© will cost plenty of extra.

I don't know why someone would think®™© that.

When you're paying for RHEL you're not paying for the software that you are installing. All of that can be downloaded.

You are paying for:

- A reproducible target. You know EXACTLY what code you are running. If you manage more than three installations this is the only way you can diagnose and fix whatever issues your installation has.

- Support. The very few times I used RHEL support I always got timely and thorough assistance. Even when chasing a hardware bug or issues with third party device drivers.

- Backwards and FORWARDS compatibility. Red Hat systematically backports kernel bug fixes and support for new hardware to old kernels. We ran 2.6 kernels on Intel hardware released long after the 2.6 series were EOL.

- Device drivers. No, not for your five dollar mouse, but for hardware that costs the same as a small SUV.

If you're avoiding RHEL due to cost, have a look at their SKU list and talk to your local sales org, they have a wide range of options.

(Not affiliated with Red Hat or IBM, but RHCE since 2004)

In https://www.kermitproject.org/newsn5.html I found this lovely quote:

> "Kermit will send data over a communication channel that is only slightly better than a pair of tin cans connected with a wet string")

This is actually kind of genius:

> To reduce transmission overhead, the Kermit protocol uses a simple, but often surprisingly effective, compression technique: repeated byte values are represented by a count+byte combination.

> Analysis of large volumes of both textual and binary data shows an average compression of 15-20%.

>repeated byte values are represented by a count+byte combination.

That's just an implementation of RLE[0]. Very common in formats from the 80s. RLE was e.g. used in Amiga IFF ILBM compression.

0. https://en.wikipedia.org/wiki/Run-length_encoding