Slashdot Mirror
EIOffice 2004 vs. MS Office 2003
ryen writes "Designed to compete against MS Office, EIOffice 2004 is coded in Java therefore able to run on both Windows and Linux. EIOffice 2004 offers features which should get a few users' attention, but does it have enough to have people switching from MS Office? Flexbeta has the review." That's Evermore Integrated Office, if you're wondering.
While I can try out a million different versions of office, and get equal satisfaction. Everything really comes down to standards.
.doc .xls .ppt standards. M$ is still winning the same game, just different players.
Until there is something 10x more superior than
1) Great another competitor, we should support it
2) Its in Java it will suck
3) Java sucks
4) It should be in Perl
5) It should be in C
6) I use vi and troff.
An Eye for an Eye will make the whole world blind - Gandhi
... does it have enough features to get people to switch from OpenOffice?
write once, debug everywhere?
The site seems to be slashdotted. And, entire apps written in Java are damn slow, particularly on Linux.
but does it have enough to have people switching from MS Office?
No, not as long as Openoffice is kicking ass!!!
"EIOffice 2004 puts a word processor, presentation package and spreadsheet into a single application, not a collection of programs. The integration is smooth and deep, and there's a natural feel to the way it all works together."
Is it good enough to never need OLE?
And yet it still has the fatal flaw of no database program.
Build an office suite with a file based database with a GUI and then you can start to attack the MS Access component of MS Office. Until then, you're replicating Star-Office and OpenOffice for some reason (and then trying to sell it for $149 USD on top of that).
Get paid to code OSS
Please, to all non-MS developers out there: stop chasing Microsoft!
... well, the instant something doesn't work, or just doesn't work exactly the way they're expecting, they'll dismiss your product as a cheap knockoff.
I understand the motivation behind designing office suites to look like Office clones, window managers to look like Windows clones, etc.: the idea is that people switching from MS products will find it easier to get used to the new software if it looks like what they're used to. But I really think this is a fundamentally flawed line of reasoning, for two reasons.
1. No one will ever be as good at being Microsoft as Microsoft is. You may expend endless blood, toil, tears, and sweat trying to clone $MS_PRODUCT down to the last widget, but you'll never get it exactly right. And if you try to lull users into feeling like they're using $MS_PRODUCT
2. Microsoft interfaces may be the "standard," but they're not the best. In almost every market niche I can think of, there's some product that's faster, more powerful, and/or easier to use than whatever Microsoft is pushing. If you're going to copy something, copy something better than Windows, Office, IE, ad nauseam -- or better yet, start with the best as a baseline and innovate from there.
The correlation between ignorance of statistics and using "correlation is not causation" as an argument is close to 1.
Because you are a TROLL!
And if you can't write a java app that runs as good on Windows as it does on Linux, Solaris, OS X, etc, then no wonder you use "regular languages" (pshaw!)
I wouldn't let you program my garage door opener.
My one complaint about EIoffice is the file formats. The last thing we need is yet another file format. OpenOffice/StarOffice, KOffice*, TextMaker*, and Abiword can all save documents in StarOffice format (* these two will have that feature in their next release). We have a rule here at SteamyMobile that you can use whatever office suite you want, so long as it uses the StarOffice format, meaning that in the future, when document search and indexing programs are released, they will all be able to use the same format. If EIOffice could that, we would use it too.
-----------
mobile porn
And if you use C/C++ your application will be easy to make fast, no matter what you're doing.
This is a very silly claim, at least as bad as the one you were responding to, that if an application is written in C/C++ it will be easy to make fast.
Then why do we have so many very-poorly-performing native applications out there.
I have seen enough cases where a well-designed Java app outperforms by an order of magnitude a poorly-designed C++ app.
I am all for using C/C++ where it is appropriate, but C/C++ is no magic silver bullet when it comes to performance any more than Java is. In either language, if you have carefully-constructed libraries, porting can be quite straitforward and if you have a design that plays to the strengths of the platform, performance can be reasonable. Performance and portability are always a matter of design. It does not just happen as a result of choice of platform.
While your version makes a better joke, the reality for any sufficiently complex application is more like "write once, run once". If you want to run on even one other platform (and here platform can mean just a different vendor of java technologies on the same os and hardware, or the same java technologies on a different os/hardware, etc...), look forward to resolving lots of issues that bear a striking resemblance to porting software in any other environment.
It really begs the question, why bother with Java. I honestly think that for complex applications it's easier to write portable C/C++ than trying to port java around. A well written C/C++ app that uses a multiplatform library set like glib/gdk/gtk can recompile and run easier between linux and windows than your typical java app.
11*43+456^2
Yes, I noticed on their download page that they have seperate downloads for linux or windows. I'm not fully sure, but I believe that the reason for that is probably because they use native API calls for each OS which will make it execute a bit faster. It seems like all of the more portable Java programs I've seen are all very slow. Don't get me wrong, I love Java as much as the next guy, but the only programs I've seen with decent performance made use of native API calls for a specific OS.
This space for rent, inquire within.
I sort of disagree. The issue here is similar to shopping for a car or truck: do you need 8 cylinders, or are you satisfied with only 4? For something like an office suite, if it's written in Java, it's like buying a large truck with a 4 or 6 cylinder engine. Yeah, it'll work, but it won't do it as quickly as one with a bigger engine.
I think software buyers these days, if they're considering going outside of the M$ box, are going to be more aware of what's under the hood than will the unwashed masses (who will act just as you describe).
"My country, right or wrong; if right, to be kept right; and if wrong, to be set right." --Senator Carl Schurz (1872)
*WORD* is the easy part.
Even powerpoint is almost a non-issue
How about Access/Excel...
So for any clone, ask these questions
Yes, but does it run crystal reports?
Yes, but does it run access (.db7) and have access-like switchboards off of which MANY soho businesses live? [Dentists, doctors, small mom & pops..] The JET engine may suck, but its the de-facto standard for mom and pops.
Yes, but do the macros they use at every major investment bank and packages like XLMiner work?
When there is a suitable ACCESS replacement for small business and something that runs crystal reports and data mining packages like XLMiner run, Microsoft is in trouble.
That last 10% of features will keep many major institutions around until near the bitter end.
When in doubt, parenthesize. At the very least it will let some poor schmuck bounce on the % key in vi. (Larry Wall)
I'll go a step further. .doc often breaks when you move it around, but it doesn't matter because everyone BELIEVES that it'll work anywhere. The reality doesn't matter much (in this case) only the perception of it.
plus-good, double-plus-good
WTF are you talking about?
The sufficiently complex applications *I* have written in Java -- including a mass mail server and a database migration utility -- have worked just FINE on every arbitrary Java installation I've seen. I wrote them on a PC, moved them to a Sun server , and still run them on my Mac. The trick is to write them in pure Java...no native libraries, and when you need a file separator, get it from Preferences...don't assume / (or \, or : for that matter)!
Now, the difference between Java and GLIB/GDK/GTK is that you only need ONE binary. That's one less thing to worry about supporting...one less thing to have to TEST everywhere. Furthermore, I've rarely seen a Java UI crash unexpectedly. GTK crashes all the time on "beta" systems...like Windows.
Hey freaks: now you're ju
The advantages of MS Office are:
The advantages of OpenOffice are:
What the heck are the advantages of EIOffice?
So, WTF?
After - quickly - scanning their website they are missing one very important business application. Outlook.
MS Office comes with Outlook, the eternal scurge of mail clients. Though for all its problems it has many useful features like the journal, calendar, note, and the intergration with the exchange server system.
Sorry EIOffice lacks this support and is unlikely to gain much in the way of a business application. For business applications, the killer app will be email and it's intergrated "tools" such as the ones I listed.
-Ghost
What really irks me about your post, however, is that the grandparent was modded to Flamebait for posting a fairly evenhanded opinion, but no fact. You've been modded to Interesting for posting what is, essentially, a flame against the grandparent, and still no fact.
You admit you find Java a waste of time, yet state that the parent was evenhanded. How do you know?
Unlike either of you I have written Java GUI apps that run on a variety of platforms (including the old Oracle Network Computer). It's really not hard to make an app that works pretty much the same just about anywhere. I did not, as the parent states, run into "issues that look a lot like porting issues". You run into that a little more if you have to support specific byte ordering in files, but that has nothing at all to do with GUI's. For the GUI itself I have NEVER had platform specific code, like you do with typical porting.
I'm not just talking about some form entry system, I'm talking about a variety of things from rich interactive maps to very complex MDI document data entry systems.
The parent to your post may have been a little harsh, but calling him a zealot just because he has experience you lack is unfair.
"There is more worth loving than we have strength to love." - Brian Jay Stanley
So thats why this office suite has two downloads one for windows, and one for linux. Same thing with other java software like limewire. Or I goto www.java.com and half the featured applications only run on windows or have multiple binaries for different operation systems. Thats really portable.
Have you ever been to a turkish prison?
If sticking your fingers in your ears and pretending it's not happening is your best response to outsourcing, you're screwed.
---- Den ene knappen er powerknapp, den andre er Bender voice knapp "Bite My Shiny Metal Ass"
damn, I'll have to actually make sure the shit I'm selling actually works!
Can you fathom the difference in complexity between testing something once, and testing it on N platforms? Generally speaking, if I have a java program I've compiled that will run on a Windows system, it will run everywhere else I could run it. That means I only have to test it once -- how many times -- once before giving it to the QA team. Now, they'll do their blast testing on their own systems...and very rarely will I have a platform specific issue. This means that supporting additional platforms is nearly free. Which means that if somebody really wanted our software but ran some obscure system...we could sell it to them without having to go buy a copy, and be almost entirely sure there won't be a problem.
then what in the hell are you doing developing software for it?
Please. This isn't 1972. Do you REALLY know everything about the hardware your users have? Chances are, no, you don't, you probably don't even know what set of vector instructions the processor will be using. You use abstraction layers to access said hardware. Well, Java takes that a step further...it abstracts the most basic function of the chip, along with giving you a single general access API Framework to do everything from write to the screen to operating a server. I suppose you could get all this from a makefile with a few thousand apocryphal branching options, or from some interpretted scripting language, but why?
nice to know the MS view of software development is still alive and well
Yeah, funny how Sun, IBM, and most of the other big guys have caught the bug. You know why? Because it works, dumbass.
Hey freaks: now you're ju