im not a marxist-leninist but this is a pretty braindead take

> be me
> advocating for system that is egalitarian and focused on communal ownership of resources to reduce exploitation
> every example of such system, even if incomplete, expoused ideals of radical equity and inclusiveness in multiple facets of life
> the people who believe in the future of such systems point out that those ideals were not met and point out ways to improve on that
> "but why gay"
> no one wants me around
> mfw.jpg

Speak softly, but carry a big stick.

A 9mm would be preferred at least.

I will push back on this a bit because Debian is great, but point release distros like Debian that focus on stability can be incredibly behind on important updates that include features users will want. I personally recommend Fedora to start because imo it’s the best of both worlds for new penguins and greybeards alike.

In the US it makes sense. Much of our corn is grown for ethanol so ot can be used for fuel. Replace that with solar and we reduce our reliance on a monocrop and end up with far far more power.

I do this for my containers. I have a completely domain-managed network, so my docker/podman host mounts an NFS share that contains all the data volumes for my services. Each one only has read permissions for the service account that runs it (and has nogroup). Each OCI container mounts their data volume(s) from their respective directory as well as a kerberos user TGT and credentials cache. Each OCI container runs as the service account, which uses the kerberized credentials to access the mounted data volumes (this is necessary), and thus I acheive separation. Even if a threat actor were to compromiee a service they would still be locked down to that service account and only able to access/modify the data of this service. This is still be very bad for services like keycloak, but for other trivial services it almost guarantees more than adequate segregation. This does fall apart a little bit with the recent copyfail and dirtyfrag exploits which allow for easy privilege escalation, but I don’t allow root squash so the data volumes on the NFS share are still service_account:nogroup even when accessing as root. Now an attacler could go through and use the KRBTGTs that are stored for each service account to access the data, but at that point I am dealing with a dedicated threat actor. Defending against someone explicitly seeking to compromise me is a different situation altogether, and still requires initial access through a vulnerable application that is sitting behind an SSL termination proxy and an NGFW with IPS capabilities.