X Strike Force XFree86 SVN commit: r1624 - in trunk/debian: . local
Author: branden
Date: 2004-07-11 13:31:43 -0500 (Sun, 11 Jul 2004)
New Revision: 1624
Modified:
trunk/debian/CHANGESETS
trunk/debian/local/FAQ.xhtml
Log:
(cosmetic) Add XHTML markup to a FAQ entry.
Modified: trunk/debian/CHANGESETS
===================================================================
--- trunk/debian/CHANGESETS 2004-07-11 11:38:50 UTC (rev 1623)
+++ trunk/debian/CHANGESETS 2004-07-11 18:31:43 UTC (rev 1624)
@@ -13,7 +13,7 @@
1606
Miscellaneous cosmetic fixes.
- 1607, 1608
+ 1607, 1608, 1624
Grab latest version of XTerm (#191) from Thomas Dickey's website.
1609
Modified: trunk/debian/local/FAQ.xhtml
===================================================================
--- trunk/debian/local/FAQ.xhtml 2004-07-11 11:38:50 UTC (rev 1623)
+++ trunk/debian/local/FAQ.xhtml 2004-07-11 18:31:43 UTC (rev 1624)
@@ -1847,7 +1847,8 @@
<p>(Especially heard from KDE users with large monitors, many workspaces, and a
different picture in the root window of each workspace.)</p>
-<p>Answer courtesy of Mark Vojkovich of the XFree86 Project, Inc.:</p>
+<p>Answer courtesy of Mark Vojkovich of <a href="http://www.xfree86.org/";>The
+XFree86 Project, Inc.</a>:</p>
<blockquote>
<p>The X Window System is a client-server window system. The memory for pixmap
@@ -1861,22 +1862,26 @@
instead, people would be complaining about KDE memory usage.</p>
</blockquote>
-<p>Additionally, Sean McGlynn of the KDE Project offered assistance:</p>
+<p>Additionally, Sean McGlynn of the <a href="http://www.kde.org/";>KDE
+Project</a> offered assistance:</p>
<blockquote>
- <p>Please direct such users over to KDE's mailing lists —
- http://www.kde.org/mailinglists.html — and we can try and
- investigate/resolve their issues fully.</p>
+ <p>Please direct such users over to <a
+ href="http://www.kde.org/mailinglists.html";>KDE's mailing lists</a> —
+ <code class="other">http://www.kde.org/mailinglists.html</code> — and we
+ can try and investigate/resolve their issues fully.</p>
</blockquote>
-<p>David B. Harris of Debian also has these remarks:</p>
+<p>David B. Harris of <a href="http://www.debian.org/";>Debian</a> also has these
+remarks:</p>
<blockquote>
- <p>Something worth noting is also the concept of "leaking". This will be a term
- familiar to some and unknown to others. Basically, as processes run they
- may dynamically allocate memory for some purpose or other. If they allocate
- some memory, but never *de-allocate* it, even after they're done using it,
- then over time the memory used by that process will increase.</p>
+ <p>Something worth noting is also the concept of <em>leaking</em>. This will
+ be a term familiar to some and unknown to others. Basically, as processes run
+ they may dynamically allocate memory for some purpose or other. If they
+ allocate some memory, but never <em>de-allocate</em> it, even after they're
+ done using it, then over time the memory used by that process will
+ increase.</p>
<p>Since hardware/video drivers in XFree86 are responsible for some of this
allocation and de-allocation, a badly-written driver can increase the memory
@@ -1891,7 +1896,8 @@
all) due to these drivers.</p>
</blockquote>
-<p>Finally, Mike A. Harris of Red Hat Software offers the following advice:</p>
+<p>Finally, Mike A. Harris of <a href="http://www.redhat.com/";>Red Hat
+Software</a> offers the following advice:</p>
<blockquote>
<p>I'd like to add to that another frequently reported problem of XFree86
@@ -1899,15 +1905,16 @@
can't see any reason why it should. They blame X for being bloated, etc.</p>
<p>Digging into it more however, 99 times out of 100, they are using the
- output of top or procps or similar utility do show how much memory XFree86 is
- consuming. Unfortunately, the memory reported as used in top/ps output is
- interpreted solely as being system RAM and/or swap, and that is very
+ output of <code class="command">top</code> or <code
+ class="command">procps</code> or similar utility do show how much memory
+ XFree86 is consuming. Unfortunately, the memory reported as used in top/ps
+ output is interpreted solely as being system RAM and/or swap, and that is very
misleading as it is not true.</p>
- <p>The memory shown by top, which users are misled into believing is memory
- used up by X, is an amalgamation of the video card's own memory, and memory
- mapped I/O regions, as well as the actual memory used by the X server,
- pixmaps, and various other things.</p>
+ <p>The memory shown by <code class="command">top</code>, which users are
+ misled into believing is memory used up by X, is an amalgamation of the video
+ card's own memory, and memory mapped I/O regions, as well as the actual memory
+ used by the X server, pixmaps, and various other things.</p>
<p>It is not at all uncommon for a modern 64Mb video card, to have X's memory
usage appear to be 100Mb or more, when in reality, 64Mb of that is video RAM,
Reply to: