Data centers and most physical devices made the jump pretty early (I don't recall a time where the VPS providers I used didn't allow for IPv6 and every device I've used has allowed IPv6 in the last 2 decades besides some retro handhelds), but domestic ISPs have been lagging behind. Mobile networks are switching en masse because of them just running into internal limits of IPv4.

Domestic ISPs don't have that pressure; unlike mobile networks (where 1 connection needing an IP = 1 device), they have an extra layer in place (1 connection needing an IP = 1 router and intranet), which significantly reduces that pressure.

The lifespan of domestic ISP provided hardware is also completely unbound by anything resembling a security patch cycle, cost amortization or value depreciation. If an ISP supplies a device, unless it fundamentally breaks to a point where it quite literally doesn't work anymore (basically hardware failure), it's going to be in place forever. It took over 10 years to kill WEP in favor of WPA on consumer grade hardware. To support IPv6, domestic ISP providers need to do a mass product recall for all their ancient tech and they don't want to do that, because there's no real pressure to do it.

IPv6 exists concurrently with IPv4, so it's easier for ISPs to make anyone wanting to host things pay extra for an IPv4 address (externalizing an ever increasing cost on sysadmins as the IP space runs out of addresses) rather than upgrade the underlying tech. The internet default for user facing stuff is still IPv4, not IPv6.

If you want to force IPv6 adoption, major sites basically need to stop routing over IPv4. Let's say Google becomes inaccessible over IPv4 - I guarantee you that within a year, ISPs will suddenly see a much greater shift towards IPv6.

I don't quite understand why it's still like this; it's probably the biggest reason why git tends to play poorly with a lot of filesystem tools (not just backups). If it'd been something like an SQLite database instead (just an example really), you wouldn't get so much unnecessary inode bloat.

At the same time Backblaze is a backup solution. The need to back up everything is sort of baked in there. They promise to be the third backup solution in a three layer strategy (backup directly connected, backup in home, backup external), and that third one is probably the single most important one of them all since it's the one you're going to be touching the least in an ideal scenario. They really can't be excluding any files whatsoever.

The cloud service exclusion is similarly bad, although much worse. Imagine getting hit by a cryptoworm. Your cloud storage tool is dutifully going to sync everything encrypted, junking up your entire storage across devices and because restoring old versions is both ass and near impossible at scale, you need an actual backup solution for that situation. Backblaze excluding files in those folders feels like a complete misunderstanding of what their purpose should be.

Ironically, I believe you have it backwards: pack files, git's solution to the "too many tiny files" problem, are the issue here; not the tiny files themselves.

In my experience, incremental backup software works best with many small files that never change. Scanning is usually just a matter of checking modification times and moving on. This isn't fast, but it's fast enough for backups and can be optimized by monitoring for file changes in a long-running daemon.

However, lots of mostly identical files ARE an issue for filesystems as they tend to waste a lot of space. Git solves this issue by packing these small objects into larger pack files, then compressing them.

Unfortunately, it's those pack files that cause issues for backup software: any time git "garbage collects" and creates new pack files, it ends up deleting and creating a bunch of large files filled with what looks like random data (due to compression). Constantly creating/deleting large files filled with random data wreaks havoc on incremental/deduplicating backup systems.

Why should a file backup solution adapt to work with git? Or any application? It should not try to understand what a git object is.

I’m paying to copy files from a folder to their servers just do that. No matter what the file is. Stay at the filesystem level not the application level.

It's that to back up a folder on a filesystem, you need to traverse that folder and check every file in that folder to see if it's changed. Most filesystem tools usually assume a fairly low file count for these operations.

Git, rather unusually, tends to produce a lot of files in regular use; before packing, every commit/object/branch is simply stored as a file on the filesystem (branches only as pointers). Packing fixes that by compressing commit and object files together, but it's not done by default (only after an initial clone or when the garbage collector runs). Iterating over a .git folder can take a lot of time in a place that's typically not very well optimized (since most "normal" people don't have thousands of tiny files in their folders that contain sprawled out application state.)

The correct solution here is either for git to change, or for Backblaze to implement better iteration logic (which will probably require special handling for git..., so it'd be more "correct" to fix up git, since Backblaze's tools aren't the only ones with this problem.)

When I backup my computer the .git folders are among the most important things on there. Most of my personal projects aren't pushed to github or anywhere else.

Fortunately I don't use Backblaze. I guess the moral is don't use a backup solution where the vendor has an incentive to exclude things.

Windows has a much harsher approach to file locking than Linux and backup software like BackBlaze absolutely should be making use of it (lest they back up files that are being modified while they back them up), but that also means that the software effectively has to ask the OS each time to lock the file, then release the lock when the software is done with it. With a large amount of files, that does stack up.

Linux file locking is to put it mildly, deficient. Most software doesn't even bother acquiring locks in the first place. Piling further onto that, basically nobody actually uses POSIX locks because the API has some very heavy footguns (most notably, every lock on a file is released whenever any close() for that file is called, even if another component of the same process is also having a second lock open). Most Linux file locks instead work on the honor system; you create a file called filename.lock in the same directory as the file you're working on, and then any software that detects the filename.lock file exists should stop reading the file.

Nobody using file locks is probably the bigger reason why Linux chokes less on fast iteration than Windows, given that Windows is slow with loads of files even when you aren't running a virus scanner.

Since the introduction of flock on Linux, how bad is it really though? I don't see why one would need kludges like filename.lock. Though of course flock is still an "honor system" as you put it.

Well, for backups the workaround is a bit easier (as they strictly only ever read files), but still.

That's a really important fact that's getting buried so I'd like to highlight it here.

This is a joke, but honestly anyone here shouldn't be directly backing up their filesystems and should instead be using the right tool for the job. You'll make the world a more efficient place, have more robust and quicker to recover backups, and save some money along the way.

This. It's best to do this in an atomic operation, such as a VSS style snapshot that then is consistent and done with no or paused operations on the files. Something like a zip is generally better because it takes less time on the file system than the upload process typically takes.

See Fossil (https://fossil-scm.org/)

P.S. There's also (https://www.sourcegear.com/vault/)

> SourceGear Vault Pro is a version control and bug tracking solution for professional development teams. Vault Standard is for those who only want version control. Vault is based on a client / server architecture using technologies such as Microsoft SQL Server and IIS Web Services for increased performance, scalability, and security.

It's the same reason why the postgres autovacuum daemon tends to be borderline useless unless you retune it[0]: the defaults are barmy. git gc only runs if there's 6700 loose unpacked objects[1]. Most typical filesystem tools tend to start balking at traversing ~1000 files in a structure (depends a bit on the filesystem/OS as well, Windows tends to get slower a good bit earlier than Linux).

To fix it, running

> git config --global gc.auto 1000

should retune it and any subsequent commit to your repo's will trigger garbage collection properly when there's around 1000 loose files. Pack file management seems to be properly tuned by default; at more than 50 packs, gc will repack into a larger pack.

[0]: For anyone curious, the default postgres autovacuum setting runs only when 10% of the table consists of dead tuples (roughly: deleted+every revision of an updated row). If you're working with a beefy table, you're never hitting 10%. Either tune it down or create an external cronjob to run vacuum analyze more frequently on the tables you need to keep speedy. I'm pretty sure the defaults are tuned solely to ensure that Postgres' internal tables are fast, since those seem to only have active rows to a point where it'd warrant autovacuum.

[1]: https://git-scm.com/docs/git-gc

> git config --global gc.auto 1000

with the long option name, and no `=`.

Let's ride the lightning and see if it does anything.

ie. Yes, you could run a full on corporate CA, issue SSL certificates for your domains, manually rig up wireguard and run your own internal corporate VPN... or you just accept that your grand total of 1 concurrent user on an intranet is probably just better served by setting up Tailscale and a wildcard LE certificate so that the browser shuts up. (Which is still not great, but the argument over HTTPS and intranets is not for right now.)

Same with other deployment tools like Docker - yes, there's a ton of fancy ways to do persistent storage for serverless setups but get real: you're throwing the source folder in /opt/ and you have exactly one drive on that server. Save yourself the pain and just bind mount it to somewhere on your filesystem. Being able to back the folder up just with cp/rsync/rclone/scp is a lot easier than fiddling with docker's ambiguous mess of overlay2 subfolders.

Every overengineered decision of today is tomorrow's "goddammit I need to ssh into the server again for an unexpected edgecase".

Here's the real situation: the people that pick up the phone when you call them up aren't going to be paid much above minimum wage at all. They have zero institutional power to fix anything. You're yelling at people that, themselves, almost certainly are only barely making enough money to get by either.

It is worthless to yell at these people because they can't fix shit; they don't set policies, they have no power to fix things and all your yelling is going to achieve is at best counterproductive to what you want to get done (since now the front facing employee dislikes you personally and is less inclined to try and help you out) and at worst is going to get you into further trouble when you do need something routine done. (Since now you're on the list of "people that the employees don't want to put any extra effort into since they're jerks".)

There are people that get paid to be the complaints facing entity of the organization, who are paid to withstand whatever shit you can throw at them and who have an ability to fix up whatever you needed in specific. They're not the people that pick up the phone.

What you need to do is channel the inner Karen and ask to speak to the manager. The manager can help you with this sort of thing, they are the ones that can do shit to avoid sustaining the machine, because they have a career they want to grow into and risk actual consequences for pissing people off.

Be polite (but firm; you don't need to be walked over) to the first tier support employees, even if they can't help you. Save the complaints for the manager (who you shouldn't be afraid to ask to speak to either). The managers job is to deal with the real complaints, not the routine stuff that just happens to need a human involved. They are taking a job to be the face of the machine for reasons other than "I literally need a minimum wage job to survive".

It was OOP that chose to escalate this to malicious compliance and ascribed a lot more to her attitude than what's actually said. OOP assumed that she was out to get him in specific, when nothing in the described call even suggests as much.

The correct response would've been to ask for the manager and if the manager chooses to stonewall in an obnoxious way (which is possible!), then you pull the frustrating fax from hell on them. At that point, you're not just speaking to someone who has no power to fix shit, you're talking to someone who does have the power to fix shit and chooses to be a stick in the mud about it. That's when being a jerk back is deserved.

Being a jerk to low paid employees in this manner is unacceptable, rude and makes me think a lot less of the person writing it.

They also don't want to host your homepage, so if GitHub Pages is why you used GitHub, they are not a replacement.

Unfortunately I don't think there's really an answer to that conundrum that doesn't involve just spinning up your own git server and accepting all the operational overhead that comes with it. At least Forgejo (software behind Codeberg) is FOSS, so you can do that and it should cover most of what you need (and while you're in the realm of having a server, a Pages-esque replacement is trivial since you're configuring a webserver anyway.) Maybe Gitlab.com, although I am admittedly unfamiliar with how Gitlab's "main" instance has changed over the years wrt features.

Here's their FAQ on the matter, it's worth a read: https://docs.codeberg.org/getting-started/faq/

https://docs.codeberg.org/codeberg-pages/

> If you do not contribute to free/libre software (or if it is limited to your personal homepage), and we feel like you only abuse Codeberg for storing your commercial projects or media backups, we might get unhappy about that.

Emphasis mine. This isn't about if it's technically possible (it certainly is), it's whether or not it's allowed by their platform policies.

Their page publishing feature seems more like it's meant for projects and organizations rather than individual people. The way it's described here indicates that using them to host your own blog/portfolio/what have you is considered to be abusing their services.

All it shows the world is why there needs to be a VAT like tax against US digital services to help drive a public option for developers.

There's no reason why the people can't make our own solutions rather than be confined to abusive private US tech platforms.

A better alternative would be to create the incentives so that companies like these can be born in Europe.

I am not sure how someone should be entitled to prevent others from enjoying thr benefits of better technology.

If you do not like it, just skip it, as I do.

Because you will scare all of them.

Just fix the right things, not the wrong ones.

You are against democracy, I am not. Democracy has led to some of the best advances of civilization, all oligarchies have done is introduce mass poverty, mass misery, and mass death.

At least with democracy we went to the moon for mankind, not shareholders.

Your definition of not letting people choose goes more against democracy that what I mean IMHO.

Just do not let these people collude with the power. Fewer politicians would mean fewer people doing business to influence others through politics.

That is what my experience tells me.

My 2 cents.

Keep in mind, I'm not saying Codeberg is bad, but it's terms of use are pretty clear in the sense that they only really want FOSS and anyone who has something other than FOSS better look elsewhere. GitHub allowed you to basically put up anything that's "yours" and the license wasn't really their concern - that isn't the case with Codeberg. It's not about price or anything either; it'd be fine if the offer was "either give us 5$ for the privilege of private repositories or only publish and contribute public FOSS code" - I'm fine paying cash for that if need be.

One of the big draws of GitHub (and what got me to properly learn git) back in the day with GitHub Pages in particular was "I can write an HTML page, do a git push and anyone can see it". Then you throw on top an SSG (GitHub had out of the box support for Jekyll, but back then you could rig Travis CI up for other page generators if you knew what you were doing), and with a bit of technical knowledge, anyone could host a blog without the full on server stack. Codeberg cannot provide that sort of experience with their current terms of service.

Even sourcehut has, from what I can tell, a more lenient approach to what they provide (and the only reason why I wouldn't recommend sourcehut as a GitHub replacement is because git-by-email isn't really workable for most people anymore). They encourage FOSS licensing, but from what I can tell don't force it in their platform policies. (The only thing they openly ban is cryptocurrency related projects, which seems fair because cryptocurrency is pretty much always associated with platform abuse.)

I mean, it is arguably much easier to just write the HTML page and upload it with FTP and everyone can see it. I never understood why github became a popular place to host your site in the first place.

Easy: it was free, it was accessible to people that couldn't spend money for a hosting provider (read: high schoolers) and didn't impose arbitrary restrictions on what you were hosting.

Back then, your options as a high school student were basically to either try and reskin a closed off platform as much as you could (Tumblr could do that, but GitHub Pages also released in the time period where platforms were cracking down on all user customization larger than "what is my avatar") or to accept that the site you wanted to publish your stuff on could disappear at any moment the sketchy hosting provider that provided you a small amount of storage determined your bandwidth costs meant upselling you on the premium plan.

GitHub didn't impose those restrictions in exchange for being a bit less interactive when it came to publishing things (so no such thing as a comment section without using Disqus or something like that, and chances are you didn't need the comments anyways so win-win) That's why it got a lot more popular than just using an FTP server.

1) Passive mode. What is it and why do I need it? Well, you see, back in the old days, .... It took way too long for this critical "option" to become well supported and used by default.

2) Text mode. No, I don't want you to corrupt some of my files based on half-baked heuristics about what is and isn't a text file, and it doesn't make any sense to rewrite line endings anymore anyway.

3) Transport security. FTPS should have become the standard decades ago, but it still isn't to this day. If you want to actually transfer files using an FTP-like interface today, you use SFTP, which is a totally different protocol built on SSH.

And if you already knew how to write/make HTML you'd for sure already know all of that too.

I don't always have a server available to host an HTTP+FTP server on. Or want to pay for one, or spend time setting one up. I can trust that Github Pages will have reasonable uptime, and I won't have to monitor it at all.

> And if you already knew how to write/make HTML you'd for sure already know all of that too.

This seems unnecessarily aggressive, and I don't really understand where it's coming from.

BTW, you can absolutely host plain HTML with Github Pages. No SSG required.

That's a completely false statement. My kid took very basic programming classes in school which covered HTML so they could build webpages, which is a fantastic instant-results method. Hooray, now the class is finished, he wants to put it on the web. Just like millions of other kids who couldn't even spell FTP.

No it wasn't. Seriously, where?

a) git pull & push for updates

b) good enough CDN distribution, sometimes interactive examples/project page loads tons of files

c) good enough security promises of the entire platform/infra

