The fact that the CalTech group got a lot of improvement from their implementation is good real-world evidence that your analysis is probably off, since they don't halve their TX rate and they achieved significantly better throughput.
The reason I think it's off (I think this is a pretty good explanation, but there may be others) is that Internet traffic is bursty. You're not continually pouring packets into routers' buffers -- you're pumping large amounts of packets in, waiting a relatively long time, and then pumping packets back in again. That period of time in between bursts is more than enough time to clear out the buffer.
It's more like pouring one bucket of sand into a funnel, waiting for it all to flow out, and then pouring in two buckets of sand. Eventually, you overflow the funnel with 10 buckets of sand, but you don't need to go back to pouring in 5 buckets.
Okay, I'm graduating in 4 hours so I think it's a wise time to go to bed...
This is stretching my certainty (I'm recalling all of this from a sophomore year CS networks class and I've been overwhelmed by booze in my graduating week), but here's a stab at this...
I don't think that having a long RTT (round-trip time) will have a huge effect on transmission rate in the standard TCP case. Internet traffic, if I remember correctly, is bursty (cite), meaning that a typical transmission looks like:
SEND 32 PACKETS RECEIVE 32 ACKS
SEND 36 PACKETS RECEIVE 36 ACKS
SEND 40 PACKETS RECEIVE 38 ACKS
(oops! Sent 2 more than I could! Halve TX window!)
SEND 20 PACKETS RECEIVE 20 ACKS
etc. In this case it's easy to see why having a long RTT doesn't slow things down particularly, since there can be a big gap between the SEND and RECEIVE and nothing changes.
In the case of non-bursty traffic, I don't think large RTT causes a big problem for normal TCP either. This is because even with a large RTT (if it takes 400 ms to go from sender to host, for example) ACKS will still be streaming in at a constant, if slower, rate, allowing for more packets to be sent out (this is more subtle to explain, so you might want to google more for a better explanation).
I think the reason you misunderstand this is because the New Scientist article makes it sound like you send a packet, then receive an ACK, then send one, etc. This is not the case -- you send lots of packets together...this is the principle behind the "window", that you can send out more than one packet at a time without receiving an ACK because you've been successful at that so far.
FYI, I looked up MCI's traffic times and found that transatlantic latency is roughly 80ms compared to 45ms for within-US traffic (cite). This is non-trivial, but also not huge.
If anybody disagrees with this assessment, please feel free to correct, since as I said, I'm not 100% sure that increased RTT doesn't mean lower window size.
Also, from my reading a lot of the gain was simply in the fact that halving a throughput rate of 800K/sec means you're dropping to 400K/sec when realistically you should probably only be dropping a little bit. According to NS, they improved by more than two-fold, but that's probably just because normal TCP doesn't often get to the actual max of the network, it may burp a lot on the way up and dip more than halfway than its reasonable max.
FYI, a great website for understanding how TCP congestion control works is here. It explains how TCP additively increases its window size as traffic goes through okay but then halves its window size when it runs into a problem.
And I should clarify my first post as well by explaining what a "transmission error" is that would cause the window size to halve. From the article above:
It is rare that a packet is dropped because of an error during transmission. Therefore, TCP interprets timeouts as a sign of congestion, and reduces the rate at which it is transmitting.
Basically, what I mean by a "transmission error" is a timeout -- the sender sends a packet and never gets an ACK for it. TCP works on the premise that packets are mainly dropped when congestion is high enough for routers to drop packets because of maxed buffers. Thus it makes sense to reduce transmission rate when no ACK is received to adjust to the capacity of the network.
I see this as a way to transmit corrupted files, not a way to speed up the internet experiance as a whole.
Without trying to be mean, you see it that way because you don't understand what's going on (mostly because the post was misleading). Fast TCP packets will still have a checksum and everything, so you're not going to get corrupted files. The change here is that normal TCP halves its "window size", or the amount of info that's out on the network at once without receiving an acknowledgement of receipt, with each error. This means that if there's one minor slowdown when 10 packets are currently out from your computer to the recipient (you've put out 10 packets without getting an ACK back yet), then your computer will reduce its window size and only allow 5 packets to be out at a time, effectively halving the transmission rate. Since TCP continually tries to get faster, it will always hit a bottleneck, resulting in your connection vacillating between optimal speed and half of that (approximately, I guess it might be worse than this on high-speed networks based on what I've read here).
In Fast TCP, they do this "congestion control" in a different way. Rather than halving the connection speed with every slowdown to ensure stability, they send as much data as possible as long as the network seems clear on the recipient's end (I think they estimate this with round-trip time of some sort).
So the "error checking" being changed by Fast TCP is NOT bit checking -- it's transmission rate checking. You'll still always get your files intact.
does show that Novell retains the rights to all the UNIX patents and copyrights
Ahh, but the point of the article is that the contract is much more complicated than this. People will read your post and think "see, there, SCO does not own the IP, there is no case." But the article goes to great lengths to show that SCO may have the right to ENFORCE the copyright even if they don't have the copyright itself. This admittedly seems odd, but I don't see why it wouldn't be possible, in which case SCO would be able to sue everybody's pants off and legally reap the benefits of the copyright without technically holding it:
For example, while the contract leaves the copyrights with Novell, a section that gives to SCO "all claims...against any parties relating to any right, property or asset included in the (Unix) business" could be interpreted to give SCO the right to enforce the copyright, Radcliffe said. "The question is, even though (Novell) didn't assign the intellectual property (to SCO), did (Novell) assign the rights to enforce the patents and copyrights?"
Think about this for a second...would AOL, a huge company with lots of lawyers, EVER buy a company the size of Nullsoft and allow that company to own its IP and control its own software releases? I highly doubt it. It certainly appears from the statement on their website that this is the case, and unless we hear otherwise, we should assume that it is or risk being sued.
Taking drinks from a club, even though the club is private, is indeed clearly illegal. But we're talking about a private SPACE with its own private RULES about the world, which just can't be regulated by public law (except by a EULA, as you point out, but even then you probably can't punish the guy much).
And your example of going to college doesn't hold water. If I disrupt classes at my college, they can kick me out, but they certainly can't prosecute me in criminal court. This is because college has its own private rules about how things run, and if you break them you can be kicked out, but you can't be criminally punished. Nobody has ever gone to jail for violating a school's code of conduct (unless the behavior that violated the school's code also happens to violate the common code).
I'm not against slapping the shit out of these guys -- if I had my character messed up by them I'd kick their asses, too. I'm just saying they shouldn't be liable under any sort of state or federal law for messing with people's game characters.
Okay, so I was too harsh in saying you're computer obsessed. But I still think that game servers are private, not public like you claim. They're run by a private corporation and you need to pay this corporation to get access to it. Just because they're large and have lots of subscribers doesn't make them public and government-regulatable.
It's kind of like...if you break into Microsoft's fileservers, changing the names of all of the files you find probably isn't illegal, but the act of hacking into the server may be. It's illegal to break into a system (crack it, whatever), but if you're already in a private space then breaking the intentions of that space is way too vague to be illegal.
If I see somebody drop $100, is it a crime to pick it up and walk off with it?
My guess is this isn't a crime, even if it may be unethical, but IANAL. Of course, I'm talking from an American point of view, so I don't know about elsewhere.
If I see a door open to a warehouse I *KNOW* I'm not supposed to be in, is it a crime to walk in and take a couple High-Def TVs?
Yeah, that's called trespassing and larceny. Somehow I don't think any states would call acquiring GM powers without authorization trespassing.
If I see a gun just lying around, is it a crime for me to shoot people with it? I mean, it's not my gun.
Yeah, that's called murder. Last time I checked my state (MA) doesn't think killing a game character is murder.
So why is it so unusual that manipulating private software, even if the entry point is public and easily accessible, should be a crime? Why should we expect the virtual "world" to be any different, especially considering that it's much more anonymous and therefore much more enticing to break the law?
You need a serious dose of Real Life, man. The reason private spaces are PRIVATE is because government should not be regulating them. Do you really think that there should be a law against fraud in a Dungeons and Dragons game because the same unethical boundary was crossed in the private space of your basement? This kind of regulation would be a crazy encroachment upon our freedoms. And how would you define what's "right" and "wrong" behavior in a private space? Clearly, becoming a false God in the game was not intended, but where do you draw the line? Would the game publishers need to publish a list of every Acceptable Behavior? Clearly there could be no global standard -- killing may be against the standards of one community (The Sims) and not another (Vice City).
The bottom line is that a private Game World is simply not the same as the Real World, nor should they be regulated in a similar fashion. Stop conflating games and reality and get out a bit.
Forcing people to produce a working prototype before they could get a patent would mean that the people who can spend millions of dollars on fabrication equipment would be in control. Fabrication companies would never let people fabricate a prototype unless the inventors gave up some rights to it. This would obviously be a broken system, since it would take the power away from the inventor and give it to some random suit who owns a machine shop.
"Sometimes those interfaces aren't all that fresh"? Please, try posting something other than completely subjective blather.
Yes, Win95 wasn't the end of MS/DOS, but WinNT pretty much WAS the end of MS/DOS. Of course not completely, but grandfathering old macrokernel code was overshot by the desire for a non-shitty microkernel. Just the same,.NET is a substantial departure from COM...it puts much more focus on interchangeable code, interoperability, and a run-time environment rather than a hack of an inter-program communication system. They are different beasts, despite your witty rhetorical questions.
Actually, the US Supreme Court recently ruled that cross burning is, in fact, illegal.
But the supporting opinions agreed that it should be illegal because it is a form of intimidation, and I don't think anybody believes that a presentation on the security flaws of a popular transaction system is intimidating...just dangerous to a certain corporation.
Your comment is spoken from the point of view of somebody who runs a website with a small to moderately sized, simple database.
So that's great, you blog well in PHP, but you utterly overstate the power of MySQL. MySQL will not even approach taking on the big database apps until they have a) subqueries and b) true ACID support. Many complex websites have stored procedures with subqueries in them, and it's logistically impossible for these sites to migrate to MySQL, since it would involve rewriting anything with a subquery (if it's possible at all without nasty temp table hacks).
And not having ACID (atomicity, consistency, isolation, and durability, btw) support? No enterprise-level website, especially one that does eCommerce, would ever think of running a database without proper transactions.
So, yeah, MySQL is great at handling small- to mid-size loads, but once you get to high complexity or you need transactions, it's over. Maybe if they include this stuff in version 4 and it survives a couple of years of testing, THEN we might see some significant migration, but it will not happen until then.
But then you're not charging people if they're an incoming warez server, or they congest your network downloading mp3s.
When I thought of getting a burstable line from Digex, their billing process was to bill my incoming/outgoing data rate based on my peak usage EXCLUDING the top 10% of our usage time. That way if there's a usage spike (or a SQL Slammer spike), then it would be considered an anomaly and wouldn't be billed for. That seems like a rather fair system for me, since there's no real way to distinguish wanted traffic from unwanted traffic and bill based on that.
Schedulers are run every time you switch processes, which happens quite a few times a second (every time you move the mouse the window manager needs to update the mouse position, if that helps you understand how frequently this happens). As a result, a scheduler that takes, let's say, a tenth of a second to compute the next process it wants to run will lag.1 seconds every time you move your mouse. This is beyond unacceptable for even a casual workstation.
So, basically, if you could find a way to use fancy statistical methods in a couple of lines of code, you'll be a very famous man. The amount of simplicity many systems use is something like this:
Did the current process use its entire time slice? If yes, lower priority; if no, raise it.
Loop through the priority queues and pull out the first proc we see, return it
Done
(of course, this is only one popular algorithm, but it doesn't get much more complicated than that AFAIK)
The original poster said "If as many people tried as hard to find security holes in OSX or Linux, there'd be reports for those daily as well" and you countered with that article on mi2g.
What does that article say? It says "Based on the number of vulnerabilities announced in 2002 that affect operating systems..."
Now, either I'm an idiot or that article is basing its results on REPORTED VULNERABILITIES. Might the number of reported vulnerabilities have something to do with how hard people ARE LOOKING FOR VULNERABILITIES?
The ONLY way to test the relative vulnerability of an OS is to do a thorough code review of each, or send experts on each into a room and ask them to find exploits (and both approaches won't even be that accurate).
ASP.NET is "a compiled.NET Framework-based environment" (from gotdotnet.com) -- so basically it's a subset of the Framework with its own quirks like.aspx files that automatically compile. To illustrate this point, Response.Write() from ASP has turned into System.Web.HttpResponse.Write() in ASP.NET. So all of ASP.NET's functionality is in the global namespace, and ASP.NET can access the rest of the namespace hierarchy like any other program.
Also, the entire.NET Framework is designed with XML-based services in mind, not just ASP.NET. Most (all?) classes can be serialized and passed around to be discovered by reflection.
Focus on vertical industries only, in areas and industries where this type of devices are commonly used.
While Microsoft is hyping the technology globally, they are marketing primarily to "knowledge workers" right now, as you suggest. The thinking is that people who go to meetings all day have a very good use for doodling rather than typing. (see this word doc (I know) for yourself)
Lines of code has a little bit to do with reliability. It's a well-known fact that the more lines of code you write (called SLOCs), the more bugs you will have (notes on this here). Although more SLOCs means more bugs, density of bugs does not increase with code length (IEEE report here).
There are two important differences. The first is that people may not verify your data on their copy of software. If you post your data source file, and it looks legit, people may take it on face value even if an anal scientist wouldn't.
Secondly, for data used internally, you can distribute a modified binary throughout your organization. In that case everybody in your organization will believe your data even if they try to verify it themselves.
The point here is that, yes, a truly anal person should catch any attempt to fudge data, but using open source certainly makes it easier.
In fact, it is a simple task to bias results from an open source product. Just change the source to bias your data, and you're pretty much guaranteed that nobody will find out.
On the other hand, you can't change the source code of a commercial product, which as the parent post said, lots of people know how to interpret data from. This makes is significantly harder to dupe people with fudged data.
The fact that this post was modded up shows how zealous and unthinking so many people on this site are.
The EULA doesn't have ANYTHING TO DO with the shutting down of this website. Microsoft would most likely be suing Lik Sang for violating either the DMCA or IP rights (more likely IP rights, I would think, but IANAL). Microsoft has said before that they're NOT interested in punishing individual mod chippers, just mass distributors of mod chips.
Thus, you MAY do whatever you want to YOUR XBox and Microsoft won't care. The only caveat to this is if you're logged onto XBox Live -- Microsoft has reserved the right in the Live EULA to revoke the login rights of people with mod chips. This may piss some of you off, but do you really want people with mod chips on XBox Live? No, it could turn into CounterStrike before PunkBuster, with half of the people online cheating.
HTTP_REFERER tells you where you came FROM to get to the page in question (and only if the user clicked a link). The bug tells you where you're going TO.
This is significantly more of an invasion of privacy than you make it out to be. If a website owner knows that I clicked a link on cnn.com to get to your page, that's no big deal. With this bug, however, a web page can track if I, out of my own whim, decide to go to porn.com after visiting your site. This is decidedly unexpected behavior, since if I'm entering in addresses into the goto bar myself, I don't expect anybody to be tracking my behavior.
Slashdot Mirror
Just to be more clear, it should look more like this:
SEND 32 PACKETS
(wait)
RECEIVE 32 ACKS
SEND 36 PACKETS
(wait)
RECEIVE 36 ACKS
SEND 40 PACKETS
(wait)
RECEIVE 38 ACKS
Since the delay is in waiting for your ACKs to get back, not in waiting to send more packets out.
The fact that the CalTech group got a lot of improvement from their implementation is good real-world evidence that your analysis is probably off, since they don't halve their TX rate and they achieved significantly better throughput.
The reason I think it's off (I think this is a pretty good explanation, but there may be others) is that Internet traffic is bursty. You're not continually pouring packets into routers' buffers -- you're pumping large amounts of packets in, waiting a relatively long time, and then pumping packets back in again. That period of time in between bursts is more than enough time to clear out the buffer.
It's more like pouring one bucket of sand into a funnel, waiting for it all to flow out, and then pouring in two buckets of sand. Eventually, you overflow the funnel with 10 buckets of sand, but you don't need to go back to pouring in 5 buckets.
Okay, I'm graduating in 4 hours so I think it's a wise time to go to bed...
This is stretching my certainty (I'm recalling all of this from a sophomore year CS networks class and I've been overwhelmed by booze in my graduating week), but here's a stab at this...
I don't think that having a long RTT (round-trip time) will have a huge effect on transmission rate in the standard TCP case. Internet traffic, if I remember correctly, is bursty (cite), meaning that a typical transmission looks like:
SEND 32 PACKETS
RECEIVE 32 ACKS
SEND 36 PACKETS
RECEIVE 36 ACKS
SEND 40 PACKETS
RECEIVE 38 ACKS
(oops! Sent 2 more than I could! Halve TX window!)
SEND 20 PACKETS
RECEIVE 20 ACKS
etc. In this case it's easy to see why having a long RTT doesn't slow things down particularly, since there can be a big gap between the SEND and RECEIVE and nothing changes.
In the case of non-bursty traffic, I don't think large RTT causes a big problem for normal TCP either. This is because even with a large RTT (if it takes 400 ms to go from sender to host, for example) ACKS will still be streaming in at a constant, if slower, rate, allowing for more packets to be sent out (this is more subtle to explain, so you might want to google more for a better explanation).
I think the reason you misunderstand this is because the New Scientist article makes it sound like you send a packet, then receive an ACK, then send one, etc. This is not the case -- you send lots of packets together...this is the principle behind the "window", that you can send out more than one packet at a time without receiving an ACK because you've been successful at that so far.
FYI, I looked up MCI's traffic times and found that transatlantic latency is roughly 80ms compared to 45ms for within-US traffic (cite). This is non-trivial, but also not huge.
If anybody disagrees with this assessment, please feel free to correct, since as I said, I'm not 100% sure that increased RTT doesn't mean lower window size.
Also, from my reading a lot of the gain was simply in the fact that halving a throughput rate of 800K/sec means you're dropping to 400K/sec when realistically you should probably only be dropping a little bit. According to NS, they improved by more than two-fold, but that's probably just because normal TCP doesn't often get to the actual max of the network, it may burp a lot on the way up and dip more than halfway than its reasonable max.
And I should clarify my first post as well by explaining what a "transmission error" is that would cause the window size to halve. From the article above: Basically, what I mean by a "transmission error" is a timeout -- the sender sends a packet and never gets an ACK for it. TCP works on the premise that packets are mainly dropped when congestion is high enough for routers to drop packets because of maxed buffers. Thus it makes sense to reduce transmission rate when no ACK is received to adjust to the capacity of the network.
I see this as a way to transmit corrupted files, not a way to speed up the internet experiance as a whole.
Without trying to be mean, you see it that way because you don't understand what's going on (mostly because the post was misleading). Fast TCP packets will still have a checksum and everything, so you're not going to get corrupted files. The change here is that normal TCP halves its "window size", or the amount of info that's out on the network at once without receiving an acknowledgement of receipt, with each error. This means that if there's one minor slowdown when 10 packets are currently out from your computer to the recipient (you've put out 10 packets without getting an ACK back yet), then your computer will reduce its window size and only allow 5 packets to be out at a time, effectively halving the transmission rate. Since TCP continually tries to get faster, it will always hit a bottleneck, resulting in your connection vacillating between optimal speed and half of that (approximately, I guess it might be worse than this on high-speed networks based on what I've read here).
In Fast TCP, they do this "congestion control" in a different way. Rather than halving the connection speed with every slowdown to ensure stability, they send as much data as possible as long as the network seems clear on the recipient's end (I think they estimate this with round-trip time of some sort).
So the "error checking" being changed by Fast TCP is NOT bit checking -- it's transmission rate checking. You'll still always get your files intact.
does show that Novell retains the rights to all the UNIX patents and copyrights
Ahh, but the point of the article is that the contract is much more complicated than this. People will read your post and think "see, there, SCO does not own the IP, there is no case." But the article goes to great lengths to show that SCO may have the right to ENFORCE the copyright even if they don't have the copyright itself. This admittedly seems odd, but I don't see why it wouldn't be possible, in which case SCO would be able to sue everybody's pants off and legally reap the benefits of the copyright without technically holding it:
For example, while the contract leaves the copyrights with Novell, a section that gives to SCO "all claims...against any parties relating to any right, property or asset included in the (Unix) business" could be interpreted to give SCO the right to enforce the copyright, Radcliffe said. "The question is, even though (Novell) didn't assign the intellectual property (to SCO), did (Novell) assign the rights to enforce the patents and copyrights?"
Think about this for a second...would AOL, a huge company with lots of lawyers, EVER buy a company the size of Nullsoft and allow that company to own its IP and control its own software releases? I highly doubt it. It certainly appears from the statement on their website that this is the case, and unless we hear otherwise, we should assume that it is or risk being sued.
Taking drinks from a club, even though the club is private, is indeed clearly illegal. But we're talking about a private SPACE with its own private RULES about the world, which just can't be regulated by public law (except by a EULA, as you point out, but even then you probably can't punish the guy much).
And your example of going to college doesn't hold water. If I disrupt classes at my college, they can kick me out, but they certainly can't prosecute me in criminal court. This is because college has its own private rules about how things run, and if you break them you can be kicked out, but you can't be criminally punished. Nobody has ever gone to jail for violating a school's code of conduct (unless the behavior that violated the school's code also happens to violate the common code).
I'm not against slapping the shit out of these guys -- if I had my character messed up by them I'd kick their asses, too. I'm just saying they shouldn't be liable under any sort of state or federal law for messing with people's game characters.
It's kind of like...if you break into Microsoft's fileservers, changing the names of all of the files you find probably isn't illegal, but the act of hacking into the server may be. It's illegal to break into a system (crack it, whatever), but if you're already in a private space then breaking the intentions of that space is way too vague to be illegal.
My guess is this isn't a crime, even if it may be unethical, but IANAL. Of course, I'm talking from an American point of view, so I don't know about elsewhere.
If I see a door open to a warehouse I *KNOW* I'm not supposed to be in, is it a crime to walk in and take a couple High-Def TVs?
Yeah, that's called trespassing and larceny. Somehow I don't think any states would call acquiring GM powers without authorization trespassing.
If I see a gun just lying around, is it a crime for me to shoot people with it? I mean, it's not my gun.
Yeah, that's called murder. Last time I checked my state (MA) doesn't think killing a game character is murder.
So why is it so unusual that manipulating private software, even if the entry point is public and easily accessible, should be a crime? Why should we expect the virtual "world" to be any different, especially considering that it's much more anonymous and therefore much more enticing to break the law?
You need a serious dose of Real Life, man. The reason private spaces are PRIVATE is because government should not be regulating them. Do you really think that there should be a law against fraud in a Dungeons and Dragons game because the same unethical boundary was crossed in the private space of your basement? This kind of regulation would be a crazy encroachment upon our freedoms. And how would you define what's "right" and "wrong" behavior in a private space? Clearly, becoming a false God in the game was not intended, but where do you draw the line? Would the game publishers need to publish a list of every Acceptable Behavior? Clearly there could be no global standard -- killing may be against the standards of one community (The Sims) and not another (Vice City).
The bottom line is that a private Game World is simply not the same as the Real World, nor should they be regulated in a similar fashion. Stop conflating games and reality and get out a bit.
Forcing people to produce a working prototype before they could get a patent would mean that the people who can spend millions of dollars on fabrication equipment would be in control. Fabrication companies would never let people fabricate a prototype unless the inventors gave up some rights to it. This would obviously be a broken system, since it would take the power away from the inventor and give it to some random suit who owns a machine shop.
Yes, Win95 wasn't the end of MS/DOS, but WinNT pretty much WAS the end of MS/DOS. Of course not completely, but grandfathering old macrokernel code was overshot by the desire for a non-shitty microkernel. Just the same, .NET is a substantial departure from COM...it puts much more focus on interchangeable code, interoperability, and a run-time environment rather than a hack of an inter-program communication system. They are different beasts, despite your witty rhetorical questions.
But the supporting opinions agreed that it should be illegal because it is a form of intimidation, and I don't think anybody believes that a presentation on the security flaws of a popular transaction system is intimidating...just dangerous to a certain corporation.
So that's great, you blog well in PHP, but you utterly overstate the power of MySQL. MySQL will not even approach taking on the big database apps until they have a) subqueries and b) true ACID support. Many complex websites have stored procedures with subqueries in them, and it's logistically impossible for these sites to migrate to MySQL, since it would involve rewriting anything with a subquery (if it's possible at all without nasty temp table hacks).
And not having ACID (atomicity, consistency, isolation, and durability, btw) support? No enterprise-level website, especially one that does eCommerce, would ever think of running a database without proper transactions.
So, yeah, MySQL is great at handling small- to mid-size loads, but once you get to high complexity or you need transactions, it's over. Maybe if they include this stuff in version 4 and it survives a couple of years of testing, THEN we might see some significant migration, but it will not happen until then.
But then you're not charging people if they're an incoming warez server, or they congest your network downloading mp3s.
When I thought of getting a burstable line from Digex, their billing process was to bill my incoming/outgoing data rate based on my peak usage EXCLUDING the top 10% of our usage time. That way if there's a usage spike (or a SQL Slammer spike), then it would be considered an anomaly and wouldn't be billed for. That seems like a rather fair system for me, since there's no real way to distinguish wanted traffic from unwanted traffic and bill based on that.
So, basically, if you could find a way to use fancy statistical methods in a couple of lines of code, you'll be a very famous man. The amount of simplicity many systems use is something like this:
- Did the current process use its entire time slice? If yes, lower priority; if no, raise it.
- Loop through the priority queues and pull out the first proc we see, return it
- Done
(of course, this is only one popular algorithm, but it doesn't get much more complicated than that AFAIK)What does that article say? It says "Based on the number of vulnerabilities announced in 2002 that affect operating systems..."
Now, either I'm an idiot or that article is basing its results on REPORTED VULNERABILITIES. Might the number of reported vulnerabilities have something to do with how hard people ARE LOOKING FOR VULNERABILITIES?
The ONLY way to test the relative vulnerability of an OS is to do a thorough code review of each, or send experts on each into a room and ask them to find exploits (and both approaches won't even be that accurate).
Also, the entire .NET Framework is designed with XML-based services in mind, not just ASP.NET. Most (all?) classes can be serialized and passed around to be discovered by reflection.
Lines of code has a little bit to do with reliability. It's a well-known fact that the more lines of code you write (called SLOCs), the more bugs you will have (notes on this here). Although more SLOCs means more bugs, density of bugs does not increase with code length (IEEE report here).
Secondly, for data used internally, you can distribute a modified binary throughout your organization. In that case everybody in your organization will believe your data even if they try to verify it themselves.
The point here is that, yes, a truly anal person should catch any attempt to fudge data, but using open source certainly makes it easier.
In fact, it is a simple task to bias results from an open source product. Just change the source to bias your data, and you're pretty much guaranteed that nobody will find out.
On the other hand, you can't change the source code of a commercial product, which as the parent post said, lots of people know how to interpret data from. This makes is significantly harder to dupe people with fudged data.
The EULA doesn't have ANYTHING TO DO with the shutting down of this website. Microsoft would most likely be suing Lik Sang for violating either the DMCA or IP rights (more likely IP rights, I would think, but IANAL). Microsoft has said before that they're NOT interested in punishing individual mod chippers, just mass distributors of mod chips.
Thus, you MAY do whatever you want to YOUR XBox and Microsoft won't care. The only caveat to this is if you're logged onto XBox Live -- Microsoft has reserved the right in the Live EULA to revoke the login rights of people with mod chips. This may piss some of you off, but do you really want people with mod chips on XBox Live? No, it could turn into CounterStrike before PunkBuster, with half of the people online cheating.
This is significantly more of an invasion of privacy than you make it out to be. If a website owner knows that I clicked a link on cnn.com to get to your page, that's no big deal. With this bug, however, a web page can track if I, out of my own whim, decide to go to porn.com after visiting your site. This is decidedly unexpected behavior, since if I'm entering in addresses into the goto bar myself, I don't expect anybody to be tracking my behavior.