Well, people are too quick to jump on any stories blasting RIM nowadays. We should rename HN to "Questionable Hacker Rumors".
For one, it is a rumor. Apple Insider isn't exactly known for well placed sources inside RIM.
Second, even if we were to take this at face value, read the text: "The layoffs will affect the company's legal, marketing, sales, operations, and human resources divisions, a source said." Not that engineering isn't mentioned. That is a good cutting of cruft.
This may go against what lots of tech. people like to think (it's certainly a much sexier idea to think of a good company as one run by and only employing hackers), but just for the record there are people in many departments, including legal, marketing, sales, operations and HR, who are both talented and useful at companies.
The fact that RIM clearly has a lot of cruft to cut doesn't mean that a.) that cruft is all, or even mostly, outside their technical staff or that b.) of the non-technical cruft, those getting fired are part of it.
The front page is constantly changing, I didn't see it 4 days ago, and apparently a lot of other people didn't either. If you don't like it, just ignore it.
No. It does not generate GPU binaries. It generates "PTX", which is a pseudo-assembler format. You then feed the PTX to Nvidia driver to generate the actual binary. AFAIK the actual ISA and binary formats are not openly (officially) documented.
And of course GPU vendors also employ similar techniques. It is not uncommon to see the same chip in multiple models, with lower-end models with parts of the chip disabled either due to defects or for product differentiation.
Great browser support is about the only thing Rim is doing right. They should go all in on web apps. Join Mozilla's WebAPI project, make web apps a first-class citizen on BBX (not requiring their own webworks stuff)
CSS3 3D transform support surprised me too. I don't own a playbook, but when I ran one of my tests (https://ajf.me/stuff/htmcraft/200blocks/ - doesn't seem to work in IE properly) on an in-store demo model I was pleasantly surprised it ran with hardware acceleration, something I've only seen Safari do so far (Chrome doesn't on the desktop).
You can distribute interpreters. However restrictions remain:
1. You cannot distribute an interpreter that can be used for running program code downloaded from the internet. So, for example, your user can save their script and use it themselves but they cannot give it to others (except perhaps through the app store bundled as an app itself).
2. Your interpreter cannot dynamically generate binary code so JIT compilers that generate binary code on-the-fly are not allowed.
edit: For example, LuaJIT cannot do JIT compilation on iOS but it can do JIT compilation for higher performance on Android.
Yes. 1st restriction above is more for business reasons, so that there are no ways to circumvent the app store, while 2nd is a technical restriction on 3rd party apps for security purposes. Apple apps (like Safari) can obviously do JIT compilation.
However, I speculate even the 2nd restriction is partly for business reasons because it prevents some third-party toolkits (such as those compiling to LLVM) from achieving high performance. You might remember that Adobe was compiling Flash to LLVM to allow devs to port their Flash apps to iOS, but since LLVM cannot do proper JIT compilation on iOS, it will reduce performance.
FWIW: WinRT imposes both the restrictions above. Android technically doesn't impose either for sideloaded apps. But if you want to distribute app through Google Play, the 1st restriction is indeed imposed.
>Apple apps (like Safari) can obviously do JIT compilation.
I hadn't considered this before, but that means that you could potentially use JS as an intermediate representation for other languages in order to leverage Safari's JIT under iOS. Probably too inefficient to be worthwhile for any language that isn't a dialect of JS, but an intriguing concept nonetheless.
Gotta love android, you can cheerfully mprotect away the write-protection on executable pages. I've done some dynamic stub code removal that way. Worst case, you can only hose your own process.
For one, it is a rumor. Apple Insider isn't exactly known for well placed sources inside RIM.
Second, even if we were to take this at face value, read the text: "The layoffs will affect the company's legal, marketing, sales, operations, and human resources divisions, a source said." Not that engineering isn't mentioned. That is a good cutting of cruft.