<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
  <meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
</head>
<body bgcolor="#ffffff" text="#000000">
OK, I'm not a hacker, just a systems engineer, so there's a lot I don't
know here.  I could use a little clarification.  According to this,
you'd likely need 256MB or more in your thin client for just regular
ol' Web surfing, or writing OpenOffice.org documents, or viewing photos
of your kids--anything involving these images getting turned into
pixmaps by *any* X11 application, and 512MB in the client would not be
unreasonable at all.  But now we're getting into thick-client
territory; Dell's new Ubuntu PC's come with 512MB DRAM.<br>
<br>
I know, from experience on my thick clients, that X11 can suck up over
400MB until I start shutting apps down (Firefox is one of those apps;
Evolution is another).  However, I also know, from experience, that my
clients with 32MB and 64MB do not die when I use Firefox, etc. 
According to the below, X11 should indeed be dying on them left and
right.  I'm using K12LTSP 4.2EL.  Could there be something else that
we're just missing here?<br>
<br>
--TP<br>
<div class="moz-signature">_______________________________
<br>
Do you GNU!?
<br>
<a href="http://www.gnu.org/">Microsoft Free since 2003</a>--the
ultimate antivirus protection!
<br>
</div>
<br>
<br>
Jim McQuillan wrote:
<blockquote cite="mid4656D15B.4030101@McQuil.com" type="cite"><br>
  <br>
Daniel Bodanske wrote:
  <br>
  <blockquote type="cite">So Firefox stores pixmaps uncompressed in the
X server cache.
    <br>
Unbelievable. Is it Firefox or Gecko? Does Seamonkey suffer the same
    <br>
limitation. Could you move to Epiphany? Wow.
    <br>
  </blockquote>
  <br>
This is not unusual.  everybody seems to be implying that firefox is
being evil by doing this.
  <br>
  <br>
The Xserver caches pixmaps and fonts.  No big deal.  It's part of the
design of the X Window System.  The problem is, with tabs, the browser
can actually be viewing more than one page at a time, which means there
can be alot more pixmaps sent from the browser to the Xserver.  The
Xserver just happily caches them.
  <br>
  <br>
A flaw in this design is the fact that when the thin client gets low on
memory, the Xserver has no mechanism to deal with it.  It can't throw
away pixmaps from the cache, because it has no way of telling the
client application that it no longer has the image cached, so there's
no way for firefox to re-send the pixmap when the user comes back to
that page.
  <br>
  <br>
So, sadly, the Xserver runs out of memory, and bad things happen.
  <br>
  <br>
I've brought this up to the X.org developers and everybody agrees that
it's a big problem, but unfortunately, there's not an easy fix.
  <br>
  <br>
It's not just firefox that is involved here. Any graphical application
will send images and fonts to the Xserver, and expect those things to
still be in the Xserver later on.  I suppose Firefox could be modified
to never expect those things to be cached, which means it would have to
send the images and fonts each time you switch from one tab to another,
or scroll the page up and down.  Imagine the screams you'd be hearing
as the performance goes down the tubes, and the network traffic goes
through the roof.
  <br>
  <br>
We tried fixing this a few years ago in LTSP by placing a limit on how
much ram the Xserver could allocate.  This managed to keep the Xserver
from crashing, but then the client application would crash because it
didn't expect the Xserver to fail to allocate the memory for it.  If
the client is the browser, the browser would crash, which is easily
recoverable.  But, what if the client application is something more
important, like the window manager?
  <br>
  <br>
It's a tough problem, and I wish I had the magic fix for it.
  <br>
  <br>
Jim McQuillan
  <br>
<a class="moz-txt-link-abbreviated" href="mailto:jam@Ltsp.org">jam@Ltsp.org</a>
  <br>
  <br>
  <br>
  <br>
  <blockquote type="cite"><br>
I began to get scared a few years ago when so many new desktop
    <br>
