Subject: Work-arounds vs. Upgrades in Open-Source Projects

From: Shlomi Fish <[email-masked]>
Date: Wed, 31 Jul 2002 18:13:32 +0300 (IDT)

I'd like to discuss the issue of two possibilities when an open-source
project encounters a bug in the underlying layer (which is also OS),
which is included in a common version of a Linux distribution:

1. Write a workaround for the code.

2. Tell the users to upgrade the package.

Now, when I heard in the SysCallTrack Lecture Muli and Guy gave about the
fact that they wrote a workaround in their code to work with the version
of gcc that was distributed with RedHat 6.2, I was shocked. I would not do
such a thing. If at all, I would have distributed a patch for it.

From what I understood, Windows programmers need to write workarounds all
the time. I know I once had to statically link against MFC because it
crashed if it was linked dynamically without debugging symbols, and there
did not seem to be anything wrong with my code. (back then, we didn't have
Insure, Purify or friends, but the code was peer reviewed). But most Linux
systems can be upgraded at a very low cost, and there does not seem to be
any reason to support all the old systems out there.

Of course, I encounter people using old versions of programs all the time.
Someone once told me he was using ghostscript 3 or 4... I upgrade my
Mandrake systems as soon as a release is out and I know there aren't too
many horror stories of upgrading. I'm a bit afraid of Mandrake 9.0 with
gcc 3.1 and all, because of the binary incompatibility, but I know the
core system will run fine.

I think writing workarounds is unhealthy because it can lead to badly
maintainable code. So I take the "tell your users to upgrade" path. What
do you think?

Regards,

	Shlomi Fish

----------------------------------------------------------------------
Shlomi Fish        [email-masked]
Home Page:         http://t2.technion.ac.il/~shlomif/
Home E-mail:       [email-masked]

"Let's suppose you have a table with 2^n cups..."
"Wait a second - is n a natural number?"

---

From: Tzafrir Cohen <[email-masked]>
Date: Wed, 31 Jul 2002 18:53:09 +0300 (IDT)

> 2. Tell the users to upgrade the package.

Which is nice, but not always feasable for the users.

Possible reasons:

* users may have some other programs that depend on the "buggy" version.

* Users may not want to bother. The program you write may be a newcommer.
They don't have any guarantee that it will even compile, let alone work
properly. Why upgrade a whole distro/package for that?

* They don't want to bother downloading (or maybe downloading a big
package is difficult

> any reason to support all the old systems out there.

Define "very low cost":

of software? certainly

Of working time? Depends on the case

On working time to revert the upgrade? (just in case it proved to be
problematic with some of the existing programs) That would be expensive!

> core system will run fine.

Actually, upgrading mandrake 6.x->7.x was problematic. So was 7.x->8.x

And Mandrake have a nasty habbit of not maintaining an archive of RPMs of
past versions.

> maintainable code. So I take the "tell your users to upgrade" path. What

It is nice. If you can afford it.

It also dpends how badly you want your software used.

-- 
Tzafrir Cohen
mailto:[email-masked]
http://www.technion.ac.il/~tzafrir

---

From: "Nadav Har'El" <[email-masked]>
Date: Thu, 1 Aug 2002 01:23:15 +0300

> 2. Tell the users to upgrade the package.

I think you're just thinking about a small part of the issue called
"portability". You are considering one branch of the huge systems tree.

For example, consider the Redhat branch. If someone is using Redhat 7.2
and your program was designed for Redhat 7.3, you tell that person to
upgrade. Ok, let's assume for a moment that this is valid advice. But
what if someone was using Mandrake 8.0 (say) - do you also tell them to
"upgrade" to Redhat 7.3? And someone using Solaris? Windows-NT? Mac?
Should they all "upgrade" to Redhat 7.3? Of course not.

Ideally, a portable program would work on all nodes of the system tree,
i.e., in all types of systems, all kinds of operating systems and all
versions. Programs like "autoconf" have been written to help you do that
by checking for the existance of various alternative features on the
various kinds and versions of systems. This is what you called "include a
workaround in the code".

But this approach has its limits - it takes time and effort to maintain
a portable program's portability for many systems types and versions.

Let's look at a small example. I have a program that I wrote and use daily,
that has an Autoconf based building system. I've run it over the years on
more than a dozen operating systems and an even greater number of versions.
At one point or another, this program compiled and ran well on each of these
systems. But what happens as time passes and I lose access to these systems?
About 6 years ago, I made that program compile on AIX (IBM's Unix). I had
to work around a bug that AIX's compiler had at that time. But if I tried
to compile it now on AIX, will it work? Possibly it will, possibly it won't.
Certainly the bug I found 6 years ago will be irrelevant now, but new bugs
might have cropped up. And if I dug up the 6-year-old AIX system and tried
to compile the current version of the program, again it might fail because
of new changes that I made in these 6 years and never tested on the AIX.

The problem of versions is very similar to the problem of system types.
E.g., my program might have worked 6 years ago on Redhat 5.0, but if I
try now my latest version of the program on a Redhat 5.0 I dig up, it might
not work because of changes that I've made and are incompatible with Redhat
5.0. I can tell you to upgrade to Redhat 7.3 to make it work, or I can
perhaps just fix the program to work again on 5.0. Whether I'd want to do
the former or the latter depends on two things:

 1. How important is Redhat 5.0 support for me or my users? If it's not
    important, e.g., nobody but Unix museums keep Redhat 5.0 any more,
    why should I bother making any changes? I have better things to do
    with my time, like writing long posts on hackers-il :)

 2. What impact will supporting Redhat 5.0 will have on the program? If it
    will take me a month to program, will increase the source code size by
    50%, will make the program run 50% slower on all machines - well, in this
    case the answer is obvious - I will not support Redhat 5.0.
    But if the change to support Redhat 5.0 will take me 10 minutes to do,
    increase the code size by 20 lines, slow the "configure" script by 1%
    and not change performance of the code in the non-Redhat-5.0 case - well
    in this case I *will* try to support Redhat 5.0 - assuming of course
    I have access to such a system (see #1).

Obviously, portability decisions like that is one big gray area. How do
you decide when to drop support for systems or versions that are becoming
rare and difficult to test? How much should you be tolorant to people who
are "too lazy" to upgrade to the latest version of a free operating system
and make you suffer inside? Should you support systems that you don't have
access to because they are very expensive? It's your call.

-- 
Nadav Har'El                        |         Thursday, Aug 1 2002, 23 Av 5762
[email-masked]             |-----------------------------------------
Phone: +972-53-245868, ICQ 13349191 |Linux: Because rebooting is for adding
http://nadav.harel.org.il           |new hardware.