All good, but I think it's really often a misconception that a DE like KDE, which is big and brings tons of features, must be more ressource intensive than a (feature wise) smaller DE. Which, as the benchmarks show, is surprisingly not the case.
I counted 68 so far, but I fell asleep in between, so I may have missed some. I am also starting to believe, the cats just go back inside to jump out again.
It would be weird if the protests had a big effect on the predicted votes. Who would be all for the AfD and then suddenly go "yeah well, I changed my mind now"?
The protests should mainly convince the government to finally start the process to ban the AfD.
Where comments are useful most is in explaining why the implementation is as it is. Otherwise smart ass (your future self) will come along, rewrite it just to realize there was indeed a reason for the former implementation.
As with every software/product: they have different features.
ZFS is not really hip. It's pretty old. But also pretty solid. Unfortunately it's licensed in a way that is maybe incompatible with the GPL, so no one wants to take the risk of trying to get it into Linux. So in the Linux world it is always a third-party-addon. In the BSD or Solaris world though ....
btrfs has similar goals as ZFS (more to that soon) but has been developed right inside the kernel all along, so it typically works out of the box. It has a bit of a complicated history with it's stability/reliability from which it still suffers (the history, not the stability). Many/most people run it with zero problems, some will still cite problems they had in the past, some apparently also still have problems.
bcachefs is also looming around the corner and might tackle problems differently, bringing us all the nice features with less bugs (optimism, yay). But it's an even younger FS than btrfs, so only time will tell.
ext4 is an iteration on ext3 on ext2. So it's pretty fucking stable and heavily battle tested.
Now why even care? ZFS, btrfs and bcachefs are filesystems following the COW philisophy (copy on write), meaning you might lose a bit performance but win on reliability. It also allows easily enabling snapshots, which all three bring you out of the box. So you can basically say "mark the current state of the filesystem with tag/label/whatever 'x'" and every subsequent changes (since they are copies) will not touch the old snapshots, allowing you to easily roll back a whole partition. (Of course that takes up space, but only incrementally.)
They also bring native support for different RAID levels making additional layers like mdadm unnecessary. In case of ZFS and bcachefs, you also have native encryption, making LUKS obsolete.
For typical desktop use: ext4 is totally fine. Snapshots are extremely convenient if something breaks and you can basically revert the changes back in a single command. They don't replace a backup strategy, so in the end you should have some data security measures in place anyway.
What exactly do you mean? Typically you go to a website, register the domain, setup payment and then setup the nameserver. No need to install anything on your end.
Same with hosting. You sign up, setup payment, order a machine (root or virtual) and then you get SSH credentials and are good to go.
Ah one of those endeavours where an executive thought "well, it can't be that hard. We will do it better and cheaper and reap the profits". Just to be hit with reality.
Typically the point of de-googling is to get independent. If you just go to another SaaS solution, you trade one dependency for another dependency. They can lock you out from one day to the next, increase their prices, change their terms of service, etc.
Also if one of the reasons to turn your back to Google is that they should no longer have access to your data, then look up what the SaaS provider you are turning to is hosting with. Chances are high they are using Google Cloud Platform, Amazon Web Services or Microsoft Azure. So your data still ends up on machines of the big three.
All good, but I think it's really often a misconception that a DE like KDE, which is big and brings tons of features, must be more ressource intensive than a (feature wise) smaller DE. Which, as the benchmarks show, is surprisingly not the case.