Samba Team admits to proprietary restrictive implementation practices

Posted 8 Jan 2002 at 22:18 UTC by lkcl Share This

In a stunning admission, Jeremy Allison publicly announced today that "WE DON'T CARE" [about samba's dominant and limited position in providing Windows NT interoperability].

A flare-up of tempers and abberant behaviour, by all parties old and new, is reminiscent of the SAMBA / Samba-TNG breakup, over two years ago.

The technical capabilities and breadth of Windows NT and Windows 2000, developed by Microsoft, is stunning. The level of technical expertise required to interoperate with Windows NT at a network level is measured in hundreds of years of work and research to reproduce, and it is this that Microsoft is counting on, in combination with their anti-competitive practices [known as proprietary implementation and information], to protect their massive investment of time, effort and money.

Samba's developers have therefore decided to focus on a subset of and even that - with twenty man-years of development behind it - is way beyond their management and development capabilities, and way beyond most people's ability to implement or believe that the estiamount of work involved is correct, or that this is even a significant problem. Worse yet - even worse than Microsoft's anti-competitive practices, they have decided to not allow other Open Source or any other third party developers any means to access the [Microsoft-designed] transports that are embeddded in amongst the 350 thousand of lines of code that make up Samba.

Worse yet, they fail to appreciate the full significance of their decision. Through sheer volume of lines of code, monolithic architecture design, lack of time, resources, developers with the brutally demanding level of expertise required and attitude to cope with the scale of the issues they face, the Samba Team's implementation locks out the ability to fully develop an Open Source or other third party compatible Microsoft Exchange alternative client and server, as well as a compatible MSSQL client / server alternative, a full DCOM alternative, alternative Windows NT / Windows 2000 compatible clients and servers, stops the Wine Team from developing fully network-capable versions of approximately two hundred well-known important Win32 APIs (such as the Windows Registry API) - the list goes on.

Luke Kenneth Casson Leighton compares their attitude to Samba's dominance of the TCP/IP ports involved as similar to the Linux Kernel having a built-in web server that cannot be switched off and will not allow you to run Apache or any other web server.

By adding and appropriately implementing a simple NamedPipe emulation API in a dynamically loadable module as a "breakout" point to alternative implementations, their technically dominant position as the only practical Windows NT Interoperable alternative can be ended, and the process of catching up with fifteen physical years of Microsoft Technological lead can be accelerated to more acceptable levels.

NOTE: people wishing to post regarding the content of this article may wish to read the Samba TNG Architecture document first.


So, why not fork?, posted 8 Jan 2002 at 22:42 UTC by clausen » (Master)

You haven't explained why you can't just fork, if you don't like their architecture. Is samba-tng such a fork, and if so, why isn't it acceptable/successful? I can't see how they have any power, other than people trust their version of samba more than some unknown version.

Rubbish, posted 8 Jan 2002 at 22:54 UTC by djm » (Master)

I would expect someone from [large monopolistic software vendor] to resort to quoting someone so utterly out of context, but not someone from the free software community.

Your issue is with the direction and management direction of the Samba project, as decided by the leaders of that project. I have watched your diary entries spew vitriol at them for the last year. If I was them I would have killfiled you ages ago.

They are not being "proprietary" or "anti-competitive". They are not denying access to transports. Their code is free. If you call "monopolising TCP port 139" anti-competitive, you are utterly deluded.

If you don't like their direction, you should go and start/work on your own project. They have earned their place at the helm of their project, you should earn yours too.

fork or not to fork., posted 8 Jan 2002 at 23:03 UTC by lkcl » (Master)

in the discussions outlined in the samba technical archives, you will find an explanation as to what has happened with respect to the fork, known as Samba TNG. there _are_ people using it. [hang on: i think that was a private reply i sent to someone so it's not on the lists].

okay. the amount of maintenance required to keep current with a fork is drastically beyond even an experienced samba developer such as myself to deal with on a _full-time_ basis, let alone a part-time one.

that's reason number one.

second: your reason "people trust.... unknown one" has more weight and impact than you yourself might associate with it, and is an extremely large deterrant, in combination with above-average maintenance / fork-following.

third: despite having approached a number of companies, no significant funding of samba tng development has been offered. given that i am the person _responsible_ for samba's NT-domain capabilities [at a time when i was single and with a very low financial and personal committment level], i find this perplexing.

fourth: as described above, my level of financial and personal committments mean that i am in absolutely _no_ position to spend any so-called "free" time on samba tng development. i shouldn't even be spending the time to write this.

thanks for your question.

read more carefully, posted 8 Jan 2002 at 23:59 UTC by lkcl » (Master)

djm,

please read the references more carefully. i think that, once you get over the shock of someone with six years experience of hard-core research and development of open source suggesting that open source can be proprietary despite being publicly available, you'll begin to realise quite how serious this matter is.

i refer you to a posting [if i can find the damn thing] on samba technical archives which it itself a summary of comments made in other posts, in response to someone who was as equally shocked and believed my analysist to be just as absurd as you believe.

here.

i also refer you to the part of another posting which i believe will help you understand the issues i describe. read around the area where this fragment occurs:

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.

now, i will give you an example demonstration that will help you to appreciate exactly how much work is needed, involved, and why my assessement is not quite so outrageous as you make out.

i will give you one week and all the documentation that i have to complete a simple assignment.

your assignment is to, from the publicly available source code that you say is there, to modify the NTLMSSP implementation in the hard-coded DCE/RPC subsystem in samba and samba tng, to add NTLMv2 48-bit and 128-bit signing and sealing.

actually, NTLMv2 authentication in samba-tng (client ntlmv2 = yes; server ntlmv2 = yes) is already there, but the NTLMSSP dce/rpc subsystem doesn't successfully use it to do NTLMSSP-NTLMv2 signing / sealing. however, NTLMv1 authentication _does_ work, and so does NTLMSSP successfully do NTLMv1 signing and sealing.

so you stand a good chance of success: i will be available to answer any questions you might have.

heck, let's call it a month. i'll give you one month. no, make it 31 days, because we're coming into february, with less days.

Regardless of the issues..., posted 9 Jan 2002 at 00:51 UTC by zak » (Observer)

This event happens often enough on the PHP dev lists that I have strong feelings about this type of event.

I don't have time to carefully track through the various assertions made here - your perception of the situation may or may not jive with my interpretation of reality. :)

Most Open Source projects (IMHE) have this sort of event happen - developer x feels that developer y is doing something wrong, and singlehandedly initiates an FUD/DOS-like attack against them that consists of public and private messages, inflammatory public articles and general community poisoning.

In Open Source, those who share and co-operate best win. This type of activity polarizes and divides the community - those with opinions on the matter tend to cling to them more tightly, while others leave to escape the noise.

sorry to say it, but this is crazy, posted 9 Jan 2002 at 01:32 UTC by mbp » (Master)

Here is a much more reasonable description.

Luke criticizes Andrew because

> he didn't want to accept technically "inferior"
> solutions or "inferior" code.
...
> if andrew had not raised the technical bar higher and
> higher and higher in order to, ultimately, block TNG code from
> going mainstream, then i would be in a much more stable financial
> situation than i am now.

I cannot begin to understand why Luke thinks Samba ought to accept code that everybody accepts is inferior, just to benefit Luke personally. Saying that it has a better architecture is no excuse for not actually compiling.

jra is completely within his rights in saying that he doesn't care about merging broken and insecure code.

If Luke's code is better, then he's perfectly free to run his own project and let users decide which one they prefer. At the moment, strangely enough, they seem to be voting in favour of compilable code and emotionally mature leadership.

It was quiet for a while, posted 9 Jan 2002 at 02:58 UTC by Zaitcev » (Master)

What happened to this?

i am now working as a building labourer, for 12 hours a day, and have no time to spend doing open source software.

Just step away from Samba, then., posted 9 Jan 2002 at 04:01 UTC by logic » (Journeyer)

Am I the only one thinking that perhaps none of you ought to be working together? From reading the mailing list postings on this particular subject, I can't really decipher who is "right" here. The reality is, you're all wrong (for each other). lkcl, your posts appear full of vitrol (as someone else mentioned), and noone on the list appears to be listening to your points (whether they are well-reasoned or not is really quite irrelevant, they're just being ignored). Perhaps it's time that you stepped away from the whole thing, because you're obviously not getting anywhere.

<div mode="rant">

Something out of this whole thing that I do resent, as a casual open source developer, is your demand that you be able to make a living off of this stuff. You repeatedly state that you're on hard times (while, apparently, others who have worked beside you are not), and that you have no means to continue to contribute (unless someone pays you to). You go on in these and several other postings about the fabulous opportunity everyone has missed out on by ignoring your immense talents.

You know what? I'm out of a job right now because the market downturn hit my last employer and they were forced to make a few rounds of layoffs. I happen to think I'm pretty skilled at what I do. I also don't think it's anyone's fault (certainly not my prior employers', or any particular group I've worked with in the past), I don't think I need to broadcast my qualifications (as I believe my work speaks for itself, good or bad), and I certainly don't believe that my open source hobby owes me the right to a living (you chose to code under a particular license, and this is a very possible outcome of that choice). I haven't lambasted previous co-workers or employees who are receiving a paycheck while I'm searching for work. I haven't gone on and on about how much of a living I'm owed because (in your own words) "there are _very_ few people in this world who are capable of doing what i can". Not getting by on what you're doing right now? Not enough time to work on the projects you enjoy? Tough. Life sucks sometimes. Deal with it.

</div>

My honest and humble suggestion: continue working on your forks (samba-tng, freedce, etc) as time permits. No time? I feel for you, but that's how it goes sometimes. Don't lash out at people who do have the time and means to do so; learn from them. Perhaps, despite the "golden opportunity" they've missed out on, they know something you don't.

Deary me., posted 9 Jan 2002 at 07:23 UTC by robk » (Journeyer)

Luke, it's really time to give this up. Really.

Using advogato as a medium to propogate your bitterness is just not on. It's been tolerable for a while, but this is just going beyond funny.

Here's another clue: You're not the only person in the open-source community doing it tough financially. Heck, you're not the only person in the greater IT community in that situation.

Frankly, your performance here and in other public forums has been becoming progressively more unprofessional for some time. It's now just become embarrasing, and that can't be helping your career prospects

Hmmm. This has become more flamish than I intended, but I'm going to let it stand as it is. I'm tired of seeing friends whose work and ethics I respect and admire be slandered.

Pax, mate.

Rob K

personal, posted 9 Jan 2002 at 09:29 UTC by lkcl » (Master)

I cannot begin to understand why Luke thinks Samba ought to accept code that everybody accepts is inferior, just to benefit Luke personally. Saying that it has a better architecture is no excuse for not actually compiling.
hi there,

1) i was _just_ thinking that i should mention that this is not about me, personally.

it's about leveraging a million-strong install base piece of software as a tool to reach millions of people who have no option but to use an operating system developed by a company most well-known for its anti-competitive business practices [microsoft].

2) it's not "everyone"

3) the only circumstances under which i do non-compiling code is when i am using ten-year-old out-of-date hardware that takes 90 minutes to do a full build when everyone else is using hardware that takes 30 seconds; i commit as a backup mechanism to an off-site remote location over a very slow modem or am having to copy patches by floppy disk and carry them 20 minutes down to a computer with internet access; and this was a situtation that i was in approximately five years ago, and it hasn't been the case since.

