Funny, none of these points is even close to valid:
1. "Games Use" - Never heard of DGA? This capability has existed in X for a long time.
2. "Web Dev" - Just resize your browser. Yeesh, it's not that tough...
3. "Display Reqs" - If an app requires a specific resolution, as mentioned in point 1, DGA will take care of that. If it requires a specific bit-depth, R&R won't fix that, since it doesn't support bit-depth switching (yes, it's spec'd, but it's not implemented).
So, any other reasons why this is even remotely useful? I can't think of any real ones... sure, it's kinda neat to be able to test out resolutions, but most people chose a resolution and then stick with it, rendering (no pun intended) R&R useless.
Actually, as I understand it, drugs are one of the major expenditures in any healthcare system, including Canada's. The fact is, people with serious illnesses can incur many thousands of dollars per year on drugs alone. Of course, this is where generics would come to the rescue, but, as we've seen, with patent life extending and companies finding loopholes in patent law, this isn't fool proof, AND forces people who can't afford new drugs to be ten years behind the times in disease treatment.
Well, if you're planning on doing real-time encryption of that much data, odds are very good you're planning to use a hardware encryption widget of some kind. For example, according to this article, Xilinx has developed an FPGA that implements DES at 10 Gb/s. 'course, I'd imaging there are ASICs out there with even better performance (I only performed a cursory search).
Actually, the bit about XUL is not true at all. Phoenix is a full XUL application, just like Mozilla. Just more optimized. Heck, that's the whole point of Phoenix... a cross-platform browser based on Mozilla technologies that's *fast* as well. Anyway, AFAIK, they're planning on supporting theming of the interface in the future. It's just not implemented yet, as they have more important things to work on.
Keep in mind that some theorists believe that, at the time of the dinosaurs, the atmosphere was richer in oxygen, meaning the respiratory system wouldn't need to be as powerful as that of a dinosaur evolved in today's environment.
Just to play devil's advocate, it should be noted that you need to purchase a new roll of film every, what, 24 exposures? Whereas, with digital, you buy the camera, and that's it. So, theoretically, in the long term, digital photography may very well have less of an environmental impact. Whether this is actually true is another matter, but it's something to consider.
Umm... I think his comment was related to various herbal and other "public-domain" substances that we know exist, but are no longer patentable, and hence, not profitable. Or I'm on (unpatented) crack.;)
Is there another Nortel box at the other end unwrapping these things? If so, it might be doing something tricky like wrapping your IPSec packets in a standard UDP packet and then shipping those off. These will pass through the NAT unmolested, and are then unwrapped at the other end and forwarded to the IPSec target host.
This depends very much on your firewall. First of all, IPSec using AH will never work using NAT, so we'll ignore that. This is due to the way AH packets are authenticated (the NAT changes the packet, thus invalidating it). The same goes for transport mode ESP. Now, tunnel mode ESP can work... sometimes. If you're doing simple IP NATing that doesn't require access to the upper level headers (ie, TCP port remapping, etc), then yes, tunnel-mode NAT will work. However, if your firewall decides to be smarter than that, things will break, since all the upper-level headers are encapsulated inside the ESP packet.
Note that whether or not IPSec will work through your NAT has absolutely *nothing* to do with the IPSec implementation. IPSec's difficulties with NAT are inherent in it's design (and understandably so). So referring to most IPSec implementations as "NAT friendly" is probably not correct.
Can you prove that Linux is successful because of the GPL? Is there any way to show that, if Linux was under the BSD license, it would have failed? I would argue that Linux succeeded because it just happened to be in the right place at the right time. I mean, really, can you honestly say, with a straight face, that IBM and HP put money into Linux *because* it was GPLd?
The fact is, the BSDs are successful in their own right. And while they're not as successful as Linux in the commercial marketplace, I highly doubt that has anything to do with licensing. I know I'd still be using Linux if it was using a BSD license. Wouldn't you?
As for Linux's advantages you listed, "stability and security", you seem to forget that OpenBSD, a landmark of security and stability, is a BSD-derived operating system. So, clearly, these advantages have little or nothing to do with the GPL. Heck, I can't even understand why the GPL would promote these things. The popular "Linux" name exists because there is a group of developers who perform quality control on the kernel source. This is totally unrelated to licensing, since the same thing could be done if Linux wasn't GPLd. The only difference is that, theoretically, a company could create a distribute their own Linux-based kernel, and close it up. But where's the harm in that? If people wanted "stability and security", they'd just go for the official Linux kernel distribution.
So, please, try to explain to me why the GPL has *anything* to do with Linux's success. I'd love to hear it, because I sure don't believe it.
The use of the term "negative" regarding a material's refractive index is really semantic. Basically, as described by Snell's Law, light bends toward the surface normal as it crosses the boundary of a material. However, materials with a "negative" refractive index have the opposite effect: they cause the light to bend away from the surface normal.
On the flipside, at least WRT the APIs, the specs they are releasing are totally useless. They're either incomplete, or wrong, and so far, most of what's been released has been known for some time now. So, yes,MS might do something good from time to time, but this isn't one of those times.
Well, transcoding is generally frowned upon, actually. However, if you really want to do this, something like the following should work, assuming you have mpg123 and oggenc at your disposal:
mpg123 -s file.mp3 | oggenc -o file.ogg -
Of course, make sure to tailor the oggenc command-lind as necessary (quality levels, etc).
Umm... have you listened to OGG lately? OGG kills MP3 in terms of quality/size, no contest. Yes, there is a debate about it's quality relative to, so, WMA, or other second-generation (third?) lossy codecs. But compared to MP3? I didn't think that discussion was even worth having anymore. P'raps you haven't tried the latest version of OGG?
Actually, current theory, as I understand it, posits that lightening, which was highly common during early times on the earth, triggered chemical reactions in your so-called primordial soup, which lead to the development of the first RNA molecules. From there, it's basic biology...
Of course, there are alternative theories (for example, the "seeding" theory you cite), but the origin of these molecules is more or less then same... chemical reactions occuring on other planets or in interstellar space, triggered by exposure to some form of energy (ie, radiation, etc).
Just a note that, yes, National ID cards are bad... privacy issues and all that. But putting this in the same group with the anti-gun lobby is really pretty ridiculous IMHO. Guns are much more of a gray area, in that there are arguments both ways. Self-defense versus putting dangerous weapons in the hands of average people. Invading the privacy of your country's citizens, OTOH, is a pretty cut-and-dry issue, if you ask me.
Frankly, I think you placing the anti-gun lobby in the same group as National ID cards and digital censorship is a subtle ploy to sway people's opinions. It's no better than an anti-firearms supporter placing guns in the same catagory as nuclear or chemical weapons.
Sure, you can't run unauthorized software on the servers. But what about fun stuff like packet sniffers and the like? Remote exploit tools? I could go on. The fact is, there's a TON of malicious code you probably don't want a regular user to be able to run from INSIDE your network.
Bull. Local exploits are just as important to avoid as remote ones. Anyone who thinks otherwise has their head in the sand. Ignoring the proliferation of remote exploits on the Windows platform, the fact is, people want to run multiuser systems on Windows-based networks (why do you think Microsoft rolled TS into their main product line? To promote this very thing!) And the minute you start allowing multiuser access like this, local exploits become a real concern. Imagine you're running a University using TS and a bunch of thin clients, and you happen to have a cracker enrolled in your program? The point is, in this sort of environment, you CAN'T trust the user, and so you can't take the chance that a local exploit could leave you vulnerable.
Heh... the U of A is my old University (just graduated this past April), and what I'm wondering is, how big of a panic are the sysadmins in right now?:)
Actually, the code wasn't "signed" in the cryptographic sense. The code was checksummed, and that checksum showed there was a problem. However, there is nothing stopping someone from modifying the checksum and making the archive appear legit.
Real cryptographic signing, like that mentioned in the grandparent post, involves hashing the tarball using a strong hash, and then encrypting that hash using the private key of the signer. Then, any person can retrieve the public key of the signer and verify that the "signature" is legitimate by attempting to decrypt the hash (this is probably not strictly correct with the way things really work, but the concept is, AFAIK, correct). The point is that the only person who can "sign" the tarball is limited to only legitimate people (or organizations). So, if the signature for the tarball is valid, you can guarantee it was signed by someone you trust, and so you can trust the code.
Just OOC, what do these servers do that they need to initiate connections to the outside world? I mean, there's the obvious case of mail servers and DNS servers, but beyond that, I have trouble thinking of a good example. Granted, I haven't had to configure anything exotic, so I may be missing something.
Slashdot Mirror
Funny, none of these points is even close to valid:
1. "Games Use" - Never heard of DGA? This capability has existed in X for a long time.
2. "Web Dev" - Just resize your browser. Yeesh, it's not that tough...
3. "Display Reqs" - If an app requires a specific resolution, as mentioned in point 1, DGA will take care of that. If it requires a specific bit-depth, R&R won't fix that, since it doesn't support bit-depth switching (yes, it's spec'd, but it's not implemented).
So, any other reasons why this is even remotely useful? I can't think of any real ones... sure, it's kinda neat to be able to test out resolutions, but most people chose a resolution and then stick with it, rendering (no pun intended) R&R useless.
Oh, and s/ten years/x years/, since, in retrospect, I don't think that's the right number. :)
Actually, as I understand it, drugs are one of the major expenditures in any healthcare system, including Canada's. The fact is, people with serious illnesses can incur many thousands of dollars per year on drugs alone. Of course, this is where generics would come to the rescue, but, as we've seen, with patent life extending and companies finding loopholes in patent law, this isn't fool proof, AND forces people who can't afford new drugs to be ten years behind the times in disease treatment.
Well, if you're planning on doing real-time encryption of that much data, odds are very good you're planning to use a hardware encryption widget of some kind. For example, according to this article, Xilinx has developed an FPGA that implements DES at 10 Gb/s. 'course, I'd imaging there are ASICs out there with even better performance (I only performed a cursory search).
That would be the GRE (Gecko Runtime Environment)... check it out at mozilla.org.
Actually, the bit about XUL is not true at all. Phoenix is a full XUL application, just like Mozilla. Just more optimized. Heck, that's the whole point of Phoenix... a cross-platform browser based on Mozilla technologies that's *fast* as well. Anyway, AFAIK, they're planning on supporting theming of the interface in the future. It's just not implemented yet, as they have more important things to work on.
Keep in mind that some theorists believe that, at the time of the dinosaurs, the atmosphere was richer in oxygen, meaning the respiratory system wouldn't need to be as powerful as that of a dinosaur evolved in today's environment.
Just to play devil's advocate, it should be noted that you need to purchase a new roll of film every, what, 24 exposures? Whereas, with digital, you buy the camera, and that's it. So, theoretically, in the long term, digital photography may very well have less of an environmental impact. Whether this is actually true is another matter, but it's something to consider.
Umm... I think his comment was related to various herbal and other "public-domain" substances that we know exist, but are no longer patentable, and hence, not profitable. Or I'm on (unpatented) crack. ;)
Is there another Nortel box at the other end unwrapping these things? If so, it might be doing something tricky like wrapping your IPSec packets in a standard UDP packet and then shipping those off. These will pass through the NAT unmolested, and are then unwrapped at the other end and forwarded to the IPSec target host.
This depends very much on your firewall. First of all, IPSec using AH will never work using NAT, so we'll ignore that. This is due to the way AH packets are authenticated (the NAT changes the packet, thus invalidating it). The same goes for transport mode ESP. Now, tunnel mode ESP can work... sometimes. If you're doing simple IP NATing that doesn't require access to the upper level headers (ie, TCP port remapping, etc), then yes, tunnel-mode NAT will work. However, if your firewall decides to be smarter than that, things will break, since all the upper-level headers are encapsulated inside the ESP packet.
Note that whether or not IPSec will work through your NAT has absolutely *nothing* to do with the IPSec implementation. IPSec's difficulties with NAT are inherent in it's design (and understandably so). So referring to most IPSec implementations as "NAT friendly" is probably not correct.
Troll? Probably, but I'll bite...
Can you prove that Linux is successful because of the GPL? Is there any way to show that, if Linux was under the BSD license, it would have failed? I would argue that Linux succeeded because it just happened to be in the right place at the right time. I mean, really, can you honestly say, with a straight face, that IBM and HP put money into Linux *because* it was GPLd?
The fact is, the BSDs are successful in their own right. And while they're not as successful as Linux in the commercial marketplace, I highly doubt that has anything to do with licensing. I know I'd still be using Linux if it was using a BSD license. Wouldn't you?
As for Linux's advantages you listed, "stability and security", you seem to forget that OpenBSD, a landmark of security and stability, is a BSD-derived operating system. So, clearly, these advantages have little or nothing to do with the GPL. Heck, I can't even understand why the GPL would promote these things. The popular "Linux" name exists because there is a group of developers who perform quality control on the kernel source. This is totally unrelated to licensing, since the same thing could be done if Linux wasn't GPLd. The only difference is that, theoretically, a company could create a distribute their own Linux-based kernel, and close it up. But where's the harm in that? If people wanted "stability and security", they'd just go for the official Linux kernel distribution.
So, please, try to explain to me why the GPL has *anything* to do with Linux's success. I'd love to hear it, because I sure don't believe it.
Umm... what does this have to do with Quantum Cryptography?
The use of the term "negative" regarding a material's refractive index is really semantic. Basically, as described by Snell's Law, light bends toward the surface normal as it crosses the boundary of a material. However, materials with a "negative" refractive index have the opposite effect: they cause the light to bend away from the surface normal.
On the flipside, at least WRT the APIs, the specs they are releasing are totally useless. They're either incomplete, or wrong, and so far, most of what's been released has been known for some time now. So, yes,MS might do something good from time to time, but this isn't one of those times.
Well, transcoding is generally frowned upon, actually. However, if you really want to do this, something like the following should work, assuming you have mpg123 and oggenc at your disposal:
mpg123 -s file.mp3 | oggenc -o file.ogg -
Of course, make sure to tailor the oggenc command-lind as necessary (quality levels, etc).
Umm... have you listened to OGG lately? OGG kills MP3 in terms of quality/size, no contest. Yes, there is a debate about it's quality relative to, so, WMA, or other second-generation (third?) lossy codecs. But compared to MP3? I didn't think that discussion was even worth having anymore. P'raps you haven't tried the latest version of OGG?
Actually, current theory, as I understand it, posits that lightening, which was highly common during early times on the earth, triggered chemical reactions in your so-called primordial soup, which lead to the development of the first RNA molecules. From there, it's basic biology...
Of course, there are alternative theories (for example, the "seeding" theory you cite), but the origin of these molecules is more or less then same... chemical reactions occuring on other planets or in interstellar space, triggered by exposure to some form of energy (ie, radiation, etc).
Just a note that, yes, National ID cards are bad... privacy issues and all that. But putting this in the same group with the anti-gun lobby is really pretty ridiculous IMHO. Guns are much more of a gray area, in that there are arguments both ways. Self-defense versus putting dangerous weapons in the hands of average people. Invading the privacy of your country's citizens, OTOH, is a pretty cut-and-dry issue, if you ask me.
Frankly, I think you placing the anti-gun lobby in the same group as National ID cards and digital censorship is a subtle ploy to sway people's opinions. It's no better than an anti-firearms supporter placing guns in the same catagory as nuclear or chemical weapons.
Sure, you can't run unauthorized software on the servers. But what about fun stuff like packet sniffers and the like? Remote exploit tools? I could go on. The fact is, there's a TON of malicious code you probably don't want a regular user to be able to run from INSIDE your network.
Bull. Local exploits are just as important to avoid as remote ones. Anyone who thinks otherwise has their head in the sand. Ignoring the proliferation of remote exploits on the Windows platform, the fact is, people want to run multiuser systems on Windows-based networks (why do you think Microsoft rolled TS into their main product line? To promote this very thing!) And the minute you start allowing multiuser access like this, local exploits become a real concern. Imagine you're running a University using TS and a bunch of thin clients, and you happen to have a cracker enrolled in your program? The point is, in this sort of environment, you CAN'T trust the user, and so you can't take the chance that a local exploit could leave you vulnerable.
Heh... the U of A is my old University (just graduated this past April), and what I'm wondering is, how big of a panic are the sysadmins in right now? :)
Actually, the code wasn't "signed" in the cryptographic sense. The code was checksummed, and that checksum showed there was a problem. However, there is nothing stopping someone from modifying the checksum and making the archive appear legit.
Real cryptographic signing, like that mentioned in the grandparent post, involves hashing the tarball using a strong hash, and then encrypting that hash using the private key of the signer. Then, any person can retrieve the public key of the signer and verify that the "signature" is legitimate by attempting to decrypt the hash (this is probably not strictly correct with the way things really work, but the concept is, AFAIK, correct). The point is that the only person who can "sign" the tarball is limited to only legitimate people (or organizations). So, if the signature for the tarball is valid, you can guarantee it was signed by someone you trust, and so you can trust the code.
Just OOC, what do these servers do that they need to initiate connections to the outside world? I mean, there's the obvious case of mail servers and DNS servers, but beyond that, I have trouble thinking of a good example. Granted, I haven't had to configure anything exotic, so I may be missing something.
Umm, totally OT... isn't that phrase supposed to be "C'est la vie"?