Slashdot Mirror

I'm not sure why this problem occurs for me and not for you. I'm attempting to run NetBeans 6.1 with Sun's JDK 1.6.0_06 (64-bit) on an Ubuntu 8.04 box (amd64) and displaying it on an Ubuntu 7.04 box (also amd64). It turns out that Netbeans was not hung, it was just REALLY slow. Slow as in "takes a minute and a half to draw the screen" slow. I tried your suggestion about the cache directory, but it didn't help. I did get curious, though, and looked into the matter a little further.

I performed some X Protocol analysis on the X11 connection using xmon, and discovered that there was a horrendous amount of activity between the client and the server due to the client trying to update the display a few pixels at a time. As if that wasn't bad enough, it was reading (!!!) those few pixels from the display before updating them and writing them back, which means the loop had to do an XSync() of some sort, so the loop was twiddling its thumbs while waiting for a synchronous round-trip response every few pixels! I took a look at the source code for OpenJDK and NetBeans, and after learning more than I ever wanted to know about the Java Swing -> Java 2D -> X11 graphics pipeline, I found out I could fix the problem by setting the "sun.java2d.pmoffscreen" property to "false" in netbeans.conf.

The key ideas are in Sun's white paper Graphics Performance Improvements :

One drawback with both remote X and DirectDraw is that neither antialiasing nor alpha-blending can be accelerated. In fact, antialiasing and alpha blending operations on remote X are usually much slower compared to version 1.3 because the image must be copied to the X client to perform one of these operations and then the new image must be copied back to the server. ...Since most Swing applications do not use alpha blending or antialiasing anyway, this problem should not cause serious concern for developers using Swing.
...
Starting with the Beta 3 release of the SDK, version 1.4, Java 2D stores images in pixmaps by default when DGA is not available, whether you are working in a local or remote display environment. You can override this behavior with the pmoffscreen flag:
-Dsun.java2d.pmoffscreen=true/false
If you set this flag to true, offscreen pixmap support is enabled even if DGA is available. If you set this flag to false, offscreen pixmap support is disabled. Disabling offscreen pixmap support can solve some rendering problems.

I suppose they didn't have NetBeans in mind when they wrote "most Swing applications do not use alpha blending or antialiasing anyway." Unfortunately, disabling offscreen pixmap support also disables antialiasing, so the fonts don't look nice and pretty like in Eclipse, which manages to support antialiasing on remote X displays somehow via its SWT/GTK+/X11 stack.

Now that I have NetBeans working somewhat tolerably, I guess I can begin evaluating it now. But not until I get some sleep. :)

Nice to see this out. However I am disappointed that PDF import even when it is ready will only be added as an extension. It should be part of the core. I was also hoping for a few more big features. Even the improved Crop feature in Draw/Impress was a feature that a developer did as a side job in is free time http://blogs.sun.com/GullFOSS/entry/improved_picture_cropping_for_draw Will 3.0 include some of the features that were forked off with Go-OO http://go-oo.org/ ? ie: -SVG support - So we can import Inkscape documents ... remember SVG is a standard also. -MS-Works import - This would be nice as many home users use this as it cost less then MS Office -Improved EMF rendering - I have not done this in a while but EMF quality was poor -WordPerfect Graphics import -GStreamer integration -Rich fields support - some of the features OOo people said they would not support. -Other Go-oo features I am not trying to start a turf war, but there are some nice features. I would think that there might be time to integrate some of existing code i.e. Works support etc into OOo before 3.0 is final. AS the other features have been sitting in Go-oo they might be considered stable enough to port back to OOo at this beta stage.

Yes, is says:

" Available Soon... PDF Import Extension
The PDF Import Extension allows modifying existing PDF files for which the original source files do not exist anymore. "

However, that was August 2007.

Read the comments on the blog (below that link, they are totally unrelated).

Also, if I'm not mistaken, sun is selling the thing with an "non-production" version of solaris: http://www.sun.com/servers/x64/x4500/
(read the heavily bolded line containing the words "Open Solaris")

Of course, I'm not saying that ZFS isn't a bad thing. I'm a ZFS root on one of my (non-production) systems right now.

You should read my response above to the previous reply.

In addition let me add some history of SYSVR4 which explains why suing Sun over SYSVR4 is so funny.

