[GRLUG] Desktop managers

[Greg Folkert]

On Wed, 2008-11-12 at 15:22 -0500, Adam Tauno Williams wrote:
> On Wed, 2008-11-12 at 15:10 -0500, Michael Mol wrote:
> > On Wed, Nov 12, 2008 at 2:21 PM, Greg Folkert <greg at gregfolkert.net> wrote:
> > > Don't run GDM. Use a different display manager if you must use one, use
> > > the one that X (XDM) provides its no frills and very light in most
> > > respects.>
> 
> Can someone document that disabling GDM makes any difference?  Once you
> are logged in GDM is out of the picture,  the very few pages it
> allocates that aren't shared will get paged out (if needed).  So long as
> GDM isn't doing anything in the back ground (is it), it will have no
> affect at all.

Its called "Willing to manage" and XDMCP, its always watching for
certain keystrokes. Especially if it is accepting remote GUI login's
(which means its listening). Also if you have the "zephyr" or "xnest"
stuff its doing other parts, its being dubious about watching for
additional X servers to need starting.

startx does just that, no listening, no watching, the ctrl-alt-bkspc and
ctrl-alt-r etc... keystrokes are event driven vs GDM managing them.

> > > Otherwise, "startx" saves considerable resources... though you have to
> > > login on the "icky" command line.
> > startx is fine, but I haven't notice gdm continue to consume resources
> > after I log in.  Besides, being able to switch sessions when needed is
> > helpful.
> > > "XFS" (X Font Server) if you have the fonts locally and in the proper
> > > place, you don't need it.
> 
> I don't believe most workstation oriented installed run XFS by default.
> openSUSE doesn't.

Some people Still have it installed by default and running and HYARGE
amount of Fonts installed that they never use and xfs will use memory. I
may have it installed, but its not running.

> > > Any "mouse manager" isn't needed as long as you don't need it outside of
> > > X.
> > True, but gpm was designed to run on systems with 64MB of RAM...it's
> > hardly a resource hog.
> 
> The question is whether it is active while X is running.  I have no
> idea.

Yes it reads "uinput" and typically can be used at the same time as *X*
stuff, X may (depending on its build and configure) even use it vs
uinput.

> > > Run X at a lower color resolution, it amazing at how much the memory
> > > difference is between a 24/32bit display color vs 8 bit is. Yes 8 bit is
> > > 256 colors... but aren't we talking about a small resource machine? Oh
> > > yes and try not running at 1600x1200 or other HUGE resolution, as that
> > > ALSO cranks the memory the X server requires.
> > Very true.
> 
> Yep, this is the in the top three ways to improve performance.
> 
> > The problem with a framebuffer X server is that it's largely
> > unaccelerated.  Last time I used one, I had terrible tearing and lag
> > when simply scrolling a web page in phoenix or opera.
> 
> Agree,  I've never had acceptable performance running a frame buffer.

Did I say it would be GREAT performance on newer stuff? No. I've used a
straight framebuffer environment (no X) to good extent. I really should
clarify though using X framebuffer server, I don't typically use
framebuffer for anything except console work.

> > > Also, since it *IS* an older machine perhaps you don't need HAL/udev and
> > > other scanning processes, like ACPID or APMD or any kind of an AVAHI
> > > (and related services) running.
> > acpid isn't a resource hog.  And even a 700MHz system is new enough to
> > use ACPI over APM.  If you get rid of HAL/udev, though, you're
> > sticking yourself with the responsibility of managing device nodes
> > manually, which is no longer a simple thing to do.  Worse, most
> > current distros would have those packages in their "required" list.
> 
> Agree,  but if you just don't have sufficient resources you have to
> start giving things up.  The only way, IMO, to get acceptable
> performance out of a paltry 310Mb is to strip things down to a point
> where you won't enjoy using the box anymore.

I just made sure people *KNEW* that if they are forced to use this
machine and have to proceed, there *are* alternatives.

> > > Don't know if DBUS can be easily removed, but there are things t does to
> > > suck resources.
> > I don't know about this one either...
> 
> It will break numerous apps that make the desktop usable.  Even the
> clock applet uses D-Bus these days.

Bummer.
-- 
greg at gregfolkert.net
PGP key 1024D/B524687C 2003-08-05
Fingerprint: E1D3 E3D7 5850 957E FED0  2B3A ED66 6971 B524 687C
Alternate Fingerprint: 09F9 1102 9D74  E35B D841 56C5 6356 88C0
Alternate Fingerprint: 455F E104 22CA  29C4 933F 9505 2B79 2AB2
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: This is a digitally signed message part
Url : http://shinobu.grlug.org/pipermail/grlug/attachments/20081113/25be14c5/attachment-0001.pgp