Unified capabilities site

[Jonathan S. Shapiro]

A month or so ago, we had a flurry of discussion about how to create an archival site for information about the various capability systems. So far as I am aware, nobody actually stepped up to say "I'll own it".

I actually think this is important, so unless there is a better plan already underway. I'm going to start gluing together a static archival site for all of these projects. As an organization sorts itself out, I'll be reaching out to other projects and sources as well.

Goals:

• Organize by project or major topic
• Content, where possible, in HTML and CSS, stored in public access repositories.
• Code accessible where possible, ideally by reference to GIT repositories.
• Everything gathered under a single site so that the cost of curation and maintenance is as low as possible and the whole thing can be handed off to new maintainers over time.
• [Eventually and selectively] It may make sense to do some layout and CSS work for a consistent look on an opt-in basis, but for now that's a low priority.
• To the extent that it is possible, make the individual project sections accessible to their maintainers so that the maintenance effort can be collaborative.
• At some point we should either set up or affiliate with a suitable non-profit entity that can own and provide a funding structure for the archive. At some point I'll probably talk to Brewster for advice on structure.
• In the longer term, I don't see this as an archive for our projects; I'd like it to become a reference archive site for capability systems broadly.

Non-Goals:

• It is not a goal to preserve the legacy host names for this material. This has been keeping us stuck for years, and it adds significant costs and complexity.
  
  We have established that many registrars offer the ability to put a top level domain at a URL; anybody who wants to do that should definitely feel welcome to do so.

Uncertainties:

• I don't have a final answer for interactive sites yet. I'm currently focused on using cloudflare pages, which is a JAMStack platform, but there are both security and long-term maintenance concerns to be considered. I don't have time to maintain site code from other authors and projects. I'll try to make it possible for individual project maintainers to do so.
• No matter how clean the code may be, programming languages change. It is unlikely that code written today will still be runnable in 25 years when there's nobody left to keep the small updates happening. You may want to give thought to how your project archive should look in 25 years.

This isn't going to be quick or easy, but I think it needs to be done. Before I jump in, I'd like your feedback and comments.

For clarity: I promise to read and consider them, but we haven't made any progress on this in the last 15 years (not calling names - all of us have been plenty busy)., and it's more important to make forward progress than to have a perfect result.

Jonathan

[Kevin Reid]

On Fri, Nov 21, 2025 at 10:47 AM Jonathan S. Shapiro <jonathan....@gmail.com> wrote:

A month or so ago, we had a flurry of discussion about how to create an archival site for information about the various capability systems. So far as I am aware, nobody actually stepped up to say "I'll own it".

I actually think this is important, so unless there is a better plan already underway. I'm going to start gluing together a static archival site for all of these projects. As an organization sorts itself out, I'll be reaching out to other projects and sources as well.

Goals: [...]

This all sounds like a great plan! 

[Alan Karp]

I'm in favor, but what you propose goes WAY beyond my intent.  I wanted a way to answer the question, "If capabilities are so good, why is nobody using them in production?"  Your site will provide a place for that plus a lot more.  .

--------------
Alan Karp

On Fri, Nov 21, 2025 at 10:47 AM Jonathan S. Shapiro <jonathan....@gmail.com> wrote:

--
You received this message because you are subscribed to the Google Groups "cap-talk" group.
To unsubscribe from this group and stop receiving emails from it, send an email to cap-talk+u...@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/cap-talk/CAAP%3D3QPyzCjG2eDE9%2BZ%3D92WLSd4m8Pr1xwjE5aZRnMEc__aE8w%40mail.gmail.com.

[Jonathan S. Shapiro]

Alan:

That seems like a great intent! Hopefully this would be complementary.

When I interviewed for a faculty position at U Chicago in 2000, I decided to wander over to the library to see if I could get copies of everything Fabry's group published. Arrived to be told that I was just in time, because nobody had looked at those documents in decades, and they were preparing to discard them. I spent a bunch of quality copier time. Unfortunately most of what I collected was later destroyed when the basement of my house in New York (while at IBM) flooded.