d) good enough serviceable time, we do not need 99.9999SLA but better not down often

e) have generous free tier

f) great DX & UX, this one is small but small headache adds up quickly

> you may receive a polite email from GitHub Support suggesting strategies[… such as, and including] moving to a different hosting service that might better fit your needs

GitHub Pages has never been a free-for-all. The acceptable use policy makes it clear:

> the primary focus of the Content posted in or through your Account to the Service should not be advertising or promotional[…] You may include static images, links, and promotional text in the README documents or project description sections associated with your Account, but they must be related to the project you are hosting on GitHub

Sounds like they're cool with a little personal website.

Hmm all that operational overhead... Of an ssh server? If you literally just want a place to push some code, then that really isn't that hard.

And no, its not that hard once you learn. Except, now its a never ending chore when it was an appliance. Instead of a car you have a project car.

Can confirm.

Also, not everyone who wants to share content publicly has a domain name with which to do so, or the kind of Internet connection that allows running a server. If you include "hosting" by using a hosting provider... it's perfectly possible (raises hand) to not even have any experience with that after decades of writing code and being on the Internet. (Unless you count things like, well, GitHub and its services, anyway.)

And I believe GP was talking about the only thing you need is:

  ssh user@remotehost git init --bare repo.git

  git remote add origin user@remotehost:repo.git

  git push origin branch_name

