Slashdot Mirror

I'm not going to repeat my arguments. Read them again. And if they're deficient, put out the deficiencies. Just saying "you're wrong" wastes both our time.

I've just realized that this whole argument is about a hypothetical. The Google white list does include Threads. Too bad.

So really, what we're arguing about is whether Google App should support every single class in the Java SE core class list. I don't even know what classes are missing from the White List. It looks pretty complete to me. To find the missing ones, I'd have to do a diff, and there doesn't seem to be a single files that lists all the official core classes. (There's a list of classes in the Javadoc, but not all of these are core.) It would be a lot of work to assemble a list from the core package list.

You do it, since you feel the Java Portability Apocalypse is at hand. Then do a diff and tell me why I should care about the missing classes. But I'm done with straw man hypotheticals like "what if they did away with System" or "what if they took up human sacrifice"?

So, maybe the could put some of it to use building a cloud of their own.

They area

The nice thing with Java development is it's portability. It's why the specification process can be a pain. It comes in handy.

An app I built for a client was deployed at a host that kept having problems, including being hacked. Because of standardization in the spec, the application could be deployed on a different server, using a different app server brand without any issues.

With Google App Engine, you can't do that. You have to specifically code for it. It' smore than just using their api's. Some things you would have on a normal java webapp server, you won't have with App Engine. So you can't just transfer an existing app and you might not be able to transfer away from it.

This may seem like a non issue for people working in PHP or something similar where there is one vendor, but the Java Community Process is good for vendors. It allows multiple vendors to compete to make a better implementation of the spec.

Threads is a disaster. [...] Sun itself would much prefer that everybody switch to the new Concurrency classes, which are not only much more reliable, but a lot easier to use.

"Threads is a disaster"? What are you talking about?!

If you don't have the ability to spawn multiple threads, the concurrency classes don't do squat.

What use is a read/write lock if I'm stuck in a single-threaded model anyway!?

If you want real problems, try running Java apps on a shared hosting provider sometime. The limitations of those sites will have you shouting praise for what Google is offering.

The problem you're referring to is a well-known limitation of the java platform with a planned solution. The problem is that it's been stalled and hasn't made it past the JSR stage despite being first reviewed in 2001.

See either: Project Barcelona or the Java Isolates JSR.

That combined with the Java Resource Consumption Management API would, if implemented, give application server vendors everything they would need to make a Servlet container that could be used in a shared hosting environment.

Until then, Java just isn't suitable for a shared hosting environment...at least not in the out-of-the-box kind of way. I have managed to string together a thin C CGI implementation that uses IPC to connect to a running Java process through JNI. It worked and actually substantially out-performed any of the scripting languages available from the hosting provider, but it took quite a bit of work to get running (mostly emulating what the Servlet API gives you for free) and the code I ended up with might not be portable to a real Servlet environment since I didn't bother implementing all of the Servlet API.

Long story short...I've felt that pain and can't wait for those two JSR's to make it into a new release of Java. I only wish Google's Java API had been available at the time.

This article writer is a tool. Interestingly enough, most of these restrictions (no filesystem access, no sockets, no spawning threads) are EXACTLY the same restrictions as recommended by Sun for EJB: http://java.sun.com/blueprints/qanda/ejb_tier/restrictions.html

Specifically, enterprise beans should not:

• use the java.lang.reflect Java Reflection API to access information unavailable by way of the security rules of the Java runtime environment
• read or write nonfinal static fields
• use this to refer to the instance in a method parameter or result
• access packages (and classes) that are otherwise made unavailable by the rules of Java programming language
• define a class in a package
• use the java.awt package to create a user interface
• create or modify class loaders and security managers
• redirect input, output, and error streams
• obtain security policy information for a code source
• access or modify the security configuration objects
• create or manage threads
• use thread synchronization primitives to synchronize access with other enterprise bean instances
• stop the Java virtual machine
• load a native library
• listen on, accept connections on, or multicast from a network socket
• change socket factories in java.net.Socket or java.net.ServerSocket, or change the stream handler factory of java.net.URL.
• directly read or write a file descriptor
• create, modify, or delete files in the filesystem
• use the subclass and object substitution features of the Java serialization protocol

Um... no. They're not supporting Threads for a start - which is pretty major.

A major improvement. It's now accepted on concurrency wonks (including, no especially, the ones at Sun and Google) that Threads is a disaster. Sun itself would much prefer that everybody switch to the new Concurrency classes, which are not only much more reliable, but a lot easier to use.

... and seems to use threads.

Um... no. They're not supporting Threads for a start - which is pretty major.

A major improvement. It's now accepted on concurrency wonks (including, no especially, the ones at Sun and Google) that Threads is a disaster. Sun itself would much prefer that everybody switch to the new Concurrency classes, which are not only much more reliable, but a lot easier to use.

Seriously. We all know the internet is limited. Fits in a shipping container.

Does that mean we can put it on a big truck...?

you think that the internet is unlimited

Seriously. We all know the internet is limited. Fits in a shipping container.

You know, I guess it depends. I wouldn't port an application from Perl to something else. But I'm not sure I'd base a new project on Perl either.

There are some things about perl that could be fixed that might change my mind:

1) Dump Perldoc and liberally rip from javadoc and XML comments. I know both of these got their start from perldoc, but perldoc needs to catch up.
2) Make sure the IDE actually uses said docs. Once your IDE's intellesense sucks up your comments and uses them while you are typing in a method, you are rewarded for documenting your stuff. Nothing like positive feedback to encourage good habits.
3) Finish EPIC. Perl needs IDE support. Syntax coloring and auto-indentation does not make for an IDE.
4) Get rid of this my $blah_param = shift; crap and start making function declarations that work like everybody else: sub myDopeFunction($blah_param){}. This coupled with perldoc's suckage lead to hard to maintain code
5) Give a couple million to the Template::Toolkit guys. They rock.
6) Mystery option.

