What about the people who live nearby as well?

And I always had a hell of a time getting that little kink out...

There is no such thing as "effectively infinite". What you are alluding to is the fact the the number of vulnerabilities is not known until they are all found, and thus you can never be sure how many more there are. Even in a situation where a product is evolving and new bugs are being introduced, at any given point in time there are a finite number of vulnerabilities. There certainly are not trillions of vulnerabilities undiscovered in in Apache. Nothing that would ever approach infinity such that you can say fixing a vulnerability doesn't decrease the number of remaining vulnerabilities.

As each vulnerability is discovered and patched, the effort to find the next one should increase slightly, given that methods which either analyze the code, or make brute force attempts to compromise the system(by brute force I mean, "oh let's try passing ";delete userstables" in this field to see if there is SQL injection, no, how about this field?) will have to search longer before finding a vulnerability, since there are now fewer. Each fixed vulnerability reduces the set of vulnerabilities, regardless if they are known, and thus increases the cost to find the next one. Additionally, it is more likely that researchers will find the more easy to find vulnerabilities, while some may be more elusive. This compounds the increase in cost-to-find.

What you should be more concerned about, is when you have found and fixed all of the easier to find vulnerabilities, what of the small number of finite remaining vulnerabilities? If researchers search and do not find them within a practical time frame that makes the $1,000 prize worth it, then they will not be found. But the blackmarket or other agency might find such a vulnerability to be very valuable, and throw more resources at finding one. Now such a fact doesn't mean the prize program was useless, as it certainly reduced the surface area of vulnerability.

Agreed. Lots of random reads when launching apps for example, or booting up. Just compare boot times. The difference is huge.

Right, certainly if it is CPU bound like rendering is, and not read/write intensive then it doesn't matter very much what kind of drive you have.

I was thinking in terms of sequential reads vs random reads where seek latency has more of an impact.

From the perspective of the rest of the network, the architecture of the router is pretty irrelevant, but I understand why they might want ARM but they didn't identify those reasons. I have a feeling their desire for ARM is not a direct requirement, but an indirect requirement from a desire for some of the attributes of ARM. They might find that an Intel Atom box meets the same needs. Low profile, low heat, cheap, passive heat sinks(eliminates risk of fan failure).

I went with PFSense + Intel Atom box and am happy. The web interface is pretty straightforward. Getting setup initially is a bit of a pain, attaching SSD/Card to one box and flashing, etc. Some of the documentation is terrible.

Agreed that certain scenarios are indeed poorly documented and/or pain to setup. Not that pfsense supports those scenarios poorly, but you just have to dig into command line/config editing and really have to know what you are doing.

SSDs are built off silicon chip manufacturing processes, and thus the pricing reflects that. If you look at chips such as RAM with similar feature size (e.g. 28nm) and how many chips go into an SSD, I speculate that you'd see the pricing is not that far off if comparing chips of similar feature density and size as they'd reflect the same manufacturing costs. Maybe higher for SSD, as it is a newer technology than RAM which has been around for a very long time and perhaps benefits from some efficiency of scale or other manufacturing optimizations that have developed over time.

Indeed, and even then for many usage patterns, latency will be much worse for the HDD RAID array, because certain operations will be the greatest latency of all the drives(i.e. if you read something striped across all the drives, and one of the drives has a longer latency in seeking to that data). So in many cases the average latency is skewed for the worst.

That doesn't even go into power/cooling savings. SSD's use 10th of the power, which is great for a laptop.

Risk of damage from bumping/moving the drive/laptop during operation is non-existant with SSD as well.

"to other viruses" should have read "to other generations"

It's an immune system response that viruses leverage to spread. If you could create a similar virus that didn't cause an immune system response, its transmition rates would probably be lower. I would argue that just as the pathogen in the article has evolved to evoke a certain response in the article, cold/flu have probably evolved to maximize the immune system response(short of killing the host) as such variations of the virus would transmit more readily and pass that evolutionary trait to other viruses.

Regardless, how is any of that a counter argument to the application of zombie terminology? Is it dead? No, then not a zombie. It's a vogue term and it's silly for a study to use the term. Modified behavior != zombie.

The cold/flu causes us to produce additional muccus/sneeze/cough, altering our behavior which increases transmission rates. This doesn't mean we are zombies. I think it's a very interesting find, but a little ridiculous to involve the term zombie.

I agree with the essence of the statement, but it's written in terms of childish absolutes such as "nobody" that obviously isn't true. Maybe if he had said "The majority of .NET developers aren't doing metro. When you expand support for this feature, then it'll be interesting to the rest of us." But some people live in a world that revolves around them and cry when they get left out. I hope this feature comes to the rest of the .NET platform, but I'm not going to cry about it.

Cloud is good for reliability, scalability, and if your particular scenario meets certain criteria, sometimes cost. Overall the cloud would be usually be more expensive, but can be cheaper to use cloud and only pay for what you need if you have short periods of high load combined with long periods of little load. Thus cloud might be cheaper because rather than paying for, cooling, powering, and maintaining alot of high end servers waiting to handle a large load only occasionally, you pay for what you need with the cloud. I would speculate you wouldn't see such savings on a single server.

If you could find a development/CI hosting platform that meets your needs, that would probably be a better bet. Such a service might be using cloud behind the scenes, but they benefit from the efficiencies of scale.

Another option is a semi-dedicate VPS. There are some VPS services that give you root access and terms would allow you to use the box as you do now.

I think someone went into this with the assumption that costs would go down using cloud, but your management time is going to be the same or more. You don't have a physical box, but now you will spend more time figuring out the nuances of your cloud host.

The key is to seperate the goal from the premature jump to cloud:
-If the goal is to get rid of the physical box, then VPS is an option.
-If the goal is to get rid of the physical box and lower management time/costs, then a hosted development/build/integration service is a good option. That way you don't even have to manage the OS, updates to the software/services, or perform backups.

Right-ism that "attracts low-information voters with buzzwords and sounds bites like" socialism and "destroying America".

Still have my same insurance BTW.

What version of Minecraft does it support? The answer to that question does change something.