[GE users] sge6.2u5 source ?

ron ron_chen_123 at yahoo.com
Fri Jul 2 22:57:02 BST 2010


    [ The following text is in the "utf-8" character set. ]
    [ Your display is set for the "ISO-8859-10" character set.  ]
    [ Some characters may be displayed incorrectly. ]

It's not urgent, since I googled and found the "IPv6 commlib" discussions on the dev list that happened last year by Lonel, Rayson, and Christian, with references to the files and functions for the IPv6 changes. I believe we should restart the IPv6 porting some day, as IPv6 is becoming more common now.

I think the commlib port would be useful if we get picked by the Google Summer of Code, but seems like Google does not like us. Since I have touched the commlib before when I added the poll() stuff, I will take a look at it again.

As the commlib doc is less urgent and important, you guys can take your time in producing the docs -- and focus on projects that make money, since Larry is less forgiving than Jonathan! :-(

Nevertheless, thanks Dan and Reisi for the effort!

 -Ron




--- On Sat, 7/3/10, templedf <daniel.templeton at oracle.com> wrote:
> I finally checked with Reisi about the docs.  Looks
> like there is indeed 
> an internal doc on the comm lib.  It's honestly the
> first and only 
> internal doc I'm aware of.  When Reisi has some spare
> time, I'll ask him 
> to get it translated from our internal wiki to some
> externalizable 
> format and clean it up for external consumption.
> 
> Daniel
> 
> On 06/25/10 09:47, ron wrote:
> > --- On Fri, 6/25/10, templedf<daniel.templeton at oracle.com> wrote:
> >>> yep, I'm pretty sure there is some internal
> >> documentation which would
> >>> make adding features more easy.
> >>
> >> Sadly, no.  All of the docs we have are
> open.
> >
> > Hi Dan,
> >
> > I think the commlib is a big piece of undocumented
> code, and Christian said that he would work on the docs when
> I asked for them more than 5 years ago:
> >
> > http://gridengine.sunsource.net/ds/viewMessage.do?dsForumId=39&dsMessageId=11717
> >
> > So Sun did not have a lot of internal docs even for
> the support team?
> >
> >   -Ron
> >
> >
> >>
> >>> Also in reference to the recent
> >>> question on the list about JGDI and JMX: any
> document
> >> besides looking
> >>> into the source?
> >>>
> >>
> >> You can build the javadocs from the source. 
> Aside
> >> from that, there's
> >> nothing.  JGDI is not intended as a public
> API.
> >> It exposes the
> >> qmaster's internal data structures, which means
> it's almost
> >> guaranteed
> >> to change with every release.
> >>
> >>> Somehow I have the feeling, that SGE/OGE is
> somewhere
> >> between closed
> >>> source and open source. On the one hand it's
> open
> >> source, but on the
> >>> other hand still under SUN/Oracle's QA as they
> sell
> >> their support and
> >>> can't allow any custom changes to the code
> base of
> >> course, which makes
> >>> it impossible for the community to make just
> some
> >> improvements to the
> >>> source. Enhancements of e.g. `qstat' were
> quite often
> >> on the list and
> >>> some are doing it every time again for
> themselves when
> >> a new release
> >>> is available.
> >>>
> >>
> >> We certainly have not done an exceptional job of
> making it
> >> possible for
> >> the community to contribute, but it does
> happen.  Take
> >> the included MPI
> >> support, for example. ;)
> >>
> >>> Are there any options, that the community
> becomes more
> >> involved?
> >>>
> >>
> >> I'm actually looking into it.
> >>
> >>>> and a pain in the ass to build :-) Of
> course I'm
> >>>> aware of the fact that the community using
> job
> >> schedulers is much to
> >>>> small
> >>>> to carry a refactoring of the code. Even
> then I'm
> >> dreaming of a ./
> >>>> configure;
> >>>> make; make install process.
> >>>>
> >>> Me too. For now many depend on the courtesy
> binaries
> >> simply because
> >>> the compile process is a little but unusual,
> when you
> >> are used to the
> >>> automake tools. Changing to automake could
> make the
> >> courtesy binaries
> >>> dispensable.
> >>>
> >>> I would assume, that the number of users is
> increasing
> >> with the number
> >>> of cores available in a single machine: we are
> also
> >> using SGE/OGE
> >>> local on the workstations to serialize the
> workflow
> >> instead of running
> >>> 10 computations or so at the same time. When
> you are
> >> used to SGE/OGE,
> >>> it's a matter of minutes to install it local.
> A big
> >> pro compared to
> >>> other schedulers is, that it can even run
> under a user
> >> account when
> >>> there is only one user on the system anyway
> and all
> >> parallel
> >>> applications are only starting threads or
> forks (i.e.
> >> no local `qrsh`)^
> >>> %. A special single machine install could make
> it
> >> attractive to new
> >>> users.
> >>>
> >>> BTW: I assume, that all SGE_* environment
> variables
> >> will be changed to
> >>> OGE_* like it happened with COD_* prefix ~10
> years
> >> ago. Seeing this,
> >>> OGE could also mean Open GridEngine.
> >>>
> >>
> >> We aren't planning to change the SGE_* to OGE_* at
> this
> >> time.  Some day
> >> down the road we might change our minds, but it's
> really
> >> not worth the
> >> trouble it would cause for us and our users.
> >>
> >> Daniel
> >>> -- Reuti
> >>>
> >>> %) Maybe this even doesn't apply any more with
> the new
> >> -builtin-
> >>> startup.
> >>>
> >>
> >> The built-in interactive/parallel job support
> actually
> >> makes it easier
> >> to do a single-user install.  Prior to the
> built-in
> >> support, the system
> >> needed root access to support interactive/parallel
> jobs
> >> properly.
> >>
> >>> Having the source available is a big plus for
> the Grid
> >> Engine. It's
> >>> even
> >>> bigger then the availability of commercial
> support.
> >> Whatever happens
> >>> to SUN,
> >>> Oracle and the Grid Engine team, there is a
> future for
> >> the project.
> >>> Every
> >>> investment into the Grid Engine like
> configuration,
> >> training,
> >>> debugging etc.
> >>> isn't lost. When the Grid Engine disappears or
> the
> >> license changes,
> >>> we take
> >>> the source and do a fork. Newer Linux distros
> braking
> >> the binary
> >>> compatibility? Systems not officially
> supported? Take
> >> the source.
> >>>
> >>> For my customers the situation looks similar.
> They buy
> >> clusters for
> >>> three to
> >>> five years. I have even a system now running
> for seven
> >> years, still
> >>> under a
> >>> Grid Engine 5.x.
> >>> The customer has the warranty that a change of
> the
> >> job
> >>> scheduler isn't needed whatever happens.
> >>>
> >>> Loosing the access to the sources would mean
> we have
> >> to change the
> >>> standard
> >>> job scheduler for our clusters. It would make
> me sad
> >> as the Grid
> >>> Engine is a
> >>> great piece of software. Currently not really
> >> replaceable with all
> >>> if its
> >>> features. Feel free to drop the courtesy
> binaries. But
> >> don't stop
> >>> the access
> >>> to the sources!
> >>>
> >>> Beat
> >>>
> >>> --
> >>>        \|/
> >>
> >>     Beat Rubischon<beat at 0x1b.ch>
> >>>      ( 0^0 )
> >>
> >>     http://www.0x1b.ch/~beat/
> >>>
> >>
> oOO--(_)--OOo---------------------------------------------------
> >>> Meine Erlebnisse, Gedanken und Traeume: http://www.0x1b.ch/blog/
> >>>
> >>>
> >>
> ------------------------------------------------------
> >>> http://gridengine.sunsource.net/ds/viewMessage.do?dsForumId=38&dsMessageId=263781
> >>>
> >>> To unsubscribe from this discussion, e-mail:
> [users-unsubscribe at gridengine.sunsource.net
> >>> ].
> >>>
> >>>
> >>
> ------------------------------------------------------
> >>> http://gridengine.sunsource.net/ds/viewMessage.do?dsForumId=38&dsMessageId=263914
> >>>
> >>> To unsubscribe from this discussion, e-mail:
> [users-unsubscribe at gridengine.sunsource.net].
> >>>
> >>
> >>
> ------------------------------------------------------
> >> http://gridengine.sunsource.net/ds/viewMessage.do?dsForumId=38&dsMessageId=263916
> >>
> >> To unsubscribe from this discussion, e-mail: [users-unsubscribe at gridengine.sunsource.net].
> >>
> >
> >
> ------------------------------------------------------
> > http://gridengine.sunsource.net/ds/viewMessage.do?dsForumId=38&dsMessageId=264086
> >
> > To unsubscribe from this discussion, e-mail: [users-unsubscribe at gridengine.sunsource.net].
> 
> ------------------------------------------------------
> http://gridengine.sunsource.net/ds/viewMessage.do?dsForumId=38&dsMessageId=265689
> 
> To unsubscribe from this discussion, e-mail: [users-unsubscribe at gridengine.sunsource.net].
>

------------------------------------------------------
http://gridengine.sunsource.net/ds/viewMessage.do?dsForumId=38&dsMessageId=265743

To unsubscribe from this discussion, e-mail: [users-unsubscribe at gridengine.sunsource.net].



More information about the gridengine-users mailing list