The "problem" isn't unique to Javascript. Read What Every Computer Scientist Should Know About Floating-Point Arithmetic.

Do you mean you wouldn't run a production server as a VM image or you wouldn't run it using a VM image you did not create yourself?

The latter. Recall that TPP thought that VM appliances made installation how-tos obsolete. That was the idea I was pooh-poohing.

As it happens, I'm the documentation lead for a server for which virtualization is very important. A very common use case for this system is "consolidation": you take a rack full of low-end servers each handling a separate application, and convert them all into a single machine running each application in a separate VM. Savings in power and real-estate cost can be enormous. VMware support is a key feature (of course), but Sun is also pushing its own Xen-based solution.

Do you mean you wouldn't run a production server as a VM image or you wouldn't run it using a VM image you did not create yourself?

The latter. Recall that TPP thought that VM appliances made installation how-tos obsolete. That was the idea I was pooh-poohing.

As it happens, I'm the documentation lead for a server for which virtualization is very important. A very common use case for this system is "consolidation": you take a rack full of low-end servers each handling a separate application, and convert them all into a single machine running each application in a separate VM. Savings in power and real-estate cost can be enormous. VMware support is a key feature (of course), but Sun is also pushing its own Xen-based solution.

I attended a pretty cool talk on Real-Time Java some years ago, in which the Sun guy said they have in fact been pitching it for spacecraft embedded system use for ages - it's impressive technology, and up to the job. Success has been limited though, because as good as the JVM is these days it still needs more RAM than VxWorks (NASA's weapon of choice), increasing launch mass by a small but significant amount.

http://blogs.sun.com/brendan/entry/test has some background information, and http://blogs.sun.com/brendan/entry/l2arc_screenshots and http://blogs.sun.com/brendan/entry/my_sun_storage_7410_perf has some performance numbers.

Basically, what Sun is claiming is that by adding a SSD cache layer you can improve IOPS by about 5x, for what amounts to a really small amount of money for say a 100tb system. This is being marketed quite heavily by Sun as well. (The numbers look convincing, and the prices for the Sun Storage servers are certainly very competitive, well, compared to say NetApp.)

IMHO this is just a repeat of the well known Microsoft tactic of spreading massive amounts of FUD about any competing technology that you can't reproduce yourself - you'll have to wait until Windows Server 2013 for this.

http://blogs.sun.com/brendan/entry/test has some background information, and http://blogs.sun.com/brendan/entry/l2arc_screenshots and http://blogs.sun.com/brendan/entry/my_sun_storage_7410_perf has some performance numbers.

Basically, what Sun is claiming is that by adding a SSD cache layer you can improve IOPS by about 5x, for what amounts to a really small amount of money for say a 100tb system. This is being marketed quite heavily by Sun as well. (The numbers look convincing, and the prices for the Sun Storage servers are certainly very competitive, well, compared to say NetApp.)

IMHO this is just a repeat of the well known Microsoft tactic of spreading massive amounts of FUD about any competing technology that you can't reproduce yourself - you'll have to wait until Windows Server 2013 for this.

http://blogs.sun.com/brendan/entry/test has some background information, and http://blogs.sun.com/brendan/entry/l2arc_screenshots and http://blogs.sun.com/brendan/entry/my_sun_storage_7410_perf has some performance numbers.

Basically, what Sun is claiming is that by adding a SSD cache layer you can improve IOPS by about 5x, for what amounts to a really small amount of money for say a 100tb system. This is being marketed quite heavily by Sun as well. (The numbers look convincing, and the prices for the Sun Storage servers are certainly very competitive, well, compared to say NetApp.)

IMHO this is just a repeat of the well known Microsoft tactic of spreading massive amounts of FUD about any competing technology that you can't reproduce yourself - you'll have to wait until Windows Server 2013 for this.

I'd say Microsoft does not have any "solution" in which SSD would help.

OTOH Sun does ... http://www.sun.com/storage/flash/. YMMV.

Isn't that what Java Web Start does?

Solaris on SPARC has device drivers in user-space.

According to the Sun website, for Solaris 10:
Device drivers run in kernel mode and are prevented from directly accessing processes in user mode.

The 'add_drv' command on Solaris does the exact same thing that the 'insmod' command does on Linux, that is dynamically linking device driver modules into the kernel.

You are confused.

Hmmmm - and have you noticed that the changelog incorporates almost all of these technologies?

I think the poster merely stated the most recent innovations to show ones that the majority of the slashdot posters would be familiar with.

Check out this link, for a list of Sun contributions...
http://mediacast.sun.com/users/pgdh/media/sum_of_parts_v2.8a.pdf

I'll highlight just a few, probably found in your beloved *BSD* as well..

NFS, NIS, XDR, Posix, SVR4, mmap, Streams, ld.so, diskless boot, autofs, rpc, news, abi, xdr, vfs.... /proc, truss, nsswitch, ptools, dynamic kernel, smp, domains, libthread, nis+, vold, jumpstart

hls, mpss, pools, fss, zones, brandz, s8ma, mdb, dtrace, fma, pgrep, smf, mpo, least privelege, zfs

and for additional software contributions...

JAVA, OpenOffice for starters...

Now.. this list is not all inclusive... but I think it shows a more than fair share of technologies, a lot of which are considered to be *common* tools, that would either not be here, or would not be what they are today, without Sun's contributions...

Solaris itself has a per-node licensing cost which makes it less attractive in a clustering environment.

.
Can you point me to a page on Sun's web site describing how much the OS costs? All I can find are the free download pages. By the way, Redhat doesn't have free binary downloads like Sun does.

Or are you referring to per-node support contracts, just like Redhat has? .

OpenSolaris is a terribly immature platform

.
OpenSolaris is based on and is the development platform for Solaris. Solaris is older than Linux.

You've also made disparaging comments about Solaris/x86. Solaris is written to be portable and has run on SPARC, x86, PowerPC, and Itanium with 99% common code. .

You may have noticed that Linux runs on the lower-end Sun equipment worth building clusters out of, and that IBM sells more Linux clusters than AIX clusters. Solaris is going away just like AIX is going away and like we all wish HP-UX would go the fuck away.

.
I thought you just said that Sun doesn't sell equipment that can run reliable clusters?

It sounds like you are just bitter about Sun or Solaris for some reason without having all the facts about them.

I was specifically talking about your claim that 1 Power6 core was only 43% faster than 1 T2 core

That wasn't my claim. I pulled that directly from the IBM blog.

IBM Power 570 4 cores, 2 chips 1,197.51 JOPS = 299.3775 JOPS/core

Sun SPARC Enterprise T5240 16 cores, 2 chips 3,331 JOPS = 208.1875 JOPS/core

(299.3775/208.1875) - 1 = 43.8%

The T5440 is also cheaper than an IBM p570.

What Pat Gelsinger recently said comparing the new Xeon 5500 processors with Sparc and Power cpus.

The 5500 was 1.7x the performance and 1/2 the cost.

Comparing to IBM power was "almost humorous" at 2.5x the performance at 1/10th the cost.

Here's some more information comparing the two running Siebel. The UltraSPARC T2 servers perform better and are much cheaper than IBM's

If only Sun's marketing was as good as IBM's to get you to believe that paying 10x the price for the same performance was a good deal, this thread wouldn't exist.

