zmguy

I don't think it is something to fear if it is true. It's just a trend that is talked about. I don't personally care what demographics make up the future population.

While I do want defragmentation of technical and scientific research (imagine the duplication that occurs given that lack of a unified scientific research dependency tree), I specifically qualified myself with "...as a second language." A world where everyone speaks one language would be boring as fuck, not to mention probably a dozen generations in the future before it would happen. But realistically the future global language of Earth is probably going to be Arabic, Arabic speakers are reproducing at a rate that virtually guarantees it. I can't remember to attribute this quote/sentiment accurately but here it goes... "The war against the West will not be won on a battlefield but in the wombs of our mothers..." I also can't speak to the accuracy of the claims in the following link, but they are thought provoking and worth a watch/read. http://religionresearch.org/martijn/2009/05/05/islamizing-eu...

I don't think this is a solution. We should work to defragment the technology world. A better option is for Arabic speakers to learn English as a second Language. And for English speakers to learn Arabic as a second language but ultimately program in English. There is a similar problem with Chinese and the Chinese web, they might have some great resources tutorials and libraries but we don't know about them. I'll trade someone English and Ruby if you teach me Arabic.

It's even worse, hackers can mess with anything connected directly or indirectly to the internet.

Sites that want their content linked, reused and cited should use some sort of permalinking strategy. I don't think we should have a unverifiable citation because a publication does not follow sound link generation strategies. Provenance of the information is what we seek, citing a journal who doesn't provide a time proof way to access the resource should not be cited.

I think it's interesting the URL citation does not actually include the URL. It seems like the title of the article and the domain. Why is the exact URL of the resource is not important?

This exactly. I think part of the problem is that each of these projects has a corporate backer, Monetas, sponsoring Open Transaction is building a business around the platform. There is some incentive to keep the best doco closed source. There is a slim to none chance that the only documentation Monetas is using is available publicly. I spent some time setting up an opentransactions server, but could never spend enough time/research to get a production server up.

It's not hard. It's time consuming. Scouring 9 different semi-curated resources to develop a clear and concise comparison of the 3 is quite a task, a task someone should take on if any of these technologies are to become mainstream. How would you summarize the differences between them?

I don't agree with not having local repairmen as being a real showstopper. Any new system requires training: fire building, hut building, brick making. They need to factor training into the roll out of the technology, and don't focus on training men, take the women and grandmothers, train them first. RE: The barefoot movement in India: http://www.ted.com/talks/bunker_roy Tell a mother she doesn't have to walk 6 hours for dirty water, she will learn to fix whatever is necessary given the right training and availability of tools/material.

Could someone explain the difference between: Ethereum, Ripple, and OpenTransactions?

What we need to know is when a given system was patched, that would tell you who knew what when. Is the Google fork of OpenSSL publicly maintained? Has anyone identified the commit that introduced the "bug"?

What do you consider when choosing SQLite issues to assigns resources? I would guess it would start with issues relevant to your roadmap. If that's the case with most enterprise FOSS contributors, they most likely trusted the features of OpenSSL they were using. Thus no reason to go poking around that section of the code. It's understandable why a team might choose to not perform an ad-hoc security audit of features that pass specs, even more so when such an audit requires niche expertise. We can hope this bug changes that attitude and more enterprises with the resources and knowledge start performing security and encryption audits. Just as your buildings have security guards, we need proactive and preemptive audits of at least the most common libraries is use, flagging of software that implement unaudited encryption libraries. A Travis CI like badge on GitHub for these audit metrics would bring attention to the problem. We could call it EncryptCI. Maybe this already exists?

This bug was in fact discovered by a Google employee: https://www.openssl.org/news/secadv_20140407.txt

Stiff, I think you answered your own question. Intel HIRES them, open source projects don't generally hire people. They sit around and wait for someone to contribute. Are you truly surprised that a volunteer created software is not as rigorously tested as software created by Intel?

You should check out Zoneminder: https://github.com/ZoneMinder/ZoneMinder The development has been re-started and the project seems to be shaping up very well, I'm using it as well as many others.