And didn't pay $10B for the patents. Here's a nice cost breakdown from public/SEC information or the interwebs:
Original purchase: $12.5B
Motorola's cash on hand from purchase: $2.9B (don't know much went with the sale, though...but definitely less than $2.91B)
Sale of Motorola Home: $2.35B
Sale of Motorola Mobility: $2.91B
Tax losses from Motorola: I don't know how much
So we're talking about a total cost of at most $4.34B for however many patents they're left with. And of course, there's all the invisible moneys they saved from not having to fight patent battles in court. Not to mention all the hardware/manufacturing/supply chain/client expertise they ended up with for use in their hardware projects, such as Glass and pusher robots. Yeah, not a bad deal at all. Heck, with a deal like this, they should do the same to RIMM as well -- widen that moat some more.
So, uh, that's why Google sold Motorola and kept the vast majority (not "some" as you stated) of the patents? Added to the fact that those patents were valued at almost half of the original purchase of Motorola? Oh, and how'd you get the $10B figure? I guess you didn't figure in the sale in Motorola Home for $2.35B? How about the $3B in cash that Motorola had when the original purchase took place? Good job with your "make your own smartphone" theory -- I had a good laugh.
I just read your other post, and you start to sound like someone who is uninformed. Chrome is the only other browser other than FF that "supports" Asm.js (technically speaking, all JS engines support Asm.js, so I don't know what you mean by "against it"). You can even run Epic Citadel on Chrome, and performance has been steadily improving.
I think every new version of Chrome they remove more of the webkit prefixes (and I don't think they add any more now?). I thought Google isn't even the "owner" of webkit, and Apple is? I'm also guessing this is one of the reasons why Google forked and went their own way.
I can understand your sentiment where you may not trust these benchmarks to be unbiased. However, I am fairly certain if they are, it'd be pretty easy to prove. Do you have any sites that show to the contrary?
Furthermore, one of the major points of all the "new web languages" is to add (optional) typing, which is where the biggest speedups come from modern JS engines -- type inference and unboxing. So to strip them of these features is akin to saying "you're allowed to benchmark C against Python if you made sure everything in C is type checked before being operated on, even if you know their types." So I'm not exactly sure what you're objecting to here.
Which one of them have expressed interest in each of the language the other is proposing? Let me give you a list:
Apple: Doesn't care, would rather you program in Objective-C.
MS: TypeScript, same issue -- who else do you think is adopting that?
Mozilla: LLJS, and how far along is that? Sure, there's asm.js (we're talking about speed here, yeah?), but that's a compile target and not something you'd want to write by hand from scratch -- that and it's not exactly a new language.
Google: Dart, and who knows, it might at least be on Opera some day? Caveat: you have to run Dartium if you don't want to compile to JS, but I'm sure they're working on that.
Think about it: the point that everyone is rejecting everyone else's language is because they all have their own wares to peddle. Of course "they" all express negative interest in supporting each other
At the end of the day, of all the modern browsers, which one has the highest market penetration/momentum? If you're going to target the "next generation" of web languages, which one would you chose?
Exactly, which is why PNaCl is superior at the end of the day. Good luck trying to jam multi-threaded, shared memory programming into JS. The standards committee itself already hate JS (but they maintain it for the "good of the web"). Don't even think about getting the standards committee to even think about a shared memory (webworkers with ArrayObject ownership transfer is as much of a concession as anyone's ever going to get). All JS VMs will have to be written from scratch just to support this programming model.
1) The code being benchmarked and compared against usually aren't production code, and are tight for-loops that're easy to optimize -- i.e. hit the cache all the time due to small code/data size, simple instruction mix, lack of SIMD comparisons, no real memory allocations, etc....
2) If it's a section of full production code and the results are similar, then "native" code is most likely nowhere near optimal to begin with. Just because it's "native" doesn't mean it's good. One can still write really shitty code in C/C++, i.e. triple nested vectors.
3) And if it's not complete shit and the "native" code still runs close to JS performance, then the programmer in question probably doesn't have as much experience optimizing for instruction mix, L1/L2 cache hit, pipeline balancing, software pipelining, etc....
I haven't seen any non-trivial high level code come close to real optimized C.
Asm.js is basically a somewhat limited (wrt native hardware capabilities) bytecode format in human-read/writeable form. Mozilla is resisting hard because it's just like the GP said -- their architecture isn't suited for Pepper. And as Mozilla tries to solve the multi-threading/SIMD/(u)int64 issue, it just looks more and more like (P)NaCl. I guess the nice thing about asm.js is that it doesn't require such a large upfront cost.
This is one of those things that's not necessarily true (usually true in a managed memory environment, though). If you have control to the OS functionality of memory and know your memory usage pattern, then you can actually reserve a lot of virtual memory pages in advance. Only the committed ones will consume physical memory -- in other words, you can expand your array by committing subsequent pages. And since we haven't gotten to the point where computers actually have 2^64 bytes of memory, we don't need to worry too much about running out of address space.
Or maybe people should just stop using so much templates, and use code generation instead. Oh, and also supporting the Apple/LLVM initiative to modularize C++ would be double plus good too (think #import in C++).
Please do explain if possible -- I'm very interested in reading the explanation. However, I have to admit I have the preconception of "we're not letting you play video games because this is for your own good."
Troll fail often? iPad and iPhones tend to have the top of the line internals at the time of release, CPU and GPU (they do skimp on RAM, though). If it wasn't for them maintaining screen resolution to help developers, they probably would've held on to the highest res screens title as well.
Well, it doesn't matter -- I thought the point is that everyone is born with sin. Therefore, Jesus's point is that no one should be casting anything, including magic missiles.
Ok how? I don't believe YouTube monetizes your videos (read: the ones you hold copyrights to, barring an unlawful claim to your original work) unless you explicitly tell it to.
Sure, there is a case as you pointed out -- people sitting on the fence will chose DRM when given the option. But did having a way to explicitly monetize help or dimish the App Store? I would argue if anything, the platform allowed Apple's ecosystem to flourish (let's not get into the whole walled garden argument).
Furthermore, if DRM is a form of economic protectionism, then so are the police who make sure people don't steal. Is that anti-competitive? Sure, for the thieves. But that doesn't mean it's discouraging economic participation.
If you honestly think that is one practical way, then I really don't see how you're being reasonable and not just nitpicking. If you think the standards people want to use this as a way to hijack the openness of the browser in general, that's probably the tin foil hat letting in the mind controlling waves.
If that is the case, then everyone would've turned on DRM and monetized all their videos on YouTube (you can already do that now, you know?). Since that isn't the case, I don't see how your argument fits observed human behavior.
Right, obfuscation. Still hackable, just like EME. If the Content Decryption Module is sitting on your machine, you can still attach a debugger to it. Just...how much work do you want to spend? This is the same issue in all DRM schemes -- someone can break it, but it'll require a lot of effort to do so. And also, by your example, does that mean you want more EME?
What's betterment for you? Convenience? Exchange of information? Instant access? Collaboration? Reduction in human capital? Something else? Combination of all these benefits? So if EME provides convenience, then doesn't it make society better? Does it degrade other things? Like what? Exchange of information (media)? How so if there wasn't any information being exchanged to begin with (i.e. content owners didn't publish ANYTHING before DRM happened)?
Slashdot Mirror
And didn't pay $10B for the patents. Here's a nice cost breakdown from public/SEC information or the interwebs:
Original purchase: $12.5B
Motorola's cash on hand from purchase: $2.9B (don't know much went with the sale, though...but definitely less than $2.91B)
Sale of Motorola Home: $2.35B
Sale of Motorola Mobility: $2.91B
Tax losses from Motorola: I don't know how much
So we're talking about a total cost of at most $4.34B for however many patents they're left with. And of course, there's all the invisible moneys they saved from not having to fight patent battles in court. Not to mention all the hardware/manufacturing/supply chain/client expertise they ended up with for use in their hardware projects, such as Glass and pusher robots. Yeah, not a bad deal at all. Heck, with a deal like this, they should do the same to RIMM as well -- widen that moat some more.
So, uh, that's why Google sold Motorola and kept the vast majority (not "some" as you stated) of the patents? Added to the fact that those patents were valued at almost half of the original purchase of Motorola? Oh, and how'd you get the $10B figure? I guess you didn't figure in the sale in Motorola Home for $2.35B? How about the $3B in cash that Motorola had when the original purchase took place? Good job with your "make your own smartphone" theory -- I had a good laugh.
No, the point is Dart more or less includes its own version of jQuery directly in the default library.
I just read your other post, and you start to sound like someone who is uninformed. Chrome is the only other browser other than FF that "supports" Asm.js (technically speaking, all JS engines support Asm.js, so I don't know what you mean by "against it"). You can even run Epic Citadel on Chrome, and performance has been steadily improving.
I think every new version of Chrome they remove more of the webkit prefixes (and I don't think they add any more now?). I thought Google isn't even the "owner" of webkit, and Apple is? I'm also guessing this is one of the reasons why Google forked and went their own way.
I can understand your sentiment where you may not trust these benchmarks to be unbiased. However, I am fairly certain if they are, it'd be pretty easy to prove. Do you have any sites that show to the contrary?
Furthermore, one of the major points of all the "new web languages" is to add (optional) typing, which is where the biggest speedups come from modern JS engines -- type inference and unboxing. So to strip them of these features is akin to saying "you're allowed to benchmark C against Python if you made sure everything in C is type checked before being operated on, even if you know their types." So I'm not exactly sure what you're objecting to here.
Which one of them have expressed interest in each of the language the other is proposing? Let me give you a list:
Think about it: the point that everyone is rejecting everyone else's language is because they all have their own wares to peddle. Of course "they" all express negative interest in supporting each other
At the end of the day, of all the modern browsers, which one has the highest market penetration/momentum? If you're going to target the "next generation" of web languages, which one would you chose?
Also from Cornell, not too long ago, solving similar problems. What happened to that one?
Exactly, which is why PNaCl is superior at the end of the day. Good luck trying to jam multi-threaded, shared memory programming into JS. The standards committee itself already hate JS (but they maintain it for the "good of the web"). Don't even think about getting the standards committee to even think about a shared memory (webworkers with ArrayObject ownership transfer is as much of a concession as anyone's ever going to get). All JS VMs will have to be written from scratch just to support this programming model.
That's because:
I haven't seen any non-trivial high level code come close to real optimized C.
Asm.js is basically a somewhat limited (wrt native hardware capabilities) bytecode format in human-read/writeable form. Mozilla is resisting hard because it's just like the GP said -- their architecture isn't suited for Pepper. And as Mozilla tries to solve the multi-threading/SIMD/(u)int64 issue, it just looks more and more like (P)NaCl. I guess the nice thing about asm.js is that it doesn't require such a large upfront cost.
Are you talking about self-modifying code? You can certainly do that in C, but just much, much more involved.
Are you're still living in the 90s? Or is that supposed to be tongue-in-cheek?
This is one of those things that's not necessarily true (usually true in a managed memory environment, though). If you have control to the OS functionality of memory and know your memory usage pattern, then you can actually reserve a lot of virtual memory pages in advance. Only the committed ones will consume physical memory -- in other words, you can expand your array by committing subsequent pages. And since we haven't gotten to the point where computers actually have 2^64 bytes of memory, we don't need to worry too much about running out of address space.
Or maybe people should just stop using so much templates, and use code generation instead. Oh, and also supporting the Apple/LLVM initiative to modularize C++ would be double plus good too (think #import in C++).
Please do explain if possible -- I'm very interested in reading the explanation. However, I have to admit I have the preconception of "we're not letting you play video games because this is for your own good."
Troll fail often? iPad and iPhones tend to have the top of the line internals at the time of release, CPU and GPU (they do skimp on RAM, though). If it wasn't for them maintaining screen resolution to help developers, they probably would've held on to the highest res screens title as well.
Well, it doesn't matter -- I thought the point is that everyone is born with sin. Therefore, Jesus's point is that no one should be casting anything, including magic missiles.
Ok how? I don't believe YouTube monetizes your videos (read: the ones you hold copyrights to, barring an unlawful claim to your original work) unless you explicitly tell it to.
Sure, there is a case as you pointed out -- people sitting on the fence will chose DRM when given the option. But did having a way to explicitly monetize help or dimish the App Store? I would argue if anything, the platform allowed Apple's ecosystem to flourish (let's not get into the whole walled garden argument).
Furthermore, if DRM is a form of economic protectionism, then so are the police who make sure people don't steal. Is that anti-competitive? Sure, for the thieves. But that doesn't mean it's discouraging economic participation.
If you honestly think that is one practical way, then I really don't see how you're being reasonable and not just nitpicking. If you think the standards people want to use this as a way to hijack the openness of the browser in general, that's probably the tin foil hat letting in the mind controlling waves.
If that is the case, then everyone would've turned on DRM and monetized all their videos on YouTube (you can already do that now, you know?). Since that isn't the case, I don't see how your argument fits observed human behavior.
Right, obfuscation. Still hackable, just like EME. If the Content Decryption Module is sitting on your machine, you can still attach a debugger to it. Just...how much work do you want to spend? This is the same issue in all DRM schemes -- someone can break it, but it'll require a lot of effort to do so. And also, by your example, does that mean you want more EME?
And do you have stats to back that up?
What's betterment for you? Convenience? Exchange of information? Instant access? Collaboration? Reduction in human capital? Something else? Combination of all these benefits? So if EME provides convenience, then doesn't it make society better? Does it degrade other things? Like what? Exchange of information (media)? How so if there wasn't any information being exchanged to begin with (i.e. content owners didn't publish ANYTHING before DRM happened)?