[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: rawhide and cooker compared

Austin Acton wrote:
This may or may not be of any use to you.  It's not meant to be a bug
report.  It's just my back to back comparison of two distros that people
think of as being similar or related or in competition for users.  Due
to the nature of development snapshots, some of the information is out
of date already (like ondemand scaling, it's fixed).  Hopefully, at the
very least, someone at Fedora finds it useful to see what works and what
users like.

"I've done a crazy thing. I installed the development versions of
Mandriva Linux (Cooker) and Fedora (Rawhide) back to back on the same
laptop and compared the results. I was very surprised with the results,
so I spent several hours trying to make them legible to others. They are
biased, personal, and hardware-specific, but if you're interested in the
state of rpm-based linux distros, do check out Rawhide vs. Cooker."


Some remarks (based on TFA, not on the mailinglist post):

* sensors working with lm_sensors

Note: I'm an upstream lm_sensors contributer and co-maintainer of most sensor related packages in Fedora.

About lm_sensors not being installed by default, thats because for the average users lm_sensors is not usable as it requires manual configuration.

About telling the user that he should run sensors-detect after installing lm_sensors, when and how do you envision this being told to the user?

* menus: Games section too long

This can be fixed by doing "yum install games-menus" not everyone likes having the games menu sub-menu-ed, and for a default install with just gnome-games, that indeed is a bit overkill. Thus we have the games-menus package, adding submenus for those of use who install lots of games :)

* random oddities: nspluginwrapper installed and used even on i386, why?

To run the flash plugin and other unstable plugins in their own process so that a crashing plugin doesn't take down firefox entirely

* random oddities: at random times, "prelink" process consumes 25-50% CPU and tonnes of disk activity for no apparent benefit

prelink starts up binary executing by adding some info of which libraries to load where to the binary, this is run periodically as the prelink process needs to be redone after some libs / binaries are updates. Note that not running prelink doesn't break anything, it just causes a slight slowdown.

About the random time, thats anacron for you, it tries to schedule tasks cron missed (at night, when your laptop was turned off) when your system is idle.

Thanks for the feedback, also please file bugs for all issues which could be considered such.



[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]