They do have to. The iPod and the music are separate products. Using their monopoly in portable players (yes I know there are other vendors, that doesn't matter, apple has so much marketshare it is a monopoly) to gain an advantage in the online music store business is abuse of a monopoly, anticompetitive, and probably illegal.
You can't fork it under GPL, because the license won't let you. Also, sun keeps all their trademarks and, more importantly, patents. They could quite possibly stop such a fork in most of the developed world. They have more than enough developers themselves to keep Star Office going (it was going fine before OOo existed) and it would probably leap far ahead of the open version. Sun has enormous name recognition, which seems to have attracted OOo developers over and above what would be expected - KOffice started before OOo and yet gets virtually no mention from people. I think they could pull off looking good even while going on a patent offensive against OSS. Their marketing is incredibly good - look at the success of Java.
Why do I owe sun an apology? Going with your numbers for the sake of argument, you've said yourself there are 29 files that depend on sun.*, and only some of them are documented - implying some of them aren't. That's 29 files too many, and one undocumented API is definately one too many.
There are alternatives around, and even if there weren't there are definitely alternatives to the sun-only APIs they use. Make no mistake, they're using it because they're sun.
Yes, I have coded in Java. I know in benchmarks and pure method calls it is far faster than Python. However, in practice, Python programs are faster. Compare the official bittorrent client to azureus, that's a bit unfair because azureus is far more featureful, but the Python one is faster by an incredible margin. Or compare jEdit to eric3 (a whole IDE, jedit is getting there but is not there yet) - the startup times are similar and eric3 is more responsive in use.
Python scales pretty well. For performance you want to do tight loops etc. in C, but python makes this easy. And the lower number of libraries is offset by the ease of wrapping C libraries, half the time you can literally just run swig or similar on the library and have working python bindings.
I'm not claiming that Java isn't much faster for pure maths, method calls etc. Writing a whole office suite in Python would, yes, be insane. However, you wouldn't do that in Java either. A pure python implementation would be slower, but a 90% python with 10% C would probably be faster than pure java - and a lot easier to implement than 90% java with 10% C. That's python's real advantage.
The argument still is true, look at the BeOS port of java. It's very difficult because over 75% (IIRC) of java is implemented in java. Again IIRC, the only native of the networking code is the raw sockets, the rest is built upon it in java, wheras python wraps system APIs at several levels. This is certainly the way it works for graphics and in general seems to be the java way, swing draws every pixel in Java with all the buttons etc. implemented in straight java. Which will always be slower than C.
It's JIT but not very (most of it doesn't take advantage of it yet). Yes, it is slower in terms of method calls, etc., and benchmarks show this. But it is faster in practice because most of the libraries are very thin wrappers around fast C implementations.
Python can compile to bytecode too. The compilation isn't that optimised yet, but it works. But it can interpret as well, which is good because it makes debugging *much* easier.
Python will compile when it runs the first time and then use the bytecode version if the timestamp is newer. Which means it performs just as well on subsequent runs as java.
Java does have the potential of being much faster than python, if JNI were easier and used more. But in practice they aren't, and it isn't.
Only in so far as I've read it on the Kaffe mailing lists and developer blogs, but it seems to be pretty accepted that that's what they're doing. I'll try and find a definate line in the source I can point to. Yes, it does limit it to only sun JVMs, which is exactly the problem.
The point is that it isn't really open source, and those who care about their freedom should use something else. There are plenty who only care about the functionality, but if you're one of those why not just use MS Office?
In that case, why do you bother using OOo? Why not just stay with windows and MS Office? Because that's all you'd have if that attitude prevailled. And there are perfectly useable alternatives, KOffice is IME ahead of OOo in many areas.
The only time I encountered an MS-only java feature, it was a signing thing that was entirely reimplementable, just different from the sun equivalent. That doesn't mean there weren't extensions that were tied to windows, but none of the ones I saw were.
Yes, the JRE works on the platforms it exists for, but there are platforms sun hasn't ported to, where it needs to work on alternative javas.
The sun only extensions are sun propriety. You can reimplement the API without the source, but sun could have done the same for any wrapped win32 calls. It's not easy.
Replacements are already there, e.g. koffice, but they could do with more developers and users. So we point out the problems with OOo in the hope more people will come and use them and code for them, in the same way the OSS movement as a whole points out the problems with closed source software like windows.
Yes, just as nothing can stop us reimplimenting the win32 API. In practice it's a helluva lot of work and we don't consider something truly free if it depends on a non-free API, even if, having the source, we could in theory reimplement that API
Yes, it's unlikely, but it's possible, and the point of licenses is to protect you from when people make dicks of themselves. The **AA are making dicks of themselves suing filesharers, it doesn't make you safe
Getting activestate perl is *easier* than getting java, you simply download the installer and run it, rather than having to work out whether you need a JRE or a JDK or a J2EE or JME or whatever. Ditto for python. I'd use python myself, but perl would work equally well, and so I think would C# considering it will be bundled with the next windows and used for new MS apps (so they'll make very sure it's easy to install) and non-windows users can probably handle installing mono.
I'd use Python. Java is slow too, slower in practice since it makes much less use of native code. Why is the user base a problem? I've always found the standard library very well documented and have yet to have a consistency problem, but if those problems are there it's probably because the library is a lot bigger than in most languages, you'd normally end up getting external libraries to do the same thing which would, in all probability, be inconsistent with the standard library and underdocumented.
Slashdot Mirror
Nope. There was a Qt problem that got resolved about 4 years ago, Qt is now GPL, as free as it gets. Unfortunately gnome is still spreading FUD.
Those are the current stoppers, but there are also undocumented packages in the sun.* hierarchy that OOo uses.
Yeah. The other students have usually gotten used to it.
The underlying elliptic curve problem in the better ECC schemes is suspected to be fully exponential with key length, which is harder than NP.
They do have to. The iPod and the music are separate products. Using their monopoly in portable players (yes I know there are other vendors, that doesn't matter, apple has so much marketshare it is a monopoly) to gain an advantage in the online music store business is abuse of a monopoly, anticompetitive, and probably illegal.
It's supposed to failover better, and perform better, and a few other things I forget.
You can't fork it under GPL, because the license won't let you. Also, sun keeps all their trademarks and, more importantly, patents. They could quite possibly stop such a fork in most of the developed world. They have more than enough developers themselves to keep Star Office going (it was going fine before OOo existed) and it would probably leap far ahead of the open version. Sun has enormous name recognition, which seems to have attracted OOo developers over and above what would be expected - KOffice started before OOo and yet gets virtually no mention from people. I think they could pull off looking good even while going on a patent offensive against OSS. Their marketing is incredibly good - look at the success of Java.
Why do I owe sun an apology? Going with your numbers for the sake of argument, you've said yourself there are 29 files that depend on sun.*, and only some of them are documented - implying some of them aren't. That's 29 files too many, and one undocumented API is definately one too many.
There are alternatives around, and even if there weren't there are definitely alternatives to the sun-only APIs they use. Make no mistake, they're using it because they're sun.
Python scales pretty well. For performance you want to do tight loops etc. in C, but python makes this easy. And the lower number of libraries is offset by the ease of wrapping C libraries, half the time you can literally just run swig or similar on the library and have working python bindings.
I'm not claiming that Java isn't much faster for pure maths, method calls etc. Writing a whole office suite in Python would, yes, be insane. However, you wouldn't do that in Java either. A pure python implementation would be slower, but a 90% python with 10% C would probably be faster than pure java - and a lot easier to implement than 90% java with 10% C. That's python's real advantage.
The argument still is true, look at the BeOS port of java. It's very difficult because over 75% (IIRC) of java is implemented in java. Again IIRC, the only native of the networking code is the raw sockets, the rest is built upon it in java, wheras python wraps system APIs at several levels. This is certainly the way it works for graphics and in general seems to be the java way, swing draws every pixel in Java with all the buttons etc. implemented in straight java. Which will always be slower than C.
Python can compile to bytecode too. The compilation isn't that optimised yet, but it works. But it can interpret as well, which is good because it makes debugging *much* easier.
Python will compile when it runs the first time and then use the bytecode version if the timestamp is newer. Which means it performs just as well on subsequent runs as java.
Java does have the potential of being much faster than python, if JNI were easier and used more. But in practice they aren't, and it isn't.
It's an old joke, it's been posted 3 times in the thread already, and yet you still can't get the line right? That's *no* moon.
Notice the sun.* packages in that API doc you link to? No, me neither. Oh wait, that's because THEY'RE NOT THERE
Only in so far as I've read it on the Kaffe mailing lists and developer blogs, but it seems to be pretty accepted that that's what they're doing. I'll try and find a definate line in the source I can point to. Yes, it does limit it to only sun JVMs, which is exactly the problem.
The point is that it isn't really open source, and those who care about their freedom should use something else. There are plenty who only care about the functionality, but if you're one of those why not just use MS Office?
Sorry, I assumed TFA would explain the issues better than it does. However, the problem is exactly that - OOo 2 is directly using sun.*
In that case, why do you bother using OOo? Why not just stay with windows and MS Office? Because that's all you'd have if that attitude prevailled. And there are perfectly useable alternatives, KOffice is IME ahead of OOo in many areas.
Yes, the JRE works on the platforms it exists for, but there are platforms sun hasn't ported to, where it needs to work on alternative javas.
The sun only extensions are sun propriety. You can reimplement the API without the source, but sun could have done the same for any wrapped win32 calls. It's not easy.
Replacements are already there, e.g. koffice, but they could do with more developers and users. So we point out the problems with OOo in the hope more people will come and use them and code for them, in the same way the OSS movement as a whole points out the problems with closed source software like windows.
Yes, it's unlikely, but it's possible, and the point of licenses is to protect you from when people make dicks of themselves. The **AA are making dicks of themselves suing filesharers, it doesn't make you safe
Getting activestate perl is *easier* than getting java, you simply download the installer and run it, rather than having to work out whether you need a JRE or a JDK or a J2EE or JME or whatever. Ditto for python. I'd use python myself, but perl would work equally well, and so I think would C# considering it will be bundled with the next windows and used for new MS apps (so they'll make very sure it's easy to install) and non-windows users can probably handle installing mono.
What's the difference between believing that and carrying on using MS Office because it has more features?
I'd use Python. Java is slow too, slower in practice since it makes much less use of native code. Why is the user base a problem? I've always found the standard library very well documented and have yet to have a consistency problem, but if those problems are there it's probably because the library is a lot bigger than in most languages, you'd normally end up getting external libraries to do the same thing which would, in all probability, be inconsistent with the standard library and underdocumented.