Not to replace the great advice here but if you can use a distroless image (you likely need to make it yourself) then an attacker would have a hell of a time exploiting your system. When attackers find a weakness their goal is usually to gain access to a shell; distroless images don’t have one. By the time they figure this out (or hopefully before) you should’ve detected their presence.
Also, check your logs regularly. Prevention is good but it doesn’t replace monitoring.
Could it be that the manjaro repos have older versions of the HIP runtimes then what blender 4.0 is built for? Just a thought. Either way I would report it to the blender devs so they can fix it if it’s a bug
For data science, it depends on what GPU you plan to use. If it’s an Nvidia brand GPU, go with Ubuntu or Fedora. I say from personal experience that it is easier to get Nvidia drivers working on Ubuntu or Fedora than on most other distros I have tried. If it is a Radeon GPU, it will work fine on pretty much any distro at all since Radeon does a good job following Linux standard APIs for graphics card drivers, so for Radeon products I would also recommend Debian or Mint (along side Fedora and Ubuntu).
Isolate them from your main network. If possible have then on a different public IP either using a VLAN or better yet with an entire physical network just for that - avoids VLAN hopping attacks and DDoS attacks to the server that will also take your internet down;
If you’re using VLANs then configure your switch properly. Decent switches allows you to restrict the WebUI to a certain VLAN / physical port - this will make sure if your server is hacked they won’t be able to access the Switch’s UI and reconfigure their own port to access the entire network. Note that cheap TP-Link switches usually don’t have a way to specify this;
Only expose required services (nginx, game server, program x) to the Internet. Everything else such as SSH, configuration interfaces and whatnot can be moved to another private network and/or a WireGuard VPN you can connect to when you want to manage the server;
Use custom ports with 5 digits for everything - something like 23901 (up to 65535) to make your service(s) harder to find;
Disable IPv6? Might be easier than dealing with a dual stack firewall and/or other complexities;
Use nftables / iptables / another firewall and set it to drop everything but those ports you need for services and management VPN access to work - 10 minute guide;
Use your firewall to restrict what countries are allowed to access your server. If you’re just doing it for a few friends only allow incoming connection from your country (wiki.nftables.org/wiki-nftables/…/GeoIP_matching)
Realistically speaking if you’re doing this just for a few friends why not require them to access the server through WireGuard VPN? This will reduce the risk a LOT and won’t probably impact the performance. This is a decent setup guide digitalocean.com/…/how-to-set-up-wireguard-on-deb… and you might use this GUI to add/remove clients easily github.com/ngoduykhanh/wireguard-ui
I have a Microsoft Surface tablet and Fedora with GNOME works pretty well on it. I usually use a stylus or the magnetic keyboard with it but when I do use the touch screen I dont encounter issues. I use PaperWM on top of GNOME and it makes it all so easy to use.
I have a NVDIA GPU and no idea what could be the problem here, unfortunately. The only thing that comes to mind is that when you bake textures you need to disconnect the metallic node or turn it to 0, otherwise the bake will be completely black. No idea if this is related but it looks like it might be a problem with reflection?
You tried to uninstall and reinstall the GPU drivers? Are there different versions of the drivers (for NVDIA there are) that you could try?
We use EL (Specifically Rocky, a rebuild of Redhat) for this, but I strongly suspect that any of the main distros will be absolutely fine provided they have modern enough versions of the software you need.
build the image properly, or use good images. This means limit dependencies as much as possible, as minimal images as possible (less updates due to CVEs, less tooling).
do not mount host volumes, if you really have to, use a dedicated subpath owned by the user of the container. Do not use homedirs etc.
do not run in host namespaces, like host network etc. Use port mapping to send traffic to the container.
If you want to go hardcore:
analyze your application, and if feasible, build and use a more restrictive seccomp profile compared to the default. This might limit additional syscalls that might be used during an exploitation but that your app doesn’t need.
run falco on the node. Even with the default set of rules (nothing custom), many exploitation or posts-exploitation steps would be caught, such as “shell spawned” etc.
It’s the de-facto standard for runtime container security (sysdig is based on it). The only competitor afaik is aqua security’s tracee, which is way less mature. It is very well supporter, there are tons of rules maintained by the community and it is a CNCF project used by enterprise solutions (I.e., shouldn’t disappear overnight).
linux
Newest
This magazine is from a federated server and may be incomplete. Browse more on the original instance.