Starting point for package list for Fedora 7 Desktop spin
Gian Paolo Mureddu
gmureddu at prodigy.net.mx
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 OpenOffice.org. I don't like much that it is somewhat of a disk
> space hog, only of the packages listed on
> http://download.fedora.redhat.com/pub/fedora/linux/core/6/i386/os/Fedora/RPMS/,
> 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
first-boot.
More information about the desktop
mailing list