If you allow the operating system to manage the key and/or passphrase entry, a hardware device offers no additional security.
As far as I can tell, the only additional security you might get from implementing the encryption in the hardware is that since disabling the drive encryption without losing data requires the lengthy step of rewriting all the data on the drive, it becomes harder to exfiltrate cleartext by writing it to the hard drive unencrypted. As attacks go, this isn't a very likely one; it still requires the attacker to gain physical access to the drive, when they probably have much better ways to get data off a running system. Apart from that, the OS (and thus any sufficiently privileged malware) already has direct access to all the decrypted data on the drive, so in that respect it's no different from doing the encryption in software. The OS has the additional ability to tie the encryption to a hardware security module if one is available, meaning that the drive cannot be removed from the system and decrypted offline without brute-forcing a key much longer than a typical password.
Built-in hard disk encryption is a performance optimization at most. In exchange for that small performance boost, you get attempts at security-through-obscurity with encryption-defeating bugs like the one in this article baked into the drive's firmware.
Likewise, will using a goto be clearer than the switch statement? Probably not, and the switch statement enforces a scope on the code in question (it must fall within the switch statement), where goto does not ensure this. The goto target could be embedded in an entirely different function.
The goto will almost certainly be clearer. The concerns about branching between functions are misguided, as goto labels have function scope—you can't branch to a different function in standard C. Ergo, the effective scopes of a loop & switch statement enclosing the function and a goto statement are equivalent.
The goto statement uses names, while the switch statement is using integers; if you want names you have to declare them separately, as an enum or with #define.
You have to consider the possibility that the switch argument may not match any of the provided cases. With "goto", the compiler guarantees that the target label exists.
The equivalent of "goto" is "var = NEW_STATE; continue;", which is less obvious than "goto label;" and is moreover affected by the scope issues I already addressed for the continue statement.
Finally, are you sure that the code "must fall within the switch statement"? The branch source needn't be inside the switch, just inside the loop. The control variable could even be modified from outside the function—it's effectively a computed goto, which isn't otherwise available in standard C (though there is a GCC extension).
... just because the greedy owner thinks he can charge a million. In a more normal country, this is called extortion.
First, that isn't what extortion means:
ex-tor-tion noun
the practice of obtaining something, especially money, through force or threats.
No one is using force or threats here. If you don't want to pay that much, fine—someone else will; that's why the price is so high.
Second, that "greedy" owner is only doing what any owner of any kind of property has every right to do: choose to sell, or not, on his or her own terms. If the owner doesn't want to sell, the owner doesn't have to sell. Taking the property without the owner's permission, or threatening the owner with fines or other loss of property or liberty for refusing to sell (or equivalently, for asking for "too high" a price) would be extortion.
The continue and break targets are clear enough in very simply code. They're much less clear when placed inside several levels of nested blocks. A goto statement has a named target you can easily search for, while the target of a break or continue statement is merely the end of the enclosing loop (or in the case of break, a switch statement). This may or may not be the same as the end of the current block.
Besides the lack of a named target, this points out another drawback of continue/break: wrapping code in a loop or switch statement can unintentionally change the branch target.
I've seen code where the entire body of a large function was wrapped in a "do {... } while (0)" loop just so that the programmer could use break in place of goto. It's not an improvement.
Return statements always exit the enclosing function, so they're relatively easy to analyse. The risk with multiple return points is that you may want to add code which is run unconditionally before the function returns, and that means either restructuring the function or duplicating the cleanup code.
Are there other ways? Sure. Any code using goto can be rewritten without it. A switch statement inside a loop can form a state machine with any control flow you want. But will that be clearer than using goto? Probably not.
Side-loading a new factory image isn't exactly difficult. Sure, you need the adb and fastboot tools, and it helps to be running Linux, but for the most part it's simpler than most desktop OS upgrades.
The only part I find annoying about the factory load process is that the default scripts will wipe out the user data area on the phone. There is no need for that—assuming the bootloader is already unlocked, if you just delete the -w option from the flash-all.sh script you can load new factory images while keeping your data intact.
My Nexus 5 was running Android 6.0 within days after the official release. It probably took longer to download the image than it took to perform the upgrade (not counting the interminable "Optimizing app N of 10000" sequence the phone goes through after any system update).
In C there can only be one function named do_copy() in the entire program.
And that is objectively awful.
It causes problems, sure. Either your names become unreasonably long or you risk link errors (or worse) due to name conflicts. I'm not holding C up as some kind of perfect language here, just pointing out that C++'s approach to overloading creates ambiguity. I mentioned Haskell, which has a reasonable module system. Even C++ supports namespaces, and "C with namespaces" would be fine (provided one omitted C++'s "argument-dependent lookup" rules). The problem is the ability to define multiple unrelated functions with the same name in the same scope, distinguished only by the argument type(s).
Actually, I write C code every day for my job (embedded software for avionics) and have for the last ten years. My overall experience with C is roughly twice that. But obviously I "don't know C". Or perhaps I just abused the term "program" as shorthand for "compilation unit". In any case there is never more than one function of a given name in scope, which is the important part.
The difference is overloading—not operator overloading, just overloading in general. In C there can only be one function named do_copy() in the entire program. In C++, whether we're talking about do_copy() or operator=(), there can be many, and you can't know which one will be called without knowing the types involved, and in many cases the conversion rules which the compiler will apply; some of these rules can even be user-defined.
In some ways the do_copy() case is worse, since there are at least some semi-formal conventions regarding the implementation of operator=(). Your program could link against two libraries which both provide an implementation of do_copy(), with little in common besides the name.
Other languages (e.g. Haskell) tend to solve this by requiring names to be unique within a given scope. Overloading is handled by making the name part of a polymorphic interface, with one of many available implementations is selected according to the type parameter(s). The interface represents a contract which the implementers are expected to follow, so that users of the interface can reason about the parameters, results, and side-effects in a generic way without worrying about the implementation details for whichever specific type is in use.
In the end, contracts are worthless unless there's the threat of men with guns showing up to physically enforce them.
That isn't true. The bigger threat in practice is that if you don't honor your contracts, others will stop trusting you to honor your contracts in the future. Imagine trying to operate a business without credit—not just loans, but any situation where a product or service is delivered in advance of payment. Being reduced to "cash-in-advance" dealings with other businesses would be a major blow to most companies. The prospect is more than enough to ensure that contracts will be honored without resorting to violence.
The statement "Complete and utter FUD. Has there EVER been a case where a non-family member kidnaps a specific kid based on stuff they found online?" is not true and it sounds like you aren't contesting that...
I'll contest it. The kidnapping was not "based on stuff they found online", it was based on an interactive online relationship between the "predator" and the child. Ergo, this case does not prove the statement false.
In any case this has no bearing on the danger, or lack thereof, of posting photos of your children on sites like Facebook. It may hint that in some cases there may be a danger in allowing your children to form online relationships with strangers without adult supervision.
The advantage is that compound measurements, like energy = force x distance or mass x velocity^2 don't need conversion factors.
Right, and there is no reason why you couldn't keep the same fundamental units and just use prefixes and written notation adapted for base-12 rather than base-10. As long as the units are consistent there would be no need for conversion factors.
If you pick inches then dealing with feet, yards, miles, furlongs and all other imperial measurements is very awkward.
First, those units do not form a consistent base-12 or base-60 unit system—I wasn't trying to hold up Imperial units a some kind of gold standard. Yards fit into the system naturally enough, as a divisor of 12, though they wouldn't be a base-12 unit. Miles and furlongs, on the other hand, are fairly arbitrary. Second, I think we have different ideas about what is "awkward". Measuring feet in terms of inches in base-12 is not awkward at all; it just means multiplying by the base. In base 12, 1 foot = 10 inches; 10 feet = 100 inches; 100 feet = 1000 inches. This is an awkward series of ratios in base-10 (6/5, 36/25, 216/125).
The real advantage comes when you consider fractions. One third of a meter is an awkward repeating decimal with no exact representation in any SI base unit, but would simply be 0.4 (or four of whatever we called 1/12 of a unit) in base 12. The same goes for 1/6 and 1/12. (And in base 60, 1/15 and 1/30. If base-12 has a flaw relative to base-10, it's that unlike base-60 it has no exact representation for 1/5. But thirds are more common than fifths.)
you might as well just use decimal millimetres or centimetres in multiples of 12 "blocks"
The base unit isn't the issue. The problem is the prefixes, which are based on powers of 10, not 12. For example, if you pick centimeters or millimeters as your base, dealing with meters (10^2 or 10^3 units, rather than 12^2 or 12^3) becomes very awkward. If you just ignore the SI prefixes then you're not really using the metric system, even if you happen to have an SI unit as your base. After all, even the traditional Imperial units are defined in terms of SI base units these days—that doesn't mean you're using metric when you measure lengths in inches and feet.
Base 10, being divisible only by 2 and 5, is convenient for writing decimal expansions, but not much else. Base 12, or better yet base 60, would have been better from the P.O.V. of simplifying the use of common fractions in manual arithmetic, while base 2 would have been ideal for binary computers.
No argument there. The credit contraction, made inevitable by the prior inflationary boom, caused both the deflation and the initial decline in the economy, but it was the policies instituted under Hoover and Roosevelt which prevented the sharp recovery that would otherwise have taken place, thus earning that period its label of "the Great Depression".
My point was simply that while the Great Depression did include quite a bit of deflation, there is no causative relationship between ordinary deflation, such as can be expected from increased productivity under a constant money supply, and events like the Great Depression.
In fact, the last time the US saw deflation was a period we now refer to as The Great Depression.
But not because of the deflation. The cause of the Depression was a widespread credit contraction, following an illusory boom—actually malinvestment, encouraged and masked by inflation—which resulted in a "house of cards": lots of investment profit on paper with nothing real to back it up. When the bills came due and people tried to pull "their" money out, they suddenly discovered that they didn't have nearly as much money as they thought; their savings accounts consisted mostly of IOUs from bankrupt banks. That was the cause, both of the deflation and the Depression. Deflation was merely a side-effect.
In other cases where deflation has been observed internationally, it has not been correlated with anything like the American Great Depression.
The idea that something that worked just a year or two ago should no longer work on today's browsers is unreasonable.
There will always be a cut-off point where support for older interfaces is dropped. The standard is not whether something worked a year or two ago, but whether it followed the recommended best practices in effect at that time. If you write a site using standards on the verge of being declared obsolete, you have no one to blame but yourself. Dependence on NPAPI plugins hasn't been best practice for a long time now, much longer than one year; Flash is the only plugin with any widespread support left, and it's been on its way out for a while. Sites which depend on such plugins already fail on mobile browsers, which are becoming more and more popular and haven't even supported Flash for several years, much less other plugins.
Much of the reason the web has been successful is that it has been standardised and future-proof. There were widely respected and mostly reasonable standards. There were multiple browser implementations that would let you view anything developed using those standards.
The part that was standardized and future-proof was HTML. That part still works everywhere, and even supports most of what people used to use plugins for thanks to JavaScript and HTML5. Plugins, on the other hand, have always been a compatibility nightmare—non-standardized, proprietary, and non-portable.
If you like standards and cross-browser compatibility, you should be backing this change. It means more standards-compliant web sites and fewer one-off, closed-source, browser- and OS-specific binary plugins that may or may not receive updates for security and/or compatibility with future software.
The idea that something that worked just a year or two ago should no longer work on today's browsers is unreasonable.
IE itself is deprecated, and its replacement, Edge, doesn't support NPAPI (or ActiveX) either. Using IE is no better than using an old version of Firefox.
We can't have a society based on just morality, because when you arrest someone for doing something morally wrong, they're going to say, "Who says what I did was wrong? Whose authority? I don't think what I did was wrong!"; How do you argue with that without essentially stating, "I'm right because I'm right and can enforce my will through violence"?
The "framework of laws" approach doesn't address this problem either. It just means that some people (maybe a majority, maybe just a vocal minority) got together and wrote up some laws that they agreed with. In the end, the law is still based on the same subjective morals. The person you're trying to enforce the laws on did not consent to follow them simply by being born in the same arbitrary geopolitical region as those who wrote the laws.
The only rational basis for law which does not depend on subjective morality is reciprocation. Someone who commits murder cannot rationally complain about being executed; a thief has no just cause to complain about being fined. Whatever you do to others, they can do to you—without any need for debate over whether what you did was right or wrong. It suffices to classify a given action the same way regardless of who carries it out. If you agree that what you did was wrong, that implies that you accept responsibility for the consequences. If not, then a response in kind cannot be wrong either.
Closing them off in Firefox as well just means anyone who actually relies on them is now left on IE forever. Again.
They could just as easily use an old version of Firefox instead. It's not like the previous versions are going anywhere, and it isn't unreasonable for ancient, unmaintained web sites using obsolete plugins to require a contemporary web browser.
If you're going to say "Google is an advertising firm, not a technology firm" just because they derive their income from advertising, you may as well say "Lego isn't a toy company, they are a sales company" because they derive their income from sales.
On the contrary, Lego is a toy company because their customers (i.e. the people paying them money) are buyers of toys. They also happen to perform sales and many other tasks common to all businesses. I'm sure they have an accounting department as well, but that doesn't make them an accounting firm. Google's customers are advertisers; that makes them an advertising company. They also happen to dabble in technology, among other fields, but it's all to serve the one area which brings them an actual income: advertising.
A technology firm would be one that develops and licenses or sells technology for use by others, e.g. Intel, Freescale, Microsoft. Using technology internally, or providing it for free to the public as a way of collecting data to be sold to advertisers, does not make you a technology firm.
You think the political philosophy of libertarianism does not favour a particular economic model and vice versa ?
Libertarianism aside, reality favors the capitalistic economic model. It's the only one that works for any group of significant size. And if you start from the Non-Aggression Principle, free markets and capitalism are sure to follow. That does not imply that libertarianism is based on capitalism in general or the Austrian school of economics in particular, which is what you claimed.
As an aside, you should know that personal attacks just make you look bad, and don't help your case.
Hell not only do they lack evidence they even use their own custom definition of inflation as "increased money supply". The proper definition is "decreased buying power".
That's because "decreased buying power" is a conflation of a huge number of possible factors, which makes any analysis of "inflation" by your definition meaningless. Regardless of whether you call it "inflation" or something else, the only factor that matters is the change in the money supply.
But the "Austrian School" denies the fundamental existence of SCIENCE.
Nonsense. The Austrian school doesn't deny the existence of science (obviously), just the applicability of the typical scientific process as a means of deriving economic models which can effectively predict human behavior, particularly when those models are (ab)used in an attempt to change how people behave. People always manage to come up with innovative and unpredictable solutions to get around whatever changes you're trying to force on them.
Effective economic predictions have more to do with the mathematical/logical domain of game theory than anything empirical. Austrian economics recognizes that, where other schools do not. You can, of course, measure the empirical results of specific economic policies and circumstances, but don't expect past performance to be a reliable predictor of future results.
including the Austrian model (which libertarianism is based on)
Libertarianism is a political philosophy based on the Non-Aggression Principle, not an economic model. You don't have to agree with Austrian economics, or even think that libertarian policies will be economically beneficial, to be a libertarian. It's a philosophy based on the principle of rights, not pragmatism—which is not to say that it isn't also the pragmatic choice for entirely different reasons.
New York is where both engines of USAir flight were hit by soft bodied geese weighing less than 20 pounds each and forced the plane to crash land in the Hudson river. The drones have hard metal parts and hard plastic. They would do far more damage to the plane.
As this is an obvious design flaw in the plane with or without drones, perhaps the FAA should consider mandating suitable filters on the engine intakes for commercial planes, instead of trying to ban anything that might cross a plane's path.
Slashdot Mirror
If you allow the operating system to manage the key and/or passphrase entry, a hardware device offers no additional security.
As far as I can tell, the only additional security you might get from implementing the encryption in the hardware is that since disabling the drive encryption without losing data requires the lengthy step of rewriting all the data on the drive, it becomes harder to exfiltrate cleartext by writing it to the hard drive unencrypted. As attacks go, this isn't a very likely one; it still requires the attacker to gain physical access to the drive, when they probably have much better ways to get data off a running system. Apart from that, the OS (and thus any sufficiently privileged malware) already has direct access to all the decrypted data on the drive, so in that respect it's no different from doing the encryption in software. The OS has the additional ability to tie the encryption to a hardware security module if one is available, meaning that the drive cannot be removed from the system and decrypted offline without brute-forcing a key much longer than a typical password.
Built-in hard disk encryption is a performance optimization at most. In exchange for that small performance boost, you get attempts at security-through-obscurity with encryption-defeating bugs like the one in this article baked into the drive's firmware.
Likewise, will using a goto be clearer than the switch statement? Probably not, and the switch statement enforces a scope on the code in question (it must fall within the switch statement), where goto does not ensure this. The goto target could be embedded in an entirely different function.
The goto will almost certainly be clearer. The concerns about branching between functions are misguided, as goto labels have function scope—you can't branch to a different function in standard C. Ergo, the effective scopes of a loop & switch statement enclosing the function and a goto statement are equivalent.
The goto statement uses names, while the switch statement is using integers; if you want names you have to declare them separately, as an enum or with #define.
You have to consider the possibility that the switch argument may not match any of the provided cases. With "goto", the compiler guarantees that the target label exists.
The equivalent of "goto" is "var = NEW_STATE; continue;", which is less obvious than "goto label;" and is moreover affected by the scope issues I already addressed for the continue statement.
Finally, are you sure that the code "must fall within the switch statement"? The branch source needn't be inside the switch, just inside the loop. The control variable could even be modified from outside the function—it's effectively a computed goto, which isn't otherwise available in standard C (though there is a GCC extension).
... just because the greedy owner thinks he can charge a million. In a more normal country, this is called extortion.
First, that isn't what extortion means:
ex-tor-tion
noun
the practice of obtaining something, especially money, through force or threats.
No one is using force or threats here. If you don't want to pay that much, fine—someone else will; that's why the price is so high.
Second, that "greedy" owner is only doing what any owner of any kind of property has every right to do: choose to sell, or not, on his or her own terms. If the owner doesn't want to sell, the owner doesn't have to sell. Taking the property without the owner's permission, or threatening the owner with fines or other loss of property or liberty for refusing to sell (or equivalently, for asking for "too high" a price) would be extortion.
The continue and break targets are clear enough in very simply code. They're much less clear when placed inside several levels of nested blocks. A goto statement has a named target you can easily search for, while the target of a break or continue statement is merely the end of the enclosing loop (or in the case of break, a switch statement). This may or may not be the same as the end of the current block.
Besides the lack of a named target, this points out another drawback of continue/break: wrapping code in a loop or switch statement can unintentionally change the branch target.
I've seen code where the entire body of a large function was wrapped in a "do { ... } while (0)" loop just so that the programmer could use break in place of goto. It's not an improvement.
Return statements always exit the enclosing function, so they're relatively easy to analyse. The risk with multiple return points is that you may want to add code which is run unconditionally before the function returns, and that means either restructuring the function or duplicating the cleanup code.
Are there other ways? Sure. Any code using goto can be rewritten without it. A switch statement inside a loop can form a state machine with any control flow you want. But will that be clearer than using goto? Probably not.
Side-loading a new factory image isn't exactly difficult. Sure, you need the adb and fastboot tools, and it helps to be running Linux, but for the most part it's simpler than most desktop OS upgrades.
The only part I find annoying about the factory load process is that the default scripts will wipe out the user data area on the phone. There is no need for that—assuming the bootloader is already unlocked, if you just delete the -w option from the flash-all.sh script you can load new factory images while keeping your data intact.
My Nexus 5 was running Android 6.0 within days after the official release. It probably took longer to download the image than it took to perform the upgrade (not counting the interminable "Optimizing app N of 10000" sequence the phone goes through after any system update).
In C there can only be one function named do_copy() in the entire program.
And that is objectively awful.
It causes problems, sure. Either your names become unreasonably long or you risk link errors (or worse) due to name conflicts. I'm not holding C up as some kind of perfect language here, just pointing out that C++'s approach to overloading creates ambiguity. I mentioned Haskell, which has a reasonable module system. Even C++ supports namespaces, and "C with namespaces" would be fine (provided one omitted C++'s "argument-dependent lookup" rules). The problem is the ability to define multiple unrelated functions with the same name in the same scope, distinguished only by the argument type(s).
Actually, I write C code every day for my job (embedded software for avionics) and have for the last ten years. My overall experience with C is roughly twice that. But obviously I "don't know C". Or perhaps I just abused the term "program" as shorthand for "compilation unit". In any case there is never more than one function of a given name in scope, which is the important part.
The difference is overloading—not operator overloading, just overloading in general. In C there can only be one function named do_copy() in the entire program. In C++, whether we're talking about do_copy() or operator=(), there can be many, and you can't know which one will be called without knowing the types involved, and in many cases the conversion rules which the compiler will apply; some of these rules can even be user-defined.
In some ways the do_copy() case is worse, since there are at least some semi-formal conventions regarding the implementation of operator=(). Your program could link against two libraries which both provide an implementation of do_copy(), with little in common besides the name.
Other languages (e.g. Haskell) tend to solve this by requiring names to be unique within a given scope. Overloading is handled by making the name part of a polymorphic interface, with one of many available implementations is selected according to the type parameter(s). The interface represents a contract which the implementers are expected to follow, so that users of the interface can reason about the parameters, results, and side-effects in a generic way without worrying about the implementation details for whichever specific type is in use.
In the end, contracts are worthless unless there's the threat of men with guns showing up to physically enforce them.
That isn't true. The bigger threat in practice is that if you don't honor your contracts, others will stop trusting you to honor your contracts in the future. Imagine trying to operate a business without credit—not just loans, but any situation where a product or service is delivered in advance of payment. Being reduced to "cash-in-advance" dealings with other businesses would be a major blow to most companies. The prospect is more than enough to ensure that contracts will be honored without resorting to violence.
The statement "Complete and utter FUD. Has there EVER been a case where a non-family member kidnaps a specific kid based on stuff they found online?" is not true and it sounds like you aren't contesting that...
I'll contest it. The kidnapping was not "based on stuff they found online", it was based on an interactive online relationship between the "predator" and the child. Ergo, this case does not prove the statement false.
In any case this has no bearing on the danger, or lack thereof, of posting photos of your children on sites like Facebook. It may hint that in some cases there may be a danger in allowing your children to form online relationships with strangers without adult supervision.
The advantage is that compound measurements, like energy = force x distance or mass x velocity^2 don't need conversion factors.
Right, and there is no reason why you couldn't keep the same fundamental units and just use prefixes and written notation adapted for base-12 rather than base-10. As long as the units are consistent there would be no need for conversion factors.
If you pick inches then dealing with feet, yards, miles, furlongs and all other imperial measurements is very awkward.
First, those units do not form a consistent base-12 or base-60 unit system—I wasn't trying to hold up Imperial units a some kind of gold standard. Yards fit into the system naturally enough, as a divisor of 12, though they wouldn't be a base-12 unit. Miles and furlongs, on the other hand, are fairly arbitrary. Second, I think we have different ideas about what is "awkward". Measuring feet in terms of inches in base-12 is not awkward at all; it just means multiplying by the base. In base 12, 1 foot = 10 inches; 10 feet = 100 inches; 100 feet = 1000 inches. This is an awkward series of ratios in base-10 (6/5, 36/25, 216/125).
The real advantage comes when you consider fractions. One third of a meter is an awkward repeating decimal with no exact representation in any SI base unit, but would simply be 0.4 (or four of whatever we called 1/12 of a unit) in base 12. The same goes for 1/6 and 1/12. (And in base 60, 1/15 and 1/30. If base-12 has a flaw relative to base-10, it's that unlike base-60 it has no exact representation for 1/5. But thirds are more common than fifths.)
you might as well just use decimal millimetres or centimetres in multiples of 12 "blocks"
The base unit isn't the issue. The problem is the prefixes, which are based on powers of 10, not 12. For example, if you pick centimeters or millimeters as your base, dealing with meters (10^2 or 10^3 units, rather than 12^2 or 12^3) becomes very awkward. If you just ignore the SI prefixes then you're not really using the metric system, even if you happen to have an SI unit as your base. After all, even the traditional Imperial units are defined in terms of SI base units these days—that doesn't mean you're using metric when you measure lengths in inches and feet.
Base 10, being divisible only by 2 and 5, is convenient for writing decimal expansions, but not much else. Base 12, or better yet base 60, would have been better from the P.O.V. of simplifying the use of common fractions in manual arithmetic, while base 2 would have been ideal for binary computers.
No argument there. The credit contraction, made inevitable by the prior inflationary boom, caused both the deflation and the initial decline in the economy, but it was the policies instituted under Hoover and Roosevelt which prevented the sharp recovery that would otherwise have taken place, thus earning that period its label of "the Great Depression".
My point was simply that while the Great Depression did include quite a bit of deflation, there is no causative relationship between ordinary deflation, such as can be expected from increased productivity under a constant money supply, and events like the Great Depression.
In fact, the last time the US saw deflation was a period we now refer to as The Great Depression.
But not because of the deflation. The cause of the Depression was a widespread credit contraction, following an illusory boom—actually malinvestment, encouraged and masked by inflation—which resulted in a "house of cards": lots of investment profit on paper with nothing real to back it up. When the bills came due and people tried to pull "their" money out, they suddenly discovered that they didn't have nearly as much money as they thought; their savings accounts consisted mostly of IOUs from bankrupt banks. That was the cause, both of the deflation and the Depression. Deflation was merely a side-effect.
In other cases where deflation has been observed internationally, it has not been correlated with anything like the American Great Depression.
The sheepdogs are always going to be more dangerous than the sheep.
When the "sheepdogs" are dangerous to the sheep, we tend to call them "wolves".
The idea that something that worked just a year or two ago should no longer work on today's browsers is unreasonable.
There will always be a cut-off point where support for older interfaces is dropped. The standard is not whether something worked a year or two ago, but whether it followed the recommended best practices in effect at that time. If you write a site using standards on the verge of being declared obsolete, you have no one to blame but yourself. Dependence on NPAPI plugins hasn't been best practice for a long time now, much longer than one year; Flash is the only plugin with any widespread support left, and it's been on its way out for a while. Sites which depend on such plugins already fail on mobile browsers, which are becoming more and more popular and haven't even supported Flash for several years, much less other plugins.
Much of the reason the web has been successful is that it has been standardised and future-proof. There were widely respected and mostly reasonable standards. There were multiple browser implementations that would let you view anything developed using those standards.
The part that was standardized and future-proof was HTML. That part still works everywhere, and even supports most of what people used to use plugins for thanks to JavaScript and HTML5. Plugins, on the other hand, have always been a compatibility nightmare—non-standardized, proprietary, and non-portable.
If you like standards and cross-browser compatibility, you should be backing this change. It means more standards-compliant web sites and fewer one-off, closed-source, browser- and OS-specific binary plugins that may or may not receive updates for security and/or compatibility with future software.
The idea that something that worked just a year or two ago should no longer work on today's browsers is unreasonable.
IE itself is deprecated, and its replacement, Edge, doesn't support NPAPI (or ActiveX) either. Using IE is no better than using an old version of Firefox.
We can't have a society based on just morality, because when you arrest someone for doing something morally wrong, they're going to say, "Who says what I did was wrong? Whose authority? I don't think what I did was wrong!"; How do you argue with that without essentially stating, "I'm right because I'm right and can enforce my will through violence"?
The "framework of laws" approach doesn't address this problem either. It just means that some people (maybe a majority, maybe just a vocal minority) got together and wrote up some laws that they agreed with. In the end, the law is still based on the same subjective morals. The person you're trying to enforce the laws on did not consent to follow them simply by being born in the same arbitrary geopolitical region as those who wrote the laws.
The only rational basis for law which does not depend on subjective morality is reciprocation. Someone who commits murder cannot rationally complain about being executed; a thief has no just cause to complain about being fined. Whatever you do to others, they can do to you—without any need for debate over whether what you did was right or wrong. It suffices to classify a given action the same way regardless of who carries it out. If you agree that what you did was wrong, that implies that you accept responsibility for the consequences. If not, then a response in kind cannot be wrong either.
Closing them off in Firefox as well just means anyone who actually relies on them is now left on IE forever. Again.
They could just as easily use an old version of Firefox instead. It's not like the previous versions are going anywhere, and it isn't unreasonable for ancient, unmaintained web sites using obsolete plugins to require a contemporary web browser.
If you're going to say "Google is an advertising firm, not a technology firm" just because they derive their income from advertising, you may as well say "Lego isn't a toy company, they are a sales company" because they derive their income from sales.
On the contrary, Lego is a toy company because their customers (i.e. the people paying them money) are buyers of toys. They also happen to perform sales and many other tasks common to all businesses. I'm sure they have an accounting department as well, but that doesn't make them an accounting firm. Google's customers are advertisers; that makes them an advertising company. They also happen to dabble in technology, among other fields, but it's all to serve the one area which brings them an actual income: advertising.
A technology firm would be one that develops and licenses or sells technology for use by others, e.g. Intel, Freescale, Microsoft. Using technology internally, or providing it for free to the public as a way of collecting data to be sold to advertisers, does not make you a technology firm.
You think the political philosophy of libertarianism does not favour a particular economic model and vice versa ?
Libertarianism aside, reality favors the capitalistic economic model. It's the only one that works for any group of significant size. And if you start from the Non-Aggression Principle, free markets and capitalism are sure to follow. That does not imply that libertarianism is based on capitalism in general or the Austrian school of economics in particular, which is what you claimed.
As an aside, you should know that personal attacks just make you look bad, and don't help your case.
Hell not only do they lack evidence they even use their own custom definition of inflation as "increased money supply". The proper definition is "decreased buying power".
That's because "decreased buying power" is a conflation of a huge number of possible factors, which makes any analysis of "inflation" by your definition meaningless. Regardless of whether you call it "inflation" or something else, the only factor that matters is the change in the money supply.
But the "Austrian School" denies the fundamental existence of SCIENCE.
Nonsense. The Austrian school doesn't deny the existence of science (obviously), just the applicability of the typical scientific process as a means of deriving economic models which can effectively predict human behavior, particularly when those models are (ab)used in an attempt to change how people behave. People always manage to come up with innovative and unpredictable solutions to get around whatever changes you're trying to force on them.
Effective economic predictions have more to do with the mathematical/logical domain of game theory than anything empirical. Austrian economics recognizes that, where other schools do not. You can, of course, measure the empirical results of specific economic policies and circumstances, but don't expect past performance to be a reliable predictor of future results.
including the Austrian model (which libertarianism is based on)
Libertarianism is a political philosophy based on the Non-Aggression Principle, not an economic model. You don't have to agree with Austrian economics, or even think that libertarian policies will be economically beneficial, to be a libertarian. It's a philosophy based on the principle of rights, not pragmatism—which is not to say that it isn't also the pragmatic choice for entirely different reasons.
New York is where both engines of USAir flight were hit by soft bodied geese weighing less than 20 pounds each and forced the plane to crash land in the Hudson river. The drones have hard metal parts and hard plastic. They would do far more damage to the plane.
As this is an obvious design flaw in the plane with or without drones, perhaps the FAA should consider mandating suitable filters on the engine intakes for commercial planes, instead of trying to ban anything that might cross a plane's path.