Having figured it out myself, I agree. And it's not obvious that you need both a Usenet _indexer_ (who tells you what content is available) and a Usenet provider (who actually serves you the content).
FWIW, and I'm not sure if this is against terms here, but I use newsgeek for the former and giganews for the latter. Both are paid services but reasonably priced imo. When I can find something on Usenet, it typically downloads with speeds > 10MBps vs. torrenting which can exceed that but is usually much slower.
You can use whatever client you want. I have the *arr stack mentioned elsewhere in this thread as well and SABnzbd is the recommended option there.
Between you and your provider the downloads are over HTTP. The distribution of content between the Usenet providers is over the Usenet protocol which predates HTTP and the WWW.
The Wi-Fi radio's firmware has to have special support for communicating via AWDL while staying connected to an access point. The blog post does say that they plan to expand support to other devices, though.
Fedora makes it pretty approachable, and some distros (e.g. Nobara, Bazzite) just straight-up ship the driver.
IMHO, stuff is moving fast enough in the Linux gaming world that any distro built around taking its time to update things (i.e. Debian, Ubuntu, Mint) is liable to be a bad time. Anecdotally, I've found that redirecting new users interested in gaming away from those distros has dramatically improved their satisfaction.
Graphics drivers are near the top of my list of issues I've had with Ubuntu. I've been using Linux for well over 20 years and Ubuntu (and to a large degree, other Debian derivatives) is just such a pain in the ass to install and configure. It is superficially a good UX in the sense that if you can somehow manage to stay on the happy path, it's smooth, but go an inch off of that and you're in for a world of pain.
It had the potential to be a great replacement if it just worked™ like SMS/MMS (well, MMS was also quite fickle back in the days), given it's so brittle across devices even on the same OS, with little means of troubleshooting by end-users and even less from non-tech savvy users, it's kinda dead in the water.
I understand what RCS is and I don't understand why it matters.
Everything about the concept of a phone number is confusing to me. It's a string of digits that if someone guesses, they can activate the most active notification your phone has (ringing), at any time, no matter if you know them or not. Better yet, depending on your notification and MMS app settings, they might be able to make a dick pic appear on your lock screen on a whim - big spammers of this seem to get marked by the carriers and apps pretty quickly, but for a more targeted one off, still easy.
As opposed to tcp/IP based chat apps that basically require a bilateral human-initiated handshake before someone can message you...
I do receive occasional spam on WhatsApp, Telegram and Signal. Besides the operator spam (try our shiny new AI feature!)
Tying and account to a phone number is a privacy nightmare.
I guess Facebook/Meta does it for easier social graph extraction/profiling, while Signal tried to hand of verification to precent spam.
But for the sake of this argument, we may just assume all of them are evil.
It literally is Google-only. The RCS backend theoretically could be provided by carriers, but they've all chosen not to do that, so the actual service is provided by Google. No matter what the specification says, in reality it's a Google service running on Google's servers.
To put it another way, Google can't kill SMS short of literally removing the app from Android because it's not their infrastructure, but if they shut off their RCS servers tomorrow, it would be dead for good. That's a Google-only service.
It's sad to see so many people are blinded by this. The current situation of RCS is just that Google saw Apple disguised iMessage as SMS and wanted to do the same. RCS is merely a vehicle for Google.
They could just layer their own chat platform on top of Google Messages but we all saw how Google's IM business went along: Chat, Hangouts, Alo, Meet etc. So they muddied the water so deep (to a carrier level) to make it look like it's Apple's issue for not adopting RCS. And people actually fall for it.
Nobody wanted RCS. Even carriers don't want to maintain RCS. They just use Jibe. And that's exactly what Google wanted. My RCS communication with friends don't even show up in carrier's usage. How is that ever different from iMessage...
You know who chose to selfhost their own RCS server? Yes, Chinese carriers! They call it 5G Message. New ad delivery channel for businesses hooray! Instead of plain text and a link, now your campaigns can even have MENUs inside! I can send SMS to a Chinese number, I can send iMessage to a Chinese number, but I can't send RCS. Truly "Universal" profile.
I agree with all of this except for the claim that "Google wanted this". I think Google is as annoyed with this situation as everyone else. They would've preferred to have their own iMessage alternative, but they launched a dozen which all failed, so they went "Well, we can't make our own that people want to use, so let's get the carriers to make an upgraded version of SMS". And then the carriers didn't want to do that but the "it's decentralized!" message stuck with users and even a few governments, so now RCS is the worst of all worlds: it's a de facto Google service, but with a janky, half-baked decentralized protocol, where Google has limited capability to improve it compared to a native Google chat app.
Right, and does that use Apple's servers? This is a rhetorical question, we both know it goes through Google, both literally and figuratively. Google effectively controls RCS - if Apple just implemented RCS 'per spec', it would not work. So, there is no spec, it's as if it doesn't exist. That's how that works.
It really isn't. SMS did not support adding random mobile numbers to a group chat and blasting them with spam. Someone needs to either fix RCS properly for current day use-cases or it just needs to go away.
You are right that WinForms and MVC have been around forever. However, Microsoft has continuously told devs that they are the past. So, you would be forgiven for expecting them to go away.
WinUI is the current official desktop paradigm and it is basically UWP from an API point of view. So the idea that UWP went away is not 100% accurate either.
Microsoft does not really abandon their UI tech like people say they do. But look how many different frameworks they have.
All of the above is Windows desktop only. There are a completely different set of UI technologies for the web.
UNO Platform (Open Source) allows you to use the WinUI API to target almost anything.
.NET MAUI is the official "cross platform" UI tech from Microsoft. It is what you use to target iOS and Android. As a bonus, you can target macOS and Windows too. On Windows, it uses WinUI. You will notice that the Linux desktop is missing from that list.
Here comes Avalonia to build MAUI on top of the Avalonia framework. This adds Linux and WASM to the list of platforms that MAUI will run on. Adding Linux is awesome. A lot of people have wanted that and it really completes the MAUI cross-platform story.
Adding WASM is neat but MAUI was never meant to target the web. If you use it for that, it is literally just the modern version of Silverlight. But Microsoft did not design it for that at all. It is just a back-end that Avalonia supports.
MVC is a design pattern, ASP.NET MVC is a framework that used MVC as its go to pattern. But MVC is not in any way only ASP.NET MVC. There are plenty of other UI frameworks that use MVC and the Wikipedia article lists a lot of them for example: https://en.wikipedia.org/wiki/Model%E2%80%93view%E2%80%93con...
I like WPF and I code with it regularly, but the drag and drop UI builder was the worst aspect of WPF and generated terrible Xaml that was almost impossible to maintain.
