search for: redtap

On 08/06/2019 21:32, Rowland penny via samba wrote: > On 08/06/2019 16:24, Uwe Laverenz via samba wrote: >> Hi all, >> >> when you join a linux server to an active directory with "realm" it >> uses "sssd" as default. This works well as long as you just want to >> be a simple domain member. >> >> As soon as you want a real member

On 10/06/2019 16:04, vincent at cojot.name wrote: > > There is probably some amount of redtape on this but AFAIK it works > fine for me: My RHEL7.6 hypervisors are joined to my AD DC 4.10.4 VMs > through use of realm '(and thus sssd): > > Here's a RHEL7.6 client: > # realm list > ad.lasthome.solace.krynn > ? type: kerberos > ? realm-name: AD.LASTHOME.SOLACE...

...om my perspective nothing stops Google from tossing it up on github or google code and letting it stay there until all the pieces are in the correct place. Why it *must* be an llvm project now doesn't make sense to me. When the shoe was on the other foot (OpenMP) there was all sorts of shit and redtape Intel (and others) had to jump around to get it included. Google has a lot of good karma in the llvm community and maybe that's the difference..

On Wed, Jun 12, 2019 at 4:38 AM Rowland penny via samba <samba at lists.samba.org> wrote: > > On 10/06/2019 16:04, vincent at cojot.name wrote: > > > > There is probably some amount of redtape on this but AFAIK it works > > fine for me: My RHEL7.6 hypervisors are joined to my AD DC 4.10.4 VMs > > through use of realm '(and thus sssd): > > > > Here's a RHEL7.6 client: > > # realm list > > ad.lasthome.solace.krynn > > type: kerberos >...

There is probably some amount of redtape on this but AFAIK it works fine for me: My RHEL7.6 hypervisors are joined to my AD DC 4.10.4 VMs through use of realm '(and thus sssd): Here's a RHEL7.6 client: # realm list ad.lasthome.solace.krynn type: kerberos realm-name: AD.LASTHOME.SOLACE.KRYNN domain-name: ad.lasthome.so...

...tops Google from tossing it up on github or google code and letting >> it stay there until all the pieces are in the correct place. Why it >> *must* be an llvm project now doesn't make sense to me. When the shoe >> was on the other foot (OpenMP) there was all sorts of shit and redtape >> Intel (and others) had to jump around to get it included. Google has a >> lot of good karma in the llvm community and maybe that's the >> difference.. >> _______________________________________________ >> Openmp-dev mailing list >> Openmp-dev at lists.llv...

...tops Google from tossing it up on github or google code and letting >> it stay there until all the pieces are in the correct place. Why it >> *must* be an llvm project now doesn't make sense to me. When the shoe >> was on the other foot (OpenMP) there was all sorts of shit and redtape >> Intel (and others) had to jump around to get it included. Google has a >> lot of good karma in the llvm community and maybe that's the >> difference.. >> _______________________________________________ >> Openmp-dev mailing list >> Openmp-dev at lists.llv...

Ahh, I just noticed that Chandler's proposal is to put SE only into this new project, and to keep libomptarget separately, in OpenMP project. I wonder why so? Why SE (a library serving only one PPM so far) is different from libomptarget (a library also serving only one PPM so far)? Are people have opinion on this? Yours, Andrey ===== Software Engineer Intel Compiler Team On Tue, Apr 26,

Chandler, It seems that the general consensus is to save further discussions for later and go ahead with your proposal. I can add my +1 to this as well. Could you / Jason prepare a proposal on the new project, with all the usual questions covered? One interesting thing is where to put SE and libomptarget in the project's tree. I would be happy to review it from Intel / OpenMP side. Also, as