purleeze, you think i can't type "make" or something?

thanks for reality check, posted 9 Jan 2002 at 09:41 UTC by lkcl » (Master)

hiya robk,

i'm not sure what to say.

think about this. i realise what you are saying. i've been aware of the consequences of what i say, and how it is said, on myself. and you know what?

i accept the consequences.

now, with that in mind, do you think that i would go on about this issue, given that the consequences for my own career, reputation and standing are, as you say, to be so drastically adversely affected, if i didn't think that this issue was really, really important, for millions of people, world-wide?

to give you a clue here: microsoft's default security / authentication, as used at present and for the last fifteen to twenty years is based entirely on DES.

that means that all passwords can - and probably have - and all user password changes, and all administrator account updating (including changing, synchronising or adding user passwords), be decrypted to plaintext.

_for the last fifteen years_.

quiet for a while, posted 9 Jan 2002 at 09:48 UTC by lkcl » (Master)

hi there zaitcev,

well, the work at the site is going well, the gas board are coming to install the meter tomorrow, the central heating people the day after to get the boiler certified as safe. be done in about another three weeks.

*grin*

Stop, posted 9 Jan 2002 at 14:48 UTC by rasmus » (Master)

A bit of friendly advice Luke. You are not helping your situation with postings like this. Regardless of what the facts may be, you come across as somewhat insane, very bitter developer who doesn't have the emotional maturity to accept the fact that someone has made the decision not to include your code in their project.

