You see, it’s not required for me to agree with whom you are criticizing, to criticize your inability to be civil. So keep making as many strawmen you like. We are in a post complaining about user behavior/content and your behavior and content are both completely unacceptable in a community.

Also, you can stop name-calling, this may have an effect when someone else values your opinion, I don’t.

Ok, but it’s the same thing from the perspective of all the people on an instance vs from the perspective of an individual. Those people are still there, creating posts etc., and they can easily move on other instances if they want too.

It’s just a “bigger blanket”, but the concept is essentially the same, with the plus that more people are “covered” and the minus that someone might be affected against their will.

Either way, it doesn’t solve the problem, it just masks it for the members of an instance. Why would it be a fundamentally better solution in this particular instance?

I had a look at your history, and you seem really incapable of behaving in a civil way, often using insults. I don’t think this is a good strategy to get your point across.

Be respectful of others.

This comment is in clear violation of the rules of this community. Be better, if you want to criticize others.

No, you’re putting a blanket over them and pretending they’re not there any more.

Isn’t defederation the same thing? Users won’t disappear (and they can also create accounts elsewhere…).

Thanks (grazie?)! I was looking for something similar and kanidm looks great feature wise and simple to deploy!

I struggled with this for a long time, and then I just decided to use synology photos.

It has albums, tagging, geolocation, sharing. It has phone picture backup, it is inherently a backup as it’s on my NAS and I back that data up again.

I want to keep the thing that I really care about the most friction free and also not too dependent on myself so that I can still experiment.

I didn’t try PiGallery2 though, maybe I will have a look!

Did it sound cold? Because I didn’t mean that, I just meant to actually answer the question from my PoV. Just for the record, I also did not down vote you.

So yeah, use whatever footgun you prefer, I don’t judge :)

Or rustic! It is compatible with restic but has some nice additions, for example the fact that supports a config files. It makes operations a bit easier IMHO (I am currently using both).

I really thought swarm was dead :)

To be honest, some kubernetes distributions make the cluster operations minimal (I use k0s managed via ansible)!

Either way, the moment you go from N containers on one box to N containers on M boxes you need to start considering how to handle stateful applications, load balancing, etc. And that in general requires knowledge on a domain which is different from having simply applications wrapped in containers locally.

Yeah ultimately every container has it’s own veth interface, so you can do shaping using tc on those.

Edit: I had a look at docker-tc. It does what you want, BUT. Unless your use case is complex, I would really think twice about running a tool written in bash which has access to the docker socket (I.e. trivial node escape) and runs with NET_ADMIN capability.

That’s a lot of power to do something you can also do with a few lines of code executed after you start the container. Again, provided that your use case is not complex.

Cgroups have the ability to limit TCP and total network bandwidth. I don’t know from the top of my mind whether this can be configured at runtime (I.e. via docker run), but you can specifcy at runtime the cgroup parent to use. This means you can pre-create the cgroup, set the limits and start the container with that parent cgroup.

You can also run some hook script after launch that adds the PID to a cgroup every time the container is launched, or possibly use tc.

I am not aware of the ability to only limit uplink bandwidth, but I have not researched this.

I think k8s is a different beast, that requires way more domain specific knowledge besides server/Linux basic administration. I do run it, but it’s an evolution of a need, specifically when you want to manage a fleet of machines running containers.

Because the lxc way is inherently different from the docker/podman way. It’s aimed at running full systems, rather than mono process containers. It has it’s use cases, but they are not as common IMHO.

You have a bunch of options:

kubectl run $NAME --image=$IMAGE

this just creates a pod running the specific image. If you kill the pod, or it terminates, it won’t be run again. In general though, you probably want to do some customization before running (maybe you need volumes, secrets, env, ports, labels, securityContext, etc.) and for that you can simply let kubectl generate the boilerplate YAML and then simply make some edit:

kubectl run $NAME --image=$IMAGE --dry-run=client -o yaml > mypod.yaml
# edit mypod.yaml
kubectl create -f mypod.yaml

You can do the same with a deployment or statefulset:

kubectl create deployment $NAME -n $NAMESPACE [...] --dry-run=client -o yaml > deployment.yaml

In case you don’t need anything fancy, the kubectl create subcommand allows you to create simple workload, so probably that’s the answer to your question.

Docker can run rootless too, see https://docs.docker.com/engine/security/rootless/

I would say Docker. There is no substantial benefit in running podman, while docker is a widely adopted tool (which means more tooling in the ecosystem, easier to find answers to questions etc.). The difference is not huge tbh, and some time ago the biggest advantage for podman was being able to run rootless, while docker was stuck with a root daemon. This is not the case anymore (docker can run rootless), so I would say unless you have some specific argument to use podman, stick with docker.

They have millions in funding, they will always move at a faster pace. The question is in which direction they will move, I suppose.

I am sure that for such small shops it’s trivial to explain that resources are extremely limited, I don’t see any data protection authority actually pursuing anyone based on the lack of privacy by design. The point is, nobody is forcing you to deploy the software as is, and technically anybody could write tools that bridge the gaps in the software. If the software does not offer data deletion, any instance admin could have identified this gap (a risk assessment for data collection is also needed technically) and wrote a script that would allow to satisfy data deletion requests or anything else that would have made them comply.

That said, I agree that these features are important. I do not agree that they are what the devs should work on right now, or that at least it takes some convincing to convey the fact that these are important features for instance admins to be compliant and for users (in general).

I also get the point about the “I am not taking your word for it” approach. Look how many people in this thread talk about GDPR without actually understanding who is the data controller/processor and who has to be compliant. I can only imagine the amount of uninformed people who open issues and waste time for already busy devs. We are seeing the couple of examples that the article picks, we are not seeing the rest of issues which justify this harsh approach.

The way I see it, having certain features implemented in the Lemmy software is one way to ease compliance for admins, and they should just upvote the issue and explain why it’s important for them, possibly even adding a bounty to the feature. OP’s approach doesn’t seem this and it’s much closer to demand stuff, as if the compliance responsibility was on the devs and the donation were some sort of reason to make them work on what other people want.

To be precise, it’s not devs that need to worry about GDPR, it’s instance admins. I don’t disagree with you, but I think it’s an important distinction to make.