<html>
<body>
<br>
I will have to investigate this further.&nbsp; Which distributions are
you referring to?<br><br>
This would be a crying shame!&nbsp; I would hardly think it would<br>
make sense to change the use of the sticky bit.&nbsp; It's intent<br>
and impact was indeed quite real.&nbsp; This would be more like<br>
MS Office programming, not an O.S. Fat cats get at it?<br><br>
If every invocation of Linux is copied to swap, they have<br>
regressed to days prior to AT&amp;T Unix System V.3. Why<br>
would they do this?&nbsp; Sell more Ram? Enjoy waiting while<br>
the same text pages from the same executable are loaded<br>
to swap?<br><br>
On my RH Enterprise 3.0.&nbsp; Fresh boot, loading a utility I<br>
developed a ways back, loads itself, then recursively calls<br>
subroutines, and allocates normal heap and stack (by default,<br>
it can be set, and has some Shared Memory options as well),<br>
from my olden days, shows on repeated load, the amount of<br>
virtual memory utilization did not increase, nor did the swap<br>
space allocated.<br><br>
(Commercial distributions we run on our IBM platforms, even<br>
up to the time they switched from AIX acted in this manner...<br>
I can't say it is this way for all distributions. However if this 
is<br>
the case, than IMPO, Linux just became an inferior Cheap<br>
Unix. I wouldn't mind... if it not been removed!<br><br>
I have seen your writing before, and indeed I believe you, and<br>
the&nbsp; quote, I just &quot;cant' believe&quot; the quote.&nbsp; Are
they referring<br>
to perhaps a &quot;regular&quot; non-executable file (I refer to in
Kernel<br>
speak as text, hope that did not confuse anyone..)...&nbsp; When I
say<br>
&quot;Text pages&quot;, I am referring to the &quot;executable code&quot;
that is either<br>
static, or dynamic through a shared&nbsp; &quot;reentrant&quot;
library....<br><br>
I will be able to check RH 9.0, Mandrake 10.1, (which I just<br>
received an update on) SuSe 7.3, and Slackware 7.1<br>
This would really bum me out Steve...<br>
&nbsp;<br>
With Regards<br><br>
Mark<br><br>
ps. I was rushing to catch a train... didn't see the long
tail...<br><br>
<br>
At 09:44 AM 12/9/2004, Steven Hartland wrote:<br>
<blockquote type=cite class=cite cite><font size=2>Couple of
points:</font><br>
<font size=2>1. Sticky bit is useless:</font><br>
<font size=2>Quote &quot;man sticky&quot;:</font><br>
<font size=2>&quot;A special file mode, called the sticky bit (mode
S_ISVTX), is used to<br>
indicate special treatment for directories.&nbsp; It is ignored for
regular files&quot;</font><br>
<font size=2>2. </font>Executable's copied to swap<br>
<font size=2>This is not true for a number of modern OS's inc FreeBSD and
linux?</font><br>
<font size=2>The only one that springs to mind that still does this is
Irix but its been</font><br>
<font size=2>a while since I dug down into this behaviour on OS's other
than FreeBSD</font><br>
<font size=2>so I would be talking crap :P</font><br>
<font size=2>3. Might want to trim the crap from you posts i.e. the 220
lines at</font><br>
<font size=2>the bottom :)</font><br>
&nbsp;<br>
<font size=2>&nbsp;&nbsp;&nbsp; Steve / K</font><br>
&nbsp;<br>
&lt;snip&gt;<br>
================================================<br>
This e.mail is private and confidential between Multiplay (UK) Ltd. and
the person or entity to whom it is addressed. In the event of
misdirection, the recipient is prohibited from using, copying, printing
or otherwise disseminating it or any information contained in it.
<br><br>
In the event of misdirection, illegible or incomplete transmission please
telephone (023) 8024 3137<br>
or return the E.mail to postmaster@multiplay.co.uk.
</blockquote><tt>S1---------------------------------------------------------------------------<br>
Mark J. DeFilippis, Ph. D
EE&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
defilm@acm.org<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
defilm@ieee.org<br><br>
<br>
</body>
</html>