I am frequently struck by how many people arrive on the Arch boards without any understanding of how Arch is different from the other GNU/Linux communities they may have spent time with (if, indeed, they have spent any time in another community before trying Arch). For me, this is akin to arriving in a foreign country and not bothering to familiarize yourself at all with the local mores and customs; it lies on a spectrum somewhere between ignorance and outright arrogance.

The result, inevitably, is that these people are shocked when their expectations of how they should be treated are at odds with the reception their behaviour invites…

Before venturing any further, I should preface my remarks about this with something of a disclaimer. These are my own views and not those of the current, or past, forum staff.

One of Arch’s significant acheivements is the quality of its documentation. Not just the technical documentation describing how to install and configure Arch, but the cultural documentation that sets out Arch’s philosophy and standards of behaviour. Both these pages provide clear statements on what to expect when using Arch Linux and a clear indication of how to respectfully interact with the community when you are seeking help.

The defining statement about Arch’s intended user base is quite direct and unambiguous:

Arch Linux targets and accommodates competent GNU/Linux users
by giving them complete control and responsibility over the system.

The expression “targets and accommodates” doesn’t exclude other users—for example, those that are not necessarily competent, but are wanting to learn more about the specifics of how their machines work—it does, however, signal quite explicitly what sort of community Arch is. And what it is not.

Ubuntu is an excellent distribution. Like Arch, it has very specific aims and a clear concept of what the Ubuntu community is. Popularity is central to Ubuntu’s culture. People coming from Ubuntu, who haven’t bothered to familiarize themselves with Arch’s values, often struggle to appreciate the difference; leading to comments like this one:

Maybe if Arch is friendly and Arch forum is friendly, it might go some
place, who knows…

This was posted in reply to a post on Arch in which the author noted how to seek help with Arch Linux:

You'll find far less hand-holding on the Arch Forums than some of the other
distro's forums, and for good reason.  Arch has one of the most informative,
user-friendly wiki's out there. Do not, I repeat, DO NOT ask a question in the
forums or on IRC without searching the wiki and the forums first.

Similarly, looking through the threads in Newbie Corner will periodically turn up new posters who are indignant at being told to RTFM and see it as some sort of personal attack, when in fact it is just someone pointing out the obvious to them. The community hasn’t compiled all that documentation just so they can sit around and regurgitate answers for people who are either unwilling or incapable of making the minimum amount of effort required to solve their own problems…

If you want handholding, there are plenty of online communities that will cater for you. If you install Arch and think that you are automatically entitled to immediate support for issues that you encounter, then you are mistaken. If you think that Arch will suffer if you don’t get what you want, then your problems extend significantly beyond your choice of distro.

The community has worked hard over the years to keep the signal-to-noise ratio on the boards high, that way, the forums remain a helpful resource for the community, not a breeding ground for help vampires.

Notes

Flickr Creative Commons image by si_si_ay

Seeing as I have been focussing on my mail client, I thought I would round out the trifecta of Mutt posts¹ with what I am assuming is the final piece of the puzzle: searching mutt's maildirs. For a small to average size mailbox, mutt's searching works fine, but as your mail volume grows this simple search doesn’t really scale. That’s where the rather modestly named Notmuch comes into play.

It can be run as a standalone mail client, but you can also use it with mutt to provide a ruthlessly efficient and fast search tool for your email. I had looked at it and Sup a couple of years ago, but was spurred to do something about it this week when Gunnar Lundström pinged me on twitter and suggested I check it out. So I did.

"Not much mail" is what Notmuch thinks about your email collection. Even if you receive 12000
messages per month or have on the order of millions of messages that you've been saving for decades.
Regardless, Notmuch will be able to quickly search all of it. It's just plain not much mail.

