The whole article made complete, complete sense. Until the final footnote.
[1] As an aside to the main discussion, one reason that the Beowulf clusters have been so dramatically successful is that it is a set of open source software that allows the replacement of proprietary closed mainframe hardware with standard PC components. The Beowulf thus delivers a double blow against proprietary competitors. It breaks the existing mainframe lock-in and it breaks software lock-ins.
What company/school idiot would use a mainframe for handling PVM/MPI technical computing jobs, even pre-Beowulf? Talk about the wrong tool for the wrong job! Mainframes today are used for backwards compatibility with old COBOL/REXX/JCL/etc. code and for certain larger commercial batch and transaction processing. Beowulf replacing RISC/UNIX technical servers, I could understand, but mainframes?
Name one company that has replaced a mainframe with Beowulf.
Eh, crud. What was wrong with me? You're right of course. NTFS hasn't had journalling. I think it does show up in Windows 2000. I'll go stand in the penalty box now. Serves me right for saying something nice about NT.;-)
It's one thing for a computer to pass a Turing test acting as a human. I think a more notable accomplishment, demonstrating that computers were really intelligent (and not just able to act like dumb average humans,) would be to get a dozen "5" posts on Slashdot in a two-week period.
What year are you expecting that?;-)
--LP
(So, between now and then, can *your* IRCbot get a 3 on Slashdot?)
...is that, as Bruce Schneier and a recent NYTimes article both point out, it re-introduces the problem of voter coercion that was eliminated by public, manned, polling places. In the polling booth, your vote is private, and public representatives can vouch for that fact. At home/work, others can buy or threaten you to vote a particular way and can watch to ensure that you follow-through.
--LinuxParanoid, apparently not just paranoid about Linux-related things;-)
NT has had a journaling filesystem called NTFS at least since Windows NT 3.51, released several years ago. Perhaps even since an earlier release; I don't remember that far back.
Your TCO points are well made, particularly the first one about registry corruption.
Under terms of the agreement, the intellectual property financed by Microsoft but done at M.I.T. will belong to M.I.T., but Microsoft will have the right to license it without paying royalties. But for research done jointly at Microsoft and M.I.T., Microsoft will have the first option to patent it.
So if MIT does the research, MS can license it. But do the terms of the MIT/MS agreement allow MIT to release the results of their efforts freely to other parties? Can MIT release resulting code under an open source license?
(Hint: if MIT doesn't say it can explicitly, MS probably wrote the contract tight enough that they can't... e.g. MIT can publish in results in academic journals but there are restrictions on the source code generated.)
Any explicit confirmation or denial of my paranoia appreciated.
100 mbps = 12.5 megabytes per second. PCI (standard 32-bit, 33 MHz) = 133 megabytes per second.
100 Mbps LAN speeds are comparable to today's 7200 RPM disks. Depending on the usage scenario, one is a more relevant bottleneck than the other, depending largely on how much data and code is stored locally in one's LAN environment. A full analysis of which usage scenarios this tradeoff affects is left as an exercise for the reader...
(Sorry, I was a little too hasty/estimatory with the math: the speedup over 6 MB/s CD-ROMs should be 167x, not 200x. Of course, C3D is claiming rates "exceeding 1 GB/s", but I probably should have fixed my comment before posting.)
Who cares about 150 GB capacity; we'll have that in a few years.
But I haven't heard *any* device manufacturer talking about speeds of 1 GByte/sec from a single device in any timeframe. Why not? Well, that's about 100x faster than today's hard disks (10 MB/sec is reasonable for most 7200 RPM disks, with some 10,000 RPMs getting up to 25 MB/sec peak performance.) And way faster today's optical media: a 40x CD-ROM is around 6 MB/sec peak, implying a 200x speed jump.
Now I can see how 10 layers might get you a quick 10x jump in capacity, and you could squeeze out another 3x over today's 5 GB DVD solutions if you were careful. But I don't see how 10 layers translates into a 200x speedup.
Neither PCI, SCSI, FC-AL, nor the IDE busses used for connecting disks to CPU/memory are built for 1 GByte/sec speeds, although Intel's future "System I/O" should handle it.
The transfer rate is so high, I'm strongly tempted to not believe any of it. Note that absolutely no timeframe is attached to the availability of the technology, a suspicious sign at best.
I would add to the previous poster's bullets that "CBRN" and "Cyber" threats are also different in the following ways:
Radically different logistics: terrorists face reduced logistical barriers to insertion/destruction: physical logistics takes on radically reduced importance when attacks can be relayed remotely over the global telecommunications infrastructure. Logistical-oriented defenses for detection and interception (e.g. borders) become largely irrelevant.
greater freedom of information: certain types of nuclear and biological expertise are closely guarded and narrowly disclosed, while attack tactics and strategies are much more widely available in online communities, largely in hopes of exposing infrastructure flaws so that they can get fixed.
reduced scarcity of precursors: while physical precursors to biological, chemical and nuclear materials can be controlled, at least to a limited extent, controls over precursor material useful for "Cyber" attacks is substantially less effective due to the fluidity of information flow (i.e. ease of dissemination) and availability of encryption for hiding information flows. Restricting information flows runs counter to the information-sharing process that has created existing technological (and economic) progress, not to mention raising problematic civil liberties issues. And restricting encryption technology exposes corporate interests to increased espionage vulnerabilities.
the shift into Intel consumerism where they did not have any competitive advantaged showed some very wooly thinking
They thought they did have some competitive advantage on the Intel platform, and technically speaking, they did, with their UMA architecture and strong texturing and video capabilities. However, SGI's woolly thinking since 1996 has been overlooking the fact that a differentiated product is not enough, you have to be differentiated in an area that adds significant value to a significantly large market.
(for the cognosti, there is nothing technically inferior about the MIPS architecture) I agree but this is pretty irrelevant. At the end of the day, it's all economics, and MIPS and other RISCs have steadily lost substantial price/performance ground to Intel, with no business model that ever made sense to regain it (i.e one amortizing both fab and multi-team design investments over relatively small volumes. Their embedded strategy overlooked the fact that volumes don't cut your high-end processor design costs.)
The engineers there (grossly generalizing here) got really excited about texture mapping but the bulk (40+%) of the workstation markets didn't need it very much -- CAD engineers wanted more polygons, not texture fillrate. Sun and HP paid more attention to CAD and stopped SGI's growth in its tracks. The texture-intensive "entertainment/digital content creation market" was growing from 10s of millions and never bulked up enough to help save SGI.
If you work for a company, you'd realise that the first law is survival which is depedent on their market relevance. I agree totally, and this is exactly what has been giving SGI such trouble. They've focused more on where they could do interesting cutting-edge differentiated things than on where they could be most relevant to the largest segment of customers.
In hindsight, their timing was just bad- they should have either gone NT a couple years earlier or held off till later (a la Sun). And they haven't to this day figured out how to reduce engineering cycle times for their products down to PC standards of 6-12 months for each new product, not 3-4 years.
I still wish em the best, but find it hard to put much hope in them at this point.
The compatiblity with MS Office is greatly exaggerated.
My anecdotal experience with interoperability highlights some significant limitations, primarily the limitation that StarOffice is more interoperable with Office2000 than previous Office95 or Office97 releases. I took a number of spreadsheets I use frequently and was unable to import any sort of chart from Excel95 into StarOffice (including pie, bar, scatter, and line charts.)
The point of spreadsheets and manipulating data is to A) understand what's going on and to B) cleanly and simply express what's going on to someone else. Thus charting constitutes about 50% of a spreadsheet program's value, a fact not reflected by Sun's 95%+ interoperability claims. (For those interested, Sun's precise interoperability claims are documented in hundreds of pages of documentation, mostly comparing to Office2000.)
The irony is that to get interoperability with StarOffice, such as ability to import Excel charts, corporations will have to first upgrade to Office2000 and save all files in that format before moving to StarOffice!
So I wouldn't spend too much time paying attention to StarOffice; it won't be giving MS problems any time soon (unfortunately for all our pocketbooks.) For offices/homes not needing such a conversion, I imagine it'll work fine, but currently poor compatibility will prevent it from harnessing network effects and getting a positive feedback loop going as an Office replacement. It's just cheap software.
I think Jim Davis of Apple computer put it well: "The [goal] of multimedia user interfaces is moving more toward the paradigm of the Mac, which is to recognize and point, and away from remember and type."
Or here to pick up Intel documentation on it here and here.
--LP
"One of the Internet's great ironies..."
on
Weaving The Web
·
· Score: 1
One of the Internet's great ironies is that it's grown so dramatically and remained so free primarily because none of the most powerful institutions in American life - government, journalism, business - paid it much attention in the first decades of its existence. It exploded before Congress, regulatory agencies, corporations, lawyers or the mass media had a chance to curb, control, exploit or acquire it.
So would you call that "security through obscurity?" That'd be even more ironic!;-)
The logical flaw you note can be explained as follows. Certain *types* of data compilation today have no incentive, while other types of compilation (as you point out) obviously do.
Currently, copyright is the main legal protection for collections of information, but is not sufficient to prevent people from copying your facts and changing the formatting/expression slightly. Instead, the main pragmatic protection today is to maintain an ever-increasing array of facts, keeping them up-to-date in the most timely manner reasonable order to increase barriers to entry. This is true of Yahoo, financial information, encyclopedias, etc.
Thus for content-compilation companies, without DB protection, it's really only worthwhile to compile certain types of data: the so-huge-its-hard-to-copy or updated-so-frequently-one-needs-many-collectors types of databases that provide non-legal pragmatic protection through barriers-to-entry.
Of course, this implies that DB protection has a downside too.
As a data compiler myself, I can tell you that if this law passes, it will *reduce* the incentives that data compilers have to keep their compilations up to date.
Currently, a content producer updates the content (and the user interface to the content) because A) the customer wants it, and B) to protect their business from copying-competitors.
If a database of facts becomes protected under law, half the incentive for keeping timely complete information disappears and companies will be more inclined to milk the customers of their existing information data-mines. As Reed-Elsevier and others realize, this will increase the underlying value of their core assets, since there is a significantly increased barrier to entry: facts in the databases will have to be re-acquired by upstart competitors, not just re-compiled. Not only do data-compiler asset values, go up, but customers of the data-compiler face the same barriers-to-entry of having to re-acquiring relevant facts themselves. Thus intrinsic value (the cash you can get out of a company if it stops operations today, discounted) of data-compilation companies goes up. When intrinsic values go up, data-compiler stocks thus go up.
It's all about barriers to entry. Food for thought.
--LP
Even nanotech not a problem with 128-bits...
on
CNN On IPv6
·
· Score: 1
...at least if you use a non-ethernet addressing scheme for those bottom 64 bits and get a full 128-bit space. I once wondered about whether nanotech would present problems for 128-bit addressing and did some back-of-the-envelope calculations to examine the issue. A little math to satisfy one's "what-if geek" tendencies:
That's surface area, but we live in a volumetric space; let's define that space as 1 km high above/below earth's land-mass(part of that 1km being underground, part being in the air.) Thus the volume of human space above/below land is 1.48*10^14 m3. With 10^6 cubic centimeters per cubic meter, and approximately 10^23 atoms per cubic centimeter, we get 1.48*10^43 atoms in our human-habitable slab of space on earth.
Now, how many IP addresses for that space? Well, 2^128 = 3.4*10^38th.
Ergo we have enough IP addresses for nanotech devices of 43,600 atoms each, in a human-habitable volume completely covering the land-mass of Earth and extending to fill a volume of space above and below the earth's surface for a full 1 km. Sure, you might get nanodevices smaller than that, but would they be independent enough and sensing/generating enough information to communicate via IP?
Well, if that isn't a problem for 128-bits, what is? Let's check a few other test cases that your friendly sci-fi reader might imagine...
Well, that was just land-mass. What if we filled the sea with nanodevices, would that exhaust it? The sea is 11km deep at worst, 3.8km on average. Water surface area is little over double land. Thus water basically requires a factor of 10x more devices. Given that you probably won't have more than 10% of the volume of any space being nanodevices (and this would seem to remain an extreme upper bound), this probably isn't an issue.
So what about interplanetary colonization? Still not too much of an issue for this solar system (ignoring the latency issues.) At least the first few planets (Mars/Venus/Mercury) which only add a factor of 3-4x expansion once 100% colonized form due to the roughly similar size of available nanodevice space on those planets as earth. True, a colonized Jupiter might pose problems down the line...
And if you used nanoprobes to fill/convert entire atmospheric systems, you end up covering a lot more volume (99% of earths' atmosphere fills approx 8.6*10^19 m3 by my calculations, five orders of magnitude more space than our 1 km slab.) Of course, any nanodevice design on that scale would probably use its own non-IP protocol.
Ah, but what other assumptions could be misleading us? For example, what is the efficiency of the 128-bit name space? Can we really use all those addresses? Well, I admit, I'm less an expert on this. The issue that Ethernet MACs will typically be your bottom 64-bits definitely chews up a lot of space, but if Ethernet doesn't make sense for nanodevices, we'll probably be using something else, or our self-assembling nanoprobes will build and configure themselves so that they share 1 higher-level IP but under the covers each have an colony-wide (not globally) unique ethernet address. How efficiently allocated is the rest of that (non-Ethernet) space? Well, I think CIDR-like tweaks can squeeze a fair amount out.
Still, even in the case where 128-bits isn't quite enough(!), I suspect reverting to NAT-type approaches in IPv6 will be workable. Certainly inter-stellar communications which will be limited to a relatively small number of transmitters will scale up with NATs for quite a while, assuming photon-based communications.;-)
So I suspect the 128-bit addressing scheme of IPv6 will last us at least another 200 years, not just "decades" as the IPv6 committee conservatively claims.
Of course, they probably know more weaknesses in that timeframe than I. Pretty hard to extrapolate out that far. For example, will the 4-bit header for IP version numbers be sufficient? Only 255 (8bit) hops? Who knows? Maybe IPv6's optional extension headers will even let us kludge around those issues.
Still, I think 128-bit IPv6 addressing will last us through nanotech and intra-planetary travel. Perhaps it will even last as long as our 4-digit field Y2K fixes!
I thought wordpad (not notepad) was a 3-5 line program in MFC; sort of a demo of what you could do with MFC. This would sort of be open source, in a perverse kinda way...
Before reading Kurzweil's "The Age of Spiritual Machines" last week, I would have totally agreed with you based on my undergraduate CS courses in AI. Now I still agree with you mostly but wouldn't make your "50 year" claim.
Kurzweil's argument is essentially that our understanding of neuron and brain function is reasonably far along and increasing geometrically (compounding like Moore's law, although Kurzweil doesn't single out a particular metric or rate.) He posits that our ability to model the physics/informatics of neurons and neurochemistry is sufficient to develop an understanding of "Real Intelligence" that will make "Artificial Intelligence" an implementation detail. You seem to agree we'll do this someday.
Kurzweil thinks we'll have the ability to do destructive brain-scans within 50 years (and hints at practical AI due to neurochemical understanding within 20-30 years.)
I haven't followed up on the research in his footnotes and am not familiar with the progress of neurological research findings and outstanding "hard" problems, but at a surface level, I still saw a lot of hand-waving. Thought provoking, but not convincing.
Are the UNIX companies using IA64 to slowly get out of the CPU business? or the hardware business in general? That would be an odd strategy because right now they're making most of their money off hardware, and that's where the main differentiation is right now.
As an industry analyst skimming/., the answer to your first question is "yes." The answer to your second question is "no, not quite." The UNIX vendors, most of whom have Intel product lines already in place, hope to replace their high-end SMP RISC servers with high-end SMP IA64 servers. They further have some assurance that Intel SMP will be limited to 4 or 8 processors in the short term and expect to have their own 16-64 way (potentially as high as 1024 way ccNUMA) systems on Merced and its IA-64 successors. This implies that the differentiation will be at the chipset, motherboard design and choice of server components level.
So why are they doing this? "If you can't beat 'em, join 'em)". For a long time, Intel narrowed the CPU performance gap and had a clear cost advantage due to volume economics. In December 1995, the release of the Pentium Pro marked the first Intel chip that outperformed all current RISC chips (save one clock-improved Alpha that had been announced a few weeks earlier) on the RISC chips' own benchmark: SPECint95. (SPECfp for RISC was better, but used in very few apps in essentially "niche" markets.) And obviously, Intel was selling these chips at $1000 and dropping fast, while high-performing RISC chips even internally cost $1000-$4000 just to manufacture, not to mention the design costs (say, $100M/year.)
Once it was clear that Intel chips were both faster and cheaper and that there was little or no chance of reversing this trend, and with the help of a lot of Intel/HP "post-RISC" hype, executives decided it was time to make the switch, put the RISCs on life-support and focus most of the future system efforts to IA-64 designs.
They're still hoping to sell high-end unique flagship servers, with relatively undifferentiated midrange and low-end servers that differ only in terms of the UNIX shipped (if that.)
If performance differences are under 10% between competing UNIXes, I don't think it'll make much difference to customers or vendors. There will likely be various types of lock-in and/or "optimization" on the hardware level, like different chipsets, boot (P)ROMs/service processors, that require support by their UNIX, as well as other hardware lockins you see today like varying "peak-performance" memory modules and unique voltage regulators for each CPU. Your "vendor X UNIX only runs on Vendor X Merced hardware" scenario is thus probably likely in the short term but not necessarily long term. Also, if all the UNIXes optimize to within 10%, that'll probably provide some nice optimization versus NT.
Your comment that Compaq/DEC might suspect Unix-on-Merced is a loser strategy (like NT-on-Intel was for DEC and SGI) is a decent hypothesis. Unix-on-Merced will make more sense for some UNIX vendors than others. Keep in mind that there are odder things than selling legacy hardware for years for decent margins. I heard a few years ago that $500M of PDP-11 compatibles were still being sold each year. Backwards compatibility is not a toy to trifle with in corporate America, where "it just works" means you don't have to. So far, Compaq has reiterated its commitment to Alpha and Tru64 at the high-end even with the new management (e.g. $100M marketing), without really giving some reassurance that its high-end only business model makes sense.
--Anon
Apples-to-apples: if it's not 11, it's 7.25...
on
Linux Turns 8
·
· Score: 1
Fair comment. At most though, this makes Linux look either six months older or NT look four years younger, as elucidated below, neither of which helps the Linux "case." On the Linux side, see one of the Linus-authored Linux history files around the net for a definitive discussion of Linux in 1991-1992. To summarize, even Linus doesn't remember or have records about exactly when the very first work occurred. But I've never seen any suggestion that he was working on it in 1990. It's clear that he had a few device drivers and the hard disk support in the kernel working in July 1991 and posted his first USENET request for POSIX specs around then. The first code release, a privately emailed notice of 0.01 source-only came in mid-September 1991 (hence the current 8th-year celebration.)
So back to your question, what are the comparisons for (a) start dates and (b) release dates for as close as you can get apples-to-apples comparisons? a) In terms of start dates, defined as "first work on the kernel", it's slightly pre-July 1991 for Linux and October 1988 for NT. 8-8.5 yrs (Linux) vs. 11 yrs (NT)
b) In terms of release dates, defined as first release to outside parties, this comes with Linux 0.01 in mid-Sept 1991 and with NT on July 5-6th 1992 according to my local NT guru. (For the pedantically challenged, note this is a Linux source release vs. NT binary release. For a "cleaner" apples-to-apples comparison, the first Linux binary release was on October 5, 1992.) In any case, that makes Linux older! 8 yrs (Linux) vs. 7.25 yrs (NT)
Other issues such as conceptual origin, DOS/VMS code and GNU/X code discussed elsewhere in this thread. Is the pedantic geek in you satisfied now?
--LinuxParanoid
"Those who do not know the past are doomed to repeat it" (or in this case, misinterpret it and act/fail-to-act based on resulting misperceptions.)
Re:Can't do that (was Re:And Windows NT is turn...
on
Linux Turns 8
·
· Score: 1
Totally agree (and would add that non-confirmed rumors suggest NT has some actual VMS code, too). I'd say DOS has always been less essential to NT than, say, bash or especially gcc+bash+XFree86, but this hardly merits quibbling over. If the DOS and GNU+X contributions cancel one another out, you could still make the comparison, but I don't pretend at all that it's a precise comparison.
I guess my point wasn't obvious enough for you. Let me try again.
I was pointing out that just as a baby undergoes development before it is born, so the first Linux distribution required a certain amount of development from GNU before it could be born, too.
Conceived has two meanings: "thought of", and "the genesis of a living being e.g. at the time the sperm and egg combine." I was referring to the latter definition when saying that the first GNU code (like a embryo's genetic code) constituted the true beginnings, the conception, of Linux, whereas Linus's kernel release on USENET constituted its birth, its first viable release to the outside world as a full OS.
Get it?
--LP
P.S. But of course, as with babies, the conception date of GNU contributions like gcc and bash and the GPL is too fuzzy (try getting a precise date for all three from gnu.org,) so we only celebrate the birth date.
Besides the "party line", which I'm sure we'll hear plenty about, what's really going on? Why so sudden? Which of the following options have come to pass?
1) NSA can factor prime numbers? 2) NSA/FBI finally gave in after the finalists for AES (successor to DES which they can brute-force) were announced since they can crack them all (and PGP, and RSA, and elliptic curve)? 3) The U.S. military has become so heavily dependent on TCP/IP that they need a secure infrastructure throughout the Internet. 4) NSA has developed effective nano-mites which effectively render all encryption obsolete via a physical side-channel attack? 5) Intel's microprocessor dominance is now assured. And the NSA has inserted a microcode hook (can you say, "mask technician?") in all Intel processors (cf Ken Thompson, "A well installed microcode bug will be almost impossible to detect.")
Reply with your speculative other options. Remember "only the paranoid survive."
Slashdot Mirror
The whole article made complete, complete sense.
Until the final footnote.
[1] As an aside to the main discussion, one reason that the Beowulf clusters have been so dramatically successful is that it is a set of open source software that allows the replacement of proprietary closed mainframe hardware with standard PC components. The Beowulf thus delivers a double blow against proprietary competitors. It breaks the existing mainframe lock-in and it breaks software lock-ins.
Beowulf clusters replacing mainframes?!
Beowulf clusters replacing mainframes?!?!
Beowulf clusters replacing mainframes?!?!?!
What company/school idiot would use a mainframe for handling PVM/MPI technical computing jobs, even pre-Beowulf? Talk about the wrong tool for the wrong job! Mainframes today are used for backwards compatibility with old COBOL/REXX/JCL/etc. code and for certain larger commercial batch and transaction processing. Beowulf replacing RISC/UNIX technical servers, I could understand, but mainframes?
Name one company that has replaced a mainframe with Beowulf.
Am I missing something here?
Weirded out,
--LP
Eh, crud. What was wrong with me? You're right of course. NTFS hasn't had journalling. I think it does show up in Windows 2000. I'll go stand in the penalty box now. Serves me right for saying something nice about NT. ;-)
--LP
It's one thing for a computer to pass a Turing test acting as a human. I think a more notable accomplishment, demonstrating that computers were really intelligent (and not just able to act like dumb average humans,) would be to get a dozen "5" posts on Slashdot in a two-week period.
;-)
What year are you expecting that?
--LP
(So, between now and then, can *your* IRCbot get a 3 on Slashdot?)
...is that, as Bruce Schneier and a recent NYTimes article both point out, it re-introduces the problem of voter coercion that was eliminated by public, manned, polling places. In the polling booth, your vote is private, and public representatives can vouch for that fact. At home/work, others can buy or threaten you to vote a particular way and can watch to ensure that you follow-through.
;-)
--LinuxParanoid, apparently not just paranoid about Linux-related things
NT has had a journaling filesystem called NTFS at least since Windows NT 3.51, released several years ago. Perhaps even since an earlier release; I don't remember that far back.
Your TCO points are well made, particularly the first one about registry corruption.
--LP
Under terms of the agreement, the intellectual property financed by Microsoft but done at M.I.T. will belong to M.I.T., but Microsoft will have the right to license it without paying royalties. But for research done jointly at Microsoft and M.I.T., Microsoft will have the first option to patent it.
So if MIT does the research, MS can license it. But do the terms of the MIT/MS agreement allow MIT to release the results of their efforts freely to other parties? Can MIT release resulting code under an open source license?
(Hint: if MIT doesn't say it can explicitly, MS probably wrote the contract tight enough that they can't... e.g. MIT can publish in results in academic journals but there are restrictions on the source code generated.)
Any explicit confirmation or denial of my paranoia appreciated.
--LinuxParanoid
100 mbps = 12.5 megabytes per second.
PCI (standard 32-bit, 33 MHz) = 133 megabytes per second.
100 Mbps LAN speeds are comparable to today's 7200 RPM disks. Depending on the usage scenario, one is a more relevant bottleneck than the other, depending largely on how much data and code is stored locally in one's LAN environment. A full analysis of which usage scenarios this tradeoff affects is left as an exercise for the reader...
--LP
I ntel
T ries
A lternate
N ame --
I t's
U nbelievable
M arketing!
(Sorry, I was a little too hasty/estimatory with the math: the speedup over 6 MB/s CD-ROMs should be 167x, not 200x. Of course, C3D is claiming rates "exceeding 1 GB/s", but I probably should have fixed my comment before posting.)
--LP
Who cares about 150 GB capacity; we'll have that in a few years.
But I haven't heard *any* device manufacturer talking about speeds of 1 GByte/sec from a single device in any timeframe. Why not? Well, that's about 100x faster than today's hard disks (10 MB/sec is reasonable for most 7200 RPM disks, with some 10,000 RPMs getting up to 25 MB/sec peak performance.) And way faster today's optical media: a 40x CD-ROM is around 6 MB/sec peak, implying a 200x speed jump.
Now I can see how 10 layers might get you a quick 10x jump in capacity, and you could squeeze out another 3x over today's 5 GB DVD solutions if you were careful. But I don't see how 10 layers translates into a 200x speedup.
Neither PCI, SCSI, FC-AL, nor the IDE busses used for connecting disks to CPU/memory are built for 1 GByte/sec speeds, although Intel's future "System I/O" should handle it.
The transfer rate is so high, I'm strongly tempted to not believe any of it. Note that absolutely no timeframe is attached to the availability of the technology, a suspicious sign at best.
Doubtfully yours,
--LP
I would add to the previous poster's bullets that "CBRN" and "Cyber" threats are also different in the following ways:
Radically different logistics: terrorists face reduced logistical barriers to insertion/destruction: physical logistics takes on radically reduced importance when attacks can be relayed remotely over the global telecommunications infrastructure. Logistical-oriented defenses for detection and interception (e.g. borders) become largely irrelevant.
greater freedom of information: certain types of nuclear and biological expertise are closely guarded and narrowly disclosed, while attack tactics and strategies are much more widely available in online communities, largely in hopes of exposing infrastructure flaws so that they can get fixed.
reduced scarcity of precursors: while physical precursors to biological, chemical and nuclear materials can be controlled, at least to a limited extent, controls over precursor material useful for "Cyber" attacks is substantially less effective due to the fluidity of information flow (i.e. ease of dissemination) and availability of encryption for hiding information flows. Restricting information flows runs counter to the information-sharing process that has created existing technological (and economic) progress, not to mention raising problematic civil liberties issues. And restricting encryption technology exposes corporate interests to increased espionage vulnerabilities.
--LP
the shift into Intel consumerism where they did not have any competitive advantaged showed some very wooly thinking
They thought they did have some competitive advantage on the Intel platform, and technically speaking, they did, with their UMA architecture and strong texturing and video capabilities. However, SGI's woolly thinking since 1996 has been overlooking the fact that a differentiated product is not enough, you have to be differentiated in an area that adds significant value to a significantly large market.
(for the cognosti, there is nothing technically inferior about the MIPS architecture)
I agree but this is pretty irrelevant. At the end of the day, it's all economics, and MIPS and other RISCs have steadily lost substantial price/performance ground to Intel, with no business model that ever made sense to regain it (i.e one amortizing both fab and multi-team design investments over relatively small volumes. Their embedded strategy overlooked the fact that volumes don't cut your high-end processor design costs.)
The engineers there (grossly generalizing here) got really excited about texture mapping but the bulk (40+%) of the workstation markets didn't need it very much -- CAD engineers wanted more polygons, not texture fillrate. Sun and HP paid more attention to CAD and stopped SGI's growth in its tracks. The texture-intensive "entertainment/digital content creation market" was growing from 10s of millions and never bulked up enough to help save SGI.
If you work for a company, you'd realise that the first law is survival which is depedent on their market relevance.
I agree totally, and this is exactly what has been giving SGI such trouble. They've focused more on where they could do interesting cutting-edge differentiated things than on where they could be most relevant to the largest segment of customers.
In hindsight, their timing was just bad- they should have either gone NT a couple years earlier or held off till later (a la Sun). And they haven't to this day figured out how to reduce engineering cycle times for their products down to PC standards of 6-12 months for each new product, not 3-4 years.
I still wish em the best, but find it hard to put much hope in them at this point.
--LP
The compatiblity with MS Office is greatly exaggerated.
My anecdotal experience with interoperability highlights some significant limitations, primarily the limitation that StarOffice is more interoperable with Office2000 than previous Office95 or Office97 releases. I took a number of spreadsheets I use frequently and was unable to import any sort of chart from Excel95 into StarOffice (including pie, bar, scatter, and line charts.)
The point of spreadsheets and manipulating data is to A) understand what's going on and to B) cleanly and simply express what's going on to someone else. Thus charting constitutes about 50% of a spreadsheet program's value, a fact not reflected by Sun's 95%+ interoperability claims. (For those interested, Sun's precise interoperability claims are documented in hundreds of pages of documentation, mostly comparing to Office2000.)
The irony is that to get interoperability with StarOffice, such as ability to import Excel charts, corporations will have to first upgrade to Office2000 and save all files in that format before moving to StarOffice!
So I wouldn't spend too much time paying attention to StarOffice; it won't be giving MS problems any time soon (unfortunately for all our pocketbooks.) For offices/homes not needing such a conversion, I imagine it'll work fine, but currently poor compatibility will prevent it from harnessing network effects and getting a positive feedback loop going as an Office replacement. It's just cheap software.
Sigh.
--LP
I think Jim Davis of Apple computer put it well:
"The [goal] of multimedia user interfaces is moving more toward the paradigm of the Mac, which is to recognize and point, and away from remember and type."
--LP
Analysis from InQuest, including Dell Office+Rambus benchmarks
A performance comparison of contemporary DRAM architectures. Vinodh Cuppu, Bruce Jacob, Brian Davis, and Trevor Mudge. Proc. 26th International Symposium on Computer Architecture
(ISCA-26), pp. 222-233. Atlanta GA, May 1999.
Or here to pick up Intel documentation on it here and here.
--LP
One of the Internet's great ironies is that it's grown so dramatically and remained so free primarily because none of the most powerful institutions in American life - government, journalism, business - paid it much attention in the first decades of its existence. It exploded before Congress, regulatory agencies, corporations, lawyers or the mass media had a chance to curb, control, exploit or acquire it.
;-)
So would you call that "security through obscurity?" That'd be even more ironic!
--LP
The logical flaw you note can be explained as follows. Certain *types* of data compilation today have no incentive, while other types of compilation (as you point out) obviously do.
Currently, copyright is the main legal protection for collections of information, but is not sufficient to prevent people from copying your facts and changing the formatting/expression slightly. Instead, the main pragmatic protection today is to maintain an ever-increasing array of facts, keeping them up-to-date in the most timely manner reasonable order to increase barriers to entry. This is true of Yahoo, financial information, encyclopedias, etc.
Thus for content-compilation companies, without DB protection, it's really only worthwhile to compile certain types of data: the so-huge-its-hard-to-copy or updated-so-frequently-one-needs-many-collectors types of databases that provide non-legal pragmatic protection through barriers-to-entry.
Of course, this implies that DB protection has a downside too.
As a data compiler myself, I can tell you that if this law passes, it will *reduce* the incentives that data compilers have to keep their compilations up to date.
Currently, a content producer updates the content (and the user interface to the content) because
A) the customer wants it, and
B) to protect their business from copying-competitors.
If a database of facts becomes protected under law, half the incentive for keeping timely complete information disappears and companies will be more inclined to milk the customers of their existing information data-mines. As Reed-Elsevier and others realize, this will increase the underlying value of their core assets, since there is a significantly increased barrier to entry: facts in the databases will have to be re-acquired by upstart competitors, not just re-compiled. Not only do data-compiler asset values, go up, but customers of the data-compiler face the same barriers-to-entry of having to re-acquiring relevant facts themselves. Thus intrinsic value (the cash you can get out of a company if it stops operations today, discounted) of data-compilation companies goes up. When intrinsic values go up, data-compiler stocks thus go up.
It's all about barriers to entry. Food for thought.
--LP
...at least if you use a non-ethernet addressing scheme for those bottom 64 bits and get a full 128-bit space. I once wondered about whether nanotech would present problems for 128-bit addressing and did some back-of-the-envelope calculations to examine the issue. A little math to satisfy one's "what-if geek" tendencies:
;-)
;-)
earth's surface area = 5.099*10^11 m2
earth's land area = 1.4835*10^11 m2
That's surface area, but we live in a volumetric space; let's define that space as 1 km high above/below earth's land-mass(part of that 1km being underground, part being in the air.) Thus the volume of human space above/below land is 1.48*10^14 m3. With 10^6 cubic centimeters per cubic meter, and approximately 10^23 atoms per cubic centimeter, we get 1.48*10^43 atoms in our human-habitable slab of space on earth.
Now, how many IP addresses for that space? Well, 2^128 = 3.4*10^38th.
Ergo we have enough IP addresses for nanotech devices of 43,600 atoms each, in a human-habitable volume completely covering the land-mass of Earth and extending to fill a volume of space above and below the earth's surface for a full 1 km. Sure, you might get nanodevices smaller than that, but would they be independent enough and sensing/generating enough information to communicate via IP?
Well, if that isn't a problem for 128-bits, what is? Let's check a few other test cases that your friendly sci-fi reader might imagine...
Well, that was just land-mass. What if we filled the sea with nanodevices, would that exhaust it?
The sea is 11km deep at worst, 3.8km on average. Water surface area is little over double land. Thus water basically requires a factor of 10x more devices. Given that you probably won't have more than 10% of the volume of any space being nanodevices (and this would seem to remain an extreme upper bound), this probably isn't an issue.
So what about interplanetary colonization? Still not too much of an issue for this solar system (ignoring the latency issues.) At least the first few planets (Mars/Venus/Mercury) which only add a factor of 3-4x expansion once 100% colonized form due to the roughly similar size of available nanodevice space on those planets as earth. True, a colonized Jupiter might pose problems down the line...
And if you used nanoprobes to fill/convert entire atmospheric systems, you end up covering a lot more volume (99% of earths' atmosphere fills approx 8.6*10^19 m3 by my calculations, five orders of magnitude more space than our 1 km slab.) Of course, any nanodevice design on that scale would probably use its own non-IP protocol.
Ah, but what other assumptions could be misleading us? For example, what is the efficiency of the 128-bit name space? Can we really use all those addresses? Well, I admit, I'm less an expert on this. The issue that Ethernet MACs will typically be your bottom 64-bits definitely chews up a lot of space, but if Ethernet doesn't make sense for nanodevices, we'll probably be using something else, or our self-assembling nanoprobes will build and configure themselves so that they share 1 higher-level IP but under the covers each have an colony-wide (not globally) unique ethernet address. How efficiently allocated is the rest of that (non-Ethernet) space? Well, I think CIDR-like tweaks can squeeze a fair amount out.
Still, even in the case where 128-bits isn't quite enough(!), I suspect reverting to NAT-type approaches in IPv6 will be workable. Certainly inter-stellar communications which will be limited to a relatively small number of transmitters will scale up with NATs for quite a while, assuming photon-based communications.
So I suspect the 128-bit addressing scheme of IPv6 will last us at least another 200 years, not just "decades" as the IPv6 committee conservatively claims.
Of course, they probably know more weaknesses in that timeframe than I. Pretty hard to extrapolate out that far. For example, will the 4-bit header for IP version numbers be sufficient? Only 255 (8bit) hops? Who knows? Maybe IPv6's optional extension headers will even let us kludge around those issues.
Still, I think 128-bit IPv6 addressing will last us through nanotech and intra-planetary travel. Perhaps it will even last as long as our 4-digit field Y2K fixes!
--LP
I thought wordpad (not notepad) was a 3-5 line program in MFC; sort of a demo of what you could do with MFC. This would sort of be open source, in a perverse kinda way...
--LP
Before reading Kurzweil's "The Age of Spiritual Machines" last week, I would have totally agreed with you based on my undergraduate CS courses in AI. Now I still agree with you mostly but wouldn't make your "50 year" claim.
Kurzweil's argument is essentially that our understanding of neuron and brain function is reasonably far along and increasing geometrically (compounding like Moore's law, although Kurzweil doesn't single out a particular metric or rate.) He posits that our ability to model the physics/informatics of neurons and neurochemistry is sufficient to develop an understanding of "Real Intelligence" that will make "Artificial Intelligence" an implementation detail. You seem to agree we'll do this someday.
Kurzweil thinks we'll have the ability to do destructive brain-scans within 50 years (and hints at practical AI due to neurochemical understanding within 20-30 years.)
I haven't followed up on the research in his footnotes and am not familiar with the progress of neurological research findings and outstanding "hard" problems, but at a surface level, I still saw a lot of hand-waving. Thought provoking, but not convincing.
--LP
Are the UNIX companies using IA64 to slowly get out of the CPU business? or the hardware business in general? That would be an odd strategy because right now they're making most of their money off hardware, and that's where the main differentiation is right now.
/., the answer to your first question is "yes." The answer to your second question is "no, not quite." The UNIX vendors, most of whom have Intel product lines already in place, hope to replace their high-end SMP RISC servers with high-end SMP IA64 servers. They further have some assurance that Intel SMP will be limited to 4 or 8 processors in the short term and expect to have their own 16-64 way (potentially as high as 1024 way ccNUMA) systems on Merced and its IA-64 successors. This implies that the differentiation will be at the chipset, motherboard design and choice of server components level.
As an industry analyst skimming
So why are they doing this? "If you can't beat 'em, join 'em)". For a long time, Intel narrowed the CPU performance gap and had a clear cost advantage due to volume economics. In December 1995, the release of the Pentium Pro marked the first Intel chip that outperformed all current RISC chips (save one clock-improved Alpha that had been announced a few weeks earlier) on the RISC chips' own benchmark: SPECint95. (SPECfp for RISC was better, but used in very few apps in essentially "niche" markets.) And obviously, Intel was selling these chips at $1000 and dropping fast, while high-performing RISC chips even internally cost $1000-$4000 just to manufacture, not to mention the design costs (say, $100M/year.)
Once it was clear that Intel chips were both faster and cheaper and that there was little or no chance of reversing this trend, and with the help of a lot of Intel/HP "post-RISC" hype, executives decided it was time to make the switch, put the RISCs on life-support and focus most of the future system efforts to IA-64 designs.
They're still hoping to sell high-end unique flagship servers, with relatively undifferentiated midrange and low-end servers that differ only in terms of the UNIX shipped (if that.)
If performance differences are under 10% between competing UNIXes, I don't think it'll make much difference to customers or vendors. There will likely be various types of lock-in and/or "optimization" on the hardware level, like different chipsets, boot (P)ROMs/service processors, that require support by their UNIX, as well as other hardware lockins you see today like varying "peak-performance" memory modules and unique voltage regulators for each CPU. Your "vendor X UNIX only runs on Vendor X Merced hardware" scenario is thus probably likely in the short term but not necessarily long term. Also, if all the UNIXes optimize to within 10%, that'll probably provide some nice optimization versus NT.
Your comment that Compaq/DEC might suspect Unix-on-Merced is a loser strategy (like NT-on-Intel was for DEC and SGI) is a decent hypothesis. Unix-on-Merced will make more sense for some UNIX vendors than others. Keep in mind that there are odder things than selling legacy hardware for years for decent margins. I heard a few years ago that $500M of PDP-11 compatibles were still being sold each year. Backwards compatibility is not a toy to trifle with in corporate America, where "it just works" means you don't have to. So far, Compaq has reiterated its commitment to Alpha and Tru64 at the high-end even with the new management (e.g. $100M marketing), without really giving some reassurance that its high-end only business model makes sense.
--Anon
Fair comment. At most though, this makes Linux look either six months older or NT look four years younger, as elucidated below, neither of which helps the Linux "case." On the Linux side, see one of the Linus-authored Linux history files around the net for a definitive discussion of Linux in 1991-1992. To summarize, even Linus doesn't remember or have records about exactly when the very first work occurred. But I've never seen any suggestion that he was working on it in 1990. It's clear that he had a few device drivers and the hard disk support in the kernel working in July 1991 and posted his first USENET request for POSIX specs around then. The first code release, a privately emailed notice of 0.01 source-only came in mid-September 1991 (hence the current 8th-year celebration.)
So back to your question, what are the comparisons for (a) start dates and (b) release dates for as close as you can get apples-to-apples comparisons?
a) In terms of start dates, defined as "first work on the kernel", it's slightly pre-July 1991 for Linux and October 1988 for NT. 8-8.5 yrs (Linux) vs. 11 yrs (NT)
b) In terms of release dates, defined as first release to outside parties, this comes with Linux 0.01 in mid-Sept 1991 and with NT on July 5-6th 1992 according to my local NT guru. (For the pedantically challenged, note this is a Linux source release vs. NT binary release. For a "cleaner" apples-to-apples comparison, the first Linux binary release was on October 5, 1992.) In any case, that makes Linux older! 8 yrs (Linux) vs. 7.25 yrs (NT)
Other issues such as conceptual origin, DOS/VMS code and GNU/X code discussed elsewhere in this thread. Is the pedantic geek in you satisfied now?
--LinuxParanoid
"Those who do not know the past are doomed to repeat it" (or in this case, misinterpret it and act/fail-to-act based on resulting misperceptions.)
Totally agree (and would add that non-confirmed rumors suggest NT has some actual VMS code, too). I'd say DOS has always been less essential to NT than, say, bash or especially gcc+bash+XFree86, but this hardly merits quibbling over. If the DOS and GNU+X contributions cancel one another out, you could still make the comparison, but I don't pretend at all that it's a precise comparison.
--LP
I guess my point wasn't obvious enough for you. Let me try again.
I was pointing out that just as a baby undergoes development before it is born, so the first Linux distribution required a certain amount of development from GNU before it could be born, too.
Conceived has two meanings: "thought of", and "the genesis of a living being e.g. at the time the sperm and egg combine." I was referring to the latter definition when saying that the first GNU code (like a embryo's genetic code) constituted the true beginnings, the conception, of Linux, whereas Linus's kernel release on USENET constituted its birth, its first viable release to the outside world as a full OS.
Get it?
--LP
P.S. But of course, as with babies, the conception date of GNU contributions like gcc and bash and the GPL is too fuzzy (try getting a precise date for all three from gnu.org,) so we only celebrate the birth date.
Besides the "party line", which I'm sure we'll hear plenty about, what's really going on? Why so sudden? Which of the following options have come to pass?
1) NSA can factor prime numbers?
2) NSA/FBI finally gave in after the finalists for AES (successor to DES which they can brute-force) were announced since they can crack them all (and PGP, and RSA, and elliptic curve)?
3) The U.S. military has become so heavily dependent on TCP/IP that they need a secure infrastructure throughout the Internet.
4) NSA has developed effective nano-mites which effectively render all encryption obsolete via a physical side-channel attack?
5) Intel's microprocessor dominance is now assured. And the NSA has inserted a microcode hook (can you say, "mask technician?") in all Intel processors (cf Ken Thompson, "A well installed microcode bug will be almost impossible to detect.")
Reply with your speculative other options. Remember "only the paranoid survive."
--LinuxParanoid