First results from a good search for "project manager job description"

http://hrcouncil.ca/hr-toolkit...

What you described here fits the typical definition of a project manager.

So they had one person, a "manager", keep an eye on people, keep an eye on projects, allocate resources, and basically manage the group

The difference between a project manager and a manager is that a manager has direct reports and is responsible for dealing with all of the human resource issues (hiring, firing, training, reviews, etc.)

In the situation that you described, who took care of those tasks? The boss? The manager?

We call those people Project Managers. Someone has to keep the timelines, project plans, meeting minutes, and other assorted paper work together. You do not want to waste the time of the people actually doing the work by forcing them to make sure that their co-workers are on task.

In the case of my organization, they are trying to transition to recurring revenue streams by offering technology solutions with predictable, monthly fees. They are hoping to balance out the cyclical and sporadic revenue cycles inherent in traditional consulting engagements. The organizational structure has not yet adjusted to address the realities of employing a skilled technical workforce.

http://googleonlinesecurity.bl...

What bank is this? There's nothing wrong with public shaming in cases like this, in fact it does the world a service.

Also, you should seriously consider switching banks. Your post prompted me to check the banks I use. One is great, one is okay. I'll watch the okay one.

I also live in Ontario and did a calculation for that based on prices of Chinese lithium ion batteries at the time (6 months ago). Back of the napkins said it would be greater than 10 years to get a payback, but the prices are still dropping. I'd say this kind of stuff is going to happen soon. I recently installed a whole home power monitor for interest sake, and honestly for $3500 even if it paid itself back to break-even over the 10 year warranty period it would be an interesting project to take on. Still I imaging the switching equipment you need to install along with this is pretty serious cost, and I don't think this comes with a charger/inverter either.

Yes, it is, and the same holds everywhere. Being able to grab the data on the wire has long been an easy way to get sort of what you want to see, but it's almost never exactly what you're really looking for. HTTPS will force us to hook in elsewhere to debug, but the "elsewhere" will almost certainly be a better choice anyway.

I think you're confusing IIS and IE, but your comment actually still make some amount of sense :-)

Nonsense. The people running the OpenSSL project are competent and dedicated. OpenSSL's problem was lack of resources. It was a side project with occasional funding to implement specific new features, and the funders of new features weren't interested in paying extra to have their features properly integrated and tested. That's not a recipe for great success with something that really needs a full-time team.

Using a crappier measurement of inflation doesn't improve your argument.

Perhaps I wasn't clear. I wasn't referring to building of network connections, I was referring to the building of user services that rely on them. For example, YouTube is built to dynamically adjust video quality based on available bandwidth, but the range of bandwidths considered by the designers does not include hundreds of megabits, because far too few of the users have that capacity. They have to shoot for the range that most people have.

But as that range changes, services will change their designs to make use of it. We don't really have any idea how things will change if multi-gigabit connections become the norm, but you can be certain they will. Just as programs expand to fill all available memory, Internet services expand to fill all available bandwidth. To some extent that's because more capacity enables laziness on the part of engineers... but it also enables fundamentally different and more useful technologies.

Being able to choose an operating system (BSDs, Linux, commercial UNIXen, Windows, etc.) has been in your favor, particularly from a security perspective. And would you seriously argue that the existence of multiple BSDs has been a bad thing for their security? I'd argue exactly the opposite. The BSDs, have a well-deserved reputation for being more secure than Linux, and part of that reputation arose directly from the BSD forking. In particular, OpenBSD forked specifically to focus on security, and FreeBSD and NetBSD worked to keep up.

Yes, it does. You seem to think that being vulnerable none of the time is an alternative. It's not. The system as a whole is much more resilient if vulnerabilities affect only a subset.

Look how well that has worked for OpenSSL in the past. The many eyes principle only matters if people are looking, and competition creates attention. Also, it's a common error to assume that the software ecosystem is like a company with a fixed pool of staff that must be divided among the projects. It's not. More projects (open and closed source) opens up more opportunities for people to get involved, and creates competition among them.

Competition also often creates funding opportunities, which directly addresses what was OpenSSL's biggest problem. You can argue that it also divides funding, but again that only holds if you assume a fixed pool of funding, and that's not reality. Google is contributing to OpenSSL development and almost fully funding BoringSSL (not with cash, but with people). That isn't because Google's left hand doesn't know what its right is doing.

Huh? No, obviously, you choose a browser with a development team that stays on top of problems and updates quickly. It's almost certain that developers will choose their SSL library at least partly on the same basis, again favoring more work and more attention on the crucial lib.

It's not, it's really not. It would be nice if that were true. It's really more like a car that breaks down over time in various ways; some are more reliable than others, but all require ongoing attention and maintenance.

This is true in theory, but untrue in practice, because new attacks come along all the time and ongoing maintenance (non-security bugfixes, new features, etc.) introduce new opportunities for security bugs.

Your Apache and IIS counterexamples are actually support my argument. IIS, in particular, was riddled with problems. Yes they've been cleaned up, but you're talking about a space that has been static for almost two decades (though it will soon be destabilized with the introduction of HTTP/2 and probably QUIC) and is, frankly, a much simpler problem than that solved by OpenSSL... and I assert that without the competition of alternatives, IIS never would have been cleaned up as thoroughly as it is.