Same thing with backups, they're never taken seriously until the company loses all its data and goes out of business.
But when the company goes out of business, it won't need that data anymore anyway. So making a backup would obviously have been unnecessary expense.:-)
Note that they make the biodiesel from used coffee grounds. That is, unlike corn, it's not in competition to food usage. Indeed, a growing biodiesel price would mean that the coffee makers would get more money for the waste coffee ground, and therefore if at all, the coffee would get cheaper. Well, at least the coffy you buy ready-made. Making your own probably gets more expensive (but then, mabe it will be possible to sell personal waste coffee ground as well; after all, there should be a lot coffee be made by individuals). What would certainly get more expensive is instant coffee, because that doesn't produce waste coffee grounds.
But with your defines, if you write "FORTRAN code", you'll end up with "void main", which is illegal in C (although many compilers accept it anyway). In C, main always has to return int. Also, even ignoring that, with your defines you won't be able to just write "FORTRAN code" (even with a semicolon after it), because that would result in invalid code. And the other defines are completely irrelevant to that.
But then, my goal was to show that you don't need a single #define to write FORTRAN code. Now, if you additionally want to omit the semicolon, you'll need one #define, but that's already enough.
OK, strictly speaking, you don't need any #define at all, thanks to the -D option of the compiler:-)
First, all that energy which is radiated to outer space, never hitting earth. Now, the light which reaches other celestal bodies could be included, because it enables us to see them, and in case of the moon it even makes the night brighter (at least some of them), but even then, the vast majority of the energy doesn't reach any celestal body either, but just goes into free space. How inefficient.
Next, not all energy of the sun goes into electromagnetic radiation. Some of the energy goes into the solar wind. Again, completely useless; moreover, in cases of large sun activity it may even disturb our radio communications.
Finally, even in the case of electromagnetic radiation, there's not just light and heat. There's also X rays, which fortunately never reach the earth because the atmosphere filters them. Those X rays are, of course, also completely useless for us, thus wasted energy.
Can you imagine if we could effectively capture just one millionth of the total solar output of the Sun?
Exactly. Even capturing just one millionth would be a huge increase. And that would still mean a loss of 99.9999% of the sun's energy. As I said, totally inefficient.
Indeed, the main power source of all life is nuclear (fusion) powered, produces lots of radioactive radiation, is hopelessly inefficient (only a small part of the energy it produces reaches even the earth), and is already known to eventually fail catastrophically, destroying the whole earth during failure.
Pascal has several differences which make it much better for learning than C:
Pascal does much stronger type checking.
Pascal dynamic allocation/deallocation is typed (like C++'s new) rather than untyped (like C's malloc)
Pascal has a built-in set type (no fiddling with bit operators necessary; indeed, in Standard Pascal that's not even possible).
(Standard) Pascal doesn't have explicit typecasts (which is good for learning).
Pascal has far fewer implicit type conversions.
Pascal has a separate boolean type (no integer-as-boolean).
Pascal doesn't have unsigned types with unexpected semantics (in C, "n
Pascal distinguishes between real division (/) and integer division (div). Which C beginner wasn't caught by the fact that "1/2" gives 0? In Pascal is gives a 0.5 as expected.
Pascal has pointers, but no pointer arithmetic. Moreover, pointers cannot point to global or stack variables, so if it points to something, you can deallocate it (but Pascal does have uninitialized and dangling pointers, just like C).
Pascal has index checking (although compilers allow to disable that). An out of bounds index terminates your program instead of causing undefined behaviour.
Pascal assignments are statements, not expressions. Thus you cannot by accident put an assignment into an if (BTW, even if you could, it would usually be caught because if needs a boolean expression, and most assignments are not of boolean variables; there's no implicit conversion to boolean either)
Now, whether Pascal is the best learning language is another question. But in comparison to C, it's a clear winner.
Of course, to be bussword compatible, you'll have to translate it into XML and back. Luckily that's quite easy: Just replace (foo bar baz) with <foo>bar baz</foo> .
1) Under the old paradigm I had to buy the CD to discover I didn't like it. So record company gets + $12.
Some CD sellers already have the ability to listen into the CDs in the shop. You'll not pay $12 if you don't like what you listen to there, either.
(2) Under the new paradigm the record company has a loss of 0.1 cent (approximate cost of bandwidth I used). 0.1 cent may not sound like much but when multiplied by a few million non-purchasing listeners, it adds up.
OTOH someone may buy something he wouldn't ever have bought if he hadn't listened and liked it. Or maybe he even would have, if he had actually looked there, instead of going somewhere else where he knew that he could listen in advance.
Remember, the number of people who buy your stuff is not a constant. And a preview feature may well increase that number. Note that the in-shop preview ability mentioned above costs money, too, so obviously it works, or they wouldn't pay for it.
But what if the JavaScript would e.g. return a hash of the typed password? Then things like comparing would still work, but the password wouldn't be revealed. Of course it would open up the password for brute-force attacks; however that could be prevented by salting, where the salt is randomly changed every time a new page is loaded (so JavaScript comparison between passwords really only works if both come from the same load of the same page).
A redirection attack could be prevented by disallowing redirecting a form with password. Or even by simply giving a confirmation alert whenever the destination server doesn't match the server the page comes from.
Indeed, in Germany at least one bank (probably more of them, but one I know for sure) has this as option: When you make a transaction they send you an SMS with a TAN which you then have to enter to finish the transaction.
Seriously, though, if a key like that were introduced, it would just be one more layer these people would have to overcome.
Well, a physical device is a layer which isn't so easily overcome through the network. Provided it doesn't have any security holes of its own, of course. But then, you'd not want to just rely on an USB stick, because that one could be physically stolen. Better would be an ATM card reader with builtin PIN keypad (so the pin doesn't even reach the possibly compromised computer).
I guess the malware remenmbered those passwords itself, so not storing them in the password manager wouldn't help.
IMHO the fact that you can use plugins with Firefox means that there should be an extra security barrier inside Firefox that disallows extensions to get passwords (e.g. when accessing the password lines, it would just get the stars which are also displayed on the screen).
You can save the return 0; line, but you cannot have void main(). In C++, falling off main without return statement is equivalent to returning 0. (That's a special rule for main, not applicable to any other C++ function.) However, according to the C++ standard, a compiler which lets you write void main() without at least giving a warning is not conforming (but then, most compilers are non-conforming anyway because they don't implement export:-)).
Same thing with backups, they're never taken seriously until the company loses all its data and goes out of business.
But when the company goes out of business, it won't need that data anymore anyway. So making a backup would obviously have been unnecessary expense. :-)
I thought the PHB is clueless with respect to everything!
Do you mean Jesus Christ, or the dog?
Well, if you find 50 different sources which each provide about 2% of the needed fuel, you get 100% of your needed fuel.
Note that they make the biodiesel from used coffee grounds. That is, unlike corn, it's not in competition to food usage. Indeed, a growing biodiesel price would mean that the coffee makers would get more money for the waste coffee ground, and therefore if at all, the coffee would get cheaper. Well, at least the coffy you buy ready-made. Making your own probably gets more expensive (but then, mabe it will be possible to sell personal waste coffee ground as well; after all, there should be a lot coffee be made by individuals). What would certainly get more expensive is instant coffee, because that doesn't produce waste coffee grounds.
But with your defines, if you write "FORTRAN code", you'll end up with "void main", which is illegal in C (although many compilers accept it anyway). In C, main always has to return int.
Also, even ignoring that, with your defines you won't be able to just write "FORTRAN code" (even with a semicolon after it), because that would result in invalid code. And the other defines are completely irrelevant to that.
But then, my goal was to show that you don't need a single #define to write FORTRAN code. Now, if you additionally want to omit the semicolon, you'll need one #define, but that's already enough.
OK, strictly speaking, you don't need any #define at all, thanks to the -D option of the compiler :-)
First, all that energy which is radiated to outer space, never hitting earth. Now, the light which reaches other celestal bodies could be included, because it enables us to see them, and in case of the moon it even makes the night brighter (at least some of them), but even then, the vast majority of the energy doesn't reach any celestal body either, but just goes into free space. How inefficient.
Next, not all energy of the sun goes into electromagnetic radiation. Some of the energy goes into the solar wind. Again, completely useless; moreover, in cases of large sun activity it may even disturb our radio communications.
Finally, even in the case of electromagnetic radiation, there's not just light and heat. There's also X rays, which fortunately never reach the earth because the atmosphere filters them. Those X rays are, of course, also completely useless for us, thus wasted energy.
Exactly. Even capturing just one millionth would be a huge increase. And that would still mean a loss of 99.9999% of the sun's energy. As I said, totally inefficient.
Indeed, the main power source of all life is nuclear (fusion) powered, produces lots of radioactive radiation, is hopelessly inefficient (only a small part of the energy it produces reaches even the earth), and is already known to eventually fail catastrophically, destroying the whole earth during failure.
Pascal has several differences which make it much better for learning than C:
Now, whether Pascal is the best learning language is another question. But in comparison to C, it's a clear winner.
You didn't read the title tag, did you? :-)
I'm pretty sure it's still 2008.
Of course, to be bussword compatible, you'll have to translate it into XML and back. Luckily that's quite easy: Just replace (foo bar baz) with <foo>bar baz</foo> .
That will need a lot of #define s :)
Not at all:
Unlambda
Some CD sellers already have the ability to listen into the CDs in the shop. You'll not pay $12 if you don't like what you listen to there, either.
OTOH someone may buy something he wouldn't ever have bought if he hadn't listened and liked it. Or maybe he even would have, if he had actually looked there, instead of going somewhere else where he knew that he could listen in advance.
Remember, the number of people who buy your stuff is not a constant. And a preview feature may well increase that number. Note that the in-shop preview ability mentioned above costs money, too, so obviously it works, or they wouldn't pay for it.
But what if the JavaScript would e.g. return a hash of the typed password? Then things like comparing would still work, but the password wouldn't be revealed. Of course it would open up the password for brute-force attacks; however that could be prevented by salting, where the salt is randomly changed every time a new page is loaded (so JavaScript comparison between passwords really only works if both come from the same load of the same page).
A redirection attack could be prevented by disallowing redirecting a form with password. Or even by simply giving a confirmation alert whenever the destination server doesn't match the server the page comes from.
Indeed, in Germany at least one bank (probably more of them, but one I know for sure) has this as option: When you make a transaction they send you an SMS with a TAN which you then have to enter to finish the transaction.
According to the article, it contains a file "%ProgramFiles%\Mozilla Firefox\plugins\npbasic.dll", therefore it probably is Windows only.
Does NoScript block JavaScript coming from other extensions? I highly doubt so.
Well, a physical device is a layer which isn't so easily overcome through the network. Provided it doesn't have any security holes of its own, of course. But then, you'd not want to just rely on an USB stick, because that one could be physically stolen. Better would be an ATM card reader with builtin PIN keypad (so the pin doesn't even reach the possibly compromised computer).
I guess the malware remenmbered those passwords itself, so not storing them in the password manager wouldn't help.
IMHO the fact that you can use plugins with Firefox means that there should be an extra security barrier inside Firefox that disallows extensions to get passwords (e.g. when accessing the password lines, it would just get the stars which are also displayed on the screen).
I wish I could use this as an excuse for all the money disappearing from my PayPal and bank accounts, but sadly I can't....
See? With Firefox, you wouldn't have that problem! :-)
Satellites do not transmit using frequencies?
You can save the return 0; line, but you cannot have void main(). In C++, falling off main without return statement is equivalent to returning 0. (That's a special rule for main, not applicable to any other C++ function.) However, according to the C++ standard, a compiler which lets you write void main() without at least giving a warning is not conforming (but then, most compilers are non-conforming anyway because they don't implement export :-)).
After some time, the computer gets bored and just to make life a bit more interesting gives you a segmentation fault.