In 1988 I believe, AT&T and Sun got together to work on SYSVR4. SunOS was primarily based on BSD at the time and a lot of BSD bits went into SYSVR4. Bill Joy, a founder of Sun was also a leading developer of BSD. AT&T and Sun handed off the rights to a seperate entity, Unix Laboratories, to handle licensing so that others can implement it. Sun always pushed for open standards, before open source was that popular.

Solaris is based on SYSVR4. You can see the relationship here. Solaris developed on it's own after it's SYSVR4 base. As did UnixWare. What Sun needed for Solaris 10 was better x86 support. SYSVR4 did not provide that. UnixWare did. At the time UnixWare had a large i386 deployment and good drivers to support that platform. So it makes sense that if Solaris got anything from SCO it related to UnixWare. Other than the x86 support, I don't think anyone can argue that UnixWare was better than Solaris.

Imagine if somewhere down the line, someone sued Linus over his use of Linux.

The problem the APA has is that it gives different treatment to UnixWare than it does to SYSVR4. Basically, SCO can do what it wants with UnixWare and Novell's lawyers are trying to separate the UnixWare parts from SYSVR4 which doesn't make much sense. It's like if you buy a source license for Windows 3.1 which is built on Windows 3.0 but you don't have rights to the code in Windows 3.1 that is from Windows 3.0.

Another interesting thing, the thing I think has Novell, IBM, and HP worried, is that in that simplified Unix History Tree. Solaris is the only Unix still on there. AIX, HP/UX, Irix are all gone. That indicates to me that Solaris still has value. UnixWare I believe is still on there because of the SCO trial. The original Unix History Tree is a mess and unreadable but you can google it and find it.

Novell and some others would like to get Solaris off the map because they think it would help Linux. To me that's a very short sighted view. I like what Jonathan Schwartz has to say on that issue.

"Company forced to give up revenue stream due to open-source fanatics [...]"

Actually Sun CEO Jonathan Schwartz has explained numerous times in his blog that opensourcing your products increases your revenue stream in the long term. I invite you to read in particular this 2-day old post where he answers the FAQ "Why don't you just stop giving your software away?" and gives precisely the example of MySQL.

You're confusing ZFS with clusterfs GFS is more like Lustre

Sigh. Yes, it does. The point is, Sun needs to deal with _Novell_, not SCO. Sun has been warned by Novell that they do not regard the deal as valid. What Novell is doing is demanding that SCO give them the money that is rightfully theirs from an invalid deal. Once that money is in hand, Novell will decide whether or not to pursue Sun for violation of their original contract.

You're wrong. Sun does not need to deal with Novell. SCO was the licensing agent. Nobody could go directly to Novell for any sort of Unix licensing. That part is clear.

An analogy I made in a previous article was that if you walk into a store, go to the counter and buy something, the cashier takes the money and pockets it, you're not at fault. You did what you were supposed to do and the store owner has to go after the employee for the money, not you.

It was countered by someone giving a different example. You go into a store, the cashier sells you the register, which isn't for sale.

Lets assume the cashier works on commission. The store owner can't demand that the employee give him the store owners cut, then go back to you and get the register back. The store owner cannot and should not be remedied twice for the same violation. If you get in a car accident and your insurance company pays your hospital bills, you cannot sue the driver at fault for your hospital bills as well.

Sun worked with AT&T to create SYSVR4. SYSVR4 also contains a bit of BSD of which Bill Joy (founder of Sun) was one of the leading developers. According to Schwartz. Novell suing Sun over SYSVR4 is like someone suing Linus over Linux.

Schwartz: We took a license from AT&T initially for $100 million as we didnt own the IP. The license we took also made clear that we had rights equivalent to ownership. When we did the deal with SCO earlier this year we bought a bunch of drivers and when we give money to a company oftentimes we get warrants, which is part of the negotiations. I have warrants in 100 different companies, we have a huge venture portfolio. I cant do anything about the perception thats out there and to be blunt, I dont care as those people arent going to drive our futureâ"customers are.

The APA seems to be a poorly written contract. In one way it helped Novell, but in another it shot them in the foot by the provisions it made for UnixWare.

The CEO of Novell has been saying a lot of stuff regarding OpenSolaris. It's all FUD. Novell claimed they would not pursue their rights to Unix previously (I have a link to the article somewhere else). Now they're claiming they are going to?

