New definition (Definition of software bloat - see "Emacs" (veering off-topic)) [LWN.net]

New definition (Definition of software bloat - see "Emacs" (veering off-topic))

Posted Feb 25, 2008 20:19 UTC (Mon) by zlynx (guest, #2285)
In reply to: New definition (Definition of software bloat - see "Emacs" (veering off-topic)) by jordanb
Parent article: Emacs news: new maintainer, version 22 pretest

It depends on which sort of bloat.

Eclipse wins for run-time memory usage bloat.  I've seen it go to 800 MB.

But Open Office wins for source code bloat I think.  It can take over 8 hours to compile on a
fairly decent machine and GCC 4.2.x.

to post comments

New definition (Definition of software bloat - see "Emacs" (veering off-topic))

Posted Feb 25, 2008 21:41 UTC (Mon) by nix (subscriber, #2304) [Link] (2 responses)

Agreed.

`Look! There's a wheel!'
`I know, let's reinvent it, and make ours square.'

Iterate for several dozen wheels.

New definition (Definition of software bloat - see "Emacs" (veering off-topic))

Posted Feb 26, 2008 13:05 UTC (Tue) by smitty_one_each (subscriber, #28989) [Link] (1 responses)

The clear goal of any wheel-reinvention project is to rationalize pi, silly rabbit.

New definition (Definition of software bloat - see "Emacs" (veering off-topic))

Posted Feb 28, 2008 19:46 UTC (Thu) by nix (subscriber, #2304) [Link]

OpenOffice tries to have its pi and eat it, but it's eaten so many pis 
that it's got terribly fat.

*puts metaphor into concrete mixer and walks away*

[OT] The real definition of software bloat

Posted Feb 25, 2008 22:50 UTC (Mon) by man_ls (guest, #15091) [Link]

800 MB! Haw haw haw! If you want to see positive bloat, just try IBM's payware versions of Eclipse. WSAD 6 was ludicrous in its memory usage, and (with help from a few custom plugins) I have seen it reach 2 GB. As to the all new RAD 7... the full installer takes something like 11 DVDs.

Of course none of this is free software, but it is based on free software.

Still more software bloat (even further off topic)

Posted Feb 26, 2008 2:01 UTC (Tue) by pr1268 (guest, #24648) [Link] (3 responses)

But Open Office wins for source code bloat I think. It can take over 8 hours to compile on a fairly decent machine and GCC 4.2.x.

While we're on this tangent, I might add that another friend of mine actually attempted to compile Firefox from source. Something like 450 MB of source code alone! After a whole weekend he hadn't gotten very far. (He thought it was convenient that the FF image rendering library is titled "libpr0n" or similar.) :-)

As for my earlier friend trying to edit the 750 MB text file in Emacs, FWIW it was a Dell desktop PC with a (32-bit) P4 HT and 1GB of RAM running RHEL 4.

Still more software bloat (even further off topic)

Posted Feb 26, 2008 21:24 UTC (Tue) by kamil (guest, #3802) [Link] (2 responses)

I find this hard to believe.  Being a Gentoo user, I routinely compile Firefox on my machines.
On the lowly laptop I'm typing this in (Pentium-M 1.7 GHz), Firefox 2.0.0.12 took 32 minutes
to compile.  Maybe your friend simply didn't have enough RAM and GCC had to resort to using
swap -- that would sure slow the process down to a crawl.

Having said that, I never even try compiling OOo.  It is the only open source package I
install from pre-compiled binaries.

Still more software bloat (even further off topic)

Posted Feb 26, 2008 21:42 UTC (Tue) by pr1268 (guest, #24648) [Link] (1 responses)

Maybe your friend simply didn't have enough RAM and GCC had to resort to using swap -- that would sure slow the process down to a crawl.

Oops! I forgot to mention that my friend attempting to compile Firefox from source code was doing so in Windows using Visual Studio .NET. He mentioned that he was able to hobble together some functionality but the running program had "various stability and reliability issues...".

I thought I read somewhere that the Win32 version of FF is compiled on Windows using Cygwin and/or MinGW using CMake, but I might be mistaken.

Still more software bloat (even further off topic)

Posted Feb 28, 2008 19:36 UTC (Thu) by nix (subscriber, #2304) [Link]

Yeah, well, that explains it. Cygwin is very slow at fork()ing, and 
several fork()s are involved in the process of compiling a single .o. 
There are tens of thousands of object files in Firefox.

(The sources for Firefox on my system clock in at a 'mere' 340Mb.)