The system will be secure for personal use as before.
I wouldn't be so sure of that. CPU side channels allow data to be leaked across security contexts. For example, from a user process to sandboxed JavaScript in a browser, from kernel space to user space, or from one containerized process to another. This is a problem even on a single user system without any VMs.
While ZDI reported the vulnerability to the Exim team in June 2022 and resent info on the flaw at the vendor's request in May 2023, the developers failed to provide an update on their patch progress.
Yikes. Sitting on a critical RCE in internet exposed server software for a year. That's a great way to destroy trust in a project.
Some Chromebooks are pretty hackable. I've got an older one that I reflashed with tianocore UEFI firmware. It makes for a pretty decent cheap and lightweight low power laptop. You can run basically any standard ARM Linux distro on it.
Looks like it's got a jam. Did you reduce retractions with the direct hotend? If not, you are probably retracting way too far, which will cause filament to solidify in the cold area and jam up.
The architecture is a bit different than octoprint. Fluidd and mainsail are purely client side UI's, while Moonraker provides the server side API for them to connect to. So any additional functionality would need to integrate with Moonraker - not Fluidd/Mainsail.
A lot of functionality that is plugin based in octoprint is core to Moonraker and fluidd/mainsail. Things like cameras, mesh bed tools, gcode viewer, UI layout customization, power device control, etc are all included.
Spool manager is not something I've personally needed or used, but this would probably be a good option: https://github.com/Donkie/Spoolman
I highly recommend switching to fluidd or mainsail. They don't require any more CPU power than octoprint (possibly a bit less, actually). They are more modern and polished interfaces than octoprint.
You could maybe do some tricks with one of the variations of locate - such as mlocate or locate. There are options for the updatedb to index specific paths and store in the specified database. If you store a separate db per drive, a bit of scripting to loop through all DBs would let you search them all.
That's much easier said than done. For game developers that already have games based on unity released or in development, changing to another engine is an expensive and time consuming development effort.
What are you comparing it to? I'm pretty sure vnstat is using the raw.interface counters. This would include all protocol overhead. I would expect it to be higher than, for example, an application level counter.
Things like taking screenshots and setting wallpaper actually do have a standard API. That stuff is just part of xdg desktop portals and not the core Wayland protocols. If, for example, a screenshot app uses the org.freedesktop.portal.Screenshot API then it should work with any compositor (as long as the compositor follows the API standards).
If you are familiar with the concepts and are looking more for the specific details, you can probably go a long way with official docs (iptables, nftables, kernel), the arch wiki, man pages, and some hands-on.
Adding a wireframe modifier is pretty simple - I'm sure you'll do fine with that.
If you want to get into modeling in blender, I highly recommend the donut tutorial series by blenderguru. It's on YouTube.