I struggle to believe you don't understand what they mean. There is many a homophobe in the world. GP isn't saying homophobia is good, simply that espousing a pro-LGBT viewpoint may upset people. Maybe they deserve to be upset, but that doesn't change that it may become your problem.
> simply that espousing a pro-LGBT viewpoint may upset people.
Y'know, I'm pretty much fine with upsetting bigots. I'd assume that people inclined to be upset by a scary pride flag are also upset by my _existence_, so, y'know, I don't see a strong reason to moderate my stickers to protect the delicate feelings of idiots. If they're a homophobe they'll have a problem with me _anyway_.
Sincere or not, the obvious should be stated here that distain for extremely politicized gender movements has little to do with outstanding opinions for said actual sexualities. I've personally voted for (several!) gay political candidates and attended a gay wedding, among other similar things.
The current day form of the lgbt(...) movement has done more damage to their representation than the natural, mostly not strong but dismissive opinions of the common folk could ever have. The screaming intentional ignorance of criticism of its increasingly radical extensions and effects sometimes makes me think we're not just living in the world of Idiocracy, but in the version of the world that comes after it ...
People can become upset for a great variety of reasons. I think it's better to accept to some extent that it happens than to design your life around not upsetting anyone.
I tried Podman on my messing around VPS but quickly reverted to rootless Docker.
The straw that broke the camels back was a bug in `podman compose` that funnily enough was fixed two hours ago[1]; if `service1` has a `depends_on` on `service2`, bringing down `service1` will unconditionally bring down `service2`, even if other services also depend on it. So if two separate services depend on a database, killing one of them will kill the database too.
Another incompatibility with Docker I experienced was raised in 2020 and fixed a few months ago[2]; you couldn't pass URLs to `build:` to automatically pull and build images. The patch for this turned out to be a few lines long.
I'm sure Podman will be great once all of these bugs are ironed out, but for me, it's not quite there yet.
Podman compose is an attempt to court Docker users by porting over a bad idea. Instead of that, learn how to create "quadlets" and you'll never want to touch docker again. See: https://www.redhat.com/en/blog/quadlet-podman
I recommend starting with .container files instead of .kube, unless you're already familiar with kubernetes.
So for my set of DVR services, quadlets would have me replace a single compose.yml with 6 .container files, and manually create the network, and have to stop and start all of the services individually.
Not sure what your compose file looks like, but my container files are tiny, flat, and trivial to maintain.
> manually create the network
There's no way for me to know what your requirements are, but often times if you just need your containers to talk to each other, all you need is an empty file with a unique name. So `touch MyDVRNetwork.network` to create it, and add `Network=MyDVRNetwork` to your containerfiles.
> and have to stop and start all of the services individually.
Nope, container files are essentially already systemd service files. If you add them to the correct folder and set up the dependencies, systemd will automatically start them in the correct order at boot time, restart them if they fail, etc. That's the best part of quadlet IMO. Literally set it and forget it, and the process works the same for rootless containers (you just need to add them to your user folder instead of the system-wide folder)
It gets even more awesome when you combine them with something like Fedora CoreOS and Butane. With a few small text files, you can declaratively generate an OS image with all of your desired services ready to go. It is pure bliss.
How would I share Quadlet files for my repo? Today I have a docker-compose.yml in my repo, the instructions to try it out are usually `docker compose up --build -d`.
I read about the recently released CLI support for quadlets [0] and the ability to install Quadlets from a URL but still cannot wrap my head around it (as in, no matter how I look at it, Quadlets seem to require non-trivially higher knowledge to use and more steps/files).
Quadlet is only for managing containers. If you need to build images too, you need to use the "buildah" CLI tool. If you know what a systemd service file is, a quadlet is essentially just that. It's a service file that automatically handles the annoying details of creating a systemd service to start/stop your container properly.
But Quadlet needs a container image before it can create a container. The example compose file you linked includes steps for building Dockerfiles. Quadlet doesn't do that. Instead, you'll need to do it as a separate step using buildah (https://www.redhat.com/en/topics/containers/what-is-buildah)
Compose does a lot of stuff, so migrating away from it isn't always easy. In this case, you'd probably need to bring in a build system like Make or some custom scripts to build all the container images you need. Once you rebuild an image, you can restart your quadlet-managed containers with `systemctl restart my-container` and they'll automatically use the new image.
I don't do much web development these days, so I'm definitely not an authority on container-based development workflows. Maybe there are better tools out there, or maybe compose is still the best tool for that job. But quadlets are definitely the better choice when it comes to deploying/orchestrating your containers without getting into a full blown kubernetes setup.
Quadlet supports ".build" and ".image" files, and ".container"s can have an auto-update policy (supported by manually invoking `podman auto-update` or the daily timer.)
It sounds interesting, but with some caveats / things that require other tooling, maybe migrating all my services from compose to quadlets would end up a fairly lateral move.
Quadlets also support a .kube file. I have a similar use case where I have 6 containers I want to all run on the same network. So have a k8s YAML file that has a pod with the containers, their configuration and path mapping and then a have a `service.kube` file with a '[Kube]' section and a 'Yaml=/path/to/config.yaml' directive. That creates a single service to stop/start with systemd and has all the containers running on the same network in a single pod.
Can you use those quadlets inside a development project? I use docker-compose (with podman) just so i can work on a project that is completely self-contained. No copying files to ~/.config/systemd just run docker-compose to start and stop.
I'm not the best person to ask about this as I don't do much web dev these days, and my experience with podman is mostly limited to deploying existing software. If compose works for that use case, then you should probably stick with it. For actually deploying it somewhere though, you should be using quadlets instead (or kubernetes I guess)
> No copying files to ~/.config/systemd just run docker-compose to start and stop.
Naively, I'd say to create symlinks instead of copying, and run `systemctl daemon-reload`/`systemctl restart ...`. Although there are probably more streamlined web development options out there.
Maybe look into Podman Pods. They're probably closer to what you're looking for, but idk what kind of dev tools exist out there for it. Maybe a few custom shell scripts to run the pod management commands is all you really need?
The quadlet user folder is typically at `~/.config/containers/systemd`. So if you put your .container files in there, you can start them with `systemctl start --user MyContainer`
What I've done is use the "podman kube play" similar to docker-compose when developing ("podman kube play file.yaml", "podman kube play --down file.yaml", "podman kube play --replace file.yaml", etc.) with the "file.yaml" in my working directory. Then when I'm satisfied and want to deploy to production I write a quadlet snippet referencing the kube file and put them under /etc.
I tried with Ubuntu just know and there's a 404 for buildah to install via apt at this exact moment. Here's my working Fedora WSL2 (which I prefer and use daily).
I use rootless podman in socket mode but use the docker CLI (just the CLI, no daemon or service or messing with iptables) as the frontend. Can recommend!
What does the docker CLI give you that the podman CLI doesn't? (Surely you aren't suggesting that `docker compose` works with a podman rootless daemon?)
For what it's worth, podman has also a thin wrapper around docker compose (podman compose) which can also automatically select `podman-compose`.
Note:
- `podman-compose` is an early attempt at remaking `docker-compose` but for Podman.
- Later Podman wrote a Docker compatible socket instead, which can work with most docker clis that accept a `DOCKER_HOST` argument, including `docker` and `docker-compose` (both v1 and v2)
- `podman compose` is a thin wrapper that automatically selects `docker-compose` or `podman-compose` depending on which is installed.
Yes. All of that works in my experience. It's a drop in replacement. You set it up once in the docker CLI with `docker context ` or just symlink it to the right location. Then you can forget about it basically.
I use this on my server with compose together with traefik which listens on 127.0.0.1:{8000,4433}. Then I have a small nftables config that does the port forwarding to 80/443.
> even if cash is legal tender and they, by law, _have_ to accept cash
this is not true as it is not what "legal tender" means. Legal tender is something that the government must accept as payment, not private enterprise.
> Businesses don’t have to accept cash.[0]
> There is no federal statute mandating that a private business, a person, or an organization must accept currency or coins as payment for goods or services.[1]
That depends on the country. There are many countries (including my own) where any business must accept certain parts of the cash payment system (around here a taxi doesn't have to accept the highest-value bank note, but the rest cannot be refused). And shops, of course. That's why newspapers bother to write articles about it.
Note that legal tender does apply to private entities when it comes to paying debts, at least in the US. Creditors must accept legal tender, or give up claim to the debt.
It’s true that private businesses can set pretty much any payment terms they want for a transaction that hasn’t yet taken place. But the moment you move to a situation where you owe money, they do have to accept cash.
I'm not a psychologist but some of these extrapolations seem insane to me.
> Using Czech police records, American and Czech researchers compared rape rates in the Czech Republic for the 17 years before porn was legalized with rates during the 18 years after. Rapes decreased from 800 a year to 500. More porn, less rape.
> In addition, the legalization of porn was associated with a decrease in another despicable sex crime, child sexual abuse. Under Communism, arrests for child sex abuse averaged 2,000 a year. After porn became legal, the figure dropped by more than half to fewer than 1,000. More porn, fewer sex crimes.
The country's entire foundation shifted from underneath it; an empire collapsed around it. How could they possibly isolate the legalisation of pornography specifically as the cause of decreased rape? Why not the legalisation of private enterprise? Is it not feasible that living in a repressive, controlled, surveilled society caused men unrest?
Perhaps the studies cited went into more detail, but "Lots of rape in 1985, less rape in 2005. Porn was legalised between then, ergo porn caused this." does NOT convince me.
Fair enough although that's not the only statistics they cite.
More importantly I think they're trying to point out the converse of maybe what you're pointing to, which is that as porn availability increases, if it caused sexual assault, rates of the latter would go up. But it doesn't, you see the opposite trend time and time again.
This is one of those cases where you'll never be able to do a RCT, so any study will be flawed in some way (even RCTs have their issues).
