Re: [opensuse] KMail on 12.3
On Mon, 19 Aug 2013, Mark Tinka wrote:
Hi all.
I'm still running openSUSE 11.4 because the last time I attempted an upgrade to 12.1, it ended in tears where KMail2 was such a surprise, particularly how it got so bundled with Akonadi and friends.
I ended up reverting to 11.4 and have been there since then.
However, I can't help but feel like I'm not enjoying any advances in KMail and other applications on openSUSE, given I'm on a release that is no longer being supported.
My main issue is KMail. Does anyone know whether the migration from KMail on 11.4 to KMail on 12.3 is now behaving? One issue I saw was some kind of problem between how KMail and KWallet are integrated in 12.3.
Any useful feedback would be much appreciated. Thanks.
Cheers,
Mark.
I tried kmail2 a few times. But each time some problem has undermined my confidence and I returned to kmail/kdepim3. As I recall I think the most recent issue was lack of search or slow search. I'm now running the 12.3 KDE3 kmail that is available in 12.3 kdepim3 package. I did find converting to kmail2 is now fairly easy. I had kdepim3 kmail convert all mbox folders to maildir. I then moved the old dir to somewhere safe. After starting with a fresh kmail2, I imported the old folders. The only downside with this approach to conversion is that after importing all my folders I had to manually shift-click bunches of folders and mark all contents as read. I don't want desktop nepomuk desktop indexing, I think this is why I'm not getting along with kmail2. As long as kmail/kdepim3 is provided I think I will just stick with that. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
Hi all. Thank you all for your invaluable feedback. It sounds like there have been some issues that have been fixed since 12.1, and that KMail is still a better option than KMail2. Best I'll do is install 12.3 in a new virtual machine (I run openSUSE on Mac OS X within Fusion), and migrate the folders across to that VM and see how it goes. If it doesn't work, I'll just relaunch my 11.4 VM. I run KMail because I still - after nearly 6 years - can't find a decent MUA that supports both Maildir and PGP. Outlook is MBOX style (and it's Microsoft). Apple Mail is Maildir style but uses a proprietary method (.emlx). Thunderbird has great PGP support but no Maildir (still can't believe that, after all this time). OperaMail has good PGP support but no Maildir. It's all here for those who are interested: http://en.wikipedia.org/wiki/Comparison_of_email_clients If I supported GNOME, I'd use Evolution, but I still find KDE better for me. Again, appreciate everyone's feedback. Cheers, Mark. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On Mon, 19 Aug 2013 02:46:56 -0700 (PDT) Mark Tinka wrote:
Hi all.
Thank you all for your invaluable feedback.
It sounds like there have been some issues that have been fixed since 12.1, and that KMail is still a better option than KMail2.
Best I'll do is install 12.3 in a new virtual machine (I run openSUSE on Mac OS X within Fusion), and migrate the folders across to that VM and see how it goes. If it doesn't work, I'll just relaunch my 11.4 VM.
I run KMail because I still - after nearly 6 years - can't find a decent MUA that supports both Maildir and PGP. Outlook is MBOX style (and it's Microsoft). Apple Mail is Maildir style but uses a proprietary method (.emlx). Thunderbird has great PGP support but no Maildir (still can't believe that, after all this time). OperaMail has good PGP support but no Maildir.
It's all here for those who are interested:
http://en.wikipedia.org/wiki/Comparison_of_email_clients
If I supported GNOME, I'd use Evolution, but I still find KDE better for me.
Again, appreciate everyone's feedback.
Cheers,
Mark.
It took a little work but I managed to switch to Claws Mail from KMail a couple of years again and I'm really glad I did. http://en.wikipedia.org/wiki/Claws_Mail -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 08/19/2013 05:46 AM, Mark Tinka pecked at the keyboard and wrote:
Hi all.
Thank you all for your invaluable feedback.
It sounds like there have been some issues that have been fixed since 12.1, and that KMail is still a better option than KMail2.
Best I'll do is install 12.3 in a new virtual machine (I run openSUSE on Mac OS X within Fusion), and migrate the folders across to that VM and see how it goes. If it doesn't work, I'll just relaunch my 11.4 VM.
I run KMail because I still - after nearly 6 years - can't find a decent MUA that supports both Maildir and PGP. Outlook is MBOX style (and it's Microsoft). Apple Mail is Maildir style but uses a proprietary method (.emlx). Thunderbird has great PGP support but no Maildir (still can't believe that, after all this time). OperaMail has good PGP support but no Maildir.
It's all here for those who are interested:
http://en.wikipedia.org/wiki/Comparison_of_email_clients
If I supported GNOME, I'd use Evolution, but I still find KDE better for me.
Why not use Evolution in KDE? It will work. Yes, it will need to install a bunch of lib's but it will work. -- Ken Schneider SuSe since Version 5.2, June 1998 -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
-----Original Message-----
From: Ken Schneider - openSUSE
If I supported GNOME, I'd use Evolution, but I still find KDE better for me.
Why not use Evolution in KDE? It will work. Yes, it will need to install a bunch of lib's but it will work. -----Original Message----- It really _does_ work: using evolution-3.4.4-1.1.1.i586 right now... (on 12.2) -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 El 2013-08-19 a las 02:46 -0700, Mark Tinka escribió:
I run KMail because I still - after nearly 6 years - can't find a decent MUA that supports both Maildir and PGP. Outlook is MBOX style (and it's Microsoft). Apple Mail is Maildir style but uses a proprietary method (.emlx). Thunderbird has great PGP support but no Maildir (still can't believe that, after all this time). OperaMail has good PGP support but no Maildir.
I find Maildir inefficient. :-p Anyway, you can run dovecot as local imap server for storage, and then use any mail client you like - even all of them at the same time. I'm doing that, and this is a laptop... - -- Cheers Carlos E. R. (from 11.4, with Evergreen, x86_64 "Celadon" (Minas Tirith)) -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.16 (GNU/Linux) iF4EAREIAAYFAlIbQxcACgkQja8UbcUWM1w9LQD+PpXjO2MTGPkBO1A2nUs3r4R2 Y3HXObotoJM7SHBJbIYA/2SQmEBE4npWT1tEyqq6ba0cHYsdDf+k3alou/znwlnj =t92d -----END PGP SIGNATURE-----
Carlos E. R. said the following on 08/26/2013 07:59 AM:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256
El 2013-08-19 a las 02:46 -0700, Mark Tinka escribió:
I run KMail because I still - after nearly 6 years - can't find a decent MUA that supports both Maildir and PGP. Outlook is MBOX style (and it's Microsoft). Apple Mail is Maildir style but uses a proprietary method (.emlx). Thunderbird has great PGP support but no Maildir (still can't believe that, after all this time). OperaMail has good PGP support but no Maildir.
I find Maildir inefficient. :-p
+1 for the appropriate definition of 'efficient'. Actually I think that's wide enough. Maildir consumes inodes and I've always found that its difficult to get a good balance of inodes to data with the ext? family of file systems. Rather than waste time doing admin work fiddling and rebalancing (If I wanted to be an IBM/CICIS system administrator I wouldn't have chose UNIX) I use ReiserFS and BtrFS. They work, are robust, don't need fiddling with for journalling and crash recovery - the "just work". Every time I use ext? I get hassle with inodes vs data. Maildir rather that mbox will just aggravate that. TMMV.
Anyway, you can run dovecot as local imap server for storage, and then use any mail client you like - even all of them at the same time.
I'm doing that, and this is a laptop...
I've been doing it for years. Dovecot is another one of those wonderful programs that once you set it up 'just works'. I was at a presentation by Cisco and VMware last month and one of the people there was an admin running a multi-seat environment. In my time I've set up variations of multi-seat UNIX/Linux; LTSP, PXE and multiple terminals to the one host. What struck me first was how inefficient running MS-Windows under VMware with RDP was compared to any of the ways I'd done multi-seat in the past. Even RDP with Xvnc uses shared libraries and is lighter on RAM, to say nothing of the efficient sharing of libraries in the applications. And the process switching is lighter and therefore faster. But what struck me was how that site admin _boasted_ of how he had to be there tuning and tweaking as the load profile & demand changed though the day, and more. Fun for Geeks, yes, but when I look at the overall trends in business its about getting things done. Part of the selling point of tablets and smartphones and some of the pre-Balmer versions of Windows was that they "just work". I realise that there are many people out there who enjoy fiddling with the guts of systems; I do too. But that isn't the way production systems in business should be run. They should 'just work' and keep working. They need to be stable and predictable. No surprises. No need to fiddle and tune and optimise. -- /"\ \ / ASCII Ribbon Campaign X Against HTML Mail / \ -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 El 2013-08-26 a las 08:15 -0400, Anton Aylward escribió:
Carlos E. R. said the following on 08/26/2013 07:59 AM:
I find Maildir inefficient. :-p
+1 for the appropriate definition of 'efficient'.
Actually I think that's wide enough. Maildir consumes inodes and I've always found that its difficult to get a good balance of inodes to data with the ext? family of file systems. Rather than waste time doing admin work fiddling and rebalancing (If I wanted to be an IBM/CICIS system administrator I wouldn't have chose UNIX) I use ReiserFS and BtrFS. They work, are robust, don't need fiddling with for journalling and crash recovery - the "just work". Every time I use ext? I get hassle with inodes vs data. Maildir rather that mbox will just aggravate that.
Right. I keep a largish local nntp storage (from opensuse nntp forum) with leafnode, stored on a reiserfs partition, and it takes a huge time to do a local text search. Millions of files to look at. Btrfs? I don't know how it compares to reiserfs in terms of small files.
Dovecot is another one of those wonderful programs that once you set it up 'just works'.
Yep. Well, I have to do some adjustements for the new version, though.
But what struck me was how that site admin _boasted_ of how he had to be there tuning and tweaking as the load profile & demand changed though the day, and more. Fun for Geeks, yes, but when I look at the overall trends in business its about getting things done. Part of the selling point of tablets and smartphones and some of the pre-Balmer versions of Windows was that they "just work".
Indeed fun, but not for a job: it becomes routine and boring. Computers should be better than people at routines.
I realise that there are many people out there who enjoy fiddling with the guts of systems; I do too. But that isn't the way production systems in business should be run. They should 'just work' and keep working. They need to be stable and predictable. No surprises. No need to fiddle and tune and optimise.
Absolutely! - -- Cheers Carlos E. R. (from 11.4, with Evergreen, x86_64 "Celadon" (Minas Tirith)) -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.16 (GNU/Linux) iF4EAREIAAYFAlIbTs8ACgkQja8UbcUWM1z4rAD/SRxrpwBIEoSFWEOtuKZMbIHe F7tBbDtiqxfbqtw/LisA+gK6clq4CEsXrzkERJ2aXwRRPt6A75Hpff44Y7/o/vr1 =HH08 -----END PGP SIGNATURE-----
Carlos E. R. said the following on 08/26/2013 08:49 AM:
El 2013-08-26 a las 08:15 -0400, Anton Aylward escribió:
Carlos E. R. said the following on 08/26/2013 07:59 AM:
I find Maildir inefficient. :-p
+1 for the appropriate definition of 'efficient'.
Actually I think that's wide enough. Maildir consumes inodes and I've always found that its difficult to get a good balance of inodes to data with the ext? family of file systems. Rather than waste time doing admin work fiddling and rebalancing (If I wanted to be an IBM/CICIS system administrator I wouldn't have chose UNIX) I use ReiserFS and BtrFS. They work, are robust, don't need fiddling with for journalling and crash recovery - the "just work". Every time I use ext? I get hassle with inodes vs data. Maildir rather that mbox will just aggravate that.
Right.
I keep a largish local nntp storage (from opensuse nntp forum) with leafnode, stored on a reiserfs partition, and it takes a huge time to do a local text search. Millions of files to look at.
I don't know about NNTP, but email is usually indexed, at least by date, most likely subject and sender and possibly by mail-ID. Dovecot also has the option of using something like Plucine for full text indexing for the body. IIR NNTP headers aren't that different from email headers; perhaps dovecot could be persuaded to manage and index those files :-)
Btrfs? I don't know how it compares to reiserfs in terms of small files.
Target is 'same or better'. I have no complaints about performance; I just wish the fsck on boot actually did something :-/
Dovecot is another one of those wonderful programs that once you set it up 'just works'.
Yep. Well, I have to do some adjustements for the new version, though.
Sadly 2.x is radically different from 1.x in many ways. :-(
But what struck me was how that site admin _boasted_ of how he had to be there tuning and tweaking as the load profile & demand changed though the day, and more. Fun for Geeks, yes, but when I look at the overall trends in business its about getting things done. Part of the selling point of tablets and smartphones and some of the pre-Balmer versions of Windows was that they "just work".
Indeed fun, but not for a job: it becomes routine and boring. Computers should be better than people at routines.
And 'smart' enough to 'tune' themselves.
I realise that there are many people out there who enjoy fiddling with the guts of systems; I do too. But that isn't the way production systems in business should be run. They should 'just work' and keep working. They need to be stable and predictable. No surprises. No need to fiddle and tune and optimise.
Absolutely!
A mind is a terrible thing to waste when a computer could be programmed to do that boring, fiddly jobs so much better. Computers don't get distracted, don't turn of for work late with a hangover, don't have BOFH mentality (no, really). As Norbert Weiner said "Render unto the computer the things that are the computer's and unto man the things that are mans'". Doing the computer's job is no job for humans. -- How long did the whining go on when KDE2 went on KDE3? The only universal constant is change. If a species can not adapt it goes extinct. That's the law of the universe, adapt or die. -- Billie Walsh, May 18 2013 -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 El 2013-08-26 a las 09:44 -0400, Anton Aylward escribió:
Carlos E. R. said the following on 08/26/2013 08:49 AM:
Right.
I keep a largish local nntp storage (from opensuse nntp forum) with leafnode, stored on a reiserfs partition, and it takes a huge time to do a local text search. Millions of files to look at.
I don't know about NNTP, but email is usually indexed, at least by date, most likely subject and sender and possibly by mail-ID. Dovecot also has the option of using something like Plucine for full text indexing for the body.
IIR NNTP headers aren't that different from email headers; perhaps dovecot could be persuaded to manage and index those files :-)
Yes, there are indexes. There is the folder "/var/spool/news/opensuse/org/help/applications/", for example, with 12000 files, each one a single post, complete (headers and body). But there is also a ".overview" file which is, I guess, a binary index of those posts. And there is also the folder "/var/spool/news/message.id/", which contains a thousand directories named "000" to "999", and each directory contains many posts, or none, each a single file with headers and body. I guess that those files in the first structure are hardlinks to those in the second structure. There is not a content index. If I want to do a body text search, I have to do a filesystem grep on one of the structures, and it takes ages. Likewise, thunderbird does not offer to do body text searches.
Btrfs? I don't know how it compares to reiserfs in terms of small files.
Target is 'same or better'. I have no complaints about performance; I just wish the fsck on boot actually did something :-/
Ah, yes, that is keeping me out :-(
Absolutely!
A mind is a terrible thing to waste when a computer could be programmed to do that boring, fiddly jobs so much better. Computers don't get distracted, don't turn of for work late with a hangover, don't have BOFH mentality (no, really). As Norbert Weiner said "Render unto the computer the things that are the computer's and unto man the things that are mans'". Doing the computer's job is no job for humans.
:-) Right. - -- Cheers Carlos E. R. (from 11.4, with Evergreen, x86_64 "Celadon" (Minas Tirith)) -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.16 (GNU/Linux) iF4EAREIAAYFAlIcrEYACgkQja8UbcUWM1yFpAD+L71iXsU7sJiUIEoHbtiuNwc/ /MqGSW/RGjjCJhnI0NoA/ieUZf1GZw9CHkLSSNdqT6tEU4xo0kw6arms8rBgQc// =Fzw3 -----END PGP SIGNATURE-----
Carlos E. R. said the following on 08/27/2013 09:40 AM:
Likewise, thunderbird does not offer to do body text searches.
Actually it does and does it the hard way. I believe there is a plugin or something to do full text searches. See https://developer.mozilla.org/en-US/docs/Thunderbird/gloda#Full-text_search <quote> FTS3 requires that it store the message text that it is indexing. This is in contrast to other solutions such as Lucene which can index text without being able to (efficiently) reconstruct the message text. </quote> Given an index hit with a Lucene search the MUA can retrieve the message. I don't see the point of FTS3. -- Tortoise: 'How many talking tortoises have you met?' Brutha: 'I don't know.' Tortoise: 'What d'you mean, you don't know?' Brutha: 'Well, they might all talk. They just might not say anything when I'm there.' -- "Small Gods", Terry Pratchett -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 El 2013-08-27 a las 10:06 -0400, Anton Aylward escribió:
Carlos E. R. said the following on 08/27/2013 09:40 AM:
Likewise, thunderbird does not offer to do body text searches.
Actually it does and does it the hard way. I believe there is a plugin or something to do full text searches. See https://developer.mozilla.org/en-US/docs/Thunderbird/gloda#Full-text_search
I was talking here of NNTP, not email :-) - -- Cheers Carlos E. R. (from 11.4, with Evergreen, x86_64 "Celadon" (Minas Tirith)) -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.16 (GNU/Linux) iF4EAREIAAYFAlIc1sEACgkQja8UbcUWM1yTdgD9EC29AhLwmcUtUkWwFxgE9rYN gqXgJbbDFYOuJ7Az1TEA/3D01wMVr7aKW8xtnXm+0qCDMfOqfSEKChFNpPS9dzc5 =I784 -----END PGP SIGNATURE-----
Carlos E. R. said the following on 08/27/2013 09:40 AM:
Btrfs? I don't know how it compares to reiserfs in terms of small files.
Target is 'same or better'. I have no complaints about performance; I just wish the fsck on boot actually did something :-/ Ah, yes, that is keeping me out:-(
I've been using it on my workstation since I installed 12.3 few months back. It seems remarkably resilient. I have everything on it including /boot. Last month I did a liveCD boot and ran the utility that does do the FSCK or equivalent clean up and tree balance/repair. Recall, everything is part of a tree with BtrFS. Varonis (?sp?) has many performance and other analysis and reports. Reality is that unless you're pushing a particular kind of task which makes specific and extreme demands (huge video file editing, creation/deleting of thousands of small files) most of the file systems are good general purpose ones. Reality is that journalling & recovery might be the most important thing going! -- "We must fall back upon the old axiom that when all other contingencies fail, whatever remains, however improbable, must be the truth." -- Sherlock Holmes, in "The Adventure of the Bruce-Partington Plans" -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
Carlos E. R. wrote:
Yes, there are indexes.
There is the folder "/var/spool/news/opensuse/org/help/applications/", for example, with 12000 files, each one a single post, complete (headers and body). But there is also a ".overview" file which is, I guess, a binary index of those posts.
And there is also the folder "/var/spool/news/message.id/", which contains a thousand directories named "000" to "999", and each directory contains many posts, or none, each a single file with headers and body.
I guess that those files in the first structure are hardlinks to those in the second structure.
There is not a content index. If I want to do a body text search, I have to do a filesystem grep on one of the structures, and it takes ages.
Dovecot does have full-text indexing, but it needs to be configured. http://wiki.dovecot.org/Plugins/FTS
Likewise, thunderbird does not offer to do body text searches.
My oldish Thunderbird (2.0.0.19) one does offer that and I have been told that version 3 will also use the server-side indexes, if present. -- Per Jessen, Zürich (18.1°C) http://www.dns24.ch/ - free DNS hosting, made in Switzerland. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
Per Jessen said the following on 08/27/2013 10:37 AM:
Likewise, thunderbird does not offer to do body text searches. My oldish Thunderbird (2.0.0.19) one does offer that and I have been told that version 3 will also use the server-side indexes, if present.
My current Thunderbird *17.0.8) offers quick search (aka filter meaning dynamic filter of what gets displayed) by "sender, recipients, subject body" If I use Edit->find->Search messages then I can choose "Body" "contains" and enter a string to search for. This is slow. It seems to download each and every message in the scope of the other search parameters. -- "You may have to fight a battle more than once to win it." -- Margaret Thatcher -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 El 2013-08-27 a las 16:37 +0200, Per Jessen escribió:
Carlos E. R. wrote:
There is the folder "/var/spool/news/opensuse/org/help/applications/",
...
Dovecot does have full-text indexing, but it needs to be configured. http://wiki.dovecot.org/Plugins/FTS
I'm talking here (this paragraph) of nntp, not email. - -- Cheers Carlos E. R. (from 11.4, with Evergreen, x86_64 "Celadon" (Minas Tirith)) -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.16 (GNU/Linux) iF4EAREIAAYFAlIc12IACgkQja8UbcUWM1yxiQD/c/x5/lxqP2GDs3Zu7/zAbAtF EC4uF7QCrTXoIOuZy8cA/iXNKAFb3fqDquM8KGgj7wAWP35IxDygBgLeWvHaZcBP =yLy/ -----END PGP SIGNATURE-----
Carlos E. R. said the following on 08/27/2013 12:44 PM:
I'm talking here (this paragraph) of nntp, not email.
Yea well, I've spun around and confused as to what refers to what. Perhaps we need to label things at the paragraph level or break up this thread into finer, more specific ones. Purely mail capabilities vs purely nntp matter vs purely file system matters. Oh dear, oh dear, oh dear... -- How long did the whining go on when KDE2 went on KDE3? The only universal constant is change. If a species can not adapt it goes extinct. That's the law of the universe, adapt or die. -- Billie Walsh, May 18 2013 -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 El 2013-08-27 a las 12:55 -0400, Anton Aylward escribió:
Carlos E. R. said the following on 08/27/2013 12:44 PM:
I'm talking here (this paragraph) of nntp, not email.
Yea well, I've spun around and confused as to what refers to what. Perhaps we need to label things at the paragraph level or break up this thread into finer, more specific ones. Purely mail capabilities vs purely nntp matter vs purely file system matters.
Oh dear, oh dear, oh dear...
:-) I was comparing both, because leafnode archives nntp as thousands of small files. In fact, previously I used thunderbid storing locally nntp posts on the equivalent of mbox, and it worked badly when the folders were large. On nntp it is typical to purge old posts and add new ones - it becomes a Gruyere cheese full of holes ;-) - -- Cheers Carlos E. R. (from 11.4, with Evergreen, x86_64 "Celadon" (Minas Tirith)) -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.16 (GNU/Linux) iF4EAREIAAYFAlIc3VgACgkQja8UbcUWM1w+WgD/SBO/+VYYDMyPoTAWwiIZJgrE W06FmjxP1UZzcr6Cy5UA/1TdKN/Gfn7zzPluyadVI/DrY/yf5y1IVvcQyrToSXLC =GYif -----END PGP SIGNATURE-----
Carlos E. R. wrote:
new ones - it becomes a Gruyere cheese full of holes ;-)
Probably Emmentaler, not Gruyere (though they also can have small holes). -- Per Jessen, Zürich (15.0°C) http://www.dns24.ch/ - free DNS hosting, made in Switzerland. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 El 2013-08-27 a las 20:04 +0200, Per Jessen escribió:
Carlos E. R. wrote:
new ones - it becomes a Gruyere cheese full of holes ;-)
Probably Emmentaler, not Gruyere (though they also can have small holes).
Oh, maybe right :-) - -- Cheers Carlos E. R. (from 11.4, with Evergreen, x86_64 "Celadon" (Minas Tirith)) -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.16 (GNU/Linux) iF4EAREIAAYFAlIc90wACgkQja8UbcUWM1wVZAD+O9qeCroEQAWllJ0Sg98h0nFa n/ISilh8j0VNYx8wB+0A/2Z+6QqnXB+pwxpz+I0fugj7rS+WR2fWaxfsEINjmaRi =/V9s -----END PGP SIGNATURE-----
Carlos E. R. wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256
El 2013-08-27 a las 16:37 +0200, Per Jessen escribió:
Carlos E. R. wrote:
There is the folder "/var/spool/news/opensuse/org/help/applications/",
...
Dovecot does have full-text indexing, but it needs to be configured. http://wiki.dovecot.org/Plugins/FTS
I'm talking here (this paragraph) of nntp, not email.
Ooops, sorry, I missed the context. (I use knode for nntp, not thunderbird). -- Per Jessen, Zürich (15.6°C) http://www.dns24.ch/ - free DNS hosting, made in Switzerland. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 El 2013-08-27 a las 19:12 +0200, Per Jessen escribió:
Carlos E. R. wrote:
Ooops, sorry, I missed the context. (I use knode for nntp, not thunderbird).
Actually, leafnode, in this case. Thunderbird reads from leafnode. It is more efficient :-) leafnode stores a database of nntp posts as thousands of small files, whereas thunderbird does it as a single file per group. And it works better. Aparently the mbox implementation done by thunderbird is not optimal. - -- Cheers Carlos E. R. (from 11.4, with Evergreen, x86_64 "Celadon" (Minas Tirith)) -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.16 (GNU/Linux) iF4EAREIAAYFAlIc9kUACgkQja8UbcUWM1yYxQD+L/IH7BDfxxjk9i5n1u03Jqbw DtBRBpGcuhFWmDG1Z+cA/ialLQ7XFmK0ihpj9aqX2VfM+AitH36G0AAR1fQA80MF =O1yG -----END PGP SIGNATURE-----
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 27/08/13 14:40, Carlos E. R. wrote:
Likewise, thunderbird does not offer to do body text searches.
I'm using Thunderbird 17.0.8 on an IMAP account and can state that it does do body text searches of email messages. If I put 'rsync' in the search box, a drop down appears offering Messages mentioning rsync Search Bing for rsync I'm not sure when Thunderbird chose Bing as its preferred search engine, but don't care much as 99% of the time I choose the first option. Bob - -- Bob Williams System: Linux 3.7.10-1.16-desktop Distro: openSUSE 12.3 (x86_64) with KDE Development Platform: 4.10.5 "release 4" Uptime: 12:00pm up 22:56, 3 users, load average: 0.77, 0.89, 0.67 -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iEYEARECAAYFAlIcxNoACgkQ0Sr7eZJrmU5ziACcCO2LEX1TtB7tOYHWbAvLasn6 59gAnRFhAKMBdMHmZanSZVvUDqye6NVC =O4O1 -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 El 2013-08-27 a las 16:25 +0100, Bob Williams escribió:
On 27/08/13 14:40, Carlos E. R. wrote:
Likewise, thunderbird does not offer to do body text searches.
I'm using Thunderbird 17.0.8 on an IMAP account and can state that it does do body text searches of email messages.
Please remember that this post refered to NNTP, not IMAP. - -- Cheers Carlos E. R. (from 11.4, with Evergreen, x86_64 "Celadon" (Minas Tirith)) -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.16 (GNU/Linux) iF4EAREIAAYFAlIc194ACgkQja8UbcUWM1z6GwD9Ea13qtiBZfDQGvMdUGUDSiUO wUfFWNya78BmoBuJyGYA/1DMORdV5gZG82m2+50NoFbFQWVF42chAfjPR4IACpzZ =mz3c -----END PGP SIGNATURE-----
Bob Williams said the following on 08/27/2013 11:25 AM:
On 27/08/13 14:40, Carlos E. R. wrote:
Likewise, thunderbird does not offer to do body text searches.
I'm using Thunderbird 17.0.8 on an IMAP account and can state that it does do body text searches of email messages.
If I put 'rsync' in the search box, a drop down appears offering
Messages mentioning rsync
Search Bing for rsync
I'm not sure when Thunderbird chose Bing as its preferred search engine, but don't care much as 99% of the time I choose the first option.
Which search box? There's one that appears when you click 'quick filter'. Is that what you mean? There's edit->find and edit->find->search messages which brings up a whole new dialog window I don't see putting 'rsync' in any of them doing what you say. I do see a capability in Firefox where I can search bing or google or yahoo for 'rsync'. Could you please expand on your explanation. Are you usign a plugin? -- How long did the whining go on when KDE2 went on KDE3? The only universal constant is change. If a species can not adapt it goes extinct. That's the law of the universe, adapt or die. -- Billie Walsh, May 18 2013 -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 27/08/13 17:50, Anton Aylward wrote:
Bob Williams said the following on 08/27/2013 11:25 AM:
On 27/08/13 14:40, Carlos E. R. wrote:
Likewise, thunderbird does not offer to do body text searches.
I'm using Thunderbird 17.0.8 on an IMAP account and can state that it does do body text searches of email messages.
[...]
Which search box? There's one that appears when you click 'quick filter'. Is that what you mean?
It's to the right of the Quick Filter button, on the same tool bar.
The box contains the word 'Search...' followed by the shortcut
There's edit->find and edit->find->search messages which brings up a whole new dialog window
No, not that one
I don't see putting 'rsync' in any of them doing what you say.
I chose 'rsync' as a bit of random text to search for that I knew would produce a result here. Maybe I should have chosen 'foo-bar'.
I do see a capability in Firefox where I can search bing or google or yahoo for 'rsync'.
Could you please expand on your explanation. Are you usign a plugin?
I do use plugins, but I don't think this functionality is provided by any of the ones currently installed here: Adblock Plus Enigmail Folder Account Lightning Provider for Google Calendar QuoteCollapse Quote Highlight Spamness
And it also works when reading newsgroups. - -- Bob Williams System: Linux 3.7.10-1.16-desktop Distro: openSUSE 12.3 (x86_64) with KDE Development Platform: 4.10.5 "release 4" Uptime: 12:00pm up 2 days 22:56, 3 users, load average: 0.11, 0.23, 0.31 -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iEYEARECAAYFAlIfOTQACgkQ0Sr7eZJrmU5PzgCfV942Cj71v5dL+FPo3fvPuzKJ 1DUAn2SA3BtISfhL76PwJWxlpGGgqBlk =yF5B -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On Mon, 26 Aug 2013 13:59:19 Carlos E. R. wrote:
El 2013-08-19 a las 02:46 -0700, Mark Tinka escribió:
I run KMail because I still - after nearly 6 years - can't find a decent MUA that supports both Maildir and PGP. Outlook is MBOX style (and it's Microsoft). Apple Mail is Maildir style but uses a proprietary method (.emlx). Thunderbird has great PGP support but no Maildir (still can't believe that, after all this time). OperaMail has good PGP support but no Maildir.
I find Maildir inefficient. :-p
Anyway, you can run dovecot as local imap server for storage, and then use any mail client you like - even all of them at the same time.
I'm doing that, and this is a laptop...
I find mbox inefficient - in terms of performance, not storage. There is always a trade-off. I agree re dovecot, though. I'm running fetchmail/sendmail/dovecot/spamassassin/clamav on a raspberry pi - a very low cost (<$60), low power (<5W) mail server that can run 24/7 for almost nothing. That consolidates 5 external email accounts into one that I can access from anywhere, any time, using any imaps (imap/ssl) client, or via a web browser (it also runs squirrelmail) via https. :-) -- ============================================================== Rodney Baker VK5ZTV rodney.baker@iinet.net.au ============================================================== -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
Content-ID:
On Mon, 26 Aug 2013 13:59:19 Carlos E. R. wrote:
I find Maildir inefficient. :-p
Anyway, you can run dovecot as local imap server for storage, and then use any mail client you like - even all of them at the same time.
I'm doing that, and this is a laptop...
I find mbox inefficient - in terms of performance, not storage.
I find Maildir inefficient in terms of perfomance - try doing a full text search on a 12000 mails folder (as the one for this list in this machine).
There is always a trade-off. I agree re dovecot, though. I'm running fetchmail/sendmail/dovecot/spamassassin/clamav on a raspberry pi - a very low cost (<$60), low power (<5W) mail server that can run 24/7 for almost nothing. That consolidates 5 external email accounts into one that I can access from anywhere, any time, using any imaps (imap/ssl) client, or via a web browser (it also runs squirrelmail) via https.
:-)
Nice! Dovecot has other formats. There are intermediate formats bewteen mbox and maildir that are very interesting. - -- Cheers Carlos E. R. (from 11.4, with Evergreen, x86_64 "Celadon" (Minas Tirith)) -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.16 (GNU/Linux) iF4EAREIAAYFAlIbTU4ACgkQja8UbcUWM1zZdwD/aBbqprM+Jhiv7L/0J4CCwPMh OazgivQEYE+3o+gx+SIA/jlcb4ekHi1R4hu95yeeh87gmEXHFu7XkRuZjadrGSTk =GeLN -----END PGP SIGNATURE-----
-----Original Message-----
From: Carlos E. R.
On Mon, 26 Aug 2013 13:59:19 Carlos E. R. wrote:
I find Maildir inefficient. :-p
Anyway, you can run dovecot as local imap server for storage, and then use any mail client you like - even all of them at the same time.
I'm doing that, and this is a laptop...
I find mbox inefficient - in terms of performance, not storage.
I find Maildir inefficient in terms of perfomance - try doing a full text search on a 12000 mails folder (as the one for this list in this machine). -----Original Message----- Really? I am on the brink on migrating from mbox towards Maildir because of efficiency... I was expecting the opposite from what you write.... If you have just one mbox-file, sequential reading/searching mbox might be fast, but when you mutate a lot, storing messages into individual files and subfolders in separate dirs looks more efficient. Specially when dealing with large (sub-)folders With regards to btrfs, it uses a more efficient way of storing meta-data, and does not need full 4K blocks for small files... hw -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
Hans Witvliet said the following on 08/26/2013 09:17 AM:
If you have just one mbox-file, sequential reading/searching mbox might be fast, but when you mutate a lot, storing messages into individual files and subfolders in separate dirs looks more efficient.
Quite true but there is a WTF reaction on my part. WTF are you doing altering emails? Or do you mean something different from that by "mutate"? As for INCOMING! opening the mbox file and doing an append ... append ... append ... isn't inefficient. It probably more efficient that doing a step and repeat of ''create, append, close'. How much of a pizzing match do you want to engage in here? Not least of all because different file systems grow files in different ways and different file system handle growing directories on file create in different ways. So mailbox vs maildir gets to be more like comparing apples to picasso paintings than apples to oranges. -- How long did the whining go on when KDE2 went on KDE3? The only universal constant is change. If a species can not adapt it goes extinct. That's the law of the universe, adapt or die. -- Billie Walsh, May 18 2013 -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
-----Original Message-----
From: Anton Aylward
If you have just one mbox-file, sequential reading/searching mbox might be fast, but when you mutate a lot, storing messages into individual files and subfolders in separate dirs looks more efficient.
Quite true but there is a WTF reaction on my part. WTF are you doing altering emails? Or do you mean something different from that by "mutate"? As for INCOMING! opening the mbox file and doing an append ... append ... append ... isn't inefficient. It probably more efficient that doing a step and repeat of ''create, append, close'. How much of a pizzing match do you want to engage in here? Not least of all because different file systems grow files in different ways and different file system handle growing directories on file create in different ways. So mailbox vs maildir gets to be more like comparing apples to picasso paintings than apples to oranges. -----Original Message----- Hi Anton, As Maildir puts everything in separate dirs/files, it seems to me that it place a higher burden to the efficiency of the underlying filesystem. Or is this a wrong assumption? So it seems to me, when deleting one message (= one file) is less costly then modifying an mbox containing 10,000 messages. otoh, if only messages got added (like on a mailing list archive) adding things at the end, and modifying the index is less costly than creating separate files each time. But ofcourse, i could completely mistaken regarding the innerworkings of mboxes ;-) hw -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 El 2013-08-27 a las 10:23 +0200, Hans Witvliet escribió:
Hi Anton,
As Maildir puts everything in separate dirs/files, it seems to me that it place a higher burden to the efficiency of the underlying filesystem. Or is this a wrong assumption?
No, it is correct.
So it seems to me, when deleting one message (= one file) is less costly then modifying an mbox containing 10,000 messages.
True.
otoh, if only messages got added (like on a mailing list archive) adding things at the end, and modifying the index is less costly than creating separate files each time.
True again :-)
But ofcourse, i could completely mistaken regarding the innerworkings of mboxes ;-)
No, you are correct. Those are the issues :-) - -- Cheers Carlos E. R. (from 11.4, with Evergreen, x86_64 "Celadon" (Minas Tirith)) -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.16 (GNU/Linux) iF4EAREIAAYFAlIcqR8ACgkQja8UbcUWM1wHCQD/aedliNvUyEld12XcwDF3jYo6 JSQcggkEbcxJvAA3eFwA/AiMwjigxybSX4l4jWHuOTZOc1vMa2eiStka9KNJl0jO =2J6W -----END PGP SIGNATURE-----
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 El 2013-08-26 a las 15:17 +0200, Hans Witvliet escribió:
From: Carlos E. R. <>
I find Maildir inefficient in terms of perfomance - try doing a full text search on a 12000 mails folder (as the one for this list in this machine).
-----Original Message-----
Really? I am on the brink on migrating from mbox towards Maildir because of efficiency...
I was expecting the opposite from what you write.... If you have just one mbox-file, sequential reading/searching mbox might be fast, but when you mutate a lot, storing messages into individual files and subfolders in separate dirs looks more efficient. Specially when dealing with large (sub-)folders
Maildir, to my knowledge, is only more efficient when you do many inserts and deletes. And frankly, with good clients like Pine I don't even notice it. Another alledged problem of mbox is concurrent ussage (like fetchmail adding an email, while the client does something else. In practice, I have never hit such a problem in 15 years.
With regards to btrfs, it uses a more efficient way of storing meta-data, and does not need full 4K blocks for small files...
Well, reiserfs stored small files directly on the metadata tree, no allocation. I would like to read some document comparing both in this respect. - -- Cheers Carlos E. R. (from 11.4, with Evergreen, x86_64 "Celadon" (Minas Tirith)) -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.16 (GNU/Linux) iF4EAREIAAYFAlIbbBwACgkQja8UbcUWM1wW1gD/bgnPUc0tkDCEV3L1FTbvrqKm wKfl0gRlOFREEUirkSYA/1ijgMCUfGkQkB/WbvrdNM0/5TBPhrFZy/LYCSj+XhvG =5QoS -----END PGP SIGNATURE-----
Carlos E. R. said the following on 08/26/2013 10:54 AM:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256
El 2013-08-26 a las 15:17 +0200, Hans Witvliet escribió:
From: Carlos E. R. <>
I find Maildir inefficient in terms of perfomance - try doing a full text search on a 12000 mails folder (as the one for this list in this machine).
-----Original Message-----
Really? I am on the brink on migrating from mbox towards Maildir because of efficiency...
I was expecting the opposite from what you write.... If you have just one mbox-file, sequential reading/searching mbox might be fast, but when you mutate a lot, storing messages into individual files and subfolders in separate dirs looks more efficient. Specially when dealing with large (sub-)folders
Maildir, to my knowledge, is only more efficient when you do many inserts and deletes. And frankly, with good clients like Pine I don't even notice it.
I fail to understand why you would want to modify mail messages once they have been stored. I can understand the modification of the headers as they pass though relays, though spam detectors and the like, but once they hit storage .... why? Do you really want to modify what people have said? I don't understand that.
Another alledged problem of mbox is concurrent ussage (like fetchmail adding an email, while the client does something else. In practice, I have never hit such a problem in 15 years.
Same here, but make that much longer. The 'problem' of adding incoming to a mailbox while reading it is not new, it dates back to the late 70s. Concurrent access for read has never been a problem with UNIX; concurrent access for write is a logical problem not confined to UNIX. But the mbox format has used sentinel flags and all mail appreciations seem to obey that simple protocol. In absolute terms appending to a file isn't going to upset another process that is simply reading from the file. In reality, the MUA will 'see' (or be notified) that the file size has increased and re-scan for new headers. How efficiently it does that depends on whether or not you allow the MUA to modify the other mail messages. One reason to use Dovecot and IMAP is that the MUA - Thunderbird, KDE-Mail, whatever - relies on Dovecot to tell it what is going on. Dovecot maintains metadata about the mail box. It can modify the metadata DB without having to modify the mbox itself. It keeps indexes on the mbox and they are 'cleaner' than the MUA/thunderbird (etc) might. q.v. -- How long did the whining go on when KDE2 went on KDE3? The only universal constant is change. If a species can not adapt it goes extinct. That's the law of the universe, adapt or die. -- Billie Walsh, May 18 2013 -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 El 2013-08-26 a las 11:26 -0400, Anton Aylward escribió:
Carlos E. R. said the following on 08/26/2013 10:54 AM:
Maildir, to my knowledge, is only more efficient when you do many inserts and deletes. And frankly, with good clients like Pine I don't even notice it.
I fail to understand why you would want to modify mail messages once they have been stored. I can understand the modification of the headers as they pass though relays, though spam detectors and the like, but once they hit storage .... why? Do you really want to modify what people have said? I don't understand that.
No, not that. It is removal of a complete post, because you do not want to keep it, or because you move it to another folder. It is possible to want to add an email in the middle of the "list" (because it is sorted). Yes, normally the clients will do the sorting just fine without that. Although I do not know of a client that does it, I would like to have a client that would allow adding a comment header (and display it by default), where I could write why that post interests me - very useful for the relatively few list emails I archive; often for something they say different that what the subject line says. Pine, for instance, changes one header to mark that an email has been read, or that it is important, and it does that very fast. I don't know exactly what it changes. In fact, dovecot does the same change, because I can see an email directly with pine or via dovecot, and the flags are correct on both. Ie, both Pine and dovecot use the same flags on mbox.
Another alledged problem of mbox is concurrent ussage (like fetchmail adding an email, while the client does something else. In practice, I have never hit such a problem in 15 years.
Same here, but make that much longer. The 'problem' of adding incoming to a mailbox while reading it is not new, it dates back to the late 70s. Concurrent access for read has never been a problem with UNIX; concurrent access for write is a logical problem not confined to UNIX. But the mbox format has used sentinel flags and all mail appreciations seem to obey that simple protocol. In absolute terms appending to a file isn't going to upset another process that is simply reading from the file. In reality, the MUA will 'see' (or be notified) that the file size has increased and re-scan for new headers. How efficiently it does that depends on whether or not you allow the MUA to modify the other mail messages.
In truth, MsDos was more advanced in this respect. When the 'share.exe' additions were loaded, you could lock a section of a file for writing while reading or even writing to another section of the same file. Using another file as lock flag is, IMHO, a kludge, and may be ignored by software (the lock not enforced by the kernel).
One reason to use Dovecot and IMAP is that the MUA - Thunderbird, KDE-Mail, whatever - relies on Dovecot to tell it what is going on. Dovecot maintains metadata about the mail box. It can modify the metadata DB without having to modify the mbox itself. It keeps indexes on the mbox and they are 'cleaner' than the MUA/thunderbird (etc) might.
True. Although here I have a problem there, because I still use procmail to write directly to folders. Dovecot copes with this, but I owuld like to instead (using procmail) send that email to dovecot. - -- Cheers Carlos E. R. (from 11.4, with Evergreen, x86_64 "Celadon" (Minas Tirith)) -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.16 (GNU/Linux) iF4EAREIAAYFAlIblv4ACgkQja8UbcUWM1wOdAD8DENBYzx7V/y/MvUptPWTjAyB NL1/tBi3A6PsXJr26R8A+wR9Zb9Ctkiph4KjGyHXaLBm9MLxQZvteTddulP0scUo =F2On -----END PGP SIGNATURE-----
Carlos E. R. said the following on 08/26/2013 01:57 PM:
El 2013-08-26 a las 11:26 -0400, Anton Aylward escribió:
Carlos E. R. said the following on 08/26/2013 10:54 AM:
Maildir, to my knowledge, is only more efficient when you do many inserts and deletes. And frankly, with good clients like Pine I don't even notice it.
I fail to understand why you would want to modify mail messages once they have been stored. I can understand the modification of the headers as they pass though relays, though spam detectors and the like, but once they hit storage .... why? Do you really want to modify what people have said? I don't understand that.
No, not that.
It is removal of a complete post, because you do not want to keep it, or because you move it to another folder.
Ah. So you think its done like in VI where the lines are removed from the middle of the file? I think not. I think that its done by a copy-and-skip. In VI the file is buffered and the lines are taken out of the buffer and then the remainder is written out as if it were a new file. Something like that. Certainly with IMAP that all doesn't get done until you tell the IMAP server to 'compact".
It is possible to want to add an email in the middle of the "list" (because it is sorted). Yes, normally the clients will do the sorting just fine without that.
I'm not sure about that. Personally, without looking at the source, I think the MUAs do the sorting at the presentation. How else can threading work? I don't think that a change in the sort order in Thunderbird causes a change in the order of the messages in the mbox. If a new message appears with a header saying it was sourced at a time 'in the middle' then it gets appended and its up to the MUA to display it in the 'correct' position. It doesn't get inserted in the 'correct' position in the file. That concept is meaningless since it all depends on how you choose to sort, and any reasonable MUA will have many sort options. q.v.
Although I do not know of a client that does it, I would like to have a client that would allow adding a comment header (and display it by default), where I could write why that post interests me - very useful for the relatively few list emails I archive; often for something they say different that what the subject line says.
Since the index files and the 'metadata' used by something like Dovecot is outside of the mbox file there is no reason why not. We're quite used to directories having a .directory file to be used by Dolphin or the like, sure, why not. I recall one file manager that allowed 'ratings' by use of icons to be attached to each file icon that was displayed - can't recall its name.
Pine, for instance, changes one header to mark that an email has been read, or that it is important, and it does that very fast. I don't know exactly what it changes. In fact, dovecot does the same change, because I can see an email directly with pine or via dovecot, and the flags are correct on both. Ie, both Pine and dovecot use the same flags on mbox.
I *think* this is a case of altering the header inside the file when the mbox is closed. I'm sure that can easily be tested.
Another alledged problem of mbox is concurrent ussage (like fetchmail adding an email, while the client does something else. In practice, I have never hit such a problem in 15 years.
Same here, but make that much longer. The 'problem' of adding incoming to a mailbox while reading it is not new, it dates back to the late 70s. Concurrent access for read has never been a problem with UNIX; concurrent access for write is a logical problem not confined to UNIX. But the mbox format has used sentinel flags and all mail appreciations seem to obey that simple protocol. In absolute terms appending to a file isn't going to upset another process that is simply reading from the file. In reality, the MUA will 'see' (or be notified) that the file size has increased and re-scan for new headers. How efficiently it does that depends on whether or not you allow the MUA to modify the other mail messages.
In truth, MsDos was more advanced in this respect. When the 'share.exe' additions were loaded, you could lock a section of a file for writing while reading or even writing to another section of the same file.
You can now; but we had email on V6 and V7 UNIX which didn't have the ability to lock sections of files as we do now. Sentinel flags did the job just so long as the parties obeyed the protocol. Sometimes with NFS that was difficult.
Using another file as lock flag is, IMHO, a kludge, and may be ignored by software (the lock not enforced by the kernel).
Yes, all parties have to obey that agreed protocol. Mandatory control is better, but we didn't have it in V6/V7 days.
One reason to use Dovecot and IMAP is that the MUA - Thunderbird, KDE-Mail, whatever - relies on Dovecot to tell it what is going on. Dovecot maintains metadata about the mail box. It can modify the metadata DB without having to modify the mbox itself. It keeps indexes on the mbox and they are 'cleaner' than the MUA/thunderbird (etc) might.
True.
Although here I have a problem there, because I still use procmail to write directly to folders. Dovecot copes with this, but I owuld like to instead (using procmail) send that email to dovecot.
My incoming mail is dragged in by fetchmail, passed to procmail and put in folders using the locking protocol procmail supports. Dovecot is *NOT* a mail transfer agent, it is a IMAP/POP server. You don't 'send' email to dovecot. Dovecot is smart enough that when it sees a mbox or directory change it rescans and reindexes. One reason I have a lot of smaller folders rather than one big INBOX :-) Oops! googling I see that dovecot does have a local delivery agent - lda. http://wiki.dovecot.org/LDA It seems you need it to do filtering. I'm doing my filtering with procmail (as I have for a few decades ...) so I don't use the LDA. My .forward sends incoming email to procmail. The dovecot lda methods sends it to "/usr/local/libexec/dovecot/deliver". I gather that its an either/or situation. I'm sure you could kludge procmail to pipe though dovecot's filters, but what make it that complicated: do one or the other. That's fine, but I'll stick with what I know works until I have a need to change. -- When nothing is sure, everything is possible. - Margaret Drabble -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 El 2013-08-26 a las 15:03 -0400, Anton Aylward escribió:
Carlos E. R. said the following on 08/26/2013 01:57 PM:
No, not that.
It is removal of a complete post, because you do not want to keep it, or because you move it to another folder.
Ah. So you think its done like in VI where the lines are removed from the middle of the file?
I think not. I think that its done by a copy-and-skip.
In VI the file is buffered and the lines are taken out of the buffer and then the remainder is written out as if it were a new file.
Something like that. Certainly with IMAP that all doesn't get done until you tell the IMAP server to 'compact".
You misunderstood me. A MUA does it by marking the post as deleted (overwriting something), and postponing the actual deletion till "compaction". Thunderbird does it on request or certains circumstances (change folder when compaction would save a certain amount). Pine does it, I think, whenver you change from one folder to another. This folder has about 12000 posts and is 80MiB big. Other folders have much fewer posts but are much larger, receiving big attachments or html posts. It means that an actual insert or delete has to copy that big folder to another temporary one. On a maildir folder, it just writes 2 or 3 small files, it is faster, in theory.
It is possible to want to add an email in the middle of the "list" (because it is sorted). Yes, normally the clients will do the sorting just fine without that.
I'm not sure about that. Personally, without looking at the source, I think the MUAs do the sorting at the presentation.
True, but Pine can also write a sorted folder. Thunderbird does not, but thunderbird keeps an index file (and pine does not).
inserted in the 'correct' position in the file. That concept is meaningless since it all depends on how you choose to sort, and any reasonable MUA will have many sort options. q.v.
True, but it is a posibility.
Although I do not know of a client that does it, I would like to have a client that would allow adding a comment header (and display it by default), where I could write why that post interests me - very useful for the relatively few list emails I archive; often for something they say different that what the subject line says.
Since the index files and the 'metadata' used by something like Dovecot is outside of the mbox file there is no reason why not. We're quite used to directories having a .directory file to be used by Dolphin or the like, sure, why not. I recall one file manager that allowed 'ratings' by use of icons to be attached to each file icon that was displayed - can't recall its name.
Nautilus. It overlays a little graphic over the icon, for classification. But I meant adding a header inside mails in the mbox file, not in an index. There was a client that did it (I can't remember the name, the header might be named "X-COMMENT" or similar. Addition of headers is permitted.
Although here I have a problem there, because I still use procmail to write directly to folders. Dovecot copes with this, but I owuld like to instead (using procmail) send that email to dovecot.
My incoming mail is dragged in by fetchmail, passed to procmail and put in folders using the locking protocol procmail supports.
Yes, I do the same.
Dovecot is *NOT* a mail transfer agent, it is a IMAP/POP server. You don't 'send' email to dovecot. Dovecot is smart enough that when it sees a mbox or directory change it rescans and reindexes. One reason I have a lot of smaller folders rather than one big INBOX :-)
Oops! googling I see that dovecot does have a local delivery agent - lda. http://wiki.dovecot.org/LDA It seems you need it to do filtering.
That's what I meant.
I'm doing my filtering with procmail (as I have for a few decades ...) so I don't use the LDA.
My .forward sends incoming email to procmail. The dovecot lda methods sends it to "/usr/local/libexec/dovecot/deliver". I gather that its an either/or situation. I'm sure you could kludge procmail to pipe though dovecot's filters, but what make it that complicated: do one or the other.
That's fine, but I'll stick with what I know works until I have a need to change.
Absolutely, but feeding it via dovecot tools would avoid having to reindex the entire folder. - -- Cheers Carlos E. R. (from 11.4, with Evergreen, x86_64 "Celadon" (Minas Tirith)) -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.16 (GNU/Linux) iF4EAREIAAYFAlIb028ACgkQja8UbcUWM1yg+gD+KvkzlrwGeXqpF+W0jAMI/G8w CiCyf/mBJGjmyXznUGgA/jCiETioDuG9noFVqSvgWQGTDkvy82QO+LZl3Y4Y0wya =tDY0 -----END PGP SIGNATURE-----
Carlos E. R. said the following on 08/26/2013 06:15 PM:
El 2013-08-26 a las 15:03 -0400, Anton Aylward escribió:
Carlos E. R. said the following on 08/26/2013 01:57 PM:
No, not that.
It is removal of a complete post, because you do not want to keep it, or because you move it to another folder.
Ah. So you think its done like in VI where the lines are removed from the middle of the file?
I think not. I think that its done by a copy-and-skip.
In VI the file is buffered and the lines are taken out of the buffer and then the remainder is written out as if it were a new file.
Something like that. Certainly with IMAP that all doesn't get done until you tell the IMAP server to 'compact".
You misunderstood me.
A MUA does it by marking the post as deleted (overwriting something), and postponing the actual deletion till "compaction". Thunderbird does it on request or certains circumstances (change folder when compaction would save a certain amount). Pine does it, I think, whenver you change from one folder to another.
My experience is with IMAP so the MUA is acting as a director and the IMAP server is doing this. When I peek I see many instances of the dovecot server. It looks like there is a new instance every time I move T'bird to another folder. From this I'm concluding that it defers the compaction for as long as possible, until logout or until explicitly instructed, which, given the IMAP protocol, makes sense. So I while I may not have understood you in some aspect (as below) what we are saying about this part is much the same.
This folder has about 12000 posts and is 80MiB big. Other folders have much fewer posts but are much larger, receiving big attachments or html posts. It means that an actual insert or delete has to copy that big folder to another temporary one.
On a maildir folder, it just writes 2 or 3 small files, it is faster, in theory.
Ah. My INBOX is about 152Meg (according to ls -h) and I have no complaints about the performance of Dovecot handling it. Theory is good. Perhaps this would be different is this was not a personal setup, of that was a larger server with tends of gigs or RAM, a couple of 8 core processors and few hundred T of disk at an ISP support a few thousand concurrent users with webmail, each with INBOXes they never purged and which were many times the size of yours and mine.
It is possible to want to add an email in the middle of the "list" (because it is sorted). Yes, normally the clients will do the sorting just fine without that.
I'm not sure about that. Personally, without looking at the source, I think the MUAs do the sorting at the presentation.
True, but Pine can also write a sorted folder. Thunderbird does not, but thunderbird keeps an index file (and pine does not).
Can pine deal with threads then? I wish T'bird didn't; I wish it could make use of the capabilities of Dovecot in that regard. I wish it could use dovecot's ability to use lucine for full text indexing too and allow easy body search. I wish I could win the lottery ...
Although I do not know of a client that does it, I would like to have a client that would allow adding a comment header (and display it by default), where I could write why that post interests me - very useful for the relatively few list emails I archive; often for something they say different that what the subject line says.
Since the index files and the 'metadata' used by something like Dovecot is outside of the mbox file there is no reason why not. We're quite used to directories having a .directory file to be used by Dolphin or the like, sure, why not. I recall one file manager that allowed 'ratings' by use of icons to be attached to each file icon that was displayed - can't recall its name.
Nautilus. It overlays a little graphic over the icon, for classification.
But I meant adding a header inside mails in the mbox file, not in an index. There was a client that did it (I can't remember the name, the header might be named "X-COMMENT" or similar. Addition of headers is permitted.
It shouldn't make any difference. I can easily imagine a mail system implemented not as files but as a database where the headers are stored in different fields from the body and its easy to add another header. So what difference does it make if the metadata isn't stored with the data? The same index file that points to the message could equally well contain any number of X- extensions without including them in the message. Heck, news readers manage that; they keep track of who has read a message without making changes to the message.
Although here I have a problem there, because I still use procmail to write directly to folders. Dovecot copes with this, but I owuld like to instead (using procmail) send that email to dovecot.
My incoming mail is dragged in by fetchmail, passed to procmail and put in folders using the locking protocol procmail supports.
Yes, I do the same.
Dovecot is *NOT* a mail transfer agent, it is a IMAP/POP server. You don't 'send' email to dovecot. Dovecot is smart enough that when it sees a mbox or directory change it rescans and reindexes. One reason I have a lot of smaller folders rather than one big INBOX :-)
Oops! googling I see that dovecot does have a local delivery agent - lda. http://wiki.dovecot.org/LDA It seems you need it to do filtering.
That's what I meant.
I'm doing my filtering with procmail (as I have for a few decades ...) so I don't use the LDA.
My .forward sends incoming email to procmail. The dovecot lda methods sends it to "/usr/local/libexec/dovecot/deliver". I gather that its an either/or situation. I'm sure you could kludge procmail to pipe though dovecot's filters, but what make it that complicated: do one or the other.
That's fine, but I'll stick with what I know works until I have a need to change.
Absolutely, but feeding it via dovecot tools would avoid having to reindex the entire folder.
Yes, so? That is only of use if you can access and make use of the dovecot index. Most MUAs can't. I'm annoyed that Thunderbird can't. It seems pointless to me that I should run Dovecot on a server and let it do indexing and full text indexing "in the background" with the intent to offload this processing and storage from my workstation and/or laptop. It seems pointless to me that I should have T'bird index things all over again. Yes, I know about https://wiki.mozilla.org/Thunderbird:Using_Gloda and I have found information on that less than useful and experimentation frustrating. This https://developer.mozilla.org/en-US/docs/Thunderbird/Gloda_indexing leads me to believe that in IMAP mode T'bird does a lot of indexing that would be redundant of it could access the dovecot metadata. There is https://addons.mozilla.org/en-us/thunderbird/addon/glodaquilla-search-indexi... but is it what we are talking about? I don't think so. -- How long did the whining go on when KDE2 went on KDE3? The only universal constant is change. If a species can not adapt it goes extinct. That's the law of the universe, adapt or die. -- Billie Walsh, May 18 2013 -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 El 2013-08-26 a las 19:37 -0400, Anton Aylward escribió:
Carlos E. R. said the following on 08/26/2013 06:15 PM:
So I while I may not have understood you in some aspect (as below) what we are saying about this part is much the same.
Yes :-)
On a maildir folder, it just writes 2 or 3 small files, it is faster, in theory.
Ah. My INBOX is about 152Meg (according to ls -h) and I have no complaints about the performance of Dovecot handling it. Theory is good. Perhaps this would be different is this was not a personal setup, of that was a larger server with tends of gigs or RAM, a couple of 8 core processors and few hundred T of disk at an ISP support a few thousand concurrent users with webmail, each with INBOXes they never purged and which were many times the size of yours and mine.
But then you have the issue of a filesystem with billions of small files... There are mail folder formats intermediate between maildir and mbox. Say that small mails are stored together in the same file till it grows to a few megabytes, and large emails are stored alone on a single file. In theory it should work very well. Pine (it happens that one of the developers of pine was the designer of Imap, so what pine does is almost canonical, it follows standards to the letter) started developping a new such format, but was not implemented finally, or I don't know how to use it. And it is pointless if procmail does not support it. Dovecot (specially the new release) supports such formats, too. But then we can't use procmail because it does not support them.
I'm not sure about that. Personally, without looking at the source, I think the MUAs do the sorting at the presentation.
True, but Pine can also write a sorted folder. Thunderbird does not, but thunderbird keeps an index file (and pine does not).
Can pine deal with threads then?
Oh, absolutely. Default sort is none (last post arrived is at the bottom). I prefer threaded sort with threads with recent posts at the bottom (or top).
I wish T'bird didn't; I wish it could make use of the capabilities of Dovecot in that regard. I wish it could use dovecot's ability to use lucine for full text indexing too and allow easy body search.
I wish I could win the lottery ...
:-) I don't know if Pine uses server index or local. Thunderbird is designed mainly with ISP imap as a target, where a local index is fast. Pine doesn't create indexes except perhaps in memory, and it assumes a good network (the local network of the university where it was designed, I guess).
But I meant adding a header inside mails in the mbox file, not in an index. There was a client that did it (I can't remember the name, the header might be named "X-COMMENT" or similar. Addition of headers is permitted.
It shouldn't make any difference. I can easily imagine a mail system implemented not as files but as a database where the headers are stored in different fields from the body and its easy to add another header.
So what difference does it make if the metadata isn't stored with the data? The same index file that points to the message could equally well contain any number of X- extensions without including them in the message.
Heck, news readers manage that; they keep track of who has read a message without making changes to the message.
Altering a header in the message, instead of using the index file, means that the index can be rebuilt, without losing that data. Many years ago I started designing a data base, and that was a feature: I could delete the index and rebuild them safely and reliably. In any case, a header is "data", not "metadata", in mail context. Yes, mail is a database, only that it is a specific one, and everybody redesigns it again.
Absolutely, but feeding it via dovecot tools would avoid having to reindex the entire folder.
Yes, so? That is only of use if you can access and make use of the dovecot index. Most MUAs can't. I'm annoyed that Thunderbird can't.
I'm not sure about Pine.
It seems pointless to me that I should run Dovecot on a server and let it do indexing and full text indexing "in the background" with the intent to offload this processing and storage from my workstation and/or laptop. It seems pointless to me that I should have T'bird index things all over again.
TH: Edit/Find/Search messages. There is a tick box for "run search in server". Is that what you want? :-) Mind, there are two types of indexes here. There is one, telling just some headers used for sorting and displaying headers, and then there is the contend index used for searches. Possibly Th uses the first one, not the second.
Yes, I know about https://wiki.mozilla.org/Thunderbird:Using_Gloda and I have found information on that less than useful and experimentation frustrating. This https://developer.mozilla.org/en-US/docs/Thunderbird/Gloda_indexing leads me to believe that in IMAP mode T'bird does a lot of indexing that would be redundant of it could access the dovecot metadata.
There is https://addons.mozilla.org/en-us/thunderbird/addon/glodaquilla-search-indexi... but is it what we are talking about? I don't think so.
I'm not at home, my internet is limited now to 500MB/month. I'll look at those later. - -- Cheers Carlos E. R. (from 11.4, with Evergreen, x86_64 "Celadon" (Minas Tirith)) -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.16 (GNU/Linux) iF4EAREIAAYFAlIcqKYACgkQja8UbcUWM1yfeAD/Wo7Au7eozWTDnr8ckgXj0TtK 2k9a2HVKpfUkCVKtqxcA/0lHtn/T8mICJLvu7PpItQdAqQl/SrIOuOhFJbTbKGZZ =/MfO -----END PGP SIGNATURE-----
Carlos E. R. said the following on 08/27/2013 09:24 AM:
But then you have the issue of a filesystem with billions of small files...
Which gets us back to the ext[234] vs {reisterFS, BtrFS} issue. Unless someone want to demonstrate why XFS is more suitable for email than any of those. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 08/27/2013 09:45 AM, Anton Aylward pecked at the keyboard and wrote:
Carlos E. R. said the following on 08/27/2013 09:24 AM:
But then you have the issue of a filesystem with billions of small files...
Which gets us back to the ext[234] vs {reisterFS, BtrFS} issue. Unless someone want to demonstrate why XFS is more suitable for email than any of those.
Because XFS was designed for a filesystem with lots of small files. -- Ken Schneider SuSe since Version 5.2, June 1998 -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 08/27/2013 06:59 AM, Ken Schneider - openSUSE wrote:
On 08/27/2013 09:45 AM, Anton Aylward pecked at the keyboard and wrote:
Carlos E. R. said the following on 08/27/2013 09:24 AM:
But then you have the issue of a filesystem with billions of small files...
Which gets us back to the ext[234] vs {reisterFS, BtrFS} issue. Unless someone want to demonstrate why XFS is more suitable for email than any of those.
Because XFS was designed for a filesystem with lots of small files.
I'm certainly no expert, but I always thought that XFS was good for huge files, reiserfs for lots of smaller files. I also ran into the maximum partition size of reiserfs recently. Went with XFS again even with the 64-bit inode placement issue. ext4 had more storage overhead, but was a tad faster than XFS. Regards, Lew -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
Ken Schneider - openSUSE said the following on 08/27/2013 09:59 AM:
On 08/27/2013 09:45 AM, Anton Aylward pecked at the keyboard and wrote:
Carlos E. R. said the following on 08/27/2013 09:24 AM:
But then you have the issue of a filesystem with billions of small files...
Which gets us back to the ext[234] vs {reisterFS, BtrFS} issue. Unless someone want to demonstrate why XFS is more suitable for email than any of those.
Because XFS was designed for a filesystem with lots of small files.
I thought it was designed for BIG files, like for video editing. Up to 8 exabytes. With 64K blocks. And Journalling. Journalling is important! I was led to believe that many metadata operations are slower with XFS, such as creation and deletion of large numbers of files. No doubt we are, as with all the currently maintained file systems, dealing with a moving target and assertions about performance might fall into the "yes it used to be but we changed all that" unless it is intrinsic to the architecture. Like with the ext family where the number of inodes is specified at mkfs time vs the btree family where inodes are created dynamically. -- Not everything that is faced can be changed. But nothing can be changed until it is faced. - James Baldwin -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 El 2013-08-27 a las 09:59 -0400, Ken Schneider - openSUSE escribió:
Because XFS was designed for a filesystem with lots of small files.
I thought it worked best with very large files. It was reiserfs which excelled with small files. - -- Cheers Carlos E. R. (from 11.4, with Evergreen, x86_64 "Celadon" (Minas Tirith)) -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.16 (GNU/Linux) iF4EAREIAAYFAlIc1dMACgkQja8UbcUWM1ysjgD/c7XR0n4AiOosw0UjDgtTR7H+ CyzxoRuQ3kEYyzMqSqkA/iDYFJh2DU+FPGQbegd2iyCxWhtJS5/rgA598dy0UtdT =fubO -----END PGP SIGNATURE-----
participants (11)
-
Anton Aylward -
Bob Williams -
Carl Hartung -
Carlos E. R. -
Hans Witvliet -
Ken Schneider - openSUSE -
Lew Wolfgang -
Mark Tinka -
Michael Hamilton -
Per Jessen -
Rodney Baker