applications started to get written for Linux. So many of them
    <br>
wouldn't work over the network. I got worried that LTSP might become
    <br>
non-viable some day when all the standard apps needed local resources.
    <br>
Once Freedesktop.org was started and picked up momentum with Jim as
    <br>
one of the founding members, I calmed down, but I guess I shouldn't
    <br>
have. Firefox seems to follow it's own rules all the time, anyway.
    <br>
    <br>
Dan
    <br>
    <br>
On 5/25/07, Dan Young <a class="moz-txt-link-rfc2396E" href="mailto:dyoung@mesd.k12.or.us"><dyoung@mesd.k12.or.us></a> wrote:
    <br>
    <blockquote type="cite">On 5/24/07, Rob Owens
<a class="moz-txt-link-rfc2396E" href="mailto:rowens@ptd.net"><rowens@ptd.net></a> wrote:
      <br>
> So maybe the question should be:  Is there a browser that it
better
      <br>
> suited to LTSP than Firfox is?
      <br>
      <br>
Well, part of it comes down to tuning. Eric put together a Firefox
      <br>
extension that sets several options to more friendly levels. In
      <br>
particular:
      <br>
      <br>
browser.cache.memory.capacity
      <br>
and
      <br>
browser.sessionhistory.max_total_viewers
      <br>
      <br>
The defaults are variable depending on the total memory of the
      <br>
computer. Of course, in an LTSP environment, it's all shared, so a 4G
      <br>
host can't expect to have all that for one browser instance.
      <br>
      <br>
As I understand it, the defaults have been dialed back somewhat for
      <br>
Firefox 2. Eric's Firefox extension dials back these values too.
      <br>
<a class="moz-txt-link-freetext" href="http://www.redhat.com/archives/k12osn/2006-May/msg00372.html">http://www.redhat.com/archives/k12osn/2006-May/msg00372.html</a>
      <br>
      <br>
-- <br>
Dan Young <a class="moz-txt-link-rfc2396E" href="mailto:dyoung@mesd.k12.or.us"><dyoung@mesd.k12.or.us></a>
      <br>
Multnomah ESD - Technology Services
      <br>
503-257-1562
      <br>
      <br>
_______________________________________________
      <br>
K12OSN mailing list
      <br>
<a class="moz-txt-link-abbreviated" href="mailto:K12OSN@redhat.com">K12OSN@redhat.com</a>
      <br>
<a class="moz-txt-link-freetext" href="https://www.redhat.com/mailman/listinfo/k12osn">https://www.redhat.com/mailman/listinfo/k12osn</a>
      <br>
For more info see <a class="moz-txt-link-rfc2396E" href="http://www.k12os.org"><http://www.k12os.org></a>
      <br>
      <br>
    </blockquote>
    <br>
_______________________________________________
    <br>
K12OSN mailing list
    <br>
<a class="moz-txt-link-abbreviated" href="mailto:K12OSN@redhat.com">K12OSN@redhat.com</a>
    <br>
<a class="moz-txt-link-freetext" href="https://www.redhat.com/mailman/listinfo/k12osn">https://www.redhat.com/mailman/listinfo/k12osn</a>
    <br>
For more info see <a class="moz-txt-link-rfc2396E" href="http://www.k12os.org"><http://www.k12os.org></a>
    <br>
  </blockquote>
  <br>
_______________________________________________
  <br>
K12OSN mailing list
  <br>
<a class="moz-txt-link-abbreviated" href="mailto:K12OSN@redhat.com">K12OSN@redhat.com</a>
  <br>
<a class="moz-txt-link-freetext" href="https://www.redhat.com/mailman/listinfo/k12osn">https://www.redhat.com/mailman/listinfo/k12osn</a>
  <br>
For more info see <a class="moz-txt-link-rfc2396E" href="http://www.k12os.org"><http://www.k12os.org></a>
  <br>
</blockquote>
</body>
</html>