Slashdot Mirror

OS/2 was a great OS, but it has only a small fraction of the market share that MacOS has. Furthermore, OS/2 is dying while MacOS is growing its market share.

Given that, now that Sun has bought Star Division and StarOffice, why do they continue to develop the OS/2 version and make it available for free download, while at the same time kill their MacOS version?

I just don't understand Scooter (Scott McNealy :) sometimes.

Go to this page, skip down to non-commercial licensing and explain those next couple of paragraphs to me. Correct me if I'm wrong, but isn't the JDK, among other things, what people use to compile those infernal Java programs? Of course, I could be digging in the wrong place (is there another release of the JDK besides the "full source"? no time for their applets and licensing stuff to be more thorough). I admit, as always, that I could be wrong. I'm not interested in Java. I stick with C/C++ and Perl. I don't know all the details. If that isn't enough of a disclaimer to stop flaming me, you should get out more. ;)

You are seeing this very very neat application that gets you drooling, and you ask the salesperson "i want one! what is it written in?". The salesperson then say, "well, it's java, sir!" and you automatically assume that java is the greatest thing in the world.

I think you've read to far into his post. No where did he say that just because the software is done in Java that it's the greatest thing. All he was saying is that Java -can- do some really cool stuff.

I know that there is no such jini-like API in C/C++/etc (at least that I know of).

And wanna know what? You don't need one in C++! The great thing about Jini is that it doesn't require Java. You can use other languages and still enable your device for Jini by using proxies. In fact, if I'm not mistaken, you can even write the lookup and other services in another language such as C++!

One more thing, as a end user I REALLY do NOT care about how fast you wrote the application!

Then don't complain when software's release is delayed or due to insufficient amount of time the feature you really wanted was kept out. Those are just the tip of the iceberg - Development time does matter.

I care about speed and reliability. Maybe java has that (I have seen otherwise, but I love to be proved wrong)

The problem with all you Java nay-sayers is that your main exposure to Java is through the dinky applets spewn across the Web. Most of you are not seeing what is actually being done inside the Fortune 500 companies or some of the various academic / research projects. Nor in many cases have people who discount Java tried it themselves.. and I don't mean a little applet.

Most "real" Java users have learned that Java can be quite reliable while cutting development costs and time spent. As for the speed issue, yeah, it's not as fast C or C++ (or asm for that matter), but it's not dog slow as people make out to be. Furthermore, Java has actually exceeded C/C++ speeds in some cases using Hot Spot.

Hotspot vaporware? Nope!

JavaTM 2 Software Development Kit, Standard Edition, v.1.3 Beta

(Obviously, only available for Windows and Solaris at the moment..)

http://developer.java.sun.com/developer/technicalA rticles/ConsumerProduc ts/JavaTanks/tankdemo.tar.gz

I'll believe it when it shows up on the top of this list, for example.

and then when someone points out that's a very real possibility, seeing as the second one on that list is a predecessor of this new IBM machine that is purported as being 2.5 times slower.

Then, what do you do? You change lists. Now, it seems, the real proof of greatness is how well you do it non-clustered.

Could it be that Sun doesn't have these good clustered benchmarks because Sun Clusters don't offer scaleable performance as do clusters from IBM and Compaq?

What I think you're really saying is that you're only impressed if it shows up on this comparison.

This claim is so heavy on spin that it ignores reality and it ignores the article that this discussion is based on. Here's some counter spin, based on fact: Sun Expands Revenues and Shipments in All Server Categories. Here's a prominent quote:

Sun maintained a prominent position in the UNIX server market, capturing first place worldwide, with a 28% market share in factory revenue and 30% share in shipments. While competitors IBM and HP lost a share of the market in both factory revenues and shipments...

The RS/6000 SP2... dots the `Top 500 Supercomputers` list all over... not a single retail Sun is found on that list.

Ignore the fact that the list is filled with those SP2 killer E10000s.

The rest of your message (os verions and "stability" claims without proof, better "web servers" without proof, and the ultimate in midrange and mainframe technology -- without proof) I'll leave as an exercise for the reader to figure out.

"A Microsoft attorney said the company will point to the remarkable financial success of Red Hat Inc., a leading vendor of the upstart Linux software operating system."

Too bad Red Hat went public looong after the antitrust suit was actually filed. Isn't this a bit late in the game to point to current trends? As much as we'd like to change the past..

"An economist who testified for the Justice Department, Franklin Fisher, had dismissed as ``a joke, of course'' the potential threat that Linux posed to the market dominance of Microsoft's Windows software."

Nice to know that people who testify for the DOJ don't watch the news.

"The Microsoft lawyer, speaking on condition of anonymity, said the company will tell the judge it believes Linux to be ``real competition.''"

I'd want to remain anonymous too after all the hoopla associated with Bill Gates' insistence that Linux isn't a threat.. not to mention the backing of several of his other yes-men. Nice to know that at least one person has some sense amidst that pack of utter liars.

"The Justice Department has argued that Linux has been successful challenging Microsoft in the sale of high-end business ``server'' computers, not consumer machines."

Not for long, baby. Once the hardware manufacturers realize that, then I'll be happy. I think it's absurd that IBM is taking a "wait and see" stance with regards to Linux PCs. Didn't Apple make the same mistake when IBM was just a start-up company? Thinking there was still lots of business in the mainframe market while IBM dove for the PC market and became the standard, leaving Apple to content themselves with being second best? Also, it's remarkable how many people say Linux has "a steep learning curve". I'm not sure how many people are aware of this, but among the average human, -Windows- has a steep learning curve (not to mention computers in general).

"And Microsoft Chairman Bill Gates was quoted in earlier evidence in the trial as saying at a technology conference this spring that Linux's impact ``will be fairly limited'' and that he's never had a customer mention Linux to him."

I don't think Bill even listens to his customers, so of course he never heard them mention much of anything.. Or else maybe he'd take the hint that people don't like it when their system "develops random features". I'm sure he thinks it's "cute", however.

"Microsoft also was expected to cite an announcement just days ago by rival Sun Microsystems Inc. that it has begun distributing free on the Internet a package of business applications meant to compete with Microsoft's Office software."

Now this is even sillier.. Who in their right mind is really afraid of Sun Microsystems or anything they have to offer? Perhaps in time their stuff will be good (they certainly have some nice concepts.. but in a business, you need more than just a bunch of "idea men" and loony ad campaigns), but for now Java and its associated hype goes a long way to prove how immature they and their products still are.

As a side note, anyone who thinks Sun is "really cool" and not just another corporate entity that has absurd notions of, well, just about everything, feel free to peruse these terms, which you must agree to if you want to post one of their logos on your site.. even if its simply as a supporter of Sun's technology. This stuff is pretty wild..

