Not a fair comparison IMHO - Ethernet is designed to be a connection between two or more otherwise independent peers (on L2), while USB's goal was to allow connecting simple peripheral devices to computers. There was never meant to be a situation where it's unclear which side is the Host.
Also note that the bridging "cable" is literally just two USB devices, one for each computer (although they are both on the same chip, so there's that), with some internal link to pass the data.
You could put your .desktop files in a separate directory and just symlink them to ~/.local/share/applications. If you want to have all your aliases together, you could have a directory like Aliases or whatever and then have Aliases/desktop for .desktop launchers, Aliases/bin for scripts or binaries (and have it in PATH), Aliases/bashrc for your bash aliases (and just put source .../Aliases/bashrc in ~/.bashrc), etc.
Of course everyone has their own opinions on how to organize stuff, but this is IMHO pretty clean for what you probably want to do.
Edit: and to quickly (re)create the symlinks, you could use a bash one-liner like for f in .../Aliases/desktop/*; do ln -s "$f" "~/.local/share/applications/$(basename "$f")"; done - put it into your bashrc as a function and remember to run it whenever you create a new .desktop launcher, and you should be golden.
I don't think that's a similar situation - the Linux kernel lost some functionality there, but in this case Ext2 filesystems are still fully supported by the Ext4 driver, so there's no difference in "hardware" support.
The separate Ext2 driver was being kept for embedded devices with extreme memory or storage limitations where saving some kilobytes by not having all the new Ext3/4 features was useful, but when you can afford the extra memory, there's no reason not to just use the Ext4 driver for all Ext2/3/4 filesystems.
I'm pretty sure all of those entries are in the same /12 network - 172.16.0.0/12. Apparently there's nothing wrong with it, but I think you can significantly simplify that config by just removing all the extra ones
Does UEFI initialize all the cores? I know the OS always starts with only one core available, but I'm not sure if UEFI just disables the cores after it's done its thing, or if it doesn't touch them. Because if it stays on core 0 and never even brings the other ones up, then this issue with core 2 could let it boot this far just fine.
Maybe. To be clear the delay isn't that large (my very rough guesstimate is somewhere between 100 and 300 ms, probably more towards the lower end), and if I just click somewhere on the slider, it feels fine.
It only feels janky when I drag the slider and the screen brightness updates in very noticeable steps. But that is how I naturally interact with sliders, so it's hard not to notice it for me.
It's a very common feature for monitors, at least in my experience - both of my cheap AOC monitors support it, as well as all the other monitors I've ever connected my laptop to (a few HP and Samsung monitors iirc).
But it also feels kinda janky due to how long the display takes to change the brightness, so maybe that's why Microsoft decided not to support it?
Because of the built-in SSD, I could also sell the external SSD and buy an 8-12tb HDD instead.
If you're going for a 3.5" HDD, then you'll most likely have to look for a bit bigger form factor than TinyMiniMicro (Lenovo Tiny / HP Mini / Dell Micro series) - these computers can't fit a 3.5" HDD.
If size isn't a major concern, I'd go for the SFF variants of these computers - they are often cheaper than minis for same specs, but probably have a bit larger idle power draw and take up more space. As a bonus upside, you get some small PCIe slots in these computers, so yay for expansions.
Not really - report your issue on their issue tracker if you can and feel like spending your time on it, then move on (and maybe check back in some time). Flatpak are meant to fix dependency issues, there's not much you can do if they got it wrong for whatever reason.
If it's a Flatpak, then installing anything with APT shouldn't help you at all - it is possible to build a Flatpak that accesses host libraries, but it would defeat the point of using Flatpak in the first place. So your xapp issues are moot anyway.
As to the meaning of the output of apt policy: it says that the most up to date libxapp1 is from Linux Mint repos, and that there's also an older version in Ubuntu repos. That means that Linux Mint doesn't provide a xapp package at all, and the only one you could install is the old one from Ubuntu (which conflicts with the newer libxapp1 from LM)
The APT error is most likely a result of using PPAs - some PPA you use (probably the one with simple64) provides libxapp1 2.8, but doesn't provide happy at all, so you end up falling back to the much older version from your distro's repositories. But xapp needs an exact version of libxapp1, so you get this error.
That said, if the simple64 PPA doesn't provide the xapp package, then it perhaps isn't required and the module should be provided by libxapp1 (and the problem is something different). Or maybe it comes from a completely different PPA - I believe apt policy libxapp1 should tell you where it's coming from.
Are you sure you didn't set DNS directly on some/all of your devices? Because in that case they won't care about the router settings and will use whatever you set them to.
Also as the other commenter said, DNS changes might not propagate to other devices on the network until the next time they connect - a reboot or unplugging the cable from your computer for a few seconds is a dirty but pretty OS agnostic way to do that.