That supports his point. The groups recieving the donated software from Microsoft are ones that were already likely to stop paying for MS and either go to a competitor or Open Source (or just use less software).
So by donating to these people, Microsoft isn't losing any sales- they were going to lose the sales regardless.
And in exchange, they gain a slowdown of adoption of alternatives.
That would be a clever trick, but it's not how they all work. I'm using as my reference the Stanford Stoogebot. The source code is unpublished, so I can't be quite sure what it does, but the authors state it keeps track of all nearby targets and computes visibilty (ray-intersection to the BSP) for all of them, before deciding which to shoot.
And it definitely forges mouse movement, as described in the section on decoupling movement and orientation. (Its not a "forgery" in the sense that it expects to fool people, though. The pseudo-mouse is updated perfectly, without introducing any of the incremental delay that might confuse a bot-detector on the server)
From what I understand (corrections invited) downloading the music isn't the illegal part (assuming you have the CD)
Well, in the US, that is technically illegal. Only the copyright holder can authorize someone to duplicate his content. The fact that you've purchased one copy on CD doesn't permit you to make more.
Many people claim that fair use entitles you to make a backup copy of a CD, and prehaps the downloaded materials could be considered such a copy (although MP3 files are lossy-compressed, and would be a poor way to recreate the original CD).
The government's description of fair use, however, mentions nothing about backup copies, although both backups and time/format shifting have seemed acceptable recently.
The client can still cheat in a game unless there is protection on the client side, on the server side, and on the whole data path in between.
For example, AimBot proxies have been written that sit between a game client and server, and modify the trajectory of a player's shots to be 100% accurate.
More simply, and with no risk of automated detection, a program could sniff the game packets to draw a birds-eye-view on the player's PC monitor.
(Oh, and the joysticks must be protected too. Can't allow macro sequences or autofire...)
That's not about types, though. It's about values. A truncation error isn't based on the type of i, but the value it contained.
So, what behavior would you really prefer? The options are (A) runtime exceptions for truncation (Java-ish), (B) No int->char assignment without an explicit typecast, (C) print warnings for questionable behavior in the rare case static analysis can catch it.
Because you called this a "type system" problem, I assume you'd prefer option (B). But that won't fix your problem- the central error here is that char was used to contain a number too large to fit in 8 bits. Having made that mistake, and having already demonstrated willingness to use typecasts (that static_cast char->int) to protect his error, the wayward programmer would've just instinctively typed "char c=(char)i;". (Especially likely as a knee-jerk response to a type-mismatch error from the compiler). And now the program exhibits exactly the same wrong behavior.
(Plus, requiring int->char typecasts would break old code, and outlaw normal things like "typedef char int8;int8 s=13;")
How about (C)? Your situation is a special case- i is given a constant value, then immediately assigned to c. But in general, looking at the statement "char c=i;" by itself, the compiler can't know what previous value i had. Sure, in foo.c the truncation effect (can't truly call it an "error"- after all, it's exactly the effect the programmer wished to produce) could be firmly detected ahead of time. But should the compiler give warnings for runtime problems in the odd event that compile-time analysis can catch it? If so, then you'd want "int x=0,y=10/x;" to be a compiler warning too.
So, what you're really saying is not that the type-checking is too weak, but either that the tradition of silent wraparound on overflow is wrong (which is true- for the majority of uses today, programmers don't want this), or that C++ compilers should try to pre-evaluate all possible arithmetic to check it for operations that are legal, but surprising to a total neophyte.
The Halting Problem is all about pathological cases. If you can't handle them, then your "solution" is not an algorithm but an heurstic.
Using a tortoise chasing a hare makes you exponentially faster than a more naive exhaustive approach (keeping each state in a list). But the number of cases to check (especially if the program under test is a busy beaver) is still proportionate to 2^m. Which is to say, unworkable.
The true Halting Problem, of course, assumes the machine has infinite memory so exhaustive approaches are flat-out disallowed. But if you try to bring it to reality and apply it to a finite computer, then you've got to also disallow running times that are merely nigh-infinite.
it is possible to determine whether any LBA will halt or loop by running it for n cycles where n is the number of states of the machine's memory (n = 2^m where m is the number of bits in the machine's memory).
But, that is impossible on a real computer.
For real computers, the number of bits in memory is usually in the millions (even a tiny Palm Zire has 16 million bits)
2^16000000 is impossible to cycle through in less than centuries- it's not a task a "real computer" can ever do.
Remember, 2^300 is the number of electrons in the entire universe! Once any algorithm has a predicted running time of 2^(150 or higher), it's on the virge of being impossible to solve on any real computer.
The article (link provided for those who don't read URLs) is wrong, even in the first section.
The title of the first "chapter" is "Why is c++ Decompiling possible?". But immediately he lists "what is totally loss when you compile a program and what stays there".
In the Lost column he puts templates and classes. The remains list has things like function calls and local variables.
Well, guess what? Those things are are "lost" are everything that distinguishes C++ from C. If you don't have classes (meaning no inheritance or virtual functions either) and don't have templates either, then you're really just programming in "a better C", not C++.
So all his approach can hope to "decompile" is C code. Which is something we've seen done in various forms for decades.
No, it can not. Write a program which will loop until any key is pressed. When will it halt? No program can determine the answer in advance.
That example is irrelevant to the actual Halting Problem.
The Halting Problem assumes that both the program itself and all it's inputs are available to you beforehand. In that case, it is still impossible to detect if the program will terminate without actually running the whole program.
(And if the program takes decades to execute, then that possibility is eliminated)
Windows is a network effect. In general, people need to run Microsoft Windows(tm) to run Microsoft Word(tm) to view files others have sent them from Microsoft Word(tm).
The intrinsic advantages of Microsoft Word(tm) over competing word processors are small, except in the field of compatibility with itself (which by definition would be hard for anything else to match). Yet that is the feature by which most buying decisions are made.
The "network effect" was introduced in Metcalfe's Law. However, it referenced hardware. Check "Gate's Corrolary" for the extension of the network effect to software.
If SCO somehow wins it's IBM lawsuit (on a copyright ground, not just a trade-secret one), it will prove that all Linux kernels everywhere are in violation of it's IP. At minimum, that will force all commercial Linux systems to either pay SCO or be offline for a few weeks as new, non-infringing kernels are built and distributed.
Um, yes, if you want recursion, code it that way... but recursion is just a mechanism for you to communicate your intent to the computer (an aspect of a programming language).
It's not instructions on how that intent must be carried out. As long as the final output of running the program is the same, the compiler is allowed to swap recursion and iteration or do many other things.
In fact, since assembly language and binary code don't support recursion, you'd better hope that the compiler replaces it with iteration for you!
When a compiler changes code from a language supporting recursion into one that doesn't, it can use two approaches. The more general approach is to use a stack to hold prior recursive states (which works adequately, especially if your target system is normal and already has a stack for function calls). There's also the special case of "tail recursion". When the recursion happens as the last statement of a function, then the prior function state can actually be completely disgarded, and no stack is needed. So the recursion becomes a cheap loop.
When you think about it, the higher level the language is, the easier it should be to "decompile".
No, no, no. This is both empirically untrue, (Do you see many ML or even C++ decompilers out there?) and theoretically insensible.
The higher level a language is, the more changes there will be between the original source code and the assembly. Thus the more source data that will have been discarded by the original compiler, which is data the decompiler cannot reconstruct.
The reason Java decompilers work relatively well is not because Java's a high-level language (it isn't, really), but because the output program is at such a high level! Instead of working from binary code, a Java decompiler gets a more presentable bytecode, packed with the names of classes and methods. (Also, because optimization of Java programs is supposed to happen after compilation at a JIT stage, the bytecodes won't be as obfuscated as the output of a normal C++ optimizing compiler)
The closer the original source was to asm, the more the individual coder's style will be reflected in the asm
When decompiling, the "individual coder's style" is exactly what you're trying to get!
the more the obvious patterns the compiler uses every time for given constructs will be present.
Good compilers don't use "obvious patterns". Their transformation functions are very sensitive, so a tiny change in the input source (expanding a loop from 3 times to 4) can cross an optimization threshold and totally change the appearance of the output.
Nasa obviously tried to make their products as safe as possible.
No they didn't. Reusable space vehicles are inherently dangerous compared to disposable ones.
If they wanted safety, we wouldn't have space shuttles at all. All the orbital lifting they do could be accomplished faster, cheaper, and safer by simpler rockets.
The only benefit of the space shuttle is that it can make a stylish 3-point landing.
Perhaps they could institute round-the-clock operations via multiple shifts, but I don't know if they have enough qualified workers to be able to handle something like that.
Standard operating procedure is nearly round-the-clock already (for the specific procedures that are the slowest, and bottleneck the overall prep time)
The idea of capturing and reparing satellites is inherently absurd
Yes, it's a rare, rare satellite that would be worth a launch to repair. However, on the off chance a Hubble-situation happened, you don't even need a Shuttle to fix it. It's also possible to spacewalk from an ELV. A nice Titan IV rocket (or whatever improved version we could've made if ELV research wasn't cancelled in favor of the Shuttle) could handle a fine repair crew for 25% the cost of a Shuttle flight. (And with a safer re-entry, too)
Um, many problems. Primarily, the Columbia had 7 people (and a shuttle can hold more), while a Soyuz just carries 3 (including the pilot who brought it up).
So it would've taken 4 Soyuz to evacuate the Columbia crew, risking 4 individual pilots. As opposed to the two pilots who could bring a shuttle up (maybe even just one could do it, but NASA'd never try that).
Without networks, hackers had to pick locks or hop fences to use computers without permission. But they did!
The meaning of "unathorized computer use" goes back to 1959, when MIT sophmore Peter Samson (from the railroad club) snuck through the basement door to Building 21 and tampered with the punchcard stacks.
What's wrong with creating your own MyString and MyStringHashMap classes?
It's impossible to create a Java class which acts like the native String class, since the language doesn't support operator overloading for the critical concatenator "+".
Slashdot Mirror
What if he submits his paper electronically to TAs who use Microsoft Office's word count feature?
That supports his point. The groups recieving the donated software from Microsoft are ones that were already likely to stop paying for MS and either go to a competitor or Open Source (or just use less software).
So by donating to these people, Microsoft isn't losing any sales- they were going to lose the sales regardless.
And in exchange, they gain a slowdown of adoption of alternatives.
That would be a clever trick, but it's not how they all work. I'm using as my reference the Stanford Stoogebot. The source code is unpublished, so I can't be quite sure what it does, but the authors state it keeps track of all nearby targets and computes visibilty (ray-intersection to the BSP) for all of them, before deciding which to shoot.
And it definitely forges mouse movement, as described in the section on decoupling movement and orientation. (Its not a "forgery" in the sense that it expects to fool people, though. The pseudo-mouse is updated perfectly, without introducing any of the incremental delay that might confuse a bot-detector on the server)
I suppose you don't enjoy the existence of C++'s explicit keyword, then.
From what I understand (corrections invited) downloading the music isn't the illegal part (assuming you have the CD)
Well, in the US, that is technically illegal. Only the copyright holder can authorize someone to duplicate his content. The fact that you've purchased one copy on CD doesn't permit you to make more.
Many people claim that fair use entitles you to make a backup copy of a CD, and prehaps the downloaded materials could be considered such a copy (although MP3 files are lossy-compressed, and would be a poor way to recreate the original CD).
The government's description of fair use, however, mentions nothing about backup copies, although both backups and time/format shifting have seemed acceptable recently.
The client can still cheat in a game unless there is protection on the client side, on the server side, and on the whole data path in between.
For example, AimBot proxies have been written that sit between a game client and server, and modify the trajectory of a player's shots to be 100% accurate.
More simply, and with no risk of automated detection, a program could sniff the game packets to draw a birds-eye-view on the player's PC monitor.
(Oh, and the joysticks must be protected too. Can't allow macro sequences or autofire...)
That's not about types, though. It's about values. A truncation error isn't based on the type of i, but the value it contained.
So, what behavior would you really prefer? The options are (A) runtime exceptions for truncation (Java-ish), (B) No int->char assignment without an explicit typecast, (C) print warnings for questionable behavior in the rare case static analysis can catch it.
Because you called this a "type system" problem, I assume you'd prefer option (B). But that won't fix your problem- the central error here is that char was used to contain a number too large to fit in 8 bits. Having made that mistake, and having already demonstrated willingness to use typecasts (that static_cast char->int) to protect his error, the wayward programmer would've just instinctively typed "char c=(char)i;". (Especially likely as a knee-jerk response to a type-mismatch error from the compiler). And now the program exhibits exactly the same wrong behavior.
(Plus, requiring int->char typecasts would break old code, and outlaw normal things like "typedef char int8;int8 s=13;")
How about (C)? Your situation is a special case- i is given a constant value, then immediately assigned to c. But in general, looking at the statement "char c=i;" by itself, the compiler can't know what previous value i had. Sure, in foo.c the truncation effect (can't truly call it an "error"- after all, it's exactly the effect the programmer wished to produce) could be firmly detected ahead of time. But should the compiler give warnings for runtime problems in the odd event that compile-time analysis can catch it? If so, then you'd want "int x=0,y=10/x;" to be a compiler warning too.
So, what you're really saying is not that the type-checking is too weak, but either that the tradition of silent wraparound on overflow is wrong (which is true- for the majority of uses today, programmers don't want this), or that C++ compilers should try to pre-evaluate all possible arithmetic to check it for operations that are legal, but surprising to a total neophyte.
you are living in a dream world.
Or you publish Free Software.
The Halting Problem is all about pathological cases. If you can't handle them, then your "solution" is not an algorithm but an heurstic.
Using a tortoise chasing a hare makes you exponentially faster than a more naive exhaustive approach (keeping each state in a list). But the number of cases to check (especially if the program under test is a busy beaver) is still proportionate to 2^m. Which is to say, unworkable.
The true Halting Problem, of course, assumes the machine has infinite memory so exhaustive approaches are flat-out disallowed. But if you try to bring it to reality and apply it to a finite computer, then you've got to also disallow running times that are merely nigh-infinite.
it is possible to determine whether any LBA will halt or loop by running it for n cycles where n is the number of states of the machine's memory (n = 2^m where m is the number of bits in the machine's memory).
But, that is impossible on a real computer.
For real computers, the number of bits in memory is usually in the millions (even a tiny Palm Zire has 16 million bits)
2^16000000 is impossible to cycle through in less than centuries- it's not a task a "real computer" can ever do.
Remember, 2^300 is the number of electrons in the entire universe! Once any algorithm has a predicted running time of 2^(150 or higher), it's on the virge of being impossible to solve on any real computer.
The article (link provided for those who don't read URLs) is wrong, even in the first section.
The title of the first "chapter" is "Why is c++ Decompiling possible?". But immediately he lists "what is totally loss when you compile a program and what stays there".
In the Lost column he puts templates and classes. The remains list has things like function calls and local variables.
Well, guess what? Those things are are "lost" are everything that distinguishes C++ from C. If you don't have classes (meaning no inheritance or virtual functions either) and don't have templates either, then you're really just programming in "a better C", not C++.
So all his approach can hope to "decompile" is C code. Which is something we've seen done in various forms for decades.
It's not slashdotted. In fact, the guy probably hasn't gotten many extra hits at all, because the posted URL is wrong.
No, it can not. Write a program which will loop until any key is pressed. When will it halt? No program can determine the answer in advance.
That example is irrelevant to the actual Halting Problem.
The Halting Problem assumes that both the program itself and all it's inputs are available to you beforehand. In that case, it is still impossible to detect if the program will terminate without actually running the whole program.
(And if the program takes decades to execute, then that possibility is eliminated)
Hi, the URL posted is obviously wrong.
There's an extra "/" character that breaks the link. Here's the article.
Basically, yes.
Windows is a network effect. In general, people need to run Microsoft Windows(tm) to run Microsoft Word(tm) to view files others have sent them from Microsoft Word(tm).
The intrinsic advantages of Microsoft Word(tm) over competing word processors are small, except in the field of compatibility with itself (which by definition would be hard for anything else to match). Yet that is the feature by which most buying decisions are made.
The "network effect" was introduced in Metcalfe's Law. However, it referenced hardware. Check "Gate's Corrolary" for the extension of the network effect to software.
And during that time, did you upgrade the kernel from 2.2.18 to patch the ptrace root exploit?
If SCO somehow wins it's IBM lawsuit (on a copyright ground, not just a trade-secret one), it will prove that all Linux kernels everywhere are in violation of it's IP. At minimum, that will force all commercial Linux systems to either pay SCO or be offline for a few weeks as new, non-infringing kernels are built and distributed.
Um, yes, if you want recursion, code it that way... but recursion is just a mechanism for you to communicate your intent to the computer (an aspect of a programming language).
It's not instructions on how that intent must be carried out. As long as the final output of running the program is the same, the compiler is allowed to swap recursion and iteration or do many other things.
In fact, since assembly language and binary code don't support recursion, you'd better hope that the compiler replaces it with iteration for you!
When a compiler changes code from a language supporting recursion into one that doesn't, it can use two approaches. The more general approach is to use a stack to hold prior recursive states (which works adequately, especially if your target system is normal and already has a stack for function calls). There's also the special case of "tail recursion". When the recursion happens as the last statement of a function, then the prior function state can actually be completely disgarded, and no stack is needed. So the recursion becomes a cheap loop.
When you think about it, the higher level the language is, the easier it should be to "decompile".
No, no, no. This is both empirically untrue, (Do you see many ML or even C++ decompilers out there?) and theoretically insensible.
The higher level a language is, the more changes there will be between the original source code and the assembly. Thus the more source data that will have been discarded by the original compiler, which is data the decompiler cannot reconstruct.
The reason Java decompilers work relatively well is not because Java's a high-level language (it isn't, really), but because the output program is at such a high level! Instead of working from binary code, a Java decompiler gets a more presentable bytecode, packed with the names of classes and methods. (Also, because optimization of Java programs is supposed to happen after compilation at a JIT stage, the bytecodes won't be as obfuscated as the output of a normal C++ optimizing compiler)
The closer the original source was to asm, the more the individual coder's style will be reflected in the asm
When decompiling, the "individual coder's style" is exactly what you're trying to get!
the more the obvious patterns the compiler uses every time for given constructs will be present.
Good compilers don't use "obvious patterns". Their transformation functions are very sensitive, so a tiny change in the input source (expanding a loop from 3 times to 4) can cross an optimization threshold and totally change the appearance of the output.
Nasa obviously tried to make their products as safe as possible.
No they didn't. Reusable space vehicles are inherently dangerous compared to disposable ones.
If they wanted safety, we wouldn't have space shuttles at all. All the orbital lifting they do could be accomplished faster, cheaper, and safer by simpler rockets.
The only benefit of the space shuttle is that it can make a stylish 3-point landing.
Perhaps they could institute round-the-clock operations via multiple shifts, but I don't know if they have enough qualified workers to be able to handle something like that.
Standard operating procedure is nearly round-the-clock already (for the specific procedures that are the slowest, and bottleneck the overall prep time)
The idea of capturing and reparing satellites is inherently absurd
Yes, it's a rare, rare satellite that would be worth a launch to repair. However, on the off chance a Hubble-situation happened, you don't even need a Shuttle to fix it. It's also possible to spacewalk from an ELV. A nice Titan IV rocket (or whatever improved version we could've made if ELV research wasn't cancelled in favor of the Shuttle) could handle a fine repair crew for 25% the cost of a Shuttle flight. (And with a safer re-entry, too)
Um, many problems. Primarily, the Columbia had 7 people (and a shuttle can hold more), while a Soyuz just carries 3 (including the pilot who brought it up).
So it would've taken 4 Soyuz to evacuate the Columbia crew, risking 4 individual pilots. As opposed to the two pilots who could bring a shuttle up (maybe even just one could do it, but NASA'd never try that).
Without networks, hackers had to pick locks or hop fences to use computers without permission. But they did!
The meaning of "unathorized computer use" goes back to 1959, when MIT sophmore Peter Samson (from the railroad club) snuck through the basement door to Building 21 and tampered with the punchcard stacks.
What's wrong with creating your own MyString and MyStringHashMap classes?
It's impossible to create a Java class which acts like the native String class, since the language doesn't support operator overloading for the critical concatenator "+".