Starting point for package list for Fedora 7 Desktop spin

Gian Paolo Mureddu gmureddu at
Fri Jan 12 05:39:32 UTC 2007

Gian Paolo Mureddu escribió:
> Just to add my opinion. Thus far the selection of packages seem very 
> good, however may I suggest Beryl instead of Compiz? The reason why I 
> ask this is simple: performance. Beryl seems to be (quite a bit) 
> faster than Compiz. The way I see this is simple: Trying to build 
> anything on my current system will render the desktop quite 
> unresponsive when CPU % use reaches near to 80%. Window animations are 
> choppy and slow. Beryl on the other hand handles this much better (at 
> least on my current setup, and I'm not sure why that is exactly). 
> Granted, Beryl has some problems of its own, however these seem to 
> have been mostly addressed in version 0.1.4 (latests from updates), 
> not only it offers a lot more options, but if the manager is loaded, 
> the user still can decide which WM to use, on the fly... Similar to 
> the "Desktop Effects" dialog, but in my opinion more convenient.
> Another program that I'd rather use and I 100% agree with its 
> inclusion is Banshee over Rhythmbox. Not that I don't like Rhythmbox, 
> but rather that Banshee uses Mono instead of Python, and in my (albeit 
> personal) tests, I've found that Mono is less of a resource hog than 
> Python both in memory fingerprint and CPU time, at least on x86_64, 
> where in x86 they both are pretty much the same (seems the memory 
> fingerprint of python on x86_64 is exaggerated quite a bit in regards 
> to its i386 version, more than twice the memory print... Maybe a 
> leak?). Also (though I can't confirm this) Banshee has support for MTP 
> devices (pretty much all the newer portable mp3 devices and phones use 
> this new protocol, instead of MSC [UMS]), through gphoto2. I've been 
> unable to make Banshee "see" my iriver Clix player, while Amarok and 
> Gnomad2 do (but then again, these two use libmtp, not necessarily 
> gphoto2).
> As far as the office debate goes, I'd rather stick to the true and 
> tried I don't like much that it is somewhat of a disk 
> space hog, only of the packages listed on 
> and only looking at the sizes of the packages listed (are those 
> package size of the rpm file or installed size?) they amount to about 
> 651.229 Mib. This is confirmed by inspecting the size of all the OO.o 
> components on the i386 FC6 DVD. Needless to say this is quite a bit. I 
> guess one way to work around this issue is by fetching from the repos 
> any extra language pack set to be installed from Anaconda... Leaving 
> out all the langpacks OOo still amounts to about 105Mib (on the DVD).
> It may only be me, but of the system-config* utilities, wouldn't it 
> also make sense to include system-config-display? Speaking of the 
> system-config utilities, how about these:
> system-config-boot
> system-config-rootpassword
> system-config-language
> system-config-samba
> ?
> Maybe these other system-configs are a bit too much for some, but 
> talking about desktop configurations, at least Samba should be there 
> to allow file sharing with Windows computers (and Macs), so even if 
> samba is a "server" component, it would still make sense to include it 
> for a desktop computer, especially since it is way too common to 
> deploy Linux boxes into already existing Windows networks, even 
> desktop Linux. Let us not forget that even though English has become 
> the "lingua franca" of the Internet, Fedora is deployed in a wide 
> range of languages, leaving out system-config-language, is like 
> denying this to the non-English speaking audience. I'm a bit hesitant 
> about system-config-rootpassowrd and boot, but since then again these 
> are desktop machines, at least having a "nice" way to change root's 
> (administrator [Yuck!]) password is a necessity, especially if the 
> system will be (as intended) used by non-"geek" users... This might 
> also be seen as a security issue, so, I understand if it is not 
> included. However system-config-boot gives the users the possibility 
> to change their currently booting kernel if (for instance) they use 
> special kernel modules that are not available for the latest official 
> kernel. Booting the latest kernel with this lacking module will render 
> their system "unusable" to a certain degree... For instance in the 
> case of graphics drivers or other modules, the users then can easily 
> revert to a previous "working" kernel.
> I think it's all the suggestions I have for now. Looking nice, and 
> keep up the good work!

Just a little addendum to my last message: I think it is also in the 
best interest of the users to include system-config-securitylevel, how 
else would they be able to easily manage iptables and the rules? Not to 
mention SELinux and its policies... Anyway, that one is kind of obvious 
now that I think of it, and most likely will be dragged along with 

More information about the desktop mailing list