Which suggests you could work around the issue by editing your kernel cmdline to blacklist the module ucsi_ccg.
On systemd-boot you can do that temporarily to test it by spamming the e key as the system starts up. You'll eventually be able to edit the boot params.
Grub should have something similar but I don't really use that these days.
In theory adding this to your cmdline should block the module from loading:
modprobe.blacklist=usci_ccg
Maybe try a more commonplace distro just to rule out a hardware issue. Try Ubuntu or Fedora's live USBs.
If you're still getting that error, it might be that somehow you're not actually booting into the live USB environment, or something more fundamental to your system is broken.
From what I understand the communication transport is encrypted so it's designed to be secure.
The problem with this however is the sharing of the key. To be truly secure you'd need to share the key securely (i.e. in person), and explicitly trust everyone in that group not to leak the key, so it depends on which group you join and their opsec.
This is all based on my rudimentary understanding though. I am very interested in Meshtastic but UK law is quite restrictive about encrypted radio communication.
Yeah, unfortunately I don't have much choice at the moment. I refuse support platforms that in my opinion have anti-consumer pricing models, and I want artists to get the most money out of my streams, so it's a bit of a catch-22.
Despite claims to the contrary ChatGPT is very accurate with its responses when such responses involve web searches. Where it falls apart is complex multi step things like coding questions.
I make heavy use of it to skip past all the clutter of Google search results and end up with clear summaries that answer my questions. That's all I'd really use it for as anything more than that its output is highly variable in quality.
I've had asthma since I was 7. I've had periods in my life where I've exercised a lot, and periods where I haven't at all. The one constant? My asthma never changed. It's always been a pain in my ass regardless.
I've been using Syncthing-Fork for a while now. It seems to work fine for me, however you do need to launch it occasionally as sometimes it can get killed when backgrounded depending on your flavour of Android.
This is more historical as fortunately I was able to work my way up in my industry over the years.
A little over 10 years ago I was living in my first flat by myself. 90% of my income from part time retail went on rent and bills. What I was left with was £4 a week for all groceries, medicine prescription fees, etc. (Travel I considered to be bills because I couldn't walk to work as it was too far)
I just had to buy the absolute cheapest of everything, bulk deals, etc. Anything I couldn't immediately afford I'd spread over a few months on my credit card.
Anything health related fell off quickly. I never saw the dentist the entire time I was this poor, and I couldn't afford healthy food at all. I'm still paying the price for that now. I swear my teeth are 90% glass at this point.
It was an extremely difficult point in my life, but I needed that freedom and independence and would do it all again if I had to.
I like the concept, but personally I see the decentralised nature of the Fediverse as a benefit rather than a hindrance, and moving all identity functionality to a centralised system would create more problems than it solves.
Suddenly you'll have a single point of failure for the entire Fediverse. A very appetising target for hackers and DDOS attacks.
An alternative that's in the spirit of your idea would be to allow for auth delegation, i.e. if you sign in with an Activitypub ID rather than a plain username, redirect to that instance to sign in then redirect back to the instance you started from, auth token in hand.
The nice thing about this approach is it's basically just OAuth 2. It's familiar, simple to implement and built in to a lot of web frameworks already. The only extra step would be advertising the server's auth URL via the nodeinfo endpoint, which is fairly trivial to do.
Since desktop mode is basically just KDE but without the ability to install software packages you could try Fedora.
They do a version just like desktop mode that has you install everything through the store, or you can get the regular variety to get a bit more flexibility.
Personally I'd steer clear of anything special as your first Linux install. Go with standard Fedora, then you can experiment and branch out if you're interested, but you don't have to if you like what you've got.
I did also find this: https://discourse.nixos.org/t/boot-error-ucsi-ccg-0-0008-failed-to-get-fw-build/27842
Which suggests you could work around the issue by editing your kernel cmdline to blacklist the module ucsi_ccg.
On systemd-boot you can do that temporarily to test it by spamming the e key as the system starts up. You'll eventually be able to edit the boot params.
Grub should have something similar but I don't really use that these days.
In theory adding this to your cmdline should block the module from loading: modprobe.blacklist=usci_ccg