really has partnered with Rosner for a [109]MP3 denim jacket (well it looks
   denim; I could be wrong) and O'Neill for a [110]MP3 enabled snowboarding
   jacket -- now you "Extreme Linux" fans have something to wear.

   No idea what OS the players use, sorry - fashion doesn't care about that. Is
   the open source concept affecting fashion more directly? Maybe not. But
   [111]someone's thinking about it.

   Amazing. Maybe we're getting somewhere. Until next month, folks. I and my
   red straw hat are off shopping.
            ____________________________________________________

(?) Generic installer locations

   From Jay R. Ashworth 

                                                Answered By: Thomas Adam 

   I  have a project, sitting here on the desk in front of me, for a menu
   program that I need to decide on an implementation language for. 

   The target environments are SCO OS5 and quite some different number of Linux
   distros; the possible languages are Python and Perl. 

   While I don't especially care if the buyer can see the code, what I do care
   about is not putting the installer into either dependency hell or conflict
   hell, while still having the pieces I need to do the work. 

   This seems like a reasonably common problem; any suggestions on how to
   approach it? 

     (!) [Thomas] Graphical, console or both?

   (?) [Jay] I suppose that was pertinent, yes; it's a menu program; text, but
   full screen. 

     (!) [Thomas] Who cares what language you'll write it in? ncurses is ported
     to Solaris, as is slang. You can probably even use "dialog". All of these
     libaries have bindings to lots of languages. As for the "benefit" pffft.
     Just use what comes naturally to you.

   (?) [Jay] I apologize; I thought I'd made my specific point clear on the
   first pass: 

     This program, when done, sold and shipped, needs to be able to install and
     run reliably on all target platforms without conflicting with, or, really,
     depending on, whatever language runtimes might or might not already be
     there.  I  don't  object to depending on what's there, or brilliant
     installers, or any of that stuff, but on SCO, I'm likely to have an
     ancient Perl and no Python at all...

     (!) [Thomas] Ok. So as long as you ensure you compile against a modern
     glibc, you should be fine. But what you cannot expect is something near
     perfect. If a potential target doesn't have XYZ installed then they should
     ensure so. Clearly versions of dependencies <= compiled_version will be
     OK, and you can test for that.

   (?) [Jay] and on Linux, you never know what will be there -- or what you
   might break if you have library/module conflicts. 

     (!) [Thomas] Indeed.

   (?) [Jay] So, again, going back to Fred Brooks' System Program Product
   concept (you know, the thing that takes 9 times as long as a simple hack?
   :-) , what is the best approach to this? 

     (!) [Thomas] Well, if you do have an antiquated version of XYZ where you
     know that in most cases the software on the target machines might well be
     newer, it should be a safe [1] approach to assume that the code you have
     is "backwards compatible" with what you produced -- i.e. it won't be using
     the newer features possibily present.

     [1] In theory, great. In practice, err.....

     Skip various snide comments -- Thomas Adam

   (?) [Jay] I propose to deploy as a commercial product a program written in a
   language  which  expects  an installed interpreter, with a system-wide
   directory of modules. 

   If that infrastructure exists, I don't object to using it (assuming that
   everything's the right version). But if it's not there, it's not my place
   to install it -- the client isn't buying a-complete-perl-install, and I
   don't want to be responsible for that, anyway. 

     (!) [Thomas] OK. Well, most distributions tend to put things like that in
     standard locations (/usr/share/$foo || /usr/lib/$foo)/ Often, these paths
     will have various environment variables defined depending on the platform
     you're installing it to, so that is definitely something to check. Of
     course that depends on the language it is written in.

   (?) [Jay] I don't have 6 years and 40 machines. 

     (!) [Thomas] I know what you mean, time is short. What I really meant by
     this is getting a Solaris machine, a linux machine, an HP-UX machine,
     whatever and seeing what the differences are to compensate. How else will
     you know otherwise?

   (?) [Jay] Because that doesn't take into account what might have already
   been done adminstratively to the machine.