Novell is a desperate company. Much like SCO was when they started all this. If you look at their quarterly reports, you'll see that most of their revenue comes from legacy products. Their revenues from SuSE is a small fraction of total revenues. Their Identity Management Solutions do pretty well but lately revenues have been flat.

So basically, Novell tried to purchase Unix to defend NetWare against MS, then they tried the same with SuSE and while their Linux lines is growing, the company isn't really doing much better financially.

One thing I read was that Ray Noorda, who started Novell and was CEO for a long time, resigned his post at Novell when Novell decided to purchase Unix instead of moving to Linux. I don't know how accurate this is, but the fact that he provided the startup capital for Caldera does give some weight to that comment.

Novell may also be a little pissed because back when they were competing with Sun to buy SuSE, Novell had to fork over a lot more money to counter Sun's bid. They even had to get $50million from IBM to be able to do so. And now Sun owns MySQL which Novell relies on for some of their products and services.

Novell may be saying certain things in court to strengthen their claims against S

I understand your reply, but this is an often requested feature that ZFS devs are aware of and would like to add if they had more resources.

http://blogs.sun.com/ahl/entry/expand_o_matic_raid_z

Having a RAID with parity arrangement does not require equal disks sizes, it's simpler and computationally easier to design but not set in stone.

Let's say I have the $$ for 4 hard drives at this time, and later on want to add a 5th equally sized HD to expand the pool. Or as I suggested before adding larger replacement drives one at a time until the whole pool is replaced.

It would be NICE if RAIDZ could redistribute the data and grow the pool without requiring the large investment of purchasing a whole new set of drives at one time.

A common scenario is a home user has wanted a RAID setup for a long time but can't afford a nice enclosure and a set of disks. What ends up happening is they get a slowly growing collection of external HDs that they buy as space requirements demand it. So maybe a 160GB here, a 200GB there, a 400 and a 500 in a stack.

In dreamland what someone could do is a buy a fresh set of 500GB or so HDs, format them ZFS. Then copy some data onto it, format another HD as ZFS, add it to the pool and continue until all their HDs are part of a RAIDZ.

That's quite a pony isn't it? :-) If you read the blog post above you'll see that it's not entirely unreasonable and it may end up added in the future.

The high level parts of the system may be written in Python but the underlying tools it uses are Java. You can actually run some of the command line tools to save memory.

My home servers are in screaming need of ZFS (A NetApp Filer for home use). I want ZFS implemented in Linux, like everyone else. Moving to a OpenSolaris based distribution just feels awkward and wrong, especially when ZFS has made it into FreeBSD 7.0 as an experimental feature.

I'm eyeballing the FreeNAS project daily. Sooner or later we will have a ZFS appliance, free as in beer at least. Sun have to work harder to win me over but things look promising. (Ubuntu on Sun hardware [+], trying to release Java under an Open Source license [+], closing some MySQL features [-])

The source code (which remaps linux systems calls to open solaris and fudges inconsistencies)

Info on installing debian (it's designed for RedHat based linux, so it's slightly painful ... though possibly out of date).

Brand Z info

Overview of linux support

I haven't tried it, but there shouldn't be much overhead/performance loss.

There's plenty of denying that.

There's plenty of denying that.

Looks fairly clear to me that Sun will Open Source all of MySQL......

http://blogs.sun.com/tpenta/entry/jonathan_on_closed_mysql_extensions

Hasn't Sun had this for a few years now? http://www.sun.com/products/sunmd/s20/index.jsp

You want the most scalable mail-server on the planet? Use Sun Java Communications Suite 5 for free.
https://cds.sun.com/is-bin/INTERSHOP.enfinity/WFS/CDS-CDS_SMI-Site/en_us/-/USD/ViewProductDetail-Start?ProductRef=COMMSUI

Sadly that article was from over a year ago, and he has since grown it back, so it looks like we're stuck with Java again.

On the plus side, he's apparently stoned, which does explain things like "type erasures" instead of true generics.

JDK6u10 solves this. It lets the applet run in a separate process from the browser, and bootstraps the download such that it starts up very quickly. See here for more information.

A lot of /. folks are extremely good programmers, and I think don't realize that what's easy for them is not easy for most people.

C and C++ are an easy languages to write buggy code in. People write working programs in them, and people also write buggy code in every language that anyone has written more than "Hello, world!" in. But this doesn't mean that all languages are equally easy to write bug-free code in. The flexibility and power C/C++ have (which is part of their appeal) also gives you a lot of rope to hang yourself with.

