Nothing the GP said was incorrect - perhaps you've misread it. I thought GP was referring to the FUD/backlash against KDE which lasted many, many years longer than the actual licensing dillemma itself (less than a year?).
So yes, politics/belief/FUD drove the creation of Gnome, and that mis-maneouver by Qt/KDE project - despite being quickly rectified - had repurcussions that lasted much of a decade, despite the indifference of pragmatic users such as yourself.
I've been a Gnome user since around 2001, to say things were pretty rough back then is an understatement... In 2012 I switched to KDE. I finally had a machine with 16GB ram to run it on (FWIW KDE seems slightly better at running on limited hardware now, but stil..) Its defaults made me angry, though (especially Konsole - seriously, no keyboard shortcuts to hit a specific tab? Tabs at the bottom [oposite edge to the menus and titlebar]?) but I can actually repair it a lot quicker than fixing Unity/Gnome.
It's been this long and they still can't make KDE remember the orientation/resolution/relative position of any monitor that isn't the primary one - if I'm going to suffer through that sort of thing I might as well give i3-wm a proper go. I was able to use it productively for a whole day recently, which is more than awesome and xmonad lasted for me.
A *lot* of funky SCADA software. In 2012 built another MS-DOS 6.22-based data acquisition server (which is still in use, along with the others) using incredibly overpriced (albeit reliable) bits from Advantech, 16-bit ISA cards and all. The application's last update was 1996, not quite 20 years but getting there. Slightly less ancient data acquisition software runs in parallel with nicer looking reports and modern export formats, but isn't as reliable. The DOS machine, as clunky and ugly as it is, just absolutely refuses to ever fail. And I can't say that disaster recovery in an environment without any internet connectivity (drivers? activation? updates? etc.) is any worse with MS-DOS: transplanting the windows software from one installation to the next is actually quite traumatic compared to "let's just dd this image to a new CF-Card and boot from that"...
Also, did some work last year on an impressively large website with many millions of hits per month whose codebase began circa 1997. I should tell them perl 5.19 has dropped CGI.pm from the core distribution, heh
What a strange question. Octave has quite an enormous userbase, perhaps not as big as R but with a heritage going back to the 1980s.
The real question is what can't you do in Octave that you'd do in Matlab: it's been quite some years since I used either, but I did have to port my Matlab code to use different or missing toolboxes so that it would run on Octave. The other big problem is a complete lack of integration with data/signal acquisition hardware which has drivers for Matlab (up to a crusty old version you've probably just retired)...
Now personally, I happen to feel that maintaining those people's lives is a net loss for the human race, because they'll never contribute anything of import. These are not capable, creative people. These are chair-warming wal-mart shoppers.
How on earth did you reach this world view? Some of the most brilliant people I know are less than fully functioning human beings... I'm reminded of the famous mathematician Paul Erdos, a person whose achievements are truly remarkable but he famously had to ask one of his hosts once to close a window for him... apparently in the middle of one rainy night, he couldn't figure it out how to close it for himself. If he's a chair-warming waste of space, who isn't?
I always do a little research before buying my next computer, to see if there are any Linux compatibility issues. My last few laptops have been Lenovos, they seem to have pretty vanilla intel-centric hardware that works well for me with Debian.
On my recent x230 install I stumbled a bit as it was my first install on a UEFI boot machine, and KDE never remembers that I want the touchpad disabled at all times (it also never remembers how to configure my external display when I dock at my desk) - but meh. Other things which used to be a monumental pain in the arse, Eg. bluetooth tethering, printing, suspend/resume - "just works" now, so I'm probably a little more forgiving than the average windows user for any rough edges (multi-monitor support in windows is definitely superior, especially if you're spanning across different video adapters).
Metadata refers to side-channel data.
Don't make that assumption. As someone who works on data acquisition/management/processing (not telco) and gets trapped into hours-long discussions on data standards, especially derived data assets where the provenance/curation/modification history (not to mention the inputs, processing parameters, process versions/systems etc.) are just as important as the assets themselves... what is "meta" (or meta-meta, or...) and what isn't - is a huge area of ambiguity. The word "metadata" becomes utterly meaningless; I've been in meetings which informally ban it (lest we get lost into meta-meta-meta-meta-data - no exaggeration - and people lose their bearings, frame of reference and everybody gets confused about what "level" of meta-ness the conversation has collapsed into).
There is a good argument that the content of the call is only an incomplete record of the call. Without knowing the caller/callee/duration/date/time etc. we cannot put a voice recording into context and so the recording becomes useless and even perhaps unsearchable. If that's the case, then this "data" is of "first-order" importance and cannot be omitted by anyone - especially not the telcos who want generate any billing.
What is "meta" and what isn't, is all in the eye of the beholder. Meaningful documentation of protocols and information standards need to avoid assuming any common sense notion of the word.
I would be surprised if telcos consider "metadata" of a call to be far more boring than anybody cares about: technical stuff; SS7 attributes of the call, routing/exchanges/equipment involved, hand-overs between different mobile phone cells/towers, signal quality/encoding/protocol modes, measurements of bit error rate/latency/jitter/etc.
And putting huge amount of computation and DNA from the same animal through it, and we're even less stuffed. Seems to me to be a pretty damn useful technique, overall, even if it's only "statistically" correct.
Which technique are we discussing? Next-gen contig/alignment is quite mature, as is the understanding of the limitations. Older, slower, more expensive tech is still in use in some lesser-studied critters which, for want of a better word, aren't entirely validated on the next-gen stuff and some experiments are just plain easier to do.
If we're talking about the tech in TFA, yes it certainly describes the most delicate way one could conceive of for treating precious single strands of ancient DNA molecules - a kind of almost-in-situ imaging (versus the much more traumatic chemical techniques I'm more familiar with). Hence the 10-20x-ish increase in reach back in time - they've substantially lowered the minimum DNA quality/quantity required to get interesting sequence data out.
I guess I just wanted to convey something along the lines of "garbage in, garbage out". If you've got garbage in, no amount of CPU power is going to fix that. Denying this, as you know, is like yelling "enhance!" at bad images/videos on sci-fi or crime movies. Fitting data to models might yield some interesting stuff, or it might just yield whatever you want it to yield. I've seen geologists play tricks on each other with seismic interp, tuning filters to create convincing structures out of white noise!
And, as you said, even if they can get good data over just a few genes, even that's useful to evolutionary biologists - they can talk all day about rate of change in those genese and have arguments about calibrating genetic clocks with fossil records (unless that's just a plant biologist thing...)
I only mention the contamination issue because, at one of the seminars run by the Ancience Centre for DNA in Adelaide - it was highlighted as a significant problem early on in their research which resulted in detailed and rigorous sampling and processing protocols to get any worthwhile results at all. I seem to recall that early ancient DNA efforts had several false success which later turned out to be contamination - it's non-trivial. Even the act of using bare hands to wash an old bone in water overwhelms any tiny amount of useful, amplifiable ancient DNA.
The ACAD lab looked more like a semiconductor cleanroom compared to the more traditional labs near where I was working (plant DNA).
I'd go for that. It doesn't seem implausible at all, and DNA is much more simple in construction than you might think - which gives fewer combinations but more tricky fitting together. Get enough fragments, though, and you can throw it through a computer and get something useful out of the other end.
But that's the whole problem! Doesn't matter if you image a lonely letter 'A' on a shred of paper in 72dpi, 300dpi, 60000dpi - it's still a letter A, and you're never going to know what its neighbours were
To cut a long story short, at "6.8 mllion years old" I assume they mean "the longest read (maximum number of consecutive GATC 'letters' in a row) you're possibly going to get is one". Imagine having a pile of letters which were once arranged into the collective works of William Shakespeare: could you re-assemble the original work? No. But what if you had 4-letter fragments? You might be able to learn something about the english language, indirectly, but you probably won't be able to reverse-engineer the complete original work. Now what if you had slightly longer fragments? That would help. What if the garbled pile of letters/fragments actually consisted of multiple, similarly (randomly!) shredded copies of Shakespeare? Well, as long as they're randomly fragmented in different ways - you can imagine that where we guess two fragments might join each other, if we have a fragment from that same region from another copy wich spans that join - we can become more and more confident about forming a plausible assembly. So we can take advantage of this redundancy and randomized fragmentation to attempt recovery of the original work.
In other words, the more degraded the DNA, the shorter the fragments and the harder it is to come up with an assembly. At some point the fragmentation might be so bad that the only way you can attempt to achieve anything is to try to use a relevant, well understood reference sequence from a modern day specimen/consensus for comparison (or clues, or to fill-in-the-blanks)... if one exists. I'm no geneticist, but I think in those circumstances the confidence in the results start to go from "hey, that's cool!" to "interesting" to, eventually, an artist's rendition of what an ancient genome might have looked like - drawing from long lost cousins which are still alive today.
Happily, re-assembling short, fragmented DNA happens to be how commodoty high-speed, high-throughput, low-cost sequencing works these days - DNA is split into small lengths, Eg. 500-ish basepairs, and then depending on the experiment/purpose/targets etc. it's all (or partially) re-assembled by finding enough overlapping bits (hopefully beginning and ending with proprietary markers used in the splitting process) with statistical tricks to qualify if the data is sufficient, which areas are problematic in coverage/confidence etc... and it helps enormously if you're working on an organism that's already been sequenced to death for comparison.
So there are many well advanced tools for coming up with contiguous DNA from a pile of short reads.
IIRC, the other trick with ancient DNA is - first of all, extracting enough useful material to begin with, without damage. As reads get shorter, increased redundancy helps - more randomly overlapping regions can ease the task of re-assembly - but very short reads might mean that a number of different assemblages are possible. Not to mention delicate amplification methods which might increase the noise as well as the signal...