samba netbios / namedpipes domination: a comparison with linux having a proprietary web server built-in

[Luke Kenneth Casson Leighton]

On Tue, Jan 08, 2002 at 08:14:32AM -0800, Simo Sorce wrote:
> Well, I generally tend not to answer to these threads, but here my thoughts
> on a few things:
> 
> On Tue, Jan 08, 2002 at 03:25:25PM +0000, Luke Kenneth Casson Leighton wrote:
> > 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:
> 
> >  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.
> 
> how it happened that jeremy has the power to do so is totally unknown to me.
 
 yes, it is quite sad, i agree.  i have the benefit of working
 with samba closely since 1995 and so i will answer that for you.
 
 the answer is partly that the samba
 project came about through ad-hoc development.

 unlike, say, apache, and the apache software foundation, samba
 was developed out of necessity and interest, whereas the ASF
 was explicitly set up to provide and protect a community
 development environment.

 now, given that smb (and associated protocols) is quite
 specialist, there are extremely few people who understand
 it, and those people should be encouraged to develop those
 skills further, protected as valuable community resources,
 and should lead the open source community in finding people
 to work on these projects, under their direction, initiative
 and encouragement.

 now, unfortunately, jeremy and andrew are failing to provide
 suitable leadership and a suitable development environment,
 and have - and are - actively _dis_couraging people - not just
 myself - from being able to participate in samba development.

 and one of the simplest reasons for this is that they are only
 two people, and do not have enough time: the infrastructure
 under which they are operating simply cannot cope with the
 demands of such a massive project.

 and they are well aware of this, and losing ground all the time.



> > > 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.
> 
> Well, probably you do not understand what Jeremy is trying to say you:
> Samba has not been made to run dce/rps code, full stop!

that is so obviously untrue that i can only surmise that
you do not realise what you are saying, and have made a
mistake.

> It has been created as a file and print sharing tool, where MS forced then
> to add support of a little amount of dce/rpc 

them?  them?  _they_ didn't write the dce/rpc code, _i_ did!

and _i_ fully intended that code to evolve into a full dce/rpc
implementation!

> (and lately ldap) to maintain compatibility, this is the only reason why rpc made it's way into samba I think.
 
 no, you are incorrect.

 it was _Me_ that has developed the foundation for samba's dce/rpc code.

 the samba 2.0 dce/rpc code and all subsequent versions is on MY
 initiative, not theirs.

 please get your facts right, simo.

> 
> >  please do not attempt to mislead other people or use your own
> >  misinformation in order to justify keeping control over samba.
> 
> keeping control on what?
> Samba is free software you may adapt it to your needs if you want to.

oh purleeze, be a little more realistic and a little less naive.

it's bluntly obvious to me that samba is being controlled by
a small minority of people who are unsuited to and "DON'T CARE"
about moving the future of unix and linux forward, using samba
as a tool to end microsoft's anti-competitive practices.

or at least, to bridge the _yawning_ technological gap of about
two to three man-centuries of development work that microsoft
has on the unix world.


you also miss the point.

my "needs" are nothing to do with it.

my _aims_ are to provide total interoperability for windows operating
system and applications.

samba is one _small_ part of that.


> Oh, OPS, you already tried that way and you did not succeded.
 
 no, what i tried to do was to avoid a nervous breakdown.


> Now you should analyze that and stop to blame at people.

you miss the point, so please try to get your facts right
before making any assumptions or statements that i have
no idea why you are making.

i've never met you, i've only seen your name once or twice,
and i am very confused as to why you are responding on this
thread when you have no idea who i am, what i do, what i am
capable of, what i have done, what my aims are, or basically
anything.

which is a pity, because by getting yourself involved you
probably think i am some complete idiot, which is even _more_
of a pity because i've never met you _ever_, and haven't even
a chance to know if i _like_ or dislike you.

please, be more careful in future.


> the project had problems or most probably there was no interest in
> dce/rpc. 

the project is not samba, and we have no time.

additionally, there are factors that you are unaware of that
relate to US government agency manipulation, which have had
a seriously detrimental influence in my involvement with samba.

> In Free Software world things go this way, you raise interest
> or you make it your self, if both fail it means the project simply was
> not needed by you or by any other else.
> Why should the samba team be forced to change things break our code and
> put so much effort in a thing nobody really care of, for purposes that 
> are not port of the program objectives?
> 
> >  read the other messages i sent, you damn idiot.
> 
> And please keep offending words for you or write them in a private mail
> this is not the language to be used on a technical list.