Noooo! I've always thought Sun had the most ingenious logo (designed by Stanford Prof. Vaughan Pratt, lead designer of the original Stanford University Network (SUN) workstation)

I've got just the thing for you.

those are SATA disks (not SAS)

SATA and SAS both rate as "commodity" technologies. In the server world, you don't pay extra for SAS unless you really need the higher burst speed and reliability.

I work for Sun, and most of our servers take SAS or SATA. That's not hard to do, because spec-compliant SAS host bus adapters also support SATA drives. (Which should tell you about the importance of SATA in the server world.) The exceptions are our storage servers, which are SATA only.

It's not just Solaris.

According to this, in 2006, sun was the leading corporate contributor to open source projects that were in the Debian distro.

Here's another look at Sun's open source contributions.

Why did you pick Debian as a metric?

Because that's one of the most comprehensive studies performed on corporate contributions to open source. I'm not in a position to take the time and resources to do my own study. Here's another look at how much Sun has contributed to open source.

Debian is also a popular distro that many other distros are based on. (Ubuntu, Xandros, KNOPPIX, DSL, Linspire)

The Linux Kernel is is not the only Open Source or Free Software project out there. I'd argue it's not even the most important one. If the linux kernel one day disappeared, the rest of the open source world could continue. But without the rest of the open source world, the linux kernel is worthless.

Have you ever had IBM salespeople come in to spec out a project? You might be surprised what they have to say on AIX vs Linux. This document is old, but still available on the IBM website. It talks about how AIX is better than Linux.

Bare with me for a moment.

Sun is full of PhDs, patents and interesting technologies and I think their corporate culture is much more close to Apple than to IBM. They have a fairly decent server product line with competitive prices, a host of enterprise contracts all over the world and an excellent OSS "server" OS which is still being developed heavily. They have a solid 64-bit RISC architecture coupled with energy efficient multicore processors that give even the best x86 chips a run for their money. Not to mention their storage strategy which is, IMHO, brilliant. ZFS, StorageTek, Lustre, fishworks, mysql all fall into a strategy of acquisitions and development that was commenced several years ago. Has it started yielding financial results yet? Arguably not quite. Was it spot-on? Hell yes. Storage has come and it will be big. The bad economic conditions make their financial problems worse, but it's not like they didn't give their best.

Apple could really use them to buy its way into the Enterprise. They have already ported dtrace and zfs to MacOSX, demonstrating that a lot of technologies can be used outside of Sun products with success. Considering the stockpile of cash they're sitting on, it would not really be a problem for Apple to buy them. With their combined strength (heard that one before, right?) they could really be a dangerous adversary for IBM, HP and Microsoft.

Well, if that isn't a pipe dream, then what is?

Since 5.0 Netbeans has made tremendous improvements and now the combination of Glassfish and Netbeans is a powerhouse for J2EE development. That is real competition for Websphere Studio which costs a heck of a lot of money.

With EJB3, using EJB's even for smaller projects, using the full J2EE stack is reasonable. The complexity and performance overhead of EJBs is no longer a problem and it makes it very easy to deploy restful web services.

There's a great video on the matter from an independent developer at CommunityOne east recently. You can see the video here. When you get to that page click on the link for Video: Netbeans 6.7 and Glassfish v3. It's the third video.

My favorite quote was about which one is better, Netbeans or Eclipse. The answer was IdeaJ but it's not free :)

I just ran across this link that shows where sun modular datacenters have been deployed. Looks like a couple dozen. Dosn't give much information on them thouhg.

You had all the drives set up as one raidz2 array? From what I understand, that's not the best way of doing it. I can't find the link but there was an entry on blogs.sun.com about how it's better to use a number of raidz's in a pool than have the pool consist of a single raidz array. Here's an example of that zfs configuration. And here's one that discusses performance and MTTDL.

I was under the impression that the boards use the same type of daughter card that the TYAN server boards use. Raritan makes an IP KVM card for those boards. Have you tried contacint Raritan to see if you could use that instead?

You had all the drives set up as one raidz2 array? From what I understand, that's not the best way of doing it. I can't find the link but there was an entry on blogs.sun.com about how it's better to use a number of raidz's in a pool than have the pool consist of a single raidz array. Here's an example of that zfs configuration. And here's one that discusses performance and MTTDL.

I was under the impression that the boards use the same type of daughter card that the TYAN server boards use. Raritan makes an IP KVM card for those boards. Have you tried contacint Raritan to see if you could use that instead?

