On Nov 18, 2004, at 10:56 AM, Bogdan Costescu wrote:
>> We anticipate a first stable release in 1Q 2005.
>
> Under what license will it be released ?
Something quite similar to LAM's current license -- essentially the
modified BSD license (disclaimer: I'm not a lawyer, and this is not
legal advice!).
> n the other hand, I think that you have to define what classes of
> people you would like to address;
This is our primary concern -- the scientist or engineer who doesn't
know/care how MPI works and just wants to install it and run their app.
> It's not very clear to me yet if Open MPI will use a system similar to
> LAM/MPI's shared libraries to add optional modules.
It does. It's actually the default (whereas static builds are still
the default in LAM/MPI).
> This would make
> binary installation easier, as a maximum-compatibility tcp+shmem
> binary distribution could be eventually extended by some other modules
> either provided also as binaries by Open MPI or self compiled (to
> accomodate extra libraries). In this direction, maybe Open MPI should
> provide network enabled repositories for the most popular Linux
> distributions or packaging formats, like a yum/apt-rpm repo with RPMs
> for Fedora Fedora/Red Hat (& clones) and another one for .debs (unless
> Camm Maguire will volunteer to package it for Debian as he did with
> LAM/MPI :-)); sorry, I am completely ignorant as to whether such
> mechanism exists for MacOS...
Good input; thanks.
> For those that compile from source, I would like to (continue to) see
> included what is needed for making the binary packages, like the .spec
> file for generating RPMs. This will lower the barrier for
> distributions/repositories that would like to provide packages; it
> will also make it easier for those hard-liners that don't accept
> anything not managed by the package management tool(s).
Don't forget that being able to rebuild SRPMs is contingent upon being
able to compile a source tarball. So if cmake is required (for
example) to build a source tarball, then it will also be required to
rebuild a SRPM.
> In line with this, I would like to see also the eventual other tools
> needed for building being provided by Open MPI (not in the same
> package, of course), in both source and binary form. First and
> foremost, this will ensure that the exact same versions of the tools
> that the Open MPI developers are using are also available to those who
> compile it - this will obsolete statements like: "NOTE: The versions
> of these tools that are installed on most systems by default are not
> recent enough. You may need to update your installed versions." (from
> http://www.open-mpi.org/svn/ which also applies to LAM). The tools
> themselves should be as portable as possible and should ideally be
> standalone (=not dependent on others, especially not dependent of
> something like Java/python/perl/ruby/etc. which are not seen very well
> at some HPC sites). This would probably be a big plus for the GNU
> auto* tools at the moment which run on virtually anything.
Ah -- are you saying that we should offer distributions of the GNU auto
tools that are known to work for LAM (for example)?
> Another thing that I consider important is the speed of the
> compilation and installation process. For example, right now with LAM
> the configure step takes quite some time; I'd be happy if different
> build tools would significantly reduce that time. I would argue that
> this is important for some end-users as well: when you have a problem,
> you write to the mailing list and might receive an answer like "this
> is a bug, can you check out from SVN and test" and it might take
> several iterations to do it right (not that I doubt the capabilities
> of the Open MPI developers, but I assume that all are Homo sapiens
> sapiens :-))
Good points. Thanks for the feedback!
--
{+} Jeff Squyres
{+} jsquyres_at_[hidden]
{+} http://www.lam-mpi.org/
|