then do above.

then troubleshoot.

set vm backup policy.

save myriad passwords and secret to bitwarden.

get ubuntu to stay up to date.

    # locally
    ssh git@example.com
    
    # server
    mkdir repo.git  
    cd repo.git  
    git --bare init
    
    # locally
    git remote add origin ssh://git@example.com/home/git/repo.git  
    git push origin master

Just store the repo and access it with your account.

The whole git@ thing is because most "forge" software is built around a single dedicated user doing everything, rather than taking advantage of the OS users, permissions and acl system.

For a single user it's pointless. For anyone who knows how to setup filesystem permissions it's not necessary.

but if you're just looking for a generic place to put your code projects that aren't necessarily intended for public release and support (ie. random automation scripts, scraps of concepts that never really got off the ground, things not super cleaned up), they're not really for that - private repositories are discouraged according to their FAQ and are very limited (up to 100mb).

You don't need a one size fits all solution...

Until the AI scrapers[1] come for you at 5k requests per second and you're doing operations in hard-mode.

1. Most forges have http pages for discoverability. I suppose one could hypothetically setup an ssh-only forge and statically generate a html site periodically, but this is already advanced ops for the average Github user

Hey, I’m building Monohub - as a GitHub alternative, and having private repositories is perhaps a key feature - it started as a place for me to host my own random stuff. Monohub [dot] dev is the URL. It’s quite early in development, so it’s quite rough around the edges. It has PR support though.

