Different use cases than QEMU, honestly, to the point that there's not much overlap. QEMU is extremely good at running modern operating systems, and not so much at older ones (DOS and Win9x are pretty sore points in QEMU). 86Box is extremely good at running old operating systems (including DOS and Win9x!), but modern operating systems are mostly out of the question (you can run WinXP, but https://86box.readthedocs.io/en/latest/usage/faq.html#can-i-...).
Funny part is, that NFSv4 supports SIDs for user authentication, but the Linux implementation leaves it out (among all the other ACL features) simply on the basis that Linux doesn't support them at all.
The FreeBSD, Solaris, Mac OS X, and Windows (yes, even Windows) implementations of NFSv4 are fully featured with this stuff.
It was actually part of Microsoft Plus! for Windows 95. It wasn't directly available for Windows 98 at all, but the Windows 98 install disc does include an INF file so you can install it, provided you have a copy of Plus! for Windows 95.
It was also included with Windows NT 4.0, Windows 2000, Windows Me, and Windows XP (both the original and x64 versions). Finally removed in Vista to never return.
Delphi and Lazarus are still kicking, the latter is free and open source.
I know you asked for "the language", but Object Pascal really ain't that bad to get around. If you were proficient in VB6, you should be fine adapting. :-)
This is a current architectural limitation, manifests (defining check-ins) and tickets are different types of artifacts and you cannot combine the card types into the same artifact. Changing this would likely break backwards compatibility with previous Fossil versions and I'd expect resistance. It may still be worth bringing up on the Fossil forum if you desire the feature.
Personally speaking though, I don't want things automagically closed GitHub-style based on parsing a check-in comment. An issue ought to be closed with intention.
> (Of course Fossil actively opposes "pull requests", separate issue)
Not opposition, but very little incentive for the primary developers to implement the feature. Fossil's own developers happen to be the same as SQLite's developers, which doesn't accept outside contribution as a policy. It results in Fossil's features being predominantly, but not exclusively, the same features needed for SQLite and little else.
> Other VCSes like fossil store issues alongside the repo.
Technically the issues in Fossil are part of the repository, along with the wiki, code, forum, etc. They come along with every clone and (mostly) cannot be deleted from the historical record.
Items of Fossil that are merely "alongside" instead of actually in the repository include unversioned files, chatroom content, and users and access controls. (Not an exhaustive list.)
What are you really proposing? That a first ".INDEX" entry be made that contains the offsets of all the other members?
That could work in a backwards-compatible way (as long as no standard tar utility makes modifications to the archive...), but it's hamfisted. Just use Zip. It's already a well-known format with numerous implementations and already does the job that you want to do.
Zip has a central directory you could just query, instead of having to construct one in-memory by scanning the entire archive. That's significantly less work.