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.

I’m not sure why they feel it’s Linus’ responsibility to make Rust happen in the kernel.

That’s not what’s being said here, as far as I can tell. Linus is not expected to somehow “make Rust happen”. But as a leader, he is expected to call out maintainers who block the R4L project and harass its members just because they feel like it. Christoph Hellwig’s behavior should not be allowed.

I’m not saying Marcan is necessarily correct, to be clear. It might well be that Linus chose to handle the issue in a quieter way. We can’t know whether Linus was planning on some kind of action that didn’t involve him jumping into the middle of the mailing list fight, eg contacting Christoph Hellwig privately. I’m merely pointing out that maybe you misunderstood what Marcan is saying.

Or fork it and make a Rust Linux with blackjack and hookers, and boy, will everyone left behind feel silly that they didn’t jump on the bandwagon.

That’s what they’re doing. But if you read the entire post carefully, he explains why maintaining a fork without eventually upstreaming it is problematic. And it’s not like they’re forcing their dream on the linux project, because the discussions have already been had and rust has officially been accepted into the kernel. So in the wider context, this is about individual maintainers causing friction against an agreed-upon project they don’t like.

Do you have access to Signal servers to verify your claims by any chance?

That’s not how it works. The signal protocol is designed in a way that the server can’t have access to your message contents if the client encrypts them properly. You’re supposed to assume the server might be compromised at any time. The parts you actually need to verify for safe communication are:

• the code running on your device
• the public key of your intended recipient

My question: How do I actually physically notice the difference between these kernels?

Generally, you don’t. You can look for some benchmark to try and find a difference between them, but if you don’t notice a difference in your day to day tasks, then it’s all the same. In my experience you should pick a kernel based on your desired experience. For my needs this is how the kernels differ:

• Generic kernel: a sane default for most regular users
• LTS: only makes sense if you’re worried about regressions in the generic kernel causing issues, and only viable if you can afford to stay behind on hardware driver updates, ie you use old hardware and/or optimal performance is not required
• Zen: sometimes better for gaming, but often indistinguishable from the generic kernel
• Realtime: rarely what you want, it sounds “faster” but it’s basically optimized for very specific use cases and if you’re not among them you’ll see the same or worse performance

I encrypt all my filesystems, boot partitions excluded. I started with my work laptop. It made the most sense because there is a real possibility that it gets lost or stolen at some point. But once I learned how simple encryption is, I just started doing it everywhere. It’s probably not gonna come into play ever for my desktop, but it also doesn’t really cost me anything to be extra safe.

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.

The sooner the screen stops moving the sooner your eyes can lock on, focus and read.

On the other hand, if I’m reading through a command’s output and searching for something, abrupt movement of the contents make me lose track of where I am and it costs more time to reorient myself than the smooth scrolling animation would take to play out. More importantly (to me), it takes less mental effort as well. It’s just a more comfortable experience. Ever since I switched to neovide instead of plain nvim I find myself enjoying long coding sessions much more.

It sounds like you just might not be negatively affected by the abrupt movement as much as some of us are. You might now get why we care about smooth scrolling because it happens to not do anything for you. That’s fine and a good implementation would allow the user to toggle it on/off based on their needs.

Also you could scroll and end up with half a line visible on the top or bottom, which is just kinda weird and wasting space.

No, I imagine that’s not the way most terminal emulators would implement it. Scrolling would still be done in whole lines, it would just animate smoothly towards the final position rather than jump instantly to it. You would not be able to end up on a half-line or something.

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.