Our needs included:

portability - the application must be able to run on Windows, Mac, and Linux (if we get other *nixes as a bonus then that's even better)

consistency - the interface must be as consistent as possible across platforms

gui flexibility - the interface must be as customizable as possible

html/XML support - the language or its libraries/runtime must support HTML content, and at least be pledging future support for XML.

After doing our research, and delving into Sun's commitment to Linux, as well as its seeming support for Open Source we decided that Java was likely our best choice. The Swing components seemed to provide the desired customizability and consistency, Java supported HTML and was on its way to XML support, and the Linux support promised would guarantee us a presence on what we deemed the important platforms.

So now it's a year later. The product is designed, mostly written, and really beginning to take shape. We are trying to put together our package to show to potential underwriters but have been plagued by a serious Java issue:

The Windows and Solaris JDK/JRE packages, while still a bit slow and memory-intensive, provide most of the features we need to produce a stable and slick application which can usefully present our content. What bugs there are appear to be hot items ready for fixing in the next release. However, the Linux JDK/JRE packages are not stable, not well-supported, and not even at the same release level as the Windows and Solaris versions.

Month after month we have watched the progress of JDK development (as supposedly supported by Sun) for Linux crawl forward. We have been programming steadily, working around bugs, redesigning interface features to not rely upon features which are not yet present in Linux. Generally acting as if Java2 for Linux is not coming any time soon.

As we watch we have gotten the feeling that, despite press releases to the contrary, Sun could care less whether the Linux JDK ever gets finished, and doesn't appear to be devoting its resources at all towards the platform. Indeed, it seems as if they would prefer people forgot about Linux and its Java port altogether. Here's an example. java.sun.com is Sun's main website devoted to the Java language. Trying to actually find the Linux port from this page takes the patience of Job. Want some help? I'll locate you a few pages down in the right direction. See if you can find it from here. It doesn't help matters that Sun "reorganizes" their Java site periodically, essentially scrambling the links on the page -- reminiscent of the supermarket technique of seemingly random placement of necessities to make one wander through the store, hopefully buying non-necessities (or, similarly, the legendary placement of keys on the QWERTY keyboard to slow down the typist).

"Bad site design" aside, after looking in more desperation for help we noticed other symptoms of "Sun support gone wrong.":

Cryptic messages on Sun's message board about the availabili ty of Linux Java tools

Rumblings on the Blackdown Java port mailing list about lack of progress, with occasional hints that Blackdown is fixing bugs in Sun's code which are getting folded in for later release. While that's great (they should report bugs and the bugs should be fixed in later releases), this forces us to ask the question, "What form is the press-released 'Sun support' taking?" Evidently it's not in the form of programming resources or even $ to support developers.

Additionally, Blackdown appears to be in the lead as far as releases of the JDK go, with IBM purportedly not close to a Java2 JDK, and the other viable options being "for profit" and likely Closed Source. So, this is the net effect of Sun's much publicised "support for Java on Linux"?

This interview, to me, gives me additional reason to doubt Sun's corporate motives. While there are (even discussed on the Linux/Java developers lists) difficulties in porting Solaris thread code to Linux, and difficulties testing graphical components under the numerous X environments available to the Linux end user, if Sun were truly "supporting" the port of Java to Linux this would not really be an issue. Sun could at least provide a more portable reference implementation if nothing else. Gosling is as aware of this as anyone, but uses this as his "out" ("Sun FUD" if you will).

Similarly he straddles the fence by parroting the Sun party line -- why not truly Open Source Java (e.g., GPL it or release it under one of the BSD licenses?)? Well, it really is Open Source, but we have our own proprietary license because we want to maintain platform independence. But, ironically, the fact that Java is not truly Open Source is one of the reasons (determined from hours of sifting through user and developer mailing lists) why it isn't being ported more quickly to Linux. So, the Sun license is guaranteeing (at least for the moment) that Java is NOT platform independent.

Take this together with some reconsideration of the recent StarOffice purchase, and one begins to wonder whether Linux support is, in Sun's eyes, great PR but bad business.

Our needs included:

portability - the application must be able to run on Windows, Mac, and Linux (if we get other *nixes as a bonus then that's even better)

consistency - the interface must be as consistent as possible across platforms

gui flexibility - the interface must be as customizable as possible

html/XML support - the language or its libraries/runtime must support HTML content, and at least be pledging future support for XML.

After doing our research, and delving into Sun's commitment to Linux, as well as its seeming support for Open Source we decided that Java was likely our best choice. The Swing components seemed to provide the desired customizability and consistency, Java supported HTML and was on its way to XML support, and the Linux support promised would guarantee us a presence on what we deemed the important platforms.

So now it's a year later. The product is designed, mostly written, and really beginning to take shape. We are trying to put together our package to show to potential underwriters but have been plagued by a serious Java issue:

The Windows and Solaris JDK/JRE packages, while still a bit slow and memory-intensive, provide most of the features we need to produce a stable and slick application which can usefully present our content. What bugs there are appear to be hot items ready for fixing in the next release. However, the Linux JDK/JRE packages are not stable, not well-supported, and not even at the same release level as the Windows and Solaris versions.

Month after month we have watched the progress of JDK development (as supposedly supported by Sun) for Linux crawl forward. We have been programming steadily, working around bugs, redesigning interface features to not rely upon features which are not yet present in Linux. Generally acting as if Java2 for Linux is not coming any time soon.

As we watch we have gotten the feeling that, despite press releases to the contrary, Sun could care less whether the Linux JDK ever gets finished, and doesn't appear to be devoting its resources at all towards the platform. Indeed, it seems as if they would prefer people forgot about Linux and its Java port altogether. Here's an example. java.sun.com is Sun's main website devoted to the Java language. Trying to actually find the Linux port from this page takes the patience of Job. Want some help? I'll locate you a few pages down in the right direction. See if you can find it from here. It doesn't help matters that Sun "reorganizes" their Java site periodically, essentially scrambling the links on the page -- reminiscent of the supermarket technique of seemingly random placement of necessities to make one wander through the store, hopefully buying non-necessities (or, similarly, the legendary placement of keys on the QWERTY keyboard to slow down the typist).

"Bad site design" aside, after looking in more desperation for help we noticed other symptoms of "Sun support gone wrong.":

Cryptic messages on Sun's message board about the availabili ty of Linux Java tools

Rumblings on the Blackdown Java port mailing list about lack of progress, with occasional hints that Blackdown is fixing bugs in Sun's code which are getting folded in for later release. While that's great (they should report bugs and the bugs should be fixed in later releases), this forces us to ask the question, "What form is the press-released 'Sun support' taking?" Evidently it's not in the form of programming resources or even $ to support developers.

Additionally, Blackdown appears to be in the lead as far as releases of the JDK go, with IBM purportedly not close to a Java2 JDK, and the other viable options being "for profit" and likely Closed Source. So, this is the net effect of Sun's much publicised "support for Java on Linux"?

This interview, to me, gives me additional reason to doubt Sun's corporate motives. While there are (even discussed on the Linux/Java developers lists) difficulties in porting Solaris thread code to Linux, and difficulties testing graphical components under the numerous X environments available to the Linux end user, if Sun were truly "supporting" the port of Java to Linux this would not really be an issue. Sun could at least provide a more portable reference implementation if nothing else. Gosling is as aware of this as anyone, but uses this as his "out" ("Sun FUD" if you will).

Similarly he straddles the fence by parroting the Sun party line -- why not truly Open Source Java (e.g., GPL it or release it under one of the BSD licenses?)? Well, it really is Open Source, but we have our own proprietary license because we want to maintain platform independence. But, ironically, the fact that Java is not truly Open Source is one of the reasons (determined from hours of sifting through user and developer mailing lists) why it isn't being ported more quickly to Linux. So, the Sun license is guaranteeing (at least for the moment) that Java is NOT platform independent.

Take this together with some reconsideration of the recent StarOffice purchase, and one begins to wonder whether Linux support is, in Sun's eyes, great PR but bad business.

Our needs included:

portability - the application must be able to run on Windows, Mac, and Linux (if we get other *nixes as a bonus then that's even better)

consistency - the interface must be as consistent as possible across platforms

gui flexibility - the interface must be as customizable as possible

html/XML support - the language or its libraries/runtime must support HTML content, and at least be pledging future support for XML.

After doing our research, and delving into Sun's commitment to Linux, as well as its seeming support for Open Source we decided that Java was likely our best choice. The Swing components seemed to provide the desired customizability and consistency, Java supported HTML and was on its way to XML support, and the Linux support promised would guarantee us a presence on what we deemed the important platforms.

So now it's a year later. The product is designed, mostly written, and really beginning to take shape. We are trying to put together our package to show to potential underwriters but have been plagued by a serious Java issue:

The Windows and Solaris JDK/JRE packages, while still a bit slow and memory-intensive, provide most of the features we need to produce a stable and slick application which can usefully present our content. What bugs there are appear to be hot items ready for fixing in the next release. However, the Linux JDK/JRE packages are not stable, not well-supported, and not even at the same release level as the Windows and Solaris versions.

Month after month we have watched the progress of JDK development (as supposedly supported by Sun) for Linux crawl forward. We have been programming steadily, working around bugs, redesigning interface features to not rely upon features which are not yet present in Linux. Generally acting as if Java2 for Linux is not coming any time soon.

As we watch we have gotten the feeling that, despite press releases to the contrary, Sun could care less whether the Linux JDK ever gets finished, and doesn't appear to be devoting its resources at all towards the platform. Indeed, it seems as if they would prefer people forgot about Linux and its Java port altogether. Here's an example. java.sun.com is Sun's main website devoted to the Java language. Trying to actually find the Linux port from this page takes the patience of Job. Want some help? I'll locate you a few pages down in the right direction. See if you can find it from here. It doesn't help matters that Sun "reorganizes" their Java site periodically, essentially scrambling the links on the page -- reminiscent of the supermarket technique of seemingly random placement of necessities to make one wander through the store, hopefully buying non-necessities (or, similarly, the legendary placement of keys on the QWERTY keyboard to slow down the typist).

"Bad site design" aside, after looking in more desperation for help we noticed other symptoms of "Sun support gone wrong.":

Cryptic messages on Sun's message board about the availabili ty of Linux Java tools

Rumblings on the Blackdown Java port mailing list about lack of progress, with occasional hints that Blackdown is fixing bugs in Sun's code which are getting folded in for later release. While that's great (they should report bugs and the bugs should be fixed in later releases), this forces us to ask the question, "What form is the press-released 'Sun support' taking?" Evidently it's not in the form of programming resources or even $ to support developers.

Additionally, Blackdown appears to be in the lead as far as releases of the JDK go, with IBM purportedly not close to a Java2 JDK, and the other viable options being "for profit" and likely Closed Source. So, this is the net effect of Sun's much publicised "support for Java on Linux"?

This interview, to me, gives me additional reason to doubt Sun's corporate motives. While there are (even discussed on the Linux/Java developers lists) difficulties in porting Solaris thread code to Linux, and difficulties testing graphical components under the numerous X environments available to the Linux end user, if Sun were truly "supporting" the port of Java to Linux this would not really be an issue. Sun could at least provide a more portable reference implementation if nothing else. Gosling is as aware of this as anyone, but uses this as his "out" ("Sun FUD" if you will).

Similarly he straddles the fence by parroting the Sun party line -- why not truly Open Source Java (e.g., GPL it or release it under one of the BSD licenses?)? Well, it really is Open Source, but we have our own proprietary license because we want to maintain platform independence. But, ironically, the fact that Java is not truly Open Source is one of the reasons (determined from hours of sifting through user and developer mailing lists) why it isn't being ported more quickly to Linux. So, the Sun license is guaranteeing (at least for the moment) that Java is NOT platform independent.

Take this together with some reconsideration of the recent StarOffice purchase, and one begins to wonder whether Linux support is, in Sun's eyes, great PR but bad business.

Our needs included:

portability - the application must be able to run on Windows, Mac, and Linux (if we get other *nixes as a bonus then that's even better)

consistency - the interface must be as consistent as possible across platforms

gui flexibility - the interface must be as customizable as possible

html/XML support - the language or its libraries/runtime must support HTML content, and at least be pledging future support for XML.

After doing our research, and delving into Sun's commitment to Linux, as well as its seeming support for Open Source we decided that Java was likely our best choice. The Swing components seemed to provide the desired customizability and consistency, Java supported HTML and was on its way to XML support, and the Linux support promised would guarantee us a presence on what we deemed the important platforms.

So now it's a year later. The product is designed, mostly written, and really beginning to take shape. We are trying to put together our package to show to potential underwriters but have been plagued by a serious Java issue:

The Windows and Solaris JDK/JRE packages, while still a bit slow and memory-intensive, provide most of the features we need to produce a stable and slick application which can usefully present our content. What bugs there are appear to be hot items ready for fixing in the next release. However, the Linux JDK/JRE packages are not stable, not well-supported, and not even at the same release level as the Windows and Solaris versions.

Month after month we have watched the progress of JDK development (as supposedly supported by Sun) for Linux crawl forward. We have been programming steadily, working around bugs, redesigning interface features to not rely upon features which are not yet present in Linux. Generally acting as if Java2 for Linux is not coming any time soon.

As we watch we have gotten the feeling that, despite press releases to the contrary, Sun could care less whether the Linux JDK ever gets finished, and doesn't appear to be devoting its resources at all towards the platform. Indeed, it seems as if they would prefer people forgot about Linux and its Java port altogether. Here's an example. java.sun.com is Sun's main website devoted to the Java language. Trying to actually find the Linux port from this page takes the patience of Job. Want some help? I'll locate you a few pages down in the right direction. See if you can find it from here. It doesn't help matters that Sun "reorganizes" their Java site periodically, essentially scrambling the links on the page -- reminiscent of the supermarket technique of seemingly random placement of necessities to make one wander through the store, hopefully buying non-necessities (or, similarly, the legendary placement of keys on the QWERTY keyboard to slow down the typist).

"Bad site design" aside, after looking in more desperation for help we noticed other symptoms of "Sun support gone wrong.":

Cryptic messages on Sun's message board about the availabili ty of Linux Java tools

Rumblings on the Blackdown Java port mailing list about lack of progress, with occasional hints that Blackdown is fixing bugs in Sun's code which are getting folded in for later release. While that's great (they should report bugs and the bugs should be fixed in later releases), this forces us to ask the question, "What form is the press-released 'Sun support' taking?" Evidently it's not in the form of programming resources or even $ to support developers.

Additionally, Blackdown appears to be in the lead as far as releases of the JDK go, with IBM purportedly not close to a Java2 JDK, and the other viable options being "for profit" and likely Closed Source. So, this is the net effect of Sun's much publicised "support for Java on Linux"?

This interview, to me, gives me additional reason to doubt Sun's corporate motives. While there are (even discussed on the Linux/Java developers lists) difficulties in porting Solaris thread code to Linux, and difficulties testing graphical components under the numerous X environments available to the Linux end user, if Sun were truly "supporting" the port of Java to Linux this would not really be an issue. Sun could at least provide a more portable reference implementation if nothing else. Gosling is as aware of this as anyone, but uses this as his "out" ("Sun FUD" if you will).

Similarly he straddles the fence by parroting the Sun party line -- why not truly Open Source Java (e.g., GPL it or release it under one of the BSD licenses?)? Well, it really is Open Source, but we have our own proprietary license because we want to maintain platform independence. But, ironically, the fact that Java is not truly Open Source is one of the reasons (determined from hours of sifting through user and developer mailing lists) why it isn't being ported more quickly to Linux. So, the Sun license is guaranteeing (at least for the moment) that Java is NOT platform independent.

Take this together with some reconsideration of the recent StarOffice purchase, and one begins to wonder whether Linux support is, in Sun's eyes, great PR but bad business.

Our needs included:

portability - the application must be able to run on Windows, Mac, and Linux (if we get other *nixes as a bonus then that's even better)

consistency - the interface must be as consistent as possible across platforms

gui flexibility - the interface must be as customizable as possible

html/XML support - the language or its libraries/runtime must support HTML content, and at least be pledging future support for XML.

After doing our research, and delving into Sun's commitment to Linux, as well as its seeming support for Open Source we decided that Java was likely our best choice. The Swing components seemed to provide the desired customizability and consistency, Java supported HTML and was on its way to XML support, and the Linux support promised would guarantee us a presence on what we deemed the important platforms.

So now it's a year later. The product is designed, mostly written, and really beginning to take shape. We are trying to put together our package to show to potential underwriters but have been plagued by a serious Java issue:

The Windows and Solaris JDK/JRE packages, while still a bit slow and memory-intensive, provide most of the features we need to produce a stable and slick application which can usefully present our content. What bugs there are appear to be hot items ready for fixing in the next release. However, the Linux JDK/JRE packages are not stable, not well-supported, and not even at the same release level as the Windows and Solaris versions.

Month after month we have watched the progress of JDK development (as supposedly supported by Sun) for Linux crawl forward. We have been programming steadily, working around bugs, redesigning interface features to not rely upon features which are not yet present in Linux. Generally acting as if Java2 for Linux is not coming any time soon.

As we watch we have gotten the feeling that, despite press releases to the contrary, Sun could care less whether the Linux JDK ever gets finished, and doesn't appear to be devoting its resources at all towards the platform. Indeed, it seems as if they would prefer people forgot about Linux and its Java port altogether. Here's an example. java.sun.com is Sun's main website devoted to the Java language. Trying to actually find the Linux port from this page takes the patience of Job. Want some help? I'll locate you a few pages down in the right direction. See if you can find it from here. It doesn't help matters that Sun "reorganizes" their Java site periodically, essentially scrambling the links on the page -- reminiscent of the supermarket technique of seemingly random placement of necessities to make one wander through the store, hopefully buying non-necessities (or, similarly, the legendary placement of keys on the QWERTY keyboard to slow down the typist).

"Bad site design" aside, after looking in more desperation for help we noticed other symptoms of "Sun support gone wrong.":

Cryptic messages on Sun's message board about the availabili ty of Linux Java tools

Rumblings on the Blackdown Java port mailing list about lack of progress, with occasional hints that Blackdown is fixing bugs in Sun's code which are getting folded in for later release. While that's great (they should report bugs and the bugs should be fixed in later releases), this forces us to ask the question, "What form is the press-released 'Sun support' taking?" Evidently it's not in the form of programming resources or even $ to support developers.

Additionally, Blackdown appears to be in the lead as far as releases of the JDK go, with IBM purportedly not close to a Java2 JDK, and the other viable options being "for profit" and likely Closed Source. So, this is the net effect of Sun's much publicised "support for Java on Linux"?

This interview, to me, gives me additional reason to doubt Sun's corporate motives. While there are (even discussed on the Linux/Java developers lists) difficulties in porting Solaris thread code to Linux, and difficulties testing graphical components under the numerous X environments available to the Linux end user, if Sun were truly "supporting" the port of Java to Linux this would not really be an issue. Sun could at least provide a more portable reference implementation if nothing else. Gosling is as aware of this as anyone, but uses this as his "out" ("Sun FUD" if you will).

Similarly he straddles the fence by parroting the Sun party line -- why not truly Open Source Java (e.g., GPL it or release it under one of the BSD licenses?)? Well, it really is Open Source, but we have our own proprietary license because we want to maintain platform independence. But, ironically, the fact that Java is not truly Open Source is one of the reasons (determined from hours of sifting through user and developer mailing lists) why it isn't being ported more quickly to Linux. So, the Sun license is guaranteeing (at least for the moment) that Java is NOT platform independent.

Take this together with some reconsideration of the recent StarOffice purchase, and one begins to wonder whether Linux support is, in Sun's eyes, great PR but bad business.

Now I'm not so sure it's a good deal. I would need to read more about the server requirements first.

Bravery, Kindness, Clarity, Honesty, Compassion, Generosity

This is something that can be sold to big business as a real solution.

...and trading floors and places where user-access hardware uptime is critical will love it; if your monitor dies, whip your smartcard out of your machine, plug it into the spare system in the next cubicle, and your session moves with you in seconds.

see http://www.sun.com/products/sunray1/ for pictures and info.

- alec (who works for sun but still thinks it's a neat piece of kit)

(Note, though, that "competing" VMs on Win32 are strangely absent, including Microsoft's fast and well-patched one based on 1.1.4, IBM's etc.)

0) It is not object oriented like C++, where you can choose to use object orientation when it fits the task at hand.

No, because C++ is a hybrid language, whereas Java is a pure OO language.

2) You can easily communicate datastructures over the network. But you cannot (AFAIK) communicate the code. Why not ?? It's a virtual machine,

Yes you can, with RMI.

3) You have garbage collection always, everywhere. Not just when it's a benefit, but again you're locked into it.

I don't see why this would be a bad thing?

4) Floating point calculations are guaranteed to have same machine precision on all architectures. However, this is completely useless since numerical computations per definition are inaccurate, so all we have is an overhead from a feature with no use.

No, it is not useless. It quarantees that machine X doesn't suddenly have 10 bits less in its floating points than machine Y. Also, there is also java.math which has classes for arbitrary-precision integer and decimal arithmetic.

SUN sells workstations that will beat the G4 handily except for Altivec stuff, which probably is faster. But they also have the Enterprise 10000 can be equipped with up to 64 processors, which means it will leave a G4 in the dust.

SGI sells Onyx2 InfiniteReality2, which will beat probably anything else on heavy-duty visualisation stuff, and can be equipped with up to 128 processors.

HP makes the J-5000 workstation, which will also beat a G4 on most tasks, as well as big-ass servers with up to 128 processors.

IBM makes RS/6000 workstations and servers, which can scale up to 128 processors.

Compaq sells XP1000 workstations with a 667MHz Alpha 21264 processor, which will beat the G4 on anything that can't make very good use of Altivec, and there are places that sell dual 667MHz 21264 workstations. Compaq also has the AlphaServer GS line, which can take up to 14 21264's, probably beating the G4 on anything.

Furthermore, the Athlon probably beats the G4 on stuff that doesn't parallellise well, and an 8-way Xeon should be faster for most, if not all, things.

Unfortunately all the systems here, except the Athlon, are far, far more expensive than a G4. But you can get faster systems if you're willing to pay the price. Oh, and all of those run some Unix variant, as well as Windows NT for Alpha and Athlon/PIII.

Also, when it comes to the speed of the G4, it all depends on how useful Altivec is for your app. If it isn't useful, the G4 isn't that impressive. If it is, the G4 should be very good value for money, if Altivec is anywhere near as good as the hype claims it is.

You can get StarOffice from Sun. I've used it on Linux and Solaris and it does what you need an office suite to do -- for free, since you only have to pay if you bundle it or integrate it with something you sell.

Caveat: I work at Sun, so if you believe in conspiracy theories and so forth, perhaps you should get a second opinion.

Also, Sun will be launching their next-gen "JavaStation" in about 5-6 days, I believe.

You can download StarOffice 5.1 for free here - support for Solaris SPARC/Intel, Linux, OS/2, Windows 95/98/NT, and several languages. Unfortunately, you do have to register, but if you've already got a username/password for say the Java (or Solaris) Developers Connection then you can use that.

And finally, Sun will be making available Solaris 8 early access - ie open beta to the public, for the first time for a new version of Solaris. You'll probably see the source code available later...

Also, Sun will be launching their next-gen "JavaStation" in about 5-6 days, I believe.

You can download StarOffice 5.1 for free here - support for Solaris SPARC/Intel, Linux, OS/2, Windows 95/98/NT, and several languages. Unfortunately, you do have to register, but if you've already got a username/password for say the Java (or Solaris) Developers Connection then you can use that.

And finally, Sun will be making available Solaris 8 early access - ie open beta to the public, for the first time for a new version of Solaris. You'll probably see the source code available later...

Can't we somehow convince Sun that for this particular project even something like Mozilla's NPL would be more productive? The same licensing page referenced above shows that Sun doesn't seem to like the bazaar model much, so perhaps not.

> Sun makes workstations (You know, like PCs, only bigger) and operating systems, too. Sun couldn't
> have possibly purchased Star Division to make StarOffice work better with these products, could they?

They might have - but not according to Sun: see the press release on Sun's web site. Do you want to get in a scrap with Scott MacNealy about his company's direction?

The posts fails to grasp why we are moving back to large systems sitting in the middle of the network instead of little machines talking to each other.

Way back when, Moore noticed and projected his Moore's law saying that the speed and size of an individual processor would keep doubling. Great. So little iron gets the low costs of making millions of the little guys, mass market support, and low upgrade costs. Big iron only benefits from Moore's law, and falls behind. This happens for a decade or two.

Now the decade is over, and the tide turns the other way. Sun Microsystems, especially, has figured out a scaling law that says it can effectively (linearly) network an increasing number of processors. Over some period of time both the number of processors and the speed of processors double. Add in the shift from hardware costs to software costs, and big iron makes a comeback.

So, we've got a reason for big centralized machines to come back. If you want to make a case against this tide of technology, make it. If you can't, protest only as a luddite.

The Devout Capitalist
thalia4242@excite.com (Don't you hate the broken login script).

The posts fails to grasp why we are moving back to large systems sitting in the middle of the network instead of little machines talking to each other.

Way back when, Moore noticed and projected his Moore's law saying that the speed and size of an individual processor would keep doubling. Great. So little iron gets the low costs of making millions of the little guys, mass market support, and low upgrade costs. Big iron only benefits from Moore's law, and falls behind. This happens for a decade or two.

Now the decade is over, and the tide turns the other way. Sun Microsystems, especially, has figured out a scaling law that says it can effectively (linearly) network an increasing number of processors. Over some period of time both the number of processors and the speed of processors double. Add in the shift from hardware costs to software costs, and big iron makes a comeback.

So, we've got a reason for big centralized machines to come back. If you want to make a case against this tide of technology, make it. If you can't, protest only as a luddite.

The Devout Capitalist
thalia4242@excite.com (Don't you hate the broken login script).

The posts fails to grasp why we are moving back to large systems sitting in the middle of the network instead of little machines talking to each other.

Way back when, Moore noticed and projected his Moore's law saying that the speed and size of an individual processor would keep doubling. Great. So little iron gets the low costs of making millions of the little guys, mass market support, and low upgrade costs. Big iron only benefits from Moore's law, and falls behind. This happens for a decade or two.

Now the decade is over, and the tide turns the other way. Sun Microsystems, especially, has figured out a scaling law that says it can effectively (linearly) network an increasing number of processors. Over some period of time both the number of processors and the speed of processors double. Add in the shift from hardware costs to software costs, and big iron makes a comeback.

So, we've got a reason for big centralized machines to come back. If you want to make a case against this tide of technology, make it. If you can't, protest only as a luddite.

The Devout Capitalist
thalia4242@excite.com (Don't you hate the broken login script).

This is one of the funnier lines in the article, since it so clearly applies to the writer rather than the folks he disagrees with.

In a couple of places, he refers to SGI being profitable. According to the SEC, SGI hasn't posted an annual profit in years. In the latest quarterly report, they posted another huge loss. They have 'announced' a $22 million profit for the latest quarter, but I'll reserve judgement until the 10Q is filed.

They are on their third CEO in three years.

They are on their third 'strategy' in three years.

They are selling off their NT and Cray divisions. The last time they did this, they sold the "Business Systems Division" piece of Cray to Sun for a pittance. Sun used that division to create the Starfire (actually, it was almost finished at SGI), which has already sold more than 1500 units, for a total of (guessing) more than $1.5 billion.

Not only are they losing money every quarter, their top line (ie, sales) have been shrinking for three years.

The value of their stock has dropped by about 50% in the last 9 months.

They just laid off more than 15% of their workforce.

How much do you need before acknowledging that a once-great company is in real trouble?

This is one of the funnier lines in the article, since it so clearly applies to the writer rather than the folks he disagrees with.

In a couple of places, he refers to SGI being profitable. According to the SEC, SGI hasn't posted an annual profit in years. In the latest quarterly report, they posted another huge loss. They have 'announced' a $22 million profit for the latest quarter, but I'll reserve judgement until the 10Q is filed.

They are on their third CEO in three years.

They are on their third 'strategy' in three years.

They are selling off their NT and Cray divisions. The last time they did this, they sold the "Business Systems Division" piece of Cray to Sun for a pittance. Sun used that division to create the Starfire (actually, it was almost finished at SGI), which has already sold more than 1500 units, for a total of (guessing) more than $1.5 billion.

Not only are they losing money every quarter, their top line (ie, sales) have been shrinking for three years.

The value of their stock has dropped by about 50% in the last 9 months.

They just laid off more than 15% of their workforce.

How much do you need before acknowledging that a once-great company is in real trouble?

It started sometime last year, when Amiga Inc announced a mystery "Multimedia Chip" (MMC), that would power their new-fangle PC.
VERY reliable insiders said "It's amazing, never seen any performance like this.... but I can't say what it is."
The then CEO - Jeff Schindler, said "we can't announce our CPU partner yet, but believe us, it's revolutionary".
At this point, the "Amiga Community"(tm) went speculation mad (as usual), and several names, including TransMeta's were bandied around.
More recently, the hype got going again, because AInc were hiring, and talking about MIPS engineers, and links to ATI, etc. People started to suggest Transmeta again, and it started to become widespread.
When the Linux choice was announced, people put 2+2 together, and got Transmeta (again).
At the recent World of Amiga show, the video showed the Transmeta Logo (along with Sun's logo, ATI's logo, Corel's logo etc.) Amigans took this to mean that this was the chip choice.

BUT... remember - this has NEVER been officially announced or even hinted at in any statement by AInc. The Transmeta logo may have been used in the Linux->Linus->Transmeta context to represent their choice of Linux for the Kernel base.

That's the story.... it could just as easily turn out to be the Sun MAJC chip...

Padzo

Is anyone else having problems downloading staroffice from Sun`s website? Every time I click `download`, it takes me through a series of pages offering to send me a CD. I can`t see anything wrong with the HTML, so what`s going on? (And yes, I am clicking `download` and not `buy CD`, before anyone asks.)

Reading the SCSL license, commercial use is restricted and requires a special Commercial Use License agreement, with a "fill-in-the-blank" for royalty-per-unit payments.

"Commercial use" is defined two ways in the glossary of the license. First, internal deployments of more than 500 units are commercial use, so only small to medium sized businesses will qualify for the "Internal Deployment Use" license. Not that I see many large corps switching to StarOffice anytime soon, but it's worth noting.

Second, commercial use is defined as use for "direct or indirect commercial or strategic gain or advantage." Based on that, I don't believe hardware manufacturers could pre-install StarOffice without making payments to Sun.

Sun also does Community Source Hardware. In a nutshell, if you have the tools and the knowledge, you can brew your own picoJava or SPARC workstation on a chip. :-)

Caveat: I'm not qualified to offer expert legal advice, however if you are a (hardware) designer and don't work for Sun, I strongly suggest that you have your legal department (Intellectual Property advisor-person) look over their (or anyone's) licenses before you download any of the "open" cores.

Sun also does Community Source Hardware. In a nutshell, if you have the tools and the knowledge, you can brew your own picoJava or SPARC workstation on a chip. :-)

Caveat: I'm not qualified to offer expert legal advice, however if you are a (hardware) designer and don't work for Sun, I strongly suggest that you have your legal department (Intellectual Property advisor-person) look over their (or anyone's) licenses before you download any of the "open" cores.

Look carefully, it's not truly open sourced. It's the SCSL. For more information on SCSL, see Sun's description

Here's a link to the Sun Community Source License, in case (like me) you're not sure of exactly what that means...

cheers,

Tim

JavaRing was an implementation of JavaCard API for smart cards. The rings were manufactured by Dallas Semiconductor

Dallas Semicondutor puts JavaTM technology power in the iButton, a portable computer chip armored in stainless steel and wearable as jewelry or other personal accessory. In fact, the iButton in the JavaTM Ring gained attention as the first successful application of the Java CardTM 2.0 specification. A Java technology-enabled iButton conforms to the Java Card 2.0 specs and adds enhancements for a superior Java programming environment -- such as 32-bit Java technology integers, automatic garbage collection, and a true-time clock. Each iButton has a unique ROM registration number to which a PIN number can be attached for the same level of security banks use. Moreover, the ROM number is Java technology-accessible and supplements IP addresses, making all mobile iButtons globally addressable. Besides being physically tough and tamper-resistant, the Java technology-enabled iButton carries 800,000 transistors for cryptographic processing. A high-speed processor with a math accelerator performs the encryption to generate a digital signature in less than one second. One iButton's high-capacity NV SRAM can support multiple applications, thus maximizing the possibilities for a variety of secure Java Card technology transactions.

Smart cards are quite popular in Europe, where magnetic credit cards never got to the same level of popularity as in the US. Smart cards haven't taken off in the US because VISA and MasterCard are restraining competition.

ipv6 transitioning is a nightmare, no matter how you stack it.

I dunno - SUN (who I happen to work for) looks like it will have some nice transitioning tools. Stuff like automatic and configured IPv4 tunneling - see also the SUN IPv6 website.

MAJC home page . See the docs home page - introduction, and a "community" page .

They haven't really released enough details (on their website) just yet, but it does look interesting. One of the more obviously different attitudes the specification takes is highly customisable implimentations - you design a variation targeted at a particular application, whatever that might be - graphics accelerator, MP3 player/decoder, MPEG2/DVD decoder, or a more general purpose chip. Since it is mostly being targeted at embedded applications this is not surprising though.


Some other interesting aspects include:

'Support' for JIT/access-time compilers - not only does this help Java, but it is to make backwards compatability with older versions quite simple. This seems a bit like what Transmeta are doing, which was co-founded by an ex Sun guy btw.

Hardware support for ultra-fast thread switching - so fast that if one thread stalls waiting for DRAM access (which can take up to 100 clock cycles), you can switch to another thread rather than go idle. On many current OSs threads will be switched if the current one has to do some slow I/O say (ie read from disc) - so this is quite an improvement.

A more general approach to improving parallelism - you can have more than one CPU core in a single physical chip, which might or might not share their 1st level caches. (read this Microprocessor Report article for some background on this.) IBM are apparantly going to do a version of the PowerPC G4 which has 2 CPUs on one core, and I kinda suspect Sun might be planning something similar for their UltraSparc-V.

I'm not sure how Sun plan to make money of the design. It seems pretty likely they might do something like their "community source" model - you can get the design for free, but if you want to use it commercially you pay a license. ARM is doing well just licensing their CPU designs. I'd image Sun using to 'assist' their servers as add-on boards for doing heavy multi-media/3D graphics stuff - can you say "render farm"? Also, since Sun like selling their servers, they'd be happy for people to make lots of little, cheap devices that connect to nice big Sun servers.

Like the original poster said, IEEE Micro will probably have some interesting stuff, but it seems Sun aren't releasing all the details yet - looks like we'll have to wait until the Microprocessor Forum in October. I liked the article (written by the Sun engineers) about the UltraSparc-III - not only was it interesting (and I like Sun's approach) , it helped me figure out the inherant problem with the IA-64 architecture...

MAJC home page . See the docs home page - introduction, and a "community" page .

They haven't really released enough details (on their website) just yet, but it does look interesting. One of the more obviously different attitudes the specification takes is highly customisable implimentations - you design a variation targeted at a particular application, whatever that might be - graphics accelerator, MP3 player/decoder, MPEG2/DVD decoder, or a more general purpose chip. Since it is mostly being targeted at embedded applications this is not surprising though.


Some other interesting aspects include:

'Support' for JIT/access-time compilers - not only does this help Java, but it is to make backwards compatability with older versions quite simple. This seems a bit like what Transmeta are doing, which was co-founded by an ex Sun guy btw.

Hardware support for ultra-fast thread switching - so fast that if one thread stalls waiting for DRAM access (which can take up to 100 clock cycles), you can switch to another thread rather than go idle. On many current OSs threads will be switched if the current one has to do some slow I/O say (ie read from disc) - so this is quite an improvement.

A more general approach to improving parallelism - you can have more than one CPU core in a single physical chip, which might or might not share their 1st level caches. (read this Microprocessor Report article for some background on this.) IBM are apparantly going to do a version of the PowerPC G4 which has 2 CPUs on one core, and I kinda suspect Sun might be planning something similar for their UltraSparc-V.

I'm not sure how Sun plan to make money of the design. It seems pretty likely they might do something like their "community source" model - you can get the design for free, but if you want to use it commercially you pay a license. ARM is doing well just licensing their CPU designs. I'd image Sun using to 'assist' their servers as add-on boards for doing heavy multi-media/3D graphics stuff - can you say "render farm"? Also, since Sun like selling their servers, they'd be happy for people to make lots of little, cheap devices that connect to nice big Sun servers.

Like the original poster said, IEEE Micro will probably have some interesting stuff, but it seems Sun aren't releasing all the details yet - looks like we'll have to wait until the Microprocessor Forum in October. I liked the article (written by the Sun engineers) about the UltraSparc-III - not only was it interesting (and I like Sun's approach) , it helped me figure out the inherant problem with the IA-64 architecture...

MAJC home page . See the docs home page - introduction, and a "community" page .

They haven't really released enough details (on their website) just yet, but it does look interesting. One of the more obviously different attitudes the specification takes is highly customisable implimentations - you design a variation targeted at a particular application, whatever that might be - graphics accelerator, MP3 player/decoder, MPEG2/DVD decoder, or a more general purpose chip. Since it is mostly being targeted at embedded applications this is not surprising though.


Some other interesting aspects include:

'Support' for JIT/access-time compilers - not only does this help Java, but it is to make backwards compatability with older versions quite simple. This seems a bit like what Transmeta are doing, which was co-founded by an ex Sun guy btw.

Hardware support for ultra-fast thread switching - so fast that if one thread stalls waiting for DRAM access (which can take up to 100 clock cycles), you can switch to another thread rather than go idle. On many current OSs threads will be switched if the current one has to do some slow I/O say (ie read from disc) - so this is quite an improvement.

A more general approach to improving parallelism - you can have more than one CPU core in a single physical chip, which might or might not share their 1st level caches. (read this Microprocessor Report article for some background on this.) IBM are apparantly going to do a version of the PowerPC G4 which has 2 CPUs on one core, and I kinda suspect Sun might be planning something similar for their UltraSparc-V.

I'm not sure how Sun plan to make money of the design. It seems pretty likely they might do something like their "community source" model - you can get the design for free, but if you want to use it commercially you pay a license. ARM is doing well just licensing their CPU designs. I'd image Sun using to 'assist' their servers as add-on boards for doing heavy multi-media/3D graphics stuff - can you say "render farm"? Also, since Sun like selling their servers, they'd be happy for people to make lots of little, cheap devices that connect to nice big Sun servers.

Like the original poster said, IEEE Micro will probably have some interesting stuff, but it seems Sun aren't releasing all the details yet - looks like we'll have to wait until the Microprocessor Forum in October. I liked the article (written by the Sun engineers) about the UltraSparc-III - not only was it interesting (and I like Sun's approach) , it helped me figure out the inherant problem with the IA-64 architecture...

MAJC home page . See the docs home page - introduction, and a "community" page .

They haven't really released enough details (on their website) just yet, but it does look interesting. One of the more obviously different attitudes the specification takes is highly customisable implimentations - you design a variation targeted at a particular application, whatever that might be - graphics accelerator, MP3 player/decoder, MPEG2/DVD decoder, or a more general purpose chip. Since it is mostly being targeted at embedded applications this is not surprising though.


Some other interesting aspects include:

'Support' for JIT/access-time compilers - not only does this help Java, but it is to make backwards compatability with older versions quite simple. This seems a bit like what Transmeta are doing, which was co-founded by an ex Sun guy btw.

Hardware support for ultra-fast thread switching - so fast that if one thread stalls waiting for DRAM access (which can take up to 100 clock cycles), you can switch to another thread rather than go idle. On many current OSs threads will be switched if the current one has to do some slow I/O say (ie read from disc) - so this is quite an improvement.

A more general approach to improving parallelism - you can have more than one CPU core in a single physical chip, which might or might not share their 1st level caches. (read this Microprocessor Report article for some background on this.) IBM are apparantly going to do a version of the PowerPC G4 which has 2 CPUs on one core, and I kinda suspect Sun might be planning something similar for their UltraSparc-V.

I'm not sure how Sun plan to make money of the design. It seems pretty likely they might do something like their "community source" model - you can get the design for free, but if you want to use it commercially you pay a license. ARM is doing well just licensing their CPU designs. I'd image Sun using to 'assist' their servers as add-on boards for doing heavy multi-media/3D graphics stuff - can you say "render farm"? Also, since Sun like selling their servers, they'd be happy for people to make lots of little, cheap devices that connect to nice big Sun servers.

Like the original poster said, IEEE Micro will probably have some interesting stuff, but it seems Sun aren't releasing all the details yet - looks like we'll have to wait until the Microprocessor Forum in October. I liked the article (written by the Sun engineers) about the UltraSparc-III - not only was it interesting (and I like Sun's approach) , it helped me figure out the inherant problem with the IA-64 architecture...

DataOutputStream methods say they're big-endian, so I don't see your problem.

Unrestricted net access requires that the user trust your applet - JDK 1.2 has an excellent security framework for expressing this, but Netscape is too befuddled and Microsoft too stubborn to bother to support JDK 1.2 (it's only been around for a year or so). The plugin gives you both of them and Opera too, if you're on a platform Sun has managed to provide it for.

What really bugs me about this is whole thing is that these companies (prompted by the DA) are claiming that by looking at their source code, Mitnick caused them damadges equal to the development cost of the software. Unfortunately, the judge seems to be too clueless to know any better. How frightening.

If you do a little digging, you will find that Sun's claims against Mitnick carry no weight at all. They claimed $80 million in damages based on mitnick having solaris source code. If you go to their web site (http://wwwwswest2.sun.com/edu/programs. html) you will find the following:

Sun firmly believes that students and teachers need access to source code to enhance their technology learning experience. Source code is available for qualified educational institutions.

Even if you don't qualify for the gratis source code, You can get it for $100 - details at http://wwwwswest2.sun.com/edu/sol aris/source.html If ever there was a smoking gun, you're puffing it.

What really bugs me about this is whole thing is that these companies (prompted by the DA) are claiming that by looking at their source code, Mitnick caused them damadges equal to the development cost of the software. Unfortunately, the judge seems to be too clueless to know any better. How frightening.

If you do a little digging, you will find that Sun's claims against Mitnick carry no weight at all. They claimed $80 million in damages based on mitnick having solaris source code. If you go to their web site (http://wwwwswest2.sun.com/edu/programs. html) you will find the following:

Sun firmly believes that students and teachers need access to source code to enhance their technology learning experience. Source code is available for qualified educational institutions.

Even if you don't qualify for the gratis source code, You can get it for $100 - details at http://wwwwswest2.sun.com/edu/sol aris/source.html If ever there was a smoking gun, you're puffing it.

Quite strange that assertions are popping during the verification processes. Something must be wrong, because it would be far too easy to kill the VM with bad byte codes.

Anywho, if you generate valid byte codes, you'll pass verification. Knowing exactly why you don't pass would be handy...

Sun also has a beta IPv6 driver for solaris7.
Sun IPv6 prototype for Solaris 7 FCS

Just because they are releasing drivers early is in it self a bad thing.

If you want to use server-side Java, at least use the Servlet API. There are plenty of open source implementations of it, and it means you'll be able to port your code to other web servers if you need to.

More info Sun's web site.

Maybe he's thinking of the Java Media Framework. It isn't a ready-to-go streaming solution, but you could easily build a streaming system with it. (Of course, who knows what the memory requirements would be...)

There is a rumor going around that Solaris8 will be IPv6 ready. But if you want to play around with IPv6 on your solaris box, you are welcome to try.

Just so you don't think the commercial unices don't want to play with linux.

They haven't outright and clear said so yet, but there are very strong hints that they plan to make most, and perhaps eventually, all of their software "community source".

At the JavaOne developer conference recently, this is what Bill Joy said:

• Finally, in order to get all of this to work, we've been searching ever since we started Sun almost 20 years ago now for finding ways to work with you all. The JavaOne conference is an incredible example of a community of people getting together and doing great things. We originally started with the idea of "open systems", which means that we'd publish APIs and sell implementations, but that many people could produce implementations of those APIs.

  Next there's this idea for the Java platform. We tried to create a community and protect it from a predatory company that we were aware of that was likely to try to attack us with contract law, and discovered that contracts sometimes aren't enough to protect us because not everyone thinks they apply to them.

  So what we've decided to do going forward is to try to work from a notion of community. You've seen the Java Community Process (JCP). The JCP allows stakeholders in the different areas, like the people who care about realtime to define the realtime stuff, and that's a really good thing.

  More recently we've done Community Source, which is an attempt to blend the best things about open source and proprietary models together with the added benefit from open source that when you take a Community Source license, you're allowed to make proprietary enhancements to it. We still insist that you leave the APIs open, but you can take large chunks of commercial money and make commercial investments. This works for companies.

  The open source model works for other communities, and for them it's great. But we wanted to come up with a model that would work for traditional companies as well, so that we could quickly move into Community Source as much of our intellectual property as possible, and hopefully all of it going forward. But we insist also that people remain compatible.

  So Community Source has an additional right and an additional responsibility relative to open source. We've done this with a lot of our technology already, including picoJava, and Java and Jini technologies. We'll be doing it with more.

I think they way they're going with Jini is pretty good. They could do better for Java though. They're being kinda closed about what they're going to open though, and have only dropped hints and not made definite statements on their website.

However, some things they have hinted/said are: they will open up Solaris later this year. Also, on one of their Solaris pages they say they'll be making a new version of Solaris (presumably Solaris 8) available under their "easy access" (ie beta) program - they've never done that before. They also seem to be working on making their C/C++ development software and compilers available, and to Linux users as well - to help develop code that works on Linux and Solaris more easily. They've also made other things not mentioned in that article available under their "community source".

They do seem pretty serious about it.