[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Glibc-based Debian GNU/KNetBSD

On Mon, Dec 01, 2003 at 09:26:33PM -0500, Perry E.Metzger wrote:
> Robert Millan <zeratul2@wanadoo.es> writes:
> >
> > It isn't the FSF who maintains Glibc.
> Whatever. The point is the maintainers won't do the work for you, so
> the "upstream" comment doesn't hold much water.

The primary target of Glibc is Hurd/Mach, but still Linux is much better
supported. This is because GNU/Linux is a mature system while GNU/Hurd is
not yet.

The maintainers will support a particular system if they're interested in it,
and I have reasons to believe some of them will be interested in GNU/K*BSD.

> That's not what "third party" means. "Third party" means stuff not
> provided by The NetBSD Foundation in our releases. The BSD world
> doesn't work quite the way the Linux world does in this regard. We
> maintain both a kernel and a tightly integrated userland that goes
> with it -- anything else, for example, Gnu Emacs, is "third
> party". Our pkgsrc infrastructure exists to make it easy to compile
> third party software, but we do not claim that Emacs and /bin/ls are
> supported the same way.

This is Debian, and we have around 10000 packages here. Why do we have to
support installing packages from the NetBSD pkgsrc archive?

> > The threads stuff is not as relevant nor as complicated as you pretend. I've
> > been working with libpth
> pth is not a real preemptive threads library. It doesn't work very
> well as a result. You need kernel support to do threads right, and the
> kernel support is necessarily intimately connected to the userland
> implementation that interfaces with it.

I know that. The same applies to the rest of libc.

> > At some point we'll study which of porting NPTL or porting the
> > pthreads from NetBSD's libc is a more viable option.
> You will never port NPTL, period, because to do that would require
> that you change the NetBSD kernel, and you aren't in a position to do
> that.
> "Porting" the pthreads from NetBSD's libc will be a very serious job,
> and as I noted will require tracking all the changes that get made in
> NetBSD's pthreads engine on a constant basis, because as I said, there
> is a protocol that the kernel and userland parts of the pthreads
> implementation have to agree on.

We can do either. If it's a "serious job", that's fine. I'm not really
worried about that.

> > If you want to help or propose a solution, that's fine, but stop playing
> > devil's advocate which is just a waste of my time.
> I'm not playing devil's advocate. I'm trying to tell you the
> truth to try to help you. You seem to be unwilling to listen. Thus,
> I'll drop out of the conversation. Do whatever you want.

As a member of the NetBSD project, I have my doubts that your main interest
here is helping me.

We have had this discussion before. I explained a hundred times why porting
the bulk of Debian is much easier with Glibc, but again some people are
unwilling to listen. They have their reasons, of course, but this is why I'm
proving it with facts, so I don't have to engage in eternal discussions.

Robert Millan

"[..] but the delight and pride of Aule is in the deed of making, and in the
thing made, and neither in possession nor in his own mastery; wherefore he
gives and hoards not, and is free from care, passing ever on to some new work."

 -- J.R.R.T, Ainulindale (Silmarillion)

Reply to: