(Sorry for the lateness of this reply, I haven't been checking -bsd
very regularly in recent days. It's a long email, which is common for
me, but I do cover a lot of ground in it.)
On Mon, Dec 01, 2003 at 10:56:30PM +0100, Robert Millan wrote:
> This is not about the Debian tools, you can have Debian tools even on NetBSD
> and get them into the ports collection.
>
> It's about the GNU libc and userland, which are the standard in Debian and
> I see no reason to replace them.
There are other things in Debian that are also standard but that you do
see a reason to replace, such as (most prominently) the kernel. Many
valid technical reasons have been given as to why the NetBSD libc might
well be more appropriate for a Debian port to the NetBSD kernel, but
most of your replies have been boasts of the superiority of the GNU
userland utilities and a desire to use the same libc as Linux and Hurd. I
personally share your preference for the GNU utilities, but I quite
strongly believe that it's a matter of personal preference, and I can
definitely see how the NetBSD developers can reasonably disagree with me
about that.
In any case, everyone seems to be in agreement that the Debian port to
the NetBSD kernel should use the GNU utilities, since a vast number of
intentionally Debian-specific tools and scripts have been written to
expect them. The same argument does not hold as well for the GNU libc,
because the vast majority of the software in Debian is supposed to be
portable enough to support NetBSD as an OS, and the NetBSD libc in
particular. (If not, it's usually either a bug or else the author just
didn't think about it one way or the other. In the latter case, most
authors would be willing to accept a patch increasing portability.)
Wishing to use the same libc as the other Debian ports is not obviously
a bad argument, but it would need more justification. In fact, this
superfically general rule is only one possible generalization of the
fact that all current Debian ports use the GNU libc. Another possible
generalization would be evident if you notice that the GNU libc is the
primary, best integrated, and best supported libc on all existing Debian
ports (including both Linux- and Hurd-based ones). This suggests that
the rule should be to use the primary, best integrated, and best
supported libc for every Debian port, which in the case of NetBSD would
be the native NetBSD libc. Choosing between these generalizations
requires more justification, and only the supporters of the latter
generalization (the one that would chose NetBSD's native libc) have done
so.
They have done this justification by providing many technical examples
of how their patches have been much less intrusive and how the porting
process has gone much more smoothly with the native libc. In fact, there
is reason to believe that this would be true for any other *NIX variant
to which one were to make a Debian port (e.g., a hypothetical
freed-as-in-speech AIX or Solaris). That successful thought experiment
of extrapolation to potential future situations suggests that the second
rule in the preceding paragraph generalizes better than the other one,
and so it is the one to pick in absence of other conflicting
information.
That is why the native NetBSD libc seems to be the more
productive way to go. If you still disagree with me, I encourage you to
pursue your GNU libc-based version and present results when you have
something concrete to share on this list for public testing. Until you
have at least this to show, please don't belittle or trivialize the
efforts of other people, who have spent a great deal of effort trying to
implement the same functionality you are now trying to achieve, and who
seem to have a great deal of experience with the area in general.
I can't find the exact messages for some of these examples of their
experience, but one post mentioned that the poster had implemented
applications using hundreds or thousands of threads; Perry Metzger
talked in another post about his and the NetBSD team's two-year-long
ordeal to get scheduler activation working properly in the NetBSD
kernel-and-libc package; and the author of another post had, apparently,
individually implemented scheduler activation in a toy OS. These do not
seem like people who are inexperienced in threads. I have less
experience than they in this regard, which I freely admit, and which
inclines me to believe them on this matter, especially since they are
all in agreement.
Finally, Matthew Garrett's post in which he criticized the style and
tone of your emails, which you called a "personal rant," seemed to me to
have been written in a very professional and calm manner, with one minor
exception ("your complete inability to..."). He did sound annoyed, but I
and most probably numerous other readers of this list were also annoyed
at your tone, for reasons that Matthew summarized well, and Matthew did
seem to remain mostly polite while being annoyed Rather than not paying
attention to him, as you implied you would prefer to do, you might want
to see if you can glean from his words any useful advice on how not to
offend readers of this list.
If I have reopened a (temporarily-)closed flamewar by posting this
message, I do apologize for it, but hope that some of my arguments are
stated clearly enough to reduce the heat of future flamewars on this
topic. (Wishful thinking, I know....)
- Jimmy Kaplowitz
jimmy@debian.org
Attachment:
signature.asc
Description: Digital signature