2008/10/28 Paul Louden <paulthenerd_at_gmail.com>:
> XavierGr wrote:
>> will be rejected "on the shrine" of binsize and "the doctrine of
> Can we please try to have this discussion without resorting to rhetoric and
> terms like this?
apparently not... 3 messages back from you agreed that it ALWAYS comes
back to this.
> And, as a point of interest, we're already using ~20-25% of the available
> RAM on the Cowon Coldfire-based players as it stands, binsize is not *only*
> important to the Archos players. We're also looking at players that only
> have 384kb of RAM, which makes binsize an even more significant hurdle for
> those (which will probably need a specially toned down build of Rockbox
RAM size to target count:
<2MB - currently 0, 2 "in the works"
2- 8MB - 7
16MB - 4
32+ - 16
The old targets are holding us back. Most big features are #ifdefable
out, and those that arntt, could be.
To the people that really claim they want battery performace above
everything, mind posting your config? I assume you have the file and
playlist max size right down? last.fm, dircache, ramcache, cuesheet
(unless you actually have any) all disabled? Thats an easy way to
reclaim 2MB (Tried it on my beast). Using your own custom build with
unused features disabled?
> Honestly, in my opinion, complaining that we're accepting features too slow
> is ignoring the fact that the project is quite mature now. We need to be
> picky about features.
Why? since when should mature projects call it quits? the Linux kernel
has been going for over 10 years now and its still adding lots of
features.. are you saying its not mature yet? bringing in yesterdays
IRC conversation about TV... CRT's could be considered very mature why
bother upgrading the tech to LCD/Plasma? surely old outdated stuff is
Besides, the only reason to use the maturity argument is to say that
you want to consolidate the current feature set and get ready to
package and sell it, who are we selling to? its always been about
rockbox for the devs not the users.
Received on 2008-10-28