wyoung2

RPN calculator program implementations of the math behind a paper previously discussed here: https://news.ycombinator.com/item?id=47746610

My expanded version clarifies that, among other things:

https://tangentsoft.com/podman/wiki?name=Not%20a%20Drop-In%2...

Thanks!

Thanks! I've expanded it into an article, still in rough draft form but available here:

https://tangentsoft.com/podman/wiki?name=Not%20a%20Drop-In%2...

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.

Fossil's method is backwards-compatible, and we published the method for it five years ago (2017-03-05): https://fossil-scm.org/home/doc/trunk/www/hashpolicy.wiki

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. :)

It's easy to strap the color-coding JS library of your choice to Fossil. Here's an instance using Prism.js and its Cay theme: https://tangentsoft.com/mikrotik/wiki?name=Maintaining+a+Loc...

You may find the article of some interest, since it summarizes one common use case for Fossil.

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

How long is it going to take Git to follow?

all those features.

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. :)

https://fossil-scm.org/home/doc/trunk/www/wikitheory.wiki

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:

https://fossil-scm.org/home/doc/trunk/www/image-format-vs-re...

The thing is, Fossil is also a huge improvement over Subversion without losing its day-to-day simplicity.

Fossil was designed by someone coming from CVS, so its everyday CLI is actually closest to that. As a Subversion expat, I found Fossil quite easy to pick up, modulo a few quibbles that muscle memory sorted out quickly enough.

Fossil is that thing: a simplified DVCS that doesn't have important bits missing.

There are certainly cases where Git is the right tool, but it's vastly overapplied, used because it's popular, not because it's the best tool for every job. For smaller projects without a lot of randos offering PRs from the outside, Git's probably costing you more in its complexity than it's saving you by having that complexity at hand.

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.

1. Fossil syncs branching and tagging info among all clones; it isn't local state as with Git. Therefore, when you're looking at a timeline, others' branches and such are named, labelled, and tagged. If you need to filter away all but your current branch, that's easy, because you have all the tags. If you need to see what others are up to in parallel with you so there isn't a big surprise at merge time, Fossil does that readily, too.

2. There's a "hide" feature in Fossil. Rather than destroy information, it simply marks a given branch as not-to-be-displayed unless you go out of your way to unhide everything. It's useful for branches that never go anywhere and thus need to be forgotten.

3. For the intermediate case, where you have a branch that shouldn't be forgotten but doesn't need to be in your face all the time, you can "close" it, meaning it still shows up in the timeline when you scroll far enough back in history to see it, but it's tagged so you can filter away all closed branches, leaving only what's active. This is the default mode for "fossil branch" without arguments, for instance, where it gives only the list of open branches. Your next command will almost certainly have a branch from that list, not something closed long ago.

I could probably come up with more, but that should get you started.

tests that cannot be run locally

Fossil just got a "patch" command to help with cases like that: https://fossil-scm.org/home/doc/trunk/www/patchcmd.md

Previously, the standard solution was to commit work with potential cross-platform issues to a short-lived experimental branch, so you can check out the branch on all your test machines and try it there before merging it down to trunk.

I'm not willing to sit through for the whole 1 hour the test suite runs for

Hour-long test suite runs are a problem in and of themselves. That sets the shortest period of time your development organization can react to a test failure. Look to any application of control theory — feedback systems, process control, OODA loops... — for what happens when you have a slow-reacting feedback loop.

One of those "guys who wrote the book" on Continuous Delivery covered the problem well here: https://www.davefarley.net/?p=218

You either need multiple levels of testing so you get some feedback quickly, or you need some sort of parallel build system that breaks the tests up so that the whole set completes in a reasonable amount of time. Without that, you're going to have people either sitting around waiting on test runners or skipping the tests entirely.

One gets things done

Effort and resources spent on a massively parallel CD buildbot sounds like a good way to get things done to me. Computers are cheap; developer time is expensive.

How else do you answer questions like "How long has this been broken?" And without the answer to that, how do you know who needs to upgrade, and who doesn't?

I'm sure you can install old binaries to answer this sometimes, but I'd prefer to do it with a DVCS bisect, since that'll narrow the matter down to the individual commit that broke things.

That's section 2.5 in the same document: https://www.fossil-scm.org/home/doc/trunk/www/fossil-v-git.w...

That part of the article isn't talking about WIP branches, experimental branches, etc. My personal Fossil development philosophy is that you can go wild on those. The article's point applies primarily to long-lived development branches, things like what Git now calls "main", which Fossil calls "trunk". Commits to such branches should always build and pass all tests on all supported platforms.

If John's rubbish ended up in the merge down to trunk, then you absolutely do want to know about that individual commit.

If you've never received a 500-line patch with a one-line error in it, you haven't been developing collaboratively for very long. Me, I want all 10 commits so I can see from the commit message why the third commit broke the build on platform X, the one clearly tested only on platform Y. I don't want to disentangle the whole mess-o-hackage with a single vague commit comment ("added the foo feature") when faced with such problems.

Am I going to want each and every commit for all history? Of course not, but they're cheap to store, and Fossil makes it easy to ignore the ones not immediately in front of you.

Fossil's bisect works better than Git's in my experience, since Fossil's data model permits bidirectional tracing, whereas Git can go backwards in time only. This allows commands like "fossil bisect status" to show where you are in the decision tree, since it has to trace forward in time as well to provide the answer.

Fossil's strong resistance to changing committed history encourages a culture of not committing predictably-broken stuff, at least not to long-lived branches. This seems like an inherently good thing, to me. Every commit to long-lived development branches should pass all tests and should build on every supported platform. Fossil has tools for fixing this after the fact, but test-first development is your first line of defense for avoiding problems here.

If you're doing experimental work, you do it on a branch in Fossil, which unlike in Git is sync'd globally across all repo clones, so you can do things like check out the branch on another machine and test there before merging it down to the parent branch, presumably one of these long-lived development branches. This is useful in cross-platform development, so you catch portability problems.

(Incidentally, this merge point provides most of the benefits of Git's rebase without rewriting history and without losing the record of how you got to that merge point.)

Fossil just got a feature to avoid the need for a branch in that case: "fossil patch", which creates a Fossil repository (a specially-formatted SQLite database) with as little as one proposed commit, then gives you tools for schlepping that to another repo and integrating it temporarily so you can test on another machine before committing anything. These patch files solve all of the problems with "diff -u": preserve commit comments, file additions/deletions/renames, branches/tags, and so forth.

Fossil's shortest-path bisect algorithm can sometimes cause it to go down unstable branches, but there are ways to redirect it back to the stable branch or to skip broken commits.

Fossil is quite the antithesis of unusable and nightmarish in my experience.

Fossil is a single executable with low system requirements operating on a single SQLite database file, so it's really easy to chroot. It'll even chroot itself if started as root: https://www.fossil-scm.org/home/doc/trunk/www/chroot.md

If you want something more complicated (BSD jails, Docker, etc.) the same properties make it easy to box up that way instead.

The biggest difference was that write(1) was 1:1, whereas this lets any number of people participate. It's got a bit of formatting control as well, though not full Markdown, alas.