As long as you use an AUR helper to update your system (replace pacman -Syu with yay -Syu), and keep the kernel EOLs in your calendar, it shouldn’t be constant babysitting. Updating a (non -bin) kernel from the AUR requires compiling the kernel, which makes updates take way longer, but doesn’t require extra manual maintenance.

You can find when a kernel is EOL on kernel.org. When your chosen LTS goes out of support, you should update (for security reasons). You’ll have to hope the 580 nvidia drivers still support the newer kernel version you move to.

This path allows you to run your setup for as long as possible on Arch, when you run into issues with nvidia support, so does every other distro.

Unless Arch’s lts kernel switches to a newer lts (in a year or two?), you can run nvidia 580 dkms modules and the lts kernel with basically no maintenance.

After that, you can consider something like linux-lts66 from AUR, or switch to another distro if desired. The first option requires compiling the kernel (no maintenance, just processor time), and will keep your system security patched until the last LTS kernel supported by nvidia 580 modules stops being supported.

Whatever kernel you choose, ensure you have the -headers, like linux-lts-headers. That way, the nvidia-580xx-dkms package can install properly.

If you haven’t yet, look into an AUR helper like yay or paru. These significantly improve quality of life when using AUR packages.

There’s always the option of gathering device info first, then using the appropriate driver. Either the SSD is in a “known supported models” list, or it reports support for whatever feature the new driver needs.

It’s technically possible that straight up trying an unsupported driver can cause physical damage, but this can be avoided by carefully selecting the driver. From MS pov, they’d have to extensively test this driver on a bunch of SSDs and configurations, but it would lead to a performance improvement.

And obviously, there’s been no possible way to try loading the modern driver and if that fails, falling back to the legacy one.

This is once again Microsoft refusing to improve performance, because that doesn’t directly increase profits.

There is a way, but no point in doing so. As such no OSes offer such an option out of the box. For file encryption to be of any use, you need there to be some kind of authentication before being able to access those files (like a password).

The easiest method would be to encrypt the entire drive, as modern Linux and Windows both support using the TPM for automatic unlocking. With that, set up standard user autologin and you’ve made the drive encryption useless.

The version from their F-Droid repo, SchildiChat[f], has no Google libraries. The version from the playstore includes proprietary blobs to support Firebase Cloud Messaging (Google notifications system). Exodus may be misidentifying this as “Google Admob”, which is not present in the app.

No, not really. “Casting” through the netflix app basically just turns your phone into a remote for your TV. The TV still plays videos from Netflix directly, using the Netflix app (or website). Casting using Google or Apple’s solution casts to a proprietary device with all the content protections functional, just like using the app on those devices.

The content protections are bypassed way easier on a computer by using the website and some black magic. The removal/paywalling of casting is purely removing convenience from the user that had barely any financial impact on the company.

Or the service. Software that goes out of its way to ensure you paid, and poses limitations on the paying customer. Like always-online DRM for video games.

The difference is what code runs on your device. If proprietary libraries are included, F-Droid won’t build it, and it’s not allowed in their repository. There’s a lot to say about whether a FOSS app that relies on proprietary network services is truly “free”, there’s no arguing that an app with proprietary code blobs is “free”.

Take for example an app like NewPipe. The application itself doesn’t include proprietary code, but it contacts YouTube, a proprietary Google service. With the app itself being open source, you can tell exactly what it is doing on your device, and what information is sent over the network. Comparing that to something like Signal, which includes proprietary Google libraries, you’d have to decompile and reverse engineer it to try and figure out what it’s doing.

If you have a FOSS library that interacts with Google Play Services or microG to enable FCM, it would (probably) be allowed on F-Droid. (I’m not on their team, I can’t make a definitive statement about this).

“No Google Play services” falls under “app must be FOSS”. The average publicly developed open source app should not have much trouble getting into F-Droid if the developer wants to. Google Play services consists of several components, one of which is a proprietary library included in apps using it. If your app includes proprietary code, it is not FOSS.

If Signal decided a build without proprietary blobs isn’t worth it, they’re not getting into F-Droid. Forks of Signal exist that remove the Google Play services build requirement, those are in F-Droid.

This used to be an issue, but has been resolved in most major applications. Are you on an “app” version of slack? Try updating it, or try using an up to date webbrowser like Firefox, or anything based on Chromium if you prefer.

With either a physical security key (which no “average user” owns), or a damn numeric pin, which is vastly less secure than a password of the same length.

