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)...

I've been choosing btrfs through the debian installer for at least a couple of years now. Yes, I know it's not as awesome as ZFS, but it still beats mdraid and lvm.

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).

Not to mention - imaging a planet doesn't affect the planet. Extracting DNA, without contamination is a huge challenge for ancient DNA. It's hilarious how many NCBI sequences of mammal specimens turn out to matches for fish or insects (lab assistant's lunch? Did a fly get smooshed into a vial?) etc. Even if you do successfully extract, isolate and amplify some ancient DNA, how do you know you amplified actual DNA of the specimen and not something living in it (nematode etc)? In any case, I was just speculating that the "6.8M" year figure was perhaps the limit for the stability of the basic chemicals making up the GATCs under ideal conditions. IIRC they very quickly loose their structure and loose context from their neighbours much more quickly than that though. Disclaimer: not a scientist :-)

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 :-) Imagine those 10,000 image sources you mentioned, imagine they're 10,000px each. But instead of working from whole frames neatly arranged into 10000 frames of 100x100 pixels, all you have are 100000000 apparently random, individual pixels. How would you begin the task of assembling them into a single picture? You can imagine that as you grow the fragment size into 2x2, 4x4, 10x10 etc etc. squares which randomly cover random different pieces of the subject, you can eventually come up with a single compelling assemblage with a strong consenus that "this is what the subject must have looked like". But if these fragments get too small, especially without any idea of what the subject should look like... you suddenly get a worthlessly large number of equally valid contigs.

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...

That's cool. I understand the original article is about human genome research, but I still consider that you're thinking rather narrowly - but what do I know, so far my involvement in bioinformatics has only been accidental, I'm an engineer really. But just as an anecdote, I worked with a couple of unrelated teams - sponsored by pharma companies - to do basic "alpha taxonomy" and biology research on scientifically-neglected organsims (they're not cute or furry!). They make themselves out of (or secrete) interesting compounds potentially useful for cancer treatments. But because the biology/population dynamics of these things are so poorly understood, simply knowing where the populations exist, how diverse these populations are (sometimes "same species" individuals are chemically different in important ways - Due to life cycle? Are they just different forms of the same species? Or do the taxonomists need to split the species up? How are they interbreeding? What role does the compound of interest play in them? Etc) makes repeatability of these chemical assays on subsequent indviduals really quite difficult.

And in any case, I'm sure you're aware of all the interesting arguments for biosecurity/invasive species/food security etc... but that's getting off topic :)

I think you, honestly, misread. My point was that sequencing random organisms is not medically useful; it's focusing on diseases (to divine means of attack) or some carefully-selected model organism (to understand a simplified version of ourselves) that brings us important information.

I have to say that as somebody tangentially involved in evolutionary biology research (boring computational stuff), I appreciate and agree with most of your input in this discussion, however it has to be said that you're being a bit too dismissive of studies on non-human, non-model species. There is much to be learned about some very fundamental questions in molecular biology, not all of which might necessarily be answered by studying in-bred lab rats. It's my belief there is a mountain of data (sadly of poor quality either in controls/methods or provenance/curation) which could lead to questions and further studies of these "alien" species (Sea slugs, insects, plants) which have answers to important, basic fundamentals which wouldn't be as obvious by sticking to the utter desert of homogeneous specimens which medical research relies upon today.

That's not to say in-bred lab rats are the wrong tool for the job, but if that's all we're limited to, our discoveries will be similarly limited.

There are apps to make your tablet (at least for android anyway) a second display, but they're almost exclusively for windows. I've hacked up some scripts with VNC/x2x/etc. over WiFi in Debian with my 10" Galaxy Tab, but it was too clunky and I rarely want to travel with a tablet anyway. So I went for a Lenovo LT1421 USB DisplayLink screen instead.

Which is one of the 1366x768 resolution monitors you said you didn't want: http://www.lenovo.com/products/us/monitor/lt1421/. Given that portable productivity is my main concern though, I thought I'd share my experience with it. I use this display with a maxed-out i5 Lenovo x230 which itself is only 1366x768 - something that nearly put me off buying this brilliant little machine in the first place; but in the end I knew I'd be docking into a proper monitor for any serious work.

I take the display with me if I'm away for more than a day or two and expect to get some serious work hours in somewhere. It sits quite comfortably in my backpack which goes everywhere with me, next to the notebook. Setup is quick and painless, after some custom udev scripts at least, and in Linux also don't expect to (easily) have shared clipboard/window-dragging across screens: I've only ever been able to make this DisplayLink stuff work as a separate X11 server (with some extra bits like x2x to make it nicer).