Similarly, lots of multi-threaded programs work, and lots of single-threaded programs are buggy. But multi-threaded programming is much, much harder than single-threaded. Also, the support provided by the language and libraries you use can make a *huge* difference. (The type of app, too, since some types are a lot easier to parallelize than others, but that's OT.)

I would especially like to object to anybody who says "Why are you whining about C/C++? They have pthreads, and that's enough." That's true in the same sense that in theory you could write any program in assembly or describe any computable algorithm in lambda calculus. Yes, you *can* write multi-threaded code in pthreads, but if that's all you have, it's pretty painful. What more could you want? For one thing, higher-level libraries like the Java Concurrency Libraries.

And it's not just a matter of having the "right" add-on concurrency/threading library. If you have a bunch of other libraries, like I/O, for example, that were designed with concurrency in mind, they might all, say, use SIGALARM for timeouts. If the app is single-threaded, no problem, but if not, you're in trouble. So really, you need a whole suite of libraries made to support concurrency.

Because you have an automated installation/deployment tool that does a bare-metal install of everything on a box.

(something like Sun's SPS http://www.sun.com/software/products/sunmanagementcenter/index.xml)

At least, if you're a pro you do.

We support 9 different large-scale, global environments for various development and testing activities (never mind production), and they all run the same installation/update process.

Every night, the ENTIRE system is built, tested, deployed, stress/load/performance tested, etc... all automagically.

If you don't do that, then yes, you are very likely to be prone to such errors.

The 25k is not a mainframe. It is a high-end server. I'm sorry but it had to be said.

All these other languages mentioned (Java, Python, Ruby, PHP, Perl, etc) do not compile to native code, and all do dynamic memory management.

Er, java DOES compile to native at runtime.

But unfortunately they're not so good for real-time tasks.

They can be. For instance, the Real-Time Java dialect of Java was recently picked to run the Eglin Space Surveillance Radar.

All these other languages mentioned (Java, Python, Ruby, PHP, Perl, etc) do not compile to native code, and all do dynamic memory management.

Er, java DOES compile to native at runtime.

But unfortunately they're not so good for real-time tasks.

They can be. For instance, the Real-Time Java dialect of Java was recently picked to run the Eglin Space Surveillance Radar.

"Whereas a garbage collected language like Java gives you absolutely no control over when (if ever) an object is destructed."

That is the single biggest miss-conception that hurts java programs everywhere. The fact is, to write large high performance java programs you still have to be conscious of what is actually going on. That is why some JVM's have tuning parameters for the types of garbage collection as well as other aspects of the JVM your code is running in.

Garage collection happening automatically in no way, shape, or form implies any level of performance, good or bad.

http://java.sun.com/performance/reference/whitepapers/tuning.html

They both try to solve the same problem of shared data management across threads in a similar way, and I think neither will really scale to huge multi-core systems so long as the lock-and-key mechanisms remain in place.

Java introduced many more sophisticated tools with the java.util.concurrent package (and subpackages) that allow for programs with high CPU thoroughput and scalability. These include synchronization primitives such as a count-down latch, cyclic barrier, semaphore, an exchanger, and so on. Several concurrent collections were introduced, notably a variety of queues that serve a variety of unique purposes. An executor framework was introduced to replace Timer/TimerTask, and includes all sorts of thread pools, rejected execution policies, delayed executors... you get the idea.

java.util.concurrent.atomic has several atomic value holders, some of them reflection-based, all of which use compare-and-swap, a low-level algorithm, for lock-free access/modification. java.util.concurrent.lock contains locking utilities, including a ReentrantLock. (This class was so much faster than synchronized, btw, than synchronized was changed to use ReentrantLock's algorithm in Java 6.) Finally, there's the AbstractQueuedSynchronizer, a robust class for building synchronizers, that (again) uses compare-and-swap to maintain state.

There's no doubt that less data shared between processes, and increased parallelization, is good for any concurrent application. In terms of concurrency, though, Java offers quite a bit of flexibility and sophistication, though sacrificing some of the simplicity of functional programming languages. In my opinion, anyway.

The thing is, Andy's back, and as far as I can tell, he doesn't give a rat's ass about Solaris. He just wants to make interesting hardware. That's where the money is, after all. Software is a pathetic fraction of corporate revenues here. All the more reason to be mystified about the internal hostility toward Linux.

So, for example, the Thumper is one of Andy's creations. It's pretty hard to beat the storage density you get for the price. Put a mess of those under a Lustre filesystem, and people start to take notice of Sun as a player in HPC. The recent TACC Ranger system is all Sun gear: storage, compute, and network (with sun-built Magnum switches). The OS? Linux.

There's more interesting stuff coming down the pike, and from my perspective, it seems that there's a shift toward making money on volume rather than margins. In other words, somewhat less awesome, but more of it.

I dunno. I don't profess to have much more special knowledge than anyone outside of the upper echelons. I'm hopeful, though. I read somewhere that many of the big Solaris egos were hired away by teh google. Hopefully they keep going. They can have our kool-aid-drunk sales and marketing people too. :P

The thing is, Andy's back, and as far as I can tell, he doesn't give a rat's ass about Solaris. He just wants to make interesting hardware. That's where the money is, after all. Software is a pathetic fraction of corporate revenues here. All the more reason to be mystified about the internal hostility toward Linux.

So, for example, the Thumper is one of Andy's creations. It's pretty hard to beat the storage density you get for the price. Put a mess of those under a Lustre filesystem, and people start to take notice of Sun as a player in HPC. The recent TACC Ranger system is all Sun gear: storage, compute, and network (with sun-built Magnum switches). The OS? Linux.

There's more interesting stuff coming down the pike, and from my perspective, it seems that there's a shift toward making money on volume rather than margins. In other words, somewhat less awesome, but more of it.

I dunno. I don't profess to have much more special knowledge than anyone outside of the upper echelons. I'm hopeful, though. I read somewhere that many of the big Solaris egos were hired away by teh google. Hopefully they keep going. They can have our kool-aid-drunk sales and marketing people too. :P

Nowadays, we also have good but cheap hardware. I'm the docs lead for this Opteron-based system, which is pretty affordable and will soon be available with Barcelona quad-core CPUs.

As for our future growth, obviously we are destined to overtake IBM, put HP and Dell out of business, and reverse global warming. Come on, what else did you expect me to say?

I don't really care too much about the proprietary-ness of Java. Since I'm not a Linux zealot, I just care that it does what I want it to do.

The problem is, there's a cause-effect relation between the two that you don't seem to comprehend.

With proprietary technology, the chances are much greater that at some point you'll discover that the technology doesn't do what you'd want to.

A practical example: suppose you have a new 64 bit workstation with a fresh, new, 64 bit operating system on it and most of the software is 64 bit too. So you've been browsing pages with your 64 bit browser for a couple of weeks now, and you stumble upon a page that features a Java applet and requires it to work properly.

Now you have a real problem, since there's no Java browser plug-in for 64 bit architectures yet.

If Sun's Java had been released on a liberal license a couple of years ago, now we would probably have full support for a much larger set of architectures, including AMD64. Maybe PowerPC and others as well - the community would pick this up and work on porting according to general populace's needs.

Instead we have a large populace of angry users who wait 3 years (and will probably wait another one) for support of a quite popular hardware platform because the control has been in the hands of a single entity - Sun.

The same problem is with all the other technologies - and you are likely to be burned by this problem in the future if VmWare decides that you have to upgrade to something new or that your little interoperability problems mean nothing to them.

And it's you who will have to answer to your customers/bosses on your own for the limitations artificially imposed by a vendor, for the problems that are beyond your control. Unless you really don't care and don't take responsibility for results of your work, but then you should qualify for the position at the bottom of the IT food chain - like a helpdesk/support job...

Great! Does that mean we might see a 64-bit plug sooner rather than later? We've been waiting over 5 years!

Well perhaps we can start deploying it in nuclear control facilities?

But seriously, it would be great to see working 64-bit implementations in various distro repositories.

So, they are proposing Sun StorageTek 5800 (codenamed Honeycomb) as their research?

Compare article with this whitepaper, especially Figure 13 on page 28. Networked nodes with 4 disks each, grouped in cells of 16 + 1 management node. Each object is stured redundantly on disks of different storage nodes. Everything self-contained, accessible by nice API. Oh, and the software is Open Source.

So, they are proposing Sun StorageTek 5800 (codenamed Honeycomb) as their research?

Compare article with this whitepaper, especially Figure 13 on page 28. Networked nodes with 4 disks each, grouped in cells of 16 + 1 management node. Each object is stured redundantly on disks of different storage nodes. Everything self-contained, accessible by nice API. Oh, and the software is Open Source.

I don't think booting from ZFS is all that interesting. I think expanding a RAID-Z pool is far more interesting: http://blogs.sun.com/ahl/entry/expand_o_matic_raid_z

Our original SAN consisted of four MSS 9216's with the 32 port blades for a total of 48 ports per switch. Two at each site (stretched fabric, 3k of dark fiber between the two sites, dual fabric, bla, bla, bla) Every server has two ports and thus full redundancy in the event of a switch/cable/whatever failure. (ever try and bond two ethernet ports between two switches?).

To replace the aging MDS switches we went with four Brocade 4900's. We have what I would call a medium sized environment, so the larger brocade switches did not make sense, but then again neither did the little things like the Brocade 200E. We have some hosts who will push 500+MB/s of traffic through our SAN, so trying to bond a ton of ethernet ports together did not make sense (think of the cables). Of course, bonding to a single switch is easy, ever try bonding between two physically different switches for redundancy? (to save money, our 6509's only have 1 sup, so we need switch diversity). Storage multipathing is easy with a dual port 4Gb hba. One could argue that a dual port or a 10G-E card allows for failover but removes the need for bonding. Of course, guess which one is cheaper :-)

The nice thing about the 4900's vs the cisco MDS switches are as follows;
1) Smaller (2RU for 64 ports)
2) No oversubscription (64 ports, 4Gb any to any)
3) Less power. (Not even close)
4) Hitless firmware upgrades (cisco sorta has this with the MDS 9500, at 10x the cost)
5) Ooooh, shiny box :-)