Hosted in EU, incorporated in EU.

Would be happy if you tried it out — maybe it’s something for you.

Edit: you can have a look at a public repository I have to see what it looks like now: https://monohub.dev/@tbayramov/efcore-audit-timestamps

   ipinfo monohub.dev
  Core
  - IP           188.114.96.1
  - Anycast      true
  - Hostname     
  - City         San Francisco
  - Region       California
  - Country      United States (US)
  - Currency     USD ($)
  - Location     37.7621,-122.3971
  - Organization AS13335 Cloudflare, Inc.
  - Postal       94107
  - Timezone     America/Los_Angeles

Domain whois: https://monohub.dev.whoswho

(Yes, I'm still salty google broke our localhost .dev sites.)

(Yes, I know it was never a reserved TLD.)

1: https://code.storage/

Also gitlab has cves like every other week... You're going to be on that upgrade train, unless you keep access locked down (no internet access!!) and accept the admittedly lower risk of a vulnerable gitlab server on your LAN/VPN network.

Even if gitlab is updated fully, you're fighting bot crawlers 24/7.

Step 1.) Stay on GitHub

I think the internet has "GitHub Derangement Syndrome" right now. It's an outlet for people's frustration.

The current trend reminds me a lot of the couple years we had where Game Developers were that outlet. They needed to "Wake up" and not "Go woke, go broke". An incredible amount of online discourse around gaming was hijacked by toxic negativity.