advice, posted 9 Jan 2002 at 17:58 UTC by lkcl » (Master)

hiya rasmus,

good to hear you're still around. the point of the article is for people to take note and realise the quite consequences of the samba team's "WE DON'T CARE" decision.

you're absolutely right: it's not the point of the article for me to have another bitching session - or for anyone else to, either, i have better things to do [but they do drive me up the wall :)].

all best,

lukes

Loss of perspective?, posted 10 Jan 2002 at 00:20 UTC by neil » (Master)

lckl: quoting from your user page:

Things I Want To See Happen: "NT Domains for Unix". "MSDN for Unix". "Exchange for Unix"

You've made it your goal to mimic proprietary systems, and you get surprised when the result acts proprietary? Why?

Seems to me there wouldn't be a problem if you stuck to documented, community-supported standards, or creating such standards where they don't exist yet.

Hundreds of man years, posted 10 Jan 2002 at 01:16 UTC by graydon » (Master)

Many "hundreds of man years" have come and gone. Gone into wasted projects, silly over-engineered designs for programs which are long since dead. A good software system, like a good legal system, is one in which the code is something people can actually understand. The results of not-understanding within a formal system, projected over time, are invariably suboptimal, and often disasterous.

If you are finding this much difficulty in the emulation of microsoft's cover-fire protocols, I suggest stepping back and considering whether you expect, in all honesty, that anyone will be using this giant rats nest in another 15 years. And if not, just let it die. An incomplete "coexistence" solution is enough to solve many problems, and in the meantime other people are providing more compelling, better, easier to understand server systems out in the open, addressing many of the same problems, but with different solutions.

things i want to see happen, posted 11 Jan 2002 at 10:55 UTC by lkcl » (Master)

neil, thanks for your comments.

two things. you have the right conclusion in the first part of your comments, but for the wrong reasons. the level of complexity [necessary complexity to provide decent features!] as pointed out in the halloween documents, which are a _severe_ under statement, is the reason why these proprietary protocols remain proprietary.

the samba team, whose goals coincided with mine for some time, have _attempted_ to open things up a little, however they are failing in some key areas that i hope will be corrected soon.

so, whilst your logic is a little off-key, you have the right idea.

regarding your second point: using "open standards". well, i'm sorry to have to inform you that there _are_ no decent open standards and _definitely_ no open implementations that achieve anything _like_ the capabilities of the technology that microsoft has come up with.

now, you don't have to _like_ these cold facts, but i _will_ make sure that you are aware of them.

most linux / OSOS (open source operating system :) users are quite content with what they have, and with what they are using. and they have _no clue_ as to what the rest of the "real world" is suffering with and putting up with, because they themselves have the technical capability to say "i don't have to put up with anything i don't want to put up with", and consequently they have the _capability_ to ditch microsoft crap and go for something that they can live and work with.

so, such people are living in a small, insular world, and are simply not aware of some of the enormous technological benefits of some of microsoft's work.

and they'd prefer it if it _stayed_ that way!!!

hundreds of man-years, posted 11 Jan 2002 at 11:13 UTC by lkcl » (Master)

graydon,

thanks for pointing out a list of projects that people can focus on that, if they do, they will be able to give linux and OS users an alternative.

i hope that such projects will also integrate with windows [using APR framework, for example, to provide server-side portability].

i sincerely hope that such projects will all _not_ leave windows users in the lurch.

windows is 95% of the desktop market.

regarding man-century development: personally, i have no problem with that. if anyone wants to fund me full-time, i will slash that time down to man-years - because i can.

you have, in me, a resource capable of finding patterns where no-one else would even dream of looking.

so, for people like me, man-century catch-up development time is not a problem.

_without_ people like me, it most definitely is.

and i believe that microsoft's key people - of whom there were only seven - who developed Windows NT 3.1 / 3.5 - were of this kind of ilke.

i worked out what their coding rate was, a while back: it was something like 200,000 lines of code _each_ per year. that resulted in... oh, what was it... 6 million lines of code between them over four and a half years.

[and the technology they developed was _stunning_. oh, and based on VAX/VMS security model, of course, for which DEC went "oi!", paid $50million and a pledge to make NT available for the DEC Alpha... which they later reneged on, of course.]

now, it's _really_ difficult to find such high quality people capable of doing such accelerated development - development that is at least _one_ order of magnitude better and more capable than anything else most people would be able to do.

and even if you _do_ have such people, they are only a small fraction - a small voice. if you put them in a large crowd (e.g. 1,400 other Windows 2000 developers), their voices get lost. they get bored, they get frustrated, they get pissed off, they're millionaires by now, they _don't_ have to take such utter shit, and they retire.

so, as a result, Windows 2000 and Windows XP have lost their key people. MAPI has lost its key people. Microsoft can't _find the people the people they need of a high enough standard to maintain this code. and even if they do, such people are lost in the noise.

consequently, we can expect to see a drastic drop in the reliability of Windows XP.

additionally, it means that i believe that your estimate of 15 years for these "proprietary" protocols to die is simply _not going to happen_.

but what that doesn't mean is that we have more time in which to sit on our arses and let windows users suffer the consequences of microsoft's lack of foresight.

technical challenge, posted 11 Jan 2002 at 12:54 UTC by lkcl » (Master)

djm, i still haven't heard from you.

tell you what: i'll be _really_ generous and make it three months.

... additionally, you should be aware that the work on which they have "earned their position" - is about 25% to 30% Copyright ME, with failures to acknowledge or credit that very commonplace. most of the really _useful_ architectural decisions they make are MINE

oh, and by the way, please don't take any of this personally. you just happened to be the one brave enough to make some comments that it's good for people to say, otherwise they go away thinking that they're factually correct, when they're not...

[p.s. if you spot anything that i say that's not factually correct, or you disagree with it, please _say_ so, and why!!!]

enormous technological benefits, posted 12 Jan 2002 at 01:51 UTC by neil » (Master)

lkcl: If there are identifiable technological benefits to Microsoft protocols and servers, list them, distill them out from the "cover fire" (I'm growing to like that term) complexity that Microsoft throws in, and make a new standard based on them!

You've made it clear that you believe Samba is something that takes a great deal of effort to develop, maintain, and extend. There's no way that implementing a fresh client and server (probably based on existing free code) could take more effort. And if the new code were based on old code, you'd get the benefit of having an already existing community of developers familar with the code!

What am I missing? Or, rather, what is the free world missing that MS has, in your view?

Linux platform strategic focus coordination, posted 12 Jan 2002 at 02:51 UTC by mstarch » (Journeyer)

I have followed this discussion with some interest. I have read the threads concerning these latest issues but do not otherwise have any technical knowledge of the details of the HEAD / TNG / DCE/RPC implementations. What I have distilled from the samba threads, and my general knowledge of RPC programming is the following;

1) Samba being one of the early Linux RPC projects does not use a generic RPC server as back-end. 2) Samba implements at least one of the transports on which a general RPC framework depends (named pipes). 3) Samba uses the standardized named pipes port (139 is that correct?). 4) A complete RPC system for Linux would require support for named pipes.

