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 think you meant no data cap.
The right thing to whom? Shareholders? (=
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.
To be fair, very few people used to be better at go, let alone a lot better.
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”.
By secure they mean “the only way we can easily see everything you do”
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.
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.