 various other bits and pieces of email. If any of you have got any questions while he's speaking, that's quite alright to interrupt. If you could just lift your hand up and I'll get this microphone to you. We need you to speak into the microphone for AV purposes. Over to you, Carl. Thank you. And any time is, I know you have other signs, but what time are we ending? 45 minutes. 45 minutes, perfect. Welcome. Is that picking up? I'm glad you're all here. I hope we'll have an interesting time together talking about email. I think email is one of my least favorite things and I wish I never had to read another piece of email. And that's what I'm trying to do with not much that I've been working on over the last year is to make it so I get to read even less email. And I have less in front of me all the time. That's my primary goal, is to get rid of email. So this is the program I've come up with that makes it faster to delete email than I've used before. So that's the big feature we're looking for is how fast can we delete email. So let me talk a little bit about the basic problem of email, why it is that email is so painful, why I'm so anxious to delete it, why other programs don't let me delete email as effectively, and what are some of the things I've been able to do with not much. So there's a lot of email. Most of us are probably getting, I don't know, hundreds of messages a day, thousands of messages a month, millions of messages in not too many years. There's just a huge flood and we can never hope to really read all of it. Yet at the same time, that would be easy enough if the answer were to just plain delete all of it. Every once in a while there is a particular message that's important. It's, I don't know, something very important that we will feel very sad about if we don't actually read that email on time. So I mean it might be important because it's got some time critical thing. We have to cash in our lottery ticket this weekend or else we don't get to claim the prize. It's actually worth something to us. I guess that person was time critical and valuable. Or sometimes we need, there's a particular piece of email that holds its value for a long time. We'll want to look back on it years from now and be able to find it. I mean sometimes that's just for humor's sake to look back at old emails from people. We'll talk about that later. But anyway, for one reason or another, those are some of the things that make a few emails valuable. And the problem is, once you have millions of thousands, hundreds of thousands, a million messages, how do you actually find those that are time critical? How do you find those that are valuable? And particularly, how do you find those that you received years ago? And you don't even remember exactly what it was again. And that's one of the hardest things in a lot of existing email programs is finding a particular message among years' worth of messages. I did a quick query using not much to see how much mail I've been receiving over the past few years. It was kind of an interesting graph. I don't know where some of the spikes and drops come from. I didn't do the analysis. I mean there was a few years there where I was receiving way too much email and somehow I cut it down again in 2008 or something and then it started to climb back up. So the general trend is still that I'm receiving more and more email from year to year. And I'm currently around 8,000 messages per month. Those are monthly numbers on there. So it just builds up. It's a lot of email. So some of the problems of many existing email programs that make this whole thing so painful is that a lot of them are folder-based. If you're receiving, you know, 100 messages a month, having it folder-based is not that bad. Or if you're only saving a year's worth of email, having it folder-based is not so bad. You can file things away carefully. You can remember where you put them and when you go to search for it, you can remember where to search. But once you have gigabytes of mail and thousands of folders trying to remember, oh, which folder might I have searched it in? Instead of getting, you have to, so the folder-based email program makes you choose which folder you want to search before you can start the search operation. So then instead of the search, instead of the email program actually finding things, you're having to manually do this order and search on your folders. Oh, nope, it's not in that one. Nope, it's not in that one. And that's pretty painful. There's a lot of scalability problems that email programs have when you have a lot of email. Historically, UNX and Linux-based mail programs use the inbox format. We heard about some of the pain in this morning's keynote. And inbox really breaks down when you have too many messages. You just have a single file that has all the messages in a particular folder. And so once that file gets too big, adding or deleting a message from the folder just gets to be really slow. Mailder is a newer mail format. Other ones are MH, both Mailder and MH format have a single file per message. It's not as kind to your system in terms of using up inodes, particularly if you have lots of small email messages. But it does allow for a much quicker add and remove operation for particular email. You can still run into Mailder scalability problems if you have a single Mailder folder and you put, you know, 100,000 messages into it. Your file system is probably going to get pretty sad about that. I keep being told that file systems are going to solve that problem and be super fast no matter how big a directory gets. But I haven't managed to find one on my system yet. So even with Mailder, there's some fiddling required to keep the, you end up being forced to separate into separate folders just to keep the, to avoid running into the scalability limitations. And finally, search, like I said, is often an afterthought feature in email programs. It's a secondary to the folder filing like I talked about before. And, or it's just not been implemented in a way that it's at all scalable to the amount of volume of email that I have to deal with at least. So, and so I think one of the points I'd like to make today is that if we have, if we have email programs that use search as their fundamental feature, then the, the world can be pretty different. Basically, look at all the drawbacks I had on the previous slide and those can all be eliminated if we just make search a fundamental feature. Instead of using folders to file messages, we can apply tags to particular message. They have an advantage over folders that you can have multiple tags for any given mail, mail message. Whereas within a folder, one mail can only exist in a particular folder. And you're not, tags really give you a superset of the folder functionality. Anything you did do with folders that was useful, you can still do. Sometimes the things you do with folders are bad because you end up, one of the failure modes that happens in email is you have a particular important folder and you have a lot of less important folders and those less important folders we can neglect and they just grow and grow and grow. And then you're more likely to neglect them. And you can still do that kind of, you can still have that problem with tags. You have to find workflows that avoid that. But anytime folder is actually useful you can use tags to do that. If you have an email program that uses search as its fundamental feature, the mail storage, the problem of inbox and mailer and file system scalability can be eliminated. This is something we haven't done. We've done some experiments with this and not much. We haven't done this as the mainstream approach. But we've had Stuart here, Stuart, last year during LCA went and wrote a patch to not match to make it actually store its entire mail archive as Git packs. So you have a nice compressed mail store that doesn't have any of those iNode or folder scalability problems and not much still works just fine. Because you don't need, since you have search, you don't need that direct access to be able to CD and grep like you might want to fall back on if you don't have a good integrated search. And finally, the key point I want to make about search is that once you base a workflow around search you can find new ways of doing things with email that you've never done before. There's entirely new mechanisms of processing it. And this is, I think, one of the most unexplored areas still. I mean, not much as a new project. We've been using it about a year. And I think just as we're starting to get pickup in terms of number of users and starting to explore the workspace of what kinds of ways you can do it. This is an area that's really right for finding new things. Okay. If you look back at the previous slides of the problems and the way search solves it, you might think, well, gee, it sounds like he's describing Gmail. It's tag-based, it's search-based, it's got all of these things. And it does have those things. Some of the problems that some people just can't use Gmail because they're either unwilling to or unable to actually put their data into the cloud, as it were. People have legitimate privacy concerns. They need their mail to stay on their encrypted laptop and not leave it. Also, with some of the point I was making about discovering new workflows and finding new ways of actually processing our email, a non-free web service doesn't actually let us explore those. But if we have a free software application, we have a lot of flexibility. So those are two of the reasons that for me, Gmail hasn't been an interesting answer and I've pursued something else. So now I'm going to talk about not much and how it's implemented these things. As you might surmise from the introduction, it uses search as its fundamental feature. That search is implemented based on the Zapien library. Zapien is the search engine library that backs Gmail. It's used by Debian for several different web infrastructure things and you can even have app to do some Zapien-based package searching. There's a lot of programs that are picking up Zapien. It's a really interesting library. I'll talk more about it in the next slide. It's... I'm going to do that and then I'm going to come back to it. Talking more about Zapien. It's a library that provides full text search capabilities. It's very much written from the point of view of say you'd like to build a search engine for a website. It provides interfaces in its library that are very natural for putting a search engine. On your website search engine, you want a single text input and you pass that texturing and then you get a bunch of search results. That's what the Zapien library presents as an interface that just take free form texturing and return a bunch of results. It's based around this information retrieval model where you have a bunch of documents. You have a list of documents that you've stored in the database. You have a list of terms and then you have cross links between those. Every document knows about every term that's indexed by that document. Every term has a list of all the documents that reference it and those links also can't have position information so that when you have sequential terms, good catch Steven, when you have sequential terms you can actually compare the positions and do phrase-based searching. You can put do quoted searches and it can find occurrences only where the words are within the quotes appear in that order. That's what I wanted to say about Zapien. It's a really, really great library. The maintainers are very responsive. Its performance is unbelievable. I don't even understand how it can function as well. My current not-much database is something like 6 gigabytes. It's way beyond the memory limits of my machine but I do long searches and they'll use tens of megabytes. I still don't figure out how it works but it maintains it. We'll demonstrate that in a little bit. What else about not-much? Not-much has three basic ways you can interact with it. We have at the lowest level a library interface that's written in C. That wraps around the Zapien interface that's actually in C++ so we hide away all those messy C++ things from you and prevent a really clean and simple C interface. If you have time I've got a slide that talks about what the C interface looks like. On top of that we have a command line interface that I think emulates a lot of the best things from the Git command line interface and that's sort of the level you can think about to build things on top of that. It's very, very scriptable at that level and it's usable in sort of a low level way like you might use Git show or Git log or some of these commands but probably not intended to be a primary way to access email. We expect interfaces to be built on top of either that command line interface or the library interface and either one of those is quite suitable for building a command line interface. We also ship not much with a fairly full featured interface for dealing with mail, reading it, replying to it, doing everything you would do with email that's implemented inside of Emacs and that was built on top of the command line interface. There are some other more experimental interfaces and I've got a slide about those later but the Emacs interface is our primary one that we are shipping today but I don't want anyone who's allergic to mail. There are other interfaces that would be really simple to hook up to your favorite mail client. A lot of people have expressed interest in having a not much backed mutt for example and some interested mutt user would sit down with me and ping that out. That would be a really interesting thing to see. Not much on the project itself. It was something I started in late 2009 on my own. That was probably also the last time I actually wrote a blog post on my blog. If you look at my blog it's raving about this email program called SUP. SUP was a curses based email program written in Ruby that really does a lot of the things I've been describing. It's a search based interface, it's got tags, it's got these things and actually is implemented on top of Zapien. I switched to SUP and was really impressed by a lot of the ideas in it but the implementation was lacking in several ways. Primarily the way I looked at it was that I was hooked forever and when I looked closer at it I said well Zapien is pretty fast. It can index these documents so pretty fast. Why is this taking so long? It was a Ruby mind parsing library that was sucking up an inordinate amount of time. I said okay that's the problem here. We've got this inefficient Ruby code. Let's replace that. So I started writing an indexer that would just call directly, it was like I offered the patch to the SUP folks and they said yeah that's interesting, it's a little bit faster, that's cool but we could probably optimize our Ruby stuff and we'd rather maintain stuff from Ruby anyway. So yeah, thanks anyway. And at that point I was also fixing a lot of interface bugs in SUP. They had a lot of problems. If you were reading one message and you started composing a new message or reply, it was single pained and you couldn't get back and it was a really interesting message without like postponing your draft and posting it away. I mean you had this sort of one message at a time view that was really frustrating and coming from someone who was used to Emacs where you can have lots of buffers and switch back and forth it was really uncomfortable for me. So we had been writing a bunch of patches to improve this interface and I got to the point where I said you know what I'm writing this Ruby code which I wasn't familiar with Ruby and I just used Emacs and just set it on top of this the C code I wrote and I might have an email program and a couple weeks later I did and so that's where not much started. Keith leaked it out to the community in November and suddenly I said oh my gosh I got to set up a web page and a mailing list and all these things. In the past year we've had 62 contributors join the project and actually have code merged into the tree. We've probably had a hundred people contribute patches and that's my fault but I haven't gotten around to the patches from the other 40 people but yeah we hit something like 2000 commits we've had five releases the 0.5 release should be available in any free software distribution you might happen to use so it's an app get install not much away yeah and it would be nice if we had a better maintainer I tend to disappear at times from the not much project but I'm trying to be better about that it's hard. Alright the name not much there's probably four reasons we named it this way it's been kind of fun to have a project named not much we have bad accidental jokes that show up all the time. One of the worst is when I wrote my performance review this year and my manager asked me what I did and yeah one of my major accomplishments was not much so that's that's kind of sad. The attitude that not much has about your mail is that it's not much no matter how much you have well we'll see Trich has a lot of mail we'll see if not he's able to change not much his attitude or not when he tries to his import also not much like I talked about our primary goal is to delete our mail to get that inbox down to 0 so that's what you should be presented with every time you sit down with your email program you shouldn't have much to deal with and like I said not much was really written as an answer to SUP so there's the natural SUP not much anyway and we can't forget it's really not much of an email program the email interface isn't the main thing it's really just a little piece of library infrastructure that we'd expect a real email program to be built around so that's the attitude people should have around it's not trying to be the whole solution it's just trying to take care of this critical piece of indexing your mail and letting you search for it I think I've probably hit on most of these there's a couple of examples of what the search syntax looks like various prefixes with colon that look like site colon like you do in a google search or something like that you can use double quotes for phrase searches we one of the interface ideas that Linus has made a big deal about in Git is that it doesn't matter how fast an operation takes timing an operation with the time command in the shell is not the really interesting operation the interesting question is how quickly do you get results back that you can start interacting with that's a really much more important question we have a similar approach with not much which I'll show you we have as soon as results start appearing instantly and you can start using them even if your search is returning a million messages and will take a minute or two to get around to returning all of those to you and we haven't yet really seen it fall over I'll show some big archives later in my demonstration and I'm sure that there's some scalability limit where it's just going to fall over but as far as we haven't hit it with anyone's personal collection of email so it seems to be keeping up pretty well with what we're throwing at it I gave a quick lightning talk about not much last year some big features have landed since then here's just a few of them and some of these have been just critical for people that people kept coming to me and saying I'm really interested in not much but why doesn't it do this I can't believe it doesn't do that and I just apparently have a strange way of using email that I didn't need email when I started not much was sorted into folders of about 10,000 files per directory just to keep the file system happy I didn't have any semantic information in the names of those folders and but a lot of people do they maybe have had their mail in Gmail they do an IMAP synchronization of that mail the Gmail IMAP synchronization takes all the tags and creates a directory on your file system with the name of each of those tags so people needed to get at that information so one of the things we added is we have a new folder colon wait it's the thing that you can search and so with that it's a trivial command to take all the messages in a particular folder and give them a tag so you can migrate from folder names to from your existing folder based index information to not much tags another one that people have that really wanted to work some people say yeah not much adds some really nice fast search capability but I'm just not ready to commit to it full time so I'm going to continue to use Thunderbird as my primary email interface but I want to be able to search occasionally and not much and for people who are going back and forth with two different email programs operating on the same mail store one of the things they really wanted was synchronization of these various mail that are flags one of the primary ones is there's a flag the character s is added to a file name to indicate that the mail program has seen the message so initially the so the problem that people would have is they would read a message and not much and they'd go back to Thunderbird and it would still show that it's unread so we've now fixed that when you read a message and not much it actually adds the s flag to the file name if you're using mail there and then you can see that in your other email program finally we added several different forms of output to improve scriptability really I've got an example here with not much search dash dash output equals files that's really handy for scripting operations like you see here you want to delete every message actually remove from the file system every message that has the deleted tag that's a simple one-liner that you can do and so having a scriptable email program is kind of fun I've never had one like that before it's been fun to play with a couple of features also that some people are just desperate for before they can switch to not much that aren't quite in yet is one is to be able to search on arbitrary headers the indexing right now indexes the to from subject headers it also uses the in reply to and references headers to construct the thread information but really the so I didn't index everything originally thinking I just wanted to keep the database small but I've talked to enough people that want enough different things you need to expand flag a lot of people need list ID somewhat delivered to what's that return path okay so instead of list ID okay so I mean that the idea is that will probably I might just blacklist a couple of uh headers that would just be noise I think in the database delivered for example looks really long and I don't think it's really useful for the kind of searching that not much allows so we're going to add that one soon it's not a hard patch it does change the uh it will require anyone to rebuild their whole database so it's kind of a we'll have a slightly painful flag day when that one goes in uh but that should be soon uh this other one having more uh natural syntax for date searches is going to be really handy this one is a patch that exists on the mailing list and it's just waiting for me to apply it I think I'll have it applied this week and that's going to be really handy because our current date syntax is well anyway it's it's your next time stamps it's kind of hard to type um okay um longer longer term features that we don't have like sitting on the mailing list is a really good story for doing synchronization people have telephones they want to check their email on they want to look at a web-based interface and uh check their email from wherever they happen to be and their laptop so we have this idea that you want to have um not much available in several places well moving the mail back and forth is really easy that can be uh an imap specific problem like offline imap or it could just be an rsync um and also on both sides it's really easy to index all the messages by just running not much on both sides so that's no problem the only piece that's missing is actually getting all the tags that you create on one side to the other side that's really the only information that doesn't exist in the mail store itself so that not much can find it so one one hack that someone has done is to actually solve that problem directly by taking the tags and actually putting them into the mail store they these the X label header and write it that way um some people are kind of scared about that because if they say well if I tag something and then I forward this message I'm gonna actually leak out my tags to people and maybe I maybe I would offend someone by saying you know I don't know to be ignored or something and I don't know I just have some other incriminating information in their tags we've had some other ideas we've had um you know we had the idea that not much could keep a journal of all the tag operations it makes and two different repositories could could replay their journals we've had ideas with using get protocol to push those back and forth so there's a lot of different ideas here it's an issue we know we need to solve one way or another we're not sure exactly how we're going to do it we have a question yeah um just wondering this is a question for everybody is there are some kind of standardized metadata storage that you could use like a you know database that's specific for adding metadata to individual files I'm at some I'm at some I'm at client says you had tags that's one um uh it's the dovetail for example um uses uh an extension of the mail their specification to add particular letters to file names and then as a mapping between those particular letters and um tags you might have um that's what it does on the on the storage side of it I think I'm at protocol which I've never looked at that's one of the other things I when I said not much is not much of an email program not much doesn't send mail not much doesn't receive mail and I'm so glad to stay away from any of that so um I think there's some something in the I map protocol itself as far as adding tags so so we could maybe oh I don't want to add I map support to not much but that might be another approach to synchronization the file the mail their file name approach might be a way to do it as well if we have uh I map syncing things so uh lots of different ideas there and if someone comes up with the obvious thing and implements it that'd be great um I'm going to switch gears and I'm going to get to our demo so um I think I've mentioned most of these things already I'd love for someone to write a web interface for not much it should be really easy we already have a dash dash um format equals JSON uh command line options to actually get JSON and I'm told that these there's a lot of web authors who love JSON input and would just could just turn that into fancy HTML and make it all cool whizzy and I don't do that kind of thing but I'd love to see someone else do it also integration with your favorite email program that's a project anyone could do okay good demonstration any other questions first before I go on there's a microphone there thank you uh that's on I'm weird I like the inbox format um and do I have to convert all my mail to um mailed her to uh switch to using not much right now if your mail isn't an is an inbox yeah you're going to have to blast it out there's an inbox to m d script that does a good job of that and uh okay that's that's right maybe I'll do it give it a try see what you think all right so uh I'm gonna let's see if this demos all work today uh just export a different configuration so I don't expose all my personal email here and we'll run not much we'll say not much uh I tried to make the introduction not much be pretty painless it kind of walks you through these various steps you can just keep running the not much command and it does different things according to what what what the right thing to do is next so the first time here I ran not much it actually ran not much setup I could have run that manually and it asked me a few questions my name my primary email address do I have any other email addresses where all my mail is stored and for this case we're going to say I'll see you to money 11 dash chat uh that the next question is when new mail is incorporated what tags should be applied by default and by default we say unread an inbox which makes sense any new messages should go into my inbox and I haven't read them yet so now not not not much is all configured and it tells me I should run not much new I forgot that I just run not much and it says no you really need to run not much new so run not much new and it starts incorporating my mail it scans it all finds counts how many files it uh does and and starts the indexing operation that doesn't take too long yeah we have a small this is I think all of the LCA 2011 chat mail it's like you know a thousand messages and it took 11 seconds so now we can do some searches if you wanted to find something important like I don't know might be an important thing to find when you're here at LCA you can find that yes someone did give us a message and told us where to find the toilet paper um so you can see that the the output here I got one line per thread and the the first term that I get back from that is a thread ID and so it's kind of like pasting you know get rivet get commit IDs you can then say not much show and then you will we'll see the actual message here and so there's the there it is sure enough toilet paper isn't provided so I can get get access to my critical information I can find out where to get the toilet paper um so there's not much search there's not much show um we can do um tag operations to add a tag to um a particular message so here I'm saying I want to add the important tag to um all the messages in that thread whoops and it's just added that so now if I and I can say I want to count all the messages that have the important tag and it says there's 11 messages so there's just a few of the command line operations you'll see it's um notable that every command line interface to not much accepts search parameters no even a command that it seems like it would be natural for it to accept a single message like not much reply constructs a default reply template to a particular message often we would call that with a single message ID if I look back at the not much um not much show result this has a message ID and it's you know just from the message ID header and so if I do not much um if I do not much show of that um message I get just that one single message here in the result but um at the same time you can say not much show uh with a search term that return to a million messages and it would do the same thing so every command takes accepts a consistent search interface um syntax and every command is smart enough to figure out something reasonable to do even if it has multiple messages so you can reply to a whole thread and it constructs a buffer that's a reply to the content of all of those messages maybe not really useful but that's the consistency we have um so that was a small uh archive let's go to a slightly bigger one now I'll run not much new this archive um I got uh a good friend Ali Betts who maintains the vaping interface and also keeps gmain running I got him to supply me with all of the LKML uh messages in the gmain archive uh so these start from about 2002 and go to about last Sunday and that's going to take a while so let me interrupt that and tell it to go faster um okay that's better okay that if it's not obvious that was a hand demo I now switch to everything you saw before that last command was actually real not much commands that one I just went to something I indexed overnight let's say um you saw that it was predicting that it was going to take two hours there uh there's uh not much the zp interface as the database gets bigger or as I have memory leaks I don't know there's it's slowing down a little bit and it's it that initial estimates not very accurate in that case it probably took closer to 18 hours not two hours um but now that we have that we can start doing some commands let's count all the messages that are available also have a million messages let's count all the messages that were written um to linus and there's 75,000 messages and those those kinds of things um what else might someone be interested in searching for in the linux kernel mailing list any suggested search strings here was that panic yeah that's a good one so we can have panic and then we could do um kernel panic let's see if we can find that phrase anytime as a as a phrase you see the phrase searching is taking quite a bit longer and this archive is actually one where I am hitting for the first time some scalability limits I've never had a phrase search take that long on my archive uh if we look at the size here it's kind of interesting to see uh lkml indexed uh not much zapien uh 11 gigs and if we look at my mail not much zapien with 6 gigs um unset not much config let's run the same search on my mail yeah good idea significantly faster so I don't know if somewhere between 6 gigabytes and 11 gigabytes I hit some scalability limit and then we're starting to to thrash on memory or something anyway there are some interesting performance things when you get archives that big let me now show the um emacs interface what it looks like this is again this is with that same uh linux kernel mailing list archive if I did the initial import this is what you'd see you'd see 1 million messages in your inbox perhaps a rather daunting prospect um this would be a case where it'd be really handy to have some really nice date searches and you have all of your messages in your inbox what you might want to do is run a command like not much tag minus inbox um before uh one month ago or something like that and so that's the syntax we don't have right now um if you actually you could actually do something insane like say date da plus percent s 11 11 01 01 and actually you could actually construct these little unix times that but I said that's not really usable um but we we'll get the same date syntax soon so going back to the emacs interface um we tried to make it look a lot like uh an easy to use search interface where the the the search bar is sort of front and center that's the primary way of getting at this thing and if we do a search we can do something like we did before we can see messages addressed to leanness and they come out and it's it's going to be what this was like 80,000 messages it's probably still streaming these down below if we go to the end of the buffer we can see yeah they keep coming in coming in coming in um but meanwhile while those are coming in we can ignore that fact and we can easily browse up and down I've changed the display format um I've kind of trimmed it down to fit in the the number of columns I have here so I'm just displaying right now the date and the subject normally we have like authors and how many messages are in the thread and so I'm getting one result for every thread here and then we can go into the thread and actually see the message um see the thread um um let me do a different search and and then I'll go go do that again hold on so I want to come back here to now now that we've done a search it's showed up on our recent searches um less and so you just have a list of things that you searched for recently and if you really like that you can hit save and it says uh what's the name you'd like for this search and say this is uh messages sent to Lina's and and so now that's been added up above to one of these folders so at the top we have the inbox folder the other folder and now the to Lina's folder those aren't really folders in the sense they're just each a configured search and if we hit the edit button we can see um uh that that didn't work um we should be able to see the configuration of those Emacs is a little confused and no it's not confused it's accurately actually it's actually doing showing all of my saved folders um so this this is how what what I have set up right now um I have uh inbox is anything that's got the inbox tag uh messages sent to me um bulk messages messages that are sent to uh no mailing list that I want to sort of read once a day and get through quickly and some of these things um I'll show you more about how I deal with mail in a little bit so let's go back and we'll search for all messages no that didn't work and we'll do that in the other order so we get the newest messages first and well anyway here's an intel graphics uh message so this might so um perhaps I'm interested only in intel graphics mail and so now that I've done this search I can tell it to filter I want to see only messages that have intel graphics in the subject line and it's now appended that to the search terms and redone it so and then I can say okay and I'm only interested in messages that that also say patch in the subject so now I'm down to just uh quickly down to a few messages and um now I might start going through these and viewing them I could pipe the message to get AM or you know I could cd to cd to some directory um you know intel you know whatever whatever my linux kernel is and uh and pipe it off and have it have it apply the patch um one of the other ways uh some of the ways I look at mail is um if I wanted to read through all of these messages one by one I could um view it and as I go through here I can hit the A key to archive the message archiving it takes off the inbox tag and then advances me to the next message so I'm gonna archive archive archive and as I come back here if I refresh this view several of those messages have now um disappeared uh but often you can if you're doing some bulk processing of email if I'm looking at mailing lists it's easy enough to just sort of skim through the message maybe there's one or two messages I want to to one or two threads I want to look into but everything else I just want to remove it from my inbox we hit the star command say minus inbox and now all of those messages have been removed from my inbox and you can very quickly process process mail and get things out of my inbox that's um probably easier to see on my own mail so I can just show you something realistic here so then I've added two linus clear these recent searches edit this delete the two linus anyway so just before I came to to give this talk I refreshed my mail and I got there were 10 new messages in my inbox besides that I have 60 messages that are queued up you might have seen earlier that my my inbox folder doesn't include any not much because those were kind of getting in the way because I really far behind in my patch management so I have 60 messages over here and not much that are waiting for me to go in and review the patches and merge them meanwhile I have three messages that I've tagged as home meaning these are messages that are basically on my to-do list but they're items that I can't do anything with until I'm home so I don't want to see them in my inbox but I actually will just wait to get home similarly I have five messages tagged office the next time I'm in the office I'll go in and look at those but otherwise I don't have to see them so I might go into my inbox view here so again if I'm just archiving I'm hitting the a key one at a time and you can see that over on the right it's popping the inbox tag off of each of these and now I've just read all those messages and it's done that's a common way for me to process mail is particularly if those were all in my other folder it's different when messages are addressed directly to me so I'll use a different mode for messages that are addressed directly to me where I'm actually viewing the bodies before I'm archiving them but we try to make it really easy to delete mail we have all of these so you know these big bulk operations I'm almost out of time but I want to take any other questions that people have Trig can you say a Crock-Mile script to automatically tag things on the way in so they come in already tagged with appropriate tags based on Crock-Mile expressions yeah excellent question let me show you what I'm doing with incoming mail I have a script that I named not much poll and it actually first runs not much new to actually import new mail into the database and then it runs a whole bunch of tag commands that do these searches and it looks like it's a lot of work but if I actually run this script so the import is going to take a little while here it scans looking for new mail and then the actual tag operations shouldn't take very long so I'm doing all of my searching for the kinds of things you would do in Crock-Mile inside not much itself if you actually are using Crock-Mile and have those rules you could similarly apply not much tag commands and one of the operations that someone who's doing exactly that has proposed is a command that would effectively do what not much new does but not much new scans everything that looks for messages that have appeared in a Crock-Mile delivery case you know oh I've got this one file I just added it and I want to add it with these tags so it's they're adding a not much new that actually accepts a file name with a tag and can do that without any of the scanning would be much quicker so that's a patch that I need to merge how does this compare to Glimpse is it compared to what? Glimpse? I'm not familiar with Glimpse so I can't say I have University of Arizona built on top of Agrep has the nice property that it does fuzzy matching and Glimpse is in fact a builds a database kind of like you might want to look at it yeah definitely thank you thanks for that recommendation I think we probably have time for one more question Tridger's point there's not much deliver which is a tool that people drive out of Crock-Mile or out of MailDrop which instead of letting Crock-Mile actually deliver to the MailDirt don't pipe it through this instead and it will call not much library underneath and then deliver it to the MailDirt for you right yeah so there's that additional that tool does exist as a separate tool utility not much deliver that does the delivery and the tagging I don't have it merged into our repository but a lot of people are using it successfully already well anyway thank you very much for coming I hope that was useful thank you very much Carl another fascinating talk I thought first off I present you with a bit of toilet paper for Urban Village in case you get bored short and an appreciation gift there for our talk it's a bit smaller than the ones they gave out in the main hall but it's a much smaller one thank you very much appreciate it