Is it correct that we can resize a partition only by changing the end of the partition, not its beginning, regardless of which tool (parted or not) to use?
Filesystems generally expect that the underlying storage is contiguously addressable, i.e. when the operating system says that a particular disk/partition/LVM logical volume/whatever container is X blocks in size, the filesystem assumes that first block is #0, the last one is #(X-1) and there are no unusable holes in between. As a result, a mounted filesystem can really grow only by having more blocks added to the end, and shrink by having some blocks cut off from the end.
For an unmounted filesystem, the amount of surgery you can do is only limited by how well you (or your utility program) understand the structure of the filesystem that is being modified, and the requirement that the result must again look like a valid filesystem when you're done.
For most partition management utilities, moving the beginning of a partition involves moving the entire partition as a block to the new beginning point, then resizing as necessary at the tail end. A really clever utility might be able to move some files to make space for necessary metadata structures, and then reconstruct the filesystem metadata in a location that corresponds to the new beginning of a partition without moving all the blocks, but such an operation would be extremely risky and would probably cause hopeless filesystem corruption if interrupted.
Is it possible to merge two partitions, without removing them first and creating a new one, regardless of which tool (parted or not) to use?
It depends on filesystem(s) involved, but usually not; the standard method would be to move the files within the partition with less data into the other partition, then delete the now-empty partition and use the freed space to extend the other partition. If there is not enough free space to do that in one pass, it gets tricky.
Is there a recommended ratio of used over total size for the / partition? Specifically, for the / partition (/dev/sda3), its used size hasn't been changed drastically over the past two years, and is now only 21GiB. If I could restart partitioning from the beginning, how much size do you recommend me to specify as the total size for the / partition?
Since your experience over two years shows there's not much change, I'd aim for something between 33% .. 66 % usage level, so anything between 40 .. 60 GiB total size, to allow for plenty of space for upgrades, software installations and the like. Then again, I'm very familiar with Linux LVM so I prefer to use it, as it provides much more flexibility than traditional partitions. (Of course, there is a learning curve.)
Is there a recommended ratio of used over total size for the /home partition?
It depends heavily on what kind of files you handle: if you edit HD/4k videos, you'd have a huge free workspace for projects. Filesystem-wise, I've heard that most filesystems work best when less than about 80% full.
How can I move some of the largely unused space of the / partition (/dev/sda3) to the /home partition (/dev/sda4)?
This will be a multi-step operation, and you'll have to have the filesystem unmounted for at least the 2nd step, so you'd have to boot from a Live CD or other removable media to do it.
Step 1.) Shrink /dev/sda3 to the desired size. (gparted may be able to do this while the filesystem is mounted.)
Step 2.) Move the now-smaller /dev/sda3 "to the right". This will definitely require the filesystem to be unmounted, and since it's your root filesystem, an alternate boot media is required.
Step 3.) Extend /dev/sda4 into the now-freed space.
I don't remember why I left a 93GiB unallocated space where it is. I guess I wanted to allow both/home and / partitions to get more space from the unallocated space if either of them needs to.
You could unmount your /home, then use gparted to move it "to the left" so that the unallocated space will be between sda4 and sda3. Extending sda3 would still be a "boot from removable media, move sda3 left the necessary amount, then extend its tail end" operation.
What if you had used LVM?
Then you most likely would have set up a volume group with just a single LVM PV in place of both sda3 and sda4, and two LVM LVs within it. You could resize them within the bounds of available space. As a result of resizing operations, the LVs on the disk might not be fully contiguous within the PVs, but as long as you don't keep fiddling with the LV sizes too much, a small number of discontinuities is not a problem in practice.
(You might have your original allocation for /home, then your root filesystem, then another piece of /home as you found out you needed more space. The filesystem drivers will see a contiguous range of blocks within the LV; the logical volume manager will deal with the fact that physically there is your root filesystem somewhere in the middle.)
Assuming that the currently-unallocated space was used by something else originally, you could now create another partition out of it, make it a LVM PV, then add that PV into your existing volume group. Then you could use it to extend any of your existing LVs, or to create new LVs as needed.
And when it's time to move your data from an aging disk to a new one, you'd just partition your new disk with any necessary partitions for booting + ideally just one big LVM PV. Then add that PV to your existing volume group, and you'd be ready to move your data to the new disk with a pvmove operation. All that while your OS is running. (As a nice side effect, pvmove will make all your LVs physically contiguous while moving them if there's space to do so - and when moving all your data to a new disk, there certainly is.)
When the pvmove operation is complete, you'd just need to drop the old disk out of the volume group, re-install the bootloader to the new disk, and you'd be ready to physically remove the old disk.
With LVM, you'll come to think of your data as a sort of viscous liquid that you can pour from one PV container to another at will. If one PV is getting full, it's no problem to grab another PV to hold the rest of it as long as both belong to the same volume group.
dd seek), duplicate the partitioning of your disk on it, and practice on it until you understand how the thing works. You'll find an example in a recent answer of mine. – Feb 18 '19 at 17:52