Terry Lambert wrote:

Yury Tarasievich wrote:

[...info and pointers greatly appreciated...]

Now:

Most of the reasons this stuff is not in FreeBSD is NIH (not
being the pet research project of a committer), license, the
need to "productize" the code from research, etc..

For the complaints about scalability... Linux has a project that
they are very proud of, in order to obtain 10,000 simultaneous
TCP connections. With respect, I personally achieved 1,600,000
simultaneous TCP connections on a modified FreeBSD box with 4G
of RAM. During this process, I found a credentials reference
count overflow bug (since fixed in FreeBSD), which occurred on
close, after opening more than 32,763 connections in one process.
No one else reported this bug, so I have to assume that no one
else ever ran FreeBSD up to that number of connections, before.

So... the primary reason is that no one is using FreeBSD under
the loads necessary to cause the problems to exhibit themselves.
You have to have a need in order to be interested in a way of
satifying a need. 8-).

I wasn't explicit with my question, although with your explanations my question(s) seems rather rhetoric -- but I'd like to know your opinion:

- what is the *real* *reason* for stuff that good not going into FreeBSD?

and

- doesn't all that mean that the supposed "plentiness of choice" turn out to be rather its opposite? has one not belonging to the "inner circle" *any* chance of influencing things course?

You were also saying in same post that:

The fixes are mostly
simple, but for whatever reason, they never make it into FreeBSD
proper (my theory is that the developement focus is heavily skewed
to general purpose processing, rather than network processing).

And throttling the "FlagFeature"???

That sort of thing has to be there, for FreeBSD to be interesting
as a reasearch OS, so that additional work occurs on the platform;
that's pretty much a given. You wouldn't have someone as well-known
as Sam Leffler donating code, if that code was unlikely to get in,
since it would be a waste of his time and effort (the same reason
some people have left the project, actually).

That I didn't understand. People left because they couldn't get their code in or because they couldn't stop code of well-known persons getting in?

So even if you don't like "feature creep" or "bloat", when it impacts
top end performance, top end performance really doesn't matter to most
people who are doing the coding (i.e. how many OC3's do you have to
your computer? How many would you need to have to saturate even a
single gigabit ethernet?).

I wasn't precise in wording. Possibly, one cannot even see the real impact of worsening of network processing. I just do not see the good reason for *actually* making network processing capability -- the most praised feature of free *nixes -- worse, not better. And I think it's bad press, too.






To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message

Reply via email to