Boston Linux & Unix (BLU) Home | Calendar | Mail Lists | List Archives | Desktop SIG | Hardware Hacking SIG
Wiki | Flickr | PicasaWeb | Video | Maps & Directions | Installfests | Keysignings
Linux Cafe | Meeting Notes | Blog | Linux Links | Bling | About BLU

BLU Discuss list archive


[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Plugin Bloat (speeding up OpenOffice?)



dsr at tao.merseine.nu wrote:
> On Wed, Jan 17, 2007 at 09:53:17PM -0500, Rich Braun wrote:
>> I just set up a major new app on my now-pretty-old Linux box.  It's an app
>> that dates back to BBS days, 

That's not a very new app is it? :-)

>> Between the bloat slowing everything down, and the plugins requiring hours of
>> administrative headaches (downloading, resolving incompatibilities, fixing
>> file permissions, shuffling directories), using a Linux box is becoming more
>> of a headache than it used to be--even for those of us who know how to find
>> all the technical gotchas under the hood.

Are the problems you had because of linux, or because of poor development
practices (or lack of install script) of the particular (apparently ancient)
application that isn't even related to Linux?  Would installing this app
have been easier on Windows or some other OS?  If so, is that just because
those other OSs require binary-packages, and require them to "do the right
thing"?

Distros and their package management systems (rpm, deb) and meta-systems
(yum, apt) have evolved and really make all those things you mentioned
easier now.  For people that insist on using bare src.tar.gz instead of
packages (or use an obscure distro that no one makes packages for), well, I
guess what you said is accurate for them.  For instance, I use Trac a lot.
It's got a bunch of obscure dependencies.  But some poor soul figured it all
out, got everything that was needed into Fedora Extras, and now I can
install Trac (and all the aforementioned dependencies) with a one liner:
"yum install trac".  All the permissions, version compatibilities, etc are
all taken care of automatically.

If that BBS is so difficult to set up for your distro, and you went through
the pain of figuring it out, why not contribute a spec file for your
distro's package management system to the BBS makers (or your distro)?.
Typically, all it takes is one person to support the packaging of a given app...

My basic point is that you can't expect the functional aspects of software
(and even the details of how software is developed) to evolve over time but
keep "old" sys-admin habits.  OSS is producing an enormous amount of
code-sharing/reuse (there are 50 packages on my system that /require/
libjpeg.so.62, and probably a few more that load it if it's available), but
the cost of that is DLL-hell-like problems.  Package management systems are
the answer to that; avoid using them at your own peril...

>> Just venting, I guess, I don't really see a solution.  The open-source
>> movement is pretty much by definition oriented toward bloat:  contributions
>> keep coming in and adding to the code pile.
> 
> Depends on the project. There are lots of projects specifically
> devoted to efficient use of resources. On a desktop box, try
> running:
> 
> - XFCE instead of GNOME or KDE
> - AbiWord and Gnumeric instead of OpenOffice
> - Galeon instead of Mozilla
> ...

I agree with dsr that your statement about all open source projects lending
themselves to bloat is overly broad.  This becomes even more obvious when
you look outside the "desktop software" arena: would you consider Apache
bloated?  It can run on some really meager hardware.  (and there are plenty
of other open-source light-weight web servers that make Apache's footprint
look huge, at the cost of significant features)

With respect to Word-compatibility, one might make an argument that to
support all the features of the bloatware that is M$ Word, you have to be
pretty bloated yourself.  Of course, if AbiWord supports the MS format as
well as OO, that kind of shoots that argument down.  But I suspect it's not
quite that black-and-white, and things such as "quality" of the emulation
come in to play as well.  (this kind of thing is really obvious in M$ Office
drawings, whether in Word or powerpoint, where the drawings look great in OO
and all messed up in Word, or vis-a-versa, depending on which tool created
the original).

Matt

-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.





BLU is a member of BostonUserGroups
BLU is a member of BostonUserGroups
We also thank MIT for the use of their facilities.

Valid HTML 4.01! Valid CSS!



Boston Linux & Unix / webmaster@blu.org