I have a mini PC server that can't be physically locked away from people in the house, because I do not have the ability or space to install a rack and physically secure it.

There is a housekeeper that is sometimes not the same person.

There is a curious child in the house.

The server needs to be rebooted remotely occasionally.

Some disks are removable.

I am not concerned about an APT posing as my maid to steal the key from RAM. It's not part of my threat model.

I do want to know if my UEFI, bootloader or UKI has been fucked with without my knowledge.

Oh look, I guess Neuralink isn't out of primate test subjects after all!

I generally find writing a good role takes longer than doing it manually. Especially as you have to keep testing failure conditions as you think of them.

However, the point is, that once you're finished with the role, you never have to do that process again.

Not if you want to rebuild Not if you want to migrate to a new os Not if you build a second server Not if you move to a newcloud hosting provider

Porting to a new OS or after an update that changes how the software works is about as fast as doing it manually

Maybe it's only one server today, but how many times would you need to rebuild it over the running lifetime?

The killer feature is that having something like ansible lets you kill your darlings, and keep servers aa cattle, not pets.

Manual setup chops isn't a different skill here. I view ansible as a combination setup and documentation. If you're going to figure out how, why not write down how you did it? If you're going to write it down complete with code lines to run, why not script it?

I was going to add that the avatar was already dead, and it was your screaming the troll was talking over, because this is the 30th time you'd heard the ad

It's your 30th boss run. As you fuck up your sixth dodge roll in a row, the Troll picks up your character. He roars over the screams of your avatar as he crushes it's ribs in its massive fist.

Then, as he raises you high over head, and opens wide to chomp down on your head, the actions stops. The Troll turns to the camera and smiles, showing off brilliant pearly whites. "Colgate is recommended by 9/10 dentists.", the troll effuses over the screaming.

A text box appears.

'To proceed, type the number of dentists Colgate is recommended by, followed by this random number "N".'

Mobile Linux isn't ready. It's going to be soon, but it's just not yet.

Key pain points are hardware selection, video acceleration, sleep mode and on-screen keyboards.

Edit: and audio and mobile data/modems...

A lot of these are not developer problems, rather hostile manufacturers, but it makes little difference in the end-user experience.

There's actually two ways to view them, cross-eyed or unfocussed.

Cross-eyed makes you see the negative, the imprint. Unfocussed makes most of them pop out in 3d.

Edit: it is also possible to cross or uncross too much and focus on an image that is distorted

It's like that on Arch, and most everything by default. Standard practice - you often have to allow it explicitly via a group for unprivileged access to write to USB devices.

If you've played with custom keyboards it's commonly an issue there. You wouldn't want just any old program or webpage sending custom firmware to your keyboard!

And there was me thinking that my old google TV remote was just damaged in some way, causing battery drain...

I used to work for an MSP (Managed Service Provider), can confirm. Security is something I had to redirect attention to on a day-to-day basis. Even then, the company was more concerned with appearance and audit compliance than security.

I have worked at IT companies that really did care about security, but those companies were driven by management and staff that personally cared about IT security. One of them was a certificate authority.

Here's a story about physical security from before that time.

I once had equipment in a Data Center that was embedded in the 4th floor of an office building. There was a mantrap at the entrance, designed to prevent you from walking away with the main DC door open, or letting people tailgate in to it. One of the doors of the mantrap was a sliding door, disguised as a bit of the hallway.

The sliding door was locked with a maglock on the thin end, so when it fully closed, it locked and you couldn't slide it open without a key card, from inside or out.

...unless you bumped in to it with your shoulder, which separated the lock and opened the door. Which, after it was figured out (about 1 month), happened all the time. People would get let in to the DC without a card that opened that specific door. (DC security control provisioned the main door was separate from building control, which managed the sliding door).

When they tried to get out later, they'd get stuck in the mantrap, then they'd wait for someone to let them out (pre-cellphones). That person would then show them the trick. This was so common they turned off the forced-lock alarm. This lead to the mantrap being useless, and people propping the DC door open for ease of access when moving stuff in and out.

This was put in place in 2001, and I visited the building last year in 2025, it's still in place today.

It's worth noting that this DC was shared by multiple competitive reinsurers, ISPs and financial agencies. The were no cameras outside or inside, and you could poke most server reset buttons through the rack cages with the ink cartridge of a ball point pen. Not everyone was shown that trick.

Were you able to achieve a satisfactory resolution?

To stave off water damage and rusting when shipping to humid areas.

One dock strike or lost piece of paperwork and it could sit in an unair-conditioned container long enough for the cardboard to disintegrate.

It is an awful waste of plastic, but I expect the return rate for rusted tools 'damaging' fasteners is high enough that financially it makes sense for the company