I'm pretty violently opposed to them getting automatic royalties on every HD-DVD player manufactured...
So, do you own a DVD player today? Because there's a ton of royalties that go to the DVD group from that, which coincidentally, is a bunch of companies. So is it just Microsoft you're opposed to getting royalties?
A bit melodramatic, don't you think? You actually believe all that hyperbole you wrote? Are you being "snared" by purposefully downloading property that you have no right to view and yet do so anyway? Clearly, that's entrapment of your upright self.
Oh, and what exactly was your point to all that? Since you (or we, sorry, I forgot you were speaking for society) no longer have respect for the law, there's no reason to follow it? That's a *fantastic* idea. Seriously, anarchy is wonderful, that is, until you get murdered.
Disillusionment with the system is not a justification for breaking its laws. This is a democracy, so why don't you get involved and try to change it? I'm sorry you don't see your actions as a crime, but they are considered as such, so if you knowingly commit them then you should accept the consequences, whether or not you agree with them. That's what's called "civil disobedience", versus what you are doing, which is "trying to justify what I know is illegal but still believe I should suffer no repercussions."
I'll grant you the first point that closed source software certainly has the potential for vastly wider distribution of said malicious code. However, on what basis would you say that screening is far worse in proprietary software? I don't think it's particularly fair to use ancedotal evidence. The amount of proprietary software that has shipped over the years relative to open source or free software is absurd. It's like comparing apples to orange groves.
Okay, after reading through both the respone and the replies here on Slashdot I can honestly say that the vast majority of you are missing the point of the original article.
Yes, it's true that closed, proprietary software can have malicious code introduced into them just as well as free software. But part of the original argument is that the barrier to entry to creating your own distribution of project X is extrememly low, probably even close to zero (the author never said this explicitly, but I think it was implied). So while, yes, closed systems could get infected, too, there is an underlying assumption that proprietary software has stricter screening of its employees for just such a reason. There is no screening in free software; it's basically a free-for-all.
Also, I see a lot of responses saying varying degrees of "geez, they can just verify their binaries/source trees!". Well, once again, this is the classic Linux naivete of assuming too much on the part of the user. Sure, if we're talking about highly sensitive software then there will presumably be some auditing mechanism to make sure the software is legit. However, to assume that everyone has ready access to intelligent programmers to verify all their computer purchasing decisions is rather absurd, especially in the lower levels of government.
In short, I didn't think the response was really responding to the argument at all. Of course closed software can have the same backdoors! But did the author even stop to ponder, "Hey, I wonder why he might have singled out free software as being more vulnerable? Hmmm, no reason I can think of!"
Well, isn't that just the problem? You're speaking from your experience to make that connection, but not from any systematic evidence. That does not make this a good metric unless you can prove its a good metric. And personally, I would say that it's not a good metric; it does not account for bad design, for one. For another thing if you already have a flow analysis tool like the ones this study used than you will catch all these errors; does this imply that you code has no larger algorithmic mistakes? Undoubtedly not.
The review does point out that video performance is bad, but I think they missed the point there. The video is being rendered on the client side (i.e. your desktop) and only the graphics are being transmitted over the network. As such, it doesn't matter which protocol you use (VNC, RDC, remote X Windows) it's pretty difficult to get decent performance in such a setup. I'm actually suprised it can play any video at all. The bandwidth needed to transmit that kind of data is just not available.
Anyway, the point is that everything you do is being rendered/processed on the client side, which should theoretically make the display very lightweight in terms of hardware and therefore cheaper than a laptop. Unfortunately, I think Viewsonic missed the price point they were aiming for. If this thing were cheaper it would rock, as it stands now you might as well buy an inexpensive laptop.
If you say so. But do go back and read your original reply. It was just as vague and flame-bait worthy as my response back to you. If you had been clearer I would have responded in kind.
Man, for me being the troll, you're pretty incendiary. First of all, I did read the article, and I know it was pretty against MS, but I didn't point that out because Slashdot is pretty anti-MS site to begin with, so objective pretty much equals against MS here. But besides with, doesn't that make the quote I pulled from it that much stronger? How exactly does quoting a pro-MS statement from an anti-MS article make it have less validity?
Secondly, you're just plain wrong on security and permissions. Clearly you don't believe me, and you don't even believe anti-MS articles that I quote to you, so go look it up your damn self at this point. Windows file permissions are more flexible. You can argue about defaults and usability all you want, but the original point was about features, and the Windows permissions system is more feature-rich.
Lastly, you are right on the NOS side. I was not really trying to imply that the OSS world does not have a fully integrated NOS, although it did come off that way. Rather, I was trying to say that the Windows version (AD) is more feature-rich than anything on the OSS side. I still stand by that assertion.
Way to illustrate my point exactly. You are definitely in denial. I can help. Here's a quote from a fairly objective paper I found on Google and File and Directory Security:
Standard UNIX file and directory security is very limited compared to Windows NT flexible access control list capabilities.
It's pretty well known that the NTFS/Windows is more flexible and more granular than the Unix model. What were you saying about ignorance?
Also, with regard to the fully integrated NOS comment, I have no idea what it is you're taking issue with. How exactly is a Windows client not fully integrated into AD with security and the like?
The flip side of that is if Microsoft has all this money why doesn't Windows have all the features of Linux? No need to flame you.
The short answer is: because they don't make money. But it's a good point. I guess it works both ways: motivating workers either way will result in a different set of features, since the driving force behind them is different.
Well, do your Windows "testers" even know how to use Linux?
Forgive me, I fail to see the relevance of this statement.
If capitalism is such a good model for society and promotes competition then why doesn't Windows have more competition besides Linux? Linux isn't even trying to make money yet. Its still ramping up.
Short answer: it's either because Windows is good enough for most people, or because the costs of displacing it are too high for any significant competition. But those are really irrelevant. What does this have to do with why Linux is not feature-complete (IMO) with respect to Windows? Or the price of tea in China, for that matter?
I think MS has done pretty well imitating the "failed central planning models of Soviet Russia". Revile them all you like, I don't think failure would be the appropriate word to describe them.
I'm well aware of the difference between kernel level work and application work. The MP3 comment was just supposed to be funny. The same still applies, though, even if you look at the whole picture; Linus can't make anyone work on anything (Kernel or Application level, makes no difference) they don't want to. And even if he likes tedious work, as you claim, that's still just one person and not this vast web of resources as the author claims.
Alright fine, fair enough. How about a fully featured security model with rights, privileges, ACLs, etc.? Obviously Linux does have a security model, but it doesn't stack up feature-wise. How about a fully functional NOS integrated with security? OpenLDAP doesn't count; it's just a directory. Granted, these aren't really pure OS features, but they would certainly need OS support that isn't there today.
Keep in mind I'm not begrudging Linux at all. But to try to claim that the OSS world has everything that Windows has is pure fantasy. Never mind the fact that usability on the Windows side is generally better. Denial is not the answer...
This article is pure fluff. It makes a populist statement ("Linus has more resources! Yay!"), and then does absolutely nothing to back it up. Here's just a few of the glaring oversights he failed to address:
-The most obvious one: If Linux has so many more resources, than why doesn't it have all the features of Windows already? Flame me all you want, but it doesn't.
-Even though Linus has "the millions who use Linux and continue to tinker with it", in reality there are very few contributors (definitely not millions). Windows also has a larger installed base and thus a larger possible base of testers. How does that factor in?
-It neglects the fact that Linus's disadvantage solely as a gatekeeper, instead of director, is that unpopular, tedious, but necessary work might never get done. One advantage of motivating with money is that you can force people to do work they might not otherwise elect to do. I mean, how many MP3 players does Linux need?
-I don't think BillG has any trouble sleeping at night. Linux might be a threat to his company, but it's not going to make him a lowly multimillionaire any time soon.
I am not convinced that most of the spam comes from specialized email applications that can be fooled with a temporarily failure. Can anyone provide numbers on this?
Well, the article found that 95% of all spam was successfully blocked this way. Assuming the mail server he tried it on gets a representative sample of spam at large, then this would appear to be true.
I see a lot of spam that was probably produced by applications that use an automated signup to yahoo/hotmail/etc. to obtain a temporary email address and leave the actual emailing to those services which will circumvent 'greylisting'.
I highly doubt that many spammers do this. Both Hotmail and Yahoo limit the number of emails you can send in a 24 hour period (I think it's around 100-150). And each recipient in the same email counts against that limit, so it would be impraticable for any spammer to use those services as a result.
How much of the total internet traffic is made up of email? What happends of we all install 'greylisting' filters and each email has to be resent several times? Is doubling/tripling the amount of email traffic going to be noticable?
This does seem like a big issue. However, remember that this behavior is only employed when the "triplet" has not been seen before. So any emails along previously traveled paths would not have to be resent. It would be interesting to know what percentage of traffic was a new triplet versus a recognized one after the initial start-up period of greylisting.
Jesus Chr*st that is NOT captialism. MS being an monopoly CANNOT sell it's products for $1 each in order to keep competitors from entering its market. That is illegal plain and simple.
Okay, so first of all if this story is true MS is NOT selling XP for $1. They are selling it for $50, which, if you keep up on their public finances, is still well below their costs (aren't the margins in software great?). Selling a product at a lower price but still above your cost would, IMO, be considered the result of capitalism and competition and therefore be a good thing.
In any case, by the capitalism argument everyone should be disallowed from giving away Free Software ever. It certainly doesn't cost nothing to make, it simply that the makers of it donate their time. Talk about giving away a product to stop competitors from entering its market! If Linux dominated there'd be no possible way to enter the market. Then where's your competition?
Completely Irrelevant
on
Hijacking .NET
·
· Score: 5, Insightful
Oh for god's sakes people, this is just dumb. There's no real reason to take the performance hit and enforce this at run-time, because the protection of private member variables are there for your benefit. If you want to access undocumented variables that were never meant to be exposed, you're just asking for bugs and future incompatibility.
Oh, and BTW, this has nothing to do with actual security. Relying on access level specifiers to protect sensitive data in memory is lunacy. The standard coding technique for dealing with things like passwords is to keep them around for as short a period of time as possible and then overwrite that memory afterwards with random bits. If you're storing them long term cleartext in memory then you've got bigger problems.
How can they even know the rate of bugs in the code? It mentions automated defect detection software. If this is their benchmark, I am extraordinarily skeptical.
Windows is not explicitly included in their list of OSs. Gee, one would think that in order to laud the relative merits of open-source, it would be prudent to compare it to the most popular closed source one around. Just maybe?
They used the TCP/IP stack as the testing grounds. As most everyone knows, the TCP/IP stack in Linux is descended directly from the BSD stack, probably one of the oldest, most stable implementations around. It would be a lot more meaningful to do this comparison on some part of the OS that has a lot of churn, rather than one that is relatively fixed for a long period of time.
I smell ridiculous claims and baseless conclusions.
There is only one company that has every sold a VLIW chip that actually worked, and that people bought: TI makes DSPs, where are VLIW. They make tons of money. They are the only ones that ever did it right.
Your point being? Wouldn't that be incentive to get into VLIW, since they make a ton of money?
Essentially, until the science of compilers takes a quantum leap or we start using programming languages that makes these things easier (correct me if I'm wrong, please), Itanium will be at most as fast as a superscalar processor that finds independent instructions on its own and does register renaming.
You're oversimplifying the situation. There are very significant and obvious gains to be made by making these changes. First, compilers are more than fully capable of taking advantage of this and do so. There IS a lot of room for improvement, but considering the burden of responsibility the compiler now shoulders that's to be expected. And I don't know where you get the idea that it's an "open question" that the compilers work correctly; you seem to have quite a bit of cynicism on this topic for no particular reason at all. I have heard absolutely nothing about compilers not being correct or not being able to find parallism in the code.
Secondly, (here is where I will correct you b/c you ARE wrong) the Itanium CAN do a better job of scheduling than a normal superscalar processor with register renaming. The reason is just as you said: all the dependency checks are done at compile-time instead of at run-time. The processor is obviously bound by the amount of dependency checking logic and the number of instructions it can process at a time. The farther ahead you look, the more logic you need, and costs rise exponentially.
Doing it in software clearly alleviates this problem. All the parallelism can be extracted from a piece code ahead of time regardless of the hardware. Of course, there is a theoretical limit to the amount of instruction level parallelism (ILP) that can be extracted from any code, which is where predicates come in...
...its not entirely more useful IMHO, or at least that was my impression the last time I heard someone talk about it. Alpha has conditional execution. ARM has conditional execution. I can append checks to the condition codes in ARM assembly. I don't really understand why this is so nifty.
While conditional and predicate execution are based on the same concept, predicates are far more useful. Conditional execution is usually very, very limited in the amount of "speculation" it can do, and most conditional execution instructions force you to embed the condition inside the instruction itself. On many architectures, conditional execution are only supported on a few instructions, like a conditional MOVE.
For predicated instructions, however, you have a whole new ballgame. First off, just about every instruction can be predicated, as opposed to the limited set of conditionals you can use. On top of that, there are 64 (or 128? Someone correct me?) predicate registers in the Itanium that can be used AND SAVED for predication. This means that the processor can theoretically be speculatively executing 64 (or more?) branches of code at the same time. All the compiler has to do is to assign a different predicate register to each branch and issue predicated instructions for each branch. Now in practice this many branches are not predicated, but you get the idea; using predicates you can let the processor go nuts and start scheduling instructions far, far ahead. With conditionals, you may be able to hurdle a branch or two, but only if the branches are very small and all the instructions in them can be conditional instructions.
What this effectively does is almost completely eliminate the branch prediction penalty, which by many estimates accounts for almost 30% of processor time. In fact, this penalty is getting worse with today's processors; think about the P4, which has a 19(!) stage pipeline. When the branch prediction unit (BPU) is incorrect, think about how many instructions have to be backed out and reissued from the correct branch! It's no wonder that it's such a performance hit. On top of this, as I alluded to before, it lets the processor read much farther ahead to try to extract parallelism. Since most branches are taken care of with predicates, there's no need to wait (or even check for) dependencies; it can keep issuing instructions until it runs out of registers to schedule.
The article is woefully absent with real quotes from the school in context, but at one point it mentions about 30 lines of code in common with someone else. As I'm sure all of us coders here on Slashdot know, 30 lines of code is not a coincidence. In fact, it's extremely likely to be copying one way or the other. If you had 30 lines, or hey, even 30 words the same with someone else's English paper, it wouldn't even be a question whether plagarism occured. Assuming this is the case, it's not even debatable. The student should consider himself lucky for not getting a XF (failure due to academic dishonesty).
This entire post is ridiculous. If the situations were reversed between Sony and MS, the article would be decrying Microsoft's unfair practices of distracting people and applauding Sony. Either way, it's not news.
1) That's a good thought, but utterly incorrect. If you read the settlement, Sun did not push to get MS to follow the standard; they sued to get them to lose their license to distribute a JVM. They succeeded. MS was found guilt of copyright infringement. This IS what Sun wants, but they want THEIR JVM distributed in its place, which is pretty crybaby and ludicrous if you ask me. It's not their right to get their products distributed with Windows.
Slashdot Mirror
Oh, and what exactly was your point to all that? Since you (or we, sorry, I forgot you were speaking for society) no longer have respect for the law, there's no reason to follow it? That's a *fantastic* idea. Seriously, anarchy is wonderful, that is, until you get murdered.
Disillusionment with the system is not a justification for breaking its laws. This is a democracy, so why don't you get involved and try to change it? I'm sorry you don't see your actions as a crime, but they are considered as such, so if you knowingly commit them then you should accept the consequences, whether or not you agree with them. That's what's called "civil disobedience", versus what you are doing, which is "trying to justify what I know is illegal but still believe I should suffer no repercussions."
I'll grant you the first point that closed source software certainly has the potential for vastly wider distribution of said malicious code. However, on what basis would you say that screening is far worse in proprietary software? I don't think it's particularly fair to use ancedotal evidence. The amount of proprietary software that has shipped over the years relative to open source or free software is absurd. It's like comparing apples to orange groves.
Yes, it's true that closed, proprietary software can have malicious code introduced into them just as well as free software. But part of the original argument is that the barrier to entry to creating your own distribution of project X is extrememly low, probably even close to zero (the author never said this explicitly, but I think it was implied). So while, yes, closed systems could get infected, too, there is an underlying assumption that proprietary software has stricter screening of its employees for just such a reason. There is no screening in free software; it's basically a free-for-all.
Also, I see a lot of responses saying varying degrees of "geez, they can just verify their binaries/source trees!". Well, once again, this is the classic Linux naivete of assuming too much on the part of the user. Sure, if we're talking about highly sensitive software then there will presumably be some auditing mechanism to make sure the software is legit. However, to assume that everyone has ready access to intelligent programmers to verify all their computer purchasing decisions is rather absurd, especially in the lower levels of government.
In short, I didn't think the response was really responding to the argument at all. Of course closed software can have the same backdoors! But did the author even stop to ponder, "Hey, I wonder why he might have singled out free software as being more vulnerable? Hmmm, no reason I can think of!"
Well, isn't that just the problem? You're speaking from your experience to make that connection, but not from any systematic evidence. That does not make this a good metric unless you can prove its a good metric. And personally, I would say that it's not a good metric; it does not account for bad design, for one. For another thing if you already have a flow analysis tool like the ones this study used than you will catch all these errors; does this imply that you code has no larger algorithmic mistakes? Undoubtedly not.
Anyway, the point is that everything you do is being rendered/processed on the client side, which should theoretically make the display very lightweight in terms of hardware and therefore cheaper than a laptop. Unfortunately, I think Viewsonic missed the price point they were aiming for. If this thing were cheaper it would rock, as it stands now you might as well buy an inexpensive laptop.
This can just as easily be said about features in the OSS world.
Okay, your opinion may be different, but recognise it for what it is: a personal opinion.
True, but no more so than the author's original statement that Linus sleeps better at night than Bill. They're both garbage statements.
If you say so. But do go back and read your original reply. It was just as vague and flame-bait worthy as my response back to you. If you had been clearer I would have responded in kind.
Secondly, you're just plain wrong on security and permissions. Clearly you don't believe me, and you don't even believe anti-MS articles that I quote to you, so go look it up your damn self at this point. Windows file permissions are more flexible. You can argue about defaults and usability all you want, but the original point was about features, and the Windows permissions system is more feature-rich.
Lastly, you are right on the NOS side. I was not really trying to imply that the OSS world does not have a fully integrated NOS, although it did come off that way. Rather, I was trying to say that the Windows version (AD) is more feature-rich than anything on the OSS side. I still stand by that assertion.
The Windows model is more flexible and gives you more granularity with permissions. Or are you trying to display your vast knowledge of NTFS ACLs?
Standard UNIX file and directory security is very limited compared to Windows NT flexible access control list capabilities.
It's pretty well known that the NTFS/Windows is more flexible and more granular than the Unix model. What were you saying about ignorance?
Also, with regard to the fully integrated NOS comment, I have no idea what it is you're taking issue with. How exactly is a Windows client not fully integrated into AD with security and the like?
The short answer is: because they don't make money. But it's a good point. I guess it works both ways: motivating workers either way will result in a different set of features, since the driving force behind them is different.
Well, do your Windows "testers" even know how to use Linux?
Forgive me, I fail to see the relevance of this statement.
If capitalism is such a good model for society and promotes competition then why doesn't Windows have more competition besides Linux? Linux isn't even trying to make money yet. Its still ramping up.
Short answer: it's either because Windows is good enough for most people, or because the costs of displacing it are too high for any significant competition. But those are really irrelevant. What does this have to do with why Linux is not feature-complete (IMO) with respect to Windows? Or the price of tea in China, for that matter?
I think MS has done pretty well imitating the "failed central planning models of Soviet Russia". Revile them all you like, I don't think failure would be the appropriate word to describe them.
I'm well aware of the difference between kernel level work and application work. The MP3 comment was just supposed to be funny. The same still applies, though, even if you look at the whole picture; Linus can't make anyone work on anything (Kernel or Application level, makes no difference) they don't want to. And even if he likes tedious work, as you claim, that's still just one person and not this vast web of resources as the author claims.
Keep in mind I'm not begrudging Linux at all. But to try to claim that the OSS world has everything that Windows has is pure fantasy. Never mind the fact that usability on the Windows side is generally better. Denial is not the answer...
-The most obvious one: If Linux has so many more resources, than why doesn't it have all the features of Windows already? Flame me all you want, but it doesn't.
-Even though Linus has "the millions who use Linux and continue to tinker with it", in reality there are very few contributors (definitely not millions). Windows also has a larger installed base and thus a larger possible base of testers. How does that factor in?
-It neglects the fact that Linus's disadvantage solely as a gatekeeper, instead of director, is that unpopular, tedious, but necessary work might never get done. One advantage of motivating with money is that you can force people to do work they might not otherwise elect to do. I mean, how many MP3 players does Linux need?
-I don't think BillG has any trouble sleeping at night. Linux might be a threat to his company, but it's not going to make him a lowly multimillionaire any time soon.
What a bunch of cheerleading.
Okay, so first of all if this story is true MS is NOT selling XP for $1. They are selling it for $50, which, if you keep up on their public finances, is still well below their costs (aren't the margins in software great?). Selling a product at a lower price but still above your cost would, IMO, be considered the result of capitalism and competition and therefore be a good thing.
In any case, by the capitalism argument everyone should be disallowed from giving away Free Software ever. It certainly doesn't cost nothing to make, it simply that the makers of it donate their time. Talk about giving away a product to stop competitors from entering its market! If Linux dominated there'd be no possible way to enter the market. Then where's your competition?
Oh, and BTW, this has nothing to do with actual security. Relying on access level specifiers to protect sensitive data in memory is lunacy. The standard coding technique for dealing with things like passwords is to keep them around for as short a period of time as possible and then overwrite that memory afterwards with random bits. If you're storing them long term cleartext in memory then you've got bigger problems.
How can they even know the rate of bugs in the code? It mentions automated defect detection software. If this is their benchmark, I am extraordinarily skeptical.
Windows is not explicitly included in their list of OSs. Gee, one would think that in order to laud the relative merits of open-source, it would be prudent to compare it to the most popular closed source one around. Just maybe?
They used the TCP/IP stack as the testing grounds. As most everyone knows, the TCP/IP stack in Linux is descended directly from the BSD stack, probably one of the oldest, most stable implementations around. It would be a lot more meaningful to do this comparison on some part of the OS that has a lot of churn, rather than one that is relatively fixed for a long period of time.
I smell ridiculous claims and baseless conclusions.
While moving with the people first, we contribute to our creative cultures and the compilation and development of prediction of entertainments.
Yes, yes, I see now.
Your point being? Wouldn't that be incentive to get into VLIW, since they make a ton of money?
You're oversimplifying the situation. There are very significant and obvious gains to be made by making these changes. First, compilers are more than fully capable of taking advantage of this and do so. There IS a lot of room for improvement, but considering the burden of responsibility the compiler now shoulders that's to be expected. And I don't know where you get the idea that it's an "open question" that the compilers work correctly; you seem to have quite a bit of cynicism on this topic for no particular reason at all. I have heard absolutely nothing about compilers not being correct or not being able to find parallism in the code.
Secondly, (here is where I will correct you b/c you ARE wrong) the Itanium CAN do a better job of scheduling than a normal superscalar processor with register renaming. The reason is just as you said: all the dependency checks are done at compile-time instead of at run-time. The processor is obviously bound by the amount of dependency checking logic and the number of instructions it can process at a time. The farther ahead you look, the more logic you need, and costs rise exponentially.
Doing it in software clearly alleviates this problem. All the parallelism can be extracted from a piece code ahead of time regardless of the hardware. Of course, there is a theoretical limit to the amount of instruction level parallelism (ILP) that can be extracted from any code, which is where predicates come in...
While conditional and predicate execution are based on the same concept, predicates are far more useful. Conditional execution is usually very, very limited in the amount of "speculation" it can do, and most conditional execution instructions force you to embed the condition inside the instruction itself. On many architectures, conditional execution are only supported on a few instructions, like a conditional MOVE.
For predicated instructions, however, you have a whole new ballgame. First off, just about every instruction can be predicated, as opposed to the limited set of conditionals you can use. On top of that, there are 64 (or 128? Someone correct me?) predicate registers in the Itanium that can be used AND SAVED for predication. This means that the processor can theoretically be speculatively executing 64 (or more?) branches of code at the same time. All the compiler has to do is to assign a different predicate register to each branch and issue predicated instructions for each branch. Now in practice this many branches are not predicated, but you get the idea; using predicates you can let the processor go nuts and start scheduling instructions far, far ahead. With conditionals, you may be able to hurdle a branch or two, but only if the branches are very small and all the instructions in them can be conditional instructions.
What this effectively does is almost completely eliminate the branch prediction penalty, which by many estimates accounts for almost 30% of processor time. In fact, this penalty is getting worse with today's processors; think about the P4, which has a 19(!) stage pipeline. When the branch prediction unit (BPU) is incorrect, think about how many instructions have to be backed out and reissued from the correct branch! It's no wonder that it's such a performance hit. On top of this, as I alluded to before, it lets the processor read much farther ahead to try to extract parallelism. Since most branches are taken care of with predicates, there's no need to wait (or even check for) dependencies; it can keep issuing instructions until it runs out of registers to schedule.
The article is woefully absent with real quotes from the school in context, but at one point it mentions about 30 lines of code in common with someone else. As I'm sure all of us coders here on Slashdot know, 30 lines of code is not a coincidence. In fact, it's extremely likely to be copying one way or the other. If you had 30 lines, or hey, even 30 words the same with someone else's English paper, it wouldn't even be a question whether plagarism occured. Assuming this is the case, it's not even debatable. The student should consider himself lucky for not getting a XF (failure due to academic dishonesty).
This entire post is ridiculous. If the situations were reversed between Sony and MS, the article would be decrying Microsoft's unfair practices of distracting people and applauding Sony. Either way, it's not news.
1) That's a good thought, but utterly incorrect. If you read the settlement, Sun did not push to get MS to follow the standard; they sued to get them to lose their license to distribute a JVM. They succeeded. MS was found guilt of copyright infringement. This IS what Sun wants, but they want THEIR JVM distributed in its place, which is pretty crybaby and ludicrous if you ask me. It's not their right to get their products distributed with Windows.
2) Another good thought, but also incorrect.