Their stock and their products have been stagnant for the past 10 years and I don't see that changing any time soon. It's pathetic that such a large corporation must stoop to this level considering all of the bad PR it brings along with it and the image it tags you with. Perhaps they'll come to the conclusion that they're better than this and focus on technology and innovation instead of using their position to try and crush their opposition in the court room.
But, they're fighting a war they can't win because they'll eventually need to face Google if they continue down this path. Although, I must admit it would be glorious to see Google shred through all of their frivolous and prior art ridden patent portfolio.
Google should make a change to their Android licensing terms. If you want a licence to the Google services or to even use Android commercially you must allow your patent portfolio to be used to defend the Android OS. With other companies in collusion and forming patent pools to attack Android this seems the best solution to smack down these patent trolls.
My sentiments exactly. The app selection in the HP marketplace is very slim pickings. Regardless of how good the user experience is the lack of applications just nullifies every argument in favor of the Touchpad. You never really understand how important an ecosystem is until you're dependent on it. Had Android not been ported to the Touchpad I would sold it a long time ago. I'll probably never get rid of the WebOS partition because it's still an interesting OS to use. It was actually a bit of a shock coming from WebOS to CyanogenMod because I was so used to the WebOS gestures - so much so that I even tried to kill an app by flipping it towards the top of the screen. The card metaphor is also quite nice because you know exactly what's running instantly. I hope ICS steals some of the UI and UE features of WebOS because it really was an outstanding UI.
It's an alpha build, but it works extremely well on my 32GB Touchpad. You also get the best of both worlds by being able to boot into either WebOS or Android.
From the rootzwiki site here is what is working and what is not working. As you can see they are very close to releasing a beta.
WORKING Android USB gadget with adb LVM in Android Touchscreen with multitouch GPU acceleration Proper pixel format(color). Sound via speakers WiFi Accelerometer Battery reporting
NOT WORKING Video playback via overlay Camera Bluetooth Gyroscope Compass
The problem is Google has already beaten Microsoft at their own game and there isn't anything they can do about it. That ship has long sailed when Google recognized the opportunity and Microsoft didn't.
It's kind of ironic that MS phones and tablets will be viewed upon as the distant third place entrants in a two mobile O/S race. Kind of how Linux is viewed on in the desktop space. I have a feeling they'll be there for some time.
Actually, it is compiled. The compiled code is actually highly optimized machine code that is more efficient than what a statically compiled language could ever hope to produce. The technology is called HotSpot compilation. Do your career a favor and educate yourself on it.
The level of ignorance exhibited in relation to Java compilation and execution is just bewildering - even for a slashdot crowd. Please educate yourself on how the JVM Hotspot compiler works before making such silly comments in the future. And just to clarify, the JVM HotSpot compiler does compile the byte code into extremely efficient platform targeted machine code.
The Java HotSpot Compiler
Background
The Java programming language is a new one, with its own unique performance characteristics. Most attempts to date to accelerate Java programming language performance have focused on applying compilation techniques developed for traditional languages.
Just-In-Time (JIT) compilers are essentially fast traditional compilers that translate the Java-technology bytecodes into native machine code on-the-fly. A JIT runs on the end-user's machine which actually executes the bytecodes, and compiles each method the first time it is executed.
There are several problems with JIT compilation. First, because the compiler runs on the execution machine in "user time," it is severely constrained in terms of compile speed: if it is not very fast, then the user will perceive a significant delay in the startup of a program or part of a program. This entails a trade-off that makes it far more difficult to perform advanced optimizations, which usually slow down compilation performance significantly.
Secondly, even if a JIT had time to perform full optimization, such optimizations are less effective for the Java programming language than for traditional languages like C and C++. There are a number of reasons for this effect:
The Java programming language is dynamically "safe", meaning that it is ensured that programs do not violate the language semantics, or directly access unstructured memory. This means dynamic type-tests must frequently be performed (when casting, and when storing into object arrays).
The Java programming language allocates all objects on the "heap", whereas in C++ many objects are stack allocated. This means that object allocation rates are much higher for the Java programming language than for C++. In addition, because the Java programming language is garbage-collected, it has very different types of memory allocation overhead (including potentially scavenging and write-barrier overhead) than C++.
In the Java programming language, most method invocations are "virtual" (potentially polymorphic), which are much less frequent in C++. This means not only that method invocation performance is more dominant, but that static compiler optimizations (especially global optimizations like inlining) are much harder to perform for method invocations. Most traditional optimizations are most effective between calls, and the decreased distance between calls in the Java programming language can significantly reduce the effectiveness of such optimizations, since they have smaller sections of code to work with.
Java technology-based programs can change on-the-fly due to the powerful ability to perform dynamic loading of classes. This makes it far more difficult to perform many types of global optimization, since the compiler must not only be able to detect when these optimizations become invalid due to dynamic loading, but also must be able to undo and/or redo those optimizations during program execution, even if they involve active methods on the stack, without compromising or impacting Java technology-based program execution semantics in any way.
As a result, any attempt to achieve fundamental advances in Java programming language performance must provide non-traditional answers to these performance issues, rather than blindly applying traditional compiler techniques.
The Java HotSpot performance engine architecture addresses the Java programming language performance issues described above by using adaptive optimization technology. Adaptive optimization is the fruit of many years of research into object-oriented language implementation performed by the Sel
Gosling: "It's a toolkit based on the Windows API and getting it to run on other platforms is problematic," he said."
"Somehow I really doubt that Gosling doesn't understand how Eclipse works in the context and I doubt that Skerrett is dumb enough to think that he does, though I'm less sure of the second point as I don't know anything about him."
Judging from the fact that James Gosling believes that SWT is based on the Windows API, I think it would be safe to say that he has no idea on how SWT works and the interoperability of SWT. I would even guess that he's probably never even used Eclipse because of his personal dislike of the organization and how they came up with their name (Eclipse of the Sun).
Slashdot Mirror
The hunter is now the hunted.
The description of some those Microsoft patents seems to indicate they're quite old. I wonder how many of them will be expiring soon.
Their stock and their products have been stagnant for the past 10 years and I don't see that changing any time soon. It's pathetic that such a large corporation must stoop to this level considering all of the bad PR it brings along with it and the image it tags you with. Perhaps they'll come to the conclusion that they're better than this and focus on technology and innovation instead of using their position to try and crush their opposition in the court room.
But, they're fighting a war they can't win because they'll eventually need to face Google if they continue down this path. Although, I must admit it would be glorious to see Google shred through all of their frivolous and prior art ridden patent portfolio.
Google should make a change to their Android licensing terms. If you want a licence to the Google services or to even use Android commercially you must allow your patent portfolio to be used to defend the Android OS. With other companies in collusion and forming patent pools to attack Android this seems the best solution to smack down these patent trolls.
Well, they make Havoc which is the most popular middleware physics engine in the world and used by a majority of console games.
and their soup is made out of soylent green.
It would be so fitting.
My sentiments exactly. The app selection in the HP marketplace is very slim pickings. Regardless of how good the user experience is the lack of applications just nullifies every argument in favor of the Touchpad. You never really understand how important an ecosystem is until you're dependent on it. Had Android not been ported to the Touchpad I would sold it a long time ago. I'll probably never get rid of the WebOS partition because it's still an interesting OS to use. It was actually a bit of a shock coming from WebOS to CyanogenMod because I was so used to the WebOS gestures - so much so that I even tried to kill an app by flipping it towards the top of the screen. The card metaphor is also quite nice because you know exactly what's running instantly. I hope ICS steals some of the UI and UE features of WebOS because it really was an outstanding UI.
Cyanogen was not responsible for the porting CyanogenMod 7 to the HP Touchpad. The primary developer is Erik Hardesty (dalingrin).
It's an alpha build, but it works extremely well on my 32GB Touchpad. You also get the best of both worlds by being able to boot into either WebOS or Android.
From the rootzwiki site here is what is working and what is not working. As you can see they are very close to releasing a beta.
WORKING
Android USB gadget with adb
LVM in Android
Touchscreen with multitouch
GPU acceleration
Proper pixel format(color).
Sound via speakers
WiFi
Accelerometer
Battery reporting
NOT WORKING
Video playback via overlay
Camera
Bluetooth
Gyroscope
Compass
Looks like you got the wrong memo. Any language that is not used by a hipster is dead.
Byte signature probably.
to eliminate competition in the browser space.
We already know the patents they're using. They're the same ones they used to try and shake down Barnes and Noble: http://www.freepatentsonline.com/5778372.html http://www.freepatentsonline.com/6339780.html http://www.freepatentsonline.com/5889522.html http://www.freepatentsonline.com/6891551.html http://www.freepatentsonline.com/6957233.html They also demanded licensing fees that exceeded the cost of licensing WP7. They really are criminals.
The problem is Google has already beaten Microsoft at their own game and there isn't anything they can do about it. That ship has long sailed when Google recognized the opportunity and Microsoft didn't. It's kind of ironic that MS phones and tablets will be viewed upon as the distant third place entrants in a two mobile O/S race. Kind of how Linux is viewed on in the desktop space. I have a feeling they'll be there for some time.
open sourcing their customer data. What's wrong with giving back to the community?
What about the Progress Bar?
The wait time is atrocious.
Actually, it is compiled. The compiled code is actually highly optimized machine code that is more efficient than what a statically compiled language could ever hope to produce. The technology is called HotSpot compilation. Do your career a favor and educate yourself on it.
The level of ignorance exhibited in relation to Java compilation and execution is just bewildering - even for a slashdot crowd. Please educate yourself on how the JVM Hotspot compiler works before making such silly comments in the future. And just to clarify, the JVM HotSpot compiler does compile the byte code into extremely efficient platform targeted machine code.
The Java HotSpot Compiler
Background
The Java programming language is a new one, with its own unique performance characteristics. Most attempts to date to accelerate Java programming language performance have focused on applying compilation techniques developed for traditional languages.
Just-In-Time (JIT) compilers are essentially fast traditional compilers that translate the Java-technology bytecodes into native machine code on-the-fly. A JIT runs on the end-user's machine which actually executes the bytecodes, and compiles each method the first time it is executed.
There are several problems with JIT compilation. First, because the compiler runs on the execution machine in "user time," it is severely constrained in terms of compile speed: if it is not very fast, then the user will perceive a significant delay in the startup of a program or part of a program. This entails a trade-off that makes it far more difficult to perform advanced optimizations, which usually slow down compilation performance significantly.
Secondly, even if a JIT had time to perform full optimization, such optimizations are less effective for the Java programming language than for traditional languages like C and C++. There are a number of reasons for this effect:
The Java programming language is dynamically "safe", meaning that it is ensured that programs do not violate the language semantics, or directly access unstructured memory. This means dynamic type-tests must frequently be performed (when casting, and when storing into object arrays).
The Java programming language allocates all objects on the "heap", whereas in C++ many objects are stack allocated. This means that object allocation rates are much higher for the Java programming language than for C++. In addition, because the Java programming language is garbage-collected, it has very different types of memory allocation overhead (including potentially scavenging and write-barrier overhead) than C++.
In the Java programming language, most method invocations are "virtual" (potentially polymorphic), which are much less frequent in C++. This means not only that method invocation performance is more dominant, but that static compiler optimizations (especially global optimizations like inlining) are much harder to perform for method invocations. Most traditional optimizations are most effective between calls, and the decreased distance between calls in the Java programming language can significantly reduce the effectiveness of such optimizations, since they have smaller sections of code to work with.
Java technology-based programs can change on-the-fly due to the powerful ability to perform dynamic loading of classes. This makes it far more difficult to perform many types of global optimization, since the compiler must not only be able to detect when these optimizations become invalid due to dynamic loading, but also must be able to undo and/or redo those optimizations during program execution, even if they involve active methods on the stack, without compromising or impacting Java technology-based program execution semantics in any way.
As a result, any attempt to achieve fundamental advances in Java programming language performance must provide non-traditional answers to these performance issues, rather than blindly applying traditional compiler techniques.
The Java HotSpot performance engine architecture addresses the Java programming language performance issues described above by using adaptive optimization technology. Adaptive optimization is the fruit of many years of research into object-oriented language implementation performed by the Sel
Gosling: "It's a toolkit based on the Windows API and getting it to run on other platforms is problematic," he said."
"Somehow I really doubt that Gosling doesn't understand how Eclipse works in the context and I doubt that Skerrett is dumb enough to think that he does, though I'm less sure of the second point as I don't know anything about him."
Judging from the fact that James Gosling believes that SWT is based on the Windows API, I think it would be safe to say that he has no idea on how SWT works and the interoperability of SWT. I would even guess that he's probably never even used Eclipse because of his personal dislike of the organization and how they came up with their name (Eclipse of the Sun).
That's all nice and that, but what are the frame rates in HL2?
Ah yes, the typical duesche bag that thinks everyone has an angle.
Can you please elaborate on the ingame tribute to one of your fallen comrades.
Firefox over Internet Explorer.
"MacGibbon: eBay does not endorse any particular browser."
OK, strike that. Well at least he recommends Linux over Windows.
"MacGibbon: eBay does not endorse any particular platform."
Oh Well.