Efficiency of converting heat into work is not just a problem of engineering. There's a fundamental limit due to the second law of thermodynamics. You simply cannot extract heat from the surrounding and convert it into work. You always need a heat sink, and you always will lose some of the heat to the heat sink. The maximal theoretical efficiency you can get depends on the temperature difference between heat source and heat sink, but is always less than 100%.
Ever looked at the rockets used for lift-off? They are made mostly of fuel. Most of it is needed just for not falling (i.e. accelerating) down. In other words, it would be needed for going downwards slowly as well.
Then Google gets all your DNS queries, too. Don't be surprised if one day you get targeted ads based on which DNS queries were done from your IP. Well, maybe you shouldn't have clicked on that goatse link anyway...:-)
Or what about an user-configurable firewall at the ISP? Have it block port 80 by default, but any user who wants to use it can simply go to the web site and enable the port.
Okay, so the Chilean ISP is not to mess with your traffic in any way, or even look at it. Yet, they must filter porn and ensure your privacy and security?
Well, that's easy to solve: The ISP sends all traffic to a government computer which analyzes the content and tells the ISP what to filter out.
For example, without net neutrality an ISP could block your VoIP traffic in order to sell you their phone service instead. Since VoIP clearly is legitimate, this law means they cannot block it. I also guess it means they cannot simply block all torrents, because you could use bittorrent to download Linux images (which is a legitimate use), and blocking all torrents would restrict that legitimate service. Of course it cannot protect against restrictions by law (e.g. if a new law states that torrents are now illegal, then torrents stop being legitimate traffic), but then, there's not much a law can do to protect itself against lawmakers anyway (the only way to protect it a bit more would be to put it into the constitution).
Perhaps the absense of mind-numbing flash games back then had something to do with it.
Probably. When I had the first contact with a computer, literally the only thing you could do with it was to program it. So there were only two possible reactions to it: Learn programming it, or completely ignore it. I did the first.
I mean, it sounds reasonable to prevent my angry customers from displaying all their filth on the front of my shop doesn't it?
Well, if you don't want that, just make sure that your customers are not angry at your products. Or don't offer a forum. Or write explicitly that the forum is for fanbois only.
I would expect my cell phone to work flawless for it's main function, making phone calls, provided there's no hardware defect, it has power, a working tower is in reach, and the network is not overloaded. I accept that non-core functionality may fail. I won't accept if the one defining functionality, which is making phone calls, doesn't work due to design or implementation defects. That's a proven technology, it's no rocket science, and it should be tested like hell.
I would have just pointed out the fact that the sentence also contained the word "made".... I would find it hard to "made" something in the future.
However I don't have problems to think about something that will be made in the future.
The word made means it has already in the past, make is in the future.
The word "made" can also indicate the passive voice. And since in this case it was not about something the graphics card made, but about the graphics cards which were made, the form did only indicate passive voice. The sentence did not contain any direct indication about which time frame was meant, because there was no verb which would tell you. If he had written "for the fastest videocard which ever was made" it would have been explicit that it refers to the past, and if he had written "for the fastest videocard which ever will be made" then it would clearly refer to the future. However, he just wrote "for the fastest videocard ever made," so the grammar doesn't tell you what time frame is meant. So you have to refer either to idiomatic usage (if he meant the future, he surely would have written "for the fastest videocard ever to be made"), or to common sense (which in this case clearly indicates the past).
If you're doing GPGPU, you don't care about the monitor refresh rate. You might not even have a monitor attached. Also for gaming, while higher frame rates are clearly useless above some point, a faster GPU also means you can do more per frame without your frame rate going unacceptably low. I could even imagine games offloading some non-graphics work from the CPU to the GPU if the graphics doesn't completely max it out at the desired frame rate.
The need to feed the house would be an ongoing problem.
Well, the real problems start when the house figures out how to feet itself, and discovers that there are great sources of proteine and fat directly inside it.:-)
No, it tells you how you learn the lesser-known language named "PHP in 24 hours" which differs from normal PHP in that the scripts always take 24 hours to run.
and is a real beast if you're in an Active Directory environment with Roaming Profiles, 'cause the damn software keeps getting copied to/from the server with ever logon/logoff.
That's not a problem of installing anything there, but a problem of Window's implementation of Active Directory. First, it's plain silly to copy the whole user directory to the local machine and back again, instead of simply accessing the remote one (and I wonder what happens if you log into two computers at the same time). Second, it is even more silly to copy files back which have not changed (like executable data of a program which asn't been updated).
Note that in your directory you also might have other large files which rarely change.
I agree that `DEP' is a no-brainer, but it's only effective against very basic attack techniques. It can easily be circumvented with a return-to-libc attack.
However that type of attack could also easily be made much more difficult by having separate stacks for return addresses and stack frames. While the x86 doesn't have direct support for it (are there other processors which do?), I think due the fact that an x86 usually local variables are referred to through the base pointer, not the stack pointer, it should not be too hard to implement that (it would, however, be an ABI change, so it couldn't be enabled for existing executables; OTOH you wouldn't need to rewrite your programs, just recompile them with a compiler that supports such a modified ABI - the hardest part would probably be for the OS to support both ABIs at the same time). For extra protection, one could put a non-writable page between the return stack and the rest of the data (including the stack frames), so that buffer overruns will trigger a segmentation fault before reaching the return address stack.
Well, actuallyfor me the distinction of "program" and "application" is a bit different. A program is basically an executable together with the dynamic libraries it uses, and typically runs in a single process. An application, on the other hand, is something the user perceives as a single entity. While often an application is implemented in a single program, that's not always the case. The main program of the application may execute any number of helper programs which, while separate programs, are actually working together. A typical example would be separation of a GUI frontend and a non-GUI program doing the actual work. Those are two programs, which together form a single application.
Of course, this separation isn't too strict: For example, if you use ddd with a gdb backend, you might consider both together as an application. But on the other hand, gdb is developed independently from ddd, is designed to be used standalone, and even in ddd you can give commands to gdb directly.
Another example would be an IDE for compilers. Many people use their compiler only through the IDE, therefore from their view it can be seen as an integral part of the IDE, even though it is a separate program which also can be called separately. Moreover, the compiler itself may actually consist of several programs as well; for example, a C compiler traditionally consisted of separate executables for the preprocessor and the actual compiler, which nevertheless were called both by the same command (which in addition then also compiled the assembler and possibly the linker), so from the user's view it was just one single (command line) application, even though it consisted of several programs (today the preprocessor is usually integrated into the compiler, and many compilers produce machine code directly, instead of going through an assembler, so apart from calling the linker, the compiler application is indeed implemented in a single program).
So in short: In my view "Application" is the user-level concept, while "program" is the OS level concept. An application may consist of several programs working together to provide a single experience to the user.
Also note that the notion of a program also differs from the notion of an executable, because the program also includes all shared libraries used by that executable.
Efficiency of converting heat into work is not just a problem of engineering. There's a fundamental limit due to the second law of thermodynamics. You simply cannot extract heat from the surrounding and convert it into work. You always need a heat sink, and you always will lose some of the heat to the heat sink. The maximal theoretical efficiency you can get depends on the temperature difference between heat source and heat sink, but is always less than 100%.
Ever looked at the rockets used for lift-off? They are made mostly of fuel. Most of it is needed just for not falling (i.e. accelerating) down. In other words, it would be needed for going downwards slowly as well.
Then Google gets all your DNS queries, too. Don't be surprised if one day you get targeted ads based on which DNS queries were done from your IP. Well, maybe you shouldn't have clicked on that goatse link anyway ... :-)
Or what about an user-configurable firewall at the ISP? Have it block port 80 by default, but any user who wants to use it can simply go to the web site and enable the port.
Well, that's easy to solve: The ISP sends all traffic to a government computer which analyzes the content and tells the ISP what to filter out.
Thrid world came from the cold war era, and it was attributed to Russia and Russia sympathizers.
No, that was the second world. The third world was all those who didn't belong to either the first (i.e. Western) or the second (i.e. Soviet) world.
The term used to be associated with "impoverished." Now it is more like "laws not yet fully rewritten by and for corporations."
That's still impoverished. See, the corporations there don't even have enough money to buy laws!
You can download the women themselves?
SCNR
For example, without net neutrality an ISP could block your VoIP traffic in order to sell you their phone service instead. Since VoIP clearly is legitimate, this law means they cannot block it.
I also guess it means they cannot simply block all torrents, because you could use bittorrent to download Linux images (which is a legitimate use), and blocking all torrents would restrict that legitimate service.
Of course it cannot protect against restrictions by law (e.g. if a new law states that torrents are now illegal, then torrents stop being legitimate traffic), but then, there's not much a law can do to protect itself against lawmakers anyway (the only way to protect it a bit more would be to put it into the constitution).
Probably. When I had the first contact with a computer, literally the only thing you could do with it was to program it. So there were only two possible reactions to it: Learn programming it, or completely ignore it. I did the first.
Well, if you don't want that, just make sure that your customers are not angry at your products. Or don't offer a forum. Or write explicitly that the forum is for fanbois only.
Well, that's the fate of those who don't know sudo.
It's called a state machine. It's a marvelous invention. Look into it.
I'm waiting for the federal machine.
I would expect my cell phone to work flawless for it's main function, making phone calls, provided there's no hardware defect, it has power, a working tower is in reach, and the network is not overloaded. I accept that non-core functionality may fail. I won't accept if the one defining functionality, which is making phone calls, doesn't work due to design or implementation defects. That's a proven technology, it's no rocket science, and it should be tested like hell.
The best thing would be to support both. Then whatever service currently gives you location data will be used.
However I don't have problems to think about something that will be made in the future.
The word "made" can also indicate the passive voice. And since in this case it was not about something the graphics card made, but about the graphics cards which were made, the form did only indicate passive voice. The sentence did not contain any direct indication about which time frame was meant, because there was no verb which would tell you. If he had written "for the fastest videocard which ever was made" it would have been explicit that it refers to the past, and if he had written "for the fastest videocard which ever will be made" then it would clearly refer to the future. However, he just wrote "for the fastest videocard ever made," so the grammar doesn't tell you what time frame is meant. So you have to refer either to idiomatic usage (if he meant the future, he surely would have written "for the fastest videocard ever to be made"), or to common sense (which in this case clearly indicates the past).
If you're doing GPGPU, you don't care about the monitor refresh rate. You might not even have a monitor attached.
Also for gaming, while higher frame rates are clearly useless above some point, a faster GPU also means you can do more per frame without your frame rate going unacceptably low. I could even imagine games offloading some non-graphics work from the CPU to the GPU if the graphics doesn't completely max it out at the desired frame rate.
That's an interesting way to murder.
If you put a nail in the wall, will it bleed? Will the house feel pain?
Well, the real problems start when the house figures out how to feet itself, and discovers that there are great sources of proteine and fat directly inside it. :-)
No, it tells you how you learn the lesser-known language named "PHP in 24 hours" which differs from normal PHP in that the scripts always take 24 hours to run.
Trust is easier to earn, and much easier to lose.
That's not a problem of installing anything there, but a problem of Window's implementation of Active Directory. First, it's plain silly to copy the whole user directory to the local machine and back again, instead of simply accessing the remote one (and I wonder what happens if you log into two computers at the same time). Second, it is even more silly to copy files back which have not changed (like executable data of a program which asn't been updated).
Note that in your directory you also might have other large files which rarely change.
However that type of attack could also easily be made much more difficult by having separate stacks for return addresses and stack frames. While the x86 doesn't have direct support for it (are there other processors which do?), I think due the fact that an x86 usually local variables are referred to through the base pointer, not the stack pointer, it should not be too hard to implement that (it would, however, be an ABI change, so it couldn't be enabled for existing executables; OTOH you wouldn't need to rewrite your programs, just recompile them with a compiler that supports such a modified ABI - the hardest part would probably be for the OS to support both ABIs at the same time). For extra protection, one could put a non-writable page between the return stack and the rest of the data (including the stack frames), so that buffer overruns will trigger a segmentation fault before reaching the return address stack.
Well, actuallyfor me the distinction of "program" and "application" is a bit different. A program is basically an executable together with the dynamic libraries it uses, and typically runs in a single process. An application, on the other hand, is something the user perceives as a single entity. While often an application is implemented in a single program, that's not always the case. The main program of the application may execute any number of helper programs which, while separate programs, are actually working together. A typical example would be separation of a GUI frontend and a non-GUI program doing the actual work. Those are two programs, which together form a single application.
Of course, this separation isn't too strict: For example, if you use ddd with a gdb backend, you might consider both together as an application. But on the other hand, gdb is developed independently from ddd, is designed to be used standalone, and even in ddd you can give commands to gdb directly.
Another example would be an IDE for compilers. Many people use their compiler only through the IDE, therefore from their view it can be seen as an integral part of the IDE, even though it is a separate program which also can be called separately. Moreover, the compiler itself may actually consist of several programs as well; for example, a C compiler traditionally consisted of separate executables for the preprocessor and the actual compiler, which nevertheless were called both by the same command (which in addition then also compiled the assembler and possibly the linker), so from the user's view it was just one single (command line) application, even though it consisted of several programs (today the preprocessor is usually integrated into the compiler, and many compilers produce machine code directly, instead of going through an assembler, so apart from calling the linker, the compiler application is indeed implemented in a single program).
So in short: In my view "Application" is the user-level concept, while "program" is the OS level concept. An application may consist of several programs working together to provide a single experience to the user.
Also note that the notion of a program also differs from the notion of an executable, because the program also includes all shared libraries used by that executable.