Containers are not a security barrier. They cannot be, they never will be.
Not entirely true. If you’re hosting multiple game servers on one machine, for example, it’s best to run each instance in a container. Game servers, by their nature, are required to have public IPs and ports, and some of them run on old engines that are vulnerable to various DoS methods. If your server is attacked, it might crash the container(s), but it can’t bring the whole server down.
Very true. There are only ~65K ports. If someone decides they want to, trying all of them to see which one gives a valid response is trivial.
In general, shared accounts/credentials aren’t recommended; each user should have their own account. Even in a homelab setting, the audit trail may prove useful in ways that are difficult to foresee.
In general, separation of privileges is recommended. However, the granularity should be informed by the risks mitigated. In an enterprise setting, more risks are generally mitigated by more granularity. In a homelab setting, there are diminishing returns. A risk assessment will determine the appropriate configuration in your environment, but in general, if the scope or severity of an incident wouldn’t be substantially lessened, it is better to accept the risk than to mitigate it.
It sounds like your issue might be a bad ribbon cable, connector, or some other easy fix. Getting the display working might be doable with reasonable effort. If not, you can make it a:
Minecraft (or any game you like) server.
Steam remote play host machine. Let the laptop do the processing and send the video signal to a lower-performance client.
Load movies onto an external drive. Load emulators onto the hard drive. Use it as a media PC and emulation station.
Video editing machine.
Either way, make sure whatever screen you hook up to it has at least a 60 hertz refresh rate.
If you stream, a lot of streamers use a second machine to record, manage the stream, run the webcam, etc. allowing their main machine to prioritize rendering the game; you could use it for that.
Well, it’s IT, so the answer is always a big ol’ fat, “It depends!”
Ostensibly, the primary reason for RAID is in the name: redundancy. Of course, there’s RAID 0, which is for performance, but that’s kind of a different thing that doesn’t seem to apply here. The main risks it mitigates are those associated with drive failures.
RAID isn’t, and should’t be considered, a substitute for backups. But, backups can be a substitute for RAID in some situations. If you simply want to avoid losing data, the right backups solution can do that for you, but your time to recovery will be longer; rebuilding a RAID disk from parity is much faster than restoring a backup from scratch.
So, if you want, you can RAID some disks, partition space on those disks and store your important data on the RAIDed partition. The rest can live on backed up but un-RAIDed disks. It’s really according to your specifically desired recovery time and risk appetite for that data.