* The.apk file is saved on the external storage, but all private user data, databases, optimized.dex files, and extracted native code are saved on the internal device memory.
* The unique container in which your application is stored is encrypted with a randomly generated key that can be decrypted only by the device that originally installed it. Thus, an application installed on an SD card works for only one device.
* Only new releases of apps can do this - they need to add "android:installLocation=preferExternal" to their manifest.
News/documentaries might contain THE TRUTH(tm), which some governments may try to suppress and jail you if they knew you watched it.
If you can go to jail for watching it, you sure as hell can't legally buy it. You might as well just turn yourself in. So you need an illegal copy, and you need that transfer kept private.
So, in that instance, Tor-torrenting is morally OK.
But, in most cases, people are not Tor-torrenting THE TRUTH(tm), just hollywood movies, thinking Tor will stop them getting caught - their selfish behaviour pisses off both the movie moguls and privacy advocates alike.
At night, I'm in bed with my girlfriend and I'm pretty tired. She cozies up to me and rubs against me in a way that says "let's have sex". I don't really want sex because I'm tired, and I say "no honey, I'm tired", but she pulls a sad, coquettish face, so I change my mind and we have sex.
Have I just been raped?
According to the GP, yes I have, hundreds of times by my girlfriend. If only I was a woman, then emancipatory feminism would be there to rescue me!
"Lowering the bar" for rape happens whenever someone claims their uncoerced choice to have sex was "rape". They may regret their choices, but it's not rape; rape victims don't get a choice.
Publishers were lured away from the Amiga because Sega and Nintendo offered them a higher markup. Sega/Nintendo collectively set higher prices than was standard for Amiga/PC software (£25 vs £30-£50 per game). Sega/Nintendo splashed out on advertising for their platform - Sega/Nintendo grew a larger customer base willing to pay more money for games. Commodore weren't nearly as effective.
Then Sony brought out the super-flashy Playstation, customers ran to it and Sega/Nintendo's 16 bit platforms died off far quicker than anyone imagined.
Seriously - it wasn't about piracy then, and it's not about piracy now. It's about how much money you make regardless of the quality of software you release. It's about managing risk. Every big publisher would prefer if the public could be reliably managed - "if I put $X into development and $Y into marketing, I will get at least $X+$Y+$Z back in sales."
At the moment they're failing, and trying to get a better $Z by reducing $X and increasing $Y by spending $Y on legislators rather than the ungrateful masses.
As time goes on, everything gets faster and everything grows in storage capacity - but they all stay the same relative to each other on the list. Anybody who tells you otherwise is selling you something.
"Until I can actually BUY an e-book, not rent them for life, the entire market will remain irrelevant to me."
You're really concerned what's going to happen to your ebooks when you're dead? Taking corporate paranoia to the afterlife is a little extreme, no?
I think the key word here is RENT, i.e. "Want to keep having those books? Then you have to pay me money every single month. You'd better keep them in good condition too, because if you stop paying, I'm going to take them back. My books, baby, not yours."
I don't know about you, but I prefer it when I only pay ONCE for a book, and can then do what I want with it, rather than RENT it.
Re:How about integers instead of floating point?
on
Quake 3 For Android
·
· Score: 1
Because integers don't hold enough precision to be useful in modern graphics.
Believe it or not, they are currently useful for simply shaded/textured objects on phone-sized screens. You can use fixed point 16:16 numbers for that.
But they start being a hindrance after that because of the limited precision, and the amount of work you have to do to bring values back in line when doing multiplies or divides. You're generally wasting your time if the device you're targeting has a hardware FPU.
You can see for yourself what it looks like when you try and use fixed point values for 3D calculations. Get a Playstation (i.e. Playstation 1) emulator and run a game at 1024x768 or higher. You'll now see all the vertexes pop whenever you move about, even though they're meant to be static.
It's because the PS1 hardware used fixed point values throughout, and while the programmers were careful to make sure they wouldn't pop 1 pixel on a 320x256 screen, they didn't check what happened when you had a larger screen size.
* A large car with trailer ended up on the UK's east coast mainline * A passenger train hit it at 120mph, causing a derailment * The passenger train then hit an oncoming freight train at a combined speed of 184mph * 10 people died, 82 suffered injuries * It turned out the car driver was in no fit state to drive - how about that?
They can spell properly. Kids choose to spell like idiots because it makes them different from their parents.
It's the same reason they listen to music that's "unlistenable noise" if you ask their parents. In fact, a friend of mine complained his kids were into noisecore. Ha! He grew up being into heavy metal, which annoyed his parents who preferred the Beatles.
Texting doesn't make you a worse speller, because you have to know how to spell something properly before you can make it shorter for text-speak. Ask a linguistics professor about it sometime.
It's on the way - Ymacs is an in-browser editor that's designed to look a lot like like Emacs, which inspired elisp.js: elisp interpreter for Javascript - so hopefully we can run Emacs in the browser, at some point in the future.
Thing is, we have already been there with J2ME, and later with.NET CE. J2ME started as purely interpreted solution, but pretty much all modern smartphones which support it do JIT on hot paths, and they do it surprisingly well.
Well, maybe Dalvik will get JIT in the future. But right now, they solved IMHO the ultimate Java bugs - slow to start and using too much memory for what you get.
If Dalvik bytecode has instructions that use direct vtable indices and field byte offsets, and you say that they're not verified on load:
There's still a verifier in the Dalvik loader, but it skips verifications that are no longer relevant after converting JVM bytecode to Dalvik bytecode. Short answer: you'll still have all your offsets and calls checked for correctness. See here for details.
For virtual method calls, replace the method index with a vtable index.
For instance field get/put, replace the field index with a byte offset. Also, merge the boolean / byte / char / short variants into a single 32-bit form (less code in the interpreter means more room in the CPU I-cache).
Replace a handful of high-volume calls, like String.length(), with "inline" replacements. This skips the usual method call overhead, directly switching from the interpreter to a native implementation.
Prune empty methods. The simplest example is Object.<init>, which does nothing, but must be called whenever any object is allocated. The instruction is replaced with a new version that acts as a no-op unless a debugger is attached.
Append pre-computed data. For example, the VM wants to have a hash table for lookups on class name. Instead of computing this when the DEX file is loaded, we can compute it now, saving heap space and computation time in every VM where the DEX is loaded.
The reason that a compliant JVM can't do this is because it's sold on being a compliant JVM: it has to be able to load class files and jars, from any source, on demand. Dalvik can't do that, it has to have classes converted to.apk/.dex files first. That takes a few seconds on a desktop computer, and would absolutely rape a phone's battery if it had to do that regularly.
I'm not saying that Dalvik is faster than JIT. What I'm saying is that Dalvik is faster than a compliant JVM that doesn't run JIT, and IMHO the cost of doing JIT outweighs the benefits when running on a smartphone.
Instead of doing a whole pile of work just to start an app (reading bytecodes, verifying, converting it to native code), Dalvik can launch apps immediately. That's an astonishing thing for Java, and utterly necessary if you're going to write a full complement of apps and services for a smartphone that can start and stop at any time.
Yes, Android uses a converter that changes java bytecode to a different beast entirely, and performs a large number of global optimisations that decrease size and increase speed - ones that a compliant Java VM isn't allowed to do. So it ends up going about the same speed as JIT, but only needs the power a small phone supplies.
As for garbage collection - Android performs about as well as a C/C++ program filled with malloc()/free() or new/delete. C/C++ games programmers could do that, but they choose not to because they know that avoiding malloc/free/new/delete gives them a performance boost. Android has exactly the same tradeoff - avoid object creation in your code! Create what you need at the start of a level and then don't free it until the end of the level. You'll get good performance. Android has an entire section on how to get good performance, just like C/C++ programmers have plenty of strategies for getting good performance out of any platform.
Twenty years ago, in Europe, the PC was a dull machine that you only ever ran business applications on. Maybe a flight simulator if you're lucky. The Mac was an obscure machine for desktop publishing. If you wanted gaming, you bought an Amiga or Atari ST. Now look where we are.
You're pointing at the entrenched PC games market, where everyone has hugely invested in writing in C++ for the Microsoft Direct3D API.
By comparison, smartphones are relatively new and the investment in Apple's iPhone API is tiny compared to the gigantic Windows-only ecosystem (Windows-only middleware, Windows-only tools, Windows-only 3D programmers, etc.) that keeps gaming chained to PCs.
So, given Android programming is much easier (far more programmers know Java than Objective C), and there's not yet a huge iPhone-only ecosystem in place, switching is still relatively painless. All it would take is one damn good phone running Android to topple Apple off its perch.
Android's development kit re-encodes the standard Java class files for the Dalvik virtual machine which makes them smaller and faster. The standard Java VM has stack based parameter passing, but Dalvik's format recodes it to use registers for parameter passing wherever possible. It also makes constants much smaller - if you're only using numbers from 0-255, why store them in 64 bits?
As for the standard class library, Android implements a custom subset of the Java system classes that is smaller than Standard Edition but larger than Micro Edition, and doesn't either editions' frameworks for application development but its own custom one.
Dalvik is also ready to fire up a new Java VM at any moment, because it has a special VM that's pre-initialised and fork()s on demand - so you get an instant new Java VM instead of a several-seconds-later Java VM like you would on a regular computer.
So Android is really its own platform, which happens to use Java as the main way of doing things, and it does things really quickly, efficiently and safely. And most of your existing Java code will work provided you write an Android user interface for it.
How about you cram your rant-supporting rant up your own ass?
You've got someone going off on a rant about how evil "pirates" they are. But it could just be a baseless rant - how do we tell?
We use facts to tell us if some guy's rant is justified or not. So his rant has some unsubstantiated "facts":
"according to a recent UK study, 60% feel they are entitled to steal anything IP related they want"
"even the largest of Android developers are making, at most, 1/8th what they should be making"
So, whether this guy has a point or whether he's talking utter bullshit depends on these claims being correct.
It's not up to us to go verify some rant on Slashdot. It's up to the ranter to show he's right.
Let's examine a related "fact" from The Sun newspaper:
More than seven million Brits use illegal downloading sites that cost the economy billions of pounds, Government advisors said today. Researchers found more than a million people using a download site in ONE day and estimated that in a year they would use £120bn worth of material.
There are people on both sides of the "piracy" argument with specious reasoning, dubious statistics and unstated biases. Don't let them argue their pet positions. Challenge them each and every time. That's the only way to take the bluster out of their rants.
Slashdot Mirror
According to http://developer.android.com/guide/appendix/install-location.html
* The .apk file is saved on the external storage, but all private user data, databases, optimized .dex files, and extracted native code are saved on the internal device memory.
* The unique container in which your application is stored is encrypted with a randomly generated key that can be decrypted only by the device that originally installed it. Thus, an application installed on an SD card works for only one device.
* Only new releases of apps can do this - they need to add "android:installLocation=preferExternal" to their manifest.
News/documentaries might contain THE TRUTH(tm), which some governments may try to suppress and jail you if they knew you watched it.
If you can go to jail for watching it, you sure as hell can't legally buy it. You might as well just turn yourself in. So you need an illegal copy, and you need that transfer kept private.
So, in that instance, Tor-torrenting is morally OK.
But, in most cases, people are not Tor-torrenting THE TRUTH(tm), just hollywood movies, thinking Tor will stop them getting caught - their selfish behaviour pisses off both the movie moguls and privacy advocates alike.
Here's an Android app that provides two-way sync between your Android Calendar and any CalDAV server.
It was deliberate misinformation by "analysts" within the US government, not the government as a whole. See http://en.wikipedia.org/wiki/Team_B
To put it bluntly, no.
At night, I'm in bed with my girlfriend and I'm pretty tired. She cozies up to me and rubs against me in a way that says "let's have sex". I don't really want sex because I'm tired, and I say "no honey, I'm tired", but she pulls a sad, coquettish face, so I change my mind and we have sex.
Have I just been raped?
According to the GP, yes I have, hundreds of times by my girlfriend. If only I was a woman, then emancipatory feminism would be there to rescue me!
"Lowering the bar" for rape happens whenever someone claims their uncoerced choice to have sex was "rape". They may regret their choices, but it's not rape; rape victims don't get a choice.
Publishers don't make games - developers do.
Publishers were lured away from the Amiga because Sega and Nintendo offered them a higher markup. Sega/Nintendo collectively set higher prices than was standard for Amiga/PC software (£25 vs £30-£50 per game). Sega/Nintendo splashed out on advertising for their platform - Sega/Nintendo grew a larger customer base willing to pay more money for games. Commodore weren't nearly as effective.
http://dspace.dial.pipex.com/ap2/bad/summit.html
Then Sony brought out the super-flashy Playstation, customers ran to it and Sega/Nintendo's 16 bit platforms died off far quicker than anyone imagined.
Seriously - it wasn't about piracy then, and it's not about piracy now. It's about how much money you make regardless of the quality of software you release. It's about managing risk. Every big publisher would prefer if the public could be reliably managed - "if I put $X into development and $Y into marketing, I will get at least $X+$Y+$Z back in sales."
At the moment they're failing, and trying to get a better $Z by reducing $X and increasing $Y by spending $Y on legislators rather than the ungrateful masses.
As TFA says, For $125 you get a 40GB SSD. Today on Newegg I can pay 110 for a 1500GB hard disk drive - that's about 40 times more storage, for LESS!
Unless SSD suddenly becomes 40 times cheaper, it's unlikely to wipe out regular HDDs. And it has to cope with the fact HDDs get better every year too.
There has always been a sliding scale in computing with "faster, less storage" on one end and "slower, more storage" on the other.
Cache RAM -- RAM -- Flash RAM -- SSD -- HDDs -- tape.
As time goes on, everything gets faster and everything grows in storage capacity - but they all stay the same relative to each other on the list. Anybody who tells you otherwise is selling you something.
"Until I can actually BUY an e-book, not rent them for life, the entire market will remain irrelevant to me."
You're really concerned what's going to happen to your ebooks when you're dead? Taking corporate paranoia to the afterlife is a little extreme, no?
I think the key word here is RENT, i.e. "Want to keep having those books? Then you have to pay me money every single month. You'd better keep them in good condition too, because if you stop paying, I'm going to take them back. My books, baby, not yours."
I don't know about you, but I prefer it when I only pay ONCE for a book, and can then do what I want with it, rather than RENT it.
...for these modern times.
Because integers don't hold enough precision to be useful in modern graphics.
Believe it or not, they are currently useful for simply shaded/textured objects on phone-sized screens. You can use fixed point 16:16 numbers for that.
But they start being a hindrance after that because of the limited precision, and the amount of work you have to do to bring values back in line when doing multiplies or divides. You're generally wasting your time if the device you're targeting has a hardware FPU.
You can see for yourself what it looks like when you try and use fixed point values for 3D calculations. Get a Playstation (i.e. Playstation 1) emulator and run a game at 1024x768 or higher. You'll now see all the vertexes pop whenever you move about, even though they're meant to be static.
It's because the PS1 hardware used fixed point values throughout, and while the programmers were careful to make sure they wouldn't pop 1 pixel on a 320x256 screen, they didn't check what happened when you had a larger screen size.
Freight trains are seldom derailed by collisions. [...] Never saw one derailed. Maybe a passenger train might derail [...]
You should read http://en.wikipedia.org/wiki/Selby_rail_crash
* A large car with trailer ended up on the UK's east coast mainline
* A passenger train hit it at 120mph, causing a derailment
* The passenger train then hit an oncoming freight train at a combined speed of 184mph
* 10 people died, 82 suffered injuries
* It turned out the car driver was in no fit state to drive - how about that?
They can spell properly. Kids choose to spell like idiots because it makes them different from their parents.
It's the same reason they listen to music that's "unlistenable noise" if you ask their parents. In fact, a friend of mine complained his kids were into noisecore. Ha! He grew up being into heavy metal, which annoyed his parents who preferred the Beatles.
Texting doesn't make you a worse speller, because you have to know how to spell something properly before you can make it shorter for text-speak. Ask a linguistics professor about it sometime.
If he was at the escape window, he could have just opened it in flight! No need for the risk of dud bombs, and he would have achieved the same effect.
The usual cheating is to pretend to "compress" the data, but actually hide it some other place on the machine.
So you get a smaller filesize, and it decompresses alright too.
But copy the "compressed" file to another machine without copying the hidden data and it "fails" to decompress.
It's on the way - Ymacs is an in-browser editor that's designed to look a lot like like Emacs, which inspired elisp.js: elisp interpreter for Javascript - so hopefully we can run Emacs in the browser, at some point in the future.
Thing is, we have already been there with J2ME, and later with .NET CE. J2ME started as purely interpreted solution, but pretty much all modern smartphones which support it do JIT on hot paths, and they do it surprisingly well.
Well, maybe Dalvik will get JIT in the future. But right now, they solved IMHO the ultimate Java bugs - slow to start and using too much memory for what you get.
If Dalvik bytecode has instructions that use direct vtable indices and field byte offsets, and you say that they're not verified on load:
There's still a verifier in the Dalvik loader, but it skips verifications that are no longer relevant after converting JVM bytecode to Dalvik bytecode. Short answer: you'll still have all your offsets and calls checked for correctness. See here for details.
To be fair, it's a professional journalist's blog post.
Sure: http://www.netmite.com/android/mydroid/dalvik/docs/dexopt.html
The reason that a compliant JVM can't do this is because it's sold on being a compliant JVM: it has to be able to load class files and jars, from any source, on demand. Dalvik can't do that, it has to have classes converted to .apk/.dex files first. That takes a few seconds on a desktop computer, and would absolutely rape a phone's battery if it had to do that regularly.
I'm not saying that Dalvik is faster than JIT. What I'm saying is that Dalvik is faster than a compliant JVM that doesn't run JIT, and IMHO the cost of doing JIT outweighs the benefits when running on a smartphone.
Instead of doing a whole pile of work just to start an app (reading bytecodes, verifying, converting it to native code), Dalvik can launch apps immediately. That's an astonishing thing for Java, and utterly necessary if you're going to write a full complement of apps and services for a smartphone that can start and stop at any time.
Yes, Android uses a converter that changes java bytecode to a different beast entirely, and performs a large number of global optimisations that decrease size and increase speed - ones that a compliant Java VM isn't allowed to do. So it ends up going about the same speed as JIT, but only needs the power a small phone supplies.
As for garbage collection - Android performs about as well as a C/C++ program filled with malloc()/free() or new/delete. C/C++ games programmers could do that, but they choose not to because they know that avoiding malloc/free/new/delete gives them a performance boost. Android has exactly the same tradeoff - avoid object creation in your code! Create what you need at the start of a level and then don't free it until the end of the level. You'll get good performance. Android has an entire section on how to get good performance, just like C/C++ programmers have plenty of strategies for getting good performance out of any platform.
I would definitely include "media hype" as part of any potential iPhone-toppler, not just technical merits.
But, if Android gives you an OS for nothing, you should have plenty left over in your marketing budget for media hype.
Twenty years ago, in Europe, the PC was a dull machine that you only ever ran business applications on. Maybe a flight simulator if you're lucky. The Mac was an obscure machine for desktop publishing. If you wanted gaming, you bought an Amiga or Atari ST. Now look where we are.
You're pointing at the entrenched PC games market, where everyone has hugely invested in writing in C++ for the Microsoft Direct3D API.
By comparison, smartphones are relatively new and the investment in Apple's iPhone API is tiny compared to the gigantic Windows-only ecosystem (Windows-only middleware, Windows-only tools, Windows-only 3D programmers, etc.) that keeps gaming chained to PCs.
So, given Android programming is much easier (far more programmers know Java than Objective C), and there's not yet a huge iPhone-only ecosystem in place, switching is still relatively painless. All it would take is one damn good phone running Android to topple Apple off its perch.
Android apps are all pretty much Java-only.
Android's development kit re-encodes the standard Java class files for the Dalvik virtual machine which makes them smaller and faster. The standard Java VM has stack based parameter passing, but Dalvik's format recodes it to use registers for parameter passing wherever possible. It also makes constants much smaller - if you're only using numbers from 0-255, why store them in 64 bits?
As for the standard class library, Android implements a custom subset of the Java system classes that is smaller than Standard Edition but larger than Micro Edition, and doesn't either editions' frameworks for application development but its own custom one.
Dalvik is also ready to fire up a new Java VM at any moment, because it has a special VM that's pre-initialised and fork()s on demand - so you get an instant new Java VM instead of a several-seconds-later Java VM like you would on a regular computer.
So Android is really its own platform, which happens to use Java as the main way of doing things, and it does things really quickly, efficiently and safely. And most of your existing Java code will work provided you write an Android user interface for it.
Like this guy?
You accidentally a whole customs agent?
How about you cram your rant-supporting rant up your own ass?
You've got someone going off on a rant about how evil "pirates" they are. But it could just be a baseless rant - how do we tell?
We use facts to tell us if some guy's rant is justified or not. So his rant has some unsubstantiated "facts":
So, whether this guy has a point or whether he's talking utter bullshit depends on these claims being correct.
It's not up to us to go verify some rant on Slashdot. It's up to the ranter to show he's right.
Let's examine a related "fact" from The Sun newspaper:
Trace that "fact" back to its origins and you'll find little substance.
Another example: 136 actual people became 7 million illegal downloaders.
There are people on both sides of the "piracy" argument with specious reasoning, dubious statistics and unstated biases. Don't let them argue their pet positions. Challenge them each and every time. That's the only way to take the bluster out of their rants.