It's not as bad as it seems. He just doesn't know how valuable working with the provided structure is yet. A lot of innovative thinkers are used to questioning, bending, and tinkering with the rules. He's just still learning how necessary the existing structure is.
He accepted Linus's needs as the project head to keep order. He resubmitted the patch set without the contentious parts. It's less than 1/3 the size and doesn't touch code outside of bcachefs. Problem solved.
Honestly, Kent seems pretty reasonable (though impassioned), and bcachefs well probably make it, and Kent will get used to just submitting things at the right time in the cycle.
Honestly, it's pretty normal for Linux. It'll fracture until it becomes glaringly obvious that there's a problem, and then it'll get standardized, and the standard may be supported in the next version.
Ubuntu could have gone flatpak. They didn't. Kde and gnome could have come to a common agreement about desktop-related stuff they have in common. They didn't. So it goes. The real pain points eventually get fixed.
If I understand correctly, Wayland does provide better desktop security. At least two of the common issues are tied directly back to that.
Screen sharing apps, which need to access what one or more other apps are showing, and screen readers for the deaf, which need to access what text other apps are displaying.
Wayland intentionally recuses itself of these problems. That's understandable, as these problems aren't specifically in the realm of a display protocol. However, this has led to some significant problems.
Specifically, since there is a power and implementation void, and the Wayland crew haven't stepped in or endorsed any particular way to fill it, each compositor/desktop library is now implementing it's own means to achieve these ends. This leads to other problems.
You want to write software for X for some of these things, and regardless of the DE you're working in, there are more fundamental ways to address the information you need. But if you want to do so with Wayland, there's no "fundamental" layer to reach for, because it's handled by the DE compositor and toolkits.
So you need to do it the KDE way, or the Gnome way, or the wlroots way, etc etc - and what if you want it to work with all of them? Simple: just code it multiple times and deal with multiple different frameworks, each with their own learning curves, restrictions, and quirks.
..by which I mean, "/s, jk jk, not actually simple."
Really, my hope at this point is that maybe kde/plasma and gnome will standardize around wlroots (i.e., there is no hope).
So, failing that - maybe a single library for accessibility that does the work once (multiple times, but once), and is adopted and used by kde/gnome/wlroots, and a single library that does the same for display sharing.
Even then, is that a documentation and centralized standards issue? Was there some list they could have/should have looked to that said 'this is how that is implemented on Wayland vs X'?
Verify the device path for your normal boot disk and for your new drive using gnome disks or similar. In this example I'll call them /dev/olddisk0n1 and /dev/newdisksda
really, really don't mix up the in file and out file. In file (if) is the source. Out file (of) is the destination.
or, of you want a progress indicator: sudo pv /dev/olddisk0n1 > /dev/newdisksda
wait a long time
Not that this is the recommended method if you're new to the terminal, but it's totally viable if you have limited tools or are comfortable on the command prompt.
Unless you're using three new disk on the same system, you don't have to worry about UUIDS, though they will be identical on both drives.
Your system is likely using UUIDs in fstab. If so, you don't have to worry about fstab. If not, there's still a damned good chance you won't have to worry about fstab.
To be sure, check fstab and make sure it's using UUIDs. If it's not, follow a tutorial for switching fstab over to using UUIDs.
This is a hilariously solid take.