Instead of creating easy-to-navigate help sections of the website, and explaining the product and everything clearly, the flashy vendors simply put everything behind an opaque model as if that's somehow better.
Then you have to guess what to type to get the most basic info about fees, terms and procedures of a service.
You want to see how the Pros are doing it? Well, they're not using any AI! Tesla, for example, still has a regular PDF and a regular section-based manual (in HTML) where you can read the details about your car.
$TSLA is priced as being the most innovative auto manufacturer, and they're clearly proficient with the AI (Autopilot/FSD), yet when it comes to user's manual, clearly they're following the same process as all the legacy automakers always have had (besides not hiding the PDF behind a parts paywall, and having an open-access HTML version of the manual, too, of course). Why? Because that actually works!
I'm sure any removed feature will break someone's workflow, but is DSA common enough to be meaningfully impactful today? I suspect it's past the threshold where only a tiny fraction of users need it, and they're sufficiently covered by running old client versions (ex. in a container).
Often there's a chicken and egg problem in which there is no incentive to update/replace the systems in question until the rest of the world loses the ability to talk to them. I'm glad that OpenSSH keeps pushing the needle forward.
TBH, I never found that answer. I don't know anyone who still uses Mercurial in any way, and it's the exact same GPL license as Git, so, it's not even "nicely" licensed, either.
NetBSD has previously used Fossil-SCM, which is at least a BSD licensed SCM, and at least it has several interesting selling points compared to the rest of the SCMs.
Isn't the selling point of Mercurial, the Subversion compatibility? Who cares about Subversion?
I completely disagree on that part. SVN was a namespace nightmare, the whole repo history was expressly a monorepo (else, all your monotonically-increasing revision numbers would change), there was no per-file revision control whatsoever.
SVN basically had all the drawbacks of both CVS /and/ Git, yet without most of the benefits of either CVS /or/ Git. Subversion was a dead-end however you put it.
I would use either CVS /or/ Git over Subversion any day. I'd rather use CVS than Subversion, and I'm being completely serious here. If we look at the 4 major BSD projects today, half still use CVS, whereas the only one that has switched to Subversion at one point, already migrated to Git, so, it's 0/4 SVN, 2/4 CVS and 2/4 Git now.
I once tried doing a local mirror of Subversion of the FreeBSD tree when they still used it. It was a total failure; it was basically a complete regression compared to the ease with which you can mirror the entire CVS history of any of the other BSDs at the time. It used up WAY-WAY more storage than either CVS /or/ Git. There was no way to selectively mirror things with Subversion, unlike with CVS. (At least Git uses a really smart packing system and compression, so, even if you have to mirror the entire tree, it's still relatively small, compared to SVN.)
CVS is actually very lightweight, simple and flexible to deal with, and the fact that it's still the version control system of choice of NetBSD and OpenBSD, to this day in 2025, proves that it's actually relatively scalable to this day, even for very large projects with a very extensive multi-decade history. Whereas Subversion was so poor that even FreeBSD, an early adapter, moved off of it in 2020.
BTW, for the sake of completeness, DragonFly BSD has completed migration from CVS directly into Git back in 2008 — https://leaf.dragonflybsd.org/mailarchive/commits/2008-11/ms... — that's close to 2 decades ago now — or, to be more precise, just a little over 16 years ago now!
Privatizing hospitals further would not help the vast majority of Americans. Without non-privatization agreements, the average American could not seek or afford the medical attention they need.
As someone that's lived on the Canadian border for the past 20 years, I frankly think we need more regulations. Drug prices in the US are so absurdly high that most terminally sick Americans will happily drive back and forth to Windsor if it means treatment they can afford. It's a testament to America's core dysfunction, something that Canada can somehow get right on their first try but America... well, we struggled to put Shkreli behind bars.
Yup, it's specifically a problem if you simply go to Amazon, and shop GL.iNet based on price.
Their GL.iNet SFT-1200 "Opal" router does NOT have ANY OSS firmware options. It's a great travel router for $35 USD, but, alas, they're basically abusing the OpenWrt trademark by advertising it as an OpenWrt router when it is not.
Luckily, I think most of the other ones do have OpenWrt builds, but, if you're going to install OpenWrt manually, might as well get a different/cheaper router from some other manufacturer, like Cudy or Dynalink, which are also supported by OpenWrt, and are very affordable for the hardware that you get.
Instead of creating easy-to-navigate help sections of the website, and explaining the product and everything clearly, the flashy vendors simply put everything behind an opaque model as if that's somehow better.
Then you have to guess what to type to get the most basic info about fees, terms and procedures of a service.
You want to see how the Pros are doing it? Well, they're not using any AI! Tesla, for example, still has a regular PDF and a regular section-based manual (in HTML) where you can read the details about your car.
$TSLA is priced as being the most innovative auto manufacturer, and they're clearly proficient with the AI (Autopilot/FSD), yet when it comes to user's manual, clearly they're following the same process as all the legacy automakers always have had (besides not hiding the PDF behind a parts paywall, and having an open-access HTML version of the manual, too, of course). Why? Because that actually works!