AWS has multiple teirs of storage options in s3, some replicate and some dont. by default those that do replicate do so in multiple availability zones, but not across regions. unless you turn on cross-region replication (CRR) which is an additional charge.

So, for example without CRR if your bucket is in us-east-1 and 1 availability zone goes down you can still access the data, but if all of us-east-1 is down, you cannot.

the thing about Recaptcha is that it didn’t always gate keep a google provided service, so that logic doesn’t really work. i agree though that we all benefit from less bots.

just a small correction, /etc does get snapshotted when upgrades happen and will roll back along with everything else. you are correct though that home does not get snapshotted and is fully mutable.

I don’t have an answer to your nvidia question, but before you go and spend $2000 on an nvidia card, you should give the rocm docker containers a shot worh your existing card. https://hub.docker.com/u/rocm https://github.com/ROCm/ROCm-docker

it’s made my use of rocm 1000x easier than actually installing it on my system and was sufficient for my uses of running inference on my 6700xt.

Immutable isnt really the best word for these distros. Its why fedora is changing the name to atomic, as in changes made to the system are done atomically like git. This also means changes can be rolled back just as easily as they were made.

The trick was to install VSCodium from the Toolbox

Another option you can try that I use is the dev containers extension which allows you to move your workspace to different containers from within vscode. I will say however, i have tried many times to get it working in vscodium and have been unsuccessful and it only seems to work in vscode proper.

With fedora atomic, lets say i wanted to try out kde desktop for a while. i would first pin my current build so i can roll back to it if i dont end liking kde with

$ sudo ostree admin pin 0

Then i would rebase to the kde branch with

$ rpm-ostree rebase fedora:fedora/39/x86_64/kinoite

Then just reboot. That’s literally it and i would have a kde system with all my layered packages and i could roll back to my old system at anytime.

all changes in etc are snapshotted with each update so you could just roll back to your previous version and it would fix it.

I assume you meant you messed up permissions in your home directory, and yes that is pretty much the only place you can permanently mess something up with silverblue.

honestly i feel exactly the opposite, I don’t think it’s really necessary for servers as tools like ansible are already well established in that space. Plus most servers are VMs these days which can be snapshotted easily. Also, lot of these “immutable distros” require a reboot to apply changes which is non ideal in a server, but a non issue for desktop as you can shut it down when you go to sleep.

I run fedora atomic on my desktop and laptop because i never have to worry about my system getting into a broken state, I can always roll back or even spot the problem and fix it before i reboot to apply the change. I know a lot of people say you can accomplish the same thing with btrfs snapshots, but that requires extra thought and effort on my part, where fedora atomic it happens automatically with every update.

what issues have you had with libvirt and windows? Once you get the windows drivers installed, it works pretty much the same as other solutions. only thing thats still a pain in the ass still is shared folders.

No, it’s because the windows scheduler literally cannot handle that many cores. it simply does not know how to allocate work effectively.

my info could be out of date on this, but the last time i looked into it, the khadas vim3 was the most powerful arm sbc with mainline linux support.

i had a similar issue when rebasing to kinoite, the libvirt service wasn’t set to start on boot after, so check to make sure it’s actually running.

ah yes, Linux clipboard documentation: https://developer.android.com/develop/ui/views/touch-and-input/copy-paste

I have literally never had any upgrade issues on debian that wasn’t something mentioned in release notes(been using it since debian 7). I am guessing you did a lot of things they tell you specifically not to do on this page:

https://wiki.debian.org/DontBreakDebian

don’t forget to thank climate change as well

depends on how many services you plan on running, i think the i3 would be sufficient for what you listed, the i5 would give you room to grow.

the i7’s usually aren’t worth it for servers since they are just a clock speed increase.

Migrations take time, it was never going to be a flick of a switch. Reddit content will slowly get worse and worse, and Lemmy content (or some other competitor) will get better and better as more people move. it’s those core users that generate great discussion that matter the most and those people are looking for somewhere else.