That video was posted by Sun in 2007: here

I don't know about the other areas but in J2EE servers you can push Glassfish
It's the Sun J2EE server, it has support and is used by several imporant enterprises. Read here
And I do not work for Sun :)

Sun has more information and an Interactive tour of the Internet Archive modular data center on their site.

The total raw capacity of the container is 3 peta bytes. In reality it's going to be less than that. First, 2 disks are likely to be setup in a mirrored pool for the system disks. I believe the root pool only supports mirrors, not raidz. Not sure if this has changed.

That leaves you with 46 disks for data. Maybe they partitioned part of the root pool to include in the data pools, not sure, but zfs works better with whole disks.

In the interactive tour, they weren't clear on how they set up the pools.

Side note. Maybe I'm cynical, but if this was the other way around, with linux servers replacing sun/solaris servers that probably would have been the headline.

Pretty neat to find out that the internet archive is powered by Java too. The wayback machine is java as well as the crawlers.

This seems to be an exact use case for the X4500-type system, which as far as I'm aware is pretty unique.

Indeed. Sun is on a density kick. Check out the X4600, which does for processing power what the X4500 did for storage.

In both cases, there actually are competing products that are sort of the same. The most conspicuous difference is that the Sun versions cram the whole caboodle into 4 rack units per system, about half the space required by their competitors.

More absurdly-dense Sun products:

http://www.sun.com/servers/x64/x4240/
http://www.sun.com/servers/x64/x4140/

The point of these systems is that they take up less expensive rack space than equivalent competitors. They're also "greener": if you broke all that storage and computing power down into less dense systems, you'd need a lot more electricity to run them and keep them cool. That not only saves money, it gives the owner the ability to claim they're working on the carbon footprint.

This seems to be an exact use case for the X4500-type system, which as far as I'm aware is pretty unique.

Indeed. Sun is on a density kick. Check out the X4600, which does for processing power what the X4500 did for storage.

In both cases, there actually are competing products that are sort of the same. The most conspicuous difference is that the Sun versions cram the whole caboodle into 4 rack units per system, about half the space required by their competitors.

More absurdly-dense Sun products:

http://www.sun.com/servers/x64/x4240/
http://www.sun.com/servers/x64/x4140/

The point of these systems is that they take up less expensive rack space than equivalent competitors. They're also "greener": if you broke all that storage and computing power down into less dense systems, you'd need a lot more electricity to run them and keep them cool. That not only saves money, it gives the owner the ability to claim they're working on the carbon footprint.

I don't think that's right. Sun's site has a video tour of it. Haven't finished it yet but it's here.

The new data center houses 63 Sun Fire servers

That's not very specific. "Sun Fire" is a brand that for a while got applied to all of Sun's rack-mount servers (except for NEBS-compliant servers, which were and are called "Sun Netra"). A little confusing, of course, which is why they've started calling new SPARC boxes "Sun SPARC Enterprise" to differentiate them from those mangy x64 "Sun Fire" systems. Except that there are still SPARC systems called "Sun Fire", so I guess the confusion factor didn't get any better...

Anyway, the specific server being used here is the Sun Firex X4500, a system with no less than 48 1 TB disks in a 4U space. Notice that this model is EOLed; presumably iarchive got a deal on some remaindered machines.

The shipping container is something we've seen before.

...if you want the state of the art in data integrity. (Checksumming, transactional copy on write, self healing, simple pool management, snapshots, filesystems, etc.) Read more: Solaris 10, OpenSolaris.

Linux seriously needs to find a workaround to its licensing squabbles and find a way to get a rock-solid ZFS in the kernel. Right now, ZFS on OpenSolaris is simply wonderful, and this is what I am deploying for file service at all my customer sites now. The scary thing about file system corruption is that it is often silent, and can go on for a long time, until your system crashes, and you find that all of your backups are also crap. I've replaced a couple of linux servers (and more than a couple of Windows servers) after filesystem and disk corruption compounded by naive RAID implementations (RAID[1-5] without end-to-end checksumming can make your data *less* safe), and my customers couldn't be happier. Having hourly snapshots and a fast in-kernel CIFS server fully integrated with ZFS ACLS (and with support for NTFS-style mixed case naming) is jut icing on the cake. Now if only I could have an Opensolaris desktop with all the nice linux userland apps available. Oh wait, I can!

You don't want to store the same data in multiple places. Your query might run faster, but your data integrity is going to suck.

