I can’t remember all the details, but depending on the CPU you are running you may need some extra configuration on opnsense.
There were a few issues, on my servers, running on older Intel Xeon CPUs, but I eventually fixed them adding proper flags to deal with different bugs.
Other than that, running on a VM is really handy.
On nvidia, there are still too many edge cases involving Wayland that are just crippled. Orca slicer doesn’t work for me for example, you are completely missing any of the 3d accelerated graphics in there.
On the other hand, the AMD 7x00 series have different kind of bugs, with ring0 errors leading to full resets.
I think once nvidia drivers are squared out (the proprietary ones) it will be smooth sailing.
It is nice that you got it running, but when everything you end up doing is running services in low ports or needing specific IP address in different networks, rootless podman is just a PITA.
In my case I have one pihole running on a docker container and another one that runs directly on a VM.
Someone said before “what’s the point of running in a container”… Well, there really isn’t any measurable overhead and you have the benefit of having a very portable configuration.
I do think the compromises one has to go through for podman rootless are not worth in this case, for me, not even the rootful worked properly (a few years ago), but this is a nice walkthrough for people wanting to understand more.
I can’t say if you are overstating it but, only mention that I went through a similar path. I had it multiple scripts running and it was a neverending thing.
Since I have moved to small step I never had a problem.
The biggest advantage I got is for products like opnsense, you can do automatic renewal of certificates using your internal CA.
Generating new certs is still as simple (actually much easier for me) than relying on openssl or easyrsa scripts.
Gigabyte is the exception, 3 HDMI and 1 DP
I have dealt with “only works in kubernetes” because developers couldn’t be bothered to make it even work on docker without all the hidden orchestration.
So, instead of documentation, they just make the service work in that one specific environment.
I would argue they are all the same since most are based on wlroots and if wlroots doesn’t support something neither does the “increasing amount of Wayland compositors”.
While I don’t use TPM myself (I dislike being tied to a specific hardware) the way it protects you is:
Disk is protected through encryption, so you can’t remove and inject anything/hack the password.
If boot is protected/signed/authorized only, a random person can’t load an external OS and modify the disk either.
All this together would say, even if someone acquires your computer, they can’t do anything to it without an account with access, or an exploit that works before a user logs.
In a way, the attack surface can be bigger than if you simply encrypted your disk with a key and password protect that key.
You can always compile your own Iosevka and adjust several pieces, I have done that selecting what I consider the best pieces a long time ago.
The compiled font lives in an easy to access internal webserver that I just grab from every computer I use (=
I really love the current trend in R&D PowerPoints
Removed unreadable // Added /* */ on their own lines with fancy design above and below comments
distcc so you can compile on the faster ones and distribute it