> 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. :)
The forum, chat, and Pikchr features have been added since then. Indeed, everything in the Fossil ChangeLog has been added since then, because it cuts off a few months after your post: https://fossil-scm.org/home/doc/trunk/www/changes.wiki
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.
I'm the type of guy that would store the Pikchrs in the version control system alongside the HTML, then write a Makefile to regenerate the SVGs referenced from the HTML every time the Pikchrs change.
But at that point, you might as well just use Fossil as a CMS. :)
No technology popular enough to attract an audience ever goes away. However, would you care to speculate on how many troff documents were written in 2021 versus Markdown docs?
If you leave off the "pikchr" tag or use something else like "PikchrSource", then the renderer doesn't trigger.
If you want to see it both ways, Fossil renders the diagrams with an Alt or Ctrl-click handler attached (depending on platform) that toggles between the SVG and the fixed-width source code view.
And if you don't like the modifier key, you can tag a diagram "pikchr toggle" to make it toggle with a simple left-click.
I daresay there is no DVCS appropriate for many large files that change. You want something more like a classic non-distributed VCS so you're not cloning the entire history of huge files.
Worst is when they're data-compressed so you're not only pulling all historical versions but also most every byte of each historical version.
I wrote an article for the Fossil docs covering this, but the core experiment can be run against any VCS:
Complexity is fine in something like a programming language or a text editor where increasing mastery can mean better software and hopefully more money. How do I make more money by learning arcane Git commands?
We don't use DVCSes for their own sake, we use them to accomplish something else. To the extent that the DVCS gets in the way, it's an opportunity cost.
"Detached head" is Git's way of saying "I don't know how to find my children when you say something like 'git checkout abcd1234'". Fossil can do this, so you can point someone to a historical checkin and Fossil won't get lost should you later commit on top of it. Git's warning you that if you do that, you may end up with an orphaned commit.
If you hadn't included that restriction, I'd tell you about Numbers. Not all spreadsheet type problems fit into its limitations, but for those that do, it makes you ask "Why don't all spreadsheets work this way?"
But you did make that a restriction on your criteria, so forget I said anything. :)
The first non-Apple software I thought of when you asked the question was PDFpen, which operates vaguely like what is now called "Acrobat DC" used to. Acrobat drives me up a wall; it's like they asked, "How can we make the Microsoft ribbon interface even worse? Let's do that!"
I have about three Markdown editors that are Mac-only that I like better than any cross-platform alternative I've tried. (Byword, Markdown Pro and MultiMarkdown Composer.) I have three because none of them does everything right, so I occasionally have to switch for some task or other. I'd happily switch to something cross-platform if it matched the union of those three apps' features, those I care about, anyway.
I suspect I have three solid Markdown editors to choose from because they're all based on solid OS-level rich text editing features that exceed what you get on Windows, so the non-Mac competition has to waste a lot of resources reinventing wheels. Just as one example, you get grammar checking for free in most Mac native text-editing software. Where it doesn't occur, it's usually because the app is cross-platform and is thus avoiding Mac-specific features.
A related example is the built-in dictionary. You can get dictionary/thesaurus apps on other platforms, but they generally aren't as deeply integrated as the one on macOS.
Then there are the times where you have a cross-platform app that simply works better on macOS. VLC and MacVim (as compared to gVim) come to mind.