CVS update: tng/source/passdb

[Luke Kenneth Casson Leighton]

On Mon, Jan 07, 2002 at 04:38:49PM -0800, Jeremy Allison wrote:
> On Tue, Jan 08, 2002 at 12:35:27AM +0000, Luke Kenneth Casson Leighton wrote:
> 
> >   that's not the issue.
> > 
> >   how can an ARBITRARY dce/rpc-based program - NOT a .so - one
> >   that is UTTERLY INDEPENDENT of samba, run and register
> >   itself?
> 
> Luke,
> 
> 	Please understand.
> 
> WE DON'T CARE !
 
 jeremy, if you wanted to have a reasonable conversation,
 in which i did not make statements that you consider to be
 "slagging you off" etc, you would have put this a _lot_
 better than you have.

 i take it, therefore, from your three words above, that you
 find the above kind of tone acceptable - gloves off, in other
 words.

 anyway, with that in mind, let us continue.


 i know you don't care, otherwise you would have dealt with
 this a long time ago.

 however, the fact that you do not care [about allowing
 other people and other vendors to interoperate with ncacn_np]
 is totally unacceptable, and i will explain why, below.


> Samba is not a mechanism for running arbitrary dce/rpc code.

 this blaze statement is not acceptable.  with under
 four hours work using an IDL file that, when i find the time
 i will write for you, you will _have_ a mechanism for 
 running arbitrart dce/rpc code, you damn fool.

 the fact that you keep stating this and putting blocks in
 the way leads me to become suspicious, and believe that you
 _have_ no technical justification for your statement above,
 which leads me to speculate that you may have some other
 agenda or requirements that are making you say this.

 when someone as technically competent as you starts making
 such stupid statements as this one, i start wondering what
 justifications they have for them, and what other motives.



> That's the job of the DCE codebase you've been working on,
> which, when it wants to allocate a port should just do so and
> then register with the DCE/RPC portmapper on port 135.
 
 you are misinformed, and are attempting to speak authoritatively
 on a subject that you know not enough about.
 
 please do not attempt to mislead other people or use your own
 misinformation in order to justify keeping control over samba.

 read the other messages i sent, you damn idiot.

 and you'll realise _why_ i've been going on about this.

 samba _dominates_ port 139 [and 445] and it is the ONLY accepted,
 established [and therefore effectively proprietary] project
 that provides access to ncacn_np, netbios session and LANMAN
 functionality.  [it also dominates ports 137 and 139 which
 rule out netbios datagram access by other programs, too].

 - the Win32 project can't do an implementation of the win32
 CreateNamedPipe without this API.

 - the freedce project can't offer the ncacn_np transport
 without this API, and therefore there is no point in
 proceeding with the project [you are technically inaccurate
 regarding what you think can be achieved with just tcp and
 udp in freedce: read the other email i sent, that you replied
 to martin].

 - no other vendor [for example as sun's cascade / pc-netlink]
 may provide better NT services but still using smbd's
 better filesharing capabilities without this API.


 samba is in a MONOPOLY situation on port 139 and 
 it is technically IMPRACTICAL for any other open source
 project to compete with it.



 i don't give a shit what you think open source can do,
 the fact remains that it would take ten man-years of work
 to implement an acceptable alternative to samba and you
 bloody well know that, and it's not going to happen, okay?

 and even if it did, _you_ are making it extremely difficult
 for that to happen because you insist on making a proprietary
 implementation that cannot interoperate via an acceptable
 interface, with NamedPipes as the dividing line.


 therefore it is _your_ responsibility to make it easy to
 off-load port 139 to other programs wanting to get a word
 in edgeways, otherwise _you_ are responsible for enacting
 proprietary practices equivalent to microsoft's anti-cometitive
 strategies.

 so _don't_ talk to me about "we don't care", you arrogant
 little prick: _start_ caring and just implement that blasted
 API.

 _fast_.

 lkcl