Die GNU autotools

[Tzafrir Cohen]

On Thu, Jan 13, 2011 at 10:45:45PM +0200, Elazar Leibovich wrote:
> I think you described correctly the root of the disagreement.
> I believe that any software (including free software) is written not as to
> implement an Aristotle's Ideal, but to be used by as many people as
> possible, and to be useful for them.

Right. Though most of them won't build it directly. Most of those who
will build it will build it through some sort of packaging system. Be it
RPM, DEB, the Ports of the BSDs, or OpenEmbedded and similar embedded
system builders. All of those have the concept of packages. If you
bundle libfoo in package bar, and libfoo is also needed for building
baz, it would be a waste of time and disk space to build it twice.

Also note that if you bundle a library in your code, you tend to no
longer treat the interface to it as public. It's part of your code base.
You want to change the interface a bit: you go ahead and change it. You
can also change the behaviour of the code to match your requirements.

This is fine and dandy. But what happens when a new upstream version
comes? Do you apply it? Or do you avoid changing something that works
(and is already tested)?

And if that upstream version fixes a hole or two?

> So when I'm writing a free software, I'm trying to make it as useful as
> possible to most people. If most people are having 2Gb of memory on their
> machine they probably won't care for an extra 20Mb, 

You're not the only one who adds just extra 20Mb. This is why they have
a policy in place not to allow those. And in the process they manage to
shave off some extra 100MB.

https://fedoraproject.org/wiki/Packaging:No_Bundled_Libraries

> so they'll be happy to
> have a better tested software and pay for that in 20Mb of memory of the JVM
> (they would only pay of course if they're running two JVM based
> software simultaneously, which is not so common). Of course, I won't force
> my user to use extra 200Mb, that could matter, but nowadays 20Mb in those
> settings are not such a big deal. Wasting 20 minutes of my user's time on
> updating his JVM is. I also want to support my users, even though I'm
> writing a free software. I really want it to be useful.

But I as a packager want to work a bit harder so that my users would
have an optimal build process. After I did that extra work, I send my
patches to you ("please add an option to use the system copy of
libfoo").

You don't have to accept it. But if you don't, my fellow packager will
copy that patch from me directly rather than from you. And then you end
up with a large portion of your userbase build off a different code base
than your upstream code. Which is not what you wanted.

> 
> You see free software writing as an art. The software you write must
> implement the ideal best software, even if it's not the most practical
> solution. So, for instance, you'll use an extremely complicated algorithm,
> which is hard to debug and maintain, even though it gives no
> user visible performance gain, only because it is "the right thing to do".
> It is a plausible stance I can understand, and I understand why this stance
> cause you to prefer the autosuite for every project, despite its costs.

But much of this can be distributed. If you want to take all of it to
yourself: go ahead. But I suggest you don't make the work of potential
packagers, who may take some load off your shoulders, more difficult.

> 
> And by the way, if a software is working correctly and using 10Mb, and
> another software does the same thing with 5Mb of memory usage, I won't
> switch. It really wouldn't matter for me, the difference between both is
> immeasurable for my computer usage patterns.

Many people now complain that the live version of Debian does no longer
fit into a single CD. It seems that an extra MB here and there does
matter.

There are many fields where memory usage matters:

1. embedded devices
2. virtualization: the less memory (and other resources) you use, the
   more guests you can put on the server.

But hey, who cares about those fields?

-- 
Tzafrir Cohen         | tzafrir at jabber.org | VIM is
http://tzafrir.org.il |                    | a Mutt's
tzafrir at cohens.org.il |                    |  best
tzafrir at debian.org    |                    | friend