View Single Post
Posts: 452 | Thanked: 522 times | Joined on Nov 2007
#77
Originally Posted by allnameswereout View Post
I agree the SDK can get you far but it isn't a complete replacement and it probably will never be. You stated in earlier post:
Originally Posted by nathan
you developers do not need a device to get things going at all!
..and that is not true.

The Scratchbox+SDK platform does not use the same architecture the target platform uses. It either runs x86-32 software, or uses QEMU to emulate ARMEL. QEMU contains bugs. For example, see cmake thread, or fact it doesn't run GUI, and sometimes my ARMEL environment is screwed and I have no clue what happened. So architecture specific problems are concern. It is also difficult to test usability without touchscreen and finger/stylus using mouse instead. I wonder how Nokia deals with this internally?!
Trust me I am well aware of a lot of the issues with the scratchbox (both 1 and 2) -- in fact if you look at the cmake thread (that you referenced) you will see I also reported the exact same issue one or two posts later -- I also followed up and put a bug in to the bugtracker and posted to the dev list and got the ball rolling to get the issue fixed once it was a confirmed bug and we knew where to look/fix it. (In fact, had Nokia not fixed it as fast as they had, I had an alternative method that I was going to deploy to the repositories to work around the issue)

However, in the meantime even with that "blocking" bug, I was still able to test everything on the x86 side and get several other issues resolved while I waited (1 day) for Nokia to get the issue fixed on the armel side of things. I couldn't ask for better turn around on that fix!

Which brings me to Scratchbox not emulating certain hardware features the real device has. For example, I've seen posts about using GPS and Bluetooth inside the SDK. The former is easy to solve (gpsd or gpsfake running on host platform port 2947 reachable from Scratchbox) but the latter is a bit harder to solve. Another example, and that is my main reason, is that it doesn't emulate performance of Nokia N900 rendering tools such as htop, iotop, powertop, latencytop, nearly useless.
Yes, their are some things it won't emulate or handle properly. But again the vast majority of things it is usable for. If you are doing a project that requires a live camera feed -- yes, you need the hardware. I stated for most things the sdk is fine.


Although the number of situations these problems arise is up for debate, karma reflects past effort not present or future effort, and I'm not saying above must be fixed (is difficult), it is IMO important to take note.
If you go towards the TOP of this thread you will see that I am a very strong believer in developers (I complained and lobbied hard in a couple threads over possible cracks -- and I assume based on some of the responses I annoyed some people.). But based on their response I do firmly believe Quim, Nokia, and the CC is doing the best job they can do with the information and resources they have. I provided a list of potential cracks where developers may have fallen through; and they didn't just brush it off -- they took it seriously. I'm not saying they (Quim, Nokia, and the CC) won't make mistakes -- but they do appear to be attempting to look out for the best interest of the community and that is really all we can ask for! (Again, way to go Quim, Nokia and CC!)

Nathan.