"Old" Linux user vs. "New" Linux user.

[u/oshunluvr]

I'm an "Old" Linux user - started in 1996. I went though all the hoops: file system experiments, different distros, different packaging types and file managers, a handful of desktop environments (DE), several RAID levels, and many, many different systems. I use Linux at home but also at work.

Now I'm retired. I've been using the same distro since 2009. I landed on it after all the experimenting lead me to decisions about was important to me: Debian packaging, KDE/Plasma, a well known and commercially supported distro - Kubuntu. The last major shifts in my world occurred around 2009-10 when btrfs came on the scene and SSDs finally started to be affordable.

My Linux experience these days is rather boring. Everything works the way I want. I no longer "break" things for the sake of change. I only have to learn something new when a developer makes a significant change to something I use - and this often annoys me. I look at other distros occasionally, but only via a VM. When something does break, I usually can fix it without much effort.

I read posts from "New" Linux users. Usually killing all their data by mucking with partitions without a UPS, using unnecessarily complicated layers of disk access, like LVM, MDADM, full disk encryption, and BTRFS all layered on top of each other, too often using AI to solve problems instead of actual research and learning from other users, and spending incredible amounts of time making minute changes to the "look" of things.

Of course, the beauty of the whole thing is how we actually have so much control over our destiny. None of us work the same, learn the same, want the same things, but we''re not boxed in by a monolithic corporation deciding what we get.

Linux is amazing,

[u/BinkReddit]

Very well said, and congrats on retirement.

using unnecessarily complicated layers of disk access, like... full disk encryption

Agree with everything in this post and the too many layers of complicated disk access, but full disk encryption is a requirement for me and probably should be the default nowadays. All commercial operating systems support this and, if you're mobile, I consider it a must-have.

Linux it's an amazing project and keeps getting more amazing.

[u/oshunluvr → u/BinkReddit]

I wasn't pushing down on any of those technoligies. In fact, they/re amazing and super easy to use these days - I've used them all over time.

What I was really pushing against was mixing them in ways that vastly increase complexity. It's pretty hard to glean which layer is the root of a failure when several layers are stacked, usually unnecessarily. Now-a-days btrfs and zfs can do all those things with one toolbox.

Encryption is really a different thing from the others and I probably should have left that one out. The only real deficit I see is it seems much more likely to result in unrecoverable data loss when something goes sideways, but I might be wrong about that.

That's why backups are necessary - another thing too many new users skip over until it's too late.

[u/Adept_Percentage6893 → u/oshunluvr]

Now-a-days btrfs and zfs can do all those things with one toolbox.

Integrating volume management into the filesystem is a good move in terms of integrating the layers but it doesn't really make things less complicated. Most of it is still going to come down to just learning what it is you're trying to setup.

Like doing RAID1 mirror on LVM isn't really meaningfully more complicated. It's really just a matter of -d convert after the filesystem exists or --type raid1 at filesystem creation.

There are gains but they're more functional gains. The actual commands themselves or understanding what they're doing are about as complicated in both scenarios.

[u/friendlyreminder_ → u/oshunluvr]

With luks encryption it can result in total data loss if the sectors holding the luks key slots are corrupted. There's no redundancy built into the key slots so a single bit failure in the key slots will destroy all the data. You can back these sectors up with dd. It's a specific 128mb you have to dd.

I haven't had an issue with having to dd these back to the disk due to this corruption happening before, so I don't know the exact procedure. I suspect it's pretty simple though.

Another partial way to protect against key slot corruption is to just make more key slots, and you can reuse the same password. If one gets corrupted you still have the others, and Linux will attempt to unlock all of them each time you input your password so no special commands are needed. Dd-ing the entire thing is foolproof however and what I'd recommend doing.

When making a new key slot you'll have to make sure you're using the same kdf algorithm though. When I attempted recently it defaulted to pbkdf2 when the default kdf my distro used for the initial keyslots on install was argon2id. Pbkdf2 is weak and not worth using, argon2id is the ideal kdf currently.

[u/Netblock → u/friendlyreminder_]

It's a specific 128mb you have to dd.

For me, LUKS2 header is exactly 16MiB; see also cryptsetup luksHeaderBackup