Rockbox General > Rockbox General Discussion

Latest Rockbox not working on Nano

<< < (31/34) > >>

AlexP:
We (I use we in inverted comma's mainly meaning I) would like as many people as possible to enjoy the project, but that doesn't mean compromising and using a fudge instead of a proper fix.  Rockbox is written by coders primarily for themselves.  If other people enjoy it brilliant, and we do our best to help people enjoy it (how many people spend time coding and fixing features they never use, or spend ages helping people on these boards?).  However we don't want to put if half-arsed fudges when we know it isn't the real fix.

You said you suggested a work around, and that is all it is.  "We" want to do it the right way, not hide it with a work around.  As I have said before, personally I am rather ambivalent on this particular issue as it is a rather major problem, not just an annoyance (I suspect I would feel more strongly if I had a Nano).  I can see both sides of the arguement, and really do sympathise.  However, that is the current position of the "project" (such as it has one).


--- Quote from: mitchelln on November 05, 2007, 12:03:11 PM ---So what about this config idea of mine? Possible or not possible at a technical level? ;)

--- End quote ---

I don't know.

Llorean:
It's possible, but it 100% defeats the purpose. If it defaults to the non-bug case, why don't we just comment out the buggy setting, and ALWAYS have it in the non-bug case, and not fudge around with a config setting? It's essentially the same thing.

If the problem is not bothering people, the priority goes from "Somebody really needs to fix this" to "Oh, it'll keep until someone gets around to it."

Technical skills are something learned, not something genetic. Saying "Most of us don't have the technical skills to make our own build" means the exact same thing as "This isn't important enough for us to take a half hour to learn to do what is necessary to make our own limited workaround, so we feel YOU should cover up the problem instead of us having to spend a wee bit of time learning something."

Making your own build is probably less complicated than half the tasks you do on your computer anyway, and that's assuming you're someone who's computer experience is limited to web browsing, Microsoft Word, and email checking. It may look complicated because they're things you've never done before, but once you've done it once it's apparent how simple the basic process is, and that's all you'll need.


As for a question of politics: It's not. It's entirely possible that a temporary fix will go in some day, but if that ever happens it makes it drastically more likely there never will be a permanent fix, or at least it will happen a long time away.

Bugs shouldn't be covered up in pre-release software. You're again making the assumption that you're a "user" and you can choose to call yourself that, but in reality you're a tester. You downloaded a testing version, and if you choose to treat it like a release version, we can't really stop you, and if you choose not to help with testing, feedback, and development, nobody can force you to do that. But how you choose to use the software doesn't magically mean that you have become the new target audience.

Yes, it'd be nice to have more people using it. But it'd be nice to have them using a properly working software, rather than an ever growing pile of hacks and workarounds where bugs haven't been and now can't be fixed the right way, as that results in even worse software in the end. So bugs should be visible, then fixed, rather than hacked away as quickly as possible and forgotten until your software is so patchwork that the interplay of hacks makes it nearly impossible to maintain.

mitchelln:
The thing is, this might be a physical rather than a software issue. You could very well be setting all the chip registers just fine. It could be though that there is an issue of the PCB out there that has a layout problem that causes timing faults. Nothing you then do in software will fix it. This is  a surprisingly common problem. In such cases the only way to proceed is to provide a work around. Otherwise nobody with that particular version of the PCB will ever get their device to work. The problem is you'll never get Apple to admit that there's a faulty version of the PCB out there. Who knows, their firmware might detect the PCB version and ramp the clock down slightly. Without cracking open loads of Nano's we'll never know.
So if this is the case and it is a hardware bug, what do you suggest? Do nothing?

I truly applaud your purist software ideals, but as a hardware engineer I know practicality sometimes is required in such cases. My suggestion seems simple and sensible to me.

GodEater:
Then take the time to learn how to supply your own workaround if that's what you want.

mitchelln:

--- Quote from: GodEater on November 06, 2007, 04:32:53 AM ---Then take the time to learn how to supply your own workaround if that's what you want.

--- End quote ---
Just trying to help all those poor Nano owners who can no longer run Rockbox. I am lucky enough to have the skill set to be able to code this, other mere mortals have not.
Now the question is, if I do provide this workaround, will it be accepted into the Rockbox code base?

Navigation

[0] Message Index

[#] Next page

[*] Previous page