At the same time our network folks were purchasing some 10G line cards for their Cat 6509's. Lets just say that the 8 port card with optics cost more than my 64 port 4900 with optics. They got 160Gb of bandwidth (assuming you never leave the card when it quickly falls to 40Gb), I got 512Gb.

Just for kicks I also looked at their costs for the 48 port gig-e line cards. Loking at just the cost of the cisco line cards (6748's) and ignoring the cost of the chassis and supervisor, my cost per Gb was just a touch under theirs (and mine included the whole chassis). Of course, 256 ports of gig-E takes up a lot more space, more cables and I still have the bonding issue for redundancy.

I'm sure some day we will see it all merge together. Whitness the Magnum switch from Sun: http://www.sun.com/products/networking/datacenter/ds3456/

Until then, I'm sticking with ethernet for IP and FC for storage.

How can false opinionated stories like this be published? With it being Sun Week on campus, I've had some recent (yesterday) exposure and discussions with some of their representatives. Sun singlehandedly contributes the majority (Yes, above 50%) of Open Source code in the online community, thanks to their newly acquired MySQL. Read More, and next time get your facts right.

Oh, Gray Knowlton, you mean the Microsoft employee and liar who claims ODF has no accessibility support

If you want to debate, please try minding your language. It takes away from your argument when you feel you have to swear to emphasize your point.

It sounds like your argument is, "MS is the dominant suite, so it will set the standards." You realize that industry standards -- as opposed to defacto standards -- exists in order to prevent that very scenario from happening?

If by features you mean stuff like INK, which as already mentioned is included as a description inside OOXML, or things like autoSpaceLikeWord95, then I consider that a good thing.

BTW, autoSpaceLikeWord95 being deprecated isn't sufficient. Deprecated means it's been superseded by other functionality and shouldn't appear in new documents. However, as part of the standard an application still needs to be able to properly interpret it, and thus at the very minimum it should be stated what tags and settings apply the same functionality.

I'd love to hear what you mean by, "accessibility for the disabled." The only thing I can think of here that isn't simply an application feature is perhaps including an embedded audio of the entire document; but that's overkill. There are plenty of text-to-speech converters that operate on plain text, and hence those can be built into the application itself and simply interpret the text of the document. Switching to a larger text size -- a zoom feature or similar -- also has nothing to do with the document. In short, as my understanding goes, accessibility is a function of the application. However, if you care to give examples, I'd consider their merit.

ODF 1.2 has spreadsheet formulas and is being submitted to ISO. See here. Not ISO right now, perhaps, but still an open standard.