For the tap to pay I am now using my Garmin smartwatch. Still corporate, but not Google/Apple huge corporate.

Very content with GOS otherwise. I blame app providers for their ridiculous limitations, not custom ROM developers.

Very cool! I am guessing you never got around to making the Kubernetes controller you mention in the README? :D

Nopes, the packaging took up the last of my time for the project.

> That is their decision. Without any contract or promise, there is no obligation to anybody.

Even as a paying customer on a $1m/yr contract, still using the open source distribution because AIStor is not something we are keen on, we were not informed whatsoever.

They were well aware we were still using those container images, and we were by far the only paying customers doing the same.

This is malicious.

Not from the US, but I did see a missing word in the footer:

> There was a recent effort by the U.S. government *to* create a no cost,

In my view one reason is to ensure integrity down the line. You want the checksum of a file to still be the same when you download it maybe years later. If it isn't, you get warned about it. Without the checksum, how will you know for sure? Keep your own database of checksums? :)

If we're talking about bitrot protection, I'm pretty sure S3 would use some form of checksum (such as crc32 or xxhash) on each internal block to facilitate the Reed-Solomon process.

If it's verifying whether if it's the same file, you can use the Etag header which is computed server side by S3. Although I don't like this design as it ossifies the checksum algorithm.

You may be interested in this https://aws.amazon.com/blogs/aws/introducing-default-data-in...

Supposedly creators get a bigger share from YT Premium users' compared to regular, ad-watching views, simply because skipped ads mean no revenue. It's still marginal because most people don't have Premium though.

> Supposedly creators get a bigger share from YT Premium users'

I've heard this multiple times before, but every time I go hunting for a source from Google/YouTube, I cannot find any official statements or confirmed information about this, seems this is mostly based on 3rd party analysis afaik.

Linus tech tips had a break down of their income. One thing Linus highlighted was that YouTube Premium revenue was much larger than most would expect. See https://www.youtube.com/watch?v=-zt57TWkTF4&t=400s (it's a little under 20% of their total revenue from YouTube).

I found this screenshot of the partner program contract that says it's a 55% split for either https://imgur.com/YjOHAAr

But for Premium the amount is distributed by watch time, whereas for ad-supported users it's by number of ad views. This means that for short videos where the value of the ad is higher then the value of the watch time, a "free" user wins, but for longer form videos where the watch time is longer, the Premium user wins.

LinusTechTips once showed the YouTube income breakdowns for some of their videos that showed this - for their hour+ long PC build streams, Premium income was higher and for shorter videos, Ads income was higher.

I've released an album via Distrokid which distributes the release to YouTube as well. You can look at detailed reports there. Youtube revenue is split into Ads, ContentID and Red (which I believe is the old name for Youtube Premium). I just checked and I am currently getting a bigger share from Ads than from Red, per play.

Is "per play" the correct metric to use? What I'd like to compare are the hypotheticals "everyone is on Premium" and "everyone runs all the ads", but I'm not sure how to extrapolate this from some random split (I assume you don't see the ratio of your viewers) of Premium-to-ad..

I quite really like pdm! I can see why maybe poetry but especially pipenv might be replaced with uv, but what's the value of uv over pdm beyond performance? It ticks all my boxes otherwise.

>but what's the value of uv over pdm beyond performance

uv is not written in python so it doesn't suffer from the bootstrap problem of having a python version installed to begin using it. Users (new and even experienced) get confused and annoyed when they try to use python tooling in the same venv as their application instead of using pipx.

People also get confused and annoyed if they use mac and run `brew upgrade` and find themselves with python 3.13 or just any version that is new (yes we can pin to python@3.11 or whatever) so pyenv is a good option.

So now you have pdm, pipx, and pyenv to manage all this stuff. With uv all this hassle goes away.

I came to uv from pdm, and the only reason I switched is the sheer speed and simplicity of uv. Pdm is such a great utility, and it can use uv as the package solver, but uv still has it beat on raw speed, and it feels simpler to use (whether or not it actually is).

I am feeling the same way about PDM, it works very well, easy to configure and checks all the boxes feature-wise.

Beyond performance? Performance!

pdm is actually my favorite too, I used it on ArchiveBox for years and loved it. I still use it as the build backend instead of hatch in some places

Works fine for me on Firefox Linux. Interestingly took a lot longer to load in Chromium and Brave but they all work.

bsky still lacks basic security features like 2FA (beyond an email code) (andOAuth implementation), which puts me off from actively using it...

Thank you for introducing me to Terminal Trove. So many tools to try and experience, loving it!