That's funny because every time there's a massive security problem, it's not a younger programmer at faul
Citation required.
." So in review, for younger programmer, stupid mistakes and software glitches, yes, blatant security holes and generally old technology and methods, no!
Arrogance and belief that as a younger programmer one intuitively knows how to avoid vulnerabilities and poor security practices are far more likely to cause such security holes. such a person might be one of the fraction of a percent of programmers (young or old) who is as good as he thinks he is - but I wouldn't bet my livelihood on it.
There is no substitution for experience - in security matters as well as avoiding stupid mistakes and software glitches.
Do me and my granny a favour and stop bashing Apple for accomplishing what me / you / Ubuntu / Richard Stallman keep failing to accomplish.
I didn't see where GP was doing any bashing at all - he pointed out that they've made usable devices and systems that people like; and that their consumer base is not the geeks who are in an uproar over this. In other words, he was spot on.
are you serious? how do you think the old dynamically linked libraries are updated to run on a vastly different modern multiuser operating system?
Even if a compatibility layer is loaded between the OS and the component, the component and the layer are both running native code - not interpreted. Let's take an extreme situation: you're running a VM. Do you think all of the instructions in the system you run are interpreted by software? Unless it's a software VM architecture, you're not. The code still runs directly on the CPU. The overall performance is not as good because of the additional layers - but ultimately the binary code is not running interpreted. More recently, even software x86 VMs are trending towards the same behavior.
the REAL question is why are YOU talking about interpreted code
Actually the REAL question is this: why are you going on a rabid posting frenzy about this subject, since - by and large - it doesn't appear that you have much knowledge on the subject?
milliseconds of latency on every single executed flash bytecode instruction... billions and billions and billions of them, all of which also require electricity that will be drained from the battery.
If you think that - as a general rule - each opcode in any interpreted platform adds anything close to milliseconds of latency, you probably should call it quits now;)
show me a flash application that can't be written natively and function better and use less resources.
Nice straw man. Just because something can be written *more* efficiently does not imply a lack of efficiency.
show me a flash application that without it, your phone is useless.
Yeah, much better for your fart apps to be native. What was the point of this statement?
Do you think that if Google didn't call this Java (or more accurately market it as being programmable in Java) that Oracle would be suing at all? Similarly if they had a compliant JVM implementation, I suspect we'd see no law suit.
The only difference here is that Sun sued over calling something "Java" that wasn't exactly Java. Oracle is doing something a bit deeper in that they are saying that Google can't fork the language even if they call it something different.
I think I've missed something - last I saw, Google isn't calling it something different? If they were, I can't see how this would be a problem. But when I look at the Android Fundamentals page, this is the first thing I see (emphasis added):
Android applications are written in the Java programming language. The compiled Java code — along with any data and resource files required by the application — is bundled by the aapt tool into an Android package, an archive file marked by an.apk suffix. T
So where do you see that they're not calling it Java?
The similarity of android's dev language with Java is only superficial
You mean, aside from the fact that they are exactly the same language and both provide a large number of the same classes in the java.* namespace, they are completely different?
Damn, I'm going to do it -- I'm going to make a car analogy. I'm sorry in advance, because I *know* someone is going to helpfully correct it and take it far beyond the point I was trying to prove.
Let's say all cars had a single engine they used. They could manufacture this engine themselves, but it had to conform to the agreed-upon specs if they wanted to call it a "car engine". So Ford and Chevy and Toyota are all happily marketing cars with Genuine Car Engines; they have different trim and options, but they all use the same Car Engine under the hood.
Suddenly Hyundai comes along with its new line of cars which also uses a Genuine Car Engine. Except - as it turns out - their engine is custom built from the ground up. Its interfaces conform to the Car Engine spec, but internally it functions completely differently. If you dropped a Ford card body onto a Hyundai Car Engine, it wouldn't work at all correctly. The check engine light would play the tune of Old McDonald's and the turn signals would put the car into reverse.
Hyundai's Car Engine is superficially the same as the standard Car Engine, but it doesn't work the same way; nor does it do the same things.
Okay, I may have gotten carried away there. So let's try without the car analogy. The language constructs are the same. Even many classes are shared with the same functionality. However, you cannot execute compiled GoogleJava code on a standard JVM; and you cannot execute standard Java binaries on a Google Car Engine... erm, JVM. This is true even if the source code uses only classes that are shared in common across both platforms.
We are? What are the indications? The fact that Google has been sued for making a Java implementation that does not conform to the Java specification, and yet continues to call it Java?
It'll probably get me modded down, but I don't see this as a Bad Thing. When it comes to core Java systems (excluding GUI) it *is* write once run anywhere as long as you use the standard packages. Not only will it run on any JVM, it will also run in a predictable manner on any JVM (and I think this is one place where Google changes things - the behavior at execution time in some cases). I don't want a trusted vendor such as Google pushing a JVM implementation that is not compliant, yet still continuing to call it Java. Right now, when someone applies for a job as a senior Java developer, everyone knows what it means. When the JVM implementation is no longer standardized, developers start learning implementations instead of the platform -- quite possibly without knowing it.
If use a Java syntax with a custom JVM but called it something other than Java, I don't think Oracle would have complained.
That's kind of the point isn't it? 1% isn't; a few hundred million is. That's the risk of using percentages: they tend to minimize the significance of the real numbers -- or alternatively, overstate their significance.
If RIM caves, the correct response to this is to divest yourself of any stocks or funds that involve this company. If they cave, it will be because money is more important to them than the refusal to support institutionalized domestic spying, same story as always.
History seems to show that this is a sure indication that it's time to buy RIM stock;)
Except who refers to a program crash as a system crash? This is probably just a case of imprecise reporting , but my point was only that the article as written really didn't have enough information to say for sure -- without making assumptions.
Great! Could you point out where he mentioned the memory dump?
Why no, no you can't. That's because he didn't - or the reporter didn't bother to report it. I'm not saying it's not the case -- it probably is -- but the I *am* saying that RTFA isn't the right answer here because TFA doesn't have the details.
As you pointed out - due to a journalist who didn't know the right questions to ask (or who cared more for the sexier info about how XSS and injection were still popular attacks) we can't be 100% sure but I would agree with what you wrote. The amount of data sent in a crash dump is limited, but sufficient to see the exploit code.
The problem is that they don't specifically say that it was a crash dump. Very good article, BTW - thanks for posting it. I was surprised to find a couple of tidbits in there that I didn't already know on the subject.
Clothiers could set up booths from which to hawk malwear.
Participants ante up some money to compete at writing the best (worst?) malware using an interpreted language. The pooled entrance fees would be placed into the Script Kitty for distribution to the winner.
Not sure why this is modded insightful. RTFA doesn't answer the question, except to say
When the hacker's system crashes in Windows, as with all typical Windows crashes, Heckman said the user would be prompted to send the error details — including the malicious code — to Microsoft. The funny thing is that many say yes, according to Heckman.
it doesn't explain how the "error details" comes to be "including the malicious code". He goes on to say
"People have sent us their virus code when they're trying to develop their virus and they keep crashing their systems," Heckman said. "It's amazing how much stuff we get."
System crash implies a bluescreen - which further implies a memory dump -- but R-ing TFA doesn't answer the question one way or the other.
Because some sound alert is needed. Not everyone can see, out of those people that can see, not everyone can see a car clearly from far enough.
More importantly not everyone can drive. my answer is more drastic though - revoke driving privileges from those who can't pass a yearly competence test that includes dealing with in-car and roadside distractions.
Slashdot Mirror
That's funny because every time there's a massive security problem, it's not a younger programmer at faul
Citation required.
." So in review, for younger programmer, stupid mistakes and software glitches, yes, blatant security holes and generally old technology and methods, no!
Arrogance and belief that as a younger programmer one intuitively knows how to avoid vulnerabilities and poor security practices are far more likely to cause such security holes. such a person might be one of the fraction of a percent of programmers (young or old) who is as good as he thinks he is - but I wouldn't bet my livelihood on it.
There is no substitution for experience - in security matters as well as avoiding stupid mistakes and software glitches.
Do me and my granny a favour and stop bashing Apple for accomplishing what me / you / Ubuntu / Richard Stallman keep failing to accomplish.
I didn't see where GP was doing any bashing at all - he pointed out that they've made usable devices and systems that people like; and that their consumer base is not the geeks who are in an uproar over this. In other words, he was spot on.
are you serious? how do you think the old dynamically linked libraries are updated to run on a vastly different modern multiuser operating system?
Even if a compatibility layer is loaded between the OS and the component, the component and the layer are both running native code - not interpreted. Let's take an extreme situation: you're running a VM. Do you think all of the instructions in the system you run are interpreted by software? Unless it's a software VM architecture, you're not. The code still runs directly on the CPU. The overall performance is not as good because of the additional layers - but ultimately the binary code is not running interpreted. More recently, even software x86 VMs are trending towards the same behavior.
the REAL question is why are YOU talking about interpreted code
Actually the REAL question is this: why are you going on a rabid posting frenzy about this subject, since - by and large - it doesn't appear that you have much knowledge on the subject?
milliseconds of latency on every single executed flash bytecode instruction... billions and billions and billions of them, all of which also require electricity that will be drained from the battery.
If you think that - as a general rule - each opcode in any interpreted platform adds anything close to milliseconds of latency, you probably should call it quits now ;)
show me a flash application that can't be written natively and function better and use less resources.
Nice straw man. Just because something can be written *more* efficiently does not imply a lack of efficiency.
show me a flash application that without it, your phone is useless.
Yeah, much better for your fart apps to be native. What was the point of this statement?
Do you think that if Google didn't call this Java (or more accurately market it as being programmable in Java) that Oracle would be suing at all? Similarly if they had a compliant JVM implementation, I suspect we'd see no law suit.
Yes, seems to be the case. I'm guessing that they went with the Java syntax, packages et al since Java has some of the largest market share.
This was a great troll - I almost fell for it :D
http://developer.android.com/guide/topics/fundamentals.html
The only difference here is that Sun sued over calling something "Java" that wasn't exactly Java. Oracle is doing something a bit deeper in that they are saying that Google can't fork the language even if they call it something different.
I think I've missed something - last I saw, Google isn't calling it something different? If they were, I can't see how this would be a problem. But when I look at the Android Fundamentals page, this is the first thing I see (emphasis added):
Android applications are written in the Java programming language. The compiled Java code — along with any data and resource files required by the application — is bundled by the aapt tool into an Android package, an archive file marked by an .apk suffix. T
So where do you see that they're not calling it Java?
The similarity of android's dev language with Java is only superficial
You mean, aside from the fact that they are exactly the same language and both provide a large number of the same classes in the java.* namespace, they are completely different?
Damn, I'm going to do it -- I'm going to make a car analogy. I'm sorry in advance, because I *know* someone is going to helpfully correct it and take it far beyond the point I was trying to prove.
Let's say all cars had a single engine they used. They could manufacture this engine themselves, but it had to conform to the agreed-upon specs if they wanted to call it a "car engine". So Ford and Chevy and Toyota are all happily marketing cars with Genuine Car Engines; they have different trim and options, but they all use the same Car Engine under the hood.
Suddenly Hyundai comes along with its new line of cars which also uses a Genuine Car Engine. Except - as it turns out - their engine is custom built from the ground up. Its interfaces conform to the Car Engine spec, but internally it functions completely differently. If you dropped a Ford card body onto a Hyundai Car Engine, it wouldn't work at all correctly. The check engine light would play the tune of Old McDonald's and the turn signals would put the car into reverse.
Hyundai's Car Engine is superficially the same as the standard Car Engine, but it doesn't work the same way; nor does it do the same things.
Okay, I may have gotten carried away there. So let's try without the car analogy. The language constructs are the same. Even many classes are shared with the same functionality. However, you cannot execute compiled GoogleJava code on a standard JVM; and you cannot execute standard Java binaries on a Google Car Engine... erm, JVM. This is true even if the source code uses only classes that are shared in common across both platforms.
It'll probably get me modded down, but I don't see this as a Bad Thing. When it comes to core Java systems (excluding GUI) it *is* write once run anywhere as long as you use the standard packages. Not only will it run on any JVM, it will also run in a predictable manner on any JVM (and I think this is one place where Google changes things - the behavior at execution time in some cases). I don't want a trusted vendor such as Google pushing a JVM implementation that is not compliant, yet still continuing to call it Java. Right now, when someone applies for a job as a senior Java developer, everyone knows what it means. When the JVM implementation is no longer standardized, developers start learning implementations instead of the platform -- quite possibly without knowing it.
If use a Java syntax with a custom JVM but called it something other than Java, I don't think Oracle would have complained.
That's kind of the point isn't it? 1% isn't; a few hundred million is. That's the risk of using percentages: they tend to minimize the significance of the real numbers -- or alternatively, overstate their significance.
If RIM caves, the correct response to this is to divest yourself of any stocks or funds that involve this company. If they cave, it will be because money is more important to them than the refusal to support institutionalized domestic spying, same story as always.
History seems to show that this is a sure indication that it's time to buy RIM stock ;)
Yeah, just oddly worded. I'm guessing the reporter got something mixed up.
Except who refers to a program crash as a system crash? This is probably just a case of imprecise reporting , but my point was only that the article as written really didn't have enough information to say for sure -- without making assumptions.
Why no, no you can't. That's because he didn't - or the reporter didn't bother to report it. I'm not saying it's not the case -- it probably is -- but the I *am* saying that RTFA isn't the right answer here because TFA doesn't have the details.
As you pointed out - due to a journalist who didn't know the right questions to ask (or who cared more for the sexier info about how XSS and injection were still popular attacks) we can't be 100% sure but I would agree with what you wrote. The amount of data sent in a crash dump is limited, but sufficient to see the exploit code.
The problem is that they don't specifically say that it was a crash dump. Very good article, BTW - thanks for posting it. I was surprised to find a couple of tidbits in there that I didn't already know on the subject.
Participants ante up some money to compete at writing the best (worst?) malware using an interpreted language. The pooled entrance fees would be placed into the Script Kitty for distribution to the winner.
The possibilities are endless.
amazing FUD
Remember folks, here at Slashdot, asking a question is Fear, Uncertainty and Doubt.
Actually I think he meant Fuzzy Underwear Daemon. But I'm not positive.
When the hacker's system crashes in Windows, as with all typical Windows crashes, Heckman said the user would be prompted to send the error details — including the malicious code — to Microsoft. The funny thing is that many say yes, according to Heckman.
it doesn't explain how the "error details" comes to be "including the malicious code". He goes on to say
"People have sent us their virus code when they're trying to develop their virus and they keep crashing their systems," Heckman said. "It's amazing how much stuff we get."
System crash implies a bluescreen - which further implies a memory dump -- but R-ing TFA doesn't answer the question one way or the other.
wow. double-fail. i quit.
Does it matter? As unfortunate and annoying as it is, you're kind of obligated not to turn them into speedbumps.
d'oh! I was going for +
Because some sound alert is needed. Not everyone can see, out of those people that can see, not everyone can see a car clearly from far enough.
More importantly not everyone can drive. my answer is more drastic though - revoke driving privileges from those who can't pass a yearly competence test that includes dealing with in-car and roadside distractions.