I agree. But these cloud services are so new, that people are not aware of the risks they are taking. They don't realize the needs they actually have. Since the customers don't know their needs, neither do the service providers. But if you want to stay ahead of the curve, I think you should as a consumer, request reliable service providers, or self host. As a service provider you should provide reliable services. At least, that is where I think we are heading.
Very cool idea! I think you should think carefully about the use cases.
Is it for someone who wants to take a gene from one organism, move it to another and then order that organism?
Is it for people wanting to manually tweak genes to improve efficiency, slightly change function? What kinds of manual tweaks?
Is it for someone who wants to understand how an organism works?
When /I/ look at it, I think it could benefit from being more abstract, but I am not your target audience, so take this with a grain of salt. I don't think looking at individual base pairs is useful. Amino acids might be, but are still too emphasized in the interface. The most abstract view, showing genes in order is not abstract enough. I want to see genes grouped by function (e.g. reproductory system, energy production, acidity regulation etc). For each gene I want to see:
a) High level description of function (already there, but in a single line text field. Give more screen estate).
b) What activates the gene? i) Directly (e.g high concentration of Na+) ii) Indirectly (e.g. genes a, b, c) iii) Very Indirectly (environmental stress)
c) As exact specification as possible of what happens when it is activated: i) What does it activate in turn? ii) What does it catalyze?
My prediction: We can find a subset of proteins such that they do not interfere with each other, and still large enough that they can perform useful functions.
It is possible to write threaded software in a way that everything interacts with everything and it is almost impossible to make out how anything works. That's why we don't. The halting problem never stopped us from writing software.
Proteins are very "sticky". Even proteins with weakly predicted interactions exhibit significant effects upon one another when all-atom simulations are performed - this is actually a major stumbling block in getting cellular simulation right.
The most complicated piece of multithreaded software yet devised by humans does not compare in complexity to the transcription, translation, and interaction events occurring in a typical human cell. The "DNA as software" metaphor is just that, a metaphor - it is an exceedingly poor model. Cellular systems are so quantitatively enormous and convoluted (yet not chaotic!) that we have to compare them to the most complicated designs our species has recently engineered just to begin to get our heads around the problem.
I haven't kept up with the state of the art in the past two years, but I remember an experiment running a ~10k node cluster for several weeks being able to successfully simulate only the cytoplasm of a cell - and 1/1000th of its overall volume at that. And the proteins were all modeled as spheres. I'm sure the art has advanced, but that is orders of magnitude away.
My prediction: We can find a subset of proteins such that they do not interfere with each other, and still large enough that they can perform useful functions.
The tiny, tiny amount of bioinformatics knowledge I have makes me think the probability of your prediction is ~ 0.00000000000001%. For non-trivial values of "useful". :)
Can you tell me what experience or knowledge lead you to make that prediction?
Biological systems are highly coupled but also very "fault" tolerant if manipulated at the right pivot points. That's why you can move a fly leg from the torso to the head by just manipulating a few transcription factors.
Now I feel bad, maybe I should have voiced it in a way that sounded less sure. I base it on two things. 1. Similar genes do similar things in different species. 2. There are an incredible amount of possible proteins.
No it's incorrect. Compare "these truths... that all men are created equal, (...)" with "these kittens... that all kittens are created hungry". The that in the second sentence is wrong.
You can do better - if they're storing MD5s of the passwords, all they need to do is hash those again with another salt:
BCRYPT(MD5(Password))
Running BCrypt or SCrypt over the current MD5 hashes is easy, and they can do it right now for every password. If someone (else) grabs the database in ten days time they get no MD5 hashes of passwords instead of half of the userbase.
I believe the legacy api required md5(md5(password) + time) or something like that. Which means they needed to store the md5 of the passwords or modify all third party clients that used this method.
Thank you for the contentless comment. Instead, you might consider offering a more interesting algorithm, its tradeoffs, and why it is beneficial to take more computation time?
A rainbow table doesn't store every hash for the password space it's built for. I'm sure you already knew that, but decided to pretend otherwise when calculating the size of one.
Difficulty can be a decent heuristic for novelty, though. There are obviously a great number of simple things that have never been tried (or even thought of), but certainly difficult things are less likely to be tested, all other things being equal. That said, small ideas and small changes can be surprisingly impactful.
I rather like the idea of small changes that result in cognitive shifts. An article I read a while ago said that Lisp programmers are often unimpressed with language features other people have because Lisp can easily emulate and subsume them, essentially dismissing the idea for its technical simplicity and not an actual lack of merit.
I'm not a big web guy, but a lot of web tools seem to work that way - easy to think up, easy to code up, but once they're actually available they change the game in subtle ways. There's a mindset where people (myself included) say "Well, that's easy enough to hack up using cron and ssh and..." and we fail to recognise that actually having it makes us use it, and actually using it improves our lives.
