I'm not sure how, but I am sure somehow the MPAA will construe this as a violation of artists' rights and a violation of copyright and the American way.
The qualifier "Linux" is quite necessary. What a typical UNIX/Linux user considers a "good application" differs greatly from what a typical Windows user considers a "good application". Windows is trying to address mostly the unskilled mass-market, while UNIX/Linux addresses skilled programmers, scientists, and engineers.
I'm really tired of this one-size-fits-all attitude. That's Microsoft-think. If I wanted to use Windows, I'd just be using Windows--God knows, I have already paid for it. The reason to use UNIX/Linux is that it is different and that its applications are different. Turning Linux into a "free" version of Windows is pointless as far as I'm concerned.
Your reasoning is faulty. Just because there are some hard real-time applications (real-time music synthesis) doesn't mean that all audio applications need to be monolithic GUI programs. Pipes are fine for playing, recording, filtering, and other audio applications. And even hard real-time applications can be built from command line components that communicate via shared memory or that manipulate loadable components in a core process. The monolithic Windows way is not the only way, and certainly not the best way, of writing either non-real-time or real-time applications, for audio or anything else.
Seriously, a lot of Linux applications try to duplicate the Windows world and end up being just as bad. For example, for audio software, a monolithic executable with GUI is a Windows-style application--hard to reuse, hard to extend. A bunch of command line applications that can be piped together and come with a simple scripted GUI, that's a good Linux application because its bits and pieces can actually be reused.
Park's comment is valid and to the point. Your comment about the energy coming from the disk or the field essentially is saying that there is no Effect (a null result).
I'm sorry, run that by me again? If they succeed at reducing the gravitational mass of an object but it requires expenditure of energy, you'd consider that a "null result"? I suppose next thing you are going to tell me is that electrostatic repulsion doesn't exist because moving the charges to measure it requires expenditure of energy.
2.6 Million bucks is a lot of money. It can fund many, many, many more real projects. Instead, it gone thrown into an unsubstantiated, non-peer-reviewed crackpottery by a guy who refuses to reveal the details of his so-called experiment.
Frankly, given the kind of uninspired, peer-reviewed, publicity-hungry junk I come across daily, I'm glad to see that some people are still spending money on long-shots and crackpots. If science were exclusively done by what one's peers think useful or interesting, we'd still be living in the stone age. I think this particular experiment is a long-shot, and after $2.6M it may really be time to start looking elsewhere. But, then, I think it's much less of a long-shot than the kind of nonsense theorists have been engaging in.
And it's not like the idea that there is something funny going on with gravity were completely unfounded. We know that Einstein's theory disagrees grossly with what we observe. It's not a question of if we can replicate this experimentally but how.
While I think it's unlikely the phenomenon is real, Bob Park's commentary on it is an unwarranted and unfounded attack. There is no reason whatsoever to believe that the effect would violate the "First Law"--the energy might come from the disk or the field.
While basic Java runs fairly well across platforms, once you start getting into issues like audio, images, video, window management, drag-and-drop, etc., Java fails to work well cross-platform in my experience. Even something as simple as Forte-for-Java's window placement fails in annoying ways on Linux. Java3D is eclipsed by third party OpenGL bindings. Sun seems to try to make all their libraries work on Windows, but on MacOS and Linux, it's hit-and-miss. Sun has also been promising for years, but so far not delivered, support necessary to write computationally intensive programs, such as value classes and multidimensional arrays.
Given this history, I don't have much confidence that Sun will deliver a toolkit that is truly useful for writing games across platforms. It looks to me Sun is getting side tracked with some sort of Microsoft-envy and neglecting the fundamentals of delivering a high-performance, cross-platform system. In fact, I think if they fixed their technical and license problems, other people would likely do a much better job at defining gaming APIs for Java than Sun ever could.
Re:there is no real bloat associated with uuencode
on
Usenet Encoding: yEnc
·
· Score: 1
Huh? A compresing tunnel is transparent. It takes one command to set up (two if you don't want to change the NNTP host in your news software).
Oh, wait, you may be using Windows, and Windows users perhaps just can't figure this out? They can't even figure out what software to buy to do this for them? So, because Windows users can't figure it out, instead of just adopting a simple compressed NNTP protocol, everybody is supposed to change their software to accomodate binary postings, and everybody is supposed to post in binary?
Sorry, but that strikes me as enormously stupid. If you want efficient news transmission, do it right: use a compressing news transfer protocol, either at the level of news transfer or at the level of your networking protocols. Imposing a new, incompatible format on everybody else because you can't figure out how to compress your I/O makes no sense.
The older generation has said for years that the younger generation is all thumbs. This research now proves it.
Re:there is no real bloat associated with uuencode
on
Usenet Encoding: yEnc
·
· Score: 1
I have yet to see any DSL or cable modem with compression. So for most of the heavy binary users, uuencode data will not be compressed.
Oh, come on, think. Even if your modem doesn't compress, you can get compression at the level of a tunnel or at the level of your news transfer protocol.
Do you run a heavily used news servers to provide proof that the CPU overhead is 'negligible'.
Not anymore. But I do use software compression with most network connections, and it doesn't seem to load the CPU much.
If it really worries someone enough, they could come up with a compression envelope that works for all USENET postings and is used both during transmission and storage by servers that know about it. But it's apparently not enough of a problem for anybody to seriously worry about.
Re:Transfer speed isn't the only reason for it.
on
Usenet Encoding: yEnc
·
· Score: 1
That's a bogus argument. Dowload quotas are set taking into account that the data is compressible. If you make the data incompressible, then your download quotas will end up being set lower, or your prices will be raised.
As for compression and all that, if you believe that the constant compression/decompression during transmission and storage is too costly, then the right thing to do is to come up with an extension for NNTP that lets you transfer and store data in compressed binary form. Coming up with a new user-visible change that only a fraction of postings adopt and that breaks a lot of software is just plain stupid.
I, however, think that there simply isn't a problem. If you can't be bothered to pay for the bandwidth you want, why should the rest of the world put up with another uselss protocol?
You didn't think it through quite right. Your point is: you get charged by volume of news. My point is: the communications costs are the same whether you compress or not since the protocols already compress. If you reduce the volume you get charged for by compressing it yourself, but the company still incurs the same costs, you do indeed save--until the company adjusts their costs to account for this. In short, if you make the data you transmit harder to compress, prices go up. I'm sure if you think it through, you'll eventually get it...
Oh, come on, think about it. If pricing isn't completely arbitrary, it reflects costs. In that case, if you compress the content more, the prices are going to be raised.
It's no different over other TCP connections: people for whom this is a concern will transfer USENET postings in compressed format.
Besides, your attitude seems pretty selfish. Many people don't have a choice but to use analog modems, and that's not going to change for a long time. Unless, of course, you have a few trillion dollars to donate to the cause of stamping out analog.
But I get annoyed with people who live in the past
Why don't you get annoyed with yourself, then? Binary encodings are a holdover from the 1960's. For most content, we don't need them anymore because our infrastructure now handles all that automatically.
As an example, I post HTML to Usenet. Intentionally. And I will continue to do so.
You are confusing novelty with innovation, and generally seem to understand little of what has come before. The fact that you are obnoxious about it only makes you more annoying.
file.gz is what a raw binary encoding transfers, file.gz.uu.gz is what a communications protocol with a good compressor does when it sees a uuencoded file. Assuming everything works out, you save (drumroll) 4%. yEnc probably has more overhead than that.
The new modem standards apparently even have special compression modes for HTML, and if uuencode and base64 matter, modems and other compressors could recognize them as well. This used to be limited by the available computing power of, say, a PDP-11, but in the days of GHz signal processors and handhelds, textual encodings are OK. Really.
Brings to mind Yogi Berra: "The trouble with that place is: it's so crowded that nobody goes there anymore."
there is no real bloat associated with uuencode
on
Usenet Encoding: yEnc
·
· Score: 3, Interesting
Uuencoded text will compress down to nearly the same size as its corresponding binary (or less, if the binary can be compressed). That kind of compression is now a standard part of modems, Internet protocols, and many file systems. Even the CPU overhead of compressing and decompressing that kind of data is negligible. If yEnc doesn't end up using less space on disk and doesn't end up using any less bandwidth than uuencode, indeed, "why encode" in yEnc and break a lot of software that expects USENET posts to be text-only?
Yes, Microsoft did sell Xenix. As I recall, it was very expensive and deviated from AT&T's system in unleasant ways.
Most likely, what killed Xenix was AT&T's licensing fees--it's hard to see how such a premium priced system could have caught on with normal users, in particular at a time where people expected their OS to just "come" with the computer for free and nobody else was offering something as nice and expensive as UNIX. Many other great software systems have been killed by the desire of their creators to milk the market early and often with "breakthrough platforms". Smalltalk80, CommonLisp, and NeXTStep all priced themselves out of the market. Gates has the right business idea: make it cheap and simple and tighten the screws once you have a monopoly and people can't jump ship anymore.
I find this particular report rather dubious, however:
"Anyway, when I worked there back in the mid 80's every poor sod in the company from Bill down to the mail clerks had a Xenix terminal on their desk and used it daily for email at least. Meaning every poor sod had to master vi before they could request vacation time (and everyone wonders why Microsoft is such a hateful cramped little place.)
As opposed to what? The text editor that came with DOS? It seems to me they should have been so lucky as to get "vi". If Microsoft didn't like it, they could have developed whatever you think they did was so much better for DOS. And where did "vi" even come from? Xenix derives from 7th Edition UNIX, and I don't remember "vi" coming standard with 7th edition UNIX. If Xenix had "vi", someone must have decided that it was a good idea to backport it.
a number of mature implementations and competing implementations
Oh? Can you name any full Java 2 implementation that doesn't depend on Sun's code?
Don't believe the ECMA C# hype. That is only a small part of the.NET platform and as such is in no way comparable to the level of open specification present in the JCP.
I don't believe the ECMA C# hype--I have read the specs. It is exactly the fact that ECMA C# is small and doesn't try to standardize a lot of complex stuff that makes it valuable. Combine that with the fact that C# makes it easy to call existing C code and you have a really useful tool to replace C++. No, it won't let me write secure applets, but I don't care about writing secure applets.
Furthermore, anyone who believes that MSFT is going to play nice needs to take a refresher course on recent history.
See, with Java, I have to rely on Sun playing nice because Sun has, effectively, the only implementation. I don't expect Microsoft to play nice. In fact, the good thing is that it doesn't matter what Microsoft is going to do with C# in the future, just like it doesn't matter what Microsoft is doing with C++. If Microsoft adds new features or libraries to C# that are generally useful on other platforms, people will use them. If not, nobody is going to care and it doesn't matter.
...and you don't think that eventually Mono will have to do the same monkey tricks that Apache has to do now with Microsoft?
No. The reason is is that Sun set out to create a single, universal, platform-independent language and runtime environment. Mono and.NET, however, each have a much more modest goal: provide a Java-like language with a few libraries that work on different platforms and provide easy ways for people to use their platform-specific stuff. C# doesn't aim as high as Java: C# is just a Java-like language to replace C++, with a few portable libraries.
In different words, Apache has to care about Sun stuff like J2EE because Sun has made Java an all-or-nothing proposition; if they don't support all the latest Sun APIs, they aren't Java compliant. There is no such pressure on Mono.
We need more bad patents like this. The more of a problem this becomes, the more likely Congress is going to do something about it. And as long as the patents are as ridiculous as this one, and as long as they go after companies with money before they go after open source, everything's fine as far as I'm concerned.
In my opinion, X11 is by far your best choice. It was designed for these kinds of uses, and it manages to integrate multiple applications running on different machines almost seamlessly into a single desktop.
What you have to watch out for is that some toolkits and applications written for X11 these days seem to come out of a Windows mentality and assume that they are running locally; Mozilla and Gnome are offenders in this regard (KDE may be as well). They mostly work remotely, but sometimes they make the wrong assumptions about how to communicate with other applications. For example, they may get their resources not out of the display's resource database but out of some local configuration files. Or they may pop up another window on the wrong display. Those things should be reported as bugs when they occur.
Systems like VNC are also great and much easier to set up. However, their big disadvantage is that they remote only a whole desktop; they don't try to integrate multiple applications running on multiple machines. VNC also seems to be more bandwidth intensive than normal X11 sessions, although VNC can be faster than X11 for image-heavy applications (including some "modern" X11 toolkits that ignore all the X11 drawing commands and just blit everything--yuck).
So, my recommendadtion is: use X11 for most remote access, but use VNC for cross-platform applications or if you want a persistent desktop.
I think, JCP or not, Java has essentially become a proprietary system. It started out as a small language with a focussed library, something that could have set a widely implemented standard. Sun was promising to submit the language and a set of core libraries to a standards board. Several vendors were starting to come up with independent implementations. But Java 2 has become so big and complex that the only "standard" implementation is Sun's.
The mechanisms at work here are essentially the same as with Microsoft Windows or Microsoft VisualBasic: in the absence of multiple implementors, people will just keep adding functionality to the single codebase and ship the stuff. There is no pressure on Sun to keep things small, manageable, and independently implementable. And since Sun's Java implementation is not Open Source (although you can get the source with lots of restrictions under some legal agreement or other), it still gets controlled by just one company. The overall effect is also the same as with Microsoft: either you follow Sun wherever they go, or you are out of luck.
It's a shame that it had to come to this. I think, on balance, once Mono and similar projects have matured enough, ECMA C# (but not Microsoft C#/.NET) is going to be the better long-term choice for people interested in Java-like languages. I expect that's going to be less than a year. That is regrettable because an open source Java equivalent of ECMA C# would have been available years ago if only a standard equivalent to ECMA C# had been created for Java. And I think Sun would be doing better in the long run as well if that had come to pass--Microsoft may be able to get away with this sort of thing for decades, but I doubt Sun will.
Slashdot Mirror
I'm not sure how, but I am sure somehow the MPAA will construe this as a violation of artists' rights and a violation of copyright and the American way.
However, what they could (and should) do is have one of his parents sign the license agreements and other legal agreements.
I'm really tired of this one-size-fits-all attitude. That's Microsoft-think. If I wanted to use Windows, I'd just be using Windows--God knows, I have already paid for it. The reason to use UNIX/Linux is that it is different and that its applications are different. Turning Linux into a "free" version of Windows is pointless as far as I'm concerned.
Your reasoning is faulty. Just because there are some hard real-time applications (real-time music synthesis) doesn't mean that all audio applications need to be monolithic GUI programs. Pipes are fine for playing, recording, filtering, and other audio applications. And even hard real-time applications can be built from command line components that communicate via shared memory or that manipulate loadable components in a core process. The monolithic Windows way is not the only way, and certainly not the best way, of writing either non-real-time or real-time applications, for audio or anything else.
Seriously, a lot of Linux applications try to duplicate the Windows world and end up being just as bad. For example, for audio software, a monolithic executable with GUI is a Windows-style application--hard to reuse, hard to extend. A bunch of command line applications that can be piped together and come with a simple scripted GUI, that's a good Linux application because its bits and pieces can actually be reused.
I'm sorry, run that by me again? If they succeed at reducing the gravitational mass of an object but it requires expenditure of energy, you'd consider that a "null result"? I suppose next thing you are going to tell me is that electrostatic repulsion doesn't exist because moving the charges to measure it requires expenditure of energy.
2.6 Million bucks is a lot of money. It can fund many, many, many more real projects. Instead, it gone thrown into an unsubstantiated, non-peer-reviewed crackpottery by a guy who refuses to reveal the details of his so-called experiment.
Frankly, given the kind of uninspired, peer-reviewed, publicity-hungry junk I come across daily, I'm glad to see that some people are still spending money on long-shots and crackpots. If science were exclusively done by what one's peers think useful or interesting, we'd still be living in the stone age. I think this particular experiment is a long-shot, and after $2.6M it may really be time to start looking elsewhere. But, then, I think it's much less of a long-shot than the kind of nonsense theorists have been engaging in.
And it's not like the idea that there is something funny going on with gravity were completely unfounded. We know that Einstein's theory disagrees grossly with what we observe. It's not a question of if we can replicate this experimentally but how.
While I think it's unlikely the phenomenon is real, Bob Park's commentary on it is an unwarranted and unfounded attack. There is no reason whatsoever to believe that the effect would violate the "First Law"--the energy might come from the disk or the field.
Given this history, I don't have much confidence that Sun will deliver a toolkit that is truly useful for writing games across platforms. It looks to me Sun is getting side tracked with some sort of Microsoft-envy and neglecting the fundamentals of delivering a high-performance, cross-platform system. In fact, I think if they fixed their technical and license problems, other people would likely do a much better job at defining gaming APIs for Java than Sun ever could.
Oh, wait, you may be using Windows, and Windows users perhaps just can't figure this out? They can't even figure out what software to buy to do this for them? So, because Windows users can't figure it out, instead of just adopting a simple compressed NNTP protocol, everybody is supposed to change their software to accomodate binary postings, and everybody is supposed to post in binary?
Sorry, but that strikes me as enormously stupid. If you want efficient news transmission, do it right: use a compressing news transfer protocol, either at the level of news transfer or at the level of your networking protocols. Imposing a new, incompatible format on everybody else because you can't figure out how to compress your I/O makes no sense.
The older generation has said for years that the younger generation is all thumbs. This research now proves it.
Oh, come on, think. Even if your modem doesn't compress, you can get compression at the level of a tunnel or at the level of your news transfer protocol.
Do you run a heavily used news servers to provide proof that the CPU overhead is 'negligible'.
Not anymore. But I do use software compression with most network connections, and it doesn't seem to load the CPU much.
If it really worries someone enough, they could come up with a compression envelope that works for all USENET postings and is used both during transmission and storage by servers that know about it. But it's apparently not enough of a problem for anybody to seriously worry about.
As for compression and all that, if you believe that the constant compression/decompression during transmission and storage is too costly, then the right thing to do is to come up with an extension for NNTP that lets you transfer and store data in compressed binary form. Coming up with a new user-visible change that only a fraction of postings adopt and that breaks a lot of software is just plain stupid.
I, however, think that there simply isn't a problem. If you can't be bothered to pay for the bandwidth you want, why should the rest of the world put up with another uselss protocol?
You didn't think it through quite right. Your point is: you get charged by volume of news. My point is: the communications costs are the same whether you compress or not since the protocols already compress. If you reduce the volume you get charged for by compressing it yourself, but the company still incurs the same costs, you do indeed save--until the company adjusts their costs to account for this. In short, if you make the data you transmit harder to compress, prices go up. I'm sure if you think it through, you'll eventually get it...
Oh, come on, think about it. If pricing isn't completely arbitrary, it reflects costs. In that case, if you compress the content more, the prices are going to be raised.
Besides, your attitude seems pretty selfish. Many people don't have a choice but to use analog modems, and that's not going to change for a long time. Unless, of course, you have a few trillion dollars to donate to the cause of stamping out analog.
Why don't you get annoyed with yourself, then? Binary encodings are a holdover from the 1960's. For most content, we don't need them anymore because our infrastructure now handles all that automatically.
As an example, I post HTML to Usenet. Intentionally. And I will continue to do so.
You are confusing novelty with innovation, and generally seem to understand little of what has come before. The fact that you are obnoxious about it only makes you more annoying.
42244 file
17136 file.gz
23636 file.gz.uu
17894 file.gz.uu.gz
file.gz is what a raw binary encoding transfers, file.gz.uu.gz is what a communications protocol with a good compressor does when it sees a uuencoded file. Assuming everything works out, you save (drumroll) 4%. yEnc probably has more overhead than that.
The new modem standards apparently even have special compression modes for HTML, and if uuencode and base64 matter, modems and other compressors could recognize them as well. This used to be limited by the available computing power of, say, a PDP-11, but in the days of GHz signal processors and handhelds, textual encodings are OK. Really.
Brings to mind Yogi Berra: "The trouble with that place is: it's so crowded that nobody goes there anymore."
Uuencoded text will compress down to nearly the same size as its corresponding binary (or less, if the binary can be compressed). That kind of compression is now a standard part of modems, Internet protocols, and many file systems. Even the CPU overhead of compressing and decompressing that kind of data is negligible. If yEnc doesn't end up using less space on disk and doesn't end up using any less bandwidth than uuencode, indeed, "why encode" in yEnc and break a lot of software that expects USENET posts to be text-only?
Most likely, what killed Xenix was AT&T's licensing fees--it's hard to see how such a premium priced system could have caught on with normal users, in particular at a time where people expected their OS to just "come" with the computer for free and nobody else was offering something as nice and expensive as UNIX. Many other great software systems have been killed by the desire of their creators to milk the market early and often with "breakthrough platforms". Smalltalk80, CommonLisp, and NeXTStep all priced themselves out of the market. Gates has the right business idea: make it cheap and simple and tighten the screws once you have a monopoly and people can't jump ship anymore.
I find this particular report rather dubious, however:
"Anyway, when I worked there back in the mid 80's every poor sod in the company from Bill down to the mail clerks had a Xenix terminal on their desk and used it daily for email at least. Meaning every poor sod had to master vi before they could request vacation time (and everyone wonders why Microsoft is such a hateful cramped little place.)
As opposed to what? The text editor that came with DOS? It seems to me they should have been so lucky as to get "vi". If Microsoft didn't like it, they could have developed whatever you think they did was so much better for DOS. And where did "vi" even come from? Xenix derives from 7th Edition UNIX, and I don't remember "vi" coming standard with 7th edition UNIX. If Xenix had "vi", someone must have decided that it was a good idea to backport it.
Oh? Can you name any full Java 2 implementation that doesn't depend on Sun's code?
Don't believe the ECMA C# hype. That is only a small part of the .NET platform and as such is in no way comparable to the level of open specification present in the JCP.
I don't believe the ECMA C# hype--I have read the specs. It is exactly the fact that ECMA C# is small and doesn't try to standardize a lot of complex stuff that makes it valuable. Combine that with the fact that C# makes it easy to call existing C code and you have a really useful tool to replace C++. No, it won't let me write secure applets, but I don't care about writing secure applets.
Furthermore, anyone who believes that MSFT is going to play nice needs to take a refresher course on recent history.
See, with Java, I have to rely on Sun playing nice because Sun has, effectively, the only implementation. I don't expect Microsoft to play nice. In fact, the good thing is that it doesn't matter what Microsoft is going to do with C# in the future, just like it doesn't matter what Microsoft is doing with C++. If Microsoft adds new features or libraries to C# that are generally useful on other platforms, people will use them. If not, nobody is going to care and it doesn't matter.
No. The reason is is that Sun set out to create a single, universal, platform-independent language and runtime environment. Mono and .NET, however, each have a much more modest goal: provide a Java-like language with a few libraries that work on different platforms and provide easy ways for people to use their platform-specific stuff. C# doesn't aim as high as Java: C# is just a Java-like language to replace C++, with a few portable libraries.
In different words, Apache has to care about Sun stuff like J2EE because Sun has made Java an all-or-nothing proposition; if they don't support all the latest Sun APIs, they aren't Java compliant. There is no such pressure on Mono.
We need more bad patents like this. The more of a problem this becomes, the more likely Congress is going to do something about it. And as long as the patents are as ridiculous as this one, and as long as they go after companies with money before they go after open source, everything's fine as far as I'm concerned.
What you have to watch out for is that some toolkits and applications written for X11 these days seem to come out of a Windows mentality and assume that they are running locally; Mozilla and Gnome are offenders in this regard (KDE may be as well). They mostly work remotely, but sometimes they make the wrong assumptions about how to communicate with other applications. For example, they may get their resources not out of the display's resource database but out of some local configuration files. Or they may pop up another window on the wrong display. Those things should be reported as bugs when they occur.
Systems like VNC are also great and much easier to set up. However, their big disadvantage is that they remote only a whole desktop; they don't try to integrate multiple applications running on multiple machines. VNC also seems to be more bandwidth intensive than normal X11 sessions, although VNC can be faster than X11 for image-heavy applications (including some "modern" X11 toolkits that ignore all the X11 drawing commands and just blit everything--yuck).
So, my recommendadtion is: use X11 for most remote access, but use VNC for cross-platform applications or if you want a persistent desktop.
The mechanisms at work here are essentially the same as with Microsoft Windows or Microsoft VisualBasic: in the absence of multiple implementors, people will just keep adding functionality to the single codebase and ship the stuff. There is no pressure on Sun to keep things small, manageable, and independently implementable. And since Sun's Java implementation is not Open Source (although you can get the source with lots of restrictions under some legal agreement or other), it still gets controlled by just one company. The overall effect is also the same as with Microsoft: either you follow Sun wherever they go, or you are out of luck.
It's a shame that it had to come to this. I think, on balance, once Mono and similar projects have matured enough, ECMA C# (but not Microsoft C#/.NET) is going to be the better long-term choice for people interested in Java-like languages. I expect that's going to be less than a year. That is regrettable because an open source Java equivalent of ECMA C# would have been available years ago if only a standard equivalent to ECMA C# had been created for Java. And I think Sun would be doing better in the long run as well if that had come to pass--Microsoft may be able to get away with this sort of thing for decades, but I doubt Sun will.