Matthrew, responding to Paul:
> > If for whatever reason, you don't think it is worth the effort to morph
> > the virtual resouce manager that is currently embedded within CKRM into
> > an independent, neutral framework, then don't expect the rest of us to
> > embrace it. Do you think Reiser would have gladly used vfs to plug in
> > his file system if it had been called "ext"? In my personal opinion, it
> > would be foolhardy for SGI, NEC, Bull, Platform (LSF) or Altair (PBS) to
> > rely on critical technology so clearly biased toward and dominated by a
> > natural competitor.
>
> I don't think that is terribly fair. I can honestly say that I'm not
> opposing your implementation because of who you work for.
Good point. I was painting with too wide a brush (hmmm ... someday I
should see if I can get through an entire post without an analogy ...)
When people show a good ability to work with others on lkml who have a
shared interest and sufficient competence in an area, then it doesn't
much matter what company they work for. I see such a discussion
happening on another portion of this thread, with yourself, Nick, Peter
and Erich, involving the domain scheduler. That works well.
So far I have been unable to achieve confidence in my ability to
interact well with the key CKRM folks. In various ways, I have found
their project, and their demeanor on this list, to be difficult for me
to approach.
Normally this wouldn't matter. However Andrew and others have proposed
that cpusets have a critical dependency on CKRM. Now it matters.
If I am to have a critical project dependency on an external group with
whom I lack confidence that we share sufficient common interest and a
healthy ability to communicate, then I prefer a more adversarial style
of relations, with explicit contracts, minimum clearly defined and
verifiable deliverables, and suitable fallback contingencies in place.
I keep a sharp eye out for potential conflicts of interest.
My suggestion to separate the virtual resource management framework
(which I named 'vrm') from CKRM's other elements, such as fair share
scheduling, was an attempt to establish such a minimum verifiable
deliverable. That suggestion was clearly dead on arrival.
My apologies for implicating everyone whose email ends in "ibm.com" in
my earlier comment. IBM is a big place, and all manner and variety
of people work there. It's a pleasure working with yourself, Matthew,
and many others from IBM.
--
I won't rest till it's the best ...
Programmer, Linux Scalability
Paul Jackson <[EMAIL PROTECTED]> 1.650.933.1373
-------------------------------------------------------
This SF.net email is sponsored by: IT Product Guide on ITManagersJournal
Use IT products in your business? Tell us what you think of them. Give us
Your Opinions, Get Free ThinkGeek Gift Certificates! Click to find out more
http://productguide.itmanagersjournal.com/guidepromo.tmpl
_______________________________________________
ckrm-tech mailing list
https://lists.sourceforge.net/lists/listinfo/ckrm-tech
