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

Re: Debian BSD.. cool idea

Now this is actually worthwhile discussion... :-)

Dan Potter writes:

> I recall waay back on Jan 31 when Raul Miller wrote:
> > You're right.  Though that's a fairly constrained case and I
> > think it would be fine to have a kernel-specific set of kld*s.
> > 
> > And, I guess that means that linux apps which use /proc/ aren't
> > going to work.
> There's more to it than that though. A lot of basic system processes
> (bound up in util-linux right now) would need to be the FreeBSD
> equivalents, and they'd have to be built for the same kernel version.

I think the thing to do in the short term is to track FreeBSD equivalents,
and deal with kernel version dependence for those things. One long term
solution could be to look at creating a library interface that is
compatible with both Linux and FreeBSD, and maybe open to other targets. Do
it under BSD license, and maybe NetBSD and OpenBSD will be able/willing to
use it, too. That would be nice. :)

In any case, the issue is there in Linux, too, between 2.2 and 2.0, IIRC.
Seems like I had to upgrade ps and ifconfig, and a few other things. It's
less of a problem, but it _is_ there.

For the short term, I'd favor making the portions of the userland that are
glued to the kernel revision be built from the same source package, but be
made into separate binary packages, with exact version dependacies. It's a
bit ugly, but we already do that for apache and X, I think. That lays the
groundwork for a long-term solution -- which (long-term solution) should be
built in cooperation with FreeBSD.

I really wish that the FreeBSD advocates on this list would realize that
there isn't a real desire to fork the system. But it could happen, and the
most likely reason would be if FreeBSD refuses patches, and made it hard to
stay in sync. That could be fixed if someone with commit priviledges were
to work on Debian/BSD.

Reply to: