Help Please

Kenichi Okuyama okuyamak at dd.iij4u.or.jp
Mon May 21 14:17:28 GMT 2001


>>>>> "AT" == Andrew Tridgell <tridge at samba.org> writes:
>> # I can't give you any more hint because your mailer does not
>> # seems to set X-Mailer header..
AT> How about we agree that I don't give you any hints about what color
AT> wallpaper you should use and you don't give me any hints on
AT> configuring my mailer. OK?

As long as you quit putting Reply-to:, I don't care how.


AT> We run Samba under insure to catch memory leaks. If you know of a
AT> memory leak then point it out rather than just sending such crap to
AT> the mailing lists.
>> I did. Look at old Mail and patch lists.
AT> None of the patches from you in samba-patches is for a memory leak. If
AT> you have a patch for a memory leak then please send it in.

Then you're not recognizing it as memory leak.

I gave patch about 

source/smbd/process.c
void smbd_process()

There, InBuffer and OutBuffer are being allocated, but in case of
one failure, you simply return without doing anything, while you
shold free them.

# Wait... Did I throw it to patch-ml... I don't remember...
# I might have written it here... for patch didn't seems to be working.


>> I think continuing current work without any re-design IS INSANE.
AT> Propose a specific design. Do a prototype. Do *SOMETHING* that will
AT> convince me that your ideas have some worth. Saying vague stuff about
AT> how much better things would be if only we followed some design that
AT> you have only in your head doesn't help.

Great!

You mean you want to continue with design that many Multi-byte world
people are having hard time trying to fix but not being able to do
so because of dangling string management. And saying that you will
not wish to hear from them so you'll make big technical leap and
letting them out.


AT> As for internationalisation, I am trying to do something about it
AT> rather than just ranting on a mailing list. As you may have noticed
AT> the head branch now does unicode on the wire. The next step is to
AT> convert to utf-8 internally, and add a string conversion layer in the
AT> VFS code. I am working on that with Iverg. We should have *full*
AT> support for all languages with just a few weeks work - watch for it
AT> over the next month or two (assuming I get some time to put into it).

"Full" you say. Sounds good, but did you check what Unicode v3 says?
Aren't you simply thinking that "With UTF8, we will have ASCII code
ASCII, so nothing is need to be worried"?!

If you really know about Unicode, you must not have selected UTF-8
as internal code. Not UCS2 itself too. You should be using 32bit
fixed variable which each word points one character, to treat
multi-word characters.



>> You should stop development for several month(Now that you added
>> even more code, it's not just 6 month, we need more). Annouce that
>> you stopped. And ask for fix of basic structure. So that Samba can
>> re-start growing into faster speed, and Intenationalizations.
AT> I think that you have very little understanding of how free software
AT> is developed.

I think YOU don't, Andrew.

There's no such thing as "free software development model" that you
think there is.


Several free software succeeded, because they stick to small
functionality and kept code small, so small that they didn't need to
care about multi-lingual.

Other free software succeeded because they designed correctly. They
know about algorithm, and OO. They knew how to divide things.


With any of these two, because base structure was clean and clear,
they could make change incrementally.

"INCREMENTAL DEVELOPMENT" is "RESULT", not "METHOD" nor "MODEL" of
this development. If you designed thing wrong, things won't work the
way you wish.

And If you want any "development model" about free software, then
here's one:

" Since we do not have any target dates that we must keep or else
  we'll starve to death, We can do anything we can't do with
  business programming.
  Stopping, scratch and re-building, are two large merit."
---- 
Kenichi Okuyama at Tokyo Research Lab. IBM-Japan, Co.
               @Samba Users Group in Japan




More information about the samba-technical mailing list