But... holy sh*t. If we keep throwing away or paywalling the past, how the heck do we learn from it?  Maybe capabilities will always be the wave of the future, but throwing away the past seems somewhere between criminally stupid and utterly bone-headed.

It's just not that effing hard to scrape or clone the sites, organize them into a tree, and stick a paragraph or two of description on each.

Jonathan

To view this discussion visit https://groups.google.com/d/msgid/cap-talk/CANpA1Z1sMFHma-V8353YwpcXtRQmRJgn9dZabZKLT-M0cXkAzA%40mail.gmail.com.

[Jonathan S. Shapiro]

Val sent me a note privately that makes me think I should clarify something.

In the short term, I'm mainly trying to gather sites and code under a common umbrella. We have a huge amount of "lore" in this area that was never formally published, and a surprising amount of the dead tree literature is getting hard to locate. It would be nice for folks who decide they are interested to have a single point of entry.

I think there's also a useful place for a forum and a discussion space, but it's really hard to imagine any forum software that will still be runnable in 25 years. There's something to be said for "google groups (or whatever) has that covered, scrape that stuff once a week (or whatever) and make it static content".

So at least for the moment, I have no plans to put attention into the "forums and discussions" part of this.

Jonathan

[Bakul Shah]

You can just create a repo on  Github (or some such other public git hosting site)... You also use it for some discussion, hosting a website etc. + others can contribute (via push requests). Using git means there can be multiple copies of at least the content!

Note sure what storage limits exist on Github for free accounts but if that becomes an issue one can host such data elsewhere and put links in the repo.

I am most interested in the recordings of your talks with Norm Hardy (if you decide to put them up)!

Bakul

--
You received this message because you are subscribed to the Google Groups "cap-talk" group.
To unsubscribe from this group and stop receiving emails from it, send an email to cap-talk+u...@googlegroups.com.

To view this discussion visit https://groups.google.com/d/msgid/cap-talk/CAAP%3D3QOXLb%2Btp9iWKz7PRmTuC0Bpg_-nnwWExQrLDLk3icTCHQ%40mail.gmail.com.

[William ML Leslie]

On Sat, 22 Nov 2025 at 04:47, Jonathan S. Shapiro <jonathan....@gmail.com> wrote:

Uncertainties:

• No matter how clean the code may be, programming languages change. It is unlikely that code written today will still be runnable in 25 years when there's nobody left to keep the small updates happening. You may want to give thought to how your project archive should look in 25 years.

Just wanted to mention that I had a decent experience building CapROS and Coyotos in Guix.  It wasn't trivial, but once you have something building there, it is hermetic and should always build and run.  I started from GCC 3 and walked forward until I had them mostly building under GCC 10.  If the dependencies you need don't exist in GNU Guix, Nix has similar properties but has a much broader ecosystem.

I needed a little creativity to build specific versions of autotools as I'm not cool enough to know how to upgrade those m4 dependencies and didn't want to audit big diffs, but again, it's within reach.

Not that this needs to be a blocker, but it's worth presenting this as an option.

---

William ML Leslie

[Jonathan S. Shapiro]

On Fri, Nov 21, 2025 at 2:55 PM 'Bakul Shah' via cap-talk <cap-...@googlegroups.com> wrote:

You can just create a repo on  Github (or some such other public git hosting site)...

Using GitHub as a back end was part of my nefarious plan, but we’re going to end up drawing from separate repositories to build each project sub-tree. 

I suspect we’re going to want a transform step somewhere in this. We’ll have subtrees drawn from a bunch of different sites. It may make sense to run XSLT transforms (or some such) to get to a (very) roughy common look and feel.

So there may be something like a CI/CD phase whose output is the site tree. I’m still running this around in my head, so I’m probably way over-thinking this.

Jonathan

[Matt Rice]

The theorem prover museum seems a bit different in that they basically
just have one static site
which links to a bunch of individual repositories for various theorem provers.

That static site then contains itself a summary of each.
They don't attempt to collate any documentation from each individual
repository, and basically assume that
the individual repositories will rot, but need to be preserved in
their original form.

Figured I'd mention that model, since it seems to serve them well.
But it sounds like you're after a more integrated approach.

https://theoremprover-museum.github.io/
https://github.com/theoremprover-museum