From: XavierGr <xaviergr_at_gmail.com>
Date: Tue, 28 Oct 2008 02:18:44 +0200

Unfortunately Rockbox has become quite "feature-phobic" recenlty. This
wasn't the case a couple of years ago, where if the new feature in question
was implemented correctly, it was mostly accepted without any thorough
debate. The result was many and sometimes unneeded settings. Do I have
second thoughts about them even if I (or a large userbase) don't use them?
Hell No! For me that is the definition of Rockbox, "Configurability". That
is what is missing from OFs of other devices and that is the purpose of the
project (to my view), to give more options(plugins/codecs etc) to the user
(without of course lacking robustness, stability and usability).

The way I see it is that for the sake of rombox on archos (and their low
ram) most targets are drugged down. There is no real issue except those
targets (which is indeed a problem). I've yet to see a benchmark that
signifies lack of battery time resulted by settings overbloat (on high mem
targets) and while there is a tiny decrease it is insignificant. The major
increase in RAM usage came with dircache and Database (tagcache) which I
think nearly all of us find them as the most valuable features (and luckily
can be disabled to ensure less RAM usage).

On the other side I am glad that we are nitpicky, that way we ensure that
the best implementation is coded for inclusion. This though, is sometimes
exaggerated and some new features are ostracized. In current situation even
for the slightest settings addition you need at least 200-300 bytes even for
a simple integer setting. Most of it comes from the settings-mechanism
overhead and not the feature itself. The solution to this overhead could be
separating the settings to a plugin, an idea which I dislike but if it
allows us more settings I will happily welcome it.

About performance and complexity there is not much to be said. Performance
wise a new setting is responsible for another index on the settings
structure (loading/saving no performance lost on that) and of course
accountable for the changes or additions it introduces. Some settings can be
a resource hog (mostly playback settings), while others are quite innocent
with minor additions/changes to the core. Of course the setting in question
should be refined and be as optimized as possible. New settings can make
code more complex (not always though), but rejecting a new setting because
is complex is like saying "I don't want it because it is too difficult for
me. I am lazy and afraid of touching that part of code because it might
break it." In any case very complex settings are rare and all new ones
should be included after making sure that they are less complex as possible.

On the user side of things I haven't EVER heard of a user to complain about
"too many settings". That's in fact the grand attraction of Rockbox. The
user that doesn't want or care about more options can just use the default
firmware. I can understand frustration of not being able to customize
something, but I will never understand why someone will complain of
over-customization, it doesn't make sense. Yes, the settings menu could be
more user-friendly but I don't find it too bad at all. It is logically
separated in categories and the only problem more settings add to it, is
that you might need to press more buttons to do what you want. Some
"setting-bloat haters" could be pleased with a hidden advanced settings
menu, which I don't understand at all (save for the fewer button presses),
but again if that makes people happy I am all for it.

Basically Rockbox development (again the way I see it), consists of 3 major
parts:
1. New ports
2. Iron out bugs and optimization
3. New features or altering existing ones

My opinion is that some developers would be very glad to strike out number 3
entirely or to limit it as possible. Based on their usage patterns they miss
entirely why a new feature or setting could be needed. A feature almost
always will introduce at least one new setting. Rejecting settings limits
feature usage and without new features is like having an "eternal feature
freeze". Surely this is not something the project needs. It must evolve and
get better. We all remember that some feature freezes in the past were
introduced with lack of interest by contributors.

In the end of course, developers decide what's best for Rockbox (and I hope
they are right). I understand that it is impossible and impractical to have
everything turned into a setting, but Rockbox is far away from that
situation. I only resent what I might miss from future settings/features
that will be rejected "on the shrine" of binsize and "the doctrine of
settings-bloat". :P For me that was the key feature, over-customization.
That was the part that made Rockbox appealing and tempted me to add my own
minor contributions. Most new contributors just like to make the project
better by adding the content they thing is missing.


P.S: This of course has nothing to do with FS#9455. It is understandable if
it is deemed unneeded (though obviously I disagree :P). My disappointment
though comes from further features/settings that users might miss, on a
consensus that doesn't favor new settings.
Received on 2008-10-28