Now, to make myself clear I do not want to pretend that I have any sufficient precise technical knowledge of the exact implementation details of the samba support for named pipes, but as I gather it, it seems to me that one of the primary technical/strategical overall questions posed is whether linux should have a more general interface to the named pipes transport than what smb provides, and more generally, whether linux should ship with a standardized DCE/RPC server mechanism allowing for use of standard RPC client applications on the platform.

As I understand it, it has been suggested by the samba team to provide a glue library that allows arbitrary loadable modules to utilize this transport (and possibly others, but I focus on the named pipes transport here because of lacking technical knowledge, and to keep to the point). This solution seems a bit inadequate in a general framework, because named pipes conceptually has as little to do with smb than what tcp has to do with apache.

I'm not the person to evaluate whether lkcl's estimations of the required work to implement these complex layered protocols is correct, and with the existance of freedce at least some of the work has been done already, but I think the estimation question is irrelevant compared to the more basic question whether linux would be better off with a generalized support for the rpc framework provided by the DCE standard. If this is the case, then the question immediately becomes one of open source community cooperation / coordination.

IMO djm's and others oppinion that other implementations are free to use port 139 + others is naive at best. Samba is a de-facto standard on linux systems. Samba does it's work well, and it has required considerable amounts of work which would be futile and counterproductive to reproduce.

No average user would be interested or willing to uninstall samba to use other services that used a general RPC framework, so therefore I think lkcl's statement that Samba dominates port 139 (and others) is justified.

Something about the modularization of samba seems wrong, since services like named pipes which are so obviously not connected to one specific user of the transport, namely samba, are implemented inside it.

If based on techical merits, a general RPC framework compatible with the DCE standard, is deemed right for Linux (and personally I think it would make a world of difference for Linux), it becomes a challenge for the general open source community, and not only the samba team, to deal with the technical problems involved, in order to make that goal happen.

It has been objected that DCE/RPC is a cover-fire (Joel Spolsky is really in focus these days? :-)) approach from Microsofts side to stiffle competition and draw resources, but firstly, DCE/RPC also has an open source background which should fuse some enthusiasm, secondly, maybe, just maybe Microsoft have some extremely good developers that did something right for a change, and thirdly, wouldn't complete/almost complete windows server application interoperability be a really good thing for Linux?

Finally, let me say that I don't want to look like some smart-ass that joins the discussion having all the right answers to extremely techical questions of which I can't possibly know any or all of the answers, but instead I think that the inter-project coordination/administration issues between different open source projects raised in this discussion should seem of some great relevance to many open source developers.

Finally finally, let me also say that on the one side I agree that Advogato is not the right forum for discussing technical merits of possible project specific implementatation proposals, but on the other side, I DO find the discussion about overall strategic focus for the linux platform extremely relevant.

statements outlining dependencies SMB/DCERPC/NamedPipes/Samba/Linux, posted 12 Jan 2002 at 12:21 UTC by lkcl » (Master)

1) Samba being one of the early Linux RPC projects does not use a generic RPC server as back-end.

correct.

2) Samba implements at least one of the transports on which a general RPC framework depends (named pipes).

a general NT-compatible DCE/RPC framework, yes.

3) Samba uses the standardized named pipes port (139 is that correct?).

named pipes are a tiny but very significant part of what is implemented over the SMB ports 139 [and now 445, a la CIFS over TCP], yes.

4) A complete RPC system for Linux would require support for named pipes.

a complete and useful NT-compatible DCE/RPC systemfor Linux would require support for NT NamedPipes, yes.

finally!, posted 12 Jan 2002 at 12:28 UTC by lkcl » (Master)

hi there mr mstarch,

well at _last_ - someone whom i've never heard of before in my life has the balls to say something that is in agreement with me [a sensationalist that likes to kick up a fuss], and says it succinctly and in a way that doesn't drive people up the wall.

... you wouldn't _happen_ to want to write that reply of yours up as a separate article, would you? :) [no, never mind, save it for later. if the samba team actually address the issues you raise then it will be such an important landmark for open source that i will write up another article praising their decision to take that direction].

"cover fire" :), posted 12 Jan 2002 at 13:02 UTC by lkcl » (Master)

