I invite you to re-read the second paragraph of my post.
You're just throwing things I already listed back at me. I mentioned a staging environment, I mentioned a schedule was a (bad) option.
remram
joined 4 years ago
Is there anything about staggered upgrades and staging environments in there? Because obviously I had read it before posting...
No, I'm asking how to have unattended-upgrades do that.
... and feel endless pain from whatever they did to the scrollbars. Seriously, wtf.
I don't know, I recently got a 2-in-1 laptop, and was surprised to see that KDE works great. Got Onboard as on-screen keyboard. Screen rotation works great. Glad I didn't have to run Gnome on that machine.
There's focalboard (if you can get past the weird license): https://www.focalboard.com/
Or you can use Gitea: https://gitea.io/ It's mostly meant for collaboration on source code but it has a ticketing system with boards.
Hard disagree there. It is a tunnel, it is plenty fast if the intermediate node is close enough, and why would you want encryption at the IP layer.
It works great and gives me IPv6 that I otherwise wouldn't have with my ISP (Optimum), allowing me to connect to native IPv6 site and use all the IPv6 functionality I want (dedicated IPs for containers/VMs etc).
How many real teachers per student though? Is this just an excuse to have even less human support, because "we have 10 AIs per student"?
What does a ratio even mean in this case, the AIs are not separate.
It's called "bcachefs"
Maybe I'm not being clear.
I want to stagger updates, giving time to make sure they work before they hit the whole fleet.
If a new SSH version comes out on Tuesday, I want it installed to 1/3 of the machines on Tuesday, another third on Wednesday, and the rest in Friday. Or similar.
Having machines update on a schedule means I have much less frequent updates and doesn't even guarantee that they hit the staging environment first (what if they're released just before the prod update time?)