Re: [libreplanet-discuss] resources about mailing lists vs. forums (e.g. Discourse)

[Eric Wong]

"J.B. Nicholson" <jbn@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).