Loading ...
Sorry, an error occurred while loading the content.

Work-arounds vs. Upgrades in Open-Source Projects

Expand Messages
  • Shlomi Fish
    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
    Message 1 of 3 , Jul 31, 2002
    • 0 Attachment
      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 shlomif@...
      Home Page: http://t2.technion.ac.il/~shlomif/
      Home E-mail: shlomif@...

      "Let's suppose you have a table with 2^n cups..."
      "Wait a second - is n a natural number?"
    • Tzafrir Cohen
      ... 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
      Message 2 of 3 , Jul 31, 2002
      • 0 Attachment
        On Wed, 31 Jul 2002, Shlomi Fish wrote:

        >
        > 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.

        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

        >
        > 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.

        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!

        >
        > 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.

        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.

        >
        > 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?

        It is nice. If you can afford it.

        It also dpends how badly you want your software used.

        --
        Tzafrir Cohen
        mailto:tzafrir@...
        http://www.technion.ac.il/~tzafrir
      • Nadav Har'El
        ... 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,
        Message 3 of 3 , Jul 31, 2002
        • 0 Attachment
          On Wed, Jul 31, 2002, Shlomi Fish wrote about "[hackers-il] Work-arounds vs. Upgrades in Open-Source Projects":
          > 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.

          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
          nyh@... |-----------------------------------------
          Phone: +972-53-245868, ICQ 13349191 |Linux: Because rebooting is for adding
          http://nadav.harel.org.il |new hardware.
        Your message has been successfully submitted and would be delivered to recipients shortly.