[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

From: Eric Wong
Subject: Re: [libreplanet-discuss] resources about mailing lists vs. forums (e.g. Discourse)
Date: Mon, 6 May 2019 08:32:12 +0000

"J.B. Nicholson" <address@hidden> 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 wiki could be
> > a good place for it?
> I see that
> now points only to .

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

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, even, along with several popular ones, including
the popular address@hidden list, libc-alpha, bug-gnulib:
There's also read-only access via NNTP.

And a bunch of kernel lists on it:
(Linux Foundation paid me to improve scalability for LKML)

> I wanted to bring up one problem I've not seen with
> mailing lists: 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).

reply via email to

[Prev in Thread] Current Thread [Next in Thread]