The only thing hashing classes achieves is making it difficult for users to use ad blockers and/or custom CSS. I understand why e.g. Meta does it on their sites, but for GitHub it makes no sense.
Zelle, from my understanding, is a “protocol” – many banks support it in their own apps. (Scare quotes because I’m not entirely sure it’s a proper well-defined protocol.)
And there’s nothing preventing PoS from supporting individual wallet apps – see e.g. WeChat Pay / Alipay in China. (Alipay+ is also a “protocol”, i.e. other banks and wallets support it.)
What I mean by protocol is that there is an RFC or equivalent and anyone who implements the spec and has a bank account can then talk to their bank using the standardized protocol. If that exists for Zelle then where's the spec?
I’ve searched for ‘zelle spec’ and came across this line:
> Zelle® is available in over 2,400 banking and credit union apps.
so I’m pretty sure there is a spec because there is no way in hell this many banks are using ad-hoc protocols to talk to each other and/or a centralized system. But yeah, I don’t see anything published.
Chances are it’s something ISO 20022-ish. (Either that or an Excel spreadsheet.) Speaking of which...
> and has a bank account can then talk to their bank using the standardized protocol
...if you’re a big enough business, you probably can also speak ISO 20022 to your bank. If you want it on your personal account however, well, that makes two of us, but from practical standpoint what I care more about is that I can punch in an account number and send money near instantly, which Zelle seems to provide in the US (but I have to make do with whatever Wise provides, probably regular ACH judging by speeds).
Inserting and tapping is mostly the same process, apart from the physical layer of the protocol (NFC vs interfacing the chip directly).
Unless there’s a hidden magnetic reader in the chip-reading portion of the terminal, in which case the scammers could read like 1/3 of the magstripe data? Which doesn’t seem that useful tbh.
> Unless there’s a hidden magnetic reader in the chip-reading portion of the terminal, in which case the scammers could read like 1/3 of the magstripe data? Which doesn’t seem that useful tbh.
At least around where I am (Ohio, USA), at gas pumps and ATMs: Inserting the card for contact EMV typically means inserting the whole card.
In doing so, entire card is pushed all the way into the same slot that is also used for reading the magstripe, and to the same depth that is used for magstripe transactions.
This quality leaves the door open for magstripe skimming.
(It may be a stupid way of building things, but things exist in the real world that are built this way anyhow. Whether the information on the mag stripe still has any utility for a would-be thief in 2026 is a different matter.)
> at gas pumps and ATMs: Inserting the card for contact EMV typically means inserting the whole card.
Fairly standard for ATMs, yeah. I’ve always wondered why they do it like that.
And I think I’ve seen ticket machines like this in Finland – not a typical ATM-like receptacle, but you do insert the card all the way in and it locks it down. (I guess Ohio gas pumps also have something like that?)
So yeah, those things exist, but the “typical” terminal style where you only insert the card halfway is fairly safe at least. :-)
The credit cards, I believe, have pledged to eliminate magnetic stripes. Although given how long it takes us to do anything for all I know that will be by 2060. They are also planning to extend credit cards past 16 digits, which may also require the magstripe to go away.
“Maybe later” doesn’t explicitly say that you’ll never get the prompts again, so even if it did work that way, PMs would be able to weasel out and change it back to nagging you with the next update. (In reality, the wording like that is used precisely for this reason already, and that’s why we hate it.)
And it doesn’t really help the user. If I click “Not now” and later decide that I do want the feature, how do I find it? If you want to reassure the user, just say that:
Enable cool new feature X?
(You can always change this in System Settings → Y.)
[ Sure ] [ No, thanks ]
"No, thanks" is also insulting and unacceptable. I want "No, fuck off", so let's compromise on a plain "No" like we used to get in the era when computers were made for the users.
I agree that telling me exactly where I can change it can be helpful, although I'm also sure I won't remember that.
But we're comparing to the case where it just says "No", in which case "Not now" at least tells me I can look up how to change it later now - or more importantly, that I don't need to give this further thought now.
Yes, PMs (or anyone) making software doing dumb shit is dumb anyway, but that also holds true if it were labelled "No".
Good point. Looks like it’s related to window size (incl for lzma btw). Lzma stays 0.9 and goes to 88.5 post 8.8M gap. Zstd -14 is close to lzma up to 4.4M where it jumps to 91.5. 14L seems to be the best overall for this scenario staying at 1.9.
Even that is a bit too much to my taste. For self-promotion pre-roll kind of ads, if I can skip it the first time I see it, and I don’t see it ever again, and I don’t see more than one ad like this per day per series, then I’m reluctantly okay with that.
But ideally, just stick to some non-video recommendation UI during the credits, and let me discover things on your platform by myself otherwise, and don’t get in my way when I’m trying to enjoy the show.
> But even for broadcasts wholly owned and controlled by a streaming platform, like Thursday Night Football on Prime, there are just times when it would be dead air. I don't entirely mind commercials in that instance. Nothing else is going on.
I.e. instead of dead air, they could show some live feed in the spot that other broadcasters use for commercials.
What's happening in that time is just random bullshit. They'll run bits on the jumbotron, hold raffles, go play games with people in the stands, etc. All sponsored by "<SO AND SO>, the official <THING> of your <LOCAL SPORTS TEAM>". Or, in other words, ads.
You could show the players and coaches on the sidelines, but that's also rather boring. It'll be a couple of guys shooting the shit on a bench, or a couple of guys hunched over a table, or some guys warming up.
The best thing they can do is like information from other games maybe.
Honestly, I was going by my most recent experience, which was F1 in Singapore last year. (I’ve been in Singapore at the time, but haven’t managed to get to a good spot, so I was watching it online a couple blocks away.) That thing had ads every minute, but the race obviously doesn’t stop during the breaks.
> What's happening in that time is just random bullshit.
Are most sports events like this? It sucks then, but the playing games with people in the stands thing sounds better than just plain ads. Mix that with sidelines shots, some alternative commentary maybe (with some instant replays?), and sure, information from other games, and you get a nice, coherent broadcast with some ads from the stadium but none that are as out of place as the usual commercial breaks.
> Are you suggesting that the burden should be on channel owners to upload variations of their videos that don't include sponsor blocks?
No, just mark the sponsored segments, so YouTube can skip over (like SponsorBlock does). And they already pay more per view from Premium users vs ad-supported ones, so it just makes sense to skip ads in the video as well.
That being said, I think paying creators directly is more sustainable in the long term.
The only thing hashing classes achieves is making it difficult for users to use ad blockers and/or custom CSS. I understand why e.g. Meta does it on their sites, but for GitHub it makes no sense.
reply