Today, Amazon revealed the Fire Phone , its new Amazon branded phone. The device sports a quad-core 2.2GHz processor, 2GB of RAM, 32GB or 64GB storage, and a 13MP back-facing camera. Although the 4.7 inch screen is not actually 3D, a matrix of four front-facing cameras track your movements to alter your prospective.

What makes this an Amazon phone and not just another Android phone? Well, for starters, there is a dedicated hardware button to launch Firefly - Amazon's version of Eden-of-the-East - that can snap a picture and identify nearly any product and then link to the Amazon page. In short, it makes it really easy to buy things on Amazon. Also, Amazon is offering unlimited photo storage in the cloud. Together with Amazon Prime's new streaming video and music features, they seem to be really pushing the "Everything to the cloud!" approach.

The question arose out of the urgency of the heartbleed OpenSSL bug and the hurried round of patching that ensued: what is the future of opensource security management, and what can we learn from this crisis?

Shrikanth RP, executive editor for Times India writes:

A recent report by Coverity found out that the quality of open source surpassed proprietary projects with a defect density of 0.59 per thousand lines of code for open source compared to 0.72 for proprietary code scanned. Defect density (defects per 1,000 lines of software code) is a commonly used measurement for software quality. The report mentions that nearly 50,000 defects were fixed in 2013 alone - the largest single number of defects fixed in a single year. More than 11,000 of these defects were fixed by the four largest projects in the service: NetBSD, FreeBSD, LibreOffice and Linux. So, what do these statistics mean for open source security, and how must organizations look at open source security post Heartbleed?

Better peer review, more atomic code commits and checks, periodic, 3rd party audits: what should we be doing to improve the quality of our code?

Lennart is at it again, this time changing how /etc and /var are populated in a systemd system. In Linux, remember, system-wide configuration data (computer name, startup scripts, and such) are stored under the /etc directory, while all variable state data (caches, mail spools, and such) are stored under the /var directory. Both of these directories have traditionally been preserved across reboots.

With these changes one can perform a "factory reset" by simply removing these two directories and letting the system reconfigure itself with defaults or by dynamic means, such as DHCP. This idea isn't exactly new, as UNIX admins have been doing similar feats for network booting, live disks , and security conscious systems for many years. Still, though, by building it into systemd, wiping the installation to a clean state and maintaining a "stateless" system by default could get a lot easier in future distributions.