My intent was to refer to the fact that people tend to fall into the middle ground between the extremes. I believe the statisticians would call this a bell curve, etc. But for a non-technical post I just went with the adjective "average" because most native English speakers understand that definition (and it was the first to my mind). Hopefully that makes it easier for the mathematicians to read the post. I know how frustrating it can be to read a post with technical inaccuracies.
This combines with the most common failure of unfettered democracy, the tyranny of the loud (and perhaps underemployed/bored/obsessed), to create a perfect storm of vitriol, ignorance, and selfishness in places like an open forum online.
Quite simply, people without knowledge or experience in a field deserve less speaking time than those with knowledge and experience. If those people that are excluded from a discussion because they are ignorant or inexperienced want to participate than they should take the time to become knowledgeable and experienced in the field.
I always like to see open discussions but I also like to see comments rated and organized so that I can sift through the crap to get to the gold, something that guyminuslife mentions is missing from the Post's website system.
And to speak directly to a comment from the original article, the fact that the comments show the true feelings of the citizens of this country is interesting from a polling/election point of view but the details of those comments don't add much, if anything to the discussion at hand. This is especially true of indefensible positions like racist or sexist comments.
I'd also agree that a generic CS degree is more valuable than a technically specific degree. Concepts matter.
And as for coding 9-5, of wearing a suit as an MBA, those aren't hard coded into the different careers. You can setup a work environment that fits your style if you figure out what that style is and work towards it over time. I know plenty of programmers that have figured out how to balance coding with design and architecture work, and plenty of MBAs that never wear a suit (such as me.)
Look at your work environment just like any other task/goal, layout objectives, figure out what moves you toward those objectives, and execute those actions. It may take time but you'll almost certainly get there because no one is really working against you, it's just inertia that keeps most people from finding a good working environment, imo.
Lastly, keep coming back to focusing on your relationship with your peers. You should use that as a metric to determine the quality of your professional life. If you respect and enjoy working with your peers (even if you don't agree with them) than you're in a good spot. If not, starting moving elsewhere. We are defined in part by the people we choose to associate with, in addition to our actions.
The real focus needs to be determined. Is the question whether open source software development methodology is inherently vulnerable? Or is the question whether open source project X is more vulnerable than proprietary project Y?
I'll address my thoughts on the open source methodology, and the argument I use in these discussions.
Software security is reliant on a couple of key factors. Obscurity is the first one most people think of, and despite the prevailing feeling, obscurity is an excellent security control that protects against certain types of attacks. However, reliance on obscurity for security is not a good idea because over time most secrets are disclosed.
Good security architecture relies on robust security controls that maintain integrity even when attackers are fully aware of the mechanism's internal working. Perhaps it helps to think of it this way, imagine two people walking down the street. One is alone and vulnerable but in disguise and very hard to recognize. He's relying on obscurity for security, and it will probably work. The other person is surrounded by bodyguards and the entire region for miles around is swarming with more guards and surveillance teams. He's relying on a robust security control (really controls) and it doesn't matter if attackers no the details, they still aren't going to have an easy time getting through to him.
So open source projects are no insecure because they are open, and in fact many would argue that their very openness provides insurance against stupid decisions to use weak security controls and protect them only through obscurity (a classic move of proprietary systems, just think of the old MS password hashing scheme, or a dozen other proprietary security controls that turned out to be too weak to withstand public scrutiny).
The vulnerability numbers bear out this basic concept with more vulnerabilities relating to Windows systems than to *nix systems despite *nix systems running many more critical systems. I'd have to say that this is in large part because the underlying security controls of *nix systems are dissected by obsessive compulsive geeks, like us.
To convince your boss that FOSS is OK, do some research on vulnerabilities reported in the NVD. A (very) informal check shows about 1200 vulnerabilities tied to Linux and 1400 tied to Microsoft. I'd suggest doing more, and better, research than that before sitting down with the CEO to discuss this but the numbers seem to be on your side.
I'll end by saying that FOSS products are not always secure, and the open source development methodology is not inherently secure if the development community is too small to provide competent, and unbiased, security reviews of the software. A very large project, like Apache or Ubunut, is likely to fair well when compared directly to IIS and Windows. A smaller open source project, like a contributed module to Drupal, may be riddled with problems simply because not very many people took the time to look at it before deployment. That is one advantage of a commercial company, they (should) have a good QC/QA program to make sure bad products don't get shipped (they get sold to Microsoft who can ship crap with impunity
Anyways, it should be an easy argument with NVD numbers to back you up and the concept that security through strong algorithms and good architecture is more important than security through obscurity.
For my piece, I'd suggest the following additions/modifications:
- Use live USB keys to setup customized learning environments for certain classes, like the sciences
- Use the most basic hardware possible with a Linux environment, and consider all hardware throwaway...make no real attempts to maintain hardware
- Assign hardware to students because they'll take better care of something they "own" for the year
- Prohibit Internet access during class periods (a simple Squid proxy solution should handle this nicely)
- Establish an in-school chat/forum infrastructure to cultivate the school's community feel
- Make sure IT services are readily available between classes, lunches, and before and after school
I'm sure I could come up with lots more but I'd say the key is easy maintenance (live USB is awesome for that), throwaway hardware (no way you'll make even the best stuff last too long anyways), no Internet during classes (classes are for learning how to learn, not actually researching stuff), foster a good atmosphere (this is where the kids "work" so it should be as nice as possible).
I'd also strongly suggest letting the kids take laptops home if at all possible. The more time these kids spend on the computer the more likely they are to be able to use one as an effective tool later in life. Obviously they shouldn't be on it all day like a Slashdoter would be...but you get my drift.
About the multisite issue, I've struggled with using a single Drupal instance for this because of SSL limitations within Apache. My understanding is that a single IP is associated with a single certificate, so a multisite install could only have one SSL-enabled site. Let me know if this is incorrect or if you know of a workaround. Updating the sites with a script is certainly possible, and actually the only way I know of to handle it once you get beyond two or three sites, but requiring extra scripts to do an update is a major deficiency. Check out the Wordpress update feature for an example the way I think Drupal should go.
The security mailing list is excellent and I'd strongly agree that anyone managing a Drupal install should subscribe.
I'll check out the devel's moduel. I haven't heard of that yet.
As for update.php, the actual page states this "Drupal database update...Use this utility to update your database whenever a new release of Drupal or a module is installed." So I always run it when I install a module. This makes sense to me because the update.php script is the mechanism that updates the database structure, I believe, and there's no other way for a module's changes to be inserted into the database...again if I'm wrong please let me know.