[gentoo-amd64] Re: Re: Re: Re: Wow! KDE 3.5.1 & Xorg 7.0 w/ Composite

[Duncan]

Bernhard Auzinger posted
<200602092009.41427.e0026053@×××××××××××××××××.at>, excerpted below,  on
Thu, 09 Feb 2006 20:09:41 +0100:

> It's funny, Duncan. On the one side you are saving every byte of
> cpu-cache. On the other side, you are happy by having forked bashes in
> your main memory. But how do you take control about that? I mean, how do
> you get the code of your forked bashes away from your cpu cache to have
> it free for kernel code?

Actually, not all of them fork.  I hadn't mentioned it, but most of the
single-liners use "exec", so fork the single-line bash script off of my
invoking session (so it doesn't close when the command is finished) when I
initiate it, then use that same bash script process to run whatever the
bash script calls.

Similarly, because I initiate X/KDE from the command line rather than
using kdm/xdm/whatever, I'd normally have the initiating VC bash instance
hanging around, but run a script that starts X/KDE in the background,
sleeps for 30 seconds, then disowns everything and exits.  (I do it this
way rather than executing a forkless exec, for troubleshooting purposes,
in case X can't start, and because at some point, I discovered that if the
session didn't stick around for a bit, X would stop with it, regardless of
the disown.)

Likewise, when I sudo from my restricted normal user to my "admin user"
(which isn't root, but has unrestricted sudo abilities) I source a script
(thereby running the script in my existing user bash process) that execs
the sudo, such that I end up without any stacked idle processes taking up
resources behind my admin session.  When the admin session exits, it
either logs me out entirely (at a VC) or closes that konsole tab (if I'm
in X and using konsole).

That brings up an entirely different layer I have as well.  In addition to
/l/bin (also available in the traditional /usr/local/bin location,
courtesy of a symlink) and /l/sbin, I have /l/sudobin, which contains
stub-scripts for most of the ea* and similar root-required scriptlets
(naturally ep* doesn't require that, as emerge --pretend doesn't require
root), that simply exec sudo their /l/sbin counterparts. That way, for
commonly issued emerge and other admin commands, I don't have to directly
sudo them from the admin user, only invoke them as I would directly as
root.  At the same time, I retain protection against an errant rm -rf .*
or the like (keeping in mind the consequences of such, due to the ..
parent dir entry) as the admin user, and while sudo rm -rf .* would
certainly do it, I know that every time I stick sudo in front, as the book
"Running Linux" advises, "Sit on your hands a moment and make *VERY* sure
the command is what you /think/ it is, and will do what you /expect/ it to
and no more, before you hit that enter key."  Naturally, these
stub-scripts use the source command or exec as well, the result being that
sometimes there's a /whole/ /series/ of separate commands operating
serially as the same system process, no forking.

Of course, Linux' COW (copy on write) memory management scheme ensures
that the bash instruction code would remain shared anyway, as Kevin Quinn
mentions, but there's still the unique session data to contend with, and
in any case, I don't like seeing those stacked processes that are of no
further use, hanging around in top/ps/ksysguard/etc, so where possible I
eliminate them.

-- 
Duncan - List replies preferred.   No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master."  Richard Stallman in
http://www.linuxdevcenter.com/pub/a/linux/2004/12/22/rms_interview.html


-- 
gentoo-amd64@g.o mailing list