Don't know which "christians" you know...but that's certainly not true.

Devil's Advocate: Much of evolution, especially around the "origin of species" is completely untestable and 100% reliant on having "faith" in science.

So aside from the performance hit you take by adding all those applications, you've also increased the footprint of security issues as each of those have issues regarding security that you must now also monitor, not to mention the backdoors that can be taken advantage of.

The open source ClamAV is listed among the best products for detecting viruses last I checked it was one of the top three; McAfee hasn't been on that list in ages. That said, the APIs and drivers they insert into the kernel to work (and interface between kernel and userland) essentially provide big back doors that malicious actors can (and do) take advantage of.

ClamAV for a long-time was a user-space only product - e.g no real-time scanning of the OS, applications, memory - as it was originally (and still is primarily) intended for use by servers to scan traffic going to other systems, namely to desktop Windows users. (Most prominent use is in mail servers.) Recently it's started getting real-time scanning capabilities, enabling it to compete with others on Windows where users still think they need an AV product. ClamAV (and ClamWin) are still probably the best in that respect as they probably have the fewest backdoors of any AV product.

And honestly, I don't advocate to anyone to use an AV or malware preventative product any more, even on Windows, namely because of the issues they introduce. Instead, I advocate the users be more careful with what they do. It's proven quite effective.

AV software may be a layer of security; but it often adds more security holes than it closes. Overall, AV software generally is more of a placebo than anything else. You can actually solve the issue better by being more security aware and careful to start with.

Depends on the security incident. Not every security incident will necessarily effect everyone in the company, but many can. It's just matter of which one hits the company first.

And honestly, the security incidents that do effect the whole company only greater for knowledge oriented companies.

In the end, Security Experts have to look at everything as necessarily effecting the whole company because any little security issue could potentially become a bigger security issue - a cascading effect. For instance, a malware that exported data (f.e username/password) via LED flashes to a camera that had view of the LED could provide an outsider access they wouldn't have had otherwise; get the right information that way and an attacker could compromise the whole company.

Considering systemd is developed by non-experts...

If it were really that bad, then they'd require it of all ages. They don't. Further, the vaccine itself is problematic.

And as I said, the issue is not whether you have any given strain of HPV - the body usually fights it off just fine; it's when you have multiple strains at the same time.

And you can control your own behaviour (it's called self-control, which I know recent generations are abhorrent to do, especially when it comes to sex) - you can control how much sexual contact you have (aside from rape and molestation), and you can control how much you wash, etc; all things that provide protection without getting vaccinated.

This has nothing to do with OpenSSL other than that OpenSSH uses OpenSSL. This is a bug in OpenSSH itself.

Actually, it is a lifestyle as in you choose what you do; HPV is listed as an STD, and really only becomes an issue when two or more incompatible strains interact - meaning, multiple partners within relatively short periods, again - a lifestyle choice.

Depends on the vaccine. For Polio/Measles/etc, I certainly agree.
For life-style vaccines (e.g HPV) I don't agree.

No quite. Google+ was around as "invite only" before they did that.

Funny...I'm not a Google employee and I know I have a G+ account - I specifically created it. I much prefer G+ to Facebook, etc and spend more time on G+ than any other social network.

Now, don't mistake this for Google fan-dom, I rarely touch my gmail account; and rarely comment on anything in YouTube. My main uses of Google are G+, Calendar, Hangouts (chat), and Search.

Next up: Keyboard LED TCP

Seriously, any kind of output can be controlled to perform some kind of protocol, even the numlock/scrolllock/caplock LEDs on the keyboard. For instance, malware could be configured to use Morris Code to output usernames and passwords it finds on the computer for a camera to pick up. Industrial espionage could be done by having a spy camera hidden, with embedded malware used to push information out the LEDs off-hours when people are not watching; the intervals could be fast enough to look like a steady light unless you review the camera and see the frame on, frame off sequencing.

So yes, it could be used as an output device, even though it's intended use is only as an indicator. To prevent this, you'd have to prevent the computer from being able to push key codes to a keyboard, but then multiple keyboards (virtual/physical/etc) would get out-of-sync.

Public Key doesn't really get you much. Theoretically it means you're using a Certificate Authority (CA) to validate both sides; however, a centralized CA is still vulnerable and problematic. A Web-of-Trust system is harder to manage but can be more secure. In both cases everyone has to implement best practices and keep good key sets, which is often not the case.

With PGP/GPG people tend to keep relatively short life-spans on their keys, even then that can be between 1 and 5 years. Still, this is better than CA systems where people tend to make 5-10 year keys, often long enough now that the algorithms are being broken before the keys are replaced, and most don't use Certificate Revocation Lists (CRLs) as well because they're too painful to maintain, and essentially reduces a CA system back to a Web-of-Trust system in that respect.

There are already world-class random number generators (RNGs)...but they're costly. So we have pseudo-random number generators (PRNGs) to try to keep the costs down. Of course, RNGs are primarily expensive due to patents and companies trying to keep it to themselves instead of fully sharing the tech. But you've got to get companies to share the data more and at cheaper prices if you want to improve RNGs and PRNGs.

Now this is just false. Trusted Hardware - e.g systems booted with SecureBoot/Palladium/TrustedComputing/etc - don't really buy you anything other than locking down everything to the few "trusted" vendors that get to decide what software runs and which doesn't. As the leading push for this tech is Microsoft, which has one of the worst security records, I wouldn't count on it being used for anything other than vendor lock-in.

So TFA's assertion here is that Operating Systems, and more specifically their File Systems, don't do enough to keep data on disk from being pieced together by a bad actor. Sorry, but that's not a very good solution since they already have access to the system, either physically or on-line. If they have on-line access then it doesn't matter - the OS will help them get the data; if they have it physically, well, disk encryption is a better solution (though painful and costly in performance).

TFA's argument - everyone should be like BitCoin.

Well, this could help communications some...but that's kind of already happening with encrypted communications, just not the way BitCoin does it. Still, that could make an interesting prospect, but that doesn't mean it's necessarily more secure. For instance, a MITM attack could still fool you since it would be able to talk to the other parties and make them both think the chain was intact properly; the attack surface would be reduced since the MITM attack would have to happen at the start of the connection; but then, any good MITM attack does that.

So all this really tells you is that the information send between two parties is a continuous flow of information; however, it has the issue that is completely serializes all communications (in order to create and preserve the chain) and that doesn't work for every protocol.

This is the basic idea behind key-sharing systems. Whether web-of-trust (PGP/GPG) or CA systems. In both cases you have to exchange information with a third (trusted) party to verify the information. It can help some, but it's no silver bullet by any long shot. See above for details.

More encryption. Yes, encryption can help, but it doesn't solve MITM attacks that use the encryption to their advantage - e.g by joining into the encryption stream. Yes, it makes MITM harder, but it doesn't prevent it.

That said, encryption is good; but it also means you need more powerful systems to meet the same performance requirements because encryption - and especially good encryption - is costly in terms of performance.

All that said, there is a better solution to any of the above - better programming practices that are designed around security. However, this requires retraining pretty much every software developer, the majority of which will complain that it takes away their ability to be artistic and thereby refuse to follow said practices. It also requires software producers (individuals and companies alike) to put security first in all software; but that too is unlikely to happen.

In programming, Security doesn't start with interfacing to other systems - it starts with making each individual function as secure as it can be; preferably not trusting anything more than it absolutely has to, validating all input and generating an error when the input is not within the specifications.