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.
