The only reason a scientist is going to talk about Darwinian evolution is to understand how the current theories of evolution came about. Science is a process, and all theories are subject to change if they don't fit the observed evidence. The progression goes something like this:
Lamarckian evolution - The idea that a parent could pass its characteristics on to its offspring. The most common (overly simplistic) example given is that a short-necked ancestor to the giraffe wanted to eat leaves, so it stretched out its neck, and all of its offspring had longer necks as well. No one believes this any more, because we have never observed it.
Weismann's germ plasm theory (favored by Darwin) helped to debunk Lamarckian evolution. It said that characteristics of somatic cells acquired during life could not be passed on to offspring - only mutations in germ cells (eggs, sperm) could. His ideas also predict the idea of an offspring getting two copies of each gene, one from each parent.
Darwinian evolution was the idea that the most fit members of a species tended to survive and reproduce. This has turned out to be a very good theory, in so far as it goes. It doesn't really provide much insight into mechanisms, but the basic observation has withstood the test of time. So, while this does provide the basis for modern theories of evolution, it is woefully incomplete. Talking about 'Darwinism' as the be-all, end-all of evolution is to stop at this point - which most fundamentalists would love to do. It makes it easier to attack evolution when you forget the next 150 years of progress.
Mendelian genetics was the insight into mechanisms by which traits might be inherited. Mendel breed pea plants and carefully observed phenotypes of the offspring relative to the parents. This leads to the basic idea of dominant and recessive traits.
Modern synthesis was the culmination of work by many biologist that finally gelled evolution into a the coherent theories we know today. It accounts for a genetic mechanism for evolution, selection as the main driver of genetic change in a population, and the need for genetic diversity in populations.
A few years after modern synthesis had come into its own, Watson and Crick (and Rosalind Franklin) figured out the structure and pairing rules for DNA, opening the door for a molecular level understanding of evolution.
Crick would go on to posit the central dogma of molecular biology, DNA <--> RNA --> proteins. This forms the core of modern thinking about evolution at a molecular level, while modern synthesis helps us to understand population genetics.
Again, as far as these theories go, they make testable predictions and failed to be disproved experiment after experiment (you can't every prove science - only disprove a theory by offering contradictory evidence).
These theories are still incomplete. It turns out that many of the interactions that Crick said would never happen as part of the central dogma do, in fact, happen. Prions are an instance of a trait (related to a protein structure in this case) being passed directly from protein to protein. This doesn't invalidate the central dogma, it just shows that our understanding of inheritance mechanisms is incomplete.
Similarly, while natural selection is the primary driver of evolution, it is not the only one. Genetic drift theory describes how individual traits move through the population. Neutral evolution describes the process of changes at the genetic level that do not change the amino acid that a gene codes for, but may still have some impact on the fitness of the species.
So yeah, 'Darwinism' fails to explain all sorts of things that we observe in the world around us. Modern evolutionary theories do a better job, but any scientist worth his salt will tell you that we don't know everything yet, and there are still holes to filled. And the only people who refer to Darwinism are those trying to understand history, or those desperate to cling to their own spec
Windows XP, Firefox 3.0.5, Adblock Plus. I have to imagine that this is a pretty standard configuration for a bunch of Slashdoters. I don't even use NoScript.
I visited your link, saw the Slashdot main page, and no pop up. What was I supposed to see, again?
My pop up blocker seems to be working just fine. What is this story even supposed to be about?
Windows XP, Firefox 3.0.5, Adblock Plus. I have to imagine that this is a pretty standard configuration for a bunch of Slashdoters. I don't even use NoScript.
I visited your link, saw the Slashdot main page, and no pop up. What was I supposed to see, again?
My pop up blocker seems to be working just fine. What is this story even supposed to be about?
I believe they intend to use RS-68 motors (which are also used on the Delta IVs) which results in some performance hit over the SSMEs (Space Shuttle Main Engines).
That'll be taken care of by the time you get to the point where you could build one of these. You've got two choices:
1. Use the RS-68A engine, currently in development to upgrade the Delta IV heavy. Same basic engine, ~20% better performance.
2. Use the RD-180 design used on the Atlas V heavy. It is Russian designed, but Lockheed (now ULA) are working with the Russians to get them manufactured state-side. Better performance than either the RS-68 or 68A.
Either way, you reuse existing EELV technology, which has a much better launch record than shuttle. Just add a bit of redundancy, pick an EELV configuration that can hoist the mass you want, and focus all of your design efforts on the crew capsule.
There are two reasons that NASA is pushing anything shuttle derived. Pride (the shuttle is NASA designed), and "The astronauts feel safer on a shuttle".
The real concerns should be cost to get the required mass to the required orbit, actual safety of the astronauts (not what makes them feel safe - what actually keeps them safe!), and how long it will be until we have it ready to fly.
To sum up:
- The shuttle is old, unsafe, and at EOL.
- EELV is flight proven, could be made safe by adding redundency, and ready now.
- Ares is a bad redesign of EELV (not shuttle!), and will be over budget and very late.
- Jupiter is barely in the planning stages, will probably be safer than the shuttle, but by how much? Right now, I can't tell that it is quantitatively better than an EELV.
Scrap Ares, kill the shuttle, and show me an unbiased comparison of cost, date of first flight and the likelyhood of killing the crew for an EELV solution vs Jupiter.
Hint #1: Michael Griffin jumping up and down shouting 'my solution is better' does not an unbiased comparison make, which is why we are even working on Ares in the first place.
Hint #2: Ares started life by modeling the performance of a basic Atlas V EELV (not even heavy launch). Just roll it back to that, and all of those oscillation issues go away...
It's all about what you've been exposed to. The t-shirt was cool because she had been exposed to retro rags at school. The music wasn't, because everyone at school had been listening to homogenized top-40 crap.
I remember my friend's 11 year old son. While we were over for an after-Christmas party, he was showing off his new electric guitar, iPod, and playing guitar hero.
His dad points out that the first stuff he loaded onto his iPod were a few recent songs, and a bunch of classic rock that he got exposed to by guitar hero. I asked him what his favorite was, and he shot back with 'Back in Black' by AC/DC. All he needed was exposure - he decided for himself that AC/DC was cool.
For all those little dudes who are about to rock - WE SALUTE YOU!
You want your niece to like something other than top-40? She's got to be exposed to it first!
I grew up on classical music and 1960's classic rock, because that was what my parents listened to. I listened to top-40 in high school, because everyone else did.
When I got to college, I was exposed to much deeper cuts from the 60's and 70's, a much wider range of modern rock and alternative, and a bunch of indie stuff after I had the morning DJ from the university radio station for a lab partner.
In grad school, I went out of my way to expand my indie horizons, including picking up a taste for rap. Not the 'pop a cap and bang a ho' stuff, but more of the intelligent, political, and *musical* stuff.
Today, I listen to a *much* wider range of music than almost anyone else I know - even people who claim to like a lot of different genres. I certainly don't like everything, but I've been exposed to more than most.
Just like retro fashion is cool, retro music can be, too. The RIAA is slowly killing itself and the top-40 format, and kids music tastes are starting to expand due to exposure to video games, iTunes, and *much* larger peer groups thanks to social networking sites.
Today's newest music isn't all that different than what's been available in the past. But there is much, much more total music available to the casual listener today than ever before. This is what today's youth will figure out. Not that their new thing is bigger than Jesus, but that their music tastes are much broader and more individualized than their parents. Pay attention to them, and you just might learn something.
Home-brew genetics? Sweet stuff, and very trendy right now.
The equipment to actually build your own primers is pretty expensive, and I don't know of anything that is suitable for a regular university lab, let alone home brew. You'll occasionally find the equipment in a core facility at the local university.
With that said - basic, unmodified primers suitable for PCR can be had for relatively minimal expense on small scales, which should be enough to get you started. Search for 'oligonucleotide synthesis' and find the lowest cost per base. Add a 'protocol' to that if you want to see if you can set something up at home.
If there are universities or other resources near you, you may be able to get in on one of their bulk deals - the more primers you order, the cheaper.
By the way, what's the current error rate? Is it 0? (just asking)
Not 0. It depends on how many reads you have over the region. If you know the error rate and you have multiple reads over the same region, you can put a confidence score on your call. Most of the human genome stuff has something like 8-fold coverage, which means your error rate stays pretty low. For normal sequences.
Problems arise when you get into highly repetitive areas of the genome, or areas that can form secondary structure. These are often biologically interesting, but difficult to sequence, so the error rate is much higher.
The new sequencing techniques, like those discussed in this article, have a much harder time with single base repeats than traditional methods do. But they can sequence 'normal' DNA much more quickly.
I predict that you'll start seeing a lot more hybrid approaches. The easy stuff will get cranked out in bulk by 454 or the new solid-state technologies. You'll get a rough assembly, covering 98% of the stuff you want to know, and you can then go back and cherry pick interesting/concerning regions with more traditional methods (to knock down false positive mutations) and fill in gaps in repeat regions (useful for 'fingerprinting' DNA).
BIG nit-pick. This is funny, until you realize that 'B' is a recognized character in the DNA alphabet. It is a degenerate base that means 'not A' (i.e. a mixture of C, G, T/U).
Sometimes these are artifacts of the sequencing technology. More commonly, there is actually an admixture of DNA in the starting sample. They are very common in RNA virus genomes, where the error-correction of the polymerase enzymes is crap compared to what mammals have evolved. This is a good thing for the virus, as it mutates quickly and escapes from immunity in the population.
In a bad sequencing run, you'll get a bunch of these mixed positions, and your data is crap. In an otherwise clean sequencing run, a mixed base position is extremely important information, and is often called incorrectly by both humans and automated base calling software, because people think that there must be exactly one non-degenerate 'right' answer.
This is actually a major problem as we start using '2nd generation' sequencing (454) and developing '3rd generation' sequencing like this article is describing. The amount of data being produced is moving past the point where humans can deal with it directly, so the assembly has to be automated. But the heuristics for tasks like calling bases are not yet up to the task, meaning that we sacrifice quality of information for quantity.
There are good opportunities in the field of bioinformatics for computer scientists who know enough biology!
You *can* run Python on Linux cluster supercomputers - distribute tasks to nodes with mpich, write the code in Python. I know people who do. I just don't know why.
For the truly hardcore number crunchers, use C or Fortran. Take the time. Do it right. Maximize the utility of your cluster time.
Here's the thing. Many people don't need or want that, but still think they need the speed of C or Fortran. The prejudices about scripting languages are still handed down though most computer science programs and science departments.
My longest running scripts can usually run overnight on a single core with a decent chunk of RAM, and I'll have results by morning. Python is good enough, and I'll have my results before you have working code.
I wonder if Fortran may eventually be replaced by Python.
Already has been, in my world. I know plenty of people around the chem department who still use Fortran because 'it is the language of scientific computing, dammit!'
Here is the thing. Most of the time, they were so panicked about how long the program would take to run, they lost sight of how long it took them to write it.
I replaced many Fortran programs with Python in my time, because I could write the data IO so much faster, and then just use the C-level numerical libraries to do the analysis. The program would end up running just as fast, and the code could be written in an hour instead of a week.
Some people will die before they change languages. The rest of us just want our results. Hopefully, the switch to py3k goes easy and the community continues to grow.
Author is Pedantic... And does quite a bit of complaining about Django without completely demonstrating his point.
Malcolm's blog assumes that the reader has a *very* good understanding of the django codebase. That's understandable, given that he rewrote most of the ORM prior to the recent 1.0 release, and most of his readers know it.
I'm still foggy about his complete idea of what he believes the original interpretation of a "Controller" is, which is really the heart of the matter and where most people seem to disagree.
His basic point is that no one actually knows what the controller *is*. The term is so poorly applied that it loses all meaning.
Really, this is a long standing point in the django community, and can be traced back to the original authors of the framework. Because django uses three primary modules, it gets labeled MVC. It doesn't actually follow that pattern very closely, so the authors took to referring to it as MVT (model, view, template).
In our interpretation of MVC, the "view" describes the data that gets presented to the user. It's not necessarily how the data looks, but which data is presented. The view describes which data you see, not how you see it. It's a subtle distinction.
Where does the "controller" fit in, then? In Django's case, it's probably the framework itself: the machinery that sends a request to the appropriate view, according to the Django URL configuration.
At the end of the day, of course, it comes down to getting stuff done. And, regardless of how things are named, Django gets stuff done in a way that's most logical to us.
Malcom is just pointing out that MVC comes with a lot of baggage, and doesn't really help to get stuff done.
with the exception of 2003-2004 when it was only marginally protective for one of the more common strains
It goes even further than this. The CDC and WHO knew which strain to pick that year. And it didn't grow in eggs, so it couldn't be picked.
It is very frustrating to know what you want, not be able to get it, and then watch a bunch of people die because of it...
Get your damn flu shot and protect the rest of us.
Amen! Flu is one of the biggest disease causes of morbidity and mortality on a yearly basis. And it is vaccine preventable. Why wouldn't you get a flu shot? You doctor will tell you if you have any risk factors that would prevent you from getting one.
How the hell does WHO predict Flu strains for immunization? I am honestly ignorant and would like to know.
No magic, really.
Basically, they pick the dominant strain that is circulating at the time that they have to make a recommendation to the vaccine producers.
The vaccine strain has to be picked ~6 months before it is needed (it takes that long to grow it up in eggs in sufficient quantity). Typically, that is right at the peak of flu season for the other hemisphere (north/south).
The selection is based on the RNA sequence for the virus, and on antigenic tests (antibodies to the strain, grown up in ferrets usually).
The selection is made much earlier than the CDC/WHO would like, but the long lead time for vaccines means you have to do it. So the track record for picking vaccine strains the last few years is pretty remarkable.
The only 'wrong' strain that got picked was the H3N2 strain in 2003. Everyone knew which strain to pick, but they couldn't make it grow in eggs. So they picked another one that did grow (better than nothing) and a lot of people died. Since then, there has been a lot more interest in getting a cell-based vaccine pushed through the FDA here in the US...
You don't want voice recognition. You want basic planning and lab book management skills.
You should be asking "Why didn't I get all of my protocols, reagents, samples, and equipment set up before I started my experiments for the day?"
I did quite a bit of biochemical benchwork to get my PhD, involving flu. Touching almost anything was either a bad idea for your health, or a worse idea for your experiment.
Instead, you laid out a plan for what experiments you were going to do for the day. You wrote it up in your notebook before you started. If you were doing a standard experiment, you probably had an easy excel template where you typed in the number of replicate experiments you wanted to run, and it did all of your calculations for you. Print it out, tape it in your notebook, grab all your samples and reagents from the freezer, and then (and *only* then) did you put on your gloves and go into the sterile hood.
My old lab book is *full* of these little protocols, usually with a typed note at the bottom about which samples I wanted to run, and a few hand written notes from after I took my gloves off.
For long, complex protocols, lay out a protocol book with step by step instructions. For really sensitive experiments, don't be afraid to change gloves after you flip the page. Gloves are cheap, compared to the reagents needed to run even a single PCR reaction.
A good craftsman has laid out all of his tools, plans and materials before he starts work. Good chefs have all their ingredients measured and utensils easily accessible before they start cooking. Either one *could* use a computer to track their project. But they don't, because it just makes everything more complicated.
Use a computer for planning, data storage, analysis, etc. Once you put the gloves on, good notebook skills put the computer to shame every time.
Reformat the current paragraph (great for editing text): nnoremap Q gqap vnoremap Q gq
Incremental searching: set incsearch
Insert a comment character on multiple rows - use this to do a visual select and comment out a code block: (ctrl-v) -> visually select a column (shift-i) -> go to insert mode (your favorite character here - I like #) esc, esc
Find a good set of fold rules and syntax highlighting for your favorite programming language. This has become an essential part of the way I work.
Those are some of my favorites. I discover something new about once a week, despite having used vim for years now.
A distributed vcs can do *everything* a centralized one like svn does, but does it better, does more. You'll find yourself doing things with it that are *possible* with svn, but so painful that you would never actually contemplate doing them.
I personally cannot think of a reason to start using svn at this point. If you are currently using it, stick with it if it works for you.
For any new project (and some old ones) a distributed source control tool is going to be just plain better. The majority of the gains come from the ease with which you can branch/merge/otherwise alter your local copy of a repo.
When I use svn, the code has to be right before I check it into the central repo, which means I don't keep any version history locally. This sucks if I make any mistakes.
With a dvcs (I use mercurial personally, but git is fine), I keep a much more constant history, try out crazy ideas with a branch, merge three or four branches to get all of the new features into one place, almost without thinking about it. All of this happens locally - no need to push it to a central repo.
The most common complaint about dvcs is that they aren't centralized. This is just a question of workflow - a dvcs allows you to impose your workflow on your codebase rather, than your vcs imposing it's workflow on you.
Your project needs a central repo? Fine - just designate one. Clone it, branch, merge, do a little dance, and push your changes back. Need more control over your project? Don't allow pushes - only pull once someone's local repository passes your unit test suite.
Because it is so much easier to get started and keep up with, I find myself versioning almost all of my work. It takes very little effort, and has saved my bacon a couple of times. I'd never have tried anything on this scale with svn, for fear of having to kill myself.
Instead of claiming that the whole system is broken, just fix the breakdowns in the current system.
The authors argue that scientific research suffers from an uncertain valuation, but this would require that the consumers â" the scientists â" can't accurately judge what's significant.
Any given paper does suffer from 'uncertain valuation', but uncertain doesn't mean the consumers have no clue.
Consider the impact factor of the journal to which the paper was submitted, the reputation of the author, the actual evidence that has been presented in the paper, the fact that the paper has undergone peer review, and what impact the paper would have its claims were to have merit.
In combination, these factors allow better papers to tend to float to the surface. This is fairly typical of a market.
Most fields have decent market regulation built-in, in the form of peer review and independent verification of results.
Politically charged fields (global warming) tend toward unregulated market behavior. Papers are no longer selected based on scientific merit, but instead on hype/scare factor. This makes the value of a paper much more uncertain, and leads to a nasty failure mode (see the current world economy).
There are models that do not have such nasty failure modes (or at least have very different failure modes). Usually, these also fail to produce such good results in the common case.
I dislike the current scientific publishing system because the publishers tend to be paid by both the author and the consumer, and can generally force the author to relinquish copyright. However, the quality of the system seems to me to be far better than this article supposes.
Howsabout books or sites on Python threaded programming? I'm going to be working on a project in a short while which will require the use of GTK and twisted together in a sort of network scanner system with asynchronous results.
As much as I love Python, it does have some weak points, and threading is one of them. From the python documentation:
The Python interpreter is not fully thread safe. In order to support multi-threaded Python programs, there's a global lock that must be held by the current thread before it can safely access Python objects.
Threading is there, and I'm sure some decent documentation exists somewhere. But the GIL (global interpreter lock) generally means that there are better ways to approach the problem in python, i.e. processes instead of threads.
It's a point of contention in the community, and the GVR-BDFL point of view is that any attempt to remove it makes Python a lot slower, so he won't.
While I don't use twisted, I am given to understand that it does most of its asynchronous stuff using callbacks - you may be able to leave most of the concurrency to it and avoid the process all together...
There's something missing in your considerations - time. That's a mighty list of things you've written that I can learn and use, but I have experiments to do.
There is an old research adage that applies here:
"A month in the lab will save you a week in the library."
Doing your analysis in Excel will save you minutes now, and cost you uncounted days or weeks later. What a trade-off!
I used to be you. I'm much better with Excel than most anyone else I know. I was always to go-to guy for Excel questions.
I have become the go-to guy for questions about how a problem could be solved using something other than Excel. My most recent achievement was to take an analysis that, despite a fancy curve-fitting library written in VB with a nice Excel interface, still took the better part of an hour per dataset because it required a bunch of hand manipulations, and turn it into a nice point-and-click process that runs near-instantaneously for curve-fitting, and takes about a minute if you want to generate a pdf of a hundred or so nicely formatted graphs.
My way cost me a couple of days of work, and saves my team probably a couple of days of work every week. I probably could have worked up ~30 experiments by hand in the time it took me to code up this program. I can now do the next 30 before you can finish one. In addition, you get *far* fewer errors in your calculations, nicer graphs, greatly improved error analysis, and the potential to easily integrate the analysis into the database that I'm working on, with another hour or two of work in the future.
There are two reasons that the project took me as long as it did. 1, I put a GUI on it. When I write tools for me, I write them command line and move on with life. 2, my users have a lot of trust in Excel. My analysis kept turning out "wrong". Turns out that every time, it was because they had made a mistake doing hand manipulations. It cost me several more hours to talk them through it, let them find out that their answers were the one that were actually messed up.
It always amazes me how panicked people are about short term time, and how blind they are to long term time. Are you really sure that Excel is saving you so much?
Most scientific programming is just "automating the tedium" (actual quote from me), until you realize that you save so much time that you end up "enabling the impossible" (actual quote from a co-worker). *Every scientist* should learn a little bit of programming, or learn their limitations and hire a science-savvy programmer.
Many threads have mentioned that when you have a hammer, every problem looks like a nail - they forget/gloss over that if you have enough finesse with a hammer but no experience with an sig welder, you'll likely get better results with your hammer than you will with the arc welder. You'll learn to weld when you need to.
I'll say it again. Even if you are an Excel wizard, you'd do well to pick a better tool and invest just a few days in learning it. Don't throw away Excel! Just realize that most craftsmen have more than one tool at hand, and that when they need an arc welder, if you hand them a hammer, you *will* be laughed out of the room.
I do a lot of graphing in python/pylab, which is great for simpler stuff like scatters, lines, histograms, and some more complicated stuff like subplots, basic 3D, etc. It has VTK integration for complex 3D, and you can typeset with LaTeX syntax if you want.
If I'm looking for really nice looking complex plots, like fitting surfaces, I tend to use SigmaPlot, just because that is what I learned in grad school. You can do some reasonably complex fits with it. Don't try to do any transformations with its spreadsheet interface though - you'll hurt your brain.
For more specalized stuff, check out things like GraphViz (for relationship graphs)or VTK (for volume rendering, etc).
Other people in the thread have mentioned some other software that might be worth looking at too. If you can't get the kinds of graphs you want from you plotting package, keep looking. The most important thing is to stop thinking that Excel is the answer.
Excel is not the answer. Excel is the question. The answer is 'No'.
while undeniably "superior" in nearly every aspect to Excel, takes time to implement - Potentially quite a lot of it.
Then you picked the wrong tool.
Try an ipython shell, the numpy package, and the pylab graphing interface. You can read in most list/table formats with 2 or 3 commands, which takes only a few seconds more than importing them into Excel. Once you have done that, you get free, interactive data analysis, C-like speed benefits - most of the computations are done at the C level - a syntax that emulates Matlab, graphs that actually look good, and the ability to export that data into any format at all, most of them with another 2 or 3 commands.
Like what you did? Save it as a script. Edit it any way you like, replay it later, get the same analysis every time - this *will* save you hours or even days at some point. Really like it? Generalize it to run easily on your next data set.
My way takes only a few minutes more. The *first* time. I can do more trasforms, more kinds of graphs, in short, play more than you can. When you are asked to repeat that analysis with a new dataset, my way is done running before you can get Excel to finish loading.
Pure C still has a place - when you need computational speed, ain't nothin' else gonna satisfy like banging out the C code.
But I stand by my point from my earlier post. For anything more complicated than a linear regression that I only intend to do one time, I can find a better tool for the job.
Most people I work with argue with me about this point, until I do something in a few minutes that they've been working on for days with little or no success, then make a nicer graph of it with one command then they can ever make using Excel.
Sidenote - If you routinely touch up graphs in Paint/Photoshop/Gimp, get a real graphing package. Excel is anything but.
Excel is *almost always* the wrong tool for the job. C is often the wrong tool for the job, unless you are doing really hardcore number crunching. Look into Python, MatLab, R, or SigmaPlot. Some are free, some are expensive, and all of them are worth it. Pick one that has the right toolset to help with your analysis. Dedicate a couple of days to learning what you can do with it.
With the time you save, you'll have plenty of time later to thank me and curse Microsoft.
Hardcore data analysis in Excel is almost always a bad idea. You can almost always find a way to do it in excel, and you can almost always find a way to do it better, faster, and cheaper somewhere else.
R, MatLab, Mathemateica, Python/Numpy, SigmaPlot, and any number of old, well written, debugged and vetted numerical libraries written in C or Fortran. I've used all of these at various times to solve something that a co-worker couldn't figure out how to do in Excel.
I fit quick linear regressions in Excel. For *anything* else, there is a better choice.
Slashdot Mirror
The only reason a scientist is going to talk about Darwinian evolution is to understand how the current theories of evolution came about. Science is a process, and all theories are subject to change if they don't fit the observed evidence. The progression goes something like this:
Lamarckian evolution - The idea that a parent could pass its characteristics on to its offspring. The most common (overly simplistic) example given is that a short-necked ancestor to the giraffe wanted to eat leaves, so it stretched out its neck, and all of its offspring had longer necks as well. No one believes this any more, because we have never observed it.
Weismann's germ plasm theory (favored by Darwin) helped to debunk Lamarckian evolution. It said that characteristics of somatic cells acquired during life could not be passed on to offspring - only mutations in germ cells (eggs, sperm) could. His ideas also predict the idea of an offspring getting two copies of each gene, one from each parent.
Darwinian evolution was the idea that the most fit members of a species tended to survive and reproduce. This has turned out to be a very good theory, in so far as it goes. It doesn't really provide much insight into mechanisms, but the basic observation has withstood the test of time. So, while this does provide the basis for modern theories of evolution, it is woefully incomplete. Talking about 'Darwinism' as the be-all, end-all of evolution is to stop at this point - which most fundamentalists would love to do. It makes it easier to attack evolution when you forget the next 150 years of progress.
Mendelian genetics was the insight into mechanisms by which traits might be inherited. Mendel breed pea plants and carefully observed phenotypes of the offspring relative to the parents. This leads to the basic idea of dominant and recessive traits.
Modern synthesis was the culmination of work by many biologist that finally gelled evolution into a the coherent theories we know today. It accounts for a genetic mechanism for evolution, selection as the main driver of genetic change in a population, and the need for genetic diversity in populations.
A few years after modern synthesis had come into its own, Watson and Crick (and Rosalind Franklin) figured out the structure and pairing rules for DNA, opening the door for a molecular level understanding of evolution.
Crick would go on to posit the central dogma of molecular biology, DNA <--> RNA --> proteins. This forms the core of modern thinking about evolution at a molecular level, while modern synthesis helps us to understand population genetics.
Again, as far as these theories go, they make testable predictions and failed to be disproved experiment after experiment (you can't every prove science - only disprove a theory by offering contradictory evidence).
These theories are still incomplete. It turns out that many of the interactions that Crick said would never happen as part of the central dogma do, in fact, happen. Prions are an instance of a trait (related to a protein structure in this case) being passed directly from protein to protein. This doesn't invalidate the central dogma, it just shows that our understanding of inheritance mechanisms is incomplete.
Similarly, while natural selection is the primary driver of evolution, it is not the only one. Genetic drift theory describes how individual traits move through the population. Neutral evolution describes the process of changes at the genetic level that do not change the amino acid that a gene codes for, but may still have some impact on the fitness of the species.
So yeah, 'Darwinism' fails to explain all sorts of things that we observe in the world around us. Modern evolutionary theories do a better job, but any scientist worth his salt will tell you that we don't know everything yet, and there are still holes to filled. And the only people who refer to Darwinism are those trying to understand history, or those desperate to cling to their own spec
Uh no. Try this URL http://www.adimpact.com/cgi-bin/webapp/nph-demo.cgi/000000A/http/slashdot.org/
Windows XP, Firefox 3.0.5, Adblock Plus. I have to imagine that this is a pretty standard configuration for a bunch of Slashdoters. I don't even use NoScript.
I visited your link, saw the Slashdot main page, and no pop up. What was I supposed to see, again?
My pop up blocker seems to be working just fine. What is this story even supposed to be about?
Uh no. Try this URL http://www.adimpact.com/cgi-bin/webapp/nph-demo.cgi/000000A/http/slashdot.org/
Windows XP, Firefox 3.0.5, Adblock Plus. I have to imagine that this is a pretty standard configuration for a bunch of Slashdoters. I don't even use NoScript.
I visited your link, saw the Slashdot main page, and no pop up. What was I supposed to see, again?
My pop up blocker seems to be working just fine. What is this story even supposed to be about?
Everyone do more Google searches!
Those Google computers are on *all day* - generating CO2 all the time!
If we all do more Google searches, they'll generate *less* CO2 per search.
I intend to double the number of Google searches I do per day, thereby generating only 7g of CO2 per search, and saving the environment!
WHO IS WITH ME?
I believe they intend to use RS-68 motors (which are also used on the Delta IVs) which results in some performance hit over the SSMEs (Space Shuttle Main Engines).
That'll be taken care of by the time you get to the point where you could build one of these. You've got two choices:
1. Use the RS-68A engine, currently in development to upgrade the Delta IV heavy. Same basic engine, ~20% better performance.
2. Use the RD-180 design used on the Atlas V heavy. It is Russian designed, but Lockheed (now ULA) are working with the Russians to get them manufactured state-side. Better performance than either the RS-68 or 68A.
Either way, you reuse existing EELV technology, which has a much better launch record than shuttle. Just add a bit of redundancy, pick an EELV configuration that can hoist the mass you want, and focus all of your design efforts on the crew capsule.
There are two reasons that NASA is pushing anything shuttle derived. Pride (the shuttle is NASA designed), and "The astronauts feel safer on a shuttle".
The real concerns should be cost to get the required mass to the required orbit, actual safety of the astronauts (not what makes them feel safe - what actually keeps them safe!), and how long it will be until we have it ready to fly.
To sum up:
- The shuttle is old, unsafe, and at EOL.
- EELV is flight proven, could be made safe by adding redundency, and ready now.
- Ares is a bad redesign of EELV (not shuttle!), and will be over budget and very late.
- Jupiter is barely in the planning stages, will probably be safer than the shuttle, but by how much? Right now, I can't tell that it is quantitatively better than an EELV.
Scrap Ares, kill the shuttle, and show me an unbiased comparison of cost, date of first flight and the likelyhood of killing the crew for an EELV solution vs Jupiter.
Hint #1: Michael Griffin jumping up and down shouting 'my solution is better' does not an unbiased comparison make, which is why we are even working on Ares in the first place.
Hint #2: Ares started life by modeling the performance of a basic Atlas V EELV (not even heavy launch). Just roll it back to that, and all of those oscillation issues go away...
It's all about what you've been exposed to. The t-shirt was cool because she had been exposed to retro rags at school. The music wasn't, because everyone at school had been listening to homogenized top-40 crap.
I remember my friend's 11 year old son. While we were over for an after-Christmas party, he was showing off his new electric guitar, iPod, and playing guitar hero.
His dad points out that the first stuff he loaded onto his iPod were a few recent songs, and a bunch of classic rock that he got exposed to by guitar hero. I asked him what his favorite was, and he shot back with 'Back in Black' by AC/DC. All he needed was exposure - he decided for himself that AC/DC was cool.
For all those little dudes who are about to rock - WE SALUTE YOU!
You want your niece to like something other than top-40? She's got to be exposed to it first!
I grew up on classical music and 1960's classic rock, because that was what my parents listened to. I listened to top-40 in high school, because everyone else did.
When I got to college, I was exposed to much deeper cuts from the 60's and 70's, a much wider range of modern rock and alternative, and a bunch of indie stuff after I had the morning DJ from the university radio station for a lab partner.
In grad school, I went out of my way to expand my indie horizons, including picking up a taste for rap. Not the 'pop a cap and bang a ho' stuff, but more of the intelligent, political, and *musical* stuff.
Today, I listen to a *much* wider range of music than almost anyone else I know - even people who claim to like a lot of different genres. I certainly don't like everything, but I've been exposed to more than most.
Just like retro fashion is cool, retro music can be, too. The RIAA is slowly killing itself and the top-40 format, and kids music tastes are starting to expand due to exposure to video games, iTunes, and *much* larger peer groups thanks to social networking sites.
Today's newest music isn't all that different than what's been available in the past. But there is much, much more total music available to the casual listener today than ever before. This is what today's youth will figure out. Not that their new thing is bigger than Jesus, but that their music tastes are much broader and more individualized than their parents. Pay attention to them, and you just might learn something.
Home-brew genetics? Sweet stuff, and very trendy right now.
The equipment to actually build your own primers is pretty expensive, and I don't know of anything that is suitable for a regular university lab, let alone home brew. You'll occasionally find the equipment in a core facility at the local university.
With that said - basic, unmodified primers suitable for PCR can be had for relatively minimal expense on small scales, which should be enough to get you started. Search for 'oligonucleotide synthesis' and find the lowest cost per base. Add a 'protocol' to that if you want to see if you can set something up at home.
If there are universities or other resources near you, you may be able to get in on one of their bulk deals - the more primers you order, the cheaper.
By the way, what's the current error rate? Is it 0? (just asking)
Not 0. It depends on how many reads you have over the region. If you know the error rate and you have multiple reads over the same region, you can put a confidence score on your call. Most of the human genome stuff has something like 8-fold coverage, which means your error rate stays pretty low. For normal sequences.
Problems arise when you get into highly repetitive areas of the genome, or areas that can form secondary structure. These are often biologically interesting, but difficult to sequence, so the error rate is much higher.
The new sequencing techniques, like those discussed in this article, have a much harder time with single base repeats than traditional methods do. But they can sequence 'normal' DNA much more quickly.
I predict that you'll start seeing a lot more hybrid approaches. The easy stuff will get cranked out in bulk by 454 or the new solid-state technologies. You'll get a rough assembly, covering 98% of the stuff you want to know, and you can then go back and cherry pick interesting/concerning regions with more traditional methods (to knock down false positive mutations) and fill in gaps in repeat regions (useful for 'fingerprinting' DNA).
BIG nit-pick. This is funny, until you realize that 'B' is a recognized character in the DNA alphabet. It is a degenerate base that means 'not A' (i.e. a mixture of C, G, T/U).
More degenerate codes here.
Sometimes these are artifacts of the sequencing technology. More commonly, there is actually an admixture of DNA in the starting sample. They are very common in RNA virus genomes, where the error-correction of the polymerase enzymes is crap compared to what mammals have evolved. This is a good thing for the virus, as it mutates quickly and escapes from immunity in the population.
In a bad sequencing run, you'll get a bunch of these mixed positions, and your data is crap. In an otherwise clean sequencing run, a mixed base position is extremely important information, and is often called incorrectly by both humans and automated base calling software, because people think that there must be exactly one non-degenerate 'right' answer.
This is actually a major problem as we start using '2nd generation' sequencing (454) and developing '3rd generation' sequencing like this article is describing. The amount of data being produced is moving past the point where humans can deal with it directly, so the assembly has to be automated. But the heuristics for tasks like calling bases are not yet up to the task, meaning that we sacrifice quality of information for quantity.
There are good opportunities in the field of bioinformatics for computer scientists who know enough biology!
Maybe he's, William Shatner?
You *can* run Python on Linux cluster supercomputers - distribute tasks to nodes with mpich, write the code in Python. I know people who do. I just don't know why.
For the truly hardcore number crunchers, use C or Fortran. Take the time. Do it right. Maximize the utility of your cluster time.
Here's the thing. Many people don't need or want that, but still think they need the speed of C or Fortran. The prejudices about scripting languages are still handed down though most computer science programs and science departments.
My longest running scripts can usually run overnight on a single core with a decent chunk of RAM, and I'll have results by morning. Python is good enough, and I'll have my results before you have working code.
I wonder if Fortran may eventually be replaced by Python.
Already has been, in my world. I know plenty of people around the chem department who still use Fortran because 'it is the language of scientific computing, dammit!'
Here is the thing. Most of the time, they were so panicked about how long the program would take to run, they lost sight of how long it took them to write it.
I replaced many Fortran programs with Python in my time, because I could write the data IO so much faster, and then just use the C-level numerical libraries to do the analysis. The program would end up running just as fast, and the code could be written in an hour instead of a week.
Some people will die before they change languages. The rest of us just want our results. Hopefully, the switch to py3k goes easy and the community continues to grow.
Author is Pedantic... And does quite a bit of complaining about Django without completely demonstrating his point.
Malcolm's blog assumes that the reader has a *very* good understanding of the django codebase. That's understandable, given that he rewrote most of the ORM prior to the recent 1.0 release, and most of his readers know it.
I'm still foggy about his complete idea of what he believes the original interpretation of a "Controller" is, which is really the heart of the matter and where most people seem to disagree.
His basic point is that no one actually knows what the controller *is*. The term is so poorly applied that it loses all meaning.
Really, this is a long standing point in the django community, and can be traced back to the original authors of the framework. Because django uses three primary modules, it gets labeled MVC. It doesn't actually follow that pattern very closely, so the authors took to referring to it as MVT (model, view, template).
From the django FAQ:
In our interpretation of MVC, the "view" describes the data that gets presented to the user. It's not necessarily how the data looks, but which data is presented. The view describes which data you see, not how you see it. It's a subtle distinction.
Where does the "controller" fit in, then? In Django's case, it's probably the framework itself: the machinery that sends a request to the appropriate view, according to the Django URL configuration.
At the end of the day, of course, it comes down to getting stuff done. And, regardless of how things are named, Django gets stuff done in a way that's most logical to us.
Malcom is just pointing out that MVC comes with a lot of baggage, and doesn't really help to get stuff done.
with the exception of 2003-2004 when it was only marginally protective for one of the more common strains
It goes even further than this. The CDC and WHO knew which strain to pick that year. And it didn't grow in eggs, so it couldn't be picked.
It is very frustrating to know what you want, not be able to get it, and then watch a bunch of people die because of it...
Get your damn flu shot and protect the rest of us.
Amen! Flu is one of the biggest disease causes of morbidity and mortality on a yearly basis. And it is vaccine preventable. Why wouldn't you get a flu shot? You doctor will tell you if you have any risk factors that would prevent you from getting one.
Go get vaccinated, people.
How the hell does WHO predict Flu strains for immunization? I am honestly ignorant and would like to know.
No magic, really.
Basically, they pick the dominant strain that is circulating at the time that they have to make a recommendation to the vaccine producers.
The vaccine strain has to be picked ~6 months before it is needed (it takes that long to grow it up in eggs in sufficient quantity). Typically, that is right at the peak of flu season for the other hemisphere (north/south).
The selection is based on the RNA sequence for the virus, and on antigenic tests (antibodies to the strain, grown up in ferrets usually).
The selection is made much earlier than the CDC/WHO would like, but the long lead time for vaccines means you have to do it. So the track record for picking vaccine strains the last few years is pretty remarkable.
The only 'wrong' strain that got picked was the H3N2 strain in 2003. Everyone knew which strain to pick, but they couldn't make it grow in eggs. So they picked another one that did grow (better than nothing) and a lot of people died. Since then, there has been a lot more interest in getting a cell-based vaccine pushed through the FDA here in the US...
You don't want voice recognition. You want basic planning and lab book management skills.
You should be asking "Why didn't I get all of my protocols, reagents, samples, and equipment set up before I started my experiments for the day?"
I did quite a bit of biochemical benchwork to get my PhD, involving flu. Touching almost anything was either a bad idea for your health, or a worse idea for your experiment.
Instead, you laid out a plan for what experiments you were going to do for the day. You wrote it up in your notebook before you started. If you were doing a standard experiment, you probably had an easy excel template where you typed in the number of replicate experiments you wanted to run, and it did all of your calculations for you. Print it out, tape it in your notebook, grab all your samples and reagents from the freezer, and then (and *only* then) did you put on your gloves and go into the sterile hood.
My old lab book is *full* of these little protocols, usually with a typed note at the bottom about which samples I wanted to run, and a few hand written notes from after I took my gloves off.
For long, complex protocols, lay out a protocol book with step by step instructions. For really sensitive experiments, don't be afraid to change gloves after you flip the page. Gloves are cheap, compared to the reagents needed to run even a single PCR reaction.
A good craftsman has laid out all of his tools, plans and materials before he starts work. Good chefs have all their ingredients measured and utensils easily accessible before they start cooking. Either one *could* use a computer to track their project. But they don't, because it just makes everything more complicated.
Use a computer for planning, data storage, analysis, etc. Once you put the gloves on, good notebook skills put the computer to shame every time.
In your .vimrc:
Reformat the current paragraph (great for editing text):
nnoremap Q gqap
vnoremap Q gq
Incremental searching:
set incsearch
Insert a comment character on multiple rows - use this to do a visual select and comment out a code block:
(ctrl-v) -> visually select a column
(shift-i) -> go to insert mode
(your favorite character here - I like #)
esc, esc
Find a good set of fold rules and syntax highlighting for your favorite programming language. This has become an essential part of the way I work.
Those are some of my favorites. I discover something new about once a week, despite having used vim for years now.
A distributed vcs can do *everything* a centralized one like svn does, but does it better, does more. You'll find yourself doing things with it that are *possible* with svn, but so painful that you would never actually contemplate doing them.
I personally cannot think of a reason to start using svn at this point. If you are currently using it, stick with it if it works for you.
For any new project (and some old ones) a distributed source control tool is going to be just plain better. The majority of the gains come from the ease with which you can branch/merge/otherwise alter your local copy of a repo.
When I use svn, the code has to be right before I check it into the central repo, which means I don't keep any version history locally. This sucks if I make any mistakes.
With a dvcs (I use mercurial personally, but git is fine), I keep a much more constant history, try out crazy ideas with a branch, merge three or four branches to get all of the new features into one place, almost without thinking about it. All of this happens locally - no need to push it to a central repo.
The most common complaint about dvcs is that they aren't centralized. This is just a question of workflow - a dvcs allows you to impose your workflow on your codebase rather, than your vcs imposing it's workflow on you.
Your project needs a central repo? Fine - just designate one. Clone it, branch, merge, do a little dance, and push your changes back. Need more control over your project? Don't allow pushes - only pull once someone's local repository passes your unit test suite.
Because it is so much easier to get started and keep up with, I find myself versioning almost all of my work. It takes very little effort, and has saved my bacon a couple of times. I'd never have tried anything on this scale with svn, for fear of having to kill myself.
Instead of claiming that the whole system is broken, just fix the breakdowns in the current system.
The authors argue that scientific research suffers from an uncertain valuation, but this would require that the consumers â" the scientists â" can't accurately judge what's significant.
Any given paper does suffer from 'uncertain valuation', but uncertain doesn't mean the consumers have no clue.
Consider the impact factor of the journal to which the paper was submitted, the reputation of the author, the actual evidence that has been presented in the paper, the fact that the paper has undergone peer review, and what impact the paper would have its claims were to have merit.
In combination, these factors allow better papers to tend to float to the surface. This is fairly typical of a market.
Most fields have decent market regulation built-in, in the form of peer review and independent verification of results.
Politically charged fields (global warming) tend toward unregulated market behavior. Papers are no longer selected based on scientific merit, but instead on hype/scare factor. This makes the value of a paper much more uncertain, and leads to a nasty failure mode (see the current world economy).
There are models that do not have such nasty failure modes (or at least have very different failure modes). Usually, these also fail to produce such good results in the common case.
I dislike the current scientific publishing system because the publishers tend to be paid by both the author and the consumer, and can generally force the author to relinquish copyright. However, the quality of the system seems to me to be far better than this article supposes.
Howsabout books or sites on Python threaded programming? I'm going to be working on a project in a short while which will require the use of GTK and twisted together in a sort of network scanner system with asynchronous results.
As much as I love Python, it does have some weak points, and threading is one of them. From the python documentation:
The Python interpreter is not fully thread safe. In order to support multi-threaded Python programs, there's a global lock that must be held by the current thread before it can safely access Python objects.
Threading is there, and I'm sure some decent documentation exists somewhere. But the GIL (global interpreter lock) generally means that there are better ways to approach the problem in python, i.e. processes instead of threads.
It's a point of contention in the community, and the GVR-BDFL point of view is that any attempt to remove it makes Python a lot slower, so he won't.
While I don't use twisted, I am given to understand that it does most of its asynchronous stuff using callbacks - you may be able to leave most of the concurrency to it and avoid the process all together...
There's something missing in your considerations - time. That's a mighty list of things you've written that I can learn and use, but I have experiments to do.
There is an old research adage that applies here:
"A month in the lab will save you a week in the library."
Doing your analysis in Excel will save you minutes now, and cost you uncounted days or weeks later. What a trade-off!
I used to be you. I'm much better with Excel than most anyone else I know. I was always to go-to guy for Excel questions.
I have become the go-to guy for questions about how a problem could be solved using something other than Excel. My most recent achievement was to take an analysis that, despite a fancy curve-fitting library written in VB with a nice Excel interface, still took the better part of an hour per dataset because it required a bunch of hand manipulations, and turn it into a nice point-and-click process that runs near-instantaneously for curve-fitting, and takes about a minute if you want to generate a pdf of a hundred or so nicely formatted graphs.
My way cost me a couple of days of work, and saves my team probably a couple of days of work every week. I probably could have worked up ~30 experiments by hand in the time it took me to code up this program. I can now do the next 30 before you can finish one. In addition, you get *far* fewer errors in your calculations, nicer graphs, greatly improved error analysis, and the potential to easily integrate the analysis into the database that I'm working on, with another hour or two of work in the future.
There are two reasons that the project took me as long as it did. 1, I put a GUI on it. When I write tools for me, I write them command line and move on with life. 2, my users have a lot of trust in Excel. My analysis kept turning out "wrong". Turns out that every time, it was because they had made a mistake doing hand manipulations. It cost me several more hours to talk them through it, let them find out that their answers were the one that were actually messed up.
It always amazes me how panicked people are about short term time, and how blind they are to long term time. Are you really sure that Excel is saving you so much?
Most scientific programming is just "automating the tedium" (actual quote from me), until you realize that you save so much time that you end up "enabling the impossible" (actual quote from a co-worker). *Every scientist* should learn a little bit of programming, or learn their limitations and hire a science-savvy programmer.
Many threads have mentioned that when you have a hammer, every problem looks like a nail - they forget/gloss over that if you have enough finesse with a hammer but no experience with an sig welder, you'll likely get better results with your hammer than you will with the arc welder. You'll learn to weld when you need to.
I'll say it again. Even if you are an Excel wizard, you'd do well to pick a better tool and invest just a few days in learning it. Don't throw away Excel! Just realize that most craftsmen have more than one tool at hand, and that when they need an arc welder, if you hand them a hammer, you *will* be laughed out of the room.
I do a lot of graphing in python/pylab, which is great for simpler stuff like scatters, lines, histograms, and some more complicated stuff like subplots, basic 3D, etc. It has VTK integration for complex 3D, and you can typeset with LaTeX syntax if you want.
If I'm looking for really nice looking complex plots, like fitting surfaces, I tend to use SigmaPlot, just because that is what I learned in grad school. You can do some reasonably complex fits with it. Don't try to do any transformations with its spreadsheet interface though - you'll hurt your brain.
For more specalized stuff, check out things like GraphViz (for relationship graphs)or VTK (for volume rendering, etc).
Other people in the thread have mentioned some other software that might be worth looking at too. If you can't get the kinds of graphs you want from you plotting package, keep looking. The most important thing is to stop thinking that Excel is the answer.
Excel is not the answer. Excel is the question. The answer is 'No'.
while undeniably "superior" in nearly every aspect to Excel, takes time to implement - Potentially quite a lot of it.
Then you picked the wrong tool.
Try an ipython shell, the numpy package, and the pylab graphing interface. You can read in most list/table formats with 2 or 3 commands, which takes only a few seconds more than importing them into Excel. Once you have done that, you get free, interactive data analysis, C-like speed benefits - most of the computations are done at the C level - a syntax that emulates Matlab, graphs that actually look good, and the ability to export that data into any format at all, most of them with another 2 or 3 commands.
Like what you did? Save it as a script. Edit it any way you like, replay it later, get the same analysis every time - this *will* save you hours or even days at some point. Really like it? Generalize it to run easily on your next data set.
My way takes only a few minutes more. The *first* time. I can do more trasforms, more kinds of graphs, in short, play more than you can. When you are asked to repeat that analysis with a new dataset, my way is done running before you can get Excel to finish loading.
Pure C still has a place - when you need computational speed, ain't nothin' else gonna satisfy like banging out the C code.
But I stand by my point from my earlier post. For anything more complicated than a linear regression that I only intend to do one time, I can find a better tool for the job.
Most people I work with argue with me about this point, until I do something in a few minutes that they've been working on for days with little or no success, then make a nicer graph of it with one command then they can ever make using Excel.
Sidenote - If you routinely touch up graphs in Paint/Photoshop/Gimp, get a real graphing package. Excel is anything but.
Excel is *almost always* the wrong tool for the job. C is often the wrong tool for the job, unless you are doing really hardcore number crunching. Look into Python, MatLab, R, or SigmaPlot. Some are free, some are expensive, and all of them are worth it. Pick one that has the right toolset to help with your analysis. Dedicate a couple of days to learning what you can do with it.
With the time you save, you'll have plenty of time later to thank me and curse Microsoft.
...everything looks like a snowglobe!
Hardcore data analysis in Excel is almost always a bad idea. You can almost always find a way to do it in excel, and you can almost always find a way to do it better, faster, and cheaper somewhere else.
R, MatLab, Mathemateica, Python/Numpy, SigmaPlot, and any number of old, well written, debugged and vetted numerical libraries written in C or Fortran. I've used all of these at various times to solve something that a co-worker couldn't figure out how to do in Excel.
I fit quick linear regressions in Excel. For *anything* else, there is a better choice.
You must have a problem with .bash_history too, right? Caching your keystrokes! OMG!
I don't much like .bash_history, so I usually do this:
$ rm .bash_history /dev/null .bash_history
$ ln -s
Can I do something similar with the iPhone? Better not to have to think about it, even if it isn't incriminating.
Benjamin Franklin was talking about exactly this when he said:
"They who can give up essential privacy to obtain a little temporary eye-candy, deserve neither privacy nor eye-candy."
That man was way ahead of his time.