Iproute2 definitely does write things a bit compact. ip address show and shorthands state the routed local address space (192.168.1.x/24) and the actual /32 address (192.168.1.214) you are assigned as one unit. Additionally, it shows the broadcast address for the space. Ironically, ip route show may genuinely give you less confusing information, clearly splitting the actual route and showing your straight IPv4 address as src.

Typically in firewalling, you’d use /32 to target a singular IPv4 host. This is analogous to using /128 for IPv6 hosts. You can absolutely use /24, /16, /8, or any other mask really if you need to target a range of IP addresses for a rule to apply to. Technically, /32 is a range itself, just with a size of 1. There are CIDR calculators available to play around and see what different CIDR masks actually target.

The routing and firewalling is a bit different in terms of why certain CIDR masks are used. For the router, the /24 suffix is usually defined for itself on the LAN interface to denote the address space it may send route information to, and what addresses are controlled by the device. Almost certainly, (unless using a lower CIDR range and actually handing out /24 blocks to subsequent routers,) you are granting /32 IPv4 addresses to your devices from your router.

For your system firewall, 192.168.1.135/24 is identical to 192.168.1.0/24 as they are the same address space. You’re simply allowing from a subnet of hosts to accept from. Given the /24 mask is 255.255.255.0, it does not matter what the last number of the IPv4 address is, but the lowest possible number to match the mask is standard form. Without knowing what rule(s) specifically is being applied, I couldn’t tell you if your firewall rules are something that would affect hostname resolution of other hosts from your system or not.

In addition to the other reply on the fundamentals of why not in general, maybe we don’t recommend daily driving one of DHH’s pet projects.

If anyone is out of the loop of who DHH is, tons of people have covered the topic but I think Niccolò Venerandi has quite comprehensive and digestible coverage. If anyone cares to read or watch Nicco’s coverage.

1 + 2:

There’s not much involved in burning an ISO to a flash drive, booting from it, and installing typically. It is different in booting from one on a Mac. If you have an M-series Mac, you will be restricted mainly to anything with the experimental Asahi Linux kernel. If you have an Intel-based Mac, you should generally be good to go. Whenever booting a Linux installer, you’ll generally be able to check out the system before installing. It’s a good time to check things like backlight brightness and wireless capabilities are working out of the box on your distro of choice.

Accessing the boot menu on a Mac

3:

OpenSUSE Tumbleweed and Fedora are generally good picks. I recommend going for KDE unless you have a strong preference for how GNOME works. As good as the distros are, I generally recommend staying away from distros like Linux Mint (for now) as their implementation of the newer display system called Wayland is not yet complete for Cinnamon. Desktops like KDE and GNOME have functional implementations and will overall provide a solid experience.

4:

You’ll see mixed opinions all over the place with this. Personally, I do sit in the GrapheneOS camp at this point. If you don’t want to purchase a secondhand Google phone, I’d wait and see for the partnered device that GrapheneOS devs are in works with a currently undisclosed manufacturer on.

I’ll repeat the core points the GrapheneOS devs drone on about other Android OSP distributions, but without the hyperbole the devs constantly put in. Yes, e/OS does generally have security problems, some of which stem from the use of microG, and how microG just has to function on the device. It is a trade-off in security for some privacy gained. If you really don’t need anything of Google Play Services at all, you could always go for straight LineageOS without any Google services package installed at that point.

5:

By all means, older laptops can definitely still be functional for lighter or alternative tasks. Even if it’s not a good workstation anymore, could be fun to experiment with. Older phones (especially Android devices) really do have a set lifespan that I’d recommend to stop using them as daily drivers. When the manufacturers stop supporting them, they can be horrifically vulnerable devices as exploits are found over time. You might still get use out of it though without using its networking capabilities. It likely still has functional storage, screen, cameras, etc. If you’re lucky, you might be able to play around with straight Linux projects like PostmarketOS.

For new stuff, Linux-centric vendors can be nice (though a lot of them seem to just rebadge Clevo laptops with a decent markup) as a guarantee of good hardware support. Most business laptops make for good Linux laptops. I personally bought a Framework 13 a few years back and that’s my primary laptop. Though if you want to stay away from United States-based projects, your initial choices are probably a good fit. Additionally, you might lean more toward OpenSUSE than Fedora as well in the same principle.

There does appear to be some level of curve within your bed mesh, but the skew of the bed definitely shows that the bed is not level across the X axis. If you have manual bed leveling, work on the adjustment across the X axis before taking new mesh samples. Mesh compensation will definitely do a decent job compensating for a skew even as large as four layers worth, but the dimensional accuracy of the bottom of your parts will take a good hit printing like that.

If you happen to remember, what DE’s/WM’s did you use back when testing with your NVidia cards (particularly the 2080 and 3070)? I’ve been trying to gauge a lot of differences in DE usability, and driver versions. In my recent testing, one user on Fedora KDE 42 with the NVidia-open drivers with a 4070 have had a nearly-flawless experience that would be pretty much on par with AMD or Intel. Meanwhile a 1080ti user genuinely had major problems with both KDE and GNOME on the same distro with the standard proprietary drivers.

As for how much the average user needs to use the terminal on modern distros, especially with some of the graphical tools available, it genuinely is very little, if any at all. I think there is more of a problem with how many guides written go for the least common denominator approach of straight terminal commands for every tweak or fix somebody might look up. It is to a point where I might start attempting to write a series of guides and/or short-form videos for a lot of the more common ‘how-to’ and frequent problems that many users might encounter, both for GNOME and KDE at least.

More or less yes, minus the copying files back if the operation was successful. You must be careful shrinking partitions as it is very easy to destroy them, and I’d have to guess the partition layout looks vaguely (EFI System Partition (/boot/efi), Boot (/boot), Root (/), …), which would require shrink and move of the partition before or after /boot. If you’re unfamiliar with shrinking a partition, a bit of reading into how it is done for your filesystem will be required. Different setups, ext4, btrfs, lvm, LUKS, etc. will have different requirements.

Checking the /boot size on my Fedora install, I partitioned out a gibibyte for the 3 kernel plus recovery kernel setup, which takes up about 338 MiB in total. Depending on out-of-tree kernel modules and bootloader modifications installed, your initramfs images could be larger. A few things to look for:

• the size of your current initramfs and vmlinuz image(s)
• any kernel modules you needed to install alongside your system (v4l2-loopback, nvidia, realtek, etc.)
• If there are other large files present in the boot partition

If everything there looks fine and/or is necessary, you might need to expand your /boot partition (either reinstall if new system or offline partition shrinking, moving after a data backup if you have personal files you care about).

The Nullobsi fork of Cantata or many other mpd-backed music players are something I can recommend seems to fit what you’re looking for. It supports being able to edit the play queue whilst running a single-track on repeat within it. It does also support fade out and crossfade. The easiest way to obtain it is via its flatpak on Flathub. Cantata can either run an integrated or connect to a system-level mpd server for its backend.