lkcl: If there are identifiable technological benefits to Microsoft protocols and servers, list them, distill them out from the "cover fire" (I'm growing to like that term) complexity that Microsoft throws in, and make a new standard based on them!

You've made it clear that you believe Samba is something that takes a great deal of effort to develop, maintain, and extend. There's no way that implementing a fresh client and server (probably based on existing free code) could take more effort. And if the new code were based on old code, you'd get the benefit of having an already existing community of developers familar with the code!

What am I missing? Or, rather, what is the free world missing that MS has, in your view?

hi there neil, i'll answer your points in order - i like them. but before i do that, i'd like to point out that the list of projects on dcerpc.net is pretty much what's needed to be implemented, and microsoft's dominant position will have a strong contender.

yes, you're right about the "cover fire" thing: i really like it too. the bit about "just keep coding, keep correcting, you'll get there eventually" is very good advice. the only thing i _would_ say is that microsoft's thousands of developers may _appear_ to be "cover fire" when in fact it's a mish-mash chaotic development effort with not _that_ much direction to it, and out of that chaos [microsoft _is_ a mini open source community, btw] comes a lot of good stuff.

so. microsoft has a load of good stuff, and it _looks_ like "cover fire" when you have to compete against that kind of highly successful development environment.

fortunately, we have the advantage that this "battle" has already taken place: it's history, it's in the past. and all we have to do is identify the successes and implement them.

and that's what's outlined in the TNG arch document's introduction., and also listed on dcerpc.net

"there's no way that implementing a new SMB client / server would take more effort".

this is correct, however it's still a hell of a lot of work! five years ago, SCO implemented VisionFS in 4.5 man-years *with access to samba source code*! three years ago, Sun purchased NT source code (AFPS, 3million LOC) from AT & T and took *two years* to port that to Solaris. witness, "PC-Netlink", launched in red dwarf style last year. Novell's attempt, years too late, to enter the SMB market, have floundered after five man-years of effort.

i started "cliffs", which after cut/paste of large amounts of code, had a auto-generated SMB client/server parsing code, directly from the SMB specification. it's _still_ nowhere near useable, i lack the filesystem experience and time to correct that lack of experience. but it _does_ give you a file listing and read / write capabilities.

" What am I missing? Or, rather, what is the free world missing that MS has, in your view? "

basically, what the free world is missing is, in no particular order:

- the will to overcome fear of reprisals from microsoft by taking them on in an appropriate way [see advice in advo-article, "how to reverse engineer and still be legal"]

- protection from potential reprisals from microsoft in the form of government support, off-shore company status [ownership of intellectual property by the off-shore company], being "david vs goliath" is a _really_ strong position when faced with PR "FUD" by m$.

- time and money.

- a focus for that time and money.

- a suitable developer focus and forum for the required projects (i set up dcerpc.net for this purpose), along with a charter that encourages participation and protects the projects from detrimental influences.

- a clear outline of what projects are needed. those projects listed on the dcerpc.net site are pretty much what's needed.

yeah, that's pretty much it.

mstarch, posted 12 Jan 2002 at 15:10 UTC by mbp » (Master)

(Disclaimer: I wasn't there for all of the discussion, but this is my impression from a fair amount of contact with the people and code involved.)

If users would like to run other services that need to share port 139 and interact with Samba, then I really expect the Samba architects would like to help them do that by arranging a reasonable interface for doing so. Samba has plenty of plug-in interfaces already (NSS, PAM, VFS, ...) and the system is becoming more modular in every iteration. I certainly can't see any intention of monopolizing port 139, and on the contrary a real commitment to providing MS-Unix interoperability wherever useful.

The enormous problem with this article is that Luke is intentionally conflating "the Samba team won't accept my patch" with "Samba is never going to get this functionality."

Common sense suggests that to get a patch in to an open source project, it ought to (1) be reasonably minimal, (2) be clearly and patiently explained, (3) have a specific and worthwhile purpose, and (4) not break anything.

If Luke's changes have been rejected by maintainers who generally seem like reasonable and competent people, then personally I'm going to suspect that it was because it failed several of these criteria, rather than the involvement of the CIA.

I guess people who are interested should look around and draw their own conclusions, but it looks like the changes Luke wanted to make were really very large, and often resulted in Samba breaking. (Luke keeps citing rand(1000000) lines of code as evidence of how studly he is, but from a maintainer's point of view massive changes are not so good for a product people count on for daily work.)

The *very reason why* distributions overwhelmingly ship Samba is that the maintainers have earned a reputation for making these editorial decisions well.

It's not even absolutely obvious that these changes have an important purpose: plenty of people are happy with Samba as a file/print/authentication service, and would rather it did that well than morphed into a general-purpose DCERPC server. I don't see many programmers queueing up to write those services.

Leaving aside all technical considerations, I suspect Luke's approach of "persuading people by insulting them" makes the point entirely moot. If you can't (or can't be bothered) to provide a reasoned explanation for a change, then it's just not going to be accepted. If people question it and you flame them rather than trying to be patient and explain it more clearly or listen to their criticism, you might as well not bother.

This isn't meant to be a flame. I can believe that Luke's way of communicating makes it hard for him to get his point across and understand people's objections. But in the end I think the maintainers are doing their jobs well and responsibly.

Please, Luke, just get on with your life. There is zero chance of persuading jra or tridge at this point. Don't get upset about it.

RPC, posted 12 Jan 2002 at 21:21 UTC by grant » (Journeyer)

what is more useful about DCE than the current xml-based distributed messaging projects and protocols? (xml-rpc, xpc, BXXP, Jabber, Torino)

I'm interested in knowing reasons for using or contributing to a DCE/RPC implementation. I have a (likely unfounded) impression of unnecessary complexity, a la CORBA, but I've not spent any time with DCE except in developed architectures where I had no need to actually investigate or understand it.

I find it interesting that DCE used to be "open" and we're presently in the midst of way too many alternative s. Not that differentiation isn't a good thing, but eventually one needs to be able to make sense of all the options in order to choose one (or more) for specific tasks.

For example, why does KDE use DCOP? As far as I understand it, XML-RPC bindings for KDE apps are piggy-backed on DCOP.

So, back to the question of why DCE has an architecture more promising than others... security? Ok, maybe - but isn't it better to keep security options decoupled enough so that they can be rewired during implementation? (when making use of the RPC system) Perhaps it's necessary to integrate security, but by itself I don't see security as making or breaking an RPC design.

Apparently DCE is very abstract, having resulted in so many subordinate protocols - that's a feature I'd label as important enough to differentiate DCE from alternatives.

Other features or design paradigms that make the design of DCE so noteworthy that Luke has been saying the same thing for over a year? (since I've been listening) I find that honorable so long as the reasons behind it are, but I struggle to put my finger on those reasons.

Certainly I'm ignorant of the issues involved... which is why I'm asking : it's necessary to convince developers in other disciplines in order to change the current state of perception. With enough recognition DCE could become free again through appropriately licensed implementations, and be used in many projects, including Samba. It sounds as though Samba has bastardized DCE instead of decoupling it - is that correct?

irrational rejection, posted 13 Jan 2002 at 10:12 UTC by lkcl » (Master)

i'm going to regret mentioning this, martin. so i'm going to be careful how i say it. i'm going to leave out a whole load of stuff, however first i'd like to say that almost everything in your reply is relevant, and extremely well thought out.

If Luke's changes have been rejected by maintainers who generally seem like reasonable and competent people, then personally I'm going to suspect that it was because it failed several of these criteria

let me give you an example. it was very sad to watch andrew's behaviour get more and more "pavlovian". and as you rightly say, i am not exactly the easiest person to get on with, for being above-average intelligence and below-average social skills.

as i've mentioned before, ultimately it didn't _matter_ what i said. i could describe to andrew someone _else's_ idea, and he would reject it outright, in anger. what is even sadder is that he doesn't realise that that's what he was doing, and doesn't want to acknowledge that he had a problem with me.

specific example. tim potter, with my design assistance and advice on how the msrpc library code i wrote worked, wrote winbindd. he needed a protected unix domain socket client / server architecture. i mentioned to him and to andrew that there was some code already in TNG that could be used, i explained to andrew that it needed review for security issues, me not being a unix specialist. andrew rejected that code on the basis that "it had security issues".

so what did tim do?

he cut/paste that code, removed all of the generic function arguments making it useful and shareable between the two client/server applications, put it in front of andrew who promptly reviewed it and said, "it's got security issues here, here and here, and here's how to fix them", and approved it.

i mean, if _that_ isn't petty behaviour on the part of a project maintainer, i _really_ don't know what is. and this was back in _april 1999_. this was even before the _really_ seriously heavy shit started hitting the fan. this was when i'd only been working for linuxcare for about six weeks, when we were still in 24 marcus clarke street, martin! there was _absolutely_ no excuse for this, and no technical justification whatso_ever_.

the moral of the story is, read my reply to article 405, above, about minimising the impact of project maintainers making decisions based on non-technical grounds.

time for clear and patient explanations, posted 13 Jan 2002 at 10:22 UTC by lkcl » (Master)

that's one of the other sad things. as the designer and maintainer of 100,000 lines of DCE/RPC code and services written over a three-year period, the amount of time involved in explaining those services and the design and architecture just simply took _too_ long.

andrew therefore simply couldn't cope with the amount of work involved, and was quite clearly not prepared to:

a) take it on trust that i knew what i was talking about.

b) accept that something that would take one to two years to explain every single detail and line of code could be _quite_ as necessary as i was making out.

c) take a risk with samba and cut across to that code on the basis of "this is an open source project, if it breaks, there are plenty of people out there prepared to help fix it".

d) add in an appropriate architecture (at the NamedPipe juncture) that would allow slow migration of code on a per-module, per-server (of which there are about ten to twelve) basis.

so, in short, to mitigate such risks in any project, not just open source, it is _necessary_ to have all parties involved review code and keep track of each other's work - something that simply _didn't_ happen in samba (jeremy on 2.0.x tree; andrew doing his pHD) and _still_ isn't happening in the samba project, today [6 developers all working on their own, with minimal code review, afaik]

it is _necessary_ to subdivide the project such that individual components with fixed APIs may be upgraded on a case-by-case basis, allowing users and developers to fall back to more stable versions of such individual components.

what is DCE/RPC, posted 13 Jan 2002 at 10:59 UTC by lkcl » (Master)

DCE/RPC provides a means to use c-based interfaces between client and server applications [as if the client and server were in fact the same application, not on an artibrary network, at all.]

those interfaces may be extended (added to) through versioning and also inheritance, making DCE/RPC suitable for adding "Object-orientated" wrappers on top of it, like DCOM.

DCE/RPC is _not_ in itself an object-orientated system like DCOM or CORBA. DCE/RPC is more similar to the RPC mechanism underneath CORBA.

DCE/RPC's design is modular in practically every way imagineable, where all aspects may be negotiated at runtime. security (default is none), data formats (default is NDR), transports (anything available or even _what_ever is available), server to use (yes, there's a means to provide distributed server access, hence the D in DCE :) :) - interface to use (plus which version).

