The OpenOffice.org project has released the second beta of version 2 of their office suite. “This is our second beta of OpenOffice.org 2.0. That means it probably has bugs; use caution. Download, test it out, and file bug reports with the QA Project.”
Were’s the release notes?
The link on the beta2 page returned a 404, so I did not inlcude it in my summary.
usually they’re here
http://development.openoffice.org/releases/OpenOffice_org_2_x.html
Man, OpenOffice 2.0 is taking a *long* time. Weren’t they predicting a final 2.0 release earlier in the year? It’ll soon be September and we’re still in beta. I guess this is a reflection of the monstrous size and complexity of the code base, but I do worry that OpenOffice has become unwieldy now. I’ll give this beta a spin, but otherwise I’m considering a switch to KOffice, if it handles my files well.
C’mon now, that’s silly.
A delayed release is generally a good thing. Sometimes it’s because of bugs, but most of the time it’s to incorporate further improvements and features, iron out all remaining bugs, and improve compatibility. If you have actually used OO.o 2, you’d know it’s really getting to be fantastic, and I’m VERY optimistic.
As for KOffice, while it’s a great lightweight program, the MSOffice compatibility of OO is really a big selling point for me, not just a lightweight word processor that can write OASIS compatible files.
I don’t think there’s a problem with longer cycles itself…
The problems most people do feel are stable releases. They’ve a lot small bugs (and some big too) that do annoy people trying the software looking for alternatives for “MS Office”.
I know bunch of people who HAVE TO use OO.o at work (mainly, federal workers–as Brazilian governament changed from MS Office to OO.o sometime ago…) and HATE the software because they can’t read certain files, because random crasses and the list goes on…
Two years is too much for them. Don’t expect them saying good things about OO.o too…
A couple of minor releases with focus on bugs, stability and compatibility instead of the new features (besides the ones like OASIS fileformat update that helps the transtion when done earlier…) would make them a lot happier and probably would bring more users to the suite in a long run via recomendations (instead of complains).
Well… but too late to complain now… I’m looking foward 2.0 release. Better looking and friendly for new users… and more stable, I hope…
I hope it’s not too late for these users take a second look in the suite… =]
A couple of minor releases with focus on bugs, stability and compatibility instead of the new features (besides the ones like OASIS fileformat update that helps the transtion when done earlier…) would make them a lot happier and probably would bring more users to the suite in a long run via recomendations (instead of complains)
Ummm, do you mean like 1.1.0, 1.1.1, 1.1.2, 1.1.3, 1.1.4 and soon to be 1.1.5, or are you talking about something else? These releases introduced no new features (1.1.5 will introduce OASIS support, but nothing else), they were bug fix releases and that is it.
No, it is not silly at all.
OpenOffice would do good in getting 2.0 out in a usable state (current version is *still* too buggy) and then switch to a 6 month shedule, spending the first cycle on modulizing the tree, just like Xorg did.
Koffice is sadly nowhere near OOo. It’s nice, but it is no replacement.
Disagree. Openoffice 2.0 release will have a lot of buzz and gain mindshare. If it’s released too early without all planned features and buggy, administrators will be disappointed and OO will lost its chance till 3.0 release. If they want organizations to switch they have to be cautious about the 2.0 version and better continue providing betas and builds for rest of the community.
Besides this marketing remark you are right, betas are still too buggy right now.
Yeah, I said that they need to get 2.0 out as bug free as possible… but that schouldn’t take another year.
And after that – while fixing bugs in the stable branch – they should focus on cutting down the tree! OOo2 is 150 megs of source, not counting dictionaries and stuff. That’s simply too much. They should split the project into managable junks, stablize and then commit to a time based shedule not longer than 9 month. Also, the development community must be more open and welcoming to outside developers!
OOo2 is not bad, essentialy it’s the best (in sense of most complete) Office packets in the *nix world. But the project MUST be more flexible in the future.
Yes, the release is way behind schedule. I remember hearing April/May as the date fot the final release.
On the other hand:
1. I read an article a few months ago about how they had conflicts and learned for next time. That’s how it goes.
2. In terms of features, they have made a tremendous progress in OOo 2.
It also makes me feel better know the program is free, the beta is available to use, and the beta works pretty well. At home I use Fedora Core 4, where only OOo 1.9 is available (not 1.4).
I’m using openoffice.org-2.0.20050827 with FreeBSD 6.0-BETA3. It seems stable and quite a bit faster than the older 1.x.
I’ve been very impressed so far.
They need to release often and release more. If possible, they should follow something like GNOME’s 6 month release cycle. It seems the 2 years or more release cycle is not working for them.
Although there is quite a long gap between major jumps of the stable release of OO.org, the 1.9.x releases at http://development.openoffice.org/releases/OpenOffice_org_2_x.html are put out to the public every 3-4 weeks typically, with betas coming out several months apart.
The long time between major release jumps and the relative stability of this year’s beta releases have persuade some distros to now start shipping the 1.9.x releases already – on the current timetable, I’m expecting 2.0 final around November or December myself, but it won’t be that much different from the just-released Beta 2 version.
I suspect the big pressure for a new major release is probably coming from the StarOffice side of things than the OO.org side. They know they have to get their release out soon in order to show that the product still has legs on it.
I agree that 2 years is a long time.
OOo is likely to stay in step with Sun’s StarOffice, which will always follow longer release cycles.
“I agree that 2 years is a long time.”
No its not, how old is MS Office 2003?
That came out before 2003 or about.
I use all;
Laptop – MS 2003
1 Desktop – StarOffice 7 update 5
3 Desktop – OpenOffice 2 beta
I’ve been having problems with Base crashing because it tries to use GCJ as its Java Runtime environment.
There is an article at
http://ensode.net/openoffice_fedora64_java.html
with instructions on setting OpenOffice.org with Sun Java.
After setting up OO.o with Sun Java, Base stopped crashing.
Eraser
My apologies for going off topic.. But have any osnews user accounts been deleted ? For some reason i can’t access mine anymore, and password retrieval says its having trouble finding that user..
The only reason to download OO is to see if it still sucks. The answer is always, “yes”.
>>The only reason to download OO is to see if it still sucks. The answer is always, “yes”.<<
Funny. That’s the same reason I visit your Mom. And the answer is always, “yes”.
I agree. I hope that 1.1.5 and 2.0 fix bugs in 1.1.4.
Though I like OOo in general, there are a lot of things that could be fixed.
In the old/current (1.x) version you can download and run the (GUI) installation but the new (2.x beta) only available in RPM format. I checked and found howto for convert OO’s RPM to debian to install but the process is rather lengthy and I would much prefer the installation procedure.
Why not used the old approach or at least provide that approach as alternative to RPM’s ?
Noone knows that, really. The good ol’ installer even allowed to make network installations which was very neat…
yeah, its really annoying that you need superuser privileges now to install that bloody beta. I preferred the old approach which included the network install feature :[
re: “yeah, its really annoying that you need superuser privileges now to install that bloody beta. I preferred the old approach which included the network install feature :[”
you don’t need root privileges. if you aint’n root when installing, OOo will install in /home/your-name/OpenO…
Also, OOo isn’t slow at all. i manage to install it on slackware 10.1, following next steps:
tar xvzf OOo2.0-beta…..tar.gz
cd OOo2.0…./
rpm2tgz *.rpm
installpkg *.tgz
simple as f……
first time i launch it from konsole: /opt/openoffice…./program/soffice
it takes some seconds (probably 10 – 15). it search for one jre (really needs this, if wanna do all tasks). After configure the ‘java’ stuff, it launches by approx. 3 seconds. Good enough, isnt’t it?
my comp is: p4 3,2 Ghz, 2 GB RAM (slack see 1 GB, and don’t have time to bugfix this), hdd 80GB maxtor 7200 RPM, OS slack 10.1
taste this
Reading the package contents, it was meant to run either Suse, Mandriva or Red Hat based distribution. For the reason, better ask developer or pr themselves.
The new OpenOffice runs awesome. Excellent job! Keep it up!
Aaaarghh.. I thought they’d make 64bit XP binaries available =(… guess not. Anyone have a clue when we’ll see OOo 64bit ?
What value would there be in having a 64 bit XP release at this point? All it would do is force a lot 32 bit optimized math to be promoted to 64 bits and result in a slower application.
What value would there be in having a 64 bit XP release at this point? All it would do is force a lot 32 bit optimized math to be promoted to 64 bits and result in a slower application.
Slower application? Ehhrr…. in case you missed this, 64bit apps are generally a LOT faster since they have higher throughput. My experience so far from the 64bit world is in general that everything just simply goes twice as fast.
Just because me, and many others with me, want 64bit apps doesn’t mean we don’t appreciate a 32 bit version being around.
64bit is the way to go, and for OOo being there before MSO would definitely be a very nice move.
I’ve seen this attitude all over the OSS place about 32bit vs 64bit… and story will repeat itself. Proprietary will get there first and OSS will wake up 2 years later.
(Note: I do exclude those brave 64bit linux/BSD users but you guys hardly apply to the 64bit Windows world)
Slower application? Ehhrr…. in case you missed this, 64bit apps are generally a LOT faster since they have higher throughput.
Please say you were joking.
Office applications are among those that least benefit from 64-bit addressing and 64-bit maths but are most hit by the extra memory bandwidth required by 64-bit pointers and 64-bit register spills (although the x86-64’s extra registers kind of make up for that.)
And office applications aren’t performance critical anyway, apart from startup time. 64 bits won’t help with that either.
I guess that depends on what you’re doing with them doesn’t it?
I work a lot in spreadsheets (quite big ones) and do a lot of maths. And it’s not rare that for instance MSO get sluggish after a short while.
Memory is not an issue for me personally, I got 2gb which these days are quite cheap and wouldn’t mind wasting some memory for extra performance.
Besides, when you work with charts it also seems to be sluggish at times, that’s where the extra speed and maths would probably come in handy.
I can see that many here think that wordprocessing is what it’s all about, but frankly, that’s the area I use them least for or demand functionality the least.
I work a lot in spreadsheets (quite big ones) and do a lot of maths. And it’s not rare that for instance MSO get sluggish after a short while.
Even then it’s going to spends its time less on actual calculations, but on interpreting your formulas and updating the representation of the results.
And do all those spreadsheets of yours even require integers bigger than 32 bits (4 billion)?
Floating-point numbers have always been 64-bit anyway.
Memory is not an issue for me personally
The issue isn’t memory size but memory bandwidth. 64-bit pointers and registers require extra bandwidth and cache, so the 64-bit change by itself actually reduces performance.
It only gets beneficial when you need to address data greater than 2GB and your program requires integers bigger then 32 bit.
Besides, when you work with charts it also seems to be sluggish at times, that’s where the extra speed and maths would probably come in handy.
You have fallen for the great 64-bit hype, even before it has started properly. Sadly, you’re by no means the only one.
I have been following the OO2 beta/bimonthly releases for the past 4 months.
The interface looks better & I save it exclusively in the OASIS format *.odt, *.ods etc.
I have a Excel spreadsheet 9157KB in size. 8500 rows & 47 columns. When I convert to a ODS equivalent it is under 905KB. Great saving of space.
But opening the ODS is totally another story. It takes 25s to load the file on OO2.
MS Excel loads the 9MB file in 3s.
Note to OO Developers
Frigging do something about the loading time. A default format(ODS format) taking so long a time on a file 10th its size is unacceptable.
My Laptop is Compaq EvoN800C
P4M-2.2GHz, 1GB DDR266, 60GBToshiba 4200RPM HDD. OS is Win2K SP4
The OASIS format is gzip compressed XML. MS Office formats use an OLE tree that is basically a raw memory structure written directly to disk. OO2 will probably be able to improve the loading speed as it approaches release. However, in many scenarios it will never be able to match MS Office because of the translations required to load and process the file. The upside of the OASIS format is that it is well documented, text based, easy to modify, and less vulnerable to several classes of exploits that are more common in chunked binary formats.
I understand that it is compressed XML. Compression accounts for the great reduction in size. But if decompression is gonna take so much time, many users will be put off by that.
Some how the developers have to decide on the level of compression or something. Looking @ my laptop specs. Except for the HDD everyother things are reasonably fast.
When OO opens the file there is very little HDD factor. I am talking about decompression in the memory that takes so much time.
no it is not decompression that is taking time, it is simple a matter of interpreting the xml and building a object tree. Compressing the file probably is helping you as it uses less HDD read time. Parsing XML, then building an object tree is as slow as it gets. But it could go down to a 5 to 8 seconds probably (just a wild guess).
What I would like to see is Oo.org using python as the script language and also to wizards and this kind of stuff that they are using java. Then they can maybe stop working on this uno bridge and let only a C/C++ api and a python script backend. Probably they can get funding from Mark Shutleworth and Ubuntu for that.
Fedora version of Ooo 2 beta is using python and gcj for java. Still in progress.
I just downloaded and installed it.
It’s amazing, more polished, cleaner interface and fast!
Just a heads up. Visit the OpenOffice forums if you’re needing or willing to provide help for OpenOffice.
http://www.oooforum.org
torrents can be found here:
http://distribution.openoffice.org/p2p/download.html
I just found the .debs and other builds here:
ftp://ftp.linux.cz/pub/localization/OpenOffice.org/devel/680/SRC68…
For example, if you load the applications with a newer GUI, particularly Base and Impress, you’ll see that a lot of use is made of docked panels. However common items, like the Navigator and Stylist still use floating panels appear in floating windows.. You can dock these, and it’s easier than in OOo 1.1.4 where you had to hold the [CTRL] key as you dragged. However when docked, they look different to the panels that are docked by default in Base etc.
Screenshot: http://www.bfeeney.uklinux.net/images/ooo_impress.gif
If you look at the screenshot, you’ll see the new docked-by-default panels have titles and close buttons in the top-right. However the floating-by-default panels (stylist and navigator) have neither of these. As a result, to drag a floating-by-default panel, you have to pick an unoccupied part of the toolbar to pull it away.
Another issue, is the fact that the list of styles in the Stylist is not itself styled, so you have no idea how the individual styles look like. What’s worse is that there is no “summary configuration” pane for modifying styles as there in in MS Office XP and above, you have to pick bits and pieces out of 12 different tabs.
Lastly, I really wish they hadn’t bothered to ape the MS Office 2003 widget theme, it looks pretty awful, and it’s not implemented consistently (compare the statusbar background in the screenshot above to the overall application background).
Really, they should work on making the GUI consistent, and in improving their style configuration (as styles are essential in modern business documents). As it is, Base looks like it comes from an entirely different office suite to Writer.
There is still no native OSX support….
> There is still no native OSX support….
Maybe because Apple makes garbage computers and crappy operating systems. Did you ever think about that? Even their Open Firmware bootloader defies physics: it sucks and blows at the same time.
To install on Debian, you just need to do `alien *.rpm`. A bit long, but not too much. What is not working for me is the desktop-integration package for Debian – it seems it only works for Gnome?
Someone’s been contributing OO.o2 builds to Debian experimental. Easy to install with apt-get 🙂
Current version is 1.9.125+2.0beta2-1
I had thought of OOo as one of the best OSS projects until I had need to write some BASIC macros for Calc. Then I realised that OOo seriously lacks documentation and has very awkward BASIC implementation.
Well… maybe I’m expecting to much… then again, they spoilt me.
Here are the release notes for oo.o beta 2
http://development.openoffice.org/releases/2.0_beta.html