Right, so this is exactly the sort of “benefit” I never expect to see. This is not something that has happened to me in ~25 years of computer use, and if it does happen there are better ways to deal with it. Btrfs and zfs have quotas for this, but even if they didn’t it would not be worth the tradeoff for me. Mispredicting the partition sizes I’ll end up needing after years of use is both more likely to happen and more tedious to fix.

Are you going to dual boot? Do you have some other special requirement? If not, there’s no reason to overthink partitioning in my opinion. I did this for my main NVME:

• Partition table: GPT
• /boot : 1GB fat32 partition. Depending on your needs (number of kernels, initramfs’s, other OSs) you might be fine with 500MB or even less. But because resizing can be a pain and I have the space to spare, I would much rather overprovision.
• / : LUKS2 partition containing a btrfs filesystem with all the remaining space

I use a swap file so I don’t use a swap partition. If you want more control over specific parts of the filesystem, eg a separate /home that you can snapshot or keep when reinstalling the system, then use btrfs subvolumes. This gives you a lot of the features a partition would give you without committing to a specific size.

This is the only partitioning scheme I have never regretted. When I’ve tried to do separate partitions I find myself always regretting the sizes I’ve allocated. On the other hand, I have not actually seen any benefit of the separation in practice.

That sound weird to me. How big is the population of people who are technical enough to even check what certificate provider you are using but ignorant enough to think that let’s encrypt is bad because it’s free?

Who’s gonna come at me with a $5 wrench because they really want my data, though? The attack I’m most likely to experience is someone stealing my laptop while I’m out traveling. That’s what full filesystem encryption solves best.

Take notes, CS2!

It is copyright infringement. Nvidia (and everyone writing kernel modules) has to choose between:

• using the GPL-covered parts of the kernel interface and sharing their own source code under the GPL (a free software license)
• not using the GPL-covered parts of the kernel interface

Remember that the kernel is maintained by volunteers and by engineers funded by/working for many companies, including Nvidia’s direct competitors, and Nvidia is worth billions of dollars. Nvidia is incredibly obnoxious to infringe on the kernel’s copyright. To me it is 100% the appropriate response to show them zero tolerance for their copyright infringement.

These are terrible sources. 3 random CVEs and opinions of randoms on the internet. The “sources” conflate arguments about systemd as an init system with the non-init parts and with criticisms of Poettering, and a lot of it is “this is bad” with no argument or, worse, incorrect arguments. If there is anything in there that actually proves something, link directly to it. I’m not going to shift through mountains of garbage to find it.

systemd is insecure, bloated, etc

[Citation needed]

If a distro that doesn’t use systemd ends up booting much faster or being much easier to configure, maybe those are features you care about. But switching away from systemd in this case is merely an implementation detail. What you’re really doing is moving from a distro to another one that serves you better.

Otherwise, the choice of init system has very little impact to the average user. Maybe it’s worth it to switch init systems if you hate the syntax of unit files and/or the interface of systemctl/journalctl and you use them often enough to warrant the effort. The people who want to use alternatives to systemd without having such a practical issue with it are doing so for philosophical reasons.

I don’t think Linux literally waits for you to unmount the drive before it decides to write to it. It looks like that because the buffering is completely hidden from the user.

For example say you want to transfer a few GB from your SSD to a slow USB drive. Let’s say:

• it takes about half a minute to read the data from the SSD
• it takes ten minutes to write it to the USB
• the data fits in the spare room you have in RAM at the moment

In this scenario, the kernel will take half a minute to read the data into the RAM and then report that the file transfer is complete. Whatever program is being used will also report to the user that the transfer is complete. The kernel should have already started writing to the drive as soon as the data started being read into the RAM, so it should take another nine and a half minutes to complete the transfer in the background.

So if you unmount at that point, you will have to wait nine and a half minutes. But if you leave it running and try to unmount ten minutes later it should be close to instant. That’s because the kernel kept on writing in the background and was not waiting for you to unmount the drive in order to commit the writes.

I’m not sure but I think on Windows the file manager is aware of the buffering so this doesn’t happen, at least not for so long. But I think you can still end up with corrupted files if you don’t safely remove it.

Out of curiosity, what distro was this on?

It’s not just you. The DEs themselves generally don’t mess with each other much, beyond possibly messing with each other’s settings. But I’ve seen the the package post installation scripts cause issues. So it depends on the distro I guess.

The same people saying that this is good are also mocking X and threads for losing users.

These are not comparable. X and threads are businesses which maximize their profits by making their platform as big as possible. That is not true for Lemmy and even if it were, the average user does not care about the platform’s profits. So you can in fact make fun of the failures of big companies while being happy being part of a much smaller platform.