The ups has data output to my firewall/router via usb, which the baremetal servers all connect to via apcupsd. When the ups loses or regains AC power, it broadcasts a message to all of them and they’re each scripted to act accordingly: laptops run on their own batteries, vms migrate over to laptops, non-vital hardware shuts down, etc.
Some laptop battery firmware allows you to force discharge even when connected to AC, and if your laptop can use the tlp recalibrate or tlp discharge commands then yours is supported.
I use this to power my thinkpad servers off of their own batteries during a power outage, to reduce load on my UPS. Great feature.
You can! I registered my first account on ml, and moved to sdf, with a third on world as a backup. You can open one on every instance if you want, or more as individual instance rules permit.
I switched a workstation to Secureblue for the very specific security priorities targeted by that project, but I think for the majority of users, the main reason for not switching to atomic is one you mentioned: why fix what isn’t broken? The main selling point promoted to potential new users seems to be that updates don’t break anything, but I can’t remember a single time since Debian Sarge that an update broke anything for me, and I actually find the rpm-ostree package layering and updating process to be far more of a headache than otherwise.
Unless it’s prepackaged like a steam deck, moving from the traditional way of doing things to atomic is a major change. Like any major change, people need a good reason to make it, and I think right now the only compelling ones are either hyper-specific (switching to okd and needing to build it on coreos, wanting to move to a specific atomic project, etc.), or just general curiosity.
That’s why you can adjust swappiness, or designate a different high-endurance storage device for it.
They might have valid concerns, but when the writeup includes stuff like
the developer of Signal wants us all to beLIEve
it’s hard not to imagine the whole thing hand-painted on the side of a van.
Unless “read-only” is being enforced by hardware (reading from optical media, etc), a compromised sudo user can circumvent anything, and write anywhere. A read-only flag or the root filesystem being mounted from somehwere else are just trivial extra steps in the way.
Improved security != extremely secure, is all I’m saying. There are a lot of things that go into making a system extremely secure, and while an immutable root filesystem may be one of them, it doesn’t do the job all on its own as advertised in this post.
The root filesystem is being read from somewhere, and if it’s being read from, it can be written to. Having an extra step or two in the way doesn’t make it “extremely secure”.
Yes, with the official M16A4 unit being defined as 1/100th the length between the goal lines of an American Football field.