DCE/RPC is suitable for use when you need the speed and portability of c and can put up with c's awkwardness.

for example, DCE/DFS is a distributed filesystem.

IBM ran the 1996 olympics web farm over DCE/DFS. they used it as the back-end file server for the [off-line and real-time] video streaming and web pages, had multiple distributed servers in each major country, and had a team of people standing by to push content in different locations, updating the web pages etc.

DCE/DFS handled the demands placed on it by multiple web servers and the web masters without a single [known!!!!] hitch.

_now_ you know why microsoft was so fascinated with getting DCE/RPC into Windows NT: it's some serious heavy-duty code.

to answer the other parts:

I find it interesting that DCE used to be "open" and we're presently in the midst of way too many alternative s. Not that differentiation isn't a good thing, but eventually one needs to be able to make sense of all the options in order to choose one (or more) for specific tasks.

well, firstly, DCE 1.1 is now known as FreeDCE, and it can be downloaded from dcerpc.net's cvs repository. it's the original "Reference Implementation", gnu autoconf'd, lots of minor enhancements that make it possible to compile NT MIDL files a la NT domains services. a bit more to do to get it DCOM useable. though.

secondly, you are absolutely right. if DCE/RPC had been made more "open" even two years earlier, around the time when Olivetti Labs released their 250,000 lines of CORBA GPL code, things would have been a _totally_ different story. there would have _been_ an open source, _working and implemented_ DCE/RPC system available.

as it is, we have a situation in which, afaict, inferior RPC mechanisms are being developed by people lacking the experience, skills, time and money to produce something even _remotely_ approaching the capabilities of DCE/RPC, and it's quite disappointing for me to watch this happen, but also quite exciting, as they end up being available on more computing languages (is this a good thing?) than just c.

For example, why does KDE use DCOP? As far as I understand it, XML-RPC bindings for KDE apps are piggy-backed on DCOP.

i don't know. XML-RPC is _severely_ limited. it's about one hundredth of the code and capabilities of DCE/RPC.

So, back to the question of why DCE has an architecture more promising than others... security?
nope! DCE/RPC can be used to negotiate any modular security mechanism you care to plug in that your client/server apps wish to use.
Ok, maybe - but isn't it better to keep security options decoupled enough so that they can be rewired during implementation?
that's exactly what DCE/RPC has done.
Apparently DCE is very abstract, having resulted in so many subordinate protocols - that's a feature I'd label as important enough to differentiate DCE from alternatives.
yes it is, and so would i.

Other features or design paradigms that make the design of DCE so noteworthy that Luke has been saying the same thing for over a year? (since I've been listening) I find that honorable so long as the reasons behind it are, but I struggle to put my finger on those reasons.
:) it basically has the capability to do everything [in c] that people are looking for in their RPC systems, today. i think that people can't quite believe that, so they shy away from it. if it washes the toast and toasts the dry cleaning, why isn't it more prevalent today?

well, inside IBM, for *massive* distributed systems, it _is_ prevalent, reliable, and currently stands at version 3.0 which is an extra one million lines of code in services, modular plugins and bugfixes on top of DCE 1.2.2.

however, that's inside IBM.

for everyone else, you only get the reference implementation, which is cut-down to _just_ the runtime library, at 250,000 lines of code.