The documentation you were looking at might’ve been the Matrix specification.

There is documentation on how to host a Matrix server, I’d honestly recommend using containers (maybe docker compose) for this one. It can definitely be confusing setting up a service like a Matrix homeserver for the first time.

As for other people finding it, you can (and should) make your homeserver invite-only. It’s also possible to disable federation, which makes the server self-contained. It will not accept incoming connections from other servers, nor make outgoing connections to other servers.

This does mean everyone you want to talk with has to be on your homeserver. There are probably better options available if you want to avoid Matrix’ federation issues, like Spacebar.

To scroll in menus or desktop, sometimes virtual menus for games requiring more buttons

Web push for notifications. Sure, there’s privacy implications, but it’s already near universal. There’s other options like ntfy.sh if you’re not limited to existing infrastructure. UnifiedPush also works well as a protocol for push notifications.

Everything else can be handled in-app. Password reset will have to be done by an admin, though it’s completely doable for a small selfhosted service.

Some of the downsides OP listed may or may not always apply, but there are always downsides. Either you have to set up your own email server (with extra maintenance burden), or your “selfhosted” app suddenly relies on third party infrastructure, like your email provider (or those of other users on your instance).

I’m going to assume you’re unable to see the embedded image. I didn’t add alt text, that’s my mistake.

Below “Besides”, there is a screenshot of a tweet by user @haydendevs stating “this is who you’re arguing with online” and an attached image of a series of dots connected by lines. This is the (overused) visual representation of a “neural network” in machine learning. The meaning of the image in this context is to state you are arguing with bots or AI online. I used this twitter screenshot as an attempt to make a joke of the fact the OP reads like AI-generated text.

I will edit the alt text in my comment above.

MPV is great, I use it all the time. It’s fully replaced VLC on my desktop.

It is not an “alternative to Jellyfin”. It does not offer many “comfort features” like (synced ootb) watch tracking. It does not transcode at all, and it doesn’t even run on devices that need transcoding most, like smart TVs.

These two applications fall into two different categories, and they will never replace each other. One is a media player, you throw mpv any video file, it puts it up on screen, great. The other is a media server, it allows you to sign in, browse your nicely organized library, and click play on the movie of your choice, very cool.

Even the idea of opening SMB or NFS to the entire internet just so your most technical of friends can manually download and watch a movie is insane compared to setting up Jellyfin. Reminder, not everyone has the connection to stream a full 4k bluray rip, transcoding allows those users to watch at all.

Besides,

The RomM project does exactly that

when technical folks act like everyone and their grandma should run arch

As an Arch user, man I hate when people are like that. Arch certainly has a specific target audience. If you (the individual) are comfortable with a distro, and it works well for you, it’s a good option. If Arch isn’t that, then it’s not a good option for you. Some people don’t understand that even the “once a year single command” maintenance is too technical for most.

Having run Arch only the last few years, I don’t know how much it’s improved compared to say 10 years ago. I do know on most of my systems I don’t spend that much time updating or maintaining my Arch installations, usually just a yay, select which AUR packages not to update (the ones I have can have issues updating sometimes), wait for 15-ish minutes (depends how much I have to compile from AUR), and that’s it. From server to desktop, some weekly, others once every couple months. Although I would say it’s more than average, as I have a custom repository with some nightly compiled packages, which has its own issues.

The difference is rolling vs stable release.

Debian 13 is out, and it will stay exactly the same Debian 13 that it was when it released, even 5 years from now. The only changes are bugfixes, security patches, etc. No new features. This means you can basically do unattended sudo apt update && sudo apt upgrade with no problems. By the time Debian 14 comes out, there will have been a ton of changes to upstream software, Updating from 13 to 14 might be a one-click fix, or it might take effort fixing configs and ensuring the new software works.

Arch Linux is rolling release, it does not have version numbers, and does not hold back a major package update just “because it changes things”. This means basically every update might change things, and that can require intervention. If the Arch Linux team is aware of required intervention, it will be put on the Arch News. This is often just one or two commands. The possibility of intervention being required means unattended upgrades are a no-go on Arch, but that’s pretty much it.

If you don’t update your system for say, a year, everything that’s changed in that time will change all at once. This is often still a few commands to fix, but could be more depending on what updated exactly. Updating regularly is reccomended, because it’s easier to tell what exactly changed between updates, and thus easier to track down where a problem originates from.