Note: Here's another guest post from our friends at Black Duck, specifically Phil Marshall. Phil brings over 10 years’ experience in both product and services marketing as well as over a decade of experience in the high-tech publishing space with publications including Dr. Dobb’s Journal and Byte magazine. Prior to joining Black Duck, Phil was Director of Global Solutions Marketing at Ness Software Product Labs, a division of Ness Technologies. Before Ness Technologies, Phil held product marketing positions at both RSA and Sun Microsystems and was Director of Marketing at Compliance Engineering, a healthcare focused Systems Integration firm.
Lasse Andresen, CTO of ForgeRock recently wrote an article for SC Magazine in which he makes a great case for the relative security of open source software. That same month, Lucian Constantin, a writer for IDG News Service, published an article in PC World in which he describes vulnerabilities found and reported in seven popular open-source projects, indicating that there’s plenty of room for improvement when it comes to the security of open source projects. Can they both be right?
I’d argue that yes, they are both right. But to reconcile these assertions, we need to take a closer look at each perspective.
Lasse, to support his argument that open source software is more secure, lists four key observations regarding the use of open source. For enterprise users of open source, the takeaways are:
Mid-January and we’re pushing out a bunch of updates and improvements to our various stacks, with plans for a new Gentoo stack and Ubuntu stacks getting close to GA release. It’s a distro party!
--Tasha Drew, Product Manager
We’ve pushed out updates to PostgreSQL 9.2 & 9.3 to address corruption and VACUUM bugs, updates to PHP to address CVE-2013-6420, Upgrades installed version of check_postgres.pl for proper support of newer PostgreSQL versions, Tuned sysctl for better performance under load, Fixes missing maintenance page for PHP apps, and more!
Check out the release notes for our regularly scheduled stack updates and associated docs!
Social Calendar (Come say hi!)
Software is like fruit. It tastes great when it's fresh, but goes bad very quickly. In fact, it is ridiculous how quickly software rots.
How many times have you written a piece of software which works perfectly fine for months, only for it to mysteriously break one day? The reasons can be even more confounding. Perhaps a dependency was updated, and now you need to rewrite half your code. Or perhaps an API was changed in some irritating way which requires you to completely re-architect your code. More often than not, however, it is something obscure, like an environment default that was changed by something your package manager installed. I don't know about you, but in some instances the bug will be in a bit of code that I didn't even change, and after I fix it, I am left wondering how it ever worked in the first place!
At Engine Yard, providing high end technical support is a critical (and wildly popular) part of our platform, and flows into the attitude of the entire company. We are dedicated to improving Support and providing an awesome experience every step of the way. All of our customers automatically receive standard support with our platform, meaning our worldwide team of support engineers are on hand to answer your questions and give technical aid during business hours. For production applications where uptime is critical, we offer 24x7 support plans and more. Read all about what you receive with your Engine Yard platform and Support!
--Tasha Drew, Product Manager
CoderDojo is a Meetup group for kids to learn to code. They bring their ideas and adult developers help usher them along the way to teach them how to develop and to reach the goals they set for themselves.
At the Buffalo chapter of CoderDojo, we often have side projects to expose the students to other aspects of programming. At the most recent meeting, we brought Parrot AR Drones and allowed the kids an opportunity to manipulate scripts in an attempt to make a drone takeoff, move to a landing space.
This experiment involved a few factors outside of the code, like trying to measure how far the landing zone was from the takeoff site, calculating for any obstacles (including human traffic) and how outside influences, like a vent in the travel lane, would affect landing. The kids attacked the problem with a ferocious logic and soon appointed jobs. Each got a chance to change the code after making their observations.
We began with the following sample Cylon.js script, using Node.js as our motivator: