Active Topics
-
Error after installing Leste on sdcard (17)
to Maemo 7 / Leste by Arno_11 - 3 hrs, 49 mins ago -
Maemo 20th Anniversary (4)
to Brainstorm by teroyk - 1 day, 9 hrs ago -
Nokia Booklet 3G (RX-75) Drivers (64)
to Alternatives by teroyk - 1 day, 9 hrs ago -
Porting apps to Leste (46)
to Maemo 7 / Leste by teroyk - 3 days, 12 hrs ago - more...
 |
|
2009-10-18
, 19:06
|
|
Posts: 4,708 |
Thanked: 4,649 times |
Joined on Oct 2007
@ Bulgaria
|
#72
|
Originally Posted by VDVsx
Actually I had my prototype exchanged when Daniel discovered it had older bootloader and can't be upgraded to 41-10 at least at the spot.
I think nobody with pre-production devices asked for a new one at the summit AFAIK, that would be very greedy attitude IMHO.
__________________
Technically, there are three determinate states the cat could be in: Alive, Dead, and Bloody Furious.
Technically, there are three determinate states the cat could be in: Alive, Dead, and Bloody Furious.
|
|
2009-10-19
, 00:20
|
|
Posts: 452 |
Thanked: 522 times |
Joined on Nov 2007
|
#73
|
Originally Posted by ddalex
I never said it was easy. ;-) I said it was work-able without a device. Trust me I am well aware of how "very" hard it can be trying to debug something remotely w/o having a device. (I've been doing development for over 20 years) -- And to top that off my own learning style (and my ability to debug) is completely hands on/physical. My wife hates when I "show" her how to fix a problem because I literally have to take control of her machine -- I can't verbally walk her through it. I am a very hands on type of person. But the point is yes the device would be very nice, and it would allow certain tests to be easily performed. But most things can be done in the scratchbox and tested their. You can get it running; then you can ask the community to vet the project and make sure their are no other "oddities" that show up on the real device. If you are unaware -- you need to know the Scratchbox runs the same versions of the software the device does. When I pull a library from extras in the scratchbox; it is the same library a n900 would pull. So they are a lot closer than I think you think they are.
Nathan, I think that developers absolutely need devices to work with, and I'm saying this as one developer professionally working with mobile devices for more than three years ! Real devices do NOT behave as tested on SDK, apart for the most simple programs.
Nathan
 |
|
2009-10-19
, 02:50
|
|
Posts: 3,397 |
Thanked: 1,212 times |
Joined on Jul 2008
@ Netherlands
|
#74
|
Originally Posted by Nathan
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:
I never said it was easy. ;-) I said it was work-able without a device. Trust me I am well aware of how "very" hard it can be trying to debug something remotely w/o having a device. (I've been doing development for over 20 years) -- And to top that off my own learning style (and my ability to debug) is completely hands on/physical. My wife hates when I "show" her how to fix a problem because I literally have to take control of her machine -- I can't verbally walk her through it. I am a very hands on type of person. But the point is yes the device would be very nice, and it would allow certain tests to be easily performed. But most things can be done in the scratchbox and tested their. You can get it running; then you can ask the community to vet the project and make sure their are no other "oddities" that show up on the real device. If you are unaware -- you need to know the Scratchbox runs the same versions of the software the device does. When I pull a library from extras in the scratchbox; it is the same library a n900 would pull. So they are a lot closer than I think you think they are.
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?!
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.
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.
__________________
Goosfraba! All text written by allnameswereout is public domain unless stated otherwise. Thank you for sharing your output!
Goosfraba! All text written by allnameswereout is public domain unless stated otherwise. Thank you for sharing your output!
 |
|
2009-10-19
, 03:06
|
|
Posts: 3,105 |
Thanked: 11,088 times |
Joined on Jul 2007
@ Mountain View (CA, USA)
|
#75
|
To recap, my counter proposal to "Proposal: To include some Core Members with low Karma in Dev Program" is "To create a waiting list of community projects to get a loaned device when available".
It would be more practical to discuss on practical priorities (what goes first, e.g. MMS or Java?) rather than theoretical karma weaknesses.
You can still discuss the latter but please use another thread for that. Even if you are convincing any changes on karma calculations won't affect directly the N900 program anymore.
It would be more practical to discuss on practical priorities (what goes first, e.g. MMS or Java?) rather than theoretical karma weaknesses.
You can still discuss the latter but please use another thread for that. Even if you are convincing any changes on karma calculations won't affect directly the N900 program anymore.
| The Following User Says Thank You to qgil For This Useful Post: | ||
 |
|
2009-10-19
, 05:48
|
|
Posts: 381 |
Thanked: 847 times |
Joined on Jan 2007
@ Helsinki
|
#76
|
Originally Posted by andrewfblack
I just got an idea: how about making it possible to donate some of your karma to others? If you are an active contributing member of the community you're likely to have a lot of it, and probably can identify promising new community members who'd deserve to have more.
The problem has come up that some Core Members of Maemo Community are left out of dev discount program because they have low karma. For one reason or another thy have either are newer members or don't make use of maemo.org services.
That way we could still utilize karma for things like developer device program and travel sponsorship eligibility, but make them also accessible to new members of our community.
|
|
2009-10-19
, 06:18
|
|
Posts: 452 |
Thanked: 522 times |
Joined on Nov 2007
|
#77
|
Originally Posted by allnameswereout
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)
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..and that is not true.you developers do not need a device to get things going at all!
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?!
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.
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.
Nathan.
|
|
2009-10-19
, 06:19
|
|
Posts: 452 |
Thanked: 522 times |
Joined on Nov 2007
|
#78
|
Originally Posted by qgil
Off of my list (any any other list) do we have a list of those who actually got devices. It might make it easier to see which projects need to be put on the waiting list.
To recap, my counter proposal to "Proposal: To include some Core Members with low Karma in Dev Program" is "To create a waiting list of community projects to get a loaned device when available".
Nathan.
 |
