Ah, but when was Linux's "conception" ?
on
Linux Turns 8
·
· Score: 2
So if Linux was born in 1991, does the development of the GNU tools in the mid-late 80s count as the act of conception?
(That labor took a lot longer than 9 months, eh?)
--LP
(Hmm, this fits better than I thought. It's true, the development of the GNU tools *was* an act of passion, right?... Reproduction of the asexual kind I suppose.;-)
And Windows NT is turning 11 next month...
on
Linux Turns 8
·
· Score: 3
Dave Cutler (Windows NT architect) went to work for M$ in October 1988.
Which raises the question: if Linux is growing so much faster than any other OS ever, how much worse/better is NT for being three years older?
Something to think about before you make the claim and the MS marketing team tries to shoot it down.
Are there two keys? Yes. However, both are Microsoft keys. We do not share them with any third party, including the National Security Agency or any other government agency.
Did anyone else notice the present tense used in this statement? "We do not share"? Not "we did not share" or "we have never shared..."
However, Microsoft holds these keys and does not share them with anyone, including the NSA.
Hmmm, same thing again. I wonder if MS is leaving itself a verbal out in case it is ever caught having once divulged the keys to the NSA. "At the time that statement was made, it was literally true." The old politian's art of deceiving without lying.
Or perhaps I'm just paranoid. Oh yeah, I am.
--LinuxParanoid
P.S. Further verbal obfuscation could be exploited by not specifying whether one was talking about the public key or the private key. Hmm, MS doesn't make that distinction in its written statement either. P.P.S. These statements are observations, not a conspiracy theory!
I know about L2 caches. I didn't discuss em since it takes so long to explain. I'm still not convinced they give the G4 what I'd consider to be a "significant win" in the primary target market for G4 boxes: power Photoshop users. Those users are typically dealing with files larger than 1 MB, the G4 L2 cache size. (Manipulating smaller files, for monitor or web display are irrelevant here: if the filter finishes in.25 or.05 seconds as happens with smaller files, it doesn't matter. If the photoshop filter takes 6 seconds vs. 2 seconds with G4, or 6 minutes vs. 2 minutes as happens with larger files, *that* would matter.)
So, barring a statistically relevant survey of power photoshop users and the file sizes they deal with, let's employ a geek's look at the problem set (warning: a little math, again!)
Premise: one must scan in and manipulate pixels at a higher dpi/color-depth than the output medium (print) in order to avoid lossy artifacts. Compress images only after all manipulation to avoid other artifacts.
So, if you scan in a modest sized 3x5" image at 300 dpi at 16-bit color, that's a 2.7 MB uncompressed file (3*300*5*300*16/8). Hmmm, larger than that 1 MB L2 cache, isn't it? (Don't forget, part of the L2 cache is filled with OS and Photoshop code too.) And this isn't the worst case; you could have images larger than a postcard or you may want true 24-bit color, or you may want to print at 300dpi and so you'll scan at 600dpi. (Less than 2x oversampling might leave interpolation artifacts.) A full 8.5x11"*600dpi*24bit worst case image hits 100 MB. That's what lots of RAM is for! Don't forget that you have to store both the source and the result of the filter; memory bandwidth must include both reads and writes. Write memory bandwidths are often worse than the more-publicized read specs.)
Lest someone jump on me again for exaggerating the case, sure, sometimes you can clip the image size early in the process to reduce overhead, or reduce sampling precision of images you only plan to use as backgrounds, but these aren't always feasible, and hey, aren't these all "hacks" you'd rather avoid spending your time on (if the computer was fast enough)?
It's still not clear to me that the G4 is really better than a Pentium III (Xeon, if at a comparable price) for power photoshop users.
And really, this haggling over how my math overlooked L2 caches still doesn't address the main point of my argument - the only claimed *performance* advantage over PCs, the G4 chip, is limited by other factors in the system such as memory bandwidth due to motherboard and memory controller design. (Peripherals are also equal, or worse on Macs.) We could discuss L2 bandwidths; perhaps Apple has a slight win here? Not clear- L2 bandwidth specs are hard to dig up, but both have L2 caches that are half the speed of the CPU clock (Xeons have full-speed caches), and both offer 1 MB L2 caches on $3K workstations(PIIIs are 512K, PIII Xeons are 512K/1/2MB.)
As for Apple's published benchmarks, I'd consider a broad, well-characterized set of benchmarks to be illuminating and enough to overturn my whole case, but without that, there are lots of ways to slant the playing field.
The fact that the G4 is 6.44x faster in "32 tap x 1024 dim. Convolution" benchmarks, even from Intel, isn't terribly relevant. Intel invented these benchmarks primarily to sell MMX over non-MMX machines; they don't necessarily represent real world usage patterns, either for everyday use or for power photoshop users. They are indicative of strong performance on something, that I'll grant you, but I find it slightly odd that Apple compared themselves against this highly obscure "Intel Signal Processing Library Performance Specification" and an undisclosed set of 10 photoshop filters on files of unknown size.
Why didn't Apple at least measure against Intel's Image Processing Library, a more relevant metric for photoshop-type users? Signal processing is nice for SETI@home, and it is related mathematically to image processing, but I just find Apple's benchmarketing fishy. Of course, Apple isn't the first to practice such benchmarketing, but hey, that doesn't mean we should fall for it.
Personally, I wish Apple the best, but I sure wouldn't invest in their stock or their machines on such flimsy evidence. Remember the skeptic's credo: extraordinary claims demand extraordinary evidence. I don't see it.
The 6.4 GB/sec memory bandwidth that feeds all this data into the CPU is 16x faster than Apple G4 systems' current 400 MB/sec and 8x faster than Apples "fast" 800 MB/sec motherboard coming out in a month or so. Fast memory bandwidth (and I/O bandwidth) is the difference between "supercomputer marketing" and a real supercomputer.
The G4's flops are totally bogus because you can't feed the CPUs at those rates, at least for reasonably sized datasets that overflow the L2 cache.
This is all "apples and oranges" comparisons of today's product versus futures though, and I'd agree that switching to Alpha would be a dumb move for Apple or Apple users.
Are you kidding? PixelFusion is a company making 3D graphics chips, not general purpose microprocessors.
Big difference. Parallel graphics logic circuits do not constitute a "processor." Many logic circuits computing in parallel is "parallel processing" but is not necessarily "hundreds of processors."
...putting aside the issue of which CPU (Pentium III or G4) is better at general purpose tasks (anything non-Photoshop, or non-signal procesing-related), true geeks recognize that even in "supercomputer" vector processing, the numbers don't quite add up to a significant win for the G4.
Let's take the 128-bit vector processing operations. Say, best case, you wanted to issue and execute one of those every clock cycle, at 500 MHz, that would require 128/8*500= 8,000 MByte/sec memory bandwidth. The Apple available today has 20x less!
Only 400 MB/sec (half that of today's PII/PIIIs). And next month they'll ship a better 800 MB/sec motherboard, matching today's PCs. Even if execution rates are one every two clocks, or one only uses 64-bit wide data, the 10x gap between chip horsepower and memory bandwidth remains the crucial performance-limiting bottleneck for vector processing operations.
If both PCs and Macs have equivalent memory bandwidths, and memory bandwidths are the single largest constraint on vector processing operations, how does the wider 128-bit circuitry in G4 yield a worthwhile advantage?
(Answer: a few tweaked benchmarks aside, it doesn't.)
Yours for a more educated, critical-thinking populace, LP
Compaq ProLiant 8000-550-2M (Pentium III Xeon 4 CPU 550 MHz 2 MB cache NT4SP4/MSSQL7.0) 26,560.40 Compaq ProLiant 8000-550-2M (Pentium III Xeon 8 CPU 550 MHz 2 MB cache NT4SP4/MSSQL7.0) 40,013.30
Of course with TPC-C, systems are obscenely expensive since they configure them with so much disk that the system won't be I/O bound. But this looks likely to be an NT marketing bullet. Prepare your responses now!
--LinuxParanoid (Hey, just because we're paranoid of Microsoft doesn't mean they're not out to get us...)
Why not have a number of journalists repeatedly ask Intel the question:
Would you publicly commit to not treating Asus any differently if they released an Athlon motherboard?
(This way, if the rumor is true, Intel has to back down publicly or admit that while its business practices are "ethical", they included treating Asus differently if they do the 'wrong' thing. If the rumor is false, Intel won't have any problem making such a public commitment, right?)
Call me paranoid (I do), but you're missing the real goal behind MS draining all the profits out of ISPs.
The target isn't AOL, it's Linux (and *BSD).
ISPs are the prime revenue base for Linux vendors, and the prime source of jobs for skilled Linux developers and admins. The death of ISPs (although still far from certain) would be a significant blow to the Linux community, wouldn't it?
--LinuxParanoid
P.S. So Linux had better keep extending its value into corporate environments...
I wish em luck (hey, variety is the spice of life), but I'm not too optimistic.
With 250+ Megapixel fillrates these days, more fillrate is nice but is not the key bottleneck. Remember that there are only 1.83 million pixels on a 1600x1200 screen. And Glaze3D's technological approach of using embedded RAM is not particularly unique (see PixelFusion or to a lesser extent, S3's Savage4). Also, in general, chips with embedded RAM get higher memory bandwidths, but are manufactured with processes in such a way that the logic is not as fast as with logic-optimized ASICs.
The key bottleneck is vertex geometry processing, and is constrained currently by the Intel CPU floating point, and to a lesser degree, by Intel's AGP bus and memory bus.
When Microsoft or Linux come out with 3D GUIs that require anisotropic texture filtering (and thus huge fillrates), then Glaze3D and similar chips will be more relevant. Potentially antialiasing (via accumulation or "T" buffers) and/or multi-pass rendering of shadows could be attractive enough features to drive demand for greater fillrates, but I suspect Bitboy's competitors (3dfx, Nvidia, etc.) will be "good enough" on that score.
Given the 720x600mm substrate, they conceivably could manufacture 16:9 ratio screens with a 16.25" diagonal (8"x14.2") at about the same cost as the slightly larger 4:3 ratio screens. (Four panels per substrate.)
I looked in to various filter products about six months ago. Be careful of your facts and assumptions. CyberPatrol can block by URL, IP, long-integer IP, and domain. As a concrete example, I recall at one point that they made it block some geocities porn sites but not all of geocities. Cyberpatrol's block list is also generated by hand, not automatically. It does not default to censoring automatically by finding bad-words in the URL/HTML/TCPIP stream. (It can be configured to do so, with a wordlist built by the customer, for those who want it, although that can obviously lead to various unintended automatic blockage of innocuous pages.)
So the problem isn't with CyberPatrol's technology, it's with a Cyberpatrol policy and/or employee's decision to filter the whole domain first, rather than poking through the domain and separating "OK" from "non-OK" content. So raise the ruckus with CyberPatrol for that.
In one of my less-paranoid, more-creative moments a few months ago I found myself thinking about Open Source and Linux -- that there might be some potential for the Linux platform enabled by FPGAs that I haven't seen described or pursued elsewhere.
Ask yourself the question: What is the fundamental architectural difference of an open source environment versus the traditional proprietary-binary environments of the last two decades? Are there any new assumptions in this new era that enable something different? Well, obviously now the OS and hardware can reasonably expect, if not mandate, access to the source code, not just the binary code.
Putting aside all the well-characterized FSF/Raymond reasoning for a sec., could you take advantage of this source-code availability to somehow build a faster, more efficient platform?
I've wondered whether this is indeed possible with FPGAs.
Since with FPGAs, you can actually configure the circuits to perform a specific algorithm which might be faster than performed by general-purpose circuitry, and since the FPGA can be programmed as often as needed by having a C compiler generate the appropriate netlist and send it to the FPGA, why not build a run-time Linux environment that on-the-fly recompiles the FPGA circuitry for the specific tasks (processes) being executed?
I've glossed over the various reasons why this isn't a cake-walk as anyone with FPGA expertise would realize, but I would be interested in an FPGA expert's assessment of either A) why this will never work, or B) what the top barriers to overcome would be. Is the gap between general purpose CPU clock rates and FPGA clock rates too great to ever realistically be surmounted in such a scheme? There's a big payoff for FPGA vendors if they could ever figure out how to make a competitive general-purpose platform; from an open source perspective, a platform that requires open source to deliver faster performance than Wintel would likewise be quite attractive.
So how does USPS's 198 billion snail mails compare to the volume of Internet email? This would be a good pointer to obsolence or relevance. Barring exact statistics (pointers anyone?), let's do a back-of-the-envelope estimate...
AOL has actually made public some figures for its corner of the Internet; I haven't seen much from other providers, so lets start with that.
AOL is currently claiming to deliver 200 million pieces of email a day. Grossly simplifying, that multiplies out to 73 billion emails a year.
The number of AOL users is 17 million. The number of Internet users, (in the U.S. only, since we're comparing against the US Postal service.) is around 100 million according to figures from Neilsen or MIDS. So AOL has 17% of the US Internet users.
Extrapolating, that implies that the total amount of email being sent is 429 billion pieces. So the Internet has doubled USPS traffic and is still growing, and at a fair pace faster than 3.7%.
USPS for messages is obsolete; for goods, it'll remain relevant.
A lot of SGI employees left SGI for Nvidia, which was one of the original reasons for the lawsuit; to intimidate Nvidia and put them on notice that they couldn't take SGI's intellectual property for granted.
However, it seems unlikely to me based on the public record that SGI had a strong case. I suspect the existing settlement is a fig-leaf partially designed to cover that.
For example, start by looking at the public parts of the deal -- patent cross-licensing. Nvidia has 12 patents currently (with others pending of course) listed on http://www.patents.ibm.com/, while SGI has 294. Who gets the better end of that bargain? It ain't the plantiff.
That said, there is room for fruitful technological co-operation. Nvidia guys can use all the tricks they learned at SGI (legally now), can potentially get access to Farenheit technology, and may be able to take advantage of SGI's brand name through some co-marketing of graphics hardware products. Certainly SGI would rather sell its flat panels hooked up to Nvidia graphics than Number Nine's, and vice versa. That's a slam dunk.
Other options are grander and much more speculative. For example, potentially, the two could collaborate on a scalable graphics architecture that uses multiple Nvidia chips for high-end graphics, something that is too expensive and distracting for Nvidia to pursue alone, but interesting for SGI if they can leverage low-cost high-performance parts to meet the needs of the market niches of their traditional customer base. Nvidia engineers, having worked on various SGI products including high-end Reality-class graphics would have a better idea than anybody else in the industry on exactly how to make this work (and what the limitations of this approach are.)
So IDC expects Linux to hit 40% of the server market by unit count by 2003, and Dataquest expects it to hit 8.1% of units (450K Linux units) by 2003. (Only 450K server units in 2003?)
The discrepancy is rather large here.
Explanations other than Dataquest/IDC wild-ass-guessing, anyone? Is there some other terminology or market definition difference between DQ and IDC for 'server OS units'?
Call me a cynic (after all, I am paranoid for Linux's sake), but MS is probably holding off on moving hotmail.com and homepages.msn.com to Win2000/IIS until the optimal marketing moment sometime during Win2000 rollout.
"See, we've dropped Apache and are moving to our super-reliable, super-scalable Windows2000 with IIS. And we're now making that same power to your company for just $200!*"
--LP
"* Terms and conditions may vary according to the license purchased."
Ever heard of hardware failure or application failure? The world doesn't revolve solely around OS stability you know... (And if you think your hardware is stable, try configuring it with a few GB of RAM...)
You overlooked what I think is the biggest reason companies have problems donating code to open source: legal reasons. I.e. the company licensed code or technology from several sources to make their product, and they do not own redistribution rights to that code.
I know for a fact this is a big problem at software vendors like SGI, IBM, etc. who must pay the cost of untangling dependencies of software they'd like to open-source from SVRx/BSD/OSF/other code they don't have redistribution rights to.
I suspect its also a lesser but still present issue at hardware vendors who have licensed pieces of technology from others (e.g. a 3D chip maker who has licensed S3's VGA boot code or 2D core, for example. They can't give away S3's software interface code or documentation.)
Solving this problem would definitely help the Linux community. Creative suggestions anyone?
Has anybody seen any indication of how many dots-per-inch this technology or other digital ink technologies are? I've never seen mention of this rather relevant fact.
Slashdot Mirror
So if Linux was born in 1991, does the development of the GNU tools in the mid-late 80s count as the act of conception?
... Reproduction of the asexual kind I suppose. ;-)
(That labor took a lot longer than 9 months, eh?)
--LP
(Hmm, this fits better than I thought. It's true, the development of the GNU tools *was* an act of passion, right?
Dave Cutler (Windows NT architect) went to work for M$ in October 1988.
Which raises the question: if Linux is growing so much faster than any other OS ever, how much worse/better is NT for being three years older?
Something to think about before you make the claim and the MS marketing team tries to shoot it down.
--LinuxParanoid
Are there two keys?
Yes. However, both are Microsoft keys. We do not share them with any third party, including the National Security Agency or any other government agency.
Did anyone else notice the present tense used in this statement? "We do not share"? Not "we did not share" or "we have never shared..."
However, Microsoft holds these keys and does not share them with anyone, including the NSA.
Hmmm, same thing again. I wonder if MS is leaving itself a verbal out in case it is ever caught having once divulged the keys to the NSA. "At the time that statement was made, it was literally true." The old politian's art of deceiving without lying.
Or perhaps I'm just paranoid.
Oh yeah, I am.
--LinuxParanoid
P.S. Further verbal obfuscation could be exploited by not specifying whether one was talking about the public key or the private key. Hmm, MS doesn't make that distinction in its written statement either.
P.P.S. These statements are observations, not a conspiracy theory!
I know about L2 caches. I didn't discuss em since it takes so long to explain. I'm still not convinced they give the G4 what I'd consider to be a "significant win" in the primary target market for G4 boxes: power Photoshop users. Those users are typically dealing with files larger than 1 MB, the G4 L2 cache size. (Manipulating smaller files, for monitor or web display are irrelevant here: if the filter finishes in .25 or .05 seconds as happens with smaller files, it doesn't matter. If the photoshop filter takes 6 seconds vs. 2 seconds with G4, or 6 minutes vs. 2 minutes as happens with larger files, *that* would matter.)
So, barring a statistically relevant survey of power photoshop users and the file sizes they deal with, let's employ a geek's look at the problem set (warning: a little math, again!)
Premise: one must scan in and manipulate pixels at a higher dpi/color-depth than the output medium (print) in order to avoid lossy artifacts. Compress images only after all manipulation to avoid other artifacts.
So, if you scan in a modest sized 3x5" image at 300 dpi at 16-bit color, that's a 2.7 MB uncompressed file (3*300*5*300*16/8). Hmmm, larger than that 1 MB L2 cache, isn't it? (Don't forget, part of the L2 cache is filled with OS and Photoshop code too.) And this isn't the worst case; you could have images larger than a postcard or you may want true 24-bit color, or you may want to print at 300dpi and so you'll scan at 600dpi. (Less than 2x oversampling might leave interpolation artifacts.) A full 8.5x11"*600dpi*24bit worst case image hits 100 MB. That's what lots of RAM is for! Don't forget that you have to store both the source and the result of the filter; memory bandwidth must include both reads and writes. Write memory bandwidths are often worse than the more-publicized read specs.)
Lest someone jump on me again for exaggerating the case, sure, sometimes you can clip the image size early in the process to reduce overhead, or reduce sampling precision of images you only plan to use as backgrounds, but these aren't always feasible, and hey, aren't these all "hacks" you'd rather avoid spending your time on (if the computer was fast enough)?
It's still not clear to me that the G4 is really better than a Pentium III (Xeon, if at a comparable price) for power photoshop users.
And really, this haggling over how my math overlooked L2 caches still doesn't address the main point of my argument - the only claimed *performance* advantage over PCs, the G4 chip, is limited by other factors in the system such as memory bandwidth due to motherboard and memory controller design. (Peripherals are also equal, or worse on Macs.) We could discuss L2 bandwidths; perhaps Apple has a slight win here? Not clear- L2 bandwidth specs are hard to dig up, but both have L2 caches that are half the speed of the CPU clock (Xeons have full-speed caches), and both offer 1 MB L2 caches on $3K workstations(PIIIs are 512K, PIII Xeons are 512K/1/2MB.)
As for Apple's published benchmarks, I'd consider a broad, well-characterized set of benchmarks to be illuminating and enough to overturn my whole case, but without that, there are lots of ways to slant the playing field.
The fact that the G4 is 6.44x faster in "32 tap x 1024 dim. Convolution" benchmarks, even from Intel, isn't terribly relevant. Intel invented these benchmarks primarily to sell MMX over non-MMX machines; they don't necessarily represent real world usage patterns, either for everyday use or for power photoshop users. They are indicative of strong performance on something, that I'll grant you, but I find it slightly odd that Apple compared themselves against this highly obscure "Intel Signal Processing Library Performance Specification" and an undisclosed set of 10 photoshop filters on files of unknown size.
Why didn't Apple at least measure against Intel's Image Processing Library, a more relevant metric for photoshop-type users? Signal processing is nice for SETI@home, and it is related mathematically to image processing, but I just find Apple's benchmarketing fishy. Of course, Apple isn't the first to practice such benchmarketing, but hey, that doesn't mean we should fall for it.
Personally, I wish Apple the best, but I sure wouldn't invest in their stock or their machines on such flimsy evidence. Remember the skeptic's credo: extraordinary claims demand extraordinary evidence. I don't see it.
Skeptically yours,
--LP
The 6.4 GB/sec memory bandwidth that feeds all this data into the CPU is 16x faster than Apple G4 systems' current 400 MB/sec and 8x faster than Apples "fast" 800 MB/sec motherboard coming out in a month or so. Fast memory bandwidth (and I/O bandwidth) is the difference between "supercomputer marketing" and a real supercomputer.
The G4's flops are totally bogus because you can't feed the CPUs at those rates, at least for reasonably sized datasets that overflow the L2 cache.
This is all "apples and oranges" comparisons of today's product versus futures though, and I'd agree that switching to Alpha would be a dumb move for Apple or Apple users.
--LP
Are you kidding? PixelFusion is a company making 3D graphics chips, not general purpose microprocessors.
Big difference. Parallel graphics logic circuits do not constitute a "processor." Many logic circuits computing in parallel is "parallel processing" but is not necessarily "hundreds of processors."
--LP
...putting aside the issue of which CPU (Pentium III or G4) is better at general purpose tasks (anything non-Photoshop, or non-signal procesing-related), true geeks recognize that even in "supercomputer" vector processing, the numbers don't quite add up to a significant win for the G4.
Let's take the 128-bit vector processing operations. Say, best case, you wanted to issue and execute one of those every clock cycle, at 500 MHz, that would require 128/8*500= 8,000 MByte/sec memory bandwidth. The Apple available today has 20x less!
Only 400 MB/sec (half that of today's PII/PIIIs). And next month they'll ship a better 800 MB/sec motherboard, matching today's PCs. Even if execution rates are one every two clocks, or one only uses 64-bit wide data, the 10x gap between chip horsepower and memory bandwidth remains the crucial performance-limiting bottleneck for vector processing operations.
If both PCs and Macs have equivalent memory bandwidths, and memory bandwidths are the single largest constraint on vector processing operations, how does the wider 128-bit circuitry in G4 yield a worthwhile advantage?
(Answer: a few tweaked benchmarks aside, it doesn't.)
Yours for a more educated, critical-thinking populace,
LP
that is, 50% improved performance on an online transaction processing benchmark when growing the number of processors by 100%:
/MSSQL7.0) 26,560.40 /MSSQL7.0) 40,013.30
Compaq ProLiant 8000-550-2M (Pentium III Xeon 4 CPU 550 MHz 2 MB cache NT4SP4
Compaq ProLiant 8000-550-2M (Pentium III Xeon 8 CPU 550 MHz 2 MB cache NT4SP4
Of course with TPC-C, systems are obscenely expensive since they configure them with so much disk that the system won't be I/O bound. But this looks likely to be an NT marketing bullet. Prepare your responses now!
--LinuxParanoid
(Hey, just because we're paranoid of Microsoft doesn't mean they're not out to get us...)
Why not have a number of journalists repeatedly ask Intel the question:
Would you publicly commit to not treating Asus any differently if they released an Athlon motherboard?
(This way, if the rumor is true, Intel has to back down publicly or admit that while its business practices are "ethical", they included treating Asus differently if they do the 'wrong' thing. If the rumor is false, Intel won't have any problem making such a public commitment, right?)
Just a thought.
--LP
Call me paranoid (I do), but you're missing the real goal behind MS draining all the profits out of ISPs.
The target isn't AOL, it's Linux (and *BSD).
ISPs are the prime revenue base for Linux vendors, and the prime source of jobs for skilled Linux developers and admins. The death of ISPs (although still far from certain) would be a significant blow to the Linux community, wouldn't it?
--LinuxParanoid
P.S. So Linux had better keep extending its value into corporate environments...
I wish em luck (hey, variety is the spice of life), but I'm not too optimistic.
With 250+ Megapixel fillrates these days, more fillrate is nice but is not the key bottleneck. Remember that there are only 1.83 million pixels on a 1600x1200 screen. And Glaze3D's technological approach of using embedded RAM is not particularly unique (see PixelFusion or to a lesser extent, S3's Savage4). Also, in general, chips with embedded RAM get higher memory bandwidths, but are manufactured with processes in such a way that the logic is not as fast as with logic-optimized ASICs.
The key bottleneck is vertex geometry processing, and is constrained currently by the Intel CPU floating point, and to a lesser degree, by Intel's AGP bus and memory bus.
When Microsoft or Linux come out with 3D GUIs that require anisotropic texture filtering (and thus huge fillrates), then Glaze3D and similar chips will be more relevant. Potentially antialiasing (via accumulation or "T" buffers) and/or multi-pass rendering of shadows could be attractive enough features to drive demand for greater fillrates, but I suspect Bitboy's competitors (3dfx, Nvidia, etc.) will be "good enough" on that score.
--LP
Given the 720x600mm substrate, they conceivably could manufacture 16:9 ratio screens with a 16.25" diagonal (8"x14.2") at about the same cost as the slightly larger 4:3 ratio screens. (Four panels per substrate.)
I looked in to various filter products about six months ago. Be careful of your facts and assumptions. CyberPatrol can block by URL, IP, long-integer IP, and domain. As a concrete example, I recall at one point that they made it block some geocities porn sites but not all of geocities. Cyberpatrol's block list is also generated by hand, not automatically. It does not default to censoring automatically by finding bad-words in the URL/HTML/TCPIP stream. (It can be configured to do so, with a wordlist built by the customer, for those who want it, although that can obviously lead to various unintended automatic blockage of innocuous pages.)
So the problem isn't with CyberPatrol's technology, it's with a Cyberpatrol policy and/or employee's decision to filter the whole domain first, rather than poking through the domain and separating "OK" from "non-OK" content. So raise the ruckus with CyberPatrol for that.
You can request that Cyberpatrol remove your page(s) from their blocked list at their website. I'd recommend trying that first.
In one of my less-paranoid, more-creative moments a few months ago I found myself thinking about Open Source and Linux -- that there might be some potential for the Linux platform enabled by FPGAs that I haven't seen described or pursued elsewhere.
Ask yourself the question: What is the fundamental architectural difference of an open source environment versus the traditional proprietary-binary environments of the last two decades? Are there any new assumptions in this new era that enable something different? Well, obviously now the OS and hardware can reasonably expect, if not mandate, access to the source code, not just the binary code.
Putting aside all the well-characterized FSF/Raymond reasoning for a sec., could you take advantage of this source-code availability to somehow build a faster, more efficient platform?
I've wondered whether this is indeed possible with FPGAs.
Since with FPGAs, you can actually configure the circuits to perform a specific algorithm which might be faster than performed by general-purpose circuitry, and since the FPGA can be programmed as often as needed by having a C compiler generate the appropriate netlist and send it to the FPGA, why not build a run-time Linux environment that on-the-fly recompiles the FPGA circuitry for the specific tasks (processes) being executed?
I've glossed over the various reasons why this isn't a cake-walk as anyone with FPGA expertise would realize, but I would be interested in an FPGA expert's assessment of either A) why this will never work, or B) what the top barriers to overcome would be. Is the gap between general purpose CPU clock rates and FPGA clock rates too great to ever realistically be surmounted in such a scheme? There's a big payoff for FPGA vendors if they could ever figure out how to make a competitive general-purpose platform; from an open source perspective, a platform that requires open source to deliver faster performance than Wintel would likewise be quite attractive.
--LP
So how does USPS's 198 billion snail mails compare to the volume of Internet email? This would be a good pointer to obsolence or relevance. Barring exact statistics (pointers anyone?), let's do a back-of-the-envelope estimate...
AOL has actually made public some figures for its corner of the Internet; I haven't seen much from other providers, so lets start with that.
AOL is currently claiming to deliver 200 million pieces of email a day. Grossly simplifying, that multiplies out to 73 billion emails a year.
The number of AOL users is 17 million. The number of Internet users, (in the U.S. only, since we're comparing against the US Postal service.) is around 100 million according to figures from Neilsen or MIDS. So AOL has 17% of the US Internet users.
Extrapolating, that implies that the total amount of email being sent is 429 billion pieces. So the Internet has doubled USPS traffic and is still growing, and at a fair pace faster than 3.7%.
USPS for messages is obsolete; for goods, it'll remain relevant.
--LP
A lot of SGI employees left SGI for Nvidia, which was one of the original reasons for the lawsuit; to intimidate Nvidia and put them on notice that they couldn't take SGI's intellectual property for granted.
However, it seems unlikely to me based on the public record that SGI had a strong case. I suspect the existing settlement is a fig-leaf partially designed to cover that.
For example, start by looking at the public parts of the deal -- patent cross-licensing. Nvidia has 12 patents currently (with others pending of course) listed on http://www.patents.ibm.com/, while SGI has 294. Who gets the better end of that bargain? It ain't the plantiff.
That said, there is room for fruitful technological co-operation. Nvidia guys can use all the tricks they learned at SGI (legally now), can potentially get access to Farenheit technology, and may be able to take advantage of SGI's brand name through some co-marketing of graphics hardware products. Certainly SGI would rather sell its flat panels hooked up to Nvidia graphics than Number Nine's, and vice versa. That's a slam dunk.
Other options are grander and much more speculative. For example, potentially, the two could collaborate on a scalable graphics architecture that uses multiple Nvidia chips for high-end graphics, something that is too expensive and distracting for Nvidia to pursue alone, but interesting for SGI if they can leverage low-cost high-performance parts to meet the needs of the market niches of their traditional customer base. Nvidia engineers, having worked on various SGI products including high-end Reality-class graphics would have a better idea than anybody else in the industry on exactly how to make this work (and what the limitations of this approach are.)
We'll see.
So IDC expects Linux to hit 40% of the server market by unit count by 2003, and Dataquest expects it to hit 8.1% of units (450K Linux units) by 2003. (Only 450K server units in 2003?)
The discrepancy is rather large here.
Explanations other than Dataquest/IDC wild-ass-guessing, anyone? Is there some other terminology or market definition difference between DQ and IDC for 'server OS units'?
Call me a cynic (after all, I am paranoid for Linux's sake), but MS is probably holding off on moving hotmail.com and homepages.msn.com to Win2000/IIS until the optimal marketing moment sometime during Win2000 rollout.
"See, we've dropped Apache and are moving to our super-reliable, super-scalable Windows2000 with IIS. And we're now making that same power to your company for just $200!*"
--LP
"* Terms and conditions may vary according to the license purchased."
Ever heard of hardware failure or application failure? The world doesn't revolve solely around OS stability you know... (And if you think your hardware is stable, try configuring it with a few GB of RAM...)
Nice piece.
You overlooked what I think is the biggest reason companies have problems donating code to open source: legal reasons. I.e. the company licensed code or technology from several sources to make their product, and they do not own redistribution rights to that code.
I know for a fact this is a big problem at software vendors like SGI, IBM, etc. who must pay the cost of untangling dependencies of software they'd like to open-source from SVRx/BSD/OSF/other code they don't have redistribution rights to.
I suspect its also a lesser but still present issue at hardware vendors who have licensed pieces of technology from others (e.g. a 3D chip maker who has licensed S3's VGA boot code or 2D core, for example. They can't give away S3's software interface code or documentation.)
Solving this problem would definitely help the Linux community. Creative suggestions anyone?
Has anybody seen any indication of how many dots-per-inch this technology or other digital ink technologies are? I've never seen mention of this rather relevant fact.