distcc so you can compile on the faster ones and distribute it
distcc so you can compile on the faster ones and distribute it
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.
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 (=
Removed unreadable // Added /* */ on their own lines with fancy design above and below comments
There are a few ways to do it, but you don’t use caddy for SSH.
Last option is how I run my Gitea instance, authorized keys is managed by gitea so you don’t really need to do anything high maintenance.
~git/.ssh/authorized_keys:
command="/usr/local/bin/gitea --config=/data/gitea/conf/app.ini serv key-9",no-port-forwarding,no-X11-forwarding,no-agent-forwarding,no-pty,no-user-rc,restrict ssh-rsa PUBLICKEYHASH
/usr/local/bin/gitea:
ssh -p 2222 -o StrictHostKeyChecking=no git@127.0.0.14 "SSH_ORIGINAL_COMMAND=\"$SSH_ORIGINAL_COMMAND\" $0 $@"
127.0.0.14 is the local git docker access where I expose the service, but you couldn’t different ports, IPS, etc.