pepedog wrote:Dom the BCM guy said 800 was stable, does not void warranty, so I thought why not? A 14% increase in speed free of charge.
Don't get me wrong. I agree in implementation personally and I will deffinitely be overclocking some of these bad boys even to the warranty voiding levels and possibly to destruction just because I can. I fully predict I'll be running all my Pi's at 800Mhz or more continuously for that extra oomph.
However, where I disagree is the motion to unilaterally make this decision for the end user. I don't want to step on any toes but I feel that this goes against the Arch Way(tm) of giving vanilla states of software packages and then allowing the end-user to make any modifications that they choose to make. Arch is one of the few distros that modifies upstream packages as minimally as possible keeping them as the coders intended, in-so-long-as it's possible. And I would think that same mentality should be maintained in regards to hardware configurations.
I guess my argument is that there is a decision that is being made for the end user who may not know that such a decision is being made, and furthermore may not be aware of the potential risks associated with such a decision. The reason I choose Arch for all my systems is because there are so very few decisions made for me.
Again, I do not mean to step on toes or presume to speak for the community (ALARM, RasPi, Arch. etc), but this seems to be a pretty big deviation from the Arch norms I've come to be acquainted with over the last five years of using it.
Whatever the outcome I do think that people should presently be made aware that by running the system with the default config setup that we are providing that they are operating the Pi in an accelerated clock state that is outside of the manufacturer's listed specification (700Mhz), with appropriate warnings of what that could possibly entail, and clear instructions on how to revert this change.