I'm sure every individual has their really good logical reasons, but zooming out I think there is definitely a similar social pathology at play.

I would argue that the open source people aren't the only ones paying attention right now.

If you are hosting proprietary code on Github, it has become clear that Microsoft is going to feed that into their AI training set. If you don't want that, you don't have a choice but to leave Github.

This company either does what it wants to abuse people, or is too incompetent to make their software work as instructed. Both possibilities are bad. I expect the same translates to GitHub.

The WMF is notorious for its donation banners making wildly exaggerated claims about the state of the Foundation (it needs some money to be operational, it is however not by any real stretch of the imagination in financial trouble or losing its independence because it doesn't get enough money; they have a massive endowment that can run Wikipedia for the next 50 years or so, and major corporations already give money to the WMF to keep it in the air, making the statements those donation messages give to regular readers very deceptive), scaring people in third world countries into parting with their meager savings because they are scared of the WMF vanishing through deceptive language and in general their donation drives are extremely intrusive to the respective Wikipedias.

I understand that the Document Foundation just wants to bring donations to the attention of their users, but the WMF is the worst point to compare it to.

They have been breeding bad will and it is overflowing onto others.

That said, the failure of this post to recognise the problem of the WMF approach does not build confidence in the ability to recognise when users might have a legitimate complaint. That leads them to wonder where LibreOffice is headed.

Pretty sure those are completely standard for major changes in maintainers/hostile forks/acknowledging major contributors. I've seen a lot of abandoned MIT/BSD projects add a new line for forks/maintainers being active again in order to acknowledge that the project is currently being headed by someone else.

From my "I am not a lawyer" view, Kludex is basically correct, although I suppose to do it "properly", he might need to just duplicate the license text in order to make it clear both contributors licensed under BSD 3-clause. Probably unnecessary though, given it's not a license switch (you see that style more for ie. switching from MIT to BSD or from MIT/BSD to GPL, since that's a more substantial change); the intent of the license remains the same regardless and it's hard to imagine anyone would get confused.

