wyoung2

> huge uid didn't work in podman (like 1000000 I think)

You're running into the `/etc/sub[ug]id` defaults. The old default was to start your normal user at 100000 + 64k additional sub-IDs per user, but that changed recently when people at megacorps with hundreds of thousands of employees defined in LDAP and similar ran into ID conflict. Sub-IDs now start at 2^19 on RHEL10 for this reason.

Broadly, the claim that Podman is a drop-in replacement for Docker is true only for the simple cases, but people have developed assorted dependencies on Docker implementation details. Examples:

1. People hear about how great rootless is with Podman but then expect to be able to switch directly from rootful Docker to rootless Podman without changing anything. The only way that could work is if there was no difference between rootful and rootless to begin with, but people don't want to hear that. They combine these two selling points in their head and think they can get both a drop-in replacement for Docker and also rootless by default. The proper choice is to either switch from rootful Docker to rootful Podman *or* put in the work to make your container work in rootless, work you would also have had to do with rootless Docker.

2. Docker Compose started out as an external third-party add-on (v1) which was later rewritten as an internal facility (v2) but `podman compose` calls out to either `docker-compose` (i.e. v1) or to its own clone of the same mechanism, `podman-compose`. The upshot is a lot of impedance mismatch. Combine that with the fact that Podman wants you to use Quadlets anyway, resulting in less incentive to work on these corner cases.

3. Docker has always tried to pretend SELinux doesn't exist, either by hosting on Debian and friends or by banging things into place by using their privileged (rootful) position. Podman comes from Red Hat, and until recently they had Mr SELinux on the team. Thus Podman is SELinux-first, all of which combines to confuse transplants who think they can go on ignoring SELinux.

4. On macOS and Windows, both Podman and Docker need a background Linux VM to provide the kernel, without which they cannot do LXC-type things. These VMs are not set up precisely the same way, which produces migration issues when someone is depending on exact details of the underlying VM. One common case is that they differ in how they handle file sharing with the host.

> github.com…I don't want an 'impedance mismatch' between my system and their system

So give your contributors developer accounts on your Fossil instance, which is super-cheap to set up, being a single binary with nearly zero external dependencies. (Those being OpenSSL and zlib, which are table stakes these days.) My containerized build is a single static binary that compresses to ~3.5 MB, total, all-in.

If you're concerned over the lost promise of easy PRs from randos on the Internet, I question your premise. My experience is that below a certain project popularity level, there is less than one total full-time developer on the project, even counting all possible external committers. Below this threshold, why optimize for external contributors? If someone has a sufficiently valuable patch, they can deal with getting a Fossil repo login or sending a patch.

I've been the maintainer of a piece of software for coming on two decades that's in all popular package repos and have _never_ gotten a worthwhile PR for it via GitHub. I spend more time using their code commenting features explaining why this, this, and this make the change unacceptable, after which the PR submitter goes away rather than fix their patch. It's a total waste of time.

I did once upon a time get high-quality external contributions, but that was back when the project was hosted by Subversion, and it didn't matter that posting patches required more work than firing off a GH PR. People who have sufficient value to commit to a project will put up with a certain level of ceremony to get their code into the upstream project.

(To be fair, I expect the reason for the lack of quality external contributions is that the project is in some sense "done" now, needing only the occasional fix to track platform changes.)

If you are lucky enough to have an audience of outsiders who will provide quality contributions, Fossil does have a superior option for patches than unified diffs. See its "patch" and "bundle" commands. This lets your outsiders send a full branch of commits with comments, file renames/deletions, etc.

…kind of like a PR. :)

If you absolutely require integration with Git-based tooling, Fossil makes it easy to mirror your repo to GitHub, which you can treat as read-only.

We don't know how to push bad artifacts into a Merkle tree by exploiting SHA-1's weaknesses. The thing is, though, we didn't want to be pushed into scrambling for a better hash algorithm after some clever bastard works that trick out. :)

All of which is why Fossil now uses SHA3-256 by default.

How long is it going to take Git to follow?

When Fossil didn't have those features, the frequent complaints were that Fossil doesn't have those features, and that's why they had to keep using $INERTIA_SOURCE. Now that it has those features, it's the reason not to move to it? I see. :)

All of these features cooperate and serve the same goal: coordinate the work product of people on a project, in a distributed fashion. One path to that is the nearly fully centralized model of GitHub. Another is the VCS + mailing list + bug tracker + wiki path, which requires considerable admin resources to manage, and at the end of the day is a pile of barely-cooperating services. Fossil's path is to put them all into one place so they all work properly together.

You can reference ticket IDs from a forum post.

You can point to a section of the timeline from a wiki article.

You can create diagrams in Pikchr format that live as version-controlled text in the repo and reference them from commit messages.

You can generate HTML diffs and include them into the body of a Markdown chat posting for discussion of a proposed change before committing it.

Etc., etc. It's all communication, which you need when you have multiple people working on a project, especially across time zones.