So basically, this would mean a large number of the worlds finest mathematicians are working tirelessly to create something that is by definition mathematically impossible.
Yes, discounting the redefinition of impossible, it would mean that.:-)
Can't a quantum computer [...] break any encryption instantly by only actually arriving at the destination assigned?
No. Quantum computers can theoretically solve some problems faster than classical computers. Among these (and perhaps most famously) is factoring -- see Shor's Algorithm. Fast factorization breaks RSA encryption, which is what everyone uses.
It is not known whether quantum computers can in general solve problems exponentially faster than classical ones. Further, it is not known for most important problems how to take advantage of quantum computers to achieve dramatic speedups (or even if it's possible). It seems that NSA and the Army want to know more about this.
If you assume something has only a metaphysical or religious explanation, you can't advance your understanding. So, it's at least useful to assume there is a rational explanation, and try to find it.
I know you're exaggerating, but didn't browsers do that for forms submitted via POST? I don't know if they still do (it's been a while since I don't install a browser in a new computer), but I remember that one of the first things to do then using a new browser was to mark the "don't bug me about this anymore checkbox" and click OK.
By the way, I don't completely dislike the idea of allowing self-signed certificates but not showing the green "secure" icon. But I think it might be better to make that a "new" protocol that behaves exactly as https except that it accepts (perhaps silently) self-signed certificates (maybe call it "httpe", for "encrypted"). That way, there's less possibility of confusion between sites that are really secure and sites that just use encryption but are theoretically vulnerable to MITM attacks.
That's not the point; it doesn't matther what the protocol says.
What matters is the user's expectation. Unfortunately, today people expect "https" to be secure enough to send their bank password or credit card number. It's very hard to explain the nuances of encryption and authentication to someone who just wants to shop online.
My unrealistic solution that will never be implemented: create a new protocol that uses SSL/TLS exactly as https, but silently accepts non-verified certificates. Maybe call it httpe ("e" means encrypted). Then teach people than "https" is for using banks and online shopping, "httpe" is for other stuff that is nice to have encrypted but nothing too bad will happen if someone happens to see.
And the theorems it can't prove are all stuff like, "This statement cannot be proven."
While that might be true in some sense, that's not the whole story. As an example of an useful such theorem, Matiyasevich (using various people's results) has shown that there's no way to prove if certain Diophantine equations have solutions or not.
Strictly speaking, all this means is that you can write a Diophantine equation that encodes some statement like the one you stated. But this doesn't detract from the original point: there still exists some Diopnhantine equation for which we can't prove the existence of solutions (or lack thereof) in the set of axioms known as ZFC, and that's interesting in itself.
Well, according to section 7.2 of the C# Language Specification, operands are evaluated from left to right, so the result is what I would have expected:
first you evaluate the first i++, which yields 0 (and increments i to 1)
then, you evaluate the second i++, which yields 1 (and increments i to 2)
last, you calculate the sum (0+1 = 1) and assign it to i, overwriting the old value of 2.
I don't disagree with you, but I don't see how that relates to this case (I have read http://www.xenu.net/copyright.html, I assume that's what you're talking about.)
In the software world, copyright restriction is the norm. For instance, you simply can not copy Microsoft software (or even install it in your computer) unless you buy it from them (they call it "licensing"). That's broadly accepted, no one really disputes that. What people dispute is that copyright was initially intended for a different purpose that what it's being used today.
The GPL (and other licenses) are chosen by authors because they want to be less restrictive than that. You're free to not accept the GPL, but then you're back to not being able to copy (or change, distribute, etc.) the software.
You mean, the issue that users get functionality years earlier than they would have if the project had been GPL?
If I understand the parent correctly, we said that DirectX development in Wine froze because there was someone else developing it and promising to return the code (presumably, they wanted to avoid duplicated efforts, a reasonable thing to do).
If that's true, GPL would have prevented the situation: either Cedega would write the DirectX code and be required to return it as promised, or they wouldn't start writing it and would not promise anything (thus avoiding the freeze by Wine developers).
(Well, I suppose they could promise to develop it and do nothing, but that is simply trolling and can happen with any license.)
(now I wish there was some alternative version of the LGPL that forced derivative work to REMAIN in that license so that people could use it in proprietary products - but still giving back any changes to the library itself - so we could avoid bad moves like the MySQL one. Best of both worlds, eh?)
That's not possible.
Simply put, the copyright law says: the copyright owner of the code (in this case, the MySQL guys) can do whatever they want with the code, and no one else can do anything[*] with it except with their permission. The MySQL guys chose to allow everyone to use their code as described by the LGPL. Later, they changed their minds and said: from now on, our new versions will not be available as described by LGPL; now we choose GPL.
In summary, because of the copyright law there can't possibly exist a license that binds the copyright owner to some license -- they can always choose whatever license they want to distribute the code (or they can choose to not distribute it).
Note, however, that what the MySQL people did not revoke the old license, they changed the license for the new versions of their code.
No, it *does* weight exactly 12 grams; that's the definition of the Avogadro's number.
And while you're right that neutrons and protons have different mass, that's not the only complication. For example, the nucleus of an Helium atom has less mass then two nuclei of Hydrogen and two neutrons separated -- the difference is the amount of energy you get when you do Hydrogen fusion (well, *actual* Hydrogen fusion is a little more complicated).
While that's true, it also misses an important point: the guarantee that you're talking to the same person certificate was signed to by the CA.
If you accept a self-signed certificate, you can never be sure who you're talking to -- maybe someone intercepted the communication and generated a different self-signed certificate.
Using SSL without checking your peer's certificate is useless, as it enables MITM attacks (see this Wikipedia article). This brings us back to the problem of managing keys (or certificates, or whatever).
But I think you mean "it is possible to solve a cube from any arbitrary configuration in no more than N moves, where N is 21, 22 or 23". If it starts out only 1 move away from completion, I don't really just have twiddle it round an extra 20 moves, do I?
Yes, you're right, the "no more than" makes it clearer (that's what it was intended to mean). Of course there are configurations that don't need more than N moves (for N < 21), you can make them by starting with a solved cube and make N rotations (as with your 1 move example).
I'm speaking here as an amateur Nintendo DS developer with some experience with DevkitPro, the "toolchain" made by some guys to run stuff on Gameboy Advance, Nintendo DS, Gamecube and recently Wii, among others. I have no direct experience with Wii developing, but I think I can help you a little...
* Which programming language can I use? I am guessing C/C++ is supported?
The "toolchain" is called "DevkitPPC" (a part of DevkitPro, which is available here) consists of GCC and some other utilities (many from GNU) and libraries to generate ELF executables that the Wii can run. So, basically, C and C++ are supported.
I don't know about the last version, but they're working daily on the CVS mainly with Wii updates, so expect the next version (r15) to be very nice. All this is available as a Windows installer, or you can get binaries (or the source) for Linux. I remember seeing something for OSX, but I don't know how it is nowadays.
* Which UI library exist? Is there support for input devices, can I also output text and images?
* Which network library exist? Can I use internet/WLAN connection, can I use Berkeley sockets API?
* Are there existing example applications? Not only "hello world"... maybe something more complex?
The libraries for the NDS are very low-level stuff, with very recent additions towards higher-level stuff; so I'd imagine the Wii stuff is still very low-level.
There are some Wii examples to get you started. I don't know if the main packages include them, you can grab them here if not.
Finally, if you start developing for the Wii, expect to visit forums, dig up information on IRC and generally learn *very* low-level stuff to do anything beyond a simple "hello world".
Hey, lighten up, it was a joke. The part you didn't understand was the output of the "diff" command saying:
"1c1": the difference was that the line 1 in the first file changed to the line 1 in the second file, and the difference is:
"< " [in the first file we had this:] "Java"
"> " [and in the second file it became this:] "JavaScript"
See, now that it had to be explained, it's not funny. Well, it wasn't funny to begin with.
And, since I just wasted 5 minutes writing and formatting this, here's the link so you don't have to use Google: man diff (feel free to ignore it if you don't really want to learn about diff). I always use "diff -u" myself (I find the output more readable).
Well, except from the prototyped-based OO, JavaScript is roughly Scheme minus macros plus C-like syntax.
So, JavaScript at least supports some type of functional programming (much more than, say, Java). You can easily write in it all the "standard" higher-order-functions like map, fold, filter, etc.
Exceedingly off-topic, I known: the thing that prevents me from really using it is its scoping brain damage. Local variables are local to the whole function, so when I find myself wanting to write (function(x){...})(1) to create a new "x", I give up and go back to Lua or Scheme.
Would you agree that a physical theory being "correct" is equivalent to a physical theory being "standards compliant" where the standard is reality?
Oh, come on.
The web "standards" specify what exactly is required for an "agent" to comply (for example, in the CSS 2.1, the section 3 defines the conformance requirements).
So, I might agree that right and wrong may not be absolute for theories explaining reality (and I do!). But being compliant to a standard that specifically tells you that is needed to comply *is* absolute.
BTW, thanks for the link. I'm an Asimov fan, and I hadn't seen that yet.
But doesn't this mean that you also must pass the start and end of the allocated region together every time you pass a pointer to a function? If that's acceptable for your project, maybe you don't really need C after all... (at least from my admittedly limited experience).
The constant addressing limitation is also really... eh, limiting. Embedded code usually do things like this (based on code for a game console):
Now, I wouldn't give a calculator to a 6 year old kid while they were practicing mental arithmetic but that's only one facet of mathematics.
I think that the point being made is that you would expect a 6 year old to understand how the calculator computes -- by doing the math on paper, not in their head -- before giving him a calculator. By the same token, you would expect someone to understand how the computer does things before turning them to Java.
Slashdot Mirror
So basically, this would mean a large number of the worlds finest mathematicians are working tirelessly to create something that is by definition mathematically impossible.
Yes, discounting the redefinition of impossible, it would mean that. :-)
Can't a quantum computer [...] break any encryption instantly by only actually arriving at the destination assigned?
No. Quantum computers can theoretically solve some problems faster than classical computers. Among these (and perhaps most famously) is factoring -- see Shor's Algorithm. Fast factorization breaks RSA encryption, which is what everyone uses.
It is not known whether quantum computers can in general solve problems exponentially faster than classical ones. Further, it is not known for most important problems how to take advantage of quantum computers to achieve dramatic speedups (or even if it's possible). It seems that NSA and the Army want to know more about this.
If you assume something has only a metaphysical or religious explanation, you can't advance your understanding. So, it's at least useful to assume there is a rational explanation, and try to find it.
I know you're exaggerating, but didn't browsers do that for forms submitted via POST? I don't know if they still do (it's been a while since I don't install a browser in a new computer), but I remember that one of the first things to do then using a new browser was to mark the "don't bug me about this anymore checkbox" and click OK.
By the way, I don't completely dislike the idea of allowing self-signed certificates but not showing the green "secure" icon. But I think it might be better to make that a "new" protocol that behaves exactly as https except that it accepts (perhaps silently) self-signed certificates (maybe call it "httpe", for "encrypted"). That way, there's less possibility of confusion between sites that are really secure and sites that just use encryption but are theoretically vulnerable to MITM attacks.
That's not the point; it doesn't matther what the protocol says.
What matters is the user's expectation. Unfortunately, today people expect "https" to be secure enough to send their bank password or credit card number. It's very hard to explain the nuances of encryption and authentication to someone who just wants to shop online.
My unrealistic solution that will never be implemented: create a new protocol that uses SSL/TLS exactly as https, but silently accepts non-verified certificates. Maybe call it httpe ("e" means encrypted). Then teach people than "https" is for using banks and online shopping, "httpe" is for other stuff that is nice to have encrypted but nothing too bad will happen if someone happens to see.
And the theorems it can't prove are all stuff like, "This statement cannot be proven."
While that might be true in some sense, that's not the whole story. As an example of an useful such theorem, Matiyasevich (using various people's results) has shown that there's no way to prove if certain Diophantine equations have solutions or not.
Strictly speaking, all this means is that you can write a Diophantine equation that encodes some statement like the one you stated. But this doesn't detract from the original point: there still exists some Diopnhantine equation for which we can't prove the existence of solutions (or lack thereof) in the set of axioms known as ZFC, and that's interesting in itself.
Well, according to section 7.2 of the C# Language Specification, operands are evaluated from left to right, so the result is what I would have expected:
I don't disagree with you, but I don't see how that relates to this case (I have read http://www.xenu.net/copyright.html, I assume that's what you're talking about.)
In the software world, copyright restriction is the norm. For instance, you simply can not copy Microsoft software (or even install it in your computer) unless you buy it from them (they call it "licensing"). That's broadly accepted, no one really disputes that. What people dispute is that copyright was initially intended for a different purpose that what it's being used today.
The GPL (and other licenses) are chosen by authors because they want to be less restrictive than that. You're free to not accept the GPL, but then you're back to not being able to copy (or change, distribute, etc.) the software.
Erm... he said, not we said...
You mean, the issue that users get functionality years earlier than they would have if the project had been GPL?
If I understand the parent correctly, we said that DirectX development in Wine froze because there was someone else developing it and promising to return the code (presumably, they wanted to avoid duplicated efforts, a reasonable thing to do).
If that's true, GPL would have prevented the situation: either Cedega would write the DirectX code and be required to return it as promised, or they wouldn't start writing it and would not promise anything (thus avoiding the freeze by Wine developers).
(Well, I suppose they could promise to develop it and do nothing, but that is simply trolling and can happen with any license.)
(now I wish there was some alternative version of the LGPL that forced derivative work to REMAIN in that license so that people could use it in proprietary products - but still giving back any changes to the library itself - so we could avoid bad moves like the MySQL one. Best of both worlds, eh?)
That's not possible.
Simply put, the copyright law says: the copyright owner of the code (in this case, the MySQL guys) can do whatever they want with the code, and no one else can do anything[*] with it except with their permission. The MySQL guys chose to allow everyone to use their code as described by the LGPL. Later, they changed their minds and said: from now on, our new versions will not be available as described by LGPL; now we choose GPL.
In summary, because of the copyright law there can't possibly exist a license that binds the copyright owner to some license -- they can always choose whatever license they want to distribute the code (or they can choose to not distribute it).
Note, however, that what the MySQL people did not revoke the old license, they changed the license for the new versions of their code.
[*] Well, except what's described as "fair use".
No, it *does* weight exactly 12 grams; that's the definition of the Avogadro's number.
And while you're right that neutrons and protons have different mass, that's not the only complication. For example, the nucleus of an Helium atom has less mass then two nuclei of Hydrogen and two neutrons separated -- the difference is the amount of energy you get when you do Hydrogen fusion (well, *actual* Hydrogen fusion is a little more complicated).
I hope a learned CS major can provide the link, as I'm drawing a blank on the author.
I'm not sure, but perhaps you mean this piece by Joel Spolsky?
(Note: I'm not a learned CS major, so I hope I'm eligible to provide the link.)
While that's true, it also misses an important point: the guarantee that you're talking to the same person certificate was signed to by the CA.
If you accept a self-signed certificate, you can never be sure who you're talking to -- maybe someone intercepted the communication and generated a different self-signed certificate.
Using SSL without checking your peer's certificate is useless, as it enables MITM attacks (see this Wikipedia article). This brings us back to the problem of managing keys (or certificates, or whatever).
Yes, you're right, the "no more than" makes it clearer (that's what it was intended to mean). Of course there are configurations that don't need more than N moves (for N < 21), you can make them by starting with a solved cube and make N rotations (as with your 1 move example).
Well, he did say any arbitrary configuration.
It is currently known that there is at least one configuration that is not solvable in 20 moves or less.
The point being: it is possible to solve a cube from any arbitrary configuration in N moves, where N is 21, 22 or 23 (it's not yet known which).
I'm speaking here as an amateur Nintendo DS developer with some experience with DevkitPro, the "toolchain" made by some guys to run stuff on Gameboy Advance, Nintendo DS, Gamecube and recently Wii, among others. I have no direct experience with Wii developing, but I think I can help you a little...
The "toolchain" is called "DevkitPPC" (a part of DevkitPro, which is available here) consists of GCC and some other utilities (many from GNU) and libraries to generate ELF executables that the Wii can run. So, basically, C and C++ are supported.
I don't know about the last version, but they're working daily on the CVS mainly with Wii updates, so expect the next version (r15) to be very nice. All this is available as a Windows installer, or you can get binaries (or the source) for Linux. I remember seeing something for OSX, but I don't know how it is nowadays.
The libraries for the NDS are very low-level stuff, with very recent additions towards higher-level stuff; so I'd imagine the Wii stuff is still very low-level.
There are some Wii examples to get you started. I don't know if the main packages include them, you can grab them here if not.
Finally, if you start developing for the Wii, expect to visit forums, dig up information on IRC and generally learn *very* low-level stuff to do anything beyond a simple "hello world".
Hey, lighten up, it was a joke. The part you didn't understand was the output of the "diff" command saying:
See, now that it had to be explained, it's not funny. Well, it wasn't funny to begin with.
And, since I just wasted 5 minutes writing and formatting this, here's the link so you don't have to use Google: man diff (feel free to ignore it if you don't really want to learn about diff). I always use "diff -u" myself (I find the output more readable).
Well, except from the prototyped-based OO, JavaScript is roughly Scheme minus macros plus C-like syntax.
So, JavaScript at least supports some type of functional programming (much more than, say, Java). You can easily write in it all the "standard" higher-order-functions like map, fold, filter, etc.
Exceedingly off-topic, I known: the thing that prevents me from really using it is its scoping brain damage. Local variables are local to the whole function, so when I find myself wanting to write (function(x){...})(1) to create a new "x", I give up and go back to Lua or Scheme.
Oh, come on.
The web "standards" specify what exactly is required for an "agent" to comply (for example, in the CSS 2.1, the section 3 defines the conformance requirements).
So, I might agree that right and wrong may not be absolute for theories explaining reality (and I do!). But being compliant to a standard that specifically tells you that is needed to comply *is* absolute.
BTW, thanks for the link. I'm an Asimov fan, and I hadn't seen that yet.
OK, thanks, I see the feasibility of this scheme.
But doesn't this mean that you also must pass the start and end of the allocated region together every time you pass a pointer to a function? If that's acceptable for your project, maybe you don't really need C after all... (at least from my admittedly limited experience).
The constant addressing limitation is also really... eh, limiting. Embedded code usually do things like this (based on code for a game console):
Granted, a game console is not the place to use such compiler, but don't most embedded programming involve things like this?
Anyway, that's a cool idea, but I think I see why it's not more widely used...
You're assuming every pointer references a malloc-ed area. While (the equivalent of) this is true for Java, things simply don't work like this in C.
Consider:
I think that the point being made is that you would expect a 6 year old to understand how the calculator computes -- by doing the math on paper, not in their head -- before giving him a calculator. By the same token, you would expect someone to understand how the computer does things before turning them to Java.
I agree with the rest of your comment, though.
Why would you do that? The bottleneck in file copy is I/O, not CPU. A multi-thread file copy will just make more CPUs wait for the hard drive(s).