I suspect (given the hammering on it in responses), that Kludex asking ChatGPT if it was correct is what actually pissed off the original developer, rather than the addition of Kludex to the list in and of itself.

The original author said they were “the license holder”, specifically with a “the”, in discussions around both Starlette and MkDocs, which yes, just isn’t true even after rounding the phrase to the nearest meaningful, “the copyright holder”. This appears to be an honest misconception of theirs, so, not the end of the world, except they seem to be failing at communication hard enough to not realize they might be wrong to begin with.

Note though that with respect to Starlette this ended up being essentially a (successful and by all appearances not intentionally hostile?) project takeover, so the emotional weight of the drama should be measured with respect to that, not just an additional copyright line.

Rather, the purpose of all of these systems (in theory) is to verify that the certificate belongs to the correct entity, and not some third party that happens to impersonate the original. It's not just security, but also verification: how do I know that the server that responds to example.com controls the domain name example.com (and that someone else isn't just responding to it because they hijacked my DNS.)

The expiration date mainly exists to protect against 2 kinds of attacks: the first is that, if it didn't exist, if you somehow obtained a valid certificate for example.com, it'd just be valid forever. All I'd need to do is get a certificate for example.com at some point, sell the domain to another party and then I'd be able to impersonate the party that owns example.com forever. An expiration date limits the scope of that attack to however long the issued certificate was valid for (since I wouldn't be able to re-verify the certificate.)

The second is to reduce the value of a leaked certificate. If you assume that any certificate issued will leak at some point, regardless of how it's secured (because you don't know how it's stored), then the best thing you can do is make it so that the certificate has a limited lifespan. It's not a problem if a certificate from say, a month ago, leaks if the lifespan of the certificate was only 3 days.

Those are the on paper reasons to distrust expired certificates, but in practice the discussion is a bit more nuanced in ways you can't cleanly express in technical terms. In the case of a .mil domain (where the ways it can resolve are inherently limited because the entire TLD is owned by a single entity - the US military), it's mostly just really lazy and unprofessional. The US military has a budget of "yes"; they should be able to keep enough tech support around to renew their certificates both on time and to ensure that all their devices can handle cert rotations.

Similarly, within a network you fully control, the issues with a broken certificate setup mostly just come down to really annoying warnings rather than any actual insecurity; it's hard to argue that the device is being impersonated when it's literally sitting right across from you and you see the lights on it blink when you connect to it.

Most of the issues with bad certificate handling come into play only when you're dealing with an insecure network, where there's a ton of different parties that could plausibly resolve your request... like most of the internet. (The exception being specialty domains like .gov/.mil and other such TLDs that are owned by singular entities and as a result have secondary, non-certificate ways in which you can check if the right entity owns them, such as checking which entity the responding IP belongs to, since the US government literally owns IP ranges.)

The US's quagmire of incoherent laws and many jurisdictions seems to be a bad combination of:

* Apathetic voters that are raised on a media diet of "big government bad", which impedes any regulations on a federal level. (Note that this is irrespective on if the voters actually want a small government, it's what they're led to believe.)

* Politicians that don't like to give up power; there's an unusual desire for local/state US officials to claim responsibility and get very pissy when the federal government steps in with a standardized solution. This is very unusual compared to other countries; punting responsibilities to local officials in other countries is generally seen as a way for politicians to abdicate responsibility by letting it die in micromanagement and overworked administrative workers and isn't popular to do anymore these days. (This is also a two way street, where federal US lawmakers can abdicate making any legislation that isn't extremely popular by just punting it down to the states, even if they have legal majorities.)

