[Beowulf] SGI to offer Windows on clusters

[Andrew M.A. Cater]

On Mon, Apr 16, 2007 at 04:35:27PM -0400, Robert G. Brown wrote:
> On Mon, 16 Apr 2007, Joshua Baker-LePain wrote:
> 
> >On Mon, 16 Apr 2007 at 2:12pm, Robert G. Brown wrote
> >
> >>Try installing two year old Centos AT ALL on six-month-old hardware, and
> >>I think that there is a very high probability that it will require a
> >>much larger investment in time backporting kernels and worse.
> >
> >I think you underestimate the amount of driver back-porting RH puts into 
> >point releases.  When I first got my dual woodcrest compute nodes, the 
> >current CentOS point release (4.4) worked almost perfectly on them (a 
> >network driver upgrade removed the "almost" from that statement).  Are the 
> >app libraries out of date compared to Fedora?  Sure.  Are you more likely 
> >to have success at this with "server" hardware than more desktop oriented 
> >hardware? Sure.  But the point is that RH does roll a lot of new hardware 
> >support into their enterprise distro as it ages.
> 

That's the point - and the problem. Red Hat doesn't release stable 
releases - it releases enterprise class releases and then changes
stuff, sometimes subtly, sometimes radically between point releases.

Don't even _think_ about a seamless upgrade from Red Hat EL3 to Red Hat 
EL4. [I found, when I made a dual boot test system, that I couldn't 
install RH4 first then RH3 - the ext3 file system had changed so 
significantly that it wouldn't work - possibly something to do with SE 
Linux attributes.] RH EL4 to RH EL5 ?????

> And the other point is that it isn't just driver backporting that
> matters.  There is chipset support and more.  There is HAL.  The problem
> is especially pernicious (and visible) on laptops, but I've encountered
> it multiple times on desktops as well.  It isn't just what they fix in
> the update stream -- you still have to be able to INSTALL on the system,
> and it is a wee bit difficult to install Centos on a system when the
> UNchanged install image kernel lacks the right chipset support and
> network drivers.  Yes, I've wasted days trying to find a combination
> that would make it work.  Yes, I've been burned multiple times.  Even if
> you can manage to get a boot to work, in some cases "stability" is a
> stochastic thing and a system will run for a while and then die when it
> finally does the wrong thing.
> 
> This is directly associated with the wish for a minimal install -- I
> have a system sitting upstairs right now that thinks that it has a
> problem with a library that a) I've updated repeatedly so that I'm
> certain that the image I'm installing from matches the one on Duke's
> mirrors; b) I could care less about anyway -- if I could easily figure
> out what it is that thinks that it needs it I'd eliminate the toplevel
> package and get the system to install.

I think you need to look at Debian :) The bare minimum install does have 
some bloat - perl, for example - but it does work.

> 
> The main reason I'm whining online like this is that I really see things
> going in a really bad, really wrong way fast here.  Every new release of
> FC or RH is bigger and more complex.  Very little intelligent effort
> seems to have been expended in hierarchical decompositions of this
> increasingly vast system and application space -- even into just this:
> "systems" vs "application" space -- and as a consequence certain already
> annoying but not quite critical problems are about to be magnified
> enormously.
> 

Don't use RH based systems.

> Well, its about to stop being easy.  It may stop being POSSIBLE.  500
> packages was easy.  1500 packages wasn't easy, but with enough effort it
> was doable.  6000+ packages is doable only because it is effectively
> decomposed into 1500+4500 or thereabouts.  7000, 9000, 11000 packages as
> a single set is going to be a living nightmare.  FC "as a whole" will
> simply "never" work for the whole package set in its lifetime, and
> nobody will know what bugs and dependencies really need to be fixed
> first as they are twined throughout the entire huge space.
> 

There's no ready way that Fedora can release every 6-9 months or even 
every 18 and retain its quality if it retains its "bleeding edge"-ness.

Debian only makes it because there are, effectively, three parallel 
streams which differ in package churn rather than stability.

"Unstable" may sometimes break. If it doesn't, packages 
gradually percolate down after a period of relative bug-freeness and 
become "testing" - and get tested and refined for up to two years until 
that "testing" gets released as "stable". Then it gets supported as 
unconditionally stable - with security and bugfixes applied but 
minimal change - for the next two years or so. Lather, rinse, repeat. 
The charge that Debian is "always out of date" is simultaneously true - 
and false: it can be as up to date as your last upgrade - and whole 
distribution updates are pushed to the mirrors every twelve hours.

> This is something that I think that the debian developers have done much
> better with, and is the only way they can manage the close to 20Kpkgs
> that make up "greater" Debian.
> 

See above. I can claim no credit - it's just that 10+ years of 
development have converged into a system which works - except when it 
doesn't :) [The login bug which clobbered xdm was that was found 
worldwide within 30 minutes, worked around within 50 and fixed within an 
hour and a half, to be propagated to the mirrors the next day, if I 
recall correctly :) Beat that for speed :) ]

> Whine, whine, whine.  We (in linux) need to take a giant step BACKWARDS
> and build a rock-solid common "a"-core, establish at least the "b"-level
> decomposition that is likely to be common to all linux distros, and then
> build distro-specificity and divergence at the "c" and "d" levels only.
> I'd like to see this so much so that one could install an ab-core system
> using (e.g. FC) and then complete the install using debian packages or
> vice versa and have everything work "perfectly" as far as the core
> interactions where concerned -- they can break like hell if you want at
> the d-level packaging and dependency resolution, but ab-level
> dependencies need to "by definition" be a solid, self-contained base
> that one can stabilize and thereafter just not (easily) break.
> 

Sounds like we need to revisit the discussion of how to replace Extreme 
Linux with a "distribution-agnostic" distribution with .rpm, .deb and 
.tgz - July 1998 or so? :) :)

Andy

>     rgb
> 
> >
> >
> 
> -- 
> Robert G. Brown	                       http://www.phy.duke.edu/~rgb/
> Duke University Dept. of Physics, Box 90305
> Durham, N.C. 27708-0305
> Phone: 1-919-660-2567  Fax: 919-660-2525     email:rgb at phy.duke.edu
> 
> 
> _______________________________________________
> Beowulf mailing list, Beowulf at beowulf.org
> To change your subscription (digest mode or unsubscribe) visit 
> http://www.beowulf.org/mailman/listinfo/beowulf