The Android Lag Fix That Really Wasn't 226
jfruh writes "When Android was first introduced, it got much of its buzz in the open source community, and despite it being a mobile juggernaut backed by huge companies, it remains an open source project that anyone can submit code to. Thus, when a community patch that claimed to reduce the lag that still plagues the platform was created, it rocketed around various community code sites and was widely praised. The only problem: it didn't actually speed Android up."
Re:You mean that the placebo effect still works? (Score:5, Insightful)
The surprising thing, in both this Android case and the assorted car-widgets, is not that the placebo effect works; but that the "If it was that easy, why didn't it come from the factory that way" argument hasn't held more sway.
In the case of the 'vortex' device you link to, the argument is essentially that ~$1 worth of stamped metal could markedly improve the performance and fuel economy of most vehicles without other notable modifications. Short of a full-scale Petroleum-industrial-complex coverup, why aren't these things being bolted on at the factory?
In the Android case, it's not like entropy related issues are news to linux users or hardware makers. Devices that do lots of crypto(ie. network gear designed to support a lot of VPN users, http load balancers designed to serve a lot of SSL sessions, etc.) are frequently provided with dedicated hardware RNGs precisely to prevent performance issues on entropy depletion. VIA's more recent CPUs come with an on-die hardware RNG, and you can buy assorted RNGs for various expansion busses if your applications require it.
The issue isn't so much that you can entropy-starve a system and cause it to respond badly; but that(against a background of people already knowing that) Google went and released an OS that is somehow radically more demanding on /dev/random than most linux variants and didn't even notice? That would be a bit of a surprise.
Beware of more of this stuff on XDA (Score:5, Insightful)
Well yeah... (Score:2, Insightful)
Because you can't fix stupid.
Re:Beware of more of this stuff on XDA (Score:3, Insightful)
The funny thing is those dweebs spill out onto the general internet and tell everyone they need to hack their phones.
Then you read a 45 page thread only to find that their wicked sweet ROMz don't support the camera and give the phone 30 minutes battery life. Gee thanks, Melvin.
Re:Does it matter? (Score:2, Insightful)
If you've used an apple device then an android device, you realize how slow android is. It's not terrible, but it greatly diminishes the user experience because the screen isn't glued to your finger.
Comment removed (Score:5, Insightful)
Re:Does it matter? (Score:5, Insightful)
You can't have 0 latency audio drivers. But the latency can vary from system to system due to design decisions.
The main source of latency in audio drivers is related on how many audio samples are generated for each call to the interrupt handler (buffer size).
Bigger buffer sizes help avoid gaps in audio due to interrupt jitter. They also reduce the CPU load and energy usage which are very important in mobile devices.
Driver infrastructer for very small buffer sizes need to be designed very carfully to work reliably. So there are many reasons why android developers decided not
to use very small buffer. BUT of course for any kind of interactive audio low latency is crucial.
Re:java is shit (Score:4, Insightful)
When a user clicks (touches, slides, speaks, whatever) an object in the interface, the expectation is that the response will be immediate. Leaving aside communications delays, which users largely understand they have to live with, there is nowadays no excuse whatsoever for the device failing to respond instantly, even if only to provide feedback that acknowledges the interaction (for example when it involves an operation that is known to take measurable time such as opening an image file).
But the OS's own processes are regarded as sacrosanct, so the user interface just has to wait until they condescend to allow the user a few of their precious cycles. This happens on all end-user systems running multiple processes (leave IBM mainframes out of this :-) — just look at the time it takes to get a response from the Unity Dash, or the Gnome menu button, or the Windows Start button (or whatever it's called this week), or the Mac menu button...the first time you click it. It sits there loading its menus. Finally it lets you see them. You run your application, and for a short while, another click on the dash/start/menu will get a fairly swift response. Leave it a little longer, and it's been swapped out and takes another age to reload.
Developers, achitects, engineers, and programmers need to grasp the fact that their background processes must take a back seat when the user wants to do something. Their reply, quite naturally, is that their background processes are vital, essential, cannot be delayed or interrupted, etc etc. And quite right, some of them are. But it's their job to see to it that they are written and scheduled in such a way as not to interfere with the interface. Anything else is a design failure.
Re:Does it matter? (Score:4, Insightful)
Can I root for no one to win, but for it to remain a stalemate with several competitors?
Or do we all need to wave the flag for one uncaring corporate juggernaut or another?
(Also, do we have to present credentials like this with every opinion we post? Would the validity of your opinion change if you were an Apple fan? Are we reddit?)
Re:java is shit (Score:4, Insightful)
You do understand, don't you, that the reason the user interface has to wait isn't because developers think our processes are more important than the users.... but because the user interface DEPENDS ON THOSE PROCESSES TO BE ABLE TO DISPLAY!
Car analogy: You're complaining the the engine management computer insists on doing its fuel map calculations before responding to the throttle.
Re:Does it matter? (Score:5, Insightful)
I have nothing against Apple perse, but I have serious issues with the closed nature of their iOS devices and especially how I don't have the ability to control what gets transfered on or off the device. Everything has to go through iTunes or some cloud solution.
Android has no such restricting policies, that's why I'd like to see it 'win'.
Comment removed (Score:2, Insightful)
Re:Open Source (Score:2, Insightful)
since when does having a non mainline spin off count as being "open to user additions"?
There's no requirement for an open source project to be open to "user additions".
When was the last time you added something to the Linux kernel? Maybe you did, but that process is tightly controlled by the kernel maintainers.
Same thing for Firefox.
You are free to fork Android, like CM did, and make your additions there. Or fork CM.
I'm not saying Android couldn't be more open. But it's understandable that Google tries to keep control so they won't get sabotaged by Apple, Microsoft and others.