There was previously a mutt-notmuch script for integrating the two, but the functionality was included upstream at the start of this year so it is quite straightforward to set it up. There is a package in the AUR but it is intended as the full mail client, complete with, shudder, emacs support amongst other things. I have stripped out the uneeded bindings and included the relevant perl libraries in a modified PKGBUILD if you just want the basic search with mutt.

Otherwise, you’ll need to step through it manually.

1
2

pacman -S perl perl-mailtools perl-mail-box perl-string-shellquote
cowerd notmuch perl-term-readline-gnu

As you will see from the PKGBUILD, you will need to copy the notmuch-mutt script into your $PATH: you’ll find it in contrib/notmuch-mutt/.

There is a simple interative setup, which you can complete before running the index the first time:

1
2

notmuch setup
notmuch new

The final step is to copy across the mutt macros included with the script:

1

cat src/notmuch-0.13/contrib/notmuch-mutt/notmuch-mutt.rc >> $HOME/.mutt/muttrc

Now, from within mutt, F8, F9 and F6 will respectively search, create the relevant threads from search results, and tag mails with notmuch.

As I use offlineimap to retrieve my mail, I simply added notmuch new to the script that runs as a cron job to synch my mail and notmuch reindexes all of my mail as soon as it arrives.

Updated 27/5/12

Two of the mutt macros that are shipped in contrib/notmuch-mutt/notmuch-mutt.rc do not work. I have written a patch to fix this and posted it to the ML.

Notes

1. Using Mutt, LDAP and SSL and Mutt and HTML email

Creative Commons image by mjtmail on Flickr

Following on from my last post about Mutt, I have been tinkering more with the most suckless of mail clients to get it to deal with—of all things—HTML emails. I will preface this post with a remark or two that amounts to a warning about intemperate language, ranting and a generally cranky disposition: repeated contact with email marketers can do that to you…

A further brief digression is warranted here. HTML email is, without doubt, evidence of the imminent end of civilized life as we know it; much like the Golgafrincham diaspora, it is attributable to a depraved cabal of marketing consultants and provides the same level of social good as syphilis and fistulas. Suffice to say, it is a blight.

Sadly, it is a blight that I have to deal with. Up until now, I had done that by using the excellent w3m to render HTML as text in Mutt itself. That is accomplished easily enough with an entry in muttrc and another in a mailcap file.

1
2

auto_view text/html                                      # view html automatically
alternative_order text/plain text/enriched text/html     # save html for last

1

text/html; w3m -I %{charset} -T text/html; copiousoutput;

This works for 80 percent of the HTML email I get. It is enough to confirm that the mail is useless and can be discarded. The other 20 percent, however, is slightly more problematic. The initial view in w3m is enough to tell me that, due to the outstanding incompetence of the idiots that generated the email, there is actually some information that is contained in the email that I need to access but it is not viewable in a text browser.

For this special level of retardation, I need to be able to open the email in a graphical browser. As I use vimprobable, that means sending the file to vimprobable running in tabbed. Fortunately, as you would expect with superior software, mutt has a way of handling this gracefully. In Mutt’s extensive documentation, there is a page on Mutt’s MIME support that details how to set up a graduated response to this pernicious issue:

In addition, you can use this with Autoview to denote two commands for viewing
an attachment, one to be viewed automatically, the other to be viewed
interactively from the attachment menu.

So, you can have mutt render the HTML abomination in w3m in most cases, and when those instances of particularly cretinous behaviour make it to your inbox, you can choose to view them in your web browser. In my case, by altering the mailcap entry to look like this:

1
2

text/html; vimprobtab.sh %s &; test=test -n "$DISPLAY"; needsterminal;
text/html; w3m -I %{charset} -T text/html; copiousoutput;

The first entry tests that X is running, and if it is, it hands the file to vimprobable. The default, however, is determined by the copiousoutput tag. So, in mutt it is just a matter of hitting v to view the attached HTML and then m to send it to mailcap. For convenience, I bind Enter to that function in muttrc:

1

bind attach <return>    view-mailcap