* The US has a court system that overly favors case law rather than actual law. Laws in the US are permitted to be painfully underdefined since there's an assumption that the courts will work out all the finer details. It's an old system more designed around the days of bad infrastructure across large distances (like well, the British Empire, which it's copied from). It's meant to empower the judicial branch to be able to make the snap decision even if there's not directly a law on the books (yet) or if a law hasn't actually reached the judiciary in question. The result is that you end up with a bunch of different judiciaries, each with their own slightly different rules. It also encourages other bad behavior like jurisdiction shopping where people will try to find the judiciary most favorable to them, crafting "the perfect case" to get a case law on the books the way you want it to get judges to override similar cases and so on and so forth - in other countries, what the supreme court judges doesn't have nearly the same lasting impact that a decision in the US has.

* And finally, the entire system is effectively kept stuck in place because lobbyists like it this way; if they want to kill regulation, they just get some states to pass on it and then hem and haw at the notion of a federal regulation. Politicians keep it in place on their own, lobbyists provide them the grease/excuse to keep doing it. (And those lobbyists these days also have increasing amounts of ownership over the US media, so the rethoric about voters not liking big government regulations is reinforced by them as well.)

It didn't end up this way on purpose; the historical reasons for this are mostly untied from lobby interests (which is mostly just "the US is the size of a continent in width", "states didn't actually work together that much at first" and "the US copied shit from the British Empire"), but they're kept this way by lobby interests.

Statistically speaking, most people use one of the biggest email providers, which use their own models to detect spam (or even quietly drop messages). If you're doing an unpopular TOS change, why not set the mail up to still be RFC compliant but in such a way where the mail isn't going to be allowed through by any of the providers. Then you can just claim the problem is userside.

For example, the Message-ID header is technically not required (SHOULD rather than MUST), but as a spam detection measure, Gmail just drops the message entirely for workspace domains: https://news.ycombinator.com/item?id=46989217