But for some reason it started being sold in higher and higher dosages.
I'm not saying this to be elitist or an asshole, or trying to be "better than"/superior or whatever, but for the most part, people really just aren't that smart and don't care to improve that situation. Think of the dumbest person that you know; statistically, half of all people are dumber than that.
You're free to use sync for Lemmy in much the same way you can run a Spotify client in Linux. One does not destroy the other.
I don't understand these mini-Stallmans and their identical attitudes like this. One Stallman is enough, please develop a personality and realize that things do come in shades of grey.
I contribute to FOSS projects & I love Linux and have been using it professionally for a couple of decades, but I'm never going to stand up an LDAP server on it when Active Directory exists, the same way I'm never going to use Windows as a Docker host or a network load balancer.
but also larger distros being used regularly in enterprise/web hosting.
Red Hat is the 800lb gorilla in the room in that aspect. They put out a rock-solid product and their support is probably the best I've ever used regardless of any other factor.
They also pretty much own the Government/Gov Contractor Linux space because of the support and how simple it is to apply STIGs.
On GitLab, you start from a docker image, so it's harder to setup some things but easier for others. If you are very good at docker and don't mind making your own images just for CI purposes, then go ahead.
I think I'd probably consider myself at/near expert-level with Docker, but CI/CD runners instanced in containers just doesn't work for some of our workloads.
As an example, some of our projects have a bunch of Docker images that get built via their own Dockerfiles in the repo, are ran and discarded during the workflow, and each one is modifying the checked-out source tree in some fashion (NPM stuff, composer, whatever, etc), and then a final prod Docker image is built and tested from that source repo tree that has been modified by the Docker containers built/ran/discarded during the workflow. So in Gitlab, it sounds like we'd be running Docker in Docker for some projects.
You ever ran Docker in Docker? It's temperamental at the very best and there are a thousand gotchas associated with it, not to mention having to worry about how many variable scopes deep you are and keeping track of that, how to properly bind mount volumes into the nested Docker containers because the method and paths will vary depending on how nested you are, etc. It's just an absolute nightmare to deal with all-around in that context.
I'll see if we have some projects I can try out on it, but the majority of ours are like what I described above.
Could always just get another drive instead of tearing it down, storage is pretty cheap these days.