Re: Extreme Linux
First, I was the person who stirred water there. I think we should
introduce Debian to these people.
> Our pvm package produces both static and dynamic libraries.
> I believe the EL PVM only has static libraries. For compatibility it would
> be beneficial for us if they had a dynamic library with the same SONAME.
The whole idea is to use Debian system instead of RedHat. Of course we will
use dynamic libraries, which is much more elegant. I did not see compatibility
is an issue.
> EL needs a queueing system, but the non-commercial distribution clause in
> DQS (our only queueing system at present) probably precludes their use of
> it. PBS looks like the Beowulf favorite, but it's been in beta to U.S.-only
> sites for years. Who knows if there will ever be a public license. I wish
> GNQS was further along, but can't dedicate the time needed to give it all
> the capabilities it needs for my use when DQS is almost DFSG-free and
> currently sufficient.
This is why Debian is better. However, we need to deliver such systems to
show people. Our company (Kachina) had decided to take the mission. We
started using Debian simply because we found it _is_ the best platform for
clustering systems.
>
> Debian already distributes most everything EL has, and several things EL
> is missing (eg. a queueing system). EL might be able to make good use of
> some of our software though. Our PVM package was modified to produce both
> static and shared libraries. Our Povray source produces both PVM and
> non-PVM binaries (the upstream pvmpov patches are PVM-only). Thanks
> particularly to John Lapeyre Debian already has more scientific packages
> than any other distribution. EL could scavenge his work. Scientific
> packages are nasty to compile.
This is why we are here. There was a debate about changing "math" to "science"
(actually I think it should be "scientific") but the thread seemed dead.
What was the conclusion? Our SAL (http://sal.kachinatech.com) currently has
nine (9) categories for scientific applications. We tried our best to make
them as accurate as possible but we still need help from people who work in
other fields we are not familiar with. Since there are more than two thousands
applications listed (some programs are already listed in devel/, lib/,
language/, and graphics/ etc.), can we have subcategories under proposed
scien(ce|tific)/ ?
>
> What Debian really needs to become the prefered cluster distribution is
> non-interactive postinsts. EL isn't in a position to give us this, and
> we've already got everything else we need, even if some of it is non-free.
EXACTLY!!! Well said! I think we first should have a profile "Extreme Linux"
and then we should create a user-definable profile. You can either save it on
a floppy (like Caldera does) for workstation-style installation of multiple
nodes, or save it on a boot server (tftp). If the hostname matches, the
installation process will follow the list dutifully and we can install multiple
nodes in parallel and guarantee identical system images among the nodes.
> An automatic 'N' to the config-file handler would allow a cluster admin
> to predistribute most config files before upgrading a package, cutting out
> about 90% of the interaction with well-chosen packages. For really big
> farms nothing short of 100% would be sufficient though.
Yes. We should not be asked "[c/m]" again and again since we already told
it we had a color monitor at the very beginning ;-0.
> Perhaps a policy of checking for existence of an /etc/batch-install
> before doing anything interactive (update-mime, config-file handling,
> postinst reads), and choosing the simplest alternative when in batch mode
> would do. The work on batch installs seems to have stalled (unless it's on
> a list I'm not subscribed to- debian-dpkg is all bug reports lately). The
> configuration database proposed a few months ago may be too complex to do
> when so few need it. I've been meaning to try some simple batch changes, but
> can't on my workstation cluster (users) and my 486 mini-cluster is
> completely disassembled at the moment.
> When a non-interactive method exists we should write a Cluster HOWTO.
> The DQS README.Debian would be a good start, as it already covers a few
> related clustering issues (NFS, NIS, automounting, firewalling).
> Documentation is another missing feature of Extreme Linux.
Good ideas!
> So ... I think we're on track to take over the Beowulf market. The only
> reason I can think of to follow up a non-Debian distribution discussion on
> the beowulf lists is marketing, and we're not quite ready to market to large
> clusters yet. When we are ready, I think the big clusters will come to us
> without any prodding for the enormous pool of high quality cluster-ready
> apps.
I think based on status of RedHat software, we are already ahead of
them based on Debian's inheretant features. Also beowulf list should not
be a RedHat list.
We should start getting some attention first and ecouraging people to give
Debian a try. We also need more developers, particularly on scientific
applications. Don't we?
--ward
Reply to: