I bet it won't be too long before IM clients will, by default, ignore anyone not on your friends list, eliminating IM spam. I think there will be a lot of systems where people use whitelists of various sorts to block unrequested interactions.
Nintendo was a big name in the arcade, and entered the console market essentially by putting a coin-op game on your TV. Sure, the NES was better than the 2600, but the thing that made it big was that it was the arcade at home (compare with the Sega master system, which was about as good, but didn't play games from the arcade, and didn't go anywhere).
I personally missed the start of the whole Playstation thing, so I'm not sure what let Sony take over; the best I can recall, it was that people had brand loyalty to Square, who has a falling out with Nintendo and released FF7 for the upstart. It's not exactly the same as buying a successful player, but similar.
Oracle will probably point out that your 4-way dual-core machine performs better than a 8-way single-core machine, due to faster communications between the cores on a single chip, and costs less, due to not needing an 8-way motherboard. It would be a bit odd to charge you less for the configuration which is already a better value.
You were thinking you could upgrade your database server by only buying hardware?
In mozilla_die1.html, you're missing an ASCII NUL, which is what is supposed to make the difference.
I wouldn't be too surprised if it were impossible to crash IE with randomly malformed HTML, because I bet that IE uses an SGML parser to extract a valid document (or nothing) from the file, and does not do anything tag-specific in parsing. This means that a relatively simple chunk of code is all that sees the random garbage, and the HTML engine gets nicely cleaned stuff.
I actually suspect that they're using an XML parser which supports being permissive in a variety of ways, including all of the ways permitted by SGML, but producing a parsed XML document which is completely valid by the DTD by ignoring anything completely unparsable.
This is not to say that IE is actually secure or anything; just that it is only vulnerable to valid but tricky HTML.
An apache module isn't really a useful way to do it, because then you'll crash the only program that gets the test case, making it difficult to send it in with a bug report.
All of these are unsuccessful Microsoft businesses in areas where other companies are successful. That means that they aren't getting into new markets; they're getting into old markets they weren't in before. In order to be successful in a market you have to get into it from the beginning, change it into a new market, crush the competition, or buy a successful player.
You need to get into markets where nobody's solved the problems. Microsoft got a GUI on commodity hardware, and an integrated office suite with popular individual programs, which is why Windows and Office are their moneymakers. Other than that, they've mostly been late in their markets, and haven't done well.
In terms of actual info, there's the author's handwriting. Writing style and typoes do give a text a certain amount of character, but not as much. Then there are the differences between how the author normally writes and the handwriting in the document, which can indicate emotion, caffeine, distraction, etc.
Of course, these apply more to documents you are reading for historical value, not for things you are reading exclusively for the content.
Alternatively, DomainKeys authenticates the original sender, while SPF authenticates the proximate sender. Both may be desirable for different reasons. You may want to verify for yourself that a message was actually sent to a mailing list by the people it claims to have been sent by, or you may want to verify that it came to you from the mailing list it claims to have come from.
You might even be responsible for the spam filter for a mailing list, and want to whitelist any message which actually goes through the mailing list, even if your personal filters would trap that message were you to get it directly, while not wanting to be confused by email forged as coming by way of the list.
Software patents are pathetic since they are purposly broadly written so that pretty much anything done with a computer (even if it already exists in the non-software world) will infringe.
The LZW patent (which caused problems with GIF) was (despite it's other flaws) written sufficiently narrowly not cover anything done with a computer other than compression, and not cover the methods of compression used in gzip, JPEG, or PNG, or run length encoding. So your statement not only isn't true of all software patents, it's not even true of all bad software patents. (The inventor of LZW published a paper about it more than a year before filing for the patent; this is supposed to prevent getting a patent, because people will learn of the invention from the paper and think the technique is unencumbered, which is what happened with GIF).
The patents on techniques used to compress and decompress MPEG4 seem to me to be just as valid as patents on new can opener designs.
People certainly use this strategy in real life, where they will attempt to recognize and sacrifice themselves to benefit particular other people. Much of the animal kingdom uses this as the main social interaction: 1) Is this another wolf? 2) Am I dominant? 3) Profit!
The issue, as is often the case in game theory, is that the mathematical form of the competition does not match the human-language description of the competition. The fact that a program could encounter another program it is not competing against was not considered in the design, but it clearly matters. As such, this is an interesting result in the theory of the design of the competition. In a game thoery competition, you follow only the letter of the law, not the intent.
It would be interesting to permit saved state between pairings, permit random number generation, and require all teammates to have identical programs. Then I suspect that the strategy which produces the winning instance would have each instance randomly determine a strength, and act to recognize the same program, determine the stronger instance, and then give all the points to that one.
It's not really any more of a cheat than tit-for-tat, in any case, which loses every pairing unless the other player never defects (in which case it's a tie), but generally wins the whole competition. The next step is clearly to have multiple instances, and lose the competition most of the time, but win with one instance.
"The Linux Kernel" is not an item which could be bought. The discussion is about a non-exclusive BSD license to a particular linux version, which is a complicated thing to put a value on. First of all, such a sale would not take anything away from the sellers. Secondly, there are owners not willing to sell for money (although other assets or licenses might be more tempting). Thirdly, there are owners who can no longer be found (some of whom may not know they have inherited rights from deceased developers).
So the offer was for something which would be very difficult to provide (just in terms of finding everyone) and may be impossible to guarantee, regardless of the issue of what price people would put on it (and, for that matter, whether all developers would care at all about huge quantities of money being paid to kernl.org).
The figure given is a standard estimate for how much it would cost to pay a new group of people to develop Linux again from scratch. That is, if you can't make a deal with the actual developers of Linux, you could just pay new people to do the project; this would probably cost $600 million (in salaries for the new people).
As for the actual market value of the Linux IP, it derives in part from the fact that the complete set of owners is unlikely to collude, meaning that the license terms are effectively immutable, and in part from the fact that other licensees pay for their use in development effort rather than money, improving the result directly instead of enriching the owner. This makes its value similar to, say, the Library of Congress, in that it couldn't be owned by a purchaser and still have its value.
Linux has the same market value as the Library of Congress: it can't actually be sold.
If the purchase of physical objects from a physical store stops working for them, they could arrange something similar to Magnatune, where they would find and make non-exclusive deals with indy acts. They probably also sell mainstream stuff, which they'd have to deal with less conveniently (i.e., depending on shipment of things). I bet you'd be willing to pay their markup directly for their suggestions, and buy the music online.
These days, it's useful to let people know exactly why they should pay you, because the things they are nominally paying for in a traditional system are available with better deals elsewhere.
Chances are that they'll have DIP packages as well, because most companies that use etched PCBs tend to do early prototypes or test things with good old breadboards (or the AVR development kit). Of course, the TQFP version is what they expect people to buy in quantity and use in real applications.
The large AVRs actually do have support for external memory. On the other hand, you can only have execute code in flash, not internal or external memory on them. And there's no reason you need a specially-designated address bus; there's support for a lot of pins you just control, plus i2c and various other things. Sure, the load instruction won't automatically pull in data from external RAM, but you can handle it like swap.
Comments are valuable at a relatively high level, where you describe what the code is supposed to do. The code itself documents what it actually does, but there's no way for a person reading it later to determine if it is doing what it is supposed to do without a comment that explains the intent. For example: "// Long divide in place, junking the data, but leaving the reminder" is very useful to the person who comes along later and doesn't know that the code actually wants this odd result, and wouldn't have a chance of figuring it out if the code didn't compute it correctly due to a bug.
You don't catch SQL injection issues with unit testing; you catch them with type checking. A SQL injection occurs when someone uses a string plus quotes as a partial SQL statement. There should be a different type for partial SQL statements, and the operation to make one for a string constant out of a string should escape the string appropriately. Alternatively, you could just use prepared statements exclusively and make your database happy as well as making SQL injections totally impossible (as the database will be done parsing the SQL when it looks at the user-supplied data).
The best reason to write the tests first, in my opinion, is that this will give you a good idea of whether the API is any good. Many of the APIs I've wanted to be different obviously couldn't have been tested in advance, because writing the test would have made it clear that the API was just too much of a pain to use. If writing 10 example uses for your API is enough work to worry about, your design is bad, and people are probably going to not like how it works. Change it before either finishing the tests or writing the code (or, ideally, telling anyone else about it).
The largest producer of hydrogen currently is the petroleum industry, as a byproduct, who mostly doesn't bother to capture it, because there isn't a market for that much hydrogren gas. Even if there wasn't a big market for refined hydrocarbons, petroleum would be a cost-effective source of hydrogen gas (relative to other sources). They could sell hydrogen gas for car fuel at prices per mile better than gasoline, and make more money for the same raw materials, giving them more profit.
There's not all that much improvement that could be made to Theora, since it's a deployed standard. In order to improve Ogg, a separate codec needs to be developed. So, essentially, yes: Theora's advantage is that it is ready, while Dirac's advantage is that it will be better.
Note that there are probably a dozen video codecs for the MPEG container format in active use, and two audio codecs for Ogg, so multiple video codecs for Ogg makes sense.
The BBC is currently using a different container format than Ogg, but specifying Ogg Dirac when they're done wouldn't be particularly difficult.
Once they're shipped without endorsement keys, they can't then be used in a DRM scheme. Any key on them must be put there by the user, so the program can't tell if it is running on the bare hardware without any simulation layer, which is the basis of that mechanism.
The aluminum tubes analogy is not to dual-use facilities; the DoE's experts stated that those tubes simply couldn't be used for weapons production. In order to produce weapons, you'd have to get some other aluminum tubes, which, while also aluminum tubes, aren't the same items at all.
A massive data mining project to determine what events are likely to take down infrastructure and try to cause those or similar events. They could also use the information to determine how widespread events they caused were, in order to refine future plans.
It's not an entirely stupid thing to what the terrorists not to know. On the other hand, the terrorists are likely to be able to get the information if it's at all important to them. The government knows essentially nothing about Al Queda's operations in the US (according to the 9/11 commission), so there's no reason to think they don't have people in telecom support centers if they have people preparing to drive bulldozers through fiber bundles. It's not likely they'd trust the government's reports anyway.
Personally, I think that the global terrorists these days are satisfied to call each other by the names of public figures, make anonymous bomb threats, leave packages in lobbies, etc. It's a lot safer and easier, and no less effective at this point.
Probably so that they don't have to redesign it if someone someday wants one. It could be important in applications such as ensuring that voting machines aren't tampered with (i.e., local poll workers and Diebold can't get the machine to run different code from what the state has certified). IBM might as well have a single implementation from both that circumstance and PCs, and just ship the PCs without endorsement keys, because a single implementation will be tested better than separate ones.
To put this the other way, if these chips are intended to become part of a DRM scheme, why are they being shipped now in a configuration where they can't be used for DRM? (We know IBM is trying to lock us out of our computers, because they're using trust chips and some other aluminum tubes... er, trust chips could be used to lock us out of our computers)
Remember that RIAA members do actually serve a legitimate purpose, as well. They employ the sound engineers and technicians who get the music from the microphones to a recording. Producing a recording takes a lot of skill, and is generally underappreciated.
Of course, these days, there is a lot less capital investment in equipment capable of doing production, so the RIAA method is no longer efficient. These days, a indie label can do perfectly good production, or a band can even have essentially a member who does the sound.
So there is actually a useful function the RIAA serves, but this no longer justifies the control they have over the results.
The question, therefore, isn't whether IBM is shipping machines with trust chips, but whether IBM is shipping machines with endorsement keys. If the trust chips are really fully controlled by the user, then this isn't a dongle built into the computer.
Last time I heard about this stuff, IBM had no plans to include endorsement keys, so this actually was a way to give the owner of the computer hardware more control over it, not a way to give the manufacturer more control.
Slashdot Mirror
I bet it won't be too long before IM clients will, by default, ignore anyone not on your friends list, eliminating IM spam. I think there will be a lot of systems where people use whitelists of various sorts to block unrequested interactions.
Nintendo was a big name in the arcade, and entered the console market essentially by putting a coin-op game on your TV. Sure, the NES was better than the 2600, but the thing that made it big was that it was the arcade at home (compare with the Sega master system, which was about as good, but didn't play games from the arcade, and didn't go anywhere).
I personally missed the start of the whole Playstation thing, so I'm not sure what let Sony take over; the best I can recall, it was that people had brand loyalty to Square, who has a falling out with Nintendo and released FF7 for the upstart. It's not exactly the same as buying a successful player, but similar.
Oracle will probably point out that your 4-way dual-core machine performs better than a 8-way single-core machine, due to faster communications between the cores on a single chip, and costs less, due to not needing an 8-way motherboard. It would be a bit odd to charge you less for the configuration which is already a better value.
You were thinking you could upgrade your database server by only buying hardware?
In mozilla_die1.html, you're missing an ASCII NUL, which is what is supposed to make the difference.
I wouldn't be too surprised if it were impossible to crash IE with randomly malformed HTML, because I bet that IE uses an SGML parser to extract a valid document (or nothing) from the file, and does not do anything tag-specific in parsing. This means that a relatively simple chunk of code is all that sees the random garbage, and the HTML engine gets nicely cleaned stuff.
I actually suspect that they're using an XML parser which supports being permissive in a variety of ways, including all of the ways permitted by SGML, but producing a parsed XML document which is completely valid by the DTD by ignoring anything completely unparsable.
This is not to say that IE is actually secure or anything; just that it is only vulnerable to valid but tricky HTML.
An apache module isn't really a useful way to do it, because then you'll crash the only program that gets the test case, making it difficult to send it in with a bug report.
All of these are unsuccessful Microsoft businesses in areas where other companies are successful. That means that they aren't getting into new markets; they're getting into old markets they weren't in before. In order to be successful in a market you have to get into it from the beginning, change it into a new market, crush the competition, or buy a successful player.
You need to get into markets where nobody's solved the problems. Microsoft got a GUI on commodity hardware, and an integrated office suite with popular individual programs, which is why Windows and Office are their moneymakers. Other than that, they've mostly been late in their markets, and haven't done well.
In terms of actual info, there's the author's handwriting. Writing style and typoes do give a text a certain amount of character, but not as much. Then there are the differences between how the author normally writes and the handwriting in the document, which can indicate emotion, caffeine, distraction, etc.
Of course, these apply more to documents you are reading for historical value, not for things you are reading exclusively for the content.
Alternatively, DomainKeys authenticates the original sender, while SPF authenticates the proximate sender. Both may be desirable for different reasons. You may want to verify for yourself that a message was actually sent to a mailing list by the people it claims to have been sent by, or you may want to verify that it came to you from the mailing list it claims to have come from.
You might even be responsible for the spam filter for a mailing list, and want to whitelist any message which actually goes through the mailing list, even if your personal filters would trap that message were you to get it directly, while not wanting to be confused by email forged as coming by way of the list.
Software patents are pathetic since they are purposly broadly written so that pretty much anything done with a computer (even if it already exists in the non-software world) will infringe.
The LZW patent (which caused problems with GIF) was (despite it's other flaws) written sufficiently narrowly not cover anything done with a computer other than compression, and not cover the methods of compression used in gzip, JPEG, or PNG, or run length encoding. So your statement not only isn't true of all software patents, it's not even true of all bad software patents. (The inventor of LZW published a paper about it more than a year before filing for the patent; this is supposed to prevent getting a patent, because people will learn of the invention from the paper and think the technique is unencumbered, which is what happened with GIF).
The patents on techniques used to compress and decompress MPEG4 seem to me to be just as valid as patents on new can opener designs.
People certainly use this strategy in real life, where they will attempt to recognize and sacrifice themselves to benefit particular other people. Much of the animal kingdom uses this as the main social interaction: 1) Is this another wolf? 2) Am I dominant? 3) Profit!
The issue, as is often the case in game theory, is that the mathematical form of the competition does not match the human-language description of the competition. The fact that a program could encounter another program it is not competing against was not considered in the design, but it clearly matters. As such, this is an interesting result in the theory of the design of the competition. In a game thoery competition, you follow only the letter of the law, not the intent.
It would be interesting to permit saved state between pairings, permit random number generation, and require all teammates to have identical programs. Then I suspect that the strategy which produces the winning instance would have each instance randomly determine a strength, and act to recognize the same program, determine the stronger instance, and then give all the points to that one.
It's not really any more of a cheat than tit-for-tat, in any case, which loses every pairing unless the other player never defects (in which case it's a tie), but generally wins the whole competition. The next step is clearly to have multiple instances, and lose the competition most of the time, but win with one instance.
"The Linux Kernel" is not an item which could be bought. The discussion is about a non-exclusive BSD license to a particular linux version, which is a complicated thing to put a value on. First of all, such a sale would not take anything away from the sellers. Secondly, there are owners not willing to sell for money (although other assets or licenses might be more tempting). Thirdly, there are owners who can no longer be found (some of whom may not know they have inherited rights from deceased developers).
So the offer was for something which would be very difficult to provide (just in terms of finding everyone) and may be impossible to guarantee, regardless of the issue of what price people would put on it (and, for that matter, whether all developers would care at all about huge quantities of money being paid to kernl.org).
The figure given is a standard estimate for how much it would cost to pay a new group of people to develop Linux again from scratch. That is, if you can't make a deal with the actual developers of Linux, you could just pay new people to do the project; this would probably cost $600 million (in salaries for the new people).
As for the actual market value of the Linux IP, it derives in part from the fact that the complete set of owners is unlikely to collude, meaning that the license terms are effectively immutable, and in part from the fact that other licensees pay for their use in development effort rather than money, improving the result directly instead of enriching the owner. This makes its value similar to, say, the Library of Congress, in that it couldn't be owned by a purchaser and still have its value.
Linux has the same market value as the Library of Congress: it can't actually be sold.
An XML Parser and stuff like MD5.
If the purchase of physical objects from a physical store stops working for them, they could arrange something similar to Magnatune, where they would find and make non-exclusive deals with indy acts. They probably also sell mainstream stuff, which they'd have to deal with less conveniently (i.e., depending on shipment of things). I bet you'd be willing to pay their markup directly for their suggestions, and buy the music online.
These days, it's useful to let people know exactly why they should pay you, because the things they are nominally paying for in a traditional system are available with better deals elsewhere.
No, the sun is the largest consumer of hydrogen. It produces heavier atoms out of hydrogen.
I suppose speech is, in fact, audio; I hadn't considered Speex as an audio codec for some reason.
Chances are that they'll have DIP packages as well, because most companies that use etched PCBs tend to do early prototypes or test things with good old breadboards (or the AVR development kit). Of course, the TQFP version is what they expect people to buy in quantity and use in real applications.
The large AVRs actually do have support for external memory. On the other hand, you can only have execute code in flash, not internal or external memory on them. And there's no reason you need a specially-designated address bus; there's support for a lot of pins you just control, plus i2c and various other things. Sure, the load instruction won't automatically pull in data from external RAM, but you can handle it like swap.
Comments are valuable at a relatively high level, where you describe what the code is supposed to do. The code itself documents what it actually does, but there's no way for a person reading it later to determine if it is doing what it is supposed to do without a comment that explains the intent. For example: "// Long divide in place, junking the data, but leaving the reminder" is very useful to the person who comes along later and doesn't know that the code actually wants this odd result, and wouldn't have a chance of figuring it out if the code didn't compute it correctly due to a bug.
You don't catch SQL injection issues with unit testing; you catch them with type checking. A SQL injection occurs when someone uses a string plus quotes as a partial SQL statement. There should be a different type for partial SQL statements, and the operation to make one for a string constant out of a string should escape the string appropriately. Alternatively, you could just use prepared statements exclusively and make your database happy as well as making SQL injections totally impossible (as the database will be done parsing the SQL when it looks at the user-supplied data).
The best reason to write the tests first, in my opinion, is that this will give you a good idea of whether the API is any good. Many of the APIs I've wanted to be different obviously couldn't have been tested in advance, because writing the test would have made it clear that the API was just too much of a pain to use. If writing 10 example uses for your API is enough work to worry about, your design is bad, and people are probably going to not like how it works. Change it before either finishing the tests or writing the code (or, ideally, telling anyone else about it).
The largest producer of hydrogen currently is the petroleum industry, as a byproduct, who mostly doesn't bother to capture it, because there isn't a market for that much hydrogren gas. Even if there wasn't a big market for refined hydrocarbons, petroleum would be a cost-effective source of hydrogen gas (relative to other sources). They could sell hydrogen gas for car fuel at prices per mile better than gasoline, and make more money for the same raw materials, giving them more profit.
There's not all that much improvement that could be made to Theora, since it's a deployed standard. In order to improve Ogg, a separate codec needs to be developed. So, essentially, yes: Theora's advantage is that it is ready, while Dirac's advantage is that it will be better.
Note that there are probably a dozen video codecs for the MPEG container format in active use, and two audio codecs for Ogg, so multiple video codecs for Ogg makes sense.
The BBC is currently using a different container format than Ogg, but specifying Ogg Dirac when they're done wouldn't be particularly difficult.
Once they're shipped without endorsement keys, they can't then be used in a DRM scheme. Any key on them must be put there by the user, so the program can't tell if it is running on the bare hardware without any simulation layer, which is the basis of that mechanism.
The aluminum tubes analogy is not to dual-use facilities; the DoE's experts stated that those tubes simply couldn't be used for weapons production. In order to produce weapons, you'd have to get some other aluminum tubes, which, while also aluminum tubes, aren't the same items at all.
A massive data mining project to determine what events are likely to take down infrastructure and try to cause those or similar events. They could also use the information to determine how widespread events they caused were, in order to refine future plans.
It's not an entirely stupid thing to what the terrorists not to know. On the other hand, the terrorists are likely to be able to get the information if it's at all important to them. The government knows essentially nothing about Al Queda's operations in the US (according to the 9/11 commission), so there's no reason to think they don't have people in telecom support centers if they have people preparing to drive bulldozers through fiber bundles. It's not likely they'd trust the government's reports anyway.
Personally, I think that the global terrorists these days are satisfied to call each other by the names of public figures, make anonymous bomb threats, leave packages in lobbies, etc. It's a lot safer and easier, and no less effective at this point.
Probably so that they don't have to redesign it if someone someday wants one. It could be important in applications such as ensuring that voting machines aren't tampered with (i.e., local poll workers and Diebold can't get the machine to run different code from what the state has certified). IBM might as well have a single implementation from both that circumstance and PCs, and just ship the PCs without endorsement keys, because a single implementation will be tested better than separate ones.
To put this the other way, if these chips are intended to become part of a DRM scheme, why are they being shipped now in a configuration where they can't be used for DRM? (We know IBM is trying to lock us out of our computers, because they're using trust chips and some other aluminum tubes... er, trust chips could be used to lock us out of our computers)
Remember that RIAA members do actually serve a legitimate purpose, as well. They employ the sound engineers and technicians who get the music from the microphones to a recording. Producing a recording takes a lot of skill, and is generally underappreciated.
Of course, these days, there is a lot less capital investment in equipment capable of doing production, so the RIAA method is no longer efficient. These days, a indie label can do perfectly good production, or a band can even have essentially a member who does the sound.
So there is actually a useful function the RIAA serves, but this no longer justifies the control they have over the results.
The question, therefore, isn't whether IBM is shipping machines with trust chips, but whether IBM is shipping machines with endorsement keys. If the trust chips are really fully controlled by the user, then this isn't a dongle built into the computer.
Last time I heard about this stuff, IBM had no plans to include endorsement keys, so this actually was a way to give the owner of the computer hardware more control over it, not a way to give the manufacturer more control.