That's debatable. The movie was enjoyable, but some of the dialog-heavy segments were stilted enough to make it difficult to maintain suspension of disbelief.
The solution SHOULD be that browsers DISALLOW loading Javascript (or any script as the case may be) from more than one different hostname per page (e.g. the page's own hostname not being counted against the limit of one). This would remain flexible enough to reference scripts from a different server, or even an advertising provider, without allowing it to get excessive.
This would cause problems for lots of sites that use javascript libraries, like jQuery et al, and load them from the canonical library sources. Of course, sites could host their libraries themselves, but that would require them to keep them up to date, and it would keep them from being cached and reused across different sites.
Plus, your suggestion basically boils down to "let's break sites of clueless web developers so they'll get a clue". I don't object to that on principle, but it's not practical. What happens when a browser implements your ideas? Lots of crappy web sites don't work any more for users of that browser. What you want is the developers to fix their site. What will happen is that users will switch to a browser that works.
It didn't really answer the question about what would happen if a bullet hit a window; it just assumes the whole window blows out. I'd like to see a discussion of the type of glass used in airliner windows and how badly they'd fracture/shatter. I'm also really doubtful that it would "suck someone out of the plane".
On that last point, airliners are pressurized at 8000 feet, which means the cabins are at 10.9 PSI. The exterior pressure at 30000 feet is 4.4 PSI, so we have a 6.5 PSI difference. Airline windows are around 9x14, so a body sealing the hole at the instant it is completely removed would be subject to 9*14*6.5 = 819 pounds of pressure. That's a lot, but no one would be in that position (unless the bullet first passed through them!). As the cabin air rushes out, that differential will drop off fast, so if you can stay away from the window for a few seconds, it would quickly drop to a level that can't do much damage to you. And I can see no way that the rush of air -- which only applies 800 pounds of pressure across the window area right AT the window could lift a 150 pound body a few feet from the window.
Someone standing a few feet from the window could be pulled off-balance into it so, given exactly the right set of circumstances, someone could get knocked into the window frame very soon after the window completely blew out (assuming it would blow out) and that person would be severely injured or even killed and there's even a slim chance the pressure could break the bones needed to allow them to pass through the window. But lifted out of their seat by the airflow? I don't see it.
Also, you misread what the article said about the air supply. It did not say the supplemental oxygen system is limited to 1-2 minutes (that would be rather silly if you think about it). It said that a person at 30,000 feet without supplemental oxygen will become incoherent in a minute or so.
Agreed that hitting control lines can be very bad, though airliners do have some redundancy in their control systems. A friend of mine who used to work on avionics software spent many months building a test suite for the 777 to simulate lost control circuits, so they could verify that the redundancy worked correctly. This was for some reason more challenging to test properly on a fly-by-wire plane than a traditional aircraft.
Finally, this leads me to the most disappointing part of the article: the claim that a bullet striking a fuel take would cause an explosion. It's possible, but not very likely. First, JP-8 is only explosive in vapor form, in concentrations between 0.6% and 4.7% by volume, which can only occur in tanks that are nearly empty. Second, bullets cannot strike sparks on aluminum. Actually, copper and lead bullets can't strike sparks directly on anything, but if they hit ferrous metal and impart velocity to it that causes it to strike other ferrous metal, the secondary collision can strike a spark. So for a bullet to strike a spark in an airplane tank, it would have to hit a structural support which is not strong enough to stop the bullet, and knock off a piece of steel which then strikes another structural support with enough force to strike a spark, and that sparking would have to occur inside a nearly-empty fuel tank.
It could happen, but it would take a series of unlikely events. Much, much more likely, a fuel tank would just be holed, and having fuel streaming out of the tank would create a problem when the plane tried to land.
I recently read a book about the history of Google, and based on what I read, I don't think there was ever a time they didn't know what to do with their algorithm.
There were a couple of years during which they weren't certain how to monetize it, though. Larry and Sergey completely rejected advertising for a long time, and it wasn't until they compromised by agreeing to do unobtrusive, relevant, text-only ads rather paid search placement (what most potential investors wanted them to do) or obnoxious banner ads (what nearly all Internet advertising of the day was). Even then the business model didn't really come together until they adopted a competitor's (I forget who) innovation of a real-time advertising auction. They added some refinements to the auction algorithm and then the money started rolling in.
Perhaps you've heard of this company called Google - started with a $25 million investment from Kleiner Perkins Caufield & Byers and Sequoia Capital.
No. Google had been around for years, and had a solid track record by the time VCs got interested. They did get angel funding of $100K earlier, but even that was after they had been up and running for over a year.
Not really relevant, but interesting, IMO: Google had an even earlier investor -- Stanford University. Their biggest early operating expense would have been their Internet connection, but they used Stanford's. They also used their university contacts to scrounge a lot of hardware, and put it all in Sergey's dorm room. Google search actually got big enough that it was straining Stanford's network and Stanford's IT department was already fielding complaints from businesses who were unhappy about their search rank placement when they finally got the $100K and used it to move off campus (and into a proper garage).
2) Assuming the window shatters rather than just holing (I don't know what would happen; it depends on the type of glass, though I suspect it's tempered like auto glass and wouldn't shatter) then you'd get a larger hole which the pressure maintenance system couldn't keep up with. The plane would lose pressure over the course of a minute or two, the oxygen masks would drop and the plane would have to lose altitude and divert to a nearby airfield.
All undercover TSA agents and any armed pilots use ammunition specifically designed to not rupture the hull.
Nonsense. They carry regular jacketed hollowpoints, just like any other police officers, or civilians for that matter. A gunshot in a pressurized plane just pokes a small hole which the plane's normal pressure-maintenance systems can easily compensate for.
Why exactly do you think they would do this rather than simply sharing the info like he said?
Because privacy advocates will scream bloody murder about just sharing the lists. The only check on government action is the voice of the people, but if the people are loud enough, it can work.
They're the government and they can pretty much do whatever they want with the info once they get it because no one is going to limit them.
Which is exactly why it makes sense to employ a cryptographic protocol so they can find the e-Bay high-earning welfare recipients but cannot get any other information out of it. To use math to make it impossible for them to use the data in any way beyond the stated purpose. That still leaves open the question of whether or not allowing the data to be used for the stated purpose is a good idea (personally, I think you give up some privacy in exchange for welfare money, so I'm not opposed), but it at least closes off concerns about the government using the data for other things.
You can't just tell the government "sure you can completely undermine someone's privacy BUT ONLY FOR THIS ONE THING, OKAY?"
You can if you can ensure that they don't have the ability to undermine the privacy for other things.
A problem with your scheme is that it still gives too much information to whichever party gets the lists and does the comparisons.
e-Bay could take the list of welfare ID hashes and use it to identify all of their users who are on welfare, and then potentially misuse that data.
The government could take the list of e-Bay high-earner ID hashes and use it to identify all of its citizens who are e-Bay high earners, not just welfare recipients.
One solution is to have both give their lists to a third party, who would identify the intersection and return that to the government. But that gives the third party a list of ID hashes which could be used to identify people who are in either set (and which set(s) they're in). But if e-Bay and the government agree on a key and generated keyed hashes, the third party (who doesn't have the key) can only identify intersections, and cannot do its own hashing of personal data to match that to people.
As an added backstop against disclosure of the key to the third party, rather than building and sending a list, e-Bay could generate a Bloom filter of the keyed hashes, and deliver the filter data to the third party, who could then test each government-provided hash against the filter and return the list of positives. The false positive rate would need to be set low enough that a positive constitutes probable cause for a warrant, which could then be served to e-Bay to retrieve the person's information in the proper way.
It might even be possible to flip the sense of the test so that Bloom errors become false negatives rather than false positives. This would ensure that everyone who is matched is actually in the intersection of the two sets, while allowing some in the intersection to "get away". In fact, if this could be done (I need to think about it), you could actually set the false negative rate to be very high, which reveals even less information to the third party and to the government, but would still provide a sufficiently high probability of discovery (and prosecution) that welfare recipients would take care to properly disclose their e-Bay earnings.
If you can decrypt something that means there is a method to do so. You pass the message and one-time pad into this "function" and receive output.
Yes, but how do you know when the output is correct?
This is why an OTP provides perfect secrecy, if the key is secret. For a given ciphertext, there is some key that transforms it into every possible plaintext of the right length. This means that the result of brute force searching the keyspace for an n-bit ciphertext is every possible n-bit message. Thus, the only information you can get out of an OTP-encrypted message is the message length -- assuming it wasn't padded. With padding, the only information you can get is the maximum length.
The same problem actually occurs with "normal" ciphers and short messages. If I use AES to encrypt a one-bit message (perhaps padding the rest of the block with random bits), every possible AES key will result in an apparently-valid decryption -- the first bit will be either 0 or 1. But I have no way to tell which is right, even though I know that 2^128-1 of them are wrong. Claude Shannon defined the concept of the "unicity distance" to describe this, "unicity distance" being, basically, the length of the smallest amount of ciphertext which an attacker with infinite resources needs in order to determine the correct key, by examining resulting plaintexts. With an OTP, the unicity distance is infinite because as the message grows so dos the key, without bound.
Assuming the key is secret... which is the hard part with one-time pad protocols.
This particular therapist is in such high demand that she only accepts payment up front, directly from patients. My insurance will pay, but I have to handle claim submission and wading through the associated red tape.
Given that we haven't yet found any evidence of God's hand that would stand up to skeptical scrutiny, I posit that God does not want us to find scientific proof of His creation or intervention. There's even a clear and simple reason: presence of scientific proof would remove the requirement to first have faith before knowledge can be obtained. If God has a reason not to provide us with proof, we won't find proof. If God does not have such a reason, I think we'd have found something by now. Also, for theological reasons I believe that faith as a pre-requisite for knowledge is an essential, fundamental part of God's plan. Therefore, I expect that no compelling examples of irreducible complexity will be discovered.
The fact that hard work and talent often don't equal success on the first try doesn't mean they don't equal success. It just means that there's a large element of randomness in play at all times, and even hard work and talent don't necessarily give you high odds of success in any one endeavor. However, hard work and talent do tilt the odds in your favor, so -- except for people who get extraordinarily unlucky -- hard work, talent and persistence do equal success. On balance, I'd say that persistence is the most important of those traits, followed by hard work, with talent coming in a distant third. Which isn't to say talent isn't valuable -- in many cases it's essential. But it's almost never enough.
Well ok, Google has better offerings than a lowly local government offers.:) None of the HSA pitches I have seen made sense if you were already diagnosed with anything serious, that yours is still competitive with three major illnesses to cover out of pocket is not typical.
Perhaps. But note that IBM's plan was also competitive, primarily because the high-deductible premiums were substantially lower. I strongly encourage people to actually model their expected expenses in detail. I was surprised, and you might be as well.
You are failing to understand the products offered and have selected the wrong one. You want traditional 'insurance' if you have expensive preexisting conditions.
Not necessarily. My wife has chronic kidney disease. My boys have ADD/ADHD. My daughter has a mental illness that is very expensive. Yet every year I build a spreadsheet, work out the expected total costs for all of the options, and end up going with the high-deductible with HSA. At my current employer (Google), this is largely because the company contribution is so generous that it nearly covers the deductible, but even at my previous employer (IBM), the high deductible plan was more economical because the premiums were so much lower.
Yes, it's a little painful at the first of the year when I'm spending nearly $1K per month on medications (mostly for my daughter), but I just have to budget for it and make sure I have the cash reserves. By March I've met the deductible and am in 80/20 territory. Usually by fall I've met the out-of-pocket limit and insurance is paying 100%. One of the non-obvious benefits I've noticed is that on a traditional plan with fixed co-pays, the co-pays don't drop off when you hit the OOP limit, but with strict X% coverage.
So, I have an HSA and an FSA, spend them both dry every year, and it's still cheaper to take the high-deductible plan rather than the traditional offerings, at least the ones that have been available to me (and IBM's offerings were pretty good, and Google's are really excellent).
Actually, this year my model showed that a more traditional plan would save me about a thousand for the year, so that's what I did. But the reason was that the traditional plan happened to have better out-of-network coverage, since my daughter's therapist wasn't in the network and we didn't want to find another. That wasn't anything inherent in high-deductible vs traditional plans, though, just a quirk of the details of the two plans.
For goodness sake, life doesn't have to be a battle all the time
Which is why I don't use Windows. Your mileage has obviously varied, but I just find a *nix system more comfortable and easier to use. I hugely prefer the repository-based method of software distribution, and -- though I understand Windows has gotten good in this area -- much prefer the stability and reliability I get from Linux. That's the biggest reason I switched years ago.
These days, I use OS X and Linux, and both are very decent systems, though honestly the only reason I use OS X is that I prefer Apple hardware over the Lenovo Thinkpad and company policy won't allow me to install Linux on my company-issue MacBook Pro. As for fiddling to make hardware work... I haven't done that for nearly a decade, but I suppose that's largely because good Linux support is the #1 requirement for any piece of hardware I buy. In recent years it's gotten to where I really don't have to worry about it -- darned near everything works just fine on Linux -- but when it was harder I did the research I needed to, so I didn't have to spend time fiddling.
Anyway, my point is that while I'm sorry you've found Linux to be a struggle, don't assume that others use it only because they're "fanboys" or because they enjoy spending more time fiddling with their computers than using them. For many of us, Linux is less fiddly and more comfortable.
First, there is an Android/iPhone/BlackBerry authenticator app (software one-time pad) that you can and should use instead of SMS-sent confirmation code if you don't have a dumbphone.
Second, if you cannot use such an app: obviously SMS represents in no way a secure channel, but it still adds another unsecure channel a potential attacker has to identify then crack (although wiretapping SMS is peanut butter for NSA and friends, linking phone number to Google account might not always be trivial when using prepaid cards for example).
Another option is to pre-generate a list of codes, print them out and cross them off as you use them. When you get low, log in and generate and print another set.
We've apparently been talking about different things. I've been talking about the impact of the app, you've been talking about sales volumes and purchase considerations.:-)
I really don't see how it's useful when assessing the impact of an application, to consider whether the devices that app runs on run on a platform from a single vendor or one from multiple vendors. What matters is how many people use that platform, and therefore have access to that app. Apple is doing very well, but iOS is a minority platform, and the current trends (extrapolating current trends into the future is very risky, obviously) indicate that the iOS market share, as a percentage, has peaked and will continue declining from here. I very much doubt that concerns Apple -- they're quite happy to keep the most lucrative segment of a growing market.
rat7307's comment is correct. iOS is a minority platform, and at the present sales rates it will stay that way. Apple's sales volumes are very nice for Apple, but they are not increasing at anything like the pace that would be needed for iOS to become anything more than a (large) minority platform. Even just on mobile, it's not clear that iOS is going to be anything other than a minority platform (it has already fallen behind Android in phones, and Android is making up ground in the tablet market, too).
Your first idea will do exactly what you want. It'll resume interrupted uploads, verify upload integrity, be secure in whatever context you're in... it's perfect. As long as you don't specify the --delete option, it won't delete remote files just because local files are gone, either.
A crontab line with: "killall rsync && rsync -a ~/local/photo/dir hostname.foo.net:remote/photo/dir" will do the job admirably. Set it to run every 10 minutes or so. You could obviously polish this solution in various ways, but it's quick, it's easy and it will work.
Slashdot Mirror
No, because it showed they don't have to be...
That's debatable. The movie was enjoyable, but some of the dialog-heavy segments were stilted enough to make it difficult to maintain suspension of disbelief.
No, duh. They are launching a subscription service in the US. The SEALs are there for the TV commercials.
Because Act of Valor showed the world that SEALs are incredibly talented actors?
You've just given my gun-nut, chemistry & mech engineering friends an interesting weekend project
That sounds like an awesome weekend!
The solution SHOULD be that browsers DISALLOW loading Javascript (or any script as the case may be) from more than one different hostname per page (e.g. the page's own hostname not being counted against the limit of one). This would remain flexible enough to reference scripts from a different server, or even an advertising provider, without allowing it to get excessive.
This would cause problems for lots of sites that use javascript libraries, like jQuery et al, and load them from the canonical library sources. Of course, sites could host their libraries themselves, but that would require them to keep them up to date, and it would keep them from being cached and reused across different sites.
Plus, your suggestion basically boils down to "let's break sites of clueless web developers so they'll get a clue". I don't object to that on principle, but it's not practical. What happens when a browser implements your ideas? Lots of crappy web sites don't work any more for users of that browser. What you want is the developers to fix their site. What will happen is that users will switch to a browser that works.
Hmm. I'm not very impressed with that article.
It didn't really answer the question about what would happen if a bullet hit a window; it just assumes the whole window blows out. I'd like to see a discussion of the type of glass used in airliner windows and how badly they'd fracture/shatter. I'm also really doubtful that it would "suck someone out of the plane".
On that last point, airliners are pressurized at 8000 feet, which means the cabins are at 10.9 PSI. The exterior pressure at 30000 feet is 4.4 PSI, so we have a 6.5 PSI difference. Airline windows are around 9x14, so a body sealing the hole at the instant it is completely removed would be subject to 9*14*6.5 = 819 pounds of pressure. That's a lot, but no one would be in that position (unless the bullet first passed through them!). As the cabin air rushes out, that differential will drop off fast, so if you can stay away from the window for a few seconds, it would quickly drop to a level that can't do much damage to you. And I can see no way that the rush of air -- which only applies 800 pounds of pressure across the window area right AT the window could lift a 150 pound body a few feet from the window.
Someone standing a few feet from the window could be pulled off-balance into it so, given exactly the right set of circumstances, someone could get knocked into the window frame very soon after the window completely blew out (assuming it would blow out) and that person would be severely injured or even killed and there's even a slim chance the pressure could break the bones needed to allow them to pass through the window. But lifted out of their seat by the airflow? I don't see it.
Also, you misread what the article said about the air supply. It did not say the supplemental oxygen system is limited to 1-2 minutes (that would be rather silly if you think about it). It said that a person at 30,000 feet without supplemental oxygen will become incoherent in a minute or so.
Agreed that hitting control lines can be very bad, though airliners do have some redundancy in their control systems. A friend of mine who used to work on avionics software spent many months building a test suite for the 777 to simulate lost control circuits, so they could verify that the redundancy worked correctly. This was for some reason more challenging to test properly on a fly-by-wire plane than a traditional aircraft.
Finally, this leads me to the most disappointing part of the article: the claim that a bullet striking a fuel take would cause an explosion. It's possible, but not very likely. First, JP-8 is only explosive in vapor form, in concentrations between 0.6% and 4.7% by volume, which can only occur in tanks that are nearly empty. Second, bullets cannot strike sparks on aluminum. Actually, copper and lead bullets can't strike sparks directly on anything, but if they hit ferrous metal and impart velocity to it that causes it to strike other ferrous metal, the secondary collision can strike a spark. So for a bullet to strike a spark in an airplane tank, it would have to hit a structural support which is not strong enough to stop the bullet, and knock off a piece of steel which then strikes another structural support with enough force to strike a spark, and that sparking would have to occur inside a nearly-empty fuel tank.
It could happen, but it would take a series of unlikely events. Much, much more likely, a fuel tank would just be holed, and having fuel streaming out of the tank would create a problem when the plane tried to land.
I recently read a book about the history of Google, and based on what I read, I don't think there was ever a time they didn't know what to do with their algorithm.
There were a couple of years during which they weren't certain how to monetize it, though. Larry and Sergey completely rejected advertising for a long time, and it wasn't until they compromised by agreeing to do unobtrusive, relevant, text-only ads rather paid search placement (what most potential investors wanted them to do) or obnoxious banner ads (what nearly all Internet advertising of the day was). Even then the business model didn't really come together until they adopted a competitor's (I forget who) innovation of a real-time advertising auction. They added some refinements to the auction algorithm and then the money started rolling in.
Perhaps you've heard of this company called Google - started with a $25 million investment from Kleiner Perkins Caufield & Byers and Sequoia Capital.
No. Google had been around for years, and had a solid track record by the time VCs got interested. They did get angel funding of $100K earlier, but even that was after they had been up and running for over a year.
Not really relevant, but interesting, IMO: Google had an even earlier investor -- Stanford University. Their biggest early operating expense would have been their Internet connection, but they used Stanford's. They also used their university contacts to scrounge a lot of hardware, and put it all in Sergey's dorm room. Google search actually got big enough that it was straining Stanford's network and Stanford's IT department was already fielding complaints from businesses who were unhappy about their search rank placement when they finally got the $100K and used it to move off campus (and into a proper garage).
So...
1) You agree with me
2) Assuming the window shatters rather than just holing (I don't know what would happen; it depends on the type of glass, though I suspect it's tempered like auto glass and wouldn't shatter) then you'd get a larger hole which the pressure maintenance system couldn't keep up with. The plane would lose pressure over the course of a minute or two, the oxygen masks would drop and the plane would have to lose altitude and divert to a nearby airfield.
Not a good situation, but hardly horrific.
All undercover TSA agents and any armed pilots use ammunition specifically designed to not rupture the hull.
Nonsense. They carry regular jacketed hollowpoints, just like any other police officers, or civilians for that matter. A gunshot in a pressurized plane just pokes a small hole which the plane's normal pressure-maintenance systems can easily compensate for.
Why exactly do you think they would do this rather than simply sharing the info like he said?
Because privacy advocates will scream bloody murder about just sharing the lists. The only check on government action is the voice of the people, but if the people are loud enough, it can work.
They're the government and they can pretty much do whatever they want with the info once they get it because no one is going to limit them.
Which is exactly why it makes sense to employ a cryptographic protocol so they can find the e-Bay high-earning welfare recipients but cannot get any other information out of it. To use math to make it impossible for them to use the data in any way beyond the stated purpose. That still leaves open the question of whether or not allowing the data to be used for the stated purpose is a good idea (personally, I think you give up some privacy in exchange for welfare money, so I'm not opposed), but it at least closes off concerns about the government using the data for other things.
You can't just tell the government "sure you can completely undermine someone's privacy BUT ONLY FOR THIS ONE THING, OKAY?"
You can if you can ensure that they don't have the ability to undermine the privacy for other things.
A problem with your scheme is that it still gives too much information to whichever party gets the lists and does the comparisons.
e-Bay could take the list of welfare ID hashes and use it to identify all of their users who are on welfare, and then potentially misuse that data.
The government could take the list of e-Bay high-earner ID hashes and use it to identify all of its citizens who are e-Bay high earners, not just welfare recipients.
One solution is to have both give their lists to a third party, who would identify the intersection and return that to the government. But that gives the third party a list of ID hashes which could be used to identify people who are in either set (and which set(s) they're in). But if e-Bay and the government agree on a key and generated keyed hashes, the third party (who doesn't have the key) can only identify intersections, and cannot do its own hashing of personal data to match that to people.
As an added backstop against disclosure of the key to the third party, rather than building and sending a list, e-Bay could generate a Bloom filter of the keyed hashes, and deliver the filter data to the third party, who could then test each government-provided hash against the filter and return the list of positives. The false positive rate would need to be set low enough that a positive constitutes probable cause for a warrant, which could then be served to e-Bay to retrieve the person's information in the proper way.
It might even be possible to flip the sense of the test so that Bloom errors become false negatives rather than false positives. This would ensure that everyone who is matched is actually in the intersection of the two sets, while allowing some in the intersection to "get away". In fact, if this could be done (I need to think about it), you could actually set the false negative rate to be very high, which reveals even less information to the third party and to the government, but would still provide a sufficiently high probability of discovery (and prosecution) that welfare recipients would take care to properly disclose their e-Bay earnings.
If you can decrypt something that means there is a method to do so. You pass the message and one-time pad into this "function" and receive output.
Yes, but how do you know when the output is correct?
This is why an OTP provides perfect secrecy, if the key is secret. For a given ciphertext, there is some key that transforms it into every possible plaintext of the right length. This means that the result of brute force searching the keyspace for an n-bit ciphertext is every possible n-bit message. Thus, the only information you can get out of an OTP-encrypted message is the message length -- assuming it wasn't padded. With padding, the only information you can get is the maximum length.
The same problem actually occurs with "normal" ciphers and short messages. If I use AES to encrypt a one-bit message (perhaps padding the rest of the block with random bits), every possible AES key will result in an apparently-valid decryption -- the first bit will be either 0 or 1. But I have no way to tell which is right, even though I know that 2^128-1 of them are wrong. Claude Shannon defined the concept of the "unicity distance" to describe this, "unicity distance" being, basically, the length of the smallest amount of ciphertext which an attacker with infinite resources needs in order to determine the correct key, by examining resulting plaintexts. With an OTP, the unicity distance is infinite because as the message grows so dos the key, without bound.
Assuming the key is secret... which is the hard part with one-time pad protocols.
This particular therapist is in such high demand that she only accepts payment up front, directly from patients. My insurance will pay, but I have to handle claim submission and wading through the associated red tape.
Given that we haven't yet found any evidence of God's hand that would stand up to skeptical scrutiny, I posit that God does not want us to find scientific proof of His creation or intervention. There's even a clear and simple reason: presence of scientific proof would remove the requirement to first have faith before knowledge can be obtained. If God has a reason not to provide us with proof, we won't find proof. If God does not have such a reason, I think we'd have found something by now. Also, for theological reasons I believe that faith as a pre-requisite for knowledge is an essential, fundamental part of God's plan. Therefore, I expect that no compelling examples of irreducible complexity will be discovered.
The fact that hard work and talent often don't equal success on the first try doesn't mean they don't equal success. It just means that there's a large element of randomness in play at all times, and even hard work and talent don't necessarily give you high odds of success in any one endeavor. However, hard work and talent do tilt the odds in your favor, so -- except for people who get extraordinarily unlucky -- hard work, talent and persistence do equal success. On balance, I'd say that persistence is the most important of those traits, followed by hard work, with talent coming in a distant third. Which isn't to say talent isn't valuable -- in many cases it's essential. But it's almost never enough.
Well ok, Google has better offerings than a lowly local government offers. :) None of the HSA pitches I have seen made sense if you were already diagnosed with anything serious, that yours is still competitive with three major illnesses to cover out of pocket is not typical.
Perhaps. But note that IBM's plan was also competitive, primarily because the high-deductible premiums were substantially lower. I strongly encourage people to actually model their expected expenses in detail. I was surprised, and you might be as well.
You are failing to understand the products offered and have selected the wrong one. You want traditional 'insurance' if you have expensive preexisting conditions.
Not necessarily. My wife has chronic kidney disease. My boys have ADD/ADHD. My daughter has a mental illness that is very expensive. Yet every year I build a spreadsheet, work out the expected total costs for all of the options, and end up going with the high-deductible with HSA. At my current employer (Google), this is largely because the company contribution is so generous that it nearly covers the deductible, but even at my previous employer (IBM), the high deductible plan was more economical because the premiums were so much lower.
Yes, it's a little painful at the first of the year when I'm spending nearly $1K per month on medications (mostly for my daughter), but I just have to budget for it and make sure I have the cash reserves. By March I've met the deductible and am in 80/20 territory. Usually by fall I've met the out-of-pocket limit and insurance is paying 100%. One of the non-obvious benefits I've noticed is that on a traditional plan with fixed co-pays, the co-pays don't drop off when you hit the OOP limit, but with strict X% coverage.
So, I have an HSA and an FSA, spend them both dry every year, and it's still cheaper to take the high-deductible plan rather than the traditional offerings, at least the ones that have been available to me (and IBM's offerings were pretty good, and Google's are really excellent).
Actually, this year my model showed that a more traditional plan would save me about a thousand for the year, so that's what I did. But the reason was that the traditional plan happened to have better out-of-network coverage, since my daughter's therapist wasn't in the network and we didn't want to find another. That wasn't anything inherent in high-deductible vs traditional plans, though, just a quirk of the details of the two plans.
For goodness sake, life doesn't have to be a battle all the time
Which is why I don't use Windows. Your mileage has obviously varied, but I just find a *nix system more comfortable and easier to use. I hugely prefer the repository-based method of software distribution, and -- though I understand Windows has gotten good in this area -- much prefer the stability and reliability I get from Linux. That's the biggest reason I switched years ago.
These days, I use OS X and Linux, and both are very decent systems, though honestly the only reason I use OS X is that I prefer Apple hardware over the Lenovo Thinkpad and company policy won't allow me to install Linux on my company-issue MacBook Pro. As for fiddling to make hardware work... I haven't done that for nearly a decade, but I suppose that's largely because good Linux support is the #1 requirement for any piece of hardware I buy. In recent years it's gotten to where I really don't have to worry about it -- darned near everything works just fine on Linux -- but when it was harder I did the research I needed to, so I didn't have to spend time fiddling.
Anyway, my point is that while I'm sorry you've found Linux to be a struggle, don't assume that others use it only because they're "fanboys" or because they enjoy spending more time fiddling with their computers than using them. For many of us, Linux is less fiddly and more comfortable.
First, there is an Android/iPhone/BlackBerry authenticator app (software one-time pad) that you can and should use instead of SMS-sent confirmation code if you don't have a dumbphone.
Second, if you cannot use such an app: obviously SMS represents in no way a secure channel, but it still adds another unsecure channel a potential attacker has to identify then crack (although wiretapping SMS is peanut butter for NSA and friends, linking phone number to Google account might not always be trivial when using prepaid cards for example).
Another option is to pre-generate a list of codes, print them out and cross them off as you use them. When you get low, log in and generate and print another set.
We've apparently been talking about different things. I've been talking about the impact of the app, you've been talking about sales volumes and purchase considerations. :-)
I really don't see how it's useful when assessing the impact of an application, to consider whether the devices that app runs on run on a platform from a single vendor or one from multiple vendors. What matters is how many people use that platform, and therefore have access to that app. Apple is doing very well, but iOS is a minority platform, and the current trends (extrapolating current trends into the future is very risky, obviously) indicate that the iOS market share, as a percentage, has peaked and will continue declining from here. I very much doubt that concerns Apple -- they're quite happy to keep the most lucrative segment of a growing market.
But, if you really do want to consider a single vendor: Samsung by itself is significantly outselling Apple in the smartphone market, in terms of both units and revenue -- though Apple is making more money. http://www.guardian.co.uk/technology/2012/apr/27/samsung-apple-smartphone-sales-profit
But three squares isn't significantly different from two.
rat7307's comment is correct. iOS is a minority platform, and at the present sales rates it will stay that way. Apple's sales volumes are very nice for Apple, but they are not increasing at anything like the pace that would be needed for iOS to become anything more than a (large) minority platform. Even just on mobile, it's not clear that iOS is going to be anything other than a minority platform (it has already fallen behind Android in phones, and Android is making up ground in the tablet market, too).
Er... replace the "&&" with a semi-colon. I type too many chained commands with && and my fingers get ahead of my brain...
Your first idea will do exactly what you want. It'll resume interrupted uploads, verify upload integrity, be secure in whatever context you're in... it's perfect. As long as you don't specify the --delete option, it won't delete remote files just because local files are gone, either.
A crontab line with: "killall rsync && rsync -a ~/local/photo/dir hostname.foo.net:remote/photo/dir" will do the job admirably. Set it to run every 10 minutes or so. You could obviously polish this solution in various ways, but it's quick, it's easy and it will work.