64 bit?

Posted Aug 30, 2005 17:56 UTC (Tue) by dlang (✭ supporter ✭, #313) [Link]

the problem isn't the speed, it's the need to install a full set of 32 bit libraries just for the one program to use.

this is especially bad on some distros (Debian) where you end up having to create a chroot environment to run openoffice in.

Posted Aug 30, 2005 18:06 UTC (Tue) by jwb (guest, #15467) [Link]

My experience of installing the 32-bit OOo on 64-bit Debian and Ubuntu systems is not that it works fine, but rather that it aborts. However I have just installed the 2.0 Beta 2 from Ubuntu Breezy and it works at least superficially. That's a nice improvement.

Posted Aug 30, 2005 19:09 UTC (Tue) by hazelsct (guest, #3659) [Link]

But if you're using a 64-bit system today, it's because you want the extra performance for an application that needs it, which isn't the office suite.

No, it's because I chose an inexpensive (~$2K) alpha workstation with the best performance/price about six years ago, and that's what sits on my desk. I run Debian, and all of my applications and libraries run about as well on my alpha as on i386 -- EXCEPT OOo. Why should I have to spend another thousand dollars for a new machine just to run an office suite, when the old one works perfectly well?

I don't feel it's my "right" to run the same apps on 64-bit as others do on 32-bit. On the other hand, it's a bit arrogant and presumptuous of people like you -- and the OOo devs -- to dismiss us 64-bit folk, instead of chastising the authors of bad code!

(No, I haven't tried to fix it, though I have fixed other software over the years from gnome-pim to gnucash to mozilla to run on PPC, alpha and ARM...)

Posted Aug 30, 2005 17:29 UTC (Tue) by dwheeler (guest, #1216) [Link]

It's true that a few components are written in Java. But practically all of OOo is currently written in C++. Indeed, until very recently, many Linux distributions were shipping OOo without using Java at all. You lose Wizards, the built-in database (though you can still access databases), and some other things, and I believe the intent is to go further with more Java use. But that's not the current situation. Nor does it make sense to go differently; most users don't care what the implementation language is, as long as it works well and does what they need.

Yes, it's a little ironic. But I stand by my earlier statement -- if you're using a 64-bit system, it's not because your office suite is too slow. A 32-bit office suite is just fine on a 64-bit system; it does the job quite adequately. I think it's more important to worry about the needs that really matter first. And if someone loathes this so much that they're willing to fix it now, great... go to it!

Posted Aug 30, 2005 20:54 UTC (Tue) by bojan (subscriber, #14302) [Link]

> It's hilarious, and Sun should be ashamed [...]

You think? ;-)

A more cynical mind may even conclude that Sun are holding back open sourcing of Java on purpose, in order to cripple other FOSS distros, which then have to put huge (and unnecessary) efforts into making GCJ a solution for this problem (because they can't legally distribute Sun's JDK).

Then again, it may be for the best - once GCJ becomes as functional as "real" Java, we won't need it from Sun any more. Ah, that'll be the day... GCJ hackers, keep up the good work!

Posted Aug 30, 2006 1:15 UTC (Wed) by praedor (guest, #40215) [Link]

My problem with no x86_64 (AMD64) version of OOo is that it doesn't work
with Bibus, the ONLY viable citation manager for OOo thus far that works
on a par with EndNote and Word on Windows/Macs. This renders OOo useless
to me professionally. My writing is scientific. To journals. Journal
articles require citations. Citations are done via EndNote (or
equivalent). Virtually no professional journal accepts latex anymore (at
least in the biological sciences) so I can no longer use Lyx and bibtex.
Thus, if I want to write a professional article for publication I HAVE to
use Word because OOo wont work properly on my x86_64 system.

Installing a damn 32-bit version on my system means installing a slew of
32-bit libs and support just to make it work. One app. Practically
requires a second, shadow linux install to work at all and then I find
that it is incompatible with my professional needs: I do 32-bit install
only to find that Bibus will not communicate with OpenOffice on a 64-bit
system regardless. It only works on an old-fashioned, obsolete 32-bit
system. Thus, Openoffice has no value except as an overpowered letter
writing app since it cannot do professional documents (which requires
proper attribution).

I have waited and waited and waited for a 64-bit version. It has been
many months since last I checked and STILL not a lick of progress. Not
even an attempt.

Hardly the means for gaining share or respect in the world of MS Word that
can handle professional document writing, even on a 64-bit system.
Whenever I am asked about it, I warn people off OOo because it just isn't
up to par with Word. These are my professional colleagues and they MUST
be able to easily/painlessly be able to produce publications with proper
attribution. Bibus and OOo COULD do it but...only if you use a dinosaur
computer.

Posted Aug 31, 2005 3:13 UTC (Wed) by proski (subscriber, #104) [Link]

I think it's a good style to check facts before belittling someone in public. OOo builds and runs, it's just not very stable. See e.g. http://artax.karlin.mff.cuni.cz/~kendy/blog/. Sure, if you search for "openoffice x86_64" you'll get many problem reports because users try to build OOo when they can download the binaries. You can notice that most reported problems are generic build problems (e.g. linker using wrong libraries), rather than compile errors.

Compile errors is the easy part, and it has been done. Debugging and fixing problems that don't result in compile errors is the hard part, and it's going on now.

Unfortunately, this effort is not helped by the fact that OOo is somewhat closed to occasional external contributors. If only they used a widely accepted version control system instead of CWS!

On the lighter note, 64-bit support seems correllated with version control systems. When the repository is widely open to the public, everybody comes with their favorite kinds of patches. Somebody fixed 64-bit support after fixing it in 64 other projects, somebody polishes the GUI after doing the same in Gnumeric, somebody checks the code with Valgrind. I'm yet to see a project hosted on Subversion that would not compile cleanly on AMD64 :-)