Certainly I'm ignorant of the issues involved... which is why I'm asking : it's necessary to convince developers in other disciplines in order to change the current state of perception. With enough recognition DCE could become free again through appropriately licensed implementations,

i've been working on DCE 1.2.2 for quite some time. _yes_ there is an effort underway to get DCE 1.2.2 out under an open source license: The Open Group chose the LGPL, even.

however, the sticking point is IBM. the person that you need to speak to is "Gary Gerchak" - he is the current Open Group IBM Committee member - gerchak at ibm.com.

i sent a message to him asking why IBM was holding up the release of the DCE 1.2.2 code, gave him a suitable "face-saving" excuse saying that at the telephone conference you must have mistook that we wanted IBM's 3.0 code to be released as Open Source, not The Open Group's 1.2.2 code on which IBM's 3.0 code is based, ha ha, yes, silly me, that must have been it, i'll get in touch with The Open Group _straight_ away and be the last one to approve the release of 3.6 million lines of stagnating code under the LGPL license.

but i got no response.

anyway. bruce perens was also interested and involved in the lead-up to the failed / stalled conference call.

and be used in many projects, including Samba. It sounds as though Samba has bastardized DCE instead of decoupling it - is that correct?
as written by me, in an effort to find out what the _heck_ was going on, and because FreeDCE wasn't available in 1997, yep, that's absolutely correct.

Availability of OSF DCE RPC runtime, posted 13 Jan 2002 at 11:43 UTC by lukeh » (Master)

I remember porting the OSF RPC runtime to NEXTSTEP back in 1996. I think I got as far as getting the IDL compiler working. I believe the OSF DCE RPC runtime source code was available under an open source license back then, in fact if you look at ftp://gatekeeper.dec.com/pu b/DEC/DCE/, the source code was released on October 19, 1994.

Hence, I was actually quite surprised when, in the early days of domain controller devlopment for SAMBA, you didn't use this code as a starting point :-)

using dce 1.1, posted 13 Jan 2002 at 11:49 UTC by lkcl » (Master)

yeah, i know. inexperience, bloody-minded-ness, and also not wishing to get involved with code with a big corporation behind it. for quite some time, i moved quicker along by ignoring what already existed than i would have by trying to flounder around in ten reams of opengroup dce onlinepubs, most of which was pretty irrelevant, but i didn't know that.

now i do, which is why i'm advocating getting freedce up and running big-time :)

Availability of OSF DCE RPC source (2), posted 13 Jan 2002 at 12:12 UTC by lukeh » (Master)

Sure; however, you can't really claim that, had the DCE RPC source code been available two years ago, it would have been more widely adopted. It was, and for whatever reason, it wasn't.

lkcl, posted 14 Jan 2002 at 10:43 UTC by daniels » (Master)

lkcl, I don't know you, and am probably going to regret posting this (about the only blue in a sea of pink), but I'd personally like to see this article, and the following comments, more of a technical/architectural discussion, and less of a tridge/jra bitchfest and personal "i'm really smart, they flogged all my code" drum-beat.

This seems very very bitter, posted 14 Jan 2002 at 15:31 UTC by rmorrell » (Master)

Having worked at Linuxcare during the Samba/Samba TNG bust up and having seen the way that Andrew and Jeremy who I worked with at VA post Linuxcare handled themselves with their heads held high and without a blemish. This seems like a bitter attack on hardworking people who have moved the integration of Linux into heterogeneous network environments which is a bit out of order.

I doubt though, even if you pushed him over a cliff would you ever hear Jeremy or Andrew for that matter say a horrid thing in public about Luke because thats exactly how they behave - like gentlemen. Shame Luke that you can't behave in a more polite manner. This article was important but the stance taken was confrontational and it wasnt helpful.

I know that you have put a lot of hard work into Samba too but if you feel so strongly why dont you do something and put a realistic project together, fund it, resource it and get it off the ground and be positive.

When I couldnt get to grips with LRP - I formed SmoothWall and its a labour of love but I didnt bitch at LRP - I did something positive.

Richard

This seems very very bitter, posted 14 Jan 2002 at 15:31 UTC by rmorrell » (Master)

Having worked at Linuxcare during the Samba/Samba TNG bust up and having seen the way that Andrew and Jeremy who I worked with at VA post Linuxcare handled themselves with their heads held high and without a blemish. This seems like a bitter attack on hardworking people who have moved the integration of Linux into heterogeneous network environments which is a bit out of order.

I doubt though, even if you pushed him over a cliff would you ever here Jeremy or Andrew for that matter say a horrid thing in public about Luke because thats exactly how they behave - like gentlemen. Shame Luke that you can't behave in a more polite manner. This article was important but the stance taken was confrontational and it wasnt helpful.

I know that you have put a lot of hard work into Samba too but if you feel so strongly why dont you do something and put a realistic project together, fund it, resource it and get it off the ground and be positive.

When I couldnt get to grips with LRP - I formed SmoothWall and its a labour of love but I didnt bitch at LRP - I did something positive.

Richard

me too, posted 14 Jan 2002 at 18:53 UTC by lkcl » (Master)

hi there: me too, daniels.

mr morrel, i guess i'm overcompensating for a repressed childhood or something :) i'm sure that andrew and jeremy did in fact behave themselves impeccably.

...as i mentioned on the samba mailing lists to someone else who noticed likewise:

did you challenge, or have you at any time challenged, either of these two people [in a non-confrontational manner, which i seem not to be able to manage, through a blatant lack of social skills] in _any_ way on any technical, architectural or design issue regarding current or future issues in samba?

if so, what happened? and if not, why not? these are genuine questions that i am genuinely interested in hearing the answers to.

tia.

osf dce 1.1 code --> freedce, posted 14 Jan 2002 at 19:02 UTC by lkcl » (Master)

lukeh,

from personal experience, i know what _my_ answer is: i cannot speak for, say, wez and mirek, who _did_ have the necessary skills.

i downloaded the port by jim to redhat 5.2. it compiled. it worked. it looked like a _whole_ boatload of trouble. i started digging around, tried debugging things, gdb crashed with a 750-high stack trace from the dcethreads "posix draft 4" wrapper library, which is a sigsetjmp / siglongjmp "hack" of the first order, and that's okay.

so i abandoned it, and that was back in 1998. 2000 i investigated again, during which time, it still wasn't ready _but_ then i found "FreeDCE", which Wez and Mirek had been working on it on sf.net, and had corrected the horrible hack problems i had previously encountered and lacked the skills to correct, in dcethreads.

