This is good advice in general. Think of it like penetration testing. You really should verify what you can actually access remotely on a device and not assume you have any level of protection until you’ve tried it.

Log files can also contain signs of attack like password guessing. You should review these on a regular basis.

I was hoping for FreeBSD.

Docker performs some syscall filtering as well which may reduce the kernel attack surface. It can be pain to set up services this way, but it could help frustrate an attacker moving laterally in the system.

Processes in the container cannot see external processes for example as I think interested the OP.

Grub rescue should come with a hug or maybe a nice picture of a landscape.

Bugs come in through open Windows.

The joke is that the system requirements for Linux can be effectively nothing, but of course, some sort of processor is required. It’s hyperbole.

Does this imply it also runs Linux?

I was thinking about trying to contribute, but the code I was fixing is filled with so many workarounds that I’m terrified of breaking one.

May I recommend a versioning or snapshot capable filesystem like BTRFS? It lets me tweak and make mistakes with little fear.

With that said, always keep proper backups of data you care about.

I feel like Linux respects me as the user. Like, I don’t know why this broke, but you get to keep both pieces. We believe in you. Good luck!

Sorry, that was before KB1103995. The new method requires you to check a box in your OneDrive account first before the entry is respected.

In my defense as a AAA member, my super compact in-town car doesn’t have a spare tire, not even a doughnut.

I hear you about the kernel. You can install newer ones or follow the HWE line (as I do) which gives you 6.5 last time I checked.

Don’t need to compete when users don’t have a choice.

It breeds complacency.

This is the problem those tools try to solve. They package everything else upon which software might depend that can’t simply be linked into a single binary.

My workflow always definitely includes multiple weeks to debug random issues with building the tools I need to use. Totally a scalable and good solution to dump this work on the end user.

This doesn’t scale. If I have a bug and my package has about two dozen dependencies which can all be different versions, and the developer can’t reproduce my bug, I’m just screwed. Developers don’t have the time and resources to chase down a bug that depends on build time variables.

Ask me how I know this happens.

Great point! At the end of the day, the apps I want to use will decide which distro I main. Many FOSS fanatics are quick to critique Ubuntu, So they should support solutions that allow our distro to be diverse and use all the killer apps.

Precisely. Flatpaks solve an important problem. Perfect should not be the enemy of good.

Binary compatibility is a sad story on Linux, and we cannot expect developers — many of whom work for free — to package, test, debug, and maintain releases for multiple distributions. If we want a sustainable ecosystem with diverse distributions, we must answer the compatibility question. This is a working option that solves the problem, and it comes with minor security benefits because it isolates applications not just from the system but from each other.

It’s fair to criticize a solution, but I think it’s not fair to ignore the problem and expect volunteers to just work harder.

My WebCam has such low resolution I could argue that that’s anybody in the picture. Go ahead.