Nor is it clear that anyone other than some classes of users who are forced by law or employer dictate to use a trusted system actually would do so. No or very restricted email, social networking, etc.

This is the environment that I work in. We use a combination of Citrix and VMware 'non-persistent disks' to provide a locked down environment that reverts to a clean, known good configuration every time a new session is established. We have to maintain that kind of environment because we work with sensitive data.

I think that the fact that banks and merchants appear to be unable to secure their transaction flows ...

I am not sure that this is accurate. In two of the more recent major breaches (Target and Home Depot) it was acknowledged that the internal security controls and systems management strategies (patches, etc.) were inadequate. That leads me to believe that it is not that they are "unable" to secure their networks, but that they simply refused to do so.

Between hardware layer access controls (think MAC white listing), firewall controls and PKI technologies, it is possible to secure a network and the data that traverses it. All of those controls are worthless if the data is being held in a 15 year old SQL database that has not been patched in 3 years with an admin who is browsing porn from the console.

It is going to get to the point where the only viable solution is a trusted sandbox. It will be something along the lines of a TPM chip to make sure that the OS image / boot loader has not been compromised, combined with a white listed set of applications and trusted content sources.

People are either going to give up computing freedom for security, or they are going to become desensitized to and accepting of the fact that their "private / personal data" is neither.

Right now I do not have a well formed goal in mind. My initial goal was to relieve the sciatic nerve pain. Then it was to learn kung fu. I have pretty much plateaued and am trying to get over the hump, but lack the motivation or goal to do so. Right now I am on auto-pilot, just training seven to eight hours a week and working to refine the techniques and skills that I have. Teaching a few classes a week helps too because I enjoy helping others, but I am definitely stuck in a rut with my own training.

Mine still flairs up from time to time, but only when I slack off and stop exercising. It is definitely manageable.

I tried the whole "rest and pain killers" routine and that just made it worse. I am fully convinced that the only way to deal with sciatic nerve pain is with exercise / stretching.

This is spot on and should be modded up.

Enter personal anecdote...

About fifteen years ago I was starting to struggle with sciatic nerve pain due to years spent driving a car with a heavy racing clutch in traffic, and a lack of exercise. I considered my options and decided to start practicing tai chi. I caught a bit of a break and found a legitimate sifu. After a couple years of tai chi, I started training kung fu as well. It has been over a decade and I train on a daily basis. I can eat whatever I want because I burn it off.

None the less, it is a struggle. Despite all of the benefits, there are plenty of days when I would rather go home after work and play video games instead of heading over to the temple to train or teach classes. I still have not overcome the "exercise sucks" mentality. Sure, the endorphins are great and being able to defend myself is great, and have a strong and healthy body is great... but it is still work for me, not fun.

The question was specifically how to deal with people who only offer criticism and do not contribute anything themselves.

Criticism is a part of development or any creative effort. Development is an iterative process and requires feedback and input from lots of people.

However the person who should leave the team is the person who does not have anything to offer. If someone's only "contribution" is to suggest how other people "should" be doing the work, that person is not really contributing.

There is an old Chinese saying that is tangentially related here. "The person who says it cannot be done should not bother the person who is doing it." Similarly, the person who says it should be done another way should either demonstrate that by doing it themselves, or STFU and leave the team alone.

Open Source is developed by and large by volunteers. While critical individuals are able to offer their criticisms, the people are doing the actual work are equally able to ignore them. Either a person is contributing code, contributing to the effort through things like documentation, wiki support, what ever... or a person is just a hanger on leeching off of the efforts of others. If that person is the worst kind of hanger on; the topping from the bottom, back seat driving, wanting to be in control but lacking the talent to do things themselves type of hanger on... well then fuck them.

If a person is living an area of the world that lacks the bandwidth to view online videos, are they really the kind of person who will be accessing content about how to build and deploy multi-tier applications into a IaaS stack?

Thank you for the laugh.

While this might not be the most subtle way of handling things, it could be quite effective to repeat the same question every time they are critical. "What have you contributed?"

Just ignore their arguments and ask them what they have contributed. Over and over and over again.

They will either go away, stop posting so much, contribute, or perhaps realize that the whole point of the movement is to contribute actual code and functionality.

On the Internet, ignore them. In real life, talk about them every time they open their mouth and complain. "Oh there goes Joe again, whining and NOT CONTRIBUTING." Then return to your regularly scheduled activities of doing things.

How do you deal with things like re-tests and conflicting priorities for remediation? For example, client wants vulnerabilities patched in one week but the next maintenance window is for two weeks.

We are in the same situation and we have data centers spread around the globe to deal with data privacy and jurisdictional considerations.

I could have made that more clear. We license Rapid7 and use their tools to conduct internal tests of the systems on a bi-weekly basis.

I am curious about this as well. What are the potential risks of maintaining focus on a point a few inches away from the eye for hours upon hours?

I work for an organization that hosts PII for a number of large public companies. We are constantly asked about vulnerability scans and about 50% of the clients want to scan our networks themselves. We do not allow that.

The compromise is that we conduct bi-weekly scans with Rapid7, and hire from a rotating list of third parties to conduct yearly vulnerability assessments of our applications and infrastructure. We make the high level results of those scans (number of vulnerabilities found) available to the clients. We also have to put up with the occasional fire drill like Heartbleed. During those situations, we deploy the patches as soon as we can test them, and then provide letters of attestation to any client who wants / needs one.

While some clients complain, they eventually come around when we explain to them that it is for their own safety and the protection of their information. We are in a situation where we retain data for companies who are in direct competition with each other. When push comes to shove, we sometimes have to explain that, "Just like we will not let you scan our network for vulnerability, we will also not allow your direct competitor to scan our networks either."

I have found that the best middle ground is to work with the developers and project team to set deadlines and project milestones. While down to the tenth of an hour estimates are not necessary, there have to be goals to hit.

The best managers are going to let the developers provide their own estimates, and then calibrate the timelines accordingly. Some people are good at estimating time. Others are horrible at it. The project manager needs to know their team well enough to account for those factors.

The of thumb that I have always worked with is double the estimated time. Under promise and over deliver. This does lead to some grumbling up front, "It is going to take HOW long?!" But after successfully delivering ahead of time, enough times in a row, people come around.

The biggest challenge is keeping people honest. Some people have a hard time admitting that they are not going to make a deadline. It is important to give those people room to fail, so long as they are responsible about it. "This deadline has some flexibility, as long as you give me 48 hours notice that you are going to miss it. Don't come into my office the day I am expecting a deliverable and tell me that you need another week."

The other side of that is having to be a good manager, and push back on the business team to give the developers room to work. "We told you we would deliver it by X and we are still on track to deliver it by X. STFU you about your cranky client whose expectations you cannot manage despite us being explicitly clear with you about what our timelines are. And no, we are not going to add that extra feature that you promised them but failed to include in the scope."