Re: Browsing Guix (or any) lists with Gmane

[Maxim Cournoyer]

myglc2 <address@hidden> writes:

> On 10/01/2017 at 12:45 Maxim Cournoyer writes:
>
>> Hello Guix!
>>
>> For Guix and Gnus (or to become) users out there, I thought I'd share
>> this brief post where I explained the process of setting up Gnus and Gmane.
>>
>> Here are some benefits:
>> 1. No need to locally store emails; just view them over NNTP.
>> 2. Easily subscribe to some lists in Gnus without having to go through
>> the mailman registration.
>> 3. Much nicer/convenient UI than the web archives pages; you can post
>> follow-ups directly.
>> 4. Rich collection of some 30000+ mailing list archives.
>>
>> The main drawback I've found so far is that server-side search facility
>> doesn't seem to be available yet in the new Gmane. Still, it's not too
>> long to load the full list of messages ever post to a list and use Emacs
>> or Gnus native features to search/sort.
>
> For several years I used and really liked gmane + gnus. I was shocked
> when gmane went offline at my vulnerability to something I had taken for
> granted. When gmane came back I found that the loss of search, which I
> relied on, was a killer. So I cooked up a workaround (see below). Gmane
> has been back, but, IMO, stagnant, for a year.  I say stagnant because a
> year has gone by with no new news posts and the gmane search is still
> not working. NNTP without search is, IMO, TOTALLY lame. This makes me
> wonder about the depth of support at gmane and whether it makes sense to
> rely on it going forward.
>

Well, having never been blessed to experience Gmane with a working
search, I guess that's why I find it useful nonetheless ;)

> My workaround is to download the mail list archives to a local maildir
> cache indexed/searched by gnus/notmuch/nnir and read with gnus +
> nnmaildir. I use a makefile and mb2md running in the background to do
> downloads and trigger indexing. While not elegant, this bit of hackage
> frees me from depending on gmane or any other 3rd party and has turned
> out to be very reliable. There is really only one hitch - it suffers a
> hit each time you (re)open gnus. Apparently gnus has a scaling problem
> with large nnmaildir directories. E.g., my 1.9G cache takes ~45 sec to
> open on a 3.4 Ghz E3 w/2500 MB/sec Samsung 950PRO SSD. This is not
> really a problem in my situation because I run on the server and leave
> gnus open all the time. The 1.9 G includes all the guix lists,
> emacs-orgmode and geiser-users. But if I followed more or bigger lists
> expect the gnus (re)open might become prohibitive.

That's an interesting solution, albeit a heavy one :). Thanks for sharing
it. On my too small of a SSD, I can't afford to keep gigabytes of
mailing list material around just for the occasional search, but I
appreciate that this would allow me to be independent from any service
such as Gmane.

> I could avoid the gnus open hit by reading the cache with the notmuch
> gui or indexing/reading the maildir cache with mu/mu4e (which I do for
> my email accounts) since then I wouldn't be using gnus at all. I guess I
> continue to read these lists with gnus because I got into the habit :-)
>
> Of course the best thing would be for gmane to restore search and to be
> managed by an organization that has dept and staying power. If that
> happened I would gladly discard my workaround because gmane was truly a
> thing of beauty when search worked.

I do hope that this will happen. Reading the last posts on the new Gmane
blog, it seems they had big plans. Big plans take time to materialize,
so I will show some patience, although it would be nice if they could
keep us in the loop more with more frequent posts on their blog.

Maxim