By this time next year, AMD will have captured the lead in all relevant desktop microprocessor markets and will be seen as the acknowledged technology leader. Within two years, Intel, citing eroding margins, will effectively withdraw from this market except in the production of proprietary multi-processor Web servers based on the McKinley (the Itanium's successor) and consumer-oriented devices based around StrongARM derivatives.
I really liked the article until I read this paragraph. Almost the entire article was very good, but unfortunately the author succumbed to one fatal miscalculation that lowered his credibility in my eyes: future-punditing, and giving his critical arguments more strength than they deserve. I have severe doubts that Intel will be giving up the desktop processor market in two years. I would put money on this prediction being wrong. The author made a strong case that AMD has succeeded wildly over the last year, but did not make a strong case that this success will extrapolate to the next two years sufficiently to drive Intel out of the desktop processor market of 50+ million units. (I'm not even sure AMD could ramp up manufacturing for that scenario!) He downplays the advantages of the Williamette core in a rather name-calling way ("based on ancient PentiumPro technology") rather than via some more sophisticated technical argument. The proof pro or con will be when Williamette ships of course, but I don't see the basis for his (IMHO) overly-strong conclusion.
The other comment that the author seems oblivious of is how 64-bits pays off for databases and how strongly Intel is investing in getting server applications to port to IA-64. This is not something I see AMD addressing strongly enough. As the author somewhat recognizes, corporate IT will likely remain on Intel on the server side over the short term, not just for 64-bits but for Intel's proven SMP capability. (Can you imagine how long it'll take AMD to wring the bugs out of their SMP implementations? Catching and debugging SMP race conditions is not a cake walk. I wouldn't buy any SMP servers from them at any price for at least the first year it's out.) Oh, and SMP isn't a big deal for "webservers," (small pipes, remember?) -- it's database servers where SMP pays off most.
One other point that this author and many others I've seen fail to mention about VLIW. It's not just a "maturity" issue, although that is a factor. It's the execution units! Most of the research I've read indicates that VLIW techniques don't payoff significantly over competing techniques (agressive out of order) until you get to around 8 simultaneous execution units. Itanium is down at around 4, and Transmeta is even lower, IIRC.
Still, a nice critique. I'm just stirring a few contrary opinions into the pot.
It's not just blind users who suffer from image-intensive pages; it's bandwidth-limited users. When I login over a modem (at home) or when on the road with my laptop, I have my browser set so that image-loading is off by default. I click on the "show images" icon when I absolutely have to have images to navigate the page. Then I usually wait for 2 minutes for it to load.
Executives generally don't care about the blind or slow-bandwidth, thinking that in business terms they won't be potential customers. But I have a solution for that. You have to convince the executive that other "high-end" people will be similarly frustrated.
I think if you show an executive how fast the page-load speed from a "executive dialing in on a laptop on the road", you could make a persuasive case for alt-tags for faster navigation. And point out that the new WAP-oriented phones with web browsing (also used by executives) will have the same problem.
It'd be nice to have some Napster-like distribution and retrieval system of USENET/forum postings for those of us constantly connected and willing to give up a few gigabytes of hard disk space for the 'net's sake.
I kinda noticed that when I was posting but wasn't 100% sure I remembered the syllable counts. Now that you mention it, flipping through his sample poems, there are a bunch of them that are off by a syllable or two in various lines. I thought haiku's were all 5-7-5 in terms of syllables per line. But I have vague recollection that there are more flexible forms; are they still legitimately called haiku? An article found via Google suggests so, but while doing, describes the primacy of the 5-7-5 form. Here's another definition of haiku, pretty interesting.
The syllable patterns in the "haiku" listed in his book (p163-166) and website have the syllabic patterns: 5-5-5, 4-7-6, 5-5-6, 4-5-4, 6-5-5, 4-6-7 Another list of poems from his website includes haiku with syllabes: 5-6-5, 3-4-5, 4-4-4, 3-5-4, 5-8-5, 6-4-7, 4-6-7, 5-6-6
Fourteen haiku, all hand selected from hundreds or thousands of presumably worse ones, and not even one 5-7-5 haiku!
What's even more troubling is the potential manipulation of the input. The poem I quoted was generated "after reading poems by Ray Kurzweil and Wendy Dennis." What isn't disclosed in the book AFAICT, but is mentioned on the Cybernetic Poet website is the background of Wendy Dennis, who is one of the two authors fed in to that poem I first quoted: Wendy Dennis (KCAT Research Analyst) organized an effort to gather files of poetry from 16 contemporary poets. Files of poetry from 20 classical poets were provided by The Poetry Archives. Wendy was also the project's Poet Personality Designer, and designed the 100 poet personalities that are included with the program.
This implies that there could be at least two other potential factors that make the poems "look intelligent" here: 1) the particular pieces of poetry fed in to the program are carefully hand-selected to generate human-looking output 2) the poetry fed into the system could actually be *composed* in an optimal way so to produce interesting-looking output (output that owes more to the data entered than the code written)
Well, thanks for the conversational spur to look into this. It's been educational.
Artificial thought -- They call it intelligence; I'm still better. Hah!
(Oops, forgot the nature theme to make it truly traditional.)
Winters' discontent -- a stark new competitor arises. Shot down!
--LP
P.S. The above post was created by a wetware neural network going by the handle LinuxParanoid, an engineer by training with little education in poetry. The subject did learn how to write haiku in middle school but had no further education on the subject and has never pursued haiku as a hobby. Both haiku were written in under 2 minutes each, with the subject having written maybe one haiku in the last ten years on a lark.
You're correct, I already know. I trust based on his past work that Dr. Kurzweil hasn't done something trivial. But just since you're so obnoxious, I'll go find out more about it.
...
The program he wrote is called "Cybernetic Poet." You can learn more about it or download a binary for Win95/98 off the net at his Cybernetic Poet website.
To summarize how it works: RKCP uses the following aspects of the original authors that were analyzed to create original poems: the (i) words, (ii) word structures and sequence patterns based on RKCP's language modeling techniques (while attempting not to plagiarize the original word sequences themselves), (iii) rhythm patterns, and (iv) overall poem structure. There are also algorithms to maintain thematic consistency through the poem. RKCP uses a unique recursive poetry generation algorithm to achieve the language style, rhythm patterns and poem structure of the original authors that were analyzed, without actually copying the original authors' writings.
He also has data for how his program fared on a limited poetry-based Turing Test. To summarize: The above 28-question poetic Turing test was administered to 16 human judges with varying degrees of computer and poetry experience and knowledge. The 13 adult judges scored an average 59 percent correct in identifying the computer poem stanzas, 68 percent correct in identifying the human poem stanzas, and 63 percent correct overall. The three child judges scored an average of 52 percent correct in identifying the computer poem stanzas, 42 percent correct in identifying the human poem stanzas, and 48 percent correct overall.
Sure, he gave the program a pretty high-quality input too (i.e. Keats); this isn't just the algorithms showing. I find it a good example that the converse of Garbage-in-garbage-out is true.
What surprised me about that particular poem was that it was actually better (IMHO) than something I could have written. I'm used to that in chess, but not in poetry. That's not a Turing test, but I'd argue its a pretty damn relevant test.
Having read Kurzweil's book (/. should interview him, BTW) "The Age of Spiritual Machines", I'd point out that his belief in "downloading your mind into a computer" is based on two basic trends he sees in addition to Moore's Law:
that our understanding of physically how neural signalling works is growing exponentially, and
our ability to scan/sense neural behavior in the real world is growing exponentially.
I did not see any explicit quantization of these trends in the book. Instead, they flow out of larger principles or "laws" he describes (e.g. the law of accelerating returns, the law of evolutionary process, increasing returns on knowledge, etc.) He does point out an interesting fact noticed by several people that I hadn't heard -- that mechanical computing devices back to Hollerith's tabulator and the theoretical performance of Babbage's engine do fit on the Moore's Law curve extrapolated back to 1900-1910.
He does offer some interesting examples of where we are today based on his world-class work in pattern recognition and recapitulation. I found his book thought provoking, albeit not quite convincing, but then, I don't follow neurology closely enough to validate his core assumptions. Proof by handwaving, conjecture and story telling isn't my style, but then, the book wasn't really written for my style either. I'm also a little skeptical based on my undergrad course in AI and my experience in writing simulations of natural selection. He moved me from "it probably won't happen in my lifetime" to "it could happen" but not quite to "it will happen."
I will admit to being stunned by three lines in the book, a haiku written by one of his computer programs after reading John Keats and Wedy Dennis:
You broke my soul the juice of eternity the spirit of my lips.
Antibiotics (particularly penicillin) and water purification have added 30 years of life expectancy from 1900-2000. I can't think of a bigger payoff.
(Read this article for more details. While the life expectancy improvements are partially due to a reduction in infant deaths, there's a demonstrable improvement in disease treatment affecting all age groups whose magnitude you can see by looking at the raw data of life expectancy by age in the US. Of course other factors did help besides antibiotics, such as nutrition and pollution reduction.)
Hey, you know your stuff! Nice.:-) I could quibble on a couple things but I mostly agree. Let me skip to make a couple points and ask one question:
You don't need pretty graphs and clicking buttons to monitor a server, but they are nice.
1) *You* don't need graphs or buttons, but I submit to you that there are a huge number of people who do need them. Linux fails to cater to those people at its own elitist peril.
Interfaces dependant on recognition, not remembering, will have shorter learning curves. The power and flexibility brought by knowing a second language (UNIX) come with a price akin to learning a foreign language. Any OS that reduces the operational learning curve for admins (or power users or users) will yield an economic benefit that the market will reward.
2) If you think cluster scalability is a big deal in the enterprise, you might stop and consider why the big UNIX players and mainframes sell a lot more big SMP systems? Clusters are a lot cheaper to develop, but any database activity with lots of reads on clusters by definition slows to the bandwidth of your network (not your disk array or memory), (e.g. data warehousing, mining, other DB query apps) and the situation with write-intensive transaction processing provides contention and locking problems that are even worse. Sure, I agree that easily parallelized technical applications, DFS, and stateless webservers cluster are fine on Linux today. But we have to be better than everyone else on SMP to gain world domination.
Question: where did you get the "database performance such as SAP R3" results? SAP isn't a database, it runs on top of a database, and IIRC, the one Linux SAP benchmark I remember seeing was something like a Software Distribution benchmark which seemed to suggest more of a network than a database benchmark.
Maybe its just me, but I think if we can get Linux into enough database environments, it'll be around forever. If we get stuck in web/file/network serving, we can get pushed out by Microsoft marketing, tying and upper management. The bottleneck to more Linux DB deployments seems to be better failover software and high pricing for "trusted" databases. Scalability is a secondary but important issue here.
So, even though Win2000 is the slowest of the bunch (even slower than SCO's UNIXWare, according to this artile), it "Tops the field," but the benchmarks tell the true story. So, if you just skim the first few paragraphs of this article you'll walk away thinking Win2000 is the OS to beat. But by actually reading the article, you'll see the whole picture. Why do I think this is more of an advertisement for Win2000, than a serious article?
Because you don't seem to be willing to listen to the many weaknesses currently present in Linux that must be addressed if you want to claim superior technology. Lots of these are being worked on, but they aren't shipping yet. The GUI management interfaces in Linux aren't as good, neither are the performance monitoring tools which are woefully obscure. Red Hat Linux lacks ACLs which can accept/deny permissions to files on a per-user basis. Kerberos is a pain to learn about and install. Scalability still isn't great on the 2.2-based kernel series. The IP stack on the 2.2 kernel still isn't multithreaded. Storage management isn't that great without journalling filesystems which have been in the works on Linux for at least a year and have long been on NT. Distributions like RedHat aren't shipping ReiserFS as supported software AFAIK. The article and the associated scorecard show you the criteria and weightings.
(Is anyone doing GUI performance management tools, BTW? I've seen at least alpha code and efforts for everything else except that one...)
Would you trade all these things away to get 10-15% better file performance? I would.
There *are* things that Microsoft can't match (freedom, etc.) and we have to keep improving our ability to articulate those benfits of that, but technologically, Windows2000 does raise the bar for Linux to beat. We don't want to end up like Netscape, vaguely cooler but not as strong technically.
Perhaps Transmeta is an issue, but believe me, these price cuts have been in the works for a while and were planned to happen when Intel introduced it's SpeedStep technology. Intel always cuts prices on old stuff around the time it intros new stuff.
It does look like Transmeta found out the SpeedStep announcement date and scheduled their event the day before to preempt coverage of SpeedStep. That worked quite well, IMHO.
Hey, they may be obsolete, but I really like their www.stampsonline.com site for buying stamps online. I can pick the ones I want (unlike the local office) and shipping and handling is only $1! Try it once, it's cooler that you'd expect at first.
Actually, the problem with Staroffice is that it doesn't read lots of my office's Office95 files properly. Sure, Office2000 files work OK, most of the time, but I only have one machine with Office2000 and converting all my old docs to Office2000 would be a HUGE pain!
--LP
P.S. Your analysis that flash and sizzle always wins is clearly wrong. The Commodore64, Amiga, Mac all had more flash and sizzle than the lowly PC. But Wintel was actually useful both in work and at play. Good business apps and OK games won out over great games and OK business apps.
Due to some quirks of fate, Microsoft and Intel were at the right place at the right time to contribute to the IBM PC development effort, and customers in that era on balance cared more about making sure they knew the PC computer system at work than optimizing for the flashiest system at home. When faced with a choice, many (but not most) bought PCs. By steadily growing their flash and sizzle, Wintel managed to squeeze out PC competitors who had a harder time penetrating the corporate side of the PC business due to inherently fewer apps. Sustaining Wintel's at-birth application advantage was made possible by keeping backwards binary and file format compatibility.
Marketing didn't get Wintel where it is today. Its sold a lot of extra boxes, sure. But positioning (and good execution), not marketing was the decisive factor in ensuring Wintel's dominance. A position they gained at the birth of the IBM PC and a consistent effort afterwards to position themselves to best provide what the most customers most wanted.
To gain world domination, Linux has to overcome switching costs, and to do that, Linux will have to do a substantially better job of providing what the most customers most want than Microsoft. It's conceivable, but it won't be quick or easy. (Linux is almost 10 years old already.)
You raise an interesting point. Open sourcing the CMS would make for some interesting market opportunities. But at the end of the day, I'm just not that the market for more instruction sets is that big. Do consumers or device designers want more instruction sets? As far as I can tell, the guys who like more instruction sets are the chip designers who want to lock in a community of software developers. And they are competitors of Transmeta; no point in them using Transmeta technology.
I suspect Transmeta will try to get vendors of existing instruction sets (SPARC, MIPS, Alpha) to license the CMS and build their own instruction sets off of Transmeta's. If, for example, Sun ever decided it couldn't keep up the SPARC speeds with Intel and Transmeta had a better shot at that, Transmeta's chips would make a nice migration; you could run both x86 and SPARC (and Java.) I'm sure that this has occured to Ditzel et al.
But then again, I don't buy the premise that Open Source is two orders of magnitude more productive than closed source. Lacking more rigorous analysis, NT began in October 1988, Linux began in 1991, and I don't think, good as it is, Linux is 100x better than NT. Over confidence in open source can be just as deadly as under confidence or incomprehension.
By integrating 3D, I meant integrating the whole 3D pipeline (think "integrating Nvidia's GeForce 256"), not just the CPU instructions like 3DNow or SSE which allow floating point vector processing for early stages of geometry transformations and lighting.
You point about suits and licensing of SSE is a valid one; it's not clear to me whether the lack of SSE so far is a technology development issue or a legal isse. Transmeta has added MMX (which is widely crosslicensed) but not yet added SSE. I'm no expert on this but the fab also may need a license; i.e. IBM may have a license to fab processors with MMX technology but not SSE?
Your points are fair ones. As I said in a reply to someone else, Transmeta has a shot at opening up a whole new category of low-power, low-cost "mobile internet" as they call it PCs.
To sum up my basic concern in a single sentence: I don't see enough barriers to entry to prevent Intel from crushing them in 3 years with a "good enough" power-optimized x86 solution. Does Transmeta have a strategy to deal with this?
I'm OK with most of what you say up until the last paragraph. 3D circuit design is a very complex beast. More complex than any other digital circuitry save CPUs, IMHO, and that's saying a lot. If you understood all the stages of the graphics pipeline and how they could be executed in parallel, you'd understand that it's a lot more complicated than saying you can "cache and optimize the 3D instructions."
If your "3D instructions" are SSE or 3DNow, sure I agree with you, but if you're talking about integrating and caching/optimizing the actual hardware geometry transformations and lighting code and various rasterization stages in a flexible programmable way, that's a huge multi-year architectural project. The difference in datapath design between CPU circuitry and 3D circuitry is enough to require wholly different sets of optimization techniques. It'd be easier to just slap a fixed 3D ASIC design in one corner of the chip, although once you're doing that, you're losing much of the benefits of the Transmeta approach. Plus there is analog circuitry such as the RAMDAC video output that presents additional not-major but not-trivial engineering complications for complete 2D or 3D integration.
Your points are fair ones. Transmeta has a shot at opening up a whole new category of low-power, low-cost "mobile internet" as they call it PCs.
To sum up my basic concern in a single sentence: I don't see enough barriers to entry to prevent Intel from crushing them in 3 years with a "good enough" power-optimized x86 solution. Does Transmeta have a strategy to deal with this?
Slashdot Mirror
I really liked the article until I read this paragraph. Almost the entire article was very good, but unfortunately the author succumbed to one fatal miscalculation that lowered his credibility in my eyes: future-punditing, and giving his critical arguments more strength than they deserve. I have severe doubts that Intel will be giving up the desktop processor market in two years. I would put money on this prediction being wrong. The author made a strong case that AMD has succeeded wildly over the last year, but did not make a strong case that this success will extrapolate to the next two years sufficiently to drive Intel out of the desktop processor market of 50+ million units. (I'm not even sure AMD could ramp up manufacturing for that scenario!) He downplays the advantages of the Williamette core in a rather name-calling way ("based on ancient PentiumPro technology") rather than via some more sophisticated technical argument. The proof pro or con will be when Williamette ships of course, but I don't see the basis for his (IMHO) overly-strong conclusion.
The other comment that the author seems oblivious of is how 64-bits pays off for databases and how strongly Intel is investing in getting server applications to port to IA-64. This is not something I see AMD addressing strongly enough. As the author somewhat recognizes, corporate IT will likely remain on Intel on the server side over the short term, not just for 64-bits but for Intel's proven SMP capability. (Can you imagine how long it'll take AMD to wring the bugs out of their SMP implementations? Catching and debugging SMP race conditions is not a cake walk. I wouldn't buy any SMP servers from them at any price for at least the first year it's out.) Oh, and SMP isn't a big deal for "webservers," (small pipes, remember?) -- it's database servers where SMP pays off most.
One other point that this author and many others I've seen fail to mention about VLIW. It's not just a "maturity" issue, although that is a factor. It's the execution units! Most of the research I've read indicates that VLIW techniques don't payoff significantly over competing techniques (agressive out of order) until you get to around 8 simultaneous execution units. Itanium is down at around 4, and Transmeta is even lower, IIRC.
Still, a nice critique. I'm just stirring a few contrary opinions into the pot.
--LP
Before your head explodes, read the following explanation why the universe has 4 dimensions, not 7 or some other number:
;-)
http://www.hep.upenn.edu/~max/dimensions.html
--LP
Before your head explodes, read the following explanation why the universe has 4 dimensions, not 7 or some other number.
--LP
It's not just blind users who suffer from image-intensive pages; it's bandwidth-limited users. When I login over a modem (at home) or when on the road with my laptop, I have my browser set so that image-loading is off by default. I click on the "show images" icon when I absolutely have to have images to navigate the page. Then I usually wait for 2 minutes for it to load.
Executives generally don't care about the blind or slow-bandwidth, thinking that in business terms they won't be potential customers. But I have a solution for that. You have to convince the executive that other "high-end" people will be similarly frustrated.
I think if you show an executive how fast the page-load speed from a "executive dialing in on a laptop on the road", you could make a persuasive case for alt-tags for faster navigation. And point out that the new WAP-oriented phones with web browsing (also used by executives) will have the same problem.
--LP
It'd be nice to have some Napster-like distribution and retrieval system of USENET/forum postings for those of us constantly connected and willing to give up a few gigabytes of hard disk space for the 'net's sake.
--LP
So what encryption algorithm or program did he use? How big was the keysize?
Inquiring minds want to know.
--LP
I kinda noticed that when I was posting but wasn't 100% sure I remembered the syllable counts. Now that you mention it, flipping through his sample poems, there are a bunch of them that are off by a syllable or two in various lines. I thought haiku's were all 5-7-5 in terms of syllables per line. But I have vague recollection that there are more flexible forms; are they still legitimately called haiku? An article found via Google suggests so, but while doing, describes the primacy of the 5-7-5 form. Here's another definition of haiku, pretty interesting.
The syllable patterns in the "haiku" listed in his book (p163-166) and website have the syllabic patterns:
5-5-5, 4-7-6, 5-5-6, 4-5-4, 6-5-5, 4-6-7
Another list of poems from his website includes haiku with syllabes:
5-6-5, 3-4-5, 4-4-4, 3-5-4, 5-8-5, 6-4-7, 4-6-7, 5-6-6
Fourteen haiku, all hand selected from hundreds or thousands of presumably worse ones, and not even one 5-7-5 haiku!
What's even more troubling is the potential manipulation of the input. The poem I quoted was generated "after reading poems by Ray Kurzweil and Wendy Dennis." What isn't disclosed in the book AFAICT, but is mentioned on the Cybernetic Poet website is the background of Wendy Dennis, who is one of the two authors fed in to that poem I first quoted:
Wendy Dennis (KCAT Research Analyst) organized an
effort to gather files of poetry from 16 contemporary
poets. Files of poetry from 20 classical poets were
provided by The Poetry Archives. Wendy was also the
project's Poet Personality Designer, and designed the
100 poet personalities that are included with the
program.
This implies that there could be at least two other potential factors that make the poems "look intelligent" here:
1) the particular pieces of poetry fed in to the program are carefully hand-selected to generate human-looking output
2) the poetry fed into the system could actually be *composed* in an optimal way so to produce interesting-looking output (output that owes more to the data entered than the code written)
Well, thanks for the conversational spur to look into this. It's been educational.
Artificial thought --
They call it intelligence;
I'm still better. Hah!
(Oops, forgot the nature theme to make it truly traditional.)
Winters' discontent --
a stark new competitor
arises. Shot down!
--LP
P.S. The above post was created by a wetware neural network going by the handle LinuxParanoid, an engineer by training with little education in poetry. The subject did learn how to write haiku in middle school but had no further education on the subject and has never pursued haiku as a hobby. Both haiku were written in under 2 minutes each, with the subject having written maybe one haiku in the last ten years on a lark.
You're correct, I already know. I trust based on his past work that Dr. Kurzweil hasn't done something trivial. But just since you're so obnoxious, I'll go find out more about it.
...
The program he wrote is called "Cybernetic Poet." You can learn more about it or download a binary for Win95/98 off the net at his Cybernetic Poet website.
To summarize how it works:
RKCP uses the following aspects of the original authors
that were analyzed to create original poems: the (i)
words, (ii) word structures and sequence patterns
based on RKCP's language modeling techniques (while
attempting not to plagiarize the original word sequences
themselves), (iii) rhythm patterns, and (iv) overall poem
structure. There are also algorithms to maintain
thematic consistency through the poem. RKCP uses a
unique recursive poetry generation algorithm to achieve
the language style, rhythm patterns and poem structure
of the original authors that were analyzed, without
actually copying the original authors' writings.
He also has data for how his program fared on a limited poetry-based Turing Test. To summarize:
The above 28-question poetic Turing test was
administered to 16 human judges with varying degrees
of computer and poetry experience and knowledge. The
13 adult judges scored an average 59 percent correct in
identifying the computer poem stanzas, 68 percent
correct in identifying the human poem stanzas, and 63
percent correct overall. The three child judges scored
an average of 52 percent correct in identifying the
computer poem stanzas, 42 percent correct in
identifying the human poem stanzas, and 48 percent
correct overall.
Sure, he gave the program a pretty high-quality input too (i.e. Keats); this isn't just the algorithms showing. I find it a good example that the converse of Garbage-in-garbage-out is true.
What surprised me about that particular poem was that it was actually better (IMHO) than something I could have written. I'm used to that in chess, but not in poetry. That's not a Turing test, but I'd argue its a pretty damn relevant test.
--LP
For a much better explanation of Kurzweil's views, see the transcript of a discussion with him in a CNN chat room last week.
--LP
that our understanding of physically how neural signalling works is growing exponentially, and
our ability to scan/sense neural behavior in the real world is growing exponentially.
I did not see any explicit quantization of these trends in the book. Instead, they flow out of larger principles or "laws" he describes (e.g. the law of accelerating returns, the law of evolutionary process, increasing returns on knowledge, etc.) He does point out an interesting fact noticed by several people that I hadn't heard -- that mechanical computing devices back to Hollerith's tabulator and the theoretical performance of Babbage's engine do fit on the Moore's Law curve extrapolated back to 1900-1910.
He does offer some interesting examples of where we are today based on his world-class work in pattern recognition and recapitulation. I found his book thought provoking, albeit not quite convincing, but then, I don't follow neurology closely enough to validate his core assumptions. Proof by handwaving, conjecture and story telling isn't my style, but then, the book wasn't really written for my style either. I'm also a little skeptical based on my undergrad course in AI and my experience in writing simulations of natural selection. He moved me from "it probably won't happen in my lifetime" to "it could happen" but not quite to "it will happen."
I will admit to being stunned by three lines in the book, a haiku written by one of his computer programs after reading John Keats and Wedy Dennis:
You broke my soul
the juice of eternity
the spirit of my lips.
--LP
Antibiotics (particularly penicillin) and water purification have added 30 years of life expectancy from 1900-2000. I can't think of a bigger payoff.
(Read this article for more details. While the life expectancy improvements are partially due to a reduction in infant deaths, there's a demonstrable improvement in disease treatment affecting all age groups whose magnitude you can see by looking at the raw data of life expectancy by age in the US. Of course other factors did help besides antibiotics, such as nutrition and pollution reduction.)
--LP
Hey, you know your stuff! Nice. :-) I could quibble on a couple things but I mostly agree. Let me skip to make a couple points and ask one question:
You don't need pretty graphs and clicking buttons to monitor a server, but they are nice.
1) *You* don't need graphs or buttons, but I submit to you that there are a huge number of people who do need them. Linux fails to cater to those people at its own elitist peril.
Interfaces dependant on recognition, not remembering, will have shorter learning curves. The power and flexibility brought by knowing a second language (UNIX) come with a price akin to learning a foreign language. Any OS that reduces the operational learning curve for admins (or power users or users) will yield an economic benefit that the market will reward.
2) If you think cluster scalability is a big deal in the enterprise, you might stop and consider why the big UNIX players and mainframes sell a lot more big SMP systems? Clusters are a lot cheaper to develop, but any database activity with lots of reads on clusters by definition slows to the bandwidth of your network (not your disk array or memory), (e.g. data warehousing, mining, other DB query apps) and the situation with write-intensive transaction processing provides contention and locking problems that are even worse. Sure, I agree that easily parallelized technical applications, DFS, and stateless webservers cluster are fine on Linux today. But we have to be better than everyone else on SMP to gain world domination.
Question: where did you get the "database performance such as SAP R3" results? SAP isn't a database, it runs on top of a database, and IIRC, the one Linux SAP benchmark I remember seeing was something like a Software Distribution benchmark which seemed to suggest more of a network than a database benchmark.
Maybe its just me, but I think if we can get Linux into enough database environments, it'll be around forever. If we get stuck in web/file/network serving, we can get pushed out by Microsoft marketing, tying and upper management. The bottleneck to more Linux DB deployments seems to be better failover software and high pricing for "trusted" databases. Scalability is a secondary but important issue here.
Enough talk.
Respectfully,
--LP
So, even though Win2000 is the slowest of the bunch (even slower than SCO's UNIXWare, according to this artile), it "Tops the field," but the benchmarks tell the true story. So, if you just skim the first few paragraphs of this article you'll walk away thinking Win2000 is the OS to beat. But by actually reading the article, you'll see the whole picture. Why do I think this is more of an advertisement for Win2000, than a serious article?
Because you don't seem to be willing to listen to the many weaknesses currently present in Linux that must be addressed if you want to claim superior technology. Lots of these are being worked on, but they aren't shipping yet. The GUI management interfaces in Linux aren't as good, neither are the performance monitoring tools which are woefully obscure. Red Hat Linux lacks ACLs which can accept/deny permissions to files on a per-user basis. Kerberos is a pain to learn about and install. Scalability still isn't great on the 2.2-based kernel series. The IP stack on the 2.2 kernel still isn't multithreaded. Storage management isn't that great without journalling filesystems which have been in the works on Linux for at least a year and have long been on NT. Distributions like RedHat aren't shipping ReiserFS as supported software AFAIK. The article and the associated scorecard show you the criteria and weightings.
(Is anyone doing GUI performance management tools, BTW? I've seen at least alpha code and efforts for everything else except that one...)
Would you trade all these things away to get 10-15% better file performance? I would.
There *are* things that Microsoft can't match (freedom, etc.) and we have to keep improving our ability to articulate those benfits of that, but technologically, Windows2000 does raise the bar for Linux to beat. We don't want to end up like Netscape, vaguely cooler but not as strong technically.
Less talk, better thinking, more good code.
--LinuxParanoid, paranoid for Linux's sake
Fair enough. Transmeta's pricing was pretty aggressive for notebook-oriented parts.
--LP
Perhaps Transmeta is an issue, but believe me, these price cuts have been in the works for a while and were planned to happen when Intel introduced it's SpeedStep technology. Intel always cuts prices on old stuff around the time it intros new stuff.
It does look like Transmeta found out the SpeedStep announcement date and scheduled their event the day before to preempt coverage of SpeedStep. That worked quite well, IMHO.
--LP
Hey, they may be obsolete, but I really like their www.stampsonline.com site for buying stamps online. I can pick the ones I want (unlike the local office) and shipping and handling is only $1! Try it once, it's cooler that you'd expect at first.
--LP
Actually, the problem with Staroffice is that it doesn't read lots of my office's Office95 files properly. Sure, Office2000 files work OK, most of the time, but I only have one machine with Office2000 and converting all my old docs to Office2000 would be a HUGE pain!
--LP
P.S. Your analysis that flash and sizzle always wins is clearly wrong. The Commodore64, Amiga, Mac all had more flash and sizzle than the lowly PC. But Wintel was actually useful both in work and at play. Good business apps and OK games won out over great games and OK business apps.
Due to some quirks of fate, Microsoft and Intel were at the right place at the right time to contribute to the IBM PC development effort, and customers in that era on balance cared more about making sure they knew the PC computer system at work than optimizing for the flashiest system at home. When faced with a choice, many (but not most) bought PCs. By steadily growing their flash and sizzle, Wintel managed to squeeze out PC competitors who had a harder time penetrating the corporate side of the PC business due to inherently fewer apps. Sustaining Wintel's at-birth application advantage was made possible by keeping backwards binary and file format compatibility.
Marketing didn't get Wintel where it is today. Its sold a lot of extra boxes, sure. But positioning (and good execution), not marketing was the decisive factor in ensuring Wintel's dominance. A position they gained at the birth of the IBM PC and a consistent effort afterwards to position themselves to best provide what the most customers most wanted.
To gain world domination, Linux has to overcome switching costs, and to do that, Linux will have to do a substantially better job of providing what the most customers most want than Microsoft. It's conceivable, but it won't be quick or easy. (Linux is almost 10 years old already.)
--LinuxParanoid, paranoid for Linux's sake
Not to mention that the smell of coins also reminds me of those stupid Microsoft NT client licenses-- constantly getting nickled and dimed to death!
;-)
--LP
Don't cringe too hard, your face might get stuck.
Whenever I deal with them, I feel like I'm getting nickled and dimed to death.
--LP
You know that smell you get when you've been handling lots of money? Dipping your hands in those jars full of coins, sorting, counting them out?
That's what I smell when I visit Microsoft's websites. Makes me want to wash my hands, every time...
--LP
You raise an interesting point. Open sourcing the CMS would make for some interesting market opportunities. But at the end of the day, I'm just not that the market for more instruction sets is that big. Do consumers or device designers want more instruction sets? As far as I can tell, the guys who like more instruction sets are the chip designers who want to lock in a community of software developers. And they are competitors of Transmeta; no point in them using Transmeta technology.
I suspect Transmeta will try to get vendors of existing instruction sets (SPARC, MIPS, Alpha) to license the CMS and build their own instruction sets off of Transmeta's. If, for example, Sun ever decided it couldn't keep up the SPARC speeds with Intel and Transmeta had a better shot at that, Transmeta's chips would make a nice migration; you could run both x86 and SPARC (and Java.) I'm sure that this has occured to Ditzel et al.
But then again, I don't buy the premise that Open Source is two orders of magnitude more productive than closed source. Lacking more rigorous analysis, NT began in October 1988, Linux began in 1991, and I don't think, good as it is, Linux is 100x better than NT. Over confidence in open source can be just as deadly as under confidence or incomprehension.
--LP
By integrating 3D, I meant integrating the whole 3D pipeline (think "integrating Nvidia's GeForce 256"), not just the CPU instructions like 3DNow or SSE which allow floating point vector processing for early stages of geometry transformations and lighting.
You point about suits and licensing of SSE is a valid one; it's not clear to me whether the lack of SSE so far is a technology development issue or a legal isse. Transmeta has added MMX (which is widely crosslicensed) but not yet added SSE. I'm no expert on this but the fab also may need a license; i.e. IBM may have a license to fab processors with MMX technology but not SSE?
--LP
Your points are fair ones. As I said in a reply to someone else, Transmeta has a shot at opening up a whole new category of low-power, low-cost "mobile internet" as they call it PCs.
To sum up my basic concern in a single sentence: I don't see enough barriers to entry to prevent Intel from crushing them in 3 years with a "good enough" power-optimized x86 solution. Does Transmeta have a strategy to deal with this?
--LP
I'm OK with most of what you say up until the last paragraph. 3D circuit design is a very complex beast. More complex than any other digital circuitry save CPUs, IMHO, and that's saying a lot. If you understood all the stages of the graphics pipeline and how they could be executed in parallel, you'd understand that it's a lot more complicated than saying you can "cache and optimize the 3D instructions."
If your "3D instructions" are SSE or 3DNow, sure I agree with you, but if you're talking about integrating and caching/optimizing the actual hardware geometry transformations and lighting code and various rasterization stages in a flexible programmable way, that's a huge multi-year architectural project. The difference in datapath design between CPU circuitry and 3D circuitry is enough to require wholly different sets of optimization techniques. It'd be easier to just slap a fixed 3D ASIC design in one corner of the chip, although once you're doing that, you're losing much of the benefits of the Transmeta approach. Plus there is analog circuitry such as the RAMDAC video output that presents additional not-major but not-trivial engineering complications for complete 2D or 3D integration.
--LP
Your points are fair ones. Transmeta has a shot at opening up a whole new category of low-power, low-cost "mobile internet" as they call it PCs.
To sum up my basic concern in a single sentence: I don't see enough barriers to entry to prevent Intel from crushing them in 3 years with a "good enough" power-optimized x86 solution. Does Transmeta have a strategy to deal with this?
--LP