Garrett D'Amore wrote: > Eric Boutilier wrote: > >> On Wed, 25 Oct 2006, Dave Miner wrote: >> >>> Garrett D'Amore wrote: >>> >>>> Glynn Foster wrote: >>>> >>>>> Hey, >>>>> >>>>> Garrett D'Amore wrote: >>>>> >>>>> >>>>>> I realize that a lot of focus is being spent on JDS 3/gnome, and that >>>>>> this is largely a good thing for the end user. >>>>>> >>>>>> However, I am interested, also, in having a "lightweight" desktop >>>>>> environment, suitable for use by system administrators to access gui >>>>>> tools on machines that are otherwise not normally used as a desktop. >>>>>> (Think of an NFS server somewhere. It is useful to be able to run >>>>>> smc >>>>>> and such tools, without paying the full price of Gnome.) >>>>>> >>>>>> The requirements for such an environment would not be dissimilar to >>>>>> those required for graphical suninstall -- a basic window manager >>>>>> like >>>>>> mwm or dtwm would be adequate. I'd be even happier if we got >>>>>> something >>>>>> like xfce4, which was open source, into such as an environment >>>>>> (but then >>>>>> again, I use xfce4 on my primary desktop). >>>>>> >>>>>> >>>>> Sounds good to me - maybe it's something you'd like to consider >>>>> championing? >>>>> While it's probably a good business case for Sun to support any >>>>> more desktops >>>>> than we currently do [1], we could consider doing something like >>>>> this in the >>>>> companion CD? >>>>> >>>>> >>>>> Glynn >>>>> >>>>> [1] And after CDE moves away, I'd far rather capture that space and >>>>> reduce >>>>> the number of CD's in a Solaris install than add another >>>>> desktop env >>>>> >>>>> >>>> I have no idea if I can champion anything at all. But see my earlier >>>> post with respect to "environments". At this point I would be strongly >>>> in favor of picking up fvwm a basic Window Manger (not a whole desktop >>>> environment) and putting it in the basic install (the same place that >>>> twm is found) so that suninstall etc. can make use of it. I would >>>> _not_ >>>> like this on a separate companion CD, because at that point it loses >>>> most of its advantages (sysadmins can't "count on it being there", and >>>> Sun can't use it for suninstall, etc.) >>>> >>>> >>> I'm doubtful that we're interested in it for Solaris installation. >>> We're moving in the direction of providing a full Gnome desktop instead >>> that lets you try things out before installing or while the install is >>> happening. Other distributions might make other choices, I suppose, but >>> that's what we're looking at for Sun's. >>> >> Along those lines, what about isolating GNOME's window manager as Garrett >> asked about yesterday (see below). Is it feasible? >> >> Eric >> >> On Tue, 24 Oct 2006, Garrett D'Amore wrote: >> == (Possibly the basic window manager from gnome would work too, >> == as long as we only start up the window manager and not all >> == the other gobbeldy-gook associated with gnome. I haven't >> == looked lately, so I have no idea how tightly integrated the >> == window manager in gnome is to the rest of the desktop.) ... >> > > FYI, I found that even isolated, metacity sucked up about 67M size and > 10M rss. The "size" was more than 6X its nearest competitor of the > options I tested. (This is what some people like to call "bloatware".) >
A lot of that memory usage is mmap-ed shared libs that will in any case be used by other apps. For example both Metacity and Firefox will use libgtk-x11 which is a big library. So if you start Fvwm and then run any app that uses gtk, it will be loaded anyway. Also another big chunk of that memory will be the mmap-ed medialib library that the patched gtk uses on Solaris. You'd probably want to do a pmap -x to get a better idea of the mem usage. On my Aspire AMD64 sytstem running B43 Metacity shows 45M size and 10M RSS, of which 2.5M accounts for Metacity's own usage via heap+stack+anons and the remaining are all shlib mappings. Medialib is the bulk occupying about 16M in size but 500K RSS. But having said that it is also true that Fvwm does not use that many dependency libs and overall does less amount of mmaps and page faults and ... so it is more lightweight to startup and use. But I doubt whether you can avoid loading Gtk and friends into memory since so many apps use Gtk today. Regards, Moinak. > I was pretty surprised by that result, btw. Right now I'm a big fan of > fvwm as an approach, because its size is ~2.9M rss/4.6M size, and it > provides the basic facilities we need, plus a lot of extras that can be > _optionally_ enabled (at run time, by running helper applications). It > also can provide the basic Motif L&F that we have historically had. > > -- Garrett > >