|
2009-10-19
, 07:04
|
|
Posts: 3,159 |
Thanked: 2,023 times |
Joined on Feb 2008
@ Finland
|
#79
|
it is impossible to measure accurately everybodys work for the community. that's why whe should only improve the calculation formulas for karma if karma is used to measure one's activity and possible rewards are given based to karma.
There will always somebody who's left out. But if majority have justified discounts, I'd say the system works very well.
Of course if something exceptional (must be really awesome) appears and author doesn't get reward that he should, it should be like nobel prize of peace, one per year or something like that.
There will always somebody who's left out. But if majority have justified discounts, I'd say the system works very well.
Of course if something exceptional (must be really awesome) appears and author doesn't get reward that he should, it should be like nobel prize of peace, one per year or something like that.
| The Following User Says Thank You to ossipena For This Useful Post: | ||
 |
|
2009-10-19
, 10:15
|
|
Posts: 2,535 |
Thanked: 6,681 times |
Joined on Mar 2008
@ UK
|
#80
|
Originally Posted by bergie
This is what I imagined the thumbs-up/down on a profile would do. If a person with lots of karma gives you a thumbs-up, you get more karma than if someone with little karma gives you a thumbs-up. However, lots of low level users giving you a thumbs-up would equate with a single mid-level person.
I just got an idea: how about making it possible to donate some of your karma to others?
However, I don't think it was implemented, and the profile thumbs up/down were removed.
[Which reminds me, if there's more midgard work to be done, karma calculations need a re-architect so that everything isn't scanned every update, so that a) there won't be sudden shifts if one source is down; b) updates are more timely and c) karma decay can be implemented]
__________________
Andrew Flegg -- mailto:andrew@bleb.org | http://www.bleb.org
Andrew Flegg -- mailto:andrew@bleb.org | http://www.bleb.org
| The Following User Says Thank You to Jaffa For This Useful Post: | ||
I'm proposing on the list iancumihai, developer of myTube, very appreciated piece of software.