if a lot of people ask for the same thing, maybe 500, than maybe they might actually upgrade the flash version

Andre, I have provided all the information that is needed, as far as I am concerned. I traced execution of MicroB and found that the Flash plugin basically goes into a tight loop making gettimeofday() syscall. If you have 2-3 Flash plugins shown on the same web page, their timing loops eat 100% of the CPU. It is a very well known bug. You can go to #maemo IRC channel and just ask people if they ever encountered it. Pretty much everybody will tell you that this problem occurred to them.

Now, you or Nokia people can provide any justification to ignore this bug. Mark it WONTFIX, perpetually ask for more data, delay until Harmattan, complain that "there are no votes", but none of your actions are going to make this problem disappear for the users. As far as I can see, this bug is still going to be present in Fremantle. Personally, I am not going to spend more of my time trying to prove to Nokia (or you) that this bug exists. I have come to understand that it is just going to be a waste of my time.

If you list their email address, I will also ask for an upgrade.

"I will try causing the problem again and restarting esd." - no update after this.

That's true. Though it's definitely not on my mind to delay - I'm also not happy with some of the Nokia decisions that I forward.

I didn't complain that there are no votes, I just didn't get the relation to the comment before. Thanks for clarifying - got it now.

This kind of stuff really puts faith in their product and makes me want to have their Maemo based cellphone in my pocket... yeah.

FIXED IN FREMANTLE! (drink)

HAHA!

I think that we can hope that Adobe's Open Screen Project gets pushed to all iterations of Maemo and that Nokia doesn't get in the way.

Well, you see, the funny thing is that the problem with the current Flash plugin for MicroB can be fixed without involving Adobe, by some creative wrapping of gettimeofday() (similar fixes to RedHat can be found by Google) and/or controlling the execution time of each Flash instance. This would require Nokia to admit the problem first though. As we all know by now, this is usually an unsurmountable obstacle.

You know, I have read a lot, awful lot of replies to feature or bug requests, and while it still would be nice with an upgrade, I have to say, that was a rather nice one.

It was polite, which is common but not always so. It was honest, in that it admitted that it had to forward it to someone who had a clue to what was asked. And it was positive, using many words and obviously wasn't based on a standard reply.

I bet someone used ten minutes, a quarter of an hour on your request.

Having worked in an ISP tech support phone center in an engineering capacity (not just a rep answering the phone, but actually figuring out and fixing issues), and knowing how email is commonly handled by those departments...

I sincerely doubt that the responding support person spent more than 30 seconds to read the email, respond to it with that canned response and to pass it into a ticketing system where it will sit in a queue for an engineer to look over it and research it, make a statistical note of it, reject it, or resolve it. That's about all you can ascertain from the way it looks.

Beyond that, who knows? Once it's in a ticketing system, it's all up to the system. My guess is that the ticketing system will send out "ticklers" to get someone's attention to work on it within a set metric for that customer's SLA (Service Level Agreement), as is typical in most companies. In this case, it's probably a very liberal SLA since there's no contract agreement involved. He's just some guy sending off an email about support for a product he bought--not someone that bought a contract for hardware support in a business or something.

Anyway.. that's my guess and how I interpreted the email.