Re: [Condor-users] Condor on Intel Macs (OS X 10.4 Tiger)

["Matt Hope" <matthew.hope@xxxxxxxxx>]

On 6/19/07, Peter Keller <psilord@xxxxxxxxxxx> wrote:
> Hello,
>
> On Tue, Jun 19, 2007 at 09:48:34AM -0500, Ben Rogers wrote:
> > That said it'd be nice to have a universal version at some point so that we
> > don't have to advertise an additional classad to know which arch we are
> > really on.
>
> For OSes which go out of their way to perform binary compatibility,

<snip lots of useful stuff>

Note that I'm completely uninterested (except academically) in OSX/Mac

I think you guys should strongly consider providing additional
granularity on the OpSys data while keeping the existing OpSys the
same to keep compatibility

I suggest

OpSysFamily = <textual representation like Windows, MacOS, Linux
OpSysVendor = <e.g Microsoft, Apple, Sun, RedHat etc.>
OpSysMajorVersion = a simple integer
OpSysMinorVersion = a simple integer

And perhaps something like OpSysBitness (also an integer though
perhaps a nicer name)

All should be overridable by the config if needed.

Then for example a 64bit windows 2003 server would be

OpSysFamily = Windows
OpSysVendor = Microsoft
OpSysMajorVersion = 5
OpSysMinorVersion = 2
OpSysBitness = 64

This is not perfect (distinctions like server and client builds of
windows operating systems,  the nastiness of the various windows Vista
distributions, minor build numbers relevant to Linux, different kernel
versions in Linux etc.) but would allow people to start writing
submission tickets which were very resilient to upgrades of the
operating systems in the pool.

I also suggest that an option should be added to the submission
process called something like:

DisableAutomaticRequirementGeneration

Which would then add no automatic requirements at all (someone who
knows enough to use this knows how to deal with everything else).

This is back of envelope stuff so I'm sure it has holes but I really
think condor needs something like this as older OS's linger on in
cycle scavenging environments

Matt