"J.B. Nicholson" <j...@forestfield.org> wrote: > John Sullivan wrote: > > I'm not aware of any, but I think that's a good idea, since I've seen > > the same conversation many times too. The libreplanet.org wiki could be > > a good place for it? > > I see that https://libreplanet.org/wiki/Mailing_Lists_vs._Discourse_Forum > now points only to https://en.wikipedia.org/wiki/Internet_forum .
On the topic, how about focusing on mail archives rather than mailing lists? In other words, a "public inbox" :> I wrote public-inbox software (AGPL-3.0+, Perl5) since I wanted to be able to clone/mirror/fork discussion groups just like software projects. git clone https://80x24.org/public-inbox.git Usability and documentation ain't great atm, but I'm slowly working on improving it (along with git integration for email-based development); but I'm OK in the performance department :) There's an archive of this list I imported from mboxes over ftp.gnu.org, even, along with several popular ones, including the popular git@vger list, libc-alpha, bug-gnulib: https://public-inbox.org/hosted.html There's also read-only access via NNTP. And a bunch of kernel lists on it: https://lore.kernel.org/ (Linux Foundation paid me to improve scalability for LKML) > I wanted to bring up one Discourse.org-specific problem I've not seen with > mailing lists: Discourse.org doesn't seem to design their server layout to > properly scale up. public-inbox responses are designed for easy cache-ability (and URLs for appropriate expiration) with Varnish. My low-end $20/month VPS has been hit by numerous hug-of-death events from popular posts and never batted an eye. The main downside (aside from docs) to public-inbox is it uses a large amount of space when Xapian is enabled for search. That also benefits from SSDs and struggles with HDDs. I don't have space to mirror LKML myself; but 14 years of the git list cost me 1.2G in git objects, 5.7G in regeneratable Xapian+SQLite data). Full disclaimer: I've also taken funding from Discourse (and several others) last year to improve Ruby VM performance and lower memory use. But those remain problems in Ruby and there wasn't enough money to keep me interested in a language that's constantly breaking compatibility. So I'm a bit more productive in Perl5; but several of the big Ruby projects (Discourse, GitLab) still use a Ruby server I designed (unicorn) and followed my setup advice for dealing with slow clients via nginx (or yahns). _______________________________________________ libreplanet-discuss mailing list libreplanet-discuss@libreplanet.org https://lists.libreplanet.org/mailman/listinfo/libreplanet-discuss