<br><div><span class="gmail_quote">On 4/27/06, <b class="gmail_sendername">BillK</b> <<a href="mailto:pharos@gmail.com" target="_blank" onclick="return top.js.OpenExtLink(window,event,this)">pharos@gmail.com</a>> wrote:
</span><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
Yes, they are both on versions of the 2.4 kernel.  Puppy did move to<br>the 2.6 kernel but they were flooded with complaints from the users<br>(me included) because the 2.6 kernel wouldn't run on lots of old pcs.<br>So they reverted to 
2.4.</blockquote><div><br>I can understand 386's and 486's but what would be the problem with basic Pentiums?  (The fact that I've got Unbuntu running on one would seem to suggest there isn't any real fundamental problem.)
<br></div><br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
Puppy uses Fvwm95 as the main window manager. This is a slightly<br>modified version of Fvwm v2.0,  JWM is also installed if you prefer<br>it. And users have got Fluxbox and IceWM running also as options.<br>DSL uses Fluxbox.  So no need for X Windows here.
</blockquote><div><br>I thought X was a requirement for graphics displays -- am I misinformed?<br>Aren't Fvwm and IceWM stand-ins for GNOME or KDE (but still run on top of X)?  I will admit that GNOME isn't lightweight and I'm under the impression (though I haven't tried running it yet) that KDE is even worse (based on the package install sizes from Gentoo) so Fvwm | IceWM would seem like reasonable choices for the legacy hardware.
<br></div><br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">The Dillo browser is *very* fast on old pcs, but they both have<br>Firefox available if you need a full-featured browser.
</blockquote><div><br>I'll check it out!  There are some days I really *long* for Netscape 4.X (which can still be run if you wrestle with library compatibility issues).<br></div><br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
I keep reading about Firefox memory problems, but I live all day in<br>Firefox with 7 or 8 open tabs and have never had any problems (Linux
<br>or Windows).  But I avoid heavy video or multimedia web use, so that<br>might be the clue.</blockquote><div><br>How much memory is on your machine and how long do you keep FF running?  You probably will not see them unless you have a machine with 512MB or less and leave the browser running for days.  The problem is basically heap fragmentation interacting with Linux page management.  Over time you have small memory memory allocations (history records, bookmarks, "active" aspects of extensions (RSS records), gmail pages, etc. grabbing small chunks of memory across the entire heap.  The heap size grows over time until the Firefox resident page set is pushing about 70% of the memory on the machine (~350+MB out of 512MB).  That would be manageable if it weren't for the fact that new memory allocations, freeing old memory and the garbage collector that runs at random intervals (I think the GC is in there to support Java & Javascript but I'm not sure) have to go through essentially all of the memory in the heap (all of the allocated chunks are in linked lists).  Even though Linux will run up to 2000-3500 swap-ins per second it still takes a long time to run through all of the pages in the heap that have been paged out.  Though it doesn't crash Linux it will make both FF and everything else relatively unusable.  Alternatively it can cause the dreaded "oom-killer" to run which will start killing off processes (Firefox included) until it has enough memory to continue operating.  [In my case it usually takes out Azureus which is a process pig because it needs one for each "peer" it is exchanging files with and a memory pig because it is written in Java and has a poor one-to-many communications design -- but thats a different discussion.] [1]
<br></div><br>You also are unlikely to notice it with "7 or 8 open tabs".  "Real" men, cough, like to run it with 15-20 open windows some of which have been pushed past the 33 tab limit (at least on a 1024 pixel wide screen).  This tends to be browser pattern related -- I'll open 5-10 tabs from the front page of the NY times, another 5-10 from /., 20+ from the first 5+ pages of digg, and dozens if I'm doing specific topic research in PubMed and want to page back & forth between lots of abstracts.  If you are a few page at a time user you are unlikely to encounter it.
<br><br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">You probably need a separate thread for favorite Firefox extensions.  :)
<br>I prefer Adblock Plus, CustomizeGoogle and Bugmenot.<br>The PrefButtons and PrefBar extensions give a line of useful buttons<br>(customisable) including ones to switch on/off Javascript, Java,<br>Flash, and other functions.
</blockquote><div> <br>
Interesting set, I'll have to investigate them.</div><br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">I have more extensions installed, but they are not of general interest.
<br>(There are hundreds available now for customisers gone mad!).</blockquote><div><br>Yes, one of the more interesting aspects of Firefox is that it has a "lightweight" extension capability without the requirement for getting into the guts of the system (I've looked at the source briefly and its sufficiently complex that I am very reluctant to wade into it).
<br><br>Robert<br><br>1. Firefox (and Azureus) could serve a the "poster children" for how *not* to do software development.  I may be wrong but it looks like nobody sat down at the beginning and specified how resources should be managed by the various sub-systems (Java, Javascript, image display, internal databases, communications, etc.).  Every subsystem seems to have made their own choices assuming "Oh, its intended for 32-bit virtual systems and the OS will handle it" or "Memory is cheap, don't worry about it."  Bad, bad, bad!  Back in the days when you had to time share 256MB between ~30 users (Harvard's undergraduate Science Center circa 1974-6) you had to really pay attention to such things as memory usage and paging/swapping efficiency.
<br><br></div></div>