I don't expect the BBC to do an exhaustive search of all the peer review journals every time they do a science story, but they should at least check their own archives to help explain an curious conundrum like this one.
The date given for the bottleneck, ~70,000 years ago, coincides perfectly with the largest volcanic explosion in the last half million years. One that spewed thousands of times as much ash as produced in the 1980 Mt. St. Helens eruption.
The explosion of Toba in Indonedia around 74,000 years ago probably caused a greater than 5 degree drop in average global temperature that lasted over 6 years. 5 degrees may not seem like much but that global average may translate to over a 15C drop in the summertime temperatures in the temperate regions and would have devestating effects on many of the plants we relied on for food.
Point is that most of what I just mentioned (and much more) can be found in a few articles on their own web site:
A new hypothesis about recent human evolution suggests that we came very close to extinction because of a "volcanic winter" that occurred 71,000 years ago.
That article discusses a bottleneck of perhaps 15,000 humans. So the only real news is that the estimate of the bottleneck has been cranked back by an order of magnitude.
Just took a look at a financial site and noticed that dear old SCO/Caldera appears to have a market cap of $32.9 million today. As such, I wonder, what will be the total cost to IBM to properly defend themselves in this suit, plus the amount that they spend on "licensing" Unix from SCO? At least $32.9M perhaps? Maybe more...
Seems to me that the logical step for IBM now is to settle this suit by simply acquiring the plaintiff. Even before this suit was filed, it kinda made sense for quite a few reasons:
IBM's services division apparently loves to support old OS's and software, so the SCO support contracts would be a good match.
They would now own all the former members of the Project Monterey alliance (Sequent being the other member). No more sticky legal issues about code developed during that project.
There's the bragging rights of owning the Unix trademark. Certainly would give them a leg up marketing against Sun and HP.
Unfortunately, it looks like TLC is going to do almost exactly that with a show I just saw them advertise called Escape from Experiment Island.
And, if the contestants are as good at putting their science skills to practical use as the Professor on Gilligan's Island, this thing could go on for years.
As far as I have heard, Atria was founded by the old DSEE team and did not buy ClearCase outright:
In January of 1990, Atria Software, Inc. was founded to create the next generation of Software Configuration Management (SCM) product for Unix. Atria's founders were all originally from Apollo, and the founding team included all of the original designers of DSEE.
Only ClearCase LT uses FlexLM. The standard version uses its own license manager, which is actually a drawback since FlexLM at least tries to provide support for fallover with triad setups, but ClearCase's lm has no fallover mechanism.
Actually, Pure and Atria merged in August 96, and then in the Rational buying binge of 97, they picked up Pure Atria in June. So says Rational's history book. As for integrating RUP, using UCM with ClearCase is optional. I don't think it's existence as an option impacts standard ClearCase that much.
Note that computers will never, ever be able to figure out a protein structre ab initio. (i.e. without any info except the sequence)
Example of non-sequence info: The accuracy with which you can model the resultant structure of temperature-shocked chicken egg albumen proteins depends greatly on whether or not you choose to also model the frying pan.
First wipe your mouth becasue you've still got your mother's shit on your lips... I have the courtesy to not effect anothers, you brain dead shiteater.
I had been wondering how the MacArthur folks can so astutely tell the difference between geniuses and the rest of us, but perhaps it's not that challenging.
XML, CGI, and the DBI database interface are not part of the standard Perl install yet no one has any trouble supporting Perl projects relying on them.
Of course, that's because it's way easier to add things later to Perl than it is to initially build PHP (or add things later to it).
Re:An XML module that has surely been missed...
on
Professional PHP4 XML
·
· Score: 1
I'll second that motion! Reinventing the language wheel is so pointless when XPath is such a nice set of wheels!
Seriously, like so many other languages and query syntaxes, XPath has matured to the point where it's starting to take care of some of the issues that are important but non-obvious early on. Any new query/node-selection syntax would have to spend a while stumbling around before it noticed some of these needed subtlities
As both a Perl and a PHP programmer, I would agree that the DOM pieces need to more stanadards-compliant (read: finished), but I definitely do disagree that they should be part of the default language.
The main reason that people want them as part of the default it that DOM, Sablo, and so many other pieces of PHP are so challenging to intall manually. As such, what I'd rather see is a much better method of building and installing extensions ala Perl's CPAN. The problem is that everytime I mention CPAN to PHP people, I get a canned "but PHP has PEAR" response, without them realizing that CPAN is both a repository _AND_ a method of adding modules to Perl AFTER a build and install of the core language. That ease and capability is sorely lacking from PHP.
Gee, how come no one has submitted an open source version of Cosmic Osmo? I mean this is a Mac game competition isn't it?
Also think it's wicked cool that the number of games submitted so far is 42. Speaking of which, why no open source port of the old HHGTG text-based adventure game?
Nope. No connection to Trolltech. In fact, I wasn't even thinking of them with that comment. They've put together a fine API, but, and I'm likely about to start a flamewar here, as modern languages go, I personally exclude C++ to some degree from that definition.
Even if people don't like how Sun "fixed" a number of perceived drawbacks in C++ when they inherited from it in Java, that fact that both they and MS (in C#) both made rather radical departures, indicates that the language needs of today's coders can't be completely satisfied by C++.
So, the question remains, what modern (i.e. younger than C++) language is there that's truely cross-platform and also fast?
As with many things from Sun that have had trouble flying, the sometimes serious external attacks on their technologies have allowed them to ignore the serious internal "attacks" (or at least misapplications/poor management). I don't need to describe the external attacks, since you're probably already a either hardened believer or non-believer in the illegality of what MS did. But consider this for a moment, did Sun's well intented handling of Java actually hinder it more? My reason for saying this is that they still hold to two separate cross-platform doctrines that should have been decoupled a long time ago:
A solid cross-platform API that allows you to code one version of your app that can access many otherwise incompatible GUI and system components. This is a Very Good Thing (TM).
Still clinging to the idea that all Java has to run as byte code through an inexcusibly slow JVM instead of native code. And if they must stick to this model, why is it that a language like Perl, which must also run byte-code through a VM, but in addition also compiles on every invocation, is still much faster than Java. Sure, some other vendors have produced Java -> native compilers, but without top down direction in this field, this has not caught on. JIT's tried to promise speed, but failed.
Consider this: in the time Java has been available to the public, has there really been any serious development on a modern compiled language with one solid, standardized API across all-platforms? I can't think of any (or at least any that have caught on). Apple started down this road with Cocoa, but gave up on anything but their own platform.
In the end, two of the biggest losers due to that second doctrine has been Linux and the Mac. In order to get a vendor of an existing Windows app to produce a native Linux or Mac app, you have to convince them that it's worthwhile to branch off an almost complete re-write of their app to port it over. Imagine if there was a really usable language that they could code in, that wouldn't hinder their abilities and/or speed on Windows, but required little more than a cross-compile to target to Linux, Mac, Solaris, etc. We'd be up to our eyeballs in good apps on all platforms.
Gee, I'm so glad that in a time of falling tax revenues for so many states, counties and municipalities, that en masse they're going to staple themselves to the mast of the good ship S.S. Licensing Schemes. Full Steam Ahead. Say, what's that sinking feeling?
Back when Apple switched the Mac from 68k to PPC, they did better than expected keeping the old 68k code going, but they did so by using slow, clunky software emulators. Imagine if they could have just had one chip than ran both instructions sets! Since Jobs has finally reached the point where he doesn't immediately shoot down the idea of switching to x86 (In a recent interview: "We like having options..."), maybe they should check into this as a way of keeping PPC going. It would solve many of their potential spin problems:
Not emulating PPC on x86. After hyping the superiority of PPC over x86 for so long, they'ld be insane to use an x86 based architecture to do the emulation that would absolutely need to support.
The "x86" Mac would not just be a pretty PC clone. Running MacOSx86 on Apple hardware would have a tangible advantage over running it on generic PC hardware: the ability to run all the current PPC based Mac software at reasonable speeds. Not a big deal for current x86-ers who just wanna dump Windows, but it would be crucial for their current customers.
On x86 hardware, but not Intel hardware. Given some historic biases, this might be a bigger deal than it should be. Suggesting AMD instead doesn't seem to help.
Lots of options for their appliance/"digital hub" ideas Imagine if they could use the same CPU in everything from a multi-cpu PowerMac Server down to a settop box or handheld?
Unfortunately, my curmudgeon side says this all makes too much sense to ever become reality.
Everyone seems to be conceeding that this is too little, too late since RedHat has such a dominating market share. However, when the maker of the only Linux distro certified for use with Oracle 9i (SuSe) joins forces with the company that holds the Unix trademark and has been bringing over components and users from SCO (Caldera), perhaps we shouldn't be so quick to dismiss this.
Now, if only that rumor I've been spreading about IBM buying Caldera were to come true...
Slashdot Mirror
I don't expect the BBC to do an exhaustive search of all the peer review journals every time they do a science story, but they should at least check their own archives to help explain an curious conundrum like this one.
The date given for the bottleneck, ~70,000 years ago, coincides perfectly with the largest volcanic explosion in the last half million years. One that spewed thousands of times as much ash as produced in the 1980 Mt. St. Helens eruption.
The explosion of Toba in Indonedia around 74,000 years ago probably caused a greater than 5 degree drop in average global temperature that lasted over 6 years. 5 degrees may not seem like much but that global average may translate to over a 15C drop in the summertime temperatures in the temperate regions and would have devestating effects on many of the plants we relied on for food.
Point is that most of what I just mentioned (and much more) can be found in a few articles on their own web site:
Just took a look at a financial site and noticed that dear old SCO/Caldera appears to have a market cap of $32.9 million today. As such, I wonder, what will be the total cost to IBM to properly defend themselves in this suit, plus the amount that they spend on "licensing" Unix from SCO? At least $32.9M perhaps? Maybe more...
Seems to me that the logical step for IBM now is to settle this suit by simply acquiring the plaintiff. Even before this suit was filed, it kinda made sense for quite a few reasons:
Science Survivor?
Unfortunately, it looks like TLC is going to do almost exactly that with a show I just saw them advertise called Escape from Experiment Island.
And, if the contestants are as good at putting their science skills to practical use as the Professor on Gilligan's Island, this thing could go on for years.
Mother: Honey, why did the HR dept at Microsoft send us a fish wrapped in our missing son's NDA?
Father: It's a Sicilian message. It means he codes somewhere _really_ wet now.
In January of 1990, Atria Software, Inc. was founded to create the next generation of Software Configuration Management (SCM) product for Unix. Atria's founders were all originally from Apollo, and the founding team included all of the original designers of DSEE.
Note that computers will never, ever be able to figure out a protein structre ab initio. (i.e. without any info except the sequence)
Example of non-sequence info: The accuracy with which you can model the resultant structure of temperature-shocked chicken egg albumen proteins depends greatly on whether or not you choose to also model the frying pan.
I had been wondering how the MacArthur folks can so astutely tell the difference between geniuses and the rest of us, but perhaps it's not that challenging.
XML, CGI, and the DBI database interface are not part of the standard Perl install yet no one has any trouble supporting Perl projects relying on them.
Of course, that's because it's way easier to add things later to Perl than it is to initially build PHP (or add things later to it).
I'll second that motion! Reinventing the language wheel is so pointless when XPath is such a nice set of wheels!
Seriously, like so many other languages and query syntaxes, XPath has matured to the point where it's starting to take care of some of the issues that are important but non-obvious early on. Any new query/node-selection syntax would have to spend a while stumbling around before it noticed some of these needed subtlities
As both a Perl and a PHP programmer, I would agree that the DOM pieces need to more stanadards-compliant (read: finished), but I definitely do disagree that they should be part of the default language.
The main reason that people want them as part of the default it that DOM, Sablo, and so many other pieces of PHP are so challenging to intall manually. As such, what I'd rather see is a much better method of building and installing extensions ala Perl's CPAN. The problem is that everytime I mention CPAN to PHP people, I get a canned "but PHP has PEAR" response, without them realizing that CPAN is both a repository _AND_ a method of adding modules to Perl AFTER a build and install of the core language. That ease and capability is sorely lacking from PHP.
Gee, how come no one has submitted an open source version of Cosmic Osmo? I mean this is a Mac game competition isn't it?
Also think it's wicked cool that the number of games submitted so far is 42. Speaking of which, why no open source port of the old HHGTG text-based adventure game?
Nope. No connection to Trolltech. In fact, I wasn't even thinking of them with that comment. They've put together a fine API, but, and I'm likely about to start a flamewar here, as modern languages go, I personally exclude C++ to some degree from that definition.
Even if people don't like how Sun "fixed" a number of perceived drawbacks in C++ when they inherited from it in Java, that fact that both they and MS (in C#) both made rather radical departures, indicates that the language needs of today's coders can't be completely satisfied by C++.
So, the question remains, what modern (i.e. younger than C++) language is there that's truely cross-platform and also fast?
As with many things from Sun that have had trouble flying, the sometimes serious external attacks on their technologies have allowed them to ignore the serious internal "attacks" (or at least misapplications/poor management). I don't need to describe the external attacks, since you're probably already a either hardened believer or non-believer in the illegality of what MS did. But consider this for a moment, did Sun's well intented handling of Java actually hinder it more? My reason for saying this is that they still hold to two separate cross-platform doctrines that should have been decoupled a long time ago:
Consider this: in the time Java has been available to the public, has there really been any serious development on a modern compiled language with one solid, standardized API across all-platforms? I can't think of any (or at least any that have caught on). Apple started down this road with Cocoa, but gave up on anything but their own platform.
In the end, two of the biggest losers due to that second doctrine has been Linux and the Mac. In order to get a vendor of an existing Windows app to produce a native Linux or Mac app, you have to convince them that it's worthwhile to branch off an almost complete re-write of their app to port it over. Imagine if there was a really usable language that they could code in, that wouldn't hinder their abilities and/or speed on Windows, but required little more than a cross-compile to target to Linux, Mac, Solaris, etc. We'd be up to our eyeballs in good apps on all platforms.
Gee, I'm so glad that in a time of falling tax revenues for so many states, counties and municipalities, that en masse they're going to staple themselves to the mast of the good ship S.S. Licensing Schemes. Full Steam Ahead. Say, what's that sinking feeling?
Since Jobs has finally reached the point where he doesn't immediately shoot down the idea of switching to x86 (In a recent interview: "We like having options..."), maybe they should check into this as a way of keeping PPC going.
It would solve many of their potential spin problems:
Unfortunately, my curmudgeon side says this all makes too much sense to ever become reality.
Everyone seems to be conceeding that this is too little, too late since RedHat has such a dominating market share. However, when the maker of the only Linux distro certified for use with Oracle 9i (SuSe) joins forces with the company that holds the Unix trademark and has been bringing over components and users from SCO (Caldera), perhaps we shouldn't be so quick to dismiss this. Now, if only that rumor I've been spreading about IBM buying Caldera were to come true...