Of course the correct way to do it would be to multiply the information of the LoC with k*T ln 2 where k = Boltzmann constant, T = temperature of the Library, ln 2 to change from base 2 logarithm (information entropy) to natural logarithm (thermodynamic entropy).
Let's take the 20 million volumes * 200 pages from your calculation, and assume 250 words per page, 4.5 letters per word and 1.4 bits per letter (see directly above table 1, the value for longer text; I've taken the middle, rounded up). With this data, we get a total information content of the LoC of 6.3*10^12 bits. Let's further assume the temperature of LoC is about 290K, then we get the energy equivalent of the LoC as about 0.11 TeV.
Requires some knowledge of the many worlds interpretation or the anthropic principle though.
Of course, according to MWI, you are killed all the time even without the LHC. After all, if it can happen, and be it with absurdly low probability, then it will happen in some world. There are worlds where the whole earth collapses into a black hole not because of some LHC experiment, but just due to an unusually large quantum fluctuation. There are worlds where is just happens that no oxygen molecule finds its way into your nose for several minutes, and you suffocate. There are worlds where the nucleons in your body just tunnel into a new configuration, and you turn into a block of lead. Or into a heap of gold dust. There are worlds where an asteroid hits you just now, and others where an earth-destroying asteroid just hits. And there are worlds where all that happens at the same time.
Well, since there was no link to the original article, I only can guess. But since they said that the circuit can also read out, I guess they just read out the quantum that "was and wasn't" in the oscillator, and then they examined the resulting current (maybe using some circuit QED stuff).
Which of course only shifts the question how you analyse a superposition in another system. Well, the trick is that there are certain operations which turn a specific superposition into a measurement basis state (and the corresponding definite state into a superposition). Then you just have to measure that you indeed have that measurement basis state. Alternatively you transfer it to a system where you can measure those states directly, e.g. for electron spin, a superposition of "up" and "down" just corresponds to a definitive state in another direction, e.g. "left" or "right". So if you prove that your electron is in a "left" state, you know for sure it is in a superposition of "up" and "down".
but considering the standard of journalism in public tv, scientology hasn't much of a chance to pull that documentary off the air.
According to the Spiegel article (second link), it's not a documentary, but a drama based on a true case. Since a non-documentary is usually expected to contain fictional elements, I guess that makes it much harder to legally fight it.
There are some non-obvious things in there, such as trying things that clearly won't work, if asked to by the programmer:
Somebody reported a bug to me once, and I asked him to try a command that I knew wouldn't work. The reason I asked him to try it was that I wanted to know which of two different error messages it would give. Knowing which error message came back would give a vital clue. But he didn't actually try it - he just mailed me back and said "No, that won't work". It took me some time to persuade him to try it for real.
In that case, the developer failed to communicate relevant information. He should have explicitly said from the beginning that he needs the text of the error message to diagnose what the problem is.
'The Internet cannot be something open where anything is said and done.
That's the definition of the internet. An open communications network where anything can be said and done.
Really? Wikipedia defines it as "a global system of interconnected computer networks that use the standard Internet Protocol Suite (TCP/IP) to serve billions of users worldwide."
Well, at least ZX BASIC was the best BASIC I've ever seen. In which other BASIC could you put Formulas in strings and evaluate them at runtime, without writing a specialized formula interpreter yourself?
I'm no assembler expert, but I think PUSH alters the stack pointer, RET uses the frame pointer to find the return address and that has been unaltered...
There's no such thing as a frame pointer at the hardware level on x86, as far as I'm aware. PUSH, POP, CALL and RET all use the stack pointer.
By convention, BP is used as the frame pointer on x86. But it isn't directly done by the CPU, but has to be explicitly set up by the function prolog/epilog (basically copying the stack pointer to BP and back) and often is omitted by functions not using local variables. RET indeed reads the address through the stack pointer; the only special thing about BP is that addressing through it by default uses the stack segment register (this doesn't matter for the usual flat memory model used today, but it mattered for 16 bit code, and shows that indeed this usage of BP was intended by the x86 designers). Basically, RET is a "POP (E)IP".
I think what you are missing is that this isn't either or. They are against lack of freedom on all fronts. They are against DRM (locked BIOS), and they are against locked (proprietary) software.
And I don't have an issue with that. I only have an issue with making wrong arguments to this goal. BTW, setting a password on the BIOS IMHO doesn't count as DRM. After all, it's not the vendor who sets the password.
Both are parts of the same problem that led to this.
This is where I disagree. First, without lock down, even the proprietary OS X would have allowed them to disable the webcam. Second, even with Linux, they could have locked down the computer.
Free software has a big advantage when it comes to trusting the software vendor. It's not very relevant when it comes to trusting the computer owner (i.e. in this case, the school). In that case, lockdown is the issue.
Mac or not (lots of schools use laptops, not all mac), the fact is that students are not in a position to remove untrusted software through a re-install since they don't have installation media.
Buying a copy of Windows or OS X in a shop is completely legal as well. Yes, it will cost you money, but that's a completely unrelated issue. Also, without lockdown there would be no reason why you couldn't just make a hard disk image of the existing system, install and use Linux, and then put the hard disk image back before returning the computer.
But again, and this time in bold:
FTA does not talk about fixing things after having detected that something bad is going on, it talks about finding out whether something bad is going on in the first place.
I'm not going to quote the relevant parts again.
And yes, BIOS lockdown is exactly relevant in the discussion. After all, the problem wasn't that OS X didn't allow to disable the webcam, the point was that this option was locked down. That's the whole point. The laptops were locked down, and they almost certainly would have been locked down as well even if they had been running Linux. The problem was not about proprietary vs. free, the problem was of locked-down vs. open. The author argued that it is about free vs. proprietary, which is besides the point.
Note that giving wrong arguments for free software actually harms free software, as it gives opponents examples of bad arguments for it, which they can use to give the impression that all arguments for free software were that bad, which they of course aren't. IMHO it is the responsibility of the free software advocates (and especially the FSF) to make sure their arguments remain reasonable, so they don't destroy the credibility of the reasonable arguments through unreasonable ones.
If a student had a supposedly non-trusted debian install on their laptop, they would have recourse. Re-install it.
This is besides the point. The point isn't that you can't do anything about it after you detected it. Covering up the web cam was an easy fix for that specific problem; using another laptop is an ultimate recourse for any problem with a given laptop. If you argue they might not be allowed to use another laptop, I'll answer that they are most likely not allowed to reinstall Debian as well. Indeed, they would likely come with booting from external media disabled and BIOS password set. You'd most certainly not be allowed to physically open that laptop, so no hardware BIOS password reset.
But again, that wasn't really the point. The point is detecting whether you can trust the current installation in the first place. To quote TFA again: When the software on your computer is proprietary, then you can't know whether the light is coming on because of a glitch or because the camera is actually running. You can't tell if your hard drive is spinning because you're using it, or because someone else is using it. Only free software gives you the freedom to find the answers to these questions. The point is, even with free software you cannot find the answers to those questions if you are not given the necessary privileges. Yes, you can just assume the worst and act accordingly (as those who covered the webcam with tape did).
With windows this would be hard. They would need recovery disks (which are different for every laptop sometimes) and all of the proprietary software disks that need to be loaded later.
Given that in the concrete case it was Mac computers, it's completely irrelevant how hard or easy it is to reinstall Windows. More generally, this is about general free vs. proprietary; any deficiencies of specific proprietary software are irrelevant for this discussion (as are any deficiencies of specific free software).
When the software on your computer is proprietary, then you can't know whether the light is coming on because of a glitch or because the camera is actually running. Unless you both know programming and have lots of time to dig into the code, you don't know either (and even then, the machine might have been manipulated already at the BIOS level, and may be hiding the changes from you).
But even more to the point: The original source he quotes explains: The webcam couldn't be disabled due to tough security settings. That is, the students had not been given all the control the operating system could provide them. The exact same could have happened under Linux, if they had not been given root privileges, or if the root rights were restricted through SELinux. Free Software doesn't magically get you into control of a system (inded, I'd have more control over a machine running a proprietary DOS than over one running Linux where I don't have root privilege).
Finally, I think you may be a bit confused. In x86 (and x64) assembly at least, there's no such thing as a partial op-code. Each instruction is one or more bytes and the CPU doesn't just skip over invalid data as some did (like some 6502 variants). So you can't change any bit in an op-code or you'll change what that op-code is and thus what it does. For example 74 is JZ, jump to the address (specified afterward) if the zero flag is set. 75 is JNZ, jump to the address if the zero flag is NOT set. Change one bit, changes the whole meaning of the instruction. You can't fiddle with parts and have a different op-code that does the same thing.
All the following sequences do an unconditional jump:
; sequence 0 JMP dest
; sequence 1 JZ dest JNZ dest
; sequence 2 JNZ dest JZ dest
; sequence 3 JC dest JNC dest
; sequence 4 JNC dest JC dest
; sequence 5 JB dest JE dest JA dest
; sequence 6 PUSH dest RET
Note that any difference in length can be made up with either preceding (effective) NOPs (there are many possibilities there, too) or with following junk (it's an unconditional jump; anything directly following isn't executed anyway). Also note that the destination address can be varied if the destination starts with some (effective) NOPs, or if you have jump instructions to that address at other positions.
And all that is just what I could immediately think of. I'm sure someone who spends considerable time on designing such stuff would find many more ways to vary the code.
Slashdot Mirror
Probably because Funny doesn't earn you Karma.
Or maybe the moderator just misclicked. Shit happens.
Of course the correct way to do it would be to multiply the information of the LoC with k*T ln 2 where k = Boltzmann constant, T = temperature of the Library, ln 2 to change from base 2 logarithm (information entropy) to natural logarithm (thermodynamic entropy).
Let's take the 20 million volumes * 200 pages from your calculation, and assume 250 words per page, 4.5 letters per word and 1.4 bits per letter (see directly above table 1, the value for longer text; I've taken the middle, rounded up). With this data, we get a total information content of the LoC of 6.3*10^12 bits. Let's further assume the temperature of LoC is about 290K, then we get the energy equivalent of the LoC as about 0.11 TeV.
Therefore 3.5 TeV is about 32 LoC.
http://www.everything2.com/title/Stop+killing+me+now
Requires some knowledge of the many worlds interpretation or the anthropic principle though.
Of course, according to MWI, you are killed all the time even without the LHC. After all, if it can happen, and be it with absurdly low probability, then it will happen in some world. There are worlds where the whole earth collapses into a black hole not because of some LHC experiment, but just due to an unusually large quantum fluctuation. There are worlds where is just happens that no oxygen molecule finds its way into your nose for several minutes, and you suffocate. There are worlds where the nucleons in your body just tunnel into a new configuration, and you turn into a block of lead. Or into a heap of gold dust. There are worlds where an asteroid hits you just now, and others where an earth-destroying asteroid just hits. And there are worlds where all that happens at the same time.
Well, since there was no link to the original article, I only can guess. But since they said that the circuit can also read out, I guess they just read out the quantum that "was and wasn't" in the oscillator, and then they examined the resulting current (maybe using some circuit QED stuff).
Which of course only shifts the question how you analyse a superposition in another system. Well, the trick is that there are certain operations which turn a specific superposition into a measurement basis state (and the corresponding definite state into a superposition). Then you just have to measure that you indeed have that measurement basis state. Alternatively you transfer it to a system where you can measure those states directly, e.g. for electron spin, a superposition of "up" and "down" just corresponds to a definitive state in another direction, e.g. "left" or "right". So if you prove that your electron is in a "left" state, you know for sure it is in a superposition of "up" and "down".
I wonder which makes more money, L. Ron, or the pharmaceutical companies. My money is with the pharmaceutical companies.
That's a sure bet, because L. Ron is dead. Dead people don't make money.
My guess is that it's the size of a cat.
Mine is 42840 bytes.
Isn't this when somebody is supposed to chime in with a meme?
In Korea only old people use film? ...
In Soviet Russia film uses you?
Or maybe just imagine a Beowulf cluster of hacked Canon cameras
According to the Spiegel article (second link), it's not a documentary, but a drama based on a true case. Since a non-documentary is usually expected to contain fictional elements, I guess that makes it much harder to legally fight it.
All of them are deficient: None lets you set the weather.
You forgot the most important part of designing an AI: Whatever you want it to do has to be what it likes doing most.
Here's some advice that I find useful when reporting bugs:
http://www.chiark.greenend.org.uk/~sgtatham/bugs.html
There are some non-obvious things in there, such as trying things that clearly won't work, if asked to by the programmer:
Somebody reported a bug to me once, and I asked him to try a command that I knew wouldn't work. The reason I asked him to try it was that I wanted to know which of two different error messages it would give. Knowing which error message came back would give a vital clue. But he didn't actually try it - he just mailed me back and said "No, that won't work". It took me some time to persuade him to try it for real.
In that case, the developer failed to communicate relevant information. He should have explicitly said from the beginning that he needs the text of the error message to diagnose what the problem is.
You mean, we should start to stock ARM netbooks?
'The Internet cannot be something open where anything is said and done.
That's the definition of the internet.
An open communications network where anything can be said and done.
Really? Wikipedia defines it as "a global system of interconnected computer networks that use the standard Internet Protocol Suite (TCP/IP) to serve billions of users worldwide."
Sure. And nobody intended to build a wall ...
Well, at least ZX BASIC was the best BASIC I've ever seen. In which other BASIC could you put Formulas in strings and evaluate them at runtime, without writing a specialized formula interpreter yourself?
Quite a few scientific articles published in peer-reviewed journals. What about you?
But not the passwords.
I'm no assembler expert, but I think PUSH alters the stack pointer, RET uses the frame pointer to find the return address and that has been unaltered...
There's no such thing as a frame pointer at the hardware level on x86, as far as I'm aware. PUSH, POP, CALL and RET all use the stack pointer.
By convention, BP is used as the frame pointer on x86. But it isn't directly done by the CPU, but has to be explicitly set up by the function prolog/epilog (basically copying the stack pointer to BP and back) and often is omitted by functions not using local variables. RET indeed reads the address through the stack pointer; the only special thing about BP is that addressing through it by default uses the stack segment register (this doesn't matter for the usual flat memory model used today, but it mattered for 16 bit code, and shows that indeed this usage of BP was intended by the x86 designers). Basically, RET is a "POP (E)IP".
And I don't have an issue with that. I only have an issue with making wrong arguments to this goal. BTW, setting a password on the BIOS IMHO doesn't count as DRM. After all, it's not the vendor who sets the password.
This is where I disagree. First, without lock down, even the proprietary OS X would have allowed them to disable the webcam. Second, even with Linux, they could have locked down the computer.
Free software has a big advantage when it comes to trusting the software vendor. It's not very relevant when it comes to trusting the computer owner (i.e. in this case, the school). In that case, lockdown is the issue.
Buying a copy of Windows or OS X in a shop is completely legal as well. Yes, it will cost you money, but that's a completely unrelated issue. Also, without lockdown there would be no reason why you couldn't just make a hard disk image of the existing system, install and use Linux, and then put the hard disk image back before returning the computer.
But again, and this time in bold:
FTA does not talk about fixing things after having detected that something bad is going on, it talks about finding out whether something bad is going on in the first place.
I'm not going to quote the relevant parts again.
And yes, BIOS lockdown is exactly relevant in the discussion. After all, the problem wasn't that OS X didn't allow to disable the webcam, the point was that this option was locked down. That's the whole point. The laptops were locked down, and they almost certainly would have been locked down as well even if they had been running Linux. The problem was not about proprietary vs. free, the problem was of locked-down vs. open. The author argued that it is about free vs. proprietary, which is besides the point.
Note that giving wrong arguments for free software actually harms free software, as it gives opponents examples of bad arguments for it, which they can use to give the impression that all arguments for free software were that bad, which they of course aren't. IMHO it is the responsibility of the free software advocates (and especially the FSF) to make sure their arguments remain reasonable, so they don't destroy the credibility of the reasonable arguments through unreasonable ones.
This is besides the point. The point isn't that you can't do anything about it after you detected it. Covering up the web cam was an easy fix for that specific problem; using another laptop is an ultimate recourse for any problem with a given laptop. If you argue they might not be allowed to use another laptop, I'll answer that they are most likely not allowed to reinstall Debian as well. Indeed, they would likely come with booting from external media disabled and BIOS password set. You'd most certainly not be allowed to physically open that laptop, so no hardware BIOS password reset.
But again, that wasn't really the point. The point is detecting whether you can trust the current installation in the first place. To quote TFA again:
When the software on your computer is proprietary, then you can't know whether the light is coming on because of a glitch or because the camera is actually running. You can't tell if your hard drive is spinning because you're using it, or because someone else is using it. Only free software gives you the freedom to find the answers to these questions.
The point is, even with free software you cannot find the answers to those questions if you are not given the necessary privileges. Yes, you can just assume the worst and act accordingly (as those who covered the webcam with tape did).
Given that in the concrete case it was Mac computers, it's completely irrelevant how hard or easy it is to reinstall Windows. More generally, this is about general free vs. proprietary; any deficiencies of specific proprietary software are irrelevant for this discussion (as are any deficiencies of specific free software).
OK, the AC is trolling, but assuming it is being serious (it's hard to tell sometimes when it comes to libertarianism):
What form should this "enforcement" take?
I think the Mafia has developed quite a few methods of private enforcement. Maybe you could license them from there. :-)
And was the machine actually built according to those specs? Did he verify it?
The author is completely besides the point:
When the software on your computer is proprietary, then you can't know whether the light is coming on because of a glitch or because the camera is actually running.
Unless you both know programming and have lots of time to dig into the code, you don't know either (and even then, the machine might have been manipulated already at the BIOS level, and may be hiding the changes from you).
But even more to the point: The original source he quotes explains:
The webcam couldn't be disabled due to tough security settings.
That is, the students had not been given all the control the operating system could provide them. The exact same could have happened under Linux, if they had not been given root privileges, or if the root rights were restricted through SELinux. Free Software doesn't magically get you into control of a system (inded, I'd have more control over a machine running a proprietary DOS than over one running Linux where I don't have root privilege).
All the following sequences do an unconditional jump:
Note that any difference in length can be made up with either preceding (effective) NOPs (there are many possibilities there, too) or with following junk (it's an unconditional jump; anything directly following isn't executed anyway). Also note that the destination address can be varied if the destination starts with some (effective) NOPs, or if you have jump instructions to that address at other positions.
And all that is just what I could immediately think of. I'm sure someone who spends considerable time on designing such stuff would find many more ways to vary the code.