One statement needs clarification, Dave:
SGE is essentially a superset of UGE.
Univa Grid Engine != https://github.com/gridengine/gridengine
The github repo is the source of the open core of Univa Grid Engine. We
enhance it with proprietary extensions, we build and then extensively QA
it. This is the Univa Grid Engine which Univa supports and for which we
also indemnify customers against legal issues.
What you meant to say I assume, Dave, is that you've done some level of
comparison between the github repo and the Son of Grid Engine repo. It
might help if you detailed what that comparison did entail.
Cheers,
Fritz
Am 11.06.11 02:13, schrieb Dave Love:
Vadim Gutnik<[email protected]> writes:
This feels like a question for Miss Manners, but... which fork should I use?
I assume as a user, not contirbutor. Up to you, but only UGE is
commercially supported as far as I know, if that's a criterion and you
can afford it. Howvere, I can say something about them
http://gridengine.org/blog/faq/ mentions 3 forks:
‘Son of Grid Engine’ at:https://arc.liv.ac.uk/trac/SGE
Open Grid Scheduler at:http://gridscheduler.sourceforge.net/
Univa Grid Engine Core at:https://github.com/gridengine/gridengine
SGE is essentially a superset of UGE. The conflicts shouldn't be
user-visible outside man pages. Just counting patches from Univa
and not (but some of the univa ones are quite extensive):
sge800$ darcs log --from-tag final_sunsource --match 'name Univa' | grep
'^[^ ]' | wc -l
104
sge800$ darcs log --from-tag final_sunsource --match 'not name Univa' | grep
'^[^ ]' | wc -l
269
The extra code changes over UGE are small so far, and should be safe.
The project is now (as far as I know) the only repo with Inspect and
SDM, if you want them, but they haven't been worked on. It also
presevres arco's reporting component.
Reasons to use OGS seem to be that it's blessed by Oracle and done by
"experienced developers", but Rayson should speak to that. It has few
user-visible changes over the old sunsource code.
It's been a few months since the transition from Oracle; is there any
movement towards concensus? Or, to put it another way: is anyone
planning to package any of these forks for Debian or Redhat and make
them easier to install?
I've said yes more than once. See also
http://gridengine.org/pipermail/dev/2011-June/000045.html.
If you want rpms of something like OGS, see
http://arc.liv.ac.uk/downloads/SGE/packages/RH5/ whihc I think has more
fixes. I haven't had time to sort dpkg, much as I might prefer
Debian. The plan was to avoid Debian and Fedora having to patch it, at
least, but I don't understand all their current patches.
--
Fritz Ferstl | CTO and Business Development, EMEA
Univa Corporation <http://www.univa.com/> | The Data Center Optimization
Company
E-Mail: [email protected] | Phone: +49.9471.200.195 | Mobile:
+49.170.819.7390
_______________________________________________
users mailing list
[email protected]
https://gridengine.org/mailman/listinfo/users
