lkml.org 
[lkml]   [1999]   [Mar]   [15]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [OFFTOPIC]: MS Porting Office to Linux?
On Sat, 13 Mar 1999, Richard B. Johnson wrote:

>Vendor X has no idea what shared libraries exist in/on your system.
>To make certain that Vendor X's executable works, he provides some.

I realize that.

>Linux-ers got used to untarring a source-tree and building it.
>In this case, the libraries used will be the ones that exist on
>the system that built it.

Yes, but not always. Many many people download binary RPM's and
tarballs now, and have little if any trouble. Granted, larger
commercial packages are more susceptible to trouble, but the
solution IMHO is not to bundle libs...

>Now we have commercial software being ported to linux (just like
>Sun). To make sure it works, these vendors will provide
>libraries.

Yes. Unfortunately, their products become labeled "bloatware" by
doing so. I've followed several major commercial software
releases, and it seems that their apps are always linked to
obsolete libraries, usually a major version or more behind what
is current.

Why they do that, is likely to cover the most amount of machines
out there, as newer machines can usually use older libraries in
wrappers.

What I've found from discussing major commercial software
packages for Linux with anyone that has used them, is that any
given package performs poorly compared to it's windows
equivalent, and is a huge resource hog.

That is fine by me though, as it just disadvantages the app, and
makes open-source free alternatives more attractive in the
future.

Unfortunately, we are stuck now using bloatware and waiting for
GPL'd replacements, or we're stuck using M$.

>Now, if you have 2 or more users running Star Office, you are
>certainly sharing shared libraries so your complaint is not well
>though out.

No, I'm not really complaining, just pointing out some
disadvantages. And I did think it out well. I'm refering to the
average person's home computer, or even one being used in the
workplace in a manner similar to what Windows 95 or NT would be
being used in - a single user system.

Obviously a multiuser system that has multiple people logged in,
using Star, would benefit, however such a system is the
exception, not the rule. A user workstation using Star, wastes a
lot of memory IMHO. The best solution of course is open-source,
however I think other possibilities are viable as well. Perhaps
releasing a "general" release which works on systems with the
included libs, and another release which is compiled to the
latest up to date libraries in the latest distributions.


>Further, memory mapping a shared file, but not reading it
>yet, is less costly to performance than loading a large-size
>statically-linked file.

Ok, I'll take your word for that, but doesn't demand loading
prevent unneeded code/data from being loaded in the first place,
even in a static binary?

>I agree that Linux's new-found fame will cause integration problems
>when commercial software vendors provide their wares.

Yes, that is basically the problem. Commercial software doesn't
fit well into the distribution of the week scheme we've grown to
love. I think this is good though as it will only fuel the
open-source movement. I would rather PAY $50 to get Staroffice
source and compile it for my system, than get the binaries for
free and have to pay $500 to upgrade my system to use it.

>It is unfortunate that the first trial ballons will take a lot of heat.

Agreed. Star does take heat, it is a great program IMHO though.
I just wish it was useable. The Win32 version works very well on
my system - whereas the Linux version is more of a slideshow.

>Eventually vendors' installation programs will check to see what libraries
>your system has and use yours if they are compatible. They will eventually
>understand the power of a symbolic link. In the subject case, Star Office
>should have linked against LibStar-C (or other unique names), etc., and
>during installation, set appropriate symbolic links to compatible
>libraries their installation program found. If a compatible library was
>not found, they would provide theirs with appropriate symbolic links.

A great idea. It would also be nice if they'd try installing
their software on at least the last three releases of each major
distribution for compatibility checks. Perhaps making minor
modifications to the code to ensure that it at least installs
half decently.

Things will change in the future though, so I'm not really
worried. I'm just glad that companies are actually porting to
Linux in the first place.

Take care,
TTYL


--
Mike A. Harris Linux advocate GNU advocate
Computer Consultant Open Source advocate

The DVORAK keyboard layout RULES! I memorized it in 45 minutes
and I don't think I'm ever going back to QWERTY!


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/

\
 
 \ /
  Last update: 2005-03-22 13:50    [W:0.860 / U:1.200 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site