Surprisingly, it's not the extra real-estate that I've come to appreciate most: it's the ergonomics. I position the USB display above my notebook, resting on whatever I can find up and away from the keyboard so I can look straight forward at it rather than spending hours hunched down over a little 12" notebook screen where the keyboard is.

At my home office I dock into a decent workstation setup with 27" WQHD 2560x1440 IPS display, as an almost-30-year-old I'm regretting all the terrible posture/ergonomics I've inflicted on myself over the years - so I make sure I'm setup properly for any work which stretches for more than an hour or so.

I run the USB display at 16 bit colour depth to improve responsiveness over the USB 2.0 connection. This is just fine for coding/browsing/email/project-management stuff but any full-screen multimedia (movies/games/etc) is going to happen on your main laptop screen, unless you find a USB 3.0 DisplayLink screen perhaps. The LT1421 also isn't IPS, so it's not quite as nice to look at but to be honest any time I find myself setting it up for a decent coding session it's in an appropriately lit/quiet area anyway.

You pretty much entirely misunderstood what I was saying

... after misunderstanding the GP yourself

And therefore, when someone says something bad about Linux package management, you interpret it as an attack on the only thing which can provide sustainability, sharing of effort, etc. You need to take into account that people might be disagreeing with your axioms instead...

We're having a disagreement, not a brawl. Just because I haven't adopted your point of view based on a few casual, wishful remarks from yourself doesn't mean that I am stubbornly clinging to something for the sheer fun of it. I have responded because it seems like you're trying to say something interesting, I just can't figure out what it is. I certainly can't relate it to any actual experiences in using, supporting, maintaining and developing open source software. So I guess I'm trying to understand if you've arrived at your conclusions based on something real, or did you just like the sound of it?

You really, really don't get me. I think that, rather than helping, the existing Linux model is actually hindering.

I got that, but you have to offer some sort of reasoning or justification for this. I completely fail to see that ditching shared libraries wouldn't result in a net increase in burden - I'm trying to imagine this world, it's a forgotten pre-internet era which seems far more tedious for both users and developers alike. How would you address the concerns I raised? Can you address them, or am I supposed to simply accept that your scenario is better?

I just want to use my computer, code, and share my code. I don't want to babysit my computer in every excruciating detail. I wonder if what you actually have an issue with is more abstract - fragmentation from competing ecosystems? Community/contributor organisation? OSS collaboration/release practices? Development priorities? Policies?

And the reason for that is that when you really look into it, the things you say about how it helps all contain paradoxes which mean they actually hinder.

And yet, the very things you're saying are hindering us are prominent features in the platforms Ingo wants us to reproduce!

For example, build and test infrastructure isn't actually shared, it's duplicated -- each distro does build and test on its own, because each distro is trying to tweak thousands of applications.

Again, more misunderstanding. Distros do not run build & test infrastructure because they're tweaking applications. Yes, it happens, but the vast majority of packages are completely unmodified, using distro-specific build parameters which are supported by the toolchain and is *not* upstream's concern. In fact (especially in the case of libraries) the human involvement in updating a package with upstream is simply running a tool which automates this!

The reason distros run build & test infra is to confirm that upstream have released something sane and behaves correctly in the distro's environment. Which is exactly what the platforms Ingo advocates do as well - Android, iOS, Windows Mobile.

You haven't shown me any technical challenge yet. And I don't buy that "use of packages or package management systems" equates with "OMFG what a waste of unnecessary extra work for everybody". Nobody is forcing anyone to package anything, and if you look carefully the "too many packages" argument can be re-cast as a "move stuff out of main and into contrib/universe" - or abandon the latter entirely, which is what PPAs or vendor/project-specific repos are all about. Hell, I can't be the only one using Oracle, MongoDB, and other project/vendor-specific repos can I?

You really, really don't get me. I think that, rather than helping, the existing Linux model is actually hindering.

You said that, I know you're saying that. But mere statements don't convey meaning or understanding or in fact any actionable information at all. Do distros package too much? Yes, but I have to say things have already been quietly changing for many years now: there's heaps of places to get pacakges other than the distro's official archives. What about the assertion that packages are bad, build/test infra is bad? Ingo advocates mobile platforms which:

• Have their own package format. The horror!
• Have their own duplicate build/test/validation infrastructure (arbitrarily) gating releases
• Have a centralized, curated repository for distribution

I am trying to understand, but I have yet to see any technical challenge. About the only real difference I see is chucking most stuff out of "main" repositories to focus on a core set of a few hundred things (1000+ packages) or so; and asking all software authors to drop everything to make sure they can be bothered to do the packaging of the chucked-out stuff for us (on all architectures).

Which means each distro and upstream software pretending that all the other distros don't exist; hence my comment about consolodation.