It's secure instant messaging, whether they realize it or not. It has all the draw backs and benefits of instant messaging as well (inefficient use of resources, instant delivery notification, doesn't work when they're off-line, etc.)
The stupid thing though is the implication that just because this isn't going through an intermediary server it's more secure than PGP. What a crock! It's still going through a ton of routers, any of which could be copying the contents for analysis. Indeed, the way Carnivore, from what I know, doesn't so much scan the mail store as scan mail traffic. Heck, there are going to be roughly 10 copies of the message made before it gets read!
Weblogic application server is available for Linux. It just happens to be the #1 selling EJB app server out there.
There are also open source C++ app servers out there which will outperform (and obviously out integrate since the source is right there) an MS solution. It's just that you have to be crazy (or Microsoft) to put all that effort into the solution when there are J2EE approaches which are much easier.
This is definitely what the standard UNIX approach is to these kind of solutions. Weblogic is an obvious choice because it's been supported on Linux for a while. You'll find these kinds of solutions actually work much better than their COM/MTS/ASP counterparts.
Alternatively, you can go the open source route with something like Enhydra. It's not as sophisticated (yet), but it has most of what people need.
Actually, in 2020, most patents in place today will have expired, and those that haven't will have their days numbered.
As a consequence, things like e-mail, TCP/IP, etc. that we do today should be protected. Of course, copyright is another insanity we would still have to deal with.
I can see it now, you're sitting in your seat, surfing over to cnn.com, and suddenly you see a web page announcing that the airport you're landing at is having massive electrical problems resulting in planes crashing left and right...;-)
There exists (final/draft?) a new ANSI Standard for Smalltalk. Many of the various 3rd party vendors (there is no primary vendor, analogous to Java's Sun) are moving toward ANSI support. There are many suppliers of Smalltalk systems.
Yup, there is the ANSI Standard for Smalltalk... how many decades after it's initial incarnation? and almost 10 years after Smalltalk had achieved a decent level of visibility in commerical circles. Too little too late. You also can't tell me that Smalltalk/MT and Visual Age are highly interoperable.
Just because it's possible, doesn't mean people do it. Most developers won't touch Core/System (as it came with the initial install), lest they screw everything up. The people that do generally know what they're doing, and where it makes a difference, and are wise enough to know whether or not to do it. Making your claim irrelevant.
Actually, it's been my experience that people do modify Object and Class in particular with great regularity. People also seem fond of hacking in changes to the events and exception systems. Even if they do know what they're doing it may have a subtle impact on a 3rd party library. More importantly, if you're a vendor of such a library, you have to allow for this possibility in your support model. This basically means having Smalltalk programmers on your support lines so they can evaluate changes to the image. Not exactly very cost effective.
Are you saying that it is your response to reject Smalltalk over Java, even though Smalltalk may have a more mature GC, simply because some LISP dialects may have a better GC?
Please try to read my entire statement. I was using the original posting's comments about GC as evidence of the strong NIH mentality that exists within the Smalltalk community. The gist of the argument had nothing to do with GC.
Don't get me wrong, from a technical standpoint I love Smalltalk and lament the fact that it was not more successful. I'm just trying to outline the non-technical problems which have prevented it's success.
Certainly Smalltalk has it's merits, but it also has it's shortcomings:
It lacks Java's interoperability guaruntees, limiting the ability of end users to choose among multiple 3rd party vendors
It does not define a stable runtime (developers can and generally do modify almost all the fundamentals of the system) making it hard for 3rd party vendors to sell add ons.
A direct corollary of the previous point is that Smalltalk developers constantly reinvent the wheel. When I work with a Smalltalk team, a good deal of design effort is spent on architectural domains like exceptions, transactions, persistence, etc. With Java, all that is already there. Sure, a group of excellent programmers designing an architecture for a specific purpose will likely produce something better than a general purpose API, but it is hard from a business standpoint to justify the effort.
A strong NIH mentality within the Smalltalk community. A good example was your GC argument. In fact, Smalltalk GC's lagged LISP GC's in much the same way that Java GC's have lagged Smalltalk.
Slow adoption of modern OS capabilities, in particular threading comes to mind. You might get one vendor adopting a particular capability, but you didn't have something uniform.
Too much proprietary effort. Companies have tried too hard to wring profits out of Smalltalk, and as a consequence squandered it's commercial viability.
Probably the biggest problem of Smalltalk though is that while it does a great job of leveraging an excellent programmer's work for a project, it also does an great job at leveraging the damage a beginning programmer can do. When Smalltalk DID get in the limelight, it didn't have enough excellent programmers around (and it takes a while to create more excellent programmers). While some companies are enlightened enough to focus on getting the top programmers, most are not (nor good they). This is where Java, Visual Basic and Delphi are much stronger than Smalltalk.
Wireless devices frequently go out of range. As a consequence communications are unreliable
A wide variety of devices. Wireless devices come in many shapes and forms. You need to adapt to these forms.
A wide variety of networks. This way you can access data regardless of the native network.
Limited bandwidth. We all know this one.;-)
Now, I'm going to explain how the breakthrough technology of IP (Internet Protocol) solves all these problems:
Reliability: IP was designed back in a time when even leased line connections were unreliable, let alone the computers that were linked up to them. I would argue modern wireless communications is not significantly more unreliable than wired communications were back in the early days of IP. Furthermore, HTTP was originally designed as a stateless protocol, and as such, most "web sessions" are persistent for a limited period of time. That's right, I can pull out my ethernet plug, wait for 10 minutes, plug it back in, and then bingo, my Dell shopping cart is still there!
Variety of devices: Considering how many different kinds of devices support IP and even the Web, it seems insane to me to suggest that IP-based technology doesn't already provide enough capability to get the job done. Indeed, XML/CSS/XSL/XSLT etc. are all designed to address this issue. Indeed, before HTML became bastardized it was supposed to address this issue. The only thing that has kept the Internet from supporting a wide variety of devices has been market forces, not technological limitations. Wireless communications will hopefully balance that out.
Wide variety of networks: The original intent of IP was to bridge together a wide variety of networks. As such, IP can already be embedded on top of (and used to bridge) DecNET, NetBIOS, IPX, etc.... even itself!.
Limited bandwidth: Wireless networks today typically have 14.4kbps bandwidth, and those numbers are expected to climb significantly in the years to come. When IP was first being developed 2400bps was a lot of bandwidth. So, don't tell me that IP can't be used in low bandwidth situations.
The WAP guys have developed a huge set of protocols and technologies that mimic their IP counterparts. They've done this seemingly without considering how to use or extend the existing IP protocols to support their needs. I think it's pretty clear why this is happening.
Right today I can get a 11Mbps wireless ethernet card from Dell for $139. If I get more than about 5 nodes, it will likely outperform a comperable 10baseT network. It includes 128-bit RC4 encryption at the media layer, to say nothing about what can be done at other layers. That is
already very good for a lot of scenarios (like
linking up my VCR to my TV).
How could, "coders haphazardly interconnecting disparate components without considering how they'll work together." not be considered a bad coding practice?
They insist that it be released under the GPL but that it also must be available as a QuickTime plug-in as well as a plug-in to all kinds of proprietary software?
I seem to recall there was some debate about GPL'd browser plug-ins, and I forget how the IANAL's sorted it out? Does anyone know if these plug-ins might violate the GPL?
I think that it is incorrect to suggest the power is going to the individual. New technologies introduce new capabilities which can be leveraged by any person/organization to their own benefit. For example, television provided power to corporations, politicians, and individuals who understood how to manipulate it. Some learned faster than others, some refined their skills more than others, but I disagree with the notion that technologies (particularly classes of technologies) have a bent in any particular direction.
Sure, the Internet is making it easier for someone to make one's voice heard and to gather information. However, as more and more information becomes digitized (and particularly since digital security is being repressed), it becomes increasingly easy for governments to rewrite history, control access to information, violate someone's privacy, and police a population. Business have unprecedented oppurtunities to control and spy on their employees, manage their public image, collude and organize to maximize how much they grab from customers.
Governments, as always, have been slow to learn the Internet, as they were with television. However, television is a good indicator of how they can eventually become quite skillful. I suspect the ultimate loser will be the general public, who in the long run tend not to master new technologies.
The major problem with Jini is how it has been marketed. Most of the answers to date talk about the problems using Jini for things like refridgerators and such. There's nothing about Jini that makes it an "appliance" technology. Despite Sun's marketing to the contrary, Jini is basically a mechanism for supporting dynamic, ad-hoc network applications.
The sad reality is Jini is actually an excellent technology for enterprise solutions (particularly web solutions). Imagine the benefits of having enterprise services which can be discovered and used automatically. This means that when a system gets loaded, you just deploy a new Jini-tized component, and the without any configuration changes, the software starts spreading the load over to that component.
Unfortunately, Sun didn't tout this aspect of Jini. Indeed, 90% of the people who know what Jini is think it's a technology for connecting network devices. That's a very limited and unproven market. I suspect Sun didn't want to let J2EE's image become confused by allowing Jini to move in to that space.
That in and of itself wouldn't have been a fatal blow, but on top of this was the licensing problem. Jini's license made it hard to deploy Jini solutions without paying Sun some money. Particularly given that the technology was far from perfect and still needs a several evolutions before it'd work right, 3rd parties weren't too interested in overcoming these problems just to see their solutions become Sun property which could be licensed to their competitors.
Finally, Sun's ability to corral vendors together was starting to wane just as Jini was introduced. Sun had been the standard bearer for the anti-Microsoft camp with their Java technology, but by the time Jini was being promoted Sun was already starting to get a negative image from how they were handling Java. It's hard for a single company to maintain the position that Sun had for the preceeding 3 or 4 years.
So, in summary, Jini was the right technology introduced by the wrong vendor, at the wrong time, in the wrong way, and targeted at the wrong market.:-(
Re:Java strong at the server, weak at the client
on
Java Rocks On Linux
·
· Score: 1
Most modern Java VM's use incremental, generational GC's that can execute in their own thread. As such, you should not have GUI freezes during a garbage collect. If you are having this problem, check your VM setup.
Swing does not provide a native GUI. If you want this, you should use AWT. Swing is meant to allow you to design your own look and feel (and btw, adding wheel mouse support to a look and feel isn't THAT hard).
Generally speaking, it's safe to say that the standard GUI libraries for Java are not as muture as one would like them to be. However, the language itself is quite well suited to building GUI applications, and really just needs to have the GUI libraries updated a bit more and it'll be pretty sweet.
Actually, Microsoft regularly buys back shares. They also do regular stock splits, but this doesn't raise any more money for the company. It's merely done to keep the price of a single share at a reasonable level. Regularly issuing new offerings devalues current stockholder value, which, btw, is the best way to get yourself fired.
My goof on the 2.5 weeks. This is, sadly, by a lot of standards still very good turn around. I have no idea the particularls as to why 2.5 weeks was needed, but I suspect someone at VA could explain it to you.
You comment about hardware on the other hand is absolutely rediculous. It presumes that a measurement of the quality of some hardware is whether a bug free driver has been committed to the Linux kernel. By those standards most of the new hardware that is being developed is "shitty".
A lot of VA's hardware is optimized for the server environment. In many cases there is specific hardware out there which provides benefits beyond other alternatives. If such hardware is not well supported by the standard Linux kernel but it's in VA's interest to use it, they will develop the necessary code themselves (this is, btw, how open source works). Many distributions are not focused in this direction (Mandrake has publicly stated they are focused on workstations) and don't want to add changes which haven't been committed into the Linus' kernel, or which they have not had the time to validate themselves (as well they should). Such is life.
I'm not sure why it was deemed necessary to install Mandrake on the server, but I'll assume it was necessary. Part of determining that it's necessary should involve recognizing that the circumstances which did happen COULD happen, and accepting that risk. If you really want to have Mandrake on the system, go to Mandrake's site and they'll point you to hardware vendors which sell systems with Mandrake pre-installed.
If you'd installed NT on the system and it hadn't worked, who would you be blaming? Who should you be blaming?
Mandrake doesn't run on all hardware, and VA has some special hardware that they add support for into the RedHat distribution. If you go without their software, you have to accept what you get.
As far as "delayed replacement" goes. 7 days isn't bad at all, particularly since VA is probably trying to figure out what their problem was in the first place.
The numbers he's using as the foundation for his story are not correct. He stupidly added the aggregated Linux score with the RedHat score, effectively counting RedHat vulnerabilities twice (no idea why he though he should add RedHat but not SuSE, debian, and Slackware...). Even so, the aggregated Linux score would not represent the total vulnerabilities on any single Linux system.
Of course, he didn't combine Win9X and WinNT scores. In fact, he skillfully ignored Win9X completely. Last time I checked, WinNT had like 150% the market share of Linux, while Win9X had some overwhelmingly huge market share.
Based on his assumption (and it's a gross assumption for sure) that detected-vulnerabilities-per-user is a measure of security, well then WinNT is at best a little more secure than the worst possible combination of Linux systems, while Win9X is overwhelmingly more secure than either. Of course, he couldn't mention this, because while he could pretend to pull the wool over everyone's eyes with some numbers that show WinNT is more secure than Linux, he couldn't possibly convince people that Win9X was more secure than WinNT. I guess he was afraid to demonstrate how insanse his assumptions were.
Actually, I'm not sure about this. I think Intel's biggest problem with these high-speed PIII's has been getting decent cache-memory yields. I could be wrong, but I think with the PIII design they can make the cache seperate from the CPU. Net result: higher yields (which Intel needs desperately).
Slashdot Mirror
VLIW is pretty close to software based CPU functions. It essentially pumps out the out-of-order execution and completion units to software.
Sure, Transmeta pushes out some more things out of CPU, but it's hard to argue it's a 5 year lead.
It's secure instant messaging, whether they realize it or not. It has all the draw backs and benefits of instant messaging as well (inefficient use of resources, instant delivery notification, doesn't work when they're off-line, etc.)
The stupid thing though is the implication that just because this isn't going through an intermediary server it's more secure than PGP. What a crock! It's still going through a ton of routers, any of which could be copying the contents for analysis. Indeed, the way Carnivore, from what I know, doesn't so much scan the mail store as scan mail traffic. Heck, there are going to be roughly 10 copies of the message made before it gets read!
Weblogic application server is available for Linux. It just happens to be the #1 selling EJB app server out there.
There are also open source C++ app servers out there which will outperform (and obviously out integrate since the source is right there) an MS solution. It's just that you have to be crazy (or Microsoft) to put all that effort into the solution when there are J2EE approaches which are much easier.
This is definitely what the standard UNIX approach is to these kind of solutions. Weblogic is an obvious choice because it's been supported on Linux for a while. You'll find these kinds of solutions actually work much better than their COM/MTS/ASP counterparts.
Alternatively, you can go the open source route with something like Enhydra. It's not as sophisticated (yet), but it has most of what people need.
Heck, my copy of this JUST shipped from Bookpool. Did Bruce's publisher send you an advanced copy or something? ;-)
Actually, in 2020, most patents in place today will have expired, and those that haven't will have their days numbered.
As a consequence, things like e-mail, TCP/IP, etc. that we do today should be protected. Of course, copyright is another insanity we would still have to deal with.
I can see it now, you're sitting in your seat, surfing over to cnn.com, and suddenly you see a web page announcing that the airport you're landing at is having massive electrical problems resulting in planes crashing left and right... ;-)
That's pretty funny. For integer math Perl is very slow, as internally it's doing all math using double-wide floating point.
There exists (final/draft?) a new ANSI Standard for Smalltalk. Many of the various 3rd party vendors (there is no primary vendor, analogous to Java's Sun) are moving toward ANSI support. There are many suppliers of Smalltalk systems.
Yup, there is the ANSI Standard for Smalltalk... how many decades after it's initial incarnation? and almost 10 years after Smalltalk had achieved a decent level of visibility in commerical circles. Too little too late. You also can't tell me that Smalltalk/MT and Visual Age are highly interoperable.
Just because it's possible, doesn't mean people do it. Most developers won't touch Core/System (as it came with the initial install), lest they screw everything up. The people that do generally know what they're doing, and where it makes a difference, and are wise enough to know whether or not to do it. Making your claim irrelevant.
Actually, it's been my experience that people do modify Object and Class in particular with great regularity. People also seem fond of hacking in changes to the events and exception systems. Even if they do know what they're doing it may have a subtle impact on a 3rd party library. More importantly, if you're a vendor of such a library, you have to allow for this possibility in your support model. This basically means having Smalltalk programmers on your support lines so they can evaluate changes to the image. Not exactly very cost effective.
Are you saying that it is your response to reject Smalltalk over Java, even though Smalltalk may have a more mature GC, simply because some LISP dialects may have a better GC?
Please try to read my entire statement. I was using the original posting's comments about GC as evidence of the strong NIH mentality that exists within the Smalltalk community. The gist of the argument had nothing to do with GC.
Don't get me wrong, from a technical standpoint I love Smalltalk and lament the fact that it was not more successful. I'm just trying to outline the non-technical problems which have prevented it's success.
This might actually be practical if you do it with a digital satellite receiver card, much like the DirecTiVo systems that are expected any week now.
Certainly Smalltalk has it's merits, but it also has it's shortcomings:
Probably the biggest problem of Smalltalk though is that while it does a great job of leveraging an excellent programmer's work for a project, it also does an great job at leveraging the damage a beginning programmer can do. When Smalltalk DID get in the limelight, it didn't have enough excellent programmers around (and it takes a while to create more excellent programmers). While some companies are enlightened enough to focus on getting the top programmers, most are not (nor good they). This is where Java, Visual Basic and Delphi are much stronger than Smalltalk.
Now, I'm going to explain how the breakthrough technology of IP (Internet Protocol) solves all these problems:
Reliability: IP was designed back in a time when even leased line connections were unreliable, let alone the computers that were linked up to them. I would argue modern wireless communications is not significantly more unreliable than wired communications were back in the early days of IP. Furthermore, HTTP was originally designed as a stateless protocol, and as such, most "web sessions" are persistent for a limited period of time. That's right, I can pull out my ethernet plug, wait for 10 minutes, plug it back in, and then bingo, my Dell shopping cart is still there!
Variety of devices: Considering how many different kinds of devices support IP and even the Web, it seems insane to me to suggest that IP-based technology doesn't already provide enough capability to get the job done. Indeed, XML/CSS/XSL/XSLT etc. are all designed to address this issue. Indeed, before HTML became bastardized it was supposed to address this issue. The only thing that has kept the Internet from supporting a wide variety of devices has been market forces, not technological limitations. Wireless communications will hopefully balance that out.
Wide variety of networks: The original intent of IP was to bridge together a wide variety of networks. As such, IP can already be embedded on top of (and used to bridge) DecNET, NetBIOS, IPX, etc.... even itself!.
Limited bandwidth: Wireless networks today typically have 14.4kbps bandwidth, and those numbers are expected to climb significantly in the years to come. When IP was first being developed 2400bps was a lot of bandwidth. So, don't tell me that IP can't be used in low bandwidth situations.
The WAP guys have developed a huge set of protocols and technologies that mimic their IP counterparts. They've done this seemingly without considering how to use or extend the existing IP protocols to support their needs. I think it's pretty clear why this is happening.
Right today I can get a 11Mbps wireless ethernet card from Dell for $139. If I get more than about 5 nodes, it will likely outperform a comperable 10baseT network. It includes 128-bit RC4 encryption at the media layer, to say nothing about what can be done at other layers. That is
already very good for a lot of scenarios (like
linking up my VCR to my TV).
How could, "coders haphazardly interconnecting disparate components without considering how they'll work together." not be considered a bad coding practice?
They insist that it be released under the GPL but that it also must be available as a QuickTime plug-in as well as a plug-in to all kinds of proprietary software?
I seem to recall there was some debate about GPL'd browser plug-ins, and I forget how the IANAL's sorted it out? Does anyone know if these plug-ins might violate the GPL?
I think that it is incorrect to suggest the power is going to the individual. New technologies introduce new capabilities which can be leveraged by any person/organization to their own benefit. For example, television provided power to corporations, politicians, and individuals who understood how to manipulate it. Some learned faster than others, some refined their skills more than others, but I disagree with the notion that technologies (particularly classes of technologies) have a bent in any particular direction.
Sure, the Internet is making it easier for someone to make one's voice heard and to gather information. However, as more and more information becomes digitized (and particularly since digital security is being repressed), it becomes increasingly easy for governments to rewrite history, control access to information, violate someone's privacy, and police a population. Business have unprecedented oppurtunities to control and spy on their employees, manage their public image, collude and organize to maximize how much they grab from customers.
Governments, as always, have been slow to learn the Internet, as they were with television. However, television is a good indicator of how they can eventually become quite skillful. I suspect the ultimate loser will be the general public, who in the long run tend not to master new technologies.
There are a number of filters out there for squid which do a fairly good job of blocking banner ads.
The major problem with Jini is how it has been marketed. Most of the answers to date talk about the problems using Jini for things like refridgerators and such. There's nothing about Jini that makes it an "appliance" technology. Despite Sun's marketing to the contrary, Jini is basically a mechanism for supporting dynamic, ad-hoc network applications.
:-(
The sad reality is Jini is actually an excellent technology for enterprise solutions (particularly web solutions). Imagine the benefits of having enterprise services which can be discovered and used automatically. This means that when a system gets loaded, you just deploy a new Jini-tized component, and the without any configuration changes, the software starts spreading the load over to that component.
Unfortunately, Sun didn't tout this aspect of Jini. Indeed, 90% of the people who know what Jini is think it's a technology for connecting network devices. That's a very limited and unproven market. I suspect Sun didn't want to let J2EE's image become confused by allowing Jini to move in to that space.
That in and of itself wouldn't have been a fatal blow, but on top of this was the licensing problem. Jini's license made it hard to deploy Jini solutions without paying Sun some money. Particularly given that the technology was far from perfect and still needs a several evolutions before it'd work right, 3rd parties weren't too interested in overcoming these problems just to see their solutions become Sun property which could be licensed to their competitors.
Finally, Sun's ability to corral vendors together was starting to wane just as Jini was introduced. Sun had been the standard bearer for the anti-Microsoft camp with their Java technology, but by the time Jini was being promoted Sun was already starting to get a negative image from how they were handling Java. It's hard for a single company to maintain the position that Sun had for the preceeding 3 or 4 years.
So, in summary, Jini was the right technology introduced by the wrong vendor, at the wrong time, in the wrong way, and targeted at the wrong market.
Most modern Java VM's use incremental, generational GC's that can execute in their own thread. As such, you should not have GUI freezes during a garbage collect. If you are having this problem, check your VM setup.
Swing does not provide a native GUI. If you want this, you should use AWT. Swing is meant to allow you to design your own look and feel (and btw, adding wheel mouse support to a look and feel isn't THAT hard).
Generally speaking, it's safe to say that the standard GUI libraries for Java are not as muture as one would like them to be. However, the language itself is quite well suited to building GUI applications, and really just needs to have the GUI libraries updated a bit more and it'll be pretty sweet.
Actually, Microsoft regularly buys back shares. They also do regular stock splits, but this doesn't raise any more money for the company. It's merely done to keep the price of a single share at a reasonable level. Regularly issuing new offerings devalues current stockholder value, which, btw, is the best way to get yourself fired.
My goof on the 2.5 weeks. This is, sadly, by a lot of standards still very good turn around. I have no idea the particularls as to why 2.5 weeks was needed, but I suspect someone at VA could explain it to you.
You comment about hardware on the other hand is absolutely rediculous. It presumes that a measurement of the quality of some hardware is whether a bug free driver has been committed to the Linux kernel. By those standards most of the new hardware that is being developed is "shitty".
A lot of VA's hardware is optimized for the server environment. In many cases there is specific hardware out there which provides benefits beyond other alternatives. If such hardware is not well supported by the standard Linux kernel but it's in VA's interest to use it, they will develop the necessary code themselves (this is, btw, how open source works). Many distributions are not focused in this direction (Mandrake has publicly stated they are focused on workstations) and don't want to add changes which haven't been committed into the Linus' kernel, or which they have not had the time to validate themselves (as well they should). Such is life.
I'm not sure why it was deemed necessary to install Mandrake on the server, but I'll assume it was necessary. Part of determining that it's necessary should involve recognizing that the circumstances which did happen COULD happen, and accepting that risk. If you really want to have Mandrake on the system, go to Mandrake's site and they'll point you to hardware vendors which sell systems with Mandrake pre-installed.
If you'd installed NT on the system and it hadn't worked, who would you be blaming? Who should you be blaming?
Mandrake doesn't run on all hardware, and VA has some special hardware that they add support for into the RedHat distribution. If you go without their software, you have to accept what you get.
As far as "delayed replacement" goes. 7 days isn't bad at all, particularly since VA is probably trying to figure out what their problem was in the first place.
Isn't an iPAQ a server appliance running NT?
The numbers he's using as the foundation for his story are not correct. He stupidly added the aggregated Linux score with the RedHat score, effectively counting RedHat vulnerabilities twice (no idea why he though he should add RedHat but not SuSE, debian, and Slackware...). Even so, the aggregated Linux score would not represent the total vulnerabilities on any single Linux system.
Of course, he didn't combine Win9X and WinNT scores. In fact, he skillfully ignored Win9X completely. Last time I checked, WinNT had like 150% the market share of Linux, while Win9X had some overwhelmingly huge market share.
Based on his assumption (and it's a gross assumption for sure) that detected-vulnerabilities-per-user is a measure of security, well then WinNT is at best a little more secure than the worst possible combination of Linux systems, while Win9X is overwhelmingly more secure than either. Of course, he couldn't mention this, because while he could pretend to pull the wool over everyone's eyes with some numbers that show WinNT is more secure than Linux, he couldn't possibly convince people that Win9X was more secure than WinNT. I guess he was afraid to demonstrate how insanse his assumptions were.
Actually, I'm not sure about this. I think Intel's biggest problem with these high-speed PIII's has been getting decent cache-memory yields. I could be wrong, but I think with the PIII design they can make the cache seperate from the CPU. Net result: higher yields (which Intel needs desperately).