The big winners weren't today, they were the insider options trades that executed long before the news was public. See Who Knew What When for some of that. The SEC won't do anything, since some of those trades are likely to have high political connections. When Congress won't stop insider trading, no one in the SEC wants to rock that boat. They only take on little fish.
In Windows 7 at least, you can access the disk after a motherboard/TPM failure. I went through this when a firmware update destroyed the TPM in one of my Thinkpads. You can unlock the disk if you have the very long decryption key BitLocker shows you at initial setup.
3.10 is the next LTS kernel by Linux standards. The existing long term kernels are 2.6.32 (as used in RHEL6, Debian Squeeze, Ubuntu LTS 10.04), 2.6.34, 3.0, 3.2.50 (used in Ubuntu 12.04 LTS), and 3.4.59.
The logs of the machines that break are the most important part of the test results here. You can't just throw them away when a VM dies without losing most of the testing value. If you're lucky, a busted kernel will stay alive long enough to create a crash dump when running on dedicated hardware. That's less likely to happen on VMs.
It's also possible to automate hardware resets with IPMI or similar lights-out management code. All of that takes special hardware though, and test code like this is painful to build.
I work on PostgreSQL, and nothing goes out until it's been validated on the entire buildfarm. It's hard to have such a thing for the Linux kernel though, because it's so easy for a bug to break test machines. You need to catch when machines are responding, do a hardware reset, and then rollback to a known good kernel instead. It's much harder than most software testing to automate.
If someone offers you a "free beer", that's getting something most people expect to pay for, but for free. That's what "free as in beer" is alluding to. You shouldn't call other people idiots just because you don't understand what they are saying.
This is similar to the AudioQuest K2 reviews, which includes the funniest single review I've ever seen there--starting with "We live underground. We speak with our hands. We wear the earplugs all our lives."
CICO does not work in the long term for the majority of people. Everyone who has statistics says so. The idea that it's useful is a pop culture phenomenon. Most of the weight loss in the first few months of an exercise program are water.
Both diet and exercise changes can lose fat that way for a while. Your body will fight you to return the lost weight eventually though. There's really no proof CICO works at all in the long term. There's a long list of studies debunking each angle of the problem (and how the wrong ideas spread) detailed in "Why We Get Fat: And What to Do About It" by Gary Taubes I can't do justice to here. Data since that was published, like the 2011 Harvard study results, continue to show CICO is busted in all kinds of ways as a useful model.
Counting calories and/or exercising doesn't work. Never had, never will. Your body's fat regulation has too many feedback mechanisms for varying calories to matter very much. Check out "Why We Get Fat: And What to Do About It" by Gary Taubes if you want to get a referenced look at debunked ideas in this area.
There is a long list of patents and technologies that went into WiFi. CSIRO's patent only covered one part of that, so it's not the case that their chunk represents all the inventor royalties here.
The version of events you're describing didn't happen. There was no "convergent evolution". CSIRO spin-off Radiata was involved in creating the standard. See the Register article. There's a license letter proving the IEEE was fully aware of CSIRO patent and its impact on the 802.11a standard. If you look at the letters of assurance list, there was a long list of such agreements hammered out as part of the standardization process. Given all that, the idea that CSIRO's technology was obvious and easily duplicated isn't true either, so your US patent system flamebait is unsupported by this example. The only part you got right here is that CSIRO's role as a research lab that spins off commercial products does not make them a patent troll.
You're focused on a crack of one function in this sort of program. Given enough time, it is always possible to map all the inputs and outputs of a function, and therefore replace it with another that does the same thing--but with a change like a crack installed. The question, though, is how much time will it take?
There's not an easy to spot boolean on the line here; we're past when idiots built these things now. Let's say the output from the DRM checker is a 1024 bit key that unlocks the next function in the chain. It works right now; run it again and pseudo-random behavior means you'll get a different one. Saving the key itself will do you no good. To crack the program, you need to figure out how the DRM checker creates these 1024 keys from its inputs.
If that code is obfuscated enough, the only way to reverse engineer it is to use a "black box" approach. You inject all possible inputs, observe outputs, and then you know what the function does. The claim of the paper is that their way of constructing these functions means mapping all of the inputs and outputs well enough to duplicate the function can be made arbitrarily hard. Yes, you can do it. But if there are enough layers that all have to be carefully unwrapped function at a time, mapping all inputs and resulting outputs, that the time to do the work can be made a lot longer than people expect now.
You can make the algorithm as complex as you'd like, but at the end of the day, you have an input and output(s). You may decide to take a long time to get there, but at the end of the day, I know what you did when the code ran.
This is referred to as "black-box" reverse engineering in the paper. You know what the code did for one input. And if you injected every possible input to the program, at the end you'd have worked out a complete specifications for the function. But how long will that take? It's not always "the end of the day". For functions with a wide range of inputs, it could take the life of the universe to map them all unless you know what you're looking for in advance.
Right now, obfuscation approaches for software usually have some small chocking point to attack. It might be an encryption wrapper around the main binary. Bust that with a debugger, you can get to unobfuscated code for the main system, and then really start to work your way through the program.
But if you have to fight this every step of the way, where all you do is inject inputs and get an output to figure out what the program does, it will take you forever to reverse engineer things. That's the claim of the paper. The code itself is so obfuscated that you can't read it straight and understand it, ever. It looks like random junk. All you can do is run it with an input and see what comes back, and from that reverse engineer what it does. Assemble enough of those and you can see how the program really works. But that black box teardown process--determining possible inputs, injecting them, collecting outputs, and then deriving the function behavior--is time intensive enough that it may not be practical to actually do it anymore. You don't learn anything from reversing any component that speeds handling the next; you have to attack them all like this.
There's a great line from the seminal paper on this subjectOn the (Im)possibility of Obfuscating Programs: "Any programmer knows that total unintelligibility is the natural state of computer programs (and one must work hard in order to keep a program from deteriorating into this state)" Extracting meaning from source code, being able to predict what some lines of code will do, it's hard. Ideally you'll just be able to read the code, make sense of it, and then reverse from there. Most systems that are thoroughly cracked have some sections where it's hard, but once you get those the remaining code is straightforward to read. And in fact, it's impossible to make something where you cannot reverse it. The question though is how long it will take.
If no sense is ever made of the code, you can only apply the "black-box" reverse engineering, where you inject inputs, watch outputs, and from there determine what the code does. You can't prevent that, but you can make the box so big that such work is impossible to do. That's what this technique tries to accomplish. You never find an easy part to the code you can read; all you ever find are ones where you have to map every input into an output to figure out what the code does.
A 64 bit address space can hold values up to 2 ^ 64 bits. There are only about 10 ^ 49 atoms on our planet. That's why it's not possible for a computer on Earth to exceed a 64 bit address space, which was the point being made by that joke. Even if you squeezed each bit down to taking a single atom, a system holding enough data to overflow a 64 bit address space would have to be the size of our solar system.
You're implying here that Microsoft's products here are only better due to their user base. That's not quite fair. The way Word allows leaving document comments, reviewing them, and even directly accepting edits is the best workflow for review around. Even OpenOffice trails pretty far behind in this area, the UI isn't nearly as slick. There's nothing I'm aware of that allows a similarly powerful editor feedback cycle for formatted documents. As a full time developer / part time writer, I'm fine with using a version control system for handling LaTeX diffs, treating proposed review changes like a source code branch merge. But even with full mastery of tools like git for that, it's still clearly inferior to the review tool chain in Word.
It's hard enough to get reviewers to look at things, provide feedback, and then usefully apply that feedback when it's clear and unambiguous what they are commenting on. If your review feedback annotation isn't very tightly tied to the original document, you're just wasting everyone's time. Good review feedback isn't in the form of scribbled notes. It's very tightly targeted to avoid ambiguity, and easy to merge back into the original document too. Every additional step put into the way makes the process less efficient and useful.
And good editor feedback includes suggestions on whether the formatting is helping communicate your message. Even when it's possible to use plain text, you're reducing the value of the editing by doing that. (It may not be feasible at all if the thesis is formula heavy)
My publisher takes in Word documents with a very limited style sheet set they provide, and then turn that into a typeset format without a labor intensive manual process in the middle. It is possible to use Word as a simpler tool to make automatic conversions simpler. There isn't very much style discipline in your average Word document though.
The main advantage of newer revision control software in this context is improved merging. If three people work on the same document, and you need to combine all those sets of changes, something like git is going to make that easier. Tools like Subversion that force a more linear flow are fine for when documents are formally passed between two parties, but they don't really scale up to lots of people working in parallel on things.
Separating text creation and formatting into two steps doesn't help with anything but very early editor review. Most of the really useful editing and review happens after formatting. Editing feedback should even include comments on whether the formatting is working usefully to improve the message quality.
Even if you did split these phases up more usefully on the document creation tool side, there are a good chunk of thesis works where the text without formatted equations isn't readable at all. The text side of documentation creation and editing can be a very small fraction of the total work in this sort of paper.
Slashdot Mirror
you can get a much cheaper experience unplugging if you go backpacking in a national park.
You can get an even cheaper experience by simply unplugging.
The big winners weren't today, they were the insider options trades that executed long before the news was public. See Who Knew What When for some of that. The SEC won't do anything, since some of those trades are likely to have high political connections. When Congress won't stop insider trading, no one in the SEC wants to rock that boat. They only take on little fish.
In Windows 7 at least, you can access the disk after a motherboard/TPM failure. I went through this when a firmware update destroyed the TPM in one of my Thinkpads. You can unlock the disk if you have the very long decryption key BitLocker shows you at initial setup.
3.10 is the next LTS kernel by Linux standards. The existing long term kernels are 2.6.32 (as used in RHEL6, Debian Squeeze, Ubuntu LTS 10.04), 2.6.34, 3.0, 3.2.50 (used in Ubuntu 12.04 LTS), and 3.4.59.
The logs of the machines that break are the most important part of the test results here. You can't just throw them away when a VM dies without losing most of the testing value. If you're lucky, a busted kernel will stay alive long enough to create a crash dump when running on dedicated hardware. That's less likely to happen on VMs.
It's also possible to automate hardware resets with IPMI or similar lights-out management code. All of that takes special hardware though, and test code like this is painful to build.
"the fun thing about a kernel is that there is no good way to test it except to run it" --Greg Kroah Hartman
I work on PostgreSQL, and nothing goes out until it's been validated on the entire buildfarm. It's hard to have such a thing for the Linux kernel though, because it's so easy for a bug to break test machines. You need to catch when machines are responding, do a hardware reset, and then rollback to a known good kernel instead. It's much harder than most software testing to automate.
Call it "The Ten" and allow people to only be friends with up to 10 people.
I've already got that, I just check my Friendster account.
Post what you know to their white-hate system
Facebook says that white hate also violates the TOS.
If someone offers you a "free beer", that's getting something most people expect to pay for, but for free. That's what "free as in beer" is alluding to. You shouldn't call other people idiots just because you don't understand what they are saying.
This is similar to the AudioQuest K2 reviews, which includes the funniest single review I've ever seen there--starting with "We live underground. We speak with our hands. We wear the earplugs all our lives."
CICO does not work in the long term for the majority of people. Everyone who has statistics says so. The idea that it's useful is a pop culture phenomenon. Most of the weight loss in the first few months of an exercise program are water.
Both diet and exercise changes can lose fat that way for a while. Your body will fight you to return the lost weight eventually though. There's really no proof CICO works at all in the long term. There's a long list of studies debunking each angle of the problem (and how the wrong ideas spread) detailed in "Why We Get Fat: And What to Do About It" by Gary Taubes I can't do justice to here. Data since that was published, like the 2011 Harvard study results, continue to show CICO is busted in all kinds of ways as a useful model.
Counting calories and/or exercising doesn't work. Never had, never will. Your body's fat regulation has too many feedback mechanisms for varying calories to matter very much. Check out "Why We Get Fat: And What to Do About It" by Gary Taubes if you want to get a referenced look at debunked ideas in this area.
When you order your Pentium 60, make sure you get a stepping with the FDIV bug fixed! There's still sooo many vendors with the old ones in stock.
There is a long list of patents and technologies that went into WiFi. CSIRO's patent only covered one part of that, so it's not the case that their chunk represents all the inventor royalties here.
The version of events you're describing didn't happen. There was no "convergent evolution". CSIRO spin-off Radiata was involved in creating the standard. See the Register article. There's a license letter proving the IEEE was fully aware of CSIRO patent and its impact on the 802.11a standard. If you look at the letters of assurance list, there was a long list of such agreements hammered out as part of the standardization process. Given all that, the idea that CSIRO's technology was obvious and easily duplicated isn't true either, so your US patent system flamebait is unsupported by this example. The only part you got right here is that CSIRO's role as a research lab that spins off commercial products does not make them a patent troll.
You're focused on a crack of one function in this sort of program. Given enough time, it is always possible to map all the inputs and outputs of a function, and therefore replace it with another that does the same thing--but with a change like a crack installed. The question, though, is how much time will it take?
There's not an easy to spot boolean on the line here; we're past when idiots built these things now. Let's say the output from the DRM checker is a 1024 bit key that unlocks the next function in the chain. It works right now; run it again and pseudo-random behavior means you'll get a different one. Saving the key itself will do you no good. To crack the program, you need to figure out how the DRM checker creates these 1024 keys from its inputs.
If that code is obfuscated enough, the only way to reverse engineer it is to use a "black box" approach. You inject all possible inputs, observe outputs, and then you know what the function does. The claim of the paper is that their way of constructing these functions means mapping all of the inputs and outputs well enough to duplicate the function can be made arbitrarily hard. Yes, you can do it. But if there are enough layers that all have to be carefully unwrapped function at a time, mapping all inputs and resulting outputs, that the time to do the work can be made a lot longer than people expect now.
You can make the algorithm as complex as you'd like, but at the end of the day, you have an input and output(s). You may decide to take a long time to get there, but at the end of the day, I know what you did when the code ran.
This is referred to as "black-box" reverse engineering in the paper. You know what the code did for one input. And if you injected every possible input to the program, at the end you'd have worked out a complete specifications for the function. But how long will that take? It's not always "the end of the day". For functions with a wide range of inputs, it could take the life of the universe to map them all unless you know what you're looking for in advance.
Right now, obfuscation approaches for software usually have some small chocking point to attack. It might be an encryption wrapper around the main binary. Bust that with a debugger, you can get to unobfuscated code for the main system, and then really start to work your way through the program.
But if you have to fight this every step of the way, where all you do is inject inputs and get an output to figure out what the program does, it will take you forever to reverse engineer things. That's the claim of the paper. The code itself is so obfuscated that you can't read it straight and understand it, ever. It looks like random junk. All you can do is run it with an input and see what comes back, and from that reverse engineer what it does. Assemble enough of those and you can see how the program really works. But that black box teardown process--determining possible inputs, injecting them, collecting outputs, and then deriving the function behavior--is time intensive enough that it may not be practical to actually do it anymore. You don't learn anything from reversing any component that speeds handling the next; you have to attack them all like this.
There's a great line from the seminal paper on this subjectOn the (Im)possibility of Obfuscating Programs: "Any programmer knows that total unintelligibility is the natural state of computer programs (and one must work hard in order to keep a program from deteriorating into this state)" Extracting meaning from source code, being able to predict what some lines of code will do, it's hard. Ideally you'll just be able to read the code, make sense of it, and then reverse from there. Most systems that are thoroughly cracked have some sections where it's hard, but once you get those the remaining code is straightforward to read. And in fact, it's impossible to make something where you cannot reverse it. The question though is how long it will take.
If no sense is ever made of the code, you can only apply the "black-box" reverse engineering, where you inject inputs, watch outputs, and from there determine what the code does. You can't prevent that, but you can make the box so big that such work is impossible to do. That's what this technique tries to accomplish. You never find an easy part to the code you can read; all you ever find are ones where you have to map every input into an output to figure out what the code does.
A 64 bit address space can hold values up to 2 ^ 64 bits. There are only about 10 ^ 49 atoms on our planet. That's why it's not possible for a computer on Earth to exceed a 64 bit address space, which was the point being made by that joke. Even if you squeezed each bit down to taking a single atom, a system holding enough data to overflow a 64 bit address space would have to be the size of our solar system.
Every time I read about Detroit it seems more Robocop.
You're implying here that Microsoft's products here are only better due to their user base. That's not quite fair. The way Word allows leaving document comments, reviewing them, and even directly accepting edits is the best workflow for review around. Even OpenOffice trails pretty far behind in this area, the UI isn't nearly as slick. There's nothing I'm aware of that allows a similarly powerful editor feedback cycle for formatted documents. As a full time developer / part time writer, I'm fine with using a version control system for handling LaTeX diffs, treating proposed review changes like a source code branch merge. But even with full mastery of tools like git for that, it's still clearly inferior to the review tool chain in Word.
It's hard enough to get reviewers to look at things, provide feedback, and then usefully apply that feedback when it's clear and unambiguous what they are commenting on. If your review feedback annotation isn't very tightly tied to the original document, you're just wasting everyone's time. Good review feedback isn't in the form of scribbled notes. It's very tightly targeted to avoid ambiguity, and easy to merge back into the original document too. Every additional step put into the way makes the process less efficient and useful.
And good editor feedback includes suggestions on whether the formatting is helping communicate your message. Even when it's possible to use plain text, you're reducing the value of the editing by doing that. (It may not be feasible at all if the thesis is formula heavy)
My publisher takes in Word documents with a very limited style sheet set they provide, and then turn that into a typeset format without a labor intensive manual process in the middle. It is possible to use Word as a simpler tool to make automatic conversions simpler. There isn't very much style discipline in your average Word document though.
The main advantage of newer revision control software in this context is improved merging. If three people work on the same document, and you need to combine all those sets of changes, something like git is going to make that easier. Tools like Subversion that force a more linear flow are fine for when documents are formally passed between two parties, but they don't really scale up to lots of people working in parallel on things.
Separating text creation and formatting into two steps doesn't help with anything but very early editor review. Most of the really useful editing and review happens after formatting. Editing feedback should even include comments on whether the formatting is working usefully to improve the message quality.
Even if you did split these phases up more usefully on the document creation tool side, there are a good chunk of thesis works where the text without formatted equations isn't readable at all. The text side of documentation creation and editing can be a very small fraction of the total work in this sort of paper.
ROT-26: all the protection you've come to expect from ROT-13, but with only half the rounds!
I run my passwords through a full 12,000 rounds of ROT-13.