_and_ they autoconf'd it. _and_ started adding DCOM capabilities. a couple of months back, wez and i updated dcerpc.net's cvs rep. of freedce to support MSRPC IDL format ([size_is(size / 2), length_is(length / 2)] - dce 1.1 and 1.2.2 don't support the /2 which is a _real_ pain, but freedce does! hurrah!

next on the list is a more "generic" form such as max_is( (size & ~0x7) | 0x7)) and the like, which apparently is what some DCOM IDL files require - data transfers via interfaces, where the size of the data is rounded up to the nearest 8 bytes [yukkk! and this has to be specified in the IDL file???? eeeeuuw!]

mr morrell, posted 14 Jan 2002 at 19:09 UTC by lkcl » (Master)

please, mr morrell, i have to say this: if you were not in the linuxcare australia office, and if you were not listening to some of the most disappointing comments i've ever heard someone say to me that i respected enormously, then please, whilst i appreciate your comments may relate to _your_ personal experience of andrew's behaviour, i have to honestly say that i believe they have no relation to _my_ personal experiences of andrew's behaviour - behaviour that he himself denies at every opportunity actually took place, because it is too painful for him to admit that he could fall short, or that he could learn _anything_ from me, at any time, in any way, shape or form.

and that's a real shame, and a disappointment.

... and, also, a waste of good article space.

_why_ are we still on this? :) :) :)

re: irrational rejection, posted 15 Jan 2002 at 02:05 UTC by mbp » (Master)

Luke describes above an episode where Andrew rejected Luke's patch, but accepted one from Tim with a similar design. I think this is an interesting example of free software development at work, so it's worth studying even if we put aside the personalities.

I don't think at any point the Samba people have tried to deny or minimize the value of the work Luke has done on these protocols, or his gifts in particular areas, or that later patches that were accepted were based upon his ideas. However, people *are* saying that because luke's code tends more towards the "inspired first draft" than "finished product" end of the spectrum, he can't claim to have produced entire subsystems by himself.

Luke's also said, in this article and elsewhere, that one of his weaknesses is not liking to go back to clear up all of the little details. If that's the way he's made, it's fine. (Personally I really enjoy making existing code neat and tidy, but that's just me.)

However, I think you have to accept that before code goes into a shipping product, it has to pass through the hands of somebody who's prepared to go and do all the boring (to Luke) work of making sure that it works reliably, is secure, maintainable, etc, etc.

Similarly, if Luke sometimes has problems understanding other people's criticism or instructions, then it's perhaps reasonable that tridge would think: "I'm not going to try and beat the bug fixes into lkcl's head; I'll tell Tim instead because he's easier to talk to." In the other direction, the author of the final patch has to have some capacity to explain it to other people in a way they can clearly understand, rather than "I know this is right but I can't explain why".

So there is an explanation in which tridge's behaviour is rational: let Luke do the first draft because that's what he likes and is good at; but make sure Tim does the final cut because he's better at attending to the details. What Luke calls "pavlovian" I would say was more just the process of getting a strong opinion of Luke's strengths and weaknesses.

Part of knowing your strengths and weaknesses is accepting that you can't do every job in the world and you might have to bite your tongue and cooperate with others.

i always appreciate what martin has to say, posted 15 Jan 2002 at 11:19 UTC by lkcl » (Master)

it's funny. most other people i would have something to say: they're usually out to do one person more justice than the other. i think, however, that martin's comments are pretty accurate and thoughtful.

the only thing that i would say is that due to the massive amount of work needed to be done, i worked almost exclusively on nothing _but_ first drafts, for three years, with slow incremental changes tidying up where i considered it to be worthwhile.

heck, i'm not mad: i _knew_ the lifetime of the code i was developing was supposed to be short, and on that basis didn't want to waste time cleaning it up.

where the _real_ work begins is to use FreeDCE, behind the clean interfaces it provides. now _that's_ where it's worthwhile doing decent code, a total rewrite, and worthwhile sticking to software engineering principles - not some piece-of-junk code / design, no matter how cleaned up it is.

remember: samba tng, samba 2.0.x, 2.2.x _and_ 3.0 are _all_ based on the first cut / experimentation i did, and it _really_ shows.

and despite that, if you think that samba contains impressive bits of code, wait till you get into the Open System Foundation (Open Group)'s DCE 1.1 or 1.2.2 code: you'll be staggered at its depth, and the vision of the people who created it.

[hi, i want a linux, please. hi. i want a samba, please. hi, i want an apache, please. hi, i want a DCERPC, please.

"that'll be 10 million lines of code, please, sir. ... etc :)"]

What I have learned from this, posted 16 Jan 2002 at 06:18 UTC by nelsonrn » (Master)

What I have learned from this posting is not to take lkcl seriously anymore. No, really, Luke, you come across as a serious whinger here. Maybe there is technical merit to your ideas, but at this point you are so emotionally invested in them that when I read your presentation of them, my immediate reaction is to dismiss your concerns. Honestly, a "stunning admission"? All he said is that he doesn't care about general-purpose DCE. Perhaps the problem that DCE solves is better solved using a different service under Unix? Like I say, I really don't know, and I know that I still don't know from reading your words here. -russ

... continuation from martin's comments, posted 16 Jan 2002 at 10:17 UTC by lkcl » (Master)

... [i thought yesterday, afterwards, that's it's important to move forward and learn from the past...] so what can be learned from this?

well, it brings us back again to the critical importance of using a modular design. the primary issue with what happened was that i continued for three years to research using what i considered to be crap, whilst jeremy took a four-to-five month-old version of that same code, "cleaned it up" which took him about six to eight weeks, released it in 2.0.x, but didn't "clean up" the research code. very little further actual real functionality was ever added to the 2.0.x code,

by the time these two code-paths had diverged, there was no means to cut over even a fraction of the [crappy, but proven (but not in jeremy's or andrew's eyes) but significantly more functional] research code, as a fraction would be insufficient, and the inter-dependencies too large _anyway_.

so, i'll say it again: to be upgradeable and to remain maintainable, a modular design is _essential_ on any large project, and that includes open source ones. and the one critical project that's missing that, which is only just being addressed, is samba.

New Advogato Features

New HTML Parser: The long-awaited libxml2 based HTML parser code is live. It needs further work but already handles most markup better than the original parser.

Keep up with the latest Advogato features by reading the Advogato status blog.

If you're a C programmer with some spare time, take a look at the mod_virgule project page and help us with one of the tasks on the ToDo list!

X
Share this page