I wonder if normalization is going to be less important as de-duplication gets integrated into more file systems.

It's going to be a part of ZFS later this year I think. It looks like it's going to be a block level implementation within ZFS rather than file level. Since ZFS uses a copy on write model it seems fairly easy for them to implement compared to other file systems.

Databases that work on top of existing filesystems could benefit from this whereas databases that use block level addressing (Oracle) may not, but they might be dealing with this in other ways.

It kinda makes sense. Build your DB for the best performance and let the underlying file system handle normalization.

I don't know enough about the tech to determine if this would be an applicable usage but I don't see why not.

You may also want to look at some free, but not foss solutions. I know that Sun's Java Communications Suite is freely available and offers pretty much everything that exchange offers, including a pretty ajax-enabled web interface and an Outlook plugin so that it works just as if it were an Exchange server.

And then there's the foss solutions like Zimbra, etc.

Jonathan Schwartz put out a series of 4 videos on his blog (YouTube versions here) where he outlines the strategy you mentioned.

It seems to make sense. The economic downturn really hurt sun because a lot of it's big clients in their high margin areas were on Wall St.

I hope they work through it because they're a very innovative company for their size. For example, Intel still hasn't released their 8 core (2 threads per core) chips yet, while Sun has had 8 core 8 thread per core chips for a while now. They are even able to run them in multi socket systems.

Even a watered down version of the cloud, say for storage has inherent security issues. How do you control what data goes where, who accesses it, how do you secure it, etc.
If I got it correctly, SUN will provide cloud under roof â" cloud is owned and controlled by the company using it.
From http://blogs.sun.com/jonathan/entry/unified_computing

Third, unlike our peers, we also announced our cloud will be available for deployment behind corporate firewalls - that we'll commercialize our public cloud by instantiating it in private datacenters for those customers who can't, due to regulation, security or business constraints, use a public cloud. We recognize that workloads subject to fiduciary duty or regulatory scrutiny won't move to public clouds - if you can't move to the cloud, we'll move the cloud to you.

All this cloud nonsense is silly. Most end-users and businesses have invested way too much money in powerful workstations, desktops, and laptops, to justify scrapping them in favor of ultralights depending on cloud computing. It's just a marketing pipe dream.

The version of the cloud they are releasing is similar to the Amazon EC2 platform. It is not currently aimed at "workstatinos, desktops and laptops" as you said. The primary focus seems to be for startups and other companies that need an easy way to grow their infrastructure without having to make a big investment in hardware.

One example is a merchant that does 90% of their business around Christmas. Instead of having a rack full of expensive computers in a colo facility sitting 90% idle most of the year, they can expand their capacity just when they need it and save a lot of money.

Sun put up some videos from a recent conference where they annouced the Sun Cloud.

It's very cool. Think about all the times you've developed your dream infrastructure and maybe drew it out in Visio or Dia, except when you're adding shapes into your network diagram, actual virtual servers are being deployed.

At least that's what the demonstration shows.

Now lets say you're having a problem with your appllcation and you don't know where it is but you have to do some stress testing to figure it out. You can't do that to your live system.

You can essentially copy and paste your whole production configuration as a test environment, run your tests, profiling, fix your application, then delete the whole setup and never have to pay for it again. You can't do that with real hardware.

You could do the same with a development environment. And it seems you only pay while it's running, so you launch it from 9-5 (ok 11:30ish to 4:19pm) and turn it off the rest of the time to save money. Should be much cheaper than buying twice as many real servers.

Here are the instructions for installing 1.1 on Linux (haven't tried this myself):

http://java.dzone.com/tips/javafx-11-linux-netbeans

And OpenSolaris (not sure if they work with 1.1, I haven't had time to try):

http://blogs.sun.com/observatory/entry/javafx

The reason JavaFX is not officially available on Linux and OpenSolaris is because they haven't solved the media rendering issues on those two OS's, so they can't offer the full non-beta versions.

Besides, if JavaFX doesn't work completely on Sun's *own* OS, then you know that there are substantial issues still to be resolved. It has nothing to do with any vindication against open source.

Sun CEO Jonathan Schwartz continues to promote the use of Open Source...

Strange words considering that JavaFX is only for Windows and Mac. The promised linux and solaris release is nowhere to be found, and the hacks for installing the 1.0 mac version on linux were broken in the javafx 1.1 (also Windows/Mac only) release.

When Schwartz talks about the "cloud", I think he's really talking about vaporware.