Since Steve has to make hardware changes anyway in order to keep out those dastardly freedom loving jailbreakers, how about fixing his antenna while he's at it?
What they apparently didn't notice is that narcissists are always people with low self esteem (though the converse isn't necessarily true). The narcissist loves an image of themself that is improved or perfected in some way and does not correspond to their actual self. They do not hold their actual self in high esteem, which is why they create the image. Unfortunately, this situation is all too common, with sad effects for all concerned.
this trend of ever faster ARM platforms is interesting for the netbook market
Sadly, I presume it also means "ever hotter" and "ever more power hungry" as it has for the desktop market. I would much prefer "same power draw and but more throughput", however I may not be the typical consumer.
MySQL is already under a cloud, OpenOffice is still buggy bloatware, so we can take those two off the list.
Off your list maybe. Others are likely to differ with you over MySQL, and I certainly do in regards to OpenOffice of which I am a heavy user, warts and all.
Ahhhh shit! Time to learn another fucking language and 10 more over-engineered libraries! So much for time with the family.
Actually, it would be very straightforward just to expose the native C/C++ libraries, allowing you to develop in C++ or whatever you choose. The burden of effort here would not be on the developer. The main difficultly is achieving a level of sandboxing that meets or exceeds that of the Dalvik JVM. Something of a challenge but definitely doable. An obvious approach: run apps virtualized. Under KVM say, this would impose a slight overhead but nothing remotely in the ballpark of the overhead imposed by Dalvik.
Come to think of it, this approach could be hacked together in very little time at all and does not require the blessing of Google to demonstrate the concept, thanks to ease of loading custom firmware on most Android phones. Somebody needs to do this proof of concept, and sorry, not me, at least, not this week. I suppose if nobody else does it then I'll take a run at it.
Java is actually an idiotic choice for mobile devices. Running on an interpreter means it uses many times the battery power to get things done compared to native apps.
I'd contend that view is outdated, partly because hardware's moved on just enough to allow for a software layer with extra fat, but mostly because the market's shown that android has been hugely successful - with good reason. We can argue over what the reason might be, but is it idiotic to find a solution that sells so well in spite of increased power consumption? I can't agree with that.
I would content that my views about software efficiency and battery life are far from outdated. Battery life is one of the big influences on purchase decisions btween phones of similar capability, even when deciding between Iphone or Android. That and signal reception quality:-)
IMO licenses should be adhered to or you shouldn't use the technology. This applies to both closed and open source licenses, not just licenses we like this week because the benefit us.
A fair license should be adhered to. In case of an unfair license, just obey the law, be ethical, be moral, then feel free to kick it to hell as it richly deserves.
Instead of abiding by the spirit and intent of the license, Google instead chose to ignore it entirely by exploiting a loophole.
The spirit and intent of Sun's Java license has always been to lock users into what is less than best for them. Just as the spirit and intent of mobile carriers has always been to lock users into situations that are detestable for everyone but the carriers. Google managed to blow the cozy old mobile market wide open, and I fully support their intent to do the same for the Java market. In the end, users should make the rules, don't you agree?
At the same time I applaud this misbegotten lawsuit by Oracle, if only from the point of view of making it abundantly clear that Oracle is not to be trusted with stewardship of important components of the open source ecosystem.
Isn't this exactly what Stallman warned [gnu.org] when he suggested that Open Office should be forked because it used Java?
Regardless of ooo's tie to Java, it is clear that Oracle cannot be trusted to act in good faith as steward of Openoffice. This should remove all doubt that a fork is necessary. Incidentally, ooo is already forked, however that fork is also a patent trap courtesy of Mono.
Every other mobile implementation is licensed, but Google thought they were special and could get around it.
Google went to the effort of developing a clean-room bytecode interpreter so they did not just game the rules as you imply. Let alone the question of whether patenting a computer language is inherently evil (it is).
Guy, literally every single one of your guesses is absolutely way out.
That is a wild exaggeration, for example his observation about copy-on-write process memory is absolutely correct and dates back to the dawn of Unix.
They're talknig more about classloaders and signed apps than ACLs and C++-style object models. Your SQL example is hilarious - no, they're not trying to count anything. They're creating shared class files originally comprised of greater than one class file, recognising where the byte blocks are identical. Think more VM or storage deduplication, not counting things.
There is more than one way to skin a cat. I would suggest running the byte code through rzip, which will deduplicate it even more effectively.
Or at least, fully support native binary apps right now, at the same time as trying to clear up Dalvik's legal situation. Java is actually an idiotic choice for mobile devices. Running on an interpreter means it uses many times the battery power to get things done compared to native apps. Just expose a native app loader so folks who want to build native apps don't have to jump through demented JNI hoops.
Java may have its advantages - mainly, a garbage collector, which is also a disadvantage - but C++ apps run way faster, even if Java is JITted. And a JIT sucks battery life too, as well as introducing annoying, user-visible startup latency and imposing a huge memory footprint. Just take a deep breath and go native, it's the best solution for everybody.
Slashdot Mirror
Since Steve has to make hardware changes anyway in order to keep out those dastardly freedom loving jailbreakers, how about fixing his antenna while he's at it?
"Narcissists with low self-esteem" sounds like an oxymoron.
Narcissists have high esteem for the fictional self they create and low esteem for their real self, no contradiction.
They needed a fucking study to see that ?
What they apparently didn't notice is that narcissists are always people with low self esteem (though the converse isn't necessarily true). The narcissist loves an image of themself that is improved or perfected in some way and does not correspond to their actual self. They do not hold their actual self in high esteem, which is why they create the image. Unfortunately, this situation is all too common, with sad effects for all concerned.
this trend of ever faster ARM platforms is interesting for the netbook market
Sadly, I presume it also means "ever hotter" and "ever more power hungry" as it has for the desktop market. I would much prefer "same power draw and but more throughput", however I may not be the typical consumer.
Yeah, it's actually kind of funny how today's Intel desktop processors actually trace their lineage to the Pentium M, which was a mobile chip
And the pentium M traces its lineage to the Pentium 3, which intel tried to abandon in favor of the Pentium 4 with Netburst[tm].
EPIC was a dumb idea.
MySQL is already under a cloud, OpenOffice is still buggy bloatware, so we can take those two off the list.
Off your list maybe. Others are likely to differ with you over MySQL, and I certainly do in regards to OpenOffice of which I am a heavy user, warts and all.
you can't really bitch about MSFT making incompatible versions with MS Java and then give Google a free pass just cause you like the company
Microsoft intended to destroy Java. Google intended to popularize it.
Then he can go an look for something else to destroy.
MySQL, say? Or OpenOffice or Btrfs.
Is Oracle the new SCO?
Yes. Somebody proposed the moniker SCOracle, and that makes a great deal of sense to me.
Ahhhh shit! Time to learn another fucking language and 10 more over-engineered libraries! So much for time with the family.
Actually, it would be very straightforward just to expose the native C/C++ libraries, allowing you to develop in C++ or whatever you choose. The burden of effort here would not be on the developer. The main difficultly is achieving a level of sandboxing that meets or exceeds that of the Dalvik JVM. Something of a challenge but definitely doable. An obvious approach: run apps virtualized. Under KVM say, this would impose a slight overhead but nothing remotely in the ballpark of the overhead imposed by Dalvik.
Come to think of it, this approach could be hacked together in very little time at all and does not require the blessing of Google to demonstrate the concept, thanks to ease of loading custom firmware on most Android phones. Somebody needs to do this proof of concept, and sorry, not me, at least, not this week. I suppose if nobody else does it then I'll take a run at it.
Why screw Oracle and not F*ck You Google for selling me a product you had no legal right to sell me?
Because it is Oracle who is trying to make life worse for you and me, and not Google.
Your OS, drivers, and applications will easily eat half of that 64 GB without saving a single file of user data.
Is that what life is like in Windows land these days? Condolences.
You know how stupid Buck Rogers looked to you when you were a kid? That's how stupid Star Wars looks to your kids.
And it would require massive rewriting of Android components and almost all apps, ruining the current install base Android has built up.
Nonsense. Current apps would continue to work just fine and anybody who wants to take the risk can just stick with Java.
Java is actually an idiotic choice for mobile devices. Running on an interpreter means it uses many times the battery power to get things done compared to native apps.
I'd contend that view is outdated, partly because hardware's moved on just enough to allow for a software layer with extra fat, but mostly because the market's shown that android has been hugely successful - with good reason. We can argue over what the reason might be, but is it idiotic to find a solution that sells so well in spite of increased power consumption? I can't agree with that.
I would content that my views about software efficiency and battery life are far from outdated. Battery life is one of the big influences on purchase decisions btween phones of similar capability, even when deciding between Iphone or Android. That and signal reception quality :-)
This may serve well to provide sandboxing for Android in place of Java
IMO licenses should be adhered to or you shouldn't use the technology. This applies to both closed and open source licenses, not just licenses we like this week because the benefit us.
A fair license should be adhered to. In case of an unfair license, just obey the law, be ethical, be moral, then feel free to kick it to hell as it richly deserves.
Instead of abiding by the spirit and intent of the license, Google instead chose to ignore it entirely by exploiting a loophole.
The spirit and intent of Sun's Java license has always been to lock users into what is less than best for them. Just as the spirit and intent of mobile carriers has always been to lock users into situations that are detestable for everyone but the carriers. Google managed to blow the cozy old mobile market wide open, and I fully support their intent to do the same for the Java market. In the end, users should make the rules, don't you agree?
At the same time I applaud this misbegotten lawsuit by Oracle, if only from the point of view of making it abundantly clear that Oracle is not to be trusted with stewardship of important components of the open source ecosystem.
The article was very informative - but said nothing whatsoever about Mono's own patent exposure from Microsoft.
If anything this whole thing should make you MORE wary of Mono.
Your post is clearly not flamebait.
It does seem strange that Google, rather than using Python, whose creator (Guido van Rossum) is employed by Google, they chose to use Java....
Python runs as slow as molasses in January. Mind you, not as bad as it once was but still very bad.
Isn't this exactly what Stallman warned [gnu.org] when he suggested that Open Office should be forked because it used Java?
Regardless of ooo's tie to Java, it is clear that Oracle cannot be trusted to act in good faith as steward of Openoffice. This should remove all doubt that a fork is necessary. Incidentally, ooo is already forked, however that fork is also a patent trap courtesy of Mono.
Every other mobile implementation is licensed, but Google thought they were special and could get around it.
Google went to the effort of developing a clean-room bytecode interpreter so they did not just game the rules as you imply. Let alone the question of whether patenting a computer language is inherently evil (it is).
Guy, literally every single one of your guesses is absolutely way out.
That is a wild exaggeration, for example his observation about copy-on-write process memory is absolutely correct and dates back to the dawn of Unix.
They're talknig more about classloaders and signed apps than ACLs and C++-style object models. Your SQL example is hilarious - no, they're not trying to count anything. They're creating shared class files originally comprised of greater than one class file, recognising where the byte blocks are identical. Think more VM or storage deduplication, not counting things.
There is more than one way to skin a cat. I would suggest running the byte code through rzip, which will deduplicate it even more effectively.
Or at least, fully support native binary apps right now, at the same time as trying to clear up Dalvik's legal situation. Java is actually an idiotic choice for mobile devices. Running on an interpreter means it uses many times the battery power to get things done compared to native apps. Just expose a native app loader so folks who want to build native apps don't have to jump through demented JNI hoops.
Java may have its advantages - mainly, a garbage collector, which is also a disadvantage - but C++ apps run way faster, even if Java is JITted. And a JIT sucks battery life too, as well as introducing annoying, user-visible startup latency and imposing a huge memory footprint. Just take a deep breath and go native, it's the best solution for everybody.