yes and no. Javascript in the browser sort-of reminds me of a microkernel. Competing methods and implementations is a good thing. Having things that we think are fundamental be replacable gives us some freedom. Native implementations, from a performance perspective ... yes. Declaring "this is the reference for pattern X", not a big fan of that idea.
As somebody who would be classed as a "wantrepreneur", I really hate the term and its negative slant. For a community of people who celebrate the pathological need to "do it for yourself" we tend to look down on people who are learning how it is done. All the books in the world don't give you the character to succeed and the process of self-discovery and learning about yourself is hard. IMVHO, classification of our disorder on a scale of current success isn't productive. It seems to me to be a byproduct of the culture pushed by commentators who are making a living off being critical in the startup world rather than a term coming from those giving it a go.
Crypto is complicated and very hard to do well. Hell, any complex software is hard to do well. There will always, always be bugs. While I am pissed off with so much moaning, and do agree they should be better funded, I think it is more the case of sensationalist blogging taking control of the narrative. Rather than "Booo OpenSSL" we should focus on recovering and raising awareness of the projects we all rely on every day.
> Crypto is complicated and very hard to do well. Hell, any complex software is hard to do well. There will always, always be bugs.
There will always be bugs, sure, but differences in the engineering approach can result in orders-of-magnitude differences in the frequency of bugs.
For example, see "Some thoughts on security after ten years of qmail 1.0," where the qmail author explained why he thought qmail had a dramatically different security track record than sendmail: http://cr.yp.to/qmail/qmailsec-20071101.pdf
The kind of things he's talking about can't just happen on the level of "more people submitting patches" and "more financial contributions." You need a top-down approach that's designed to produce secure code.
One large company I know has a technical review system which we use frequently to root cause failure and more importantly to update systems and workflows that will avoid the cockup being discussed in future. Blaming a team or oneself is not entertained (we don't care about the who), the important question is why and what can we do to fix it.
In my opinion, I think the OpenSSL team should come up with such a document and a list of corrective countermeasures.
Fastmail. Just switched from gmail to them, could not be happier so far. Free trial period too. They are Australian, with some servers in the US and elsewhere. You might be hard pressed to find jurisdictions that don't cooperate with the US without heading to the .ru side of things.
Might be a bit like Google Play where it becomes a super-package on any Android OS, integrating apps with the API and while giving the apps functionality also feeds Google with data.
Problem is ... I suspect that the Wearables SDK will be another case of Google launching proprietary libraries on Android. I have no problem with proprietary, but a lot of people think that because it's Android, it is open. It isn't. Core Android gets slimmer, Google's tie-in to your business gets fatter (unless you re-write their APIs). As an example, developers followed the location APIs in to the Play SDK ... switching from an open, core API to the Play API without fuss. It's creep if you ask me.
While true, Google has made a big mention of pointing out that everything in the Play SDK leverages their cloud, and that they make all the APIs that can't inside of AOSP.
You can still geolocate inside AOSP, it just isn't as efficient as getting the location Google already has for the user in their cloud.
Stuff like the new Printer APIs and the new Storage APIs are solid evidence that Google isn't closing up Android. Only opening it further and making it more useful for everyone.
Developers followed location APIs to Play SDK because it was more efficient. Better for battery, and faster. Who wouldn't make that switch?
I agree with you, I made the switch myself. My point is that rather than enhancing the Android core, many of these closed APIs seem locked down soley to give Google more data, ie when that key API has the potential to be a data broker.
But since it's their internal infrastructure they can't not lock it down. Anything that is cloud-based has to be locked down. If at all possible, APIs for interacting with cloud-based services should be put into AOSP.