really.

i will say whatever i please, for whatever effect i choose,
and i will accept the consequences.

i thank you for your advice, now will you please keep out
of harm's way because if i ever meet you, i might wish to
hold a reasonable conversation with you, and i don't want one
mistake on your part [replying inappropriately on this thread]
to cloud that.


> >  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].
> 
> samba does not dominates anything, 

you can say that as much as you wish, it doesn't write the
code that gets into a mainstream release that ends samba's
domination of ports 137, 138, 139 and 445.


> you can change it if you want, 

yes i can change it.  so what?

what good will that do a hundred thousand or a million-strong
userbase?

> stop it if you do not need it 


> and want to use dce/rpc, use what andrew and jeremy offered you (a dinamically loadable module), or even simply set up another interface and run samba on one and you dce/rpc thing on another.
> No one "dominates" anything!

if you think this, you do not understand, and should not be
posting statements that refute what i can conclude from a
[to me] simple analysis of people's statements, behaviours,
and combine that with the results of their labour.

> 
> > 
> >  - the Win32 project can't do an implementation of the win32
> >  CreateNamedPipe without this API.
> 
> If they need it they will build it.

"if you build it, he will come".

*laugh* ;)

yes, they need a NamedPipe API.

and the developer responsible for it has contacted me.

i've explained what he will need, and he went away
because he realised that it would be dependent on
too much work.

> >  - 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.
> 
> you are free to add it, no one will prohibit you to do so ... again.
 

> >  samba is in a MONOPOLY situation on port 139 and 
> >  it is technically IMPRACTICAL for any other open source
> >  project to compete with it.
> 
> No it is not impractical isimply unneded as proved by lack
> of interest and there's no monopoly (or do you call that of
> apache a monopoly over port 80 because when it is running
> it keeps the port 80 busy?, or sendmail with port 25? or any
> other server program??)

okay.  you have drawn an analogy, and that analogy is flawed,
in two ways.

the first way is:

that http and smtp are both simple, well-documented
protocols that people can provide their own implementation, from
the RFCs, in extremely short periods of time.

the result is, as proven by the number of http and smtp client
and server implementations, that lots of people write web and email
clients and servers, the world over.

perl probably has thirty or forty such implementations, _alone_.

whereas, windows nt is layered, one transport upon another,
with.  there are various well-known "breakout" points that
have allowed microsoft to develop such a strategy, which anyone
else has to follow.

technically, therefore, anyone following in their footsteps ends
up in a dominant position of strength and control, simply by
sheer volume of lines of code and technical expertise required
to understand that code.

_regardless_ of whether the code is available or _not_.

the point about reverse-engineering binaries is that it is
time-consuming.  and it is this investment of time that
leads people to conclude that binaries are "proprietary".

where the source code itself is so massive and complex that it is so
time consuming to understand or work with, i conclude that
any such implementation - regardless of whether it is available
publicly or not (remember sendmail?) - is "technically"
proprietary.

_unless_ it provides well-known and well documented interfaces
that, in the case at hand, conform to the microsoft ones and 
provide the same functionality.


the second way is:

an expansion on the fact that samba (and windows nt) provide
an implementation of a couple of transports.  these transports
are:

- netbios

- named pipes

now, i wish to make a parallel analogy for you.

if:

- the linux _kernel_ provided an implementation of a web server,
dominating port 80, making it completely pointless for anyone
to even think about _writing_ their own web server

- all linux vendors shipped the linux kernel with this
web server implementation enabled by default.

would you consider this to be acceptable?

because this is what you are saying to me, w.r.t samba running
on ports 137,138,139 and 445 (being the kernel) and stopping
anyone from implementing NamedPipes (being the internal
implementation of a web server).  and you (the linux
vendors) tell me that i may "roll my own".

what, i am supposed to implement my own linux kernel?  are
you mad???  i am supposed to implement my own web server?
what's the point???

in the above scenario, the existing one dominates it and
is in a monopoly situation, so there's no point in competing.

and of _course_ this is unacceptable.  people would be
_outraged_.

and samba (and windows NT) both do this _not just once_, but
_twice_!!!!

first on the netbios transport, and second on the
namedpipes transport.


_now_ do you understand why i am so pissed off?


> the rest is just bullshit.

ah.  i am disappointed to hear you say this.

up until now, you had kept to your own advice.

simo, if you wish people to listen to you, you must follow
your own advice.

alternatively, feel free to stoop to my level of language,
which you find so offensive to receive.

good luck,

luke