On Mon, Sep 05, 2005 at 11:13:12PM +0100, Paul Walker wrote: > On Mon, Sep 05, 2005 at 09:49:32AM -0400, Derek Martin wrote: > > > these days where hardware has gotten so fast. Often new features or > > suggestions to improve consistency have been shot down in the name of > > computing expense, but to a large extent I think this argument has become > > I'm not sure I'd call it "often". Well... I was being a bit general, not just limiting my argument to Mutt, in this particular case. However, I'd say there are still tons of patches around which have been offered up for inclusion in mutt in the past, which were rejected for performance concerns and/or code bloat reasons... Granted, things have changed a lot recently; the maintainers have become a lot more liberal in terms of what gets in these days (or at least it seems so to me). Looking back at what I wrote, the whole first part of my post really should have been re-written. It was unclear and disorganized... if one of my students had handed it in, I'd probably give it a 'D'. :) > > I really can't agree. Computing is one of the few places where you > > can have your cake, and eat it too. That is, you can implement both, > > and let the users choose which one they prefer to use... > > Without coming down on either side here, you make it sound like that's free, > and it isn't - it costs, in various ways. Sure, of course it does. But later in my post I sort of alluded to the idea that in a lot of cases, there are lots of people who would be willing to write -- and even maintain -- such code, provided they knew it would (at least conceptually) be blessed by the maintainers. The open-source community is astonishing; there seems to be no shortage of volunteers. =8^) > > By arguing against features on the basis of performance, especially > > when those features are format-specific, you're basically telling the > > user that you know best, and they should not want to perform that > > This is exactly what's done every time people decide not to make something > an option. It's not done enough, I think. I won't disagree... but I will point out that Mutt already has a bazillion options. ;-) Probably a few of these could be cleaned up and/or combined, but whatever. :) > Sure, you can go too far - step forward the GNOME people - but you > can equally go too far the other way, and make absolutely everything > an option. Sensible defaults go a long way... Actually I think Mutt has an ungodly amount of options already, but it's still manageable because most of the defaults make sense for most people (or so it seems to me). > > After all, if a particular operation is done frequently enough that the > > user decides waiting for it is too slow with their chosen format, they can > > always convert to a different one, if it is important enough... > > How do they know that it's particular to the mail format they're using, > rather than just because mutt's slow...? It isn't the average person who is attracted to Mutt... The average person wants Outlook, or something reasonably like it (poor ignorant souls)... I think most people who use Mutt are at least somewhat clueful about computing. But also, mutters are adventurous types who are not afraid to ask questions! It's been quite a while since I've been on mutt-users, but I seem to recall a number of lengthy discussions regarding performance of various options and/or mail folder formats. > > people use to compose their mail with Mutt, the Emacsen -- probably > > the most popular editor amongst Linux users, at least -- has a VSZ[1] > > Actually, I think Vim is. At least going from the yearly poll of some > magazine - Linux Journal? Can't remember... Well, I think it's pretty close. But I guess it doesn't really matter, my point is that Emacs is very popular (a lot more popular than Mutt, generally), but it seems to garner its popularity precisely BECAUSE it's bloated! People want all those features... But most importantly, despite the bloat, on modern hardware, and even not-so-modern hardware, Emacs performs just fine. > > On modern computing hardware, these issues (computing expense and code > > bloat) really have become non-arguemnts. > > ... which is how you end up with programs like Firefox, which consumes all > of your RAM. I haven't really had that experience, that I've noticed. Well, except on my old laptop, which has only 128 MB and not a whole lot of swap allocated... But even on that system, it takes a lot to make it crash. I'd be surprised if it didn't turn out that most of the problem with memory leaks were in Flash, or possibly some other badly behaved plugin, rather than with Firefox itself. But to be honest I haven't been paying that much attention, because as I said, I haven't had any problems. Maybe you're just running a particularly buggy version... OTOH I mostly use laptops, and I can't suspend them because of the NVidia proprietary driver issues, so I tend to be rebooting fairly often anyway. But, it is worth noting (for those who may not be aware) that most of the memory reported as in use by the X server usually is NOT your system's RAM, it's your video card's frame buffer (with XFree86 4.0 and later, including XOrg). It's also worth noting that the Linux kernel is aggressive about swapping out blocks that aren't in use, so that it can speed up disk access by buffering more disk blocks. Personally I think it goes much to far... But in any case, this could account for *some* of what you're seeing. :) -- Derek D. Martin http://www.pizzashack.org
Attachment:
pgpC09oARsT5p.pgp
Description: PGP signature