Re: Is it _really_ dead?
On Mon, Oct 16, 2000 at 10:23:26AM -0700, Brent Fulgham wrote:
> > >Alright I can't just sit quietly any longer. :) I don't remember
> > >all the "flames" on this list that everyone is spouting off about.
> > >What I remember was that there was a mixture of emotions of whether
> > >this was going to create a fork. The way I see it there are two
> > >possibilities here.
> > >
>
> The first issue that comes up in these discussions is the License.
> Most Linux systems are GPL/LGPL-based, while BSD's are (of course)
> BSD-based. This is usually enought to ignate a religious war that
> causes everyone to go home angry with no work done.
I think that given the BSD tools were there first, any work done
to them should be licensed under the BSD-style license. I don't
think anyone disagrees with this, because basically you want
to share with your upstream provider! :)
> > >First Debian's userland gets a BSD kernel in which case people here
> > >should just go off and do it. Not likely to drum up a lot of coders
> > >in the BSD community to help (and it doesn't look like many in the
> > >Debian community are interested in it either), though they will
> > >probably lend an ear to questions should you have them.
> > >
>
> This shouldn't be a big deal -- if BSD's Linux compatibility is workable
> it should be fairly easy to do this.
Right, but the thing is, the userland isn't terribly different in the
first place. There's more on this to come..
>
> > >There was one other thing mentioned on this list in the early days
> > >and it involves replacing the BSD userland with an all GNU userland
> > >and I'd don't believe there will be many in the BSD community that
> > >will be into supporting such an effort. You are welcome to try but
> > >this IMHO will result in a fork and dividing all of our efforts again
> > >in support of another project doesn't help either community.
> > >
>
> As far as a Debian solution, we would probably *only* be interested
> in providing (1) a Kernel package for existing Debian users, plus
> (2) a compatibility tool for using Debian packages withing a standard
> BSD framework. I.e., we wouldn't want to provide separate packages
> for BSD for the various applications and add-ons.
I fail to see what you achieve. I think this plan envisions some
synergy between Debian and BSD, but what you'd get is a botchery
of both systems and an end product that is not up to BSD standards (nor
Debian standards)
What's the point in replacing say, BSD rm with GNU rm? Or any other
of these base utilities? And for the third party utilities, there is
no difference between the Debian and BSD counterpart.
Are you trying to provide an upgrade path from Linux to BSD? I don't
think this is advisible, because using ext2fs with BSD is something
that you can do, yes, but when you have a better alternative (UFS+softupdates)
it makes no sense to have a buggy filesystem bog you down. Besides
the usual ext2fs problems, it's not as if any of the BSDs have a
grade-A implementation of it. And why would they need one?
As a side-note: It may seem that I'm bashing ext2fs unfairly. But I've
had a bad first hand experience with it failing mysteriously and
not even letting me know, and then prohibiting me from making temporary
files. Strange, abnormal, and probably not repeatable- but that's
another story.
> One way this might work would be for BSD users to use apt-get on
> the Debian source archive, which would automatically unpack the
> Debian source packages into the BSD ports tree, then run the build
> and install automatically. This seems like it would be quite
> doable.
And I ask you: Why? Why would someone want to go through
the trouble when the BSD ports tree is already there and tested?
>
> > What BSD camp would like though is some way to use the debian's
> > extensive package collection, and some way to use any sw if it's
> > already packaged, by let's say debian. Currently Freebsd runs
> > linux binaries if one installs a redhat based compatibility
> > package and enables a boot-time option.
> > But the way redhat brings out their distro versions, actually
> > going to redhat site, and trying to install an RPM is not
> > something a user like me does. Instead, their are linux
> > compiled packages like acrobat 4, Staroffice 5.2 in FBSD's
> > on ftp site, which use the compat feature.
> >
> See above for how this could be achieved fairly easily using
> apt-get on source packages.
I think I get where you're going. But there are plenty
of FreeBSD packages, while we won't compare numbers because
Debian implements some things by having one program having
several different packages- so raw counts would be unfair. I would
say that when it comes to finding Software XYZ in either Debian
or FreeBSD, you have equal odds.
Given the elegance of the ports structure, it's also easier to write
and maintain a FreeBSD port than it is to do the same with the Debian
package. Maybe there is better documentation now, but when I last
tried to make a Debian package it was a total nightmare- having
to deal with the source and compilation by hand, getting it into
a temporary directory, etc.
If you're looking to unify something, perhaps Debian joining up
with openpackages would be a better idea.
> > What Debian Camp (Or a few in the camp) would like is the
> > proof of concept implementation, indicating debian is really
> > kernel independant distribution, by incorporating BSD kernel,
> > besides gnu-hurd.
> >
>
> As one of the Hurd developers, I can say that Debian is not
> perfect with respect to Kernel-neutrality, but it gets better
> all the time. Basically, the effort involved would be to
> build Debian packages on a BSD-system, then submit patches
> to the Debian maintainer indicating any changes required to
> build on BSD. We have tools to determine system architecture
> during the build process, so this isn't too difficult.
Are you suggesting that this is merely a textbook experiment? OK,
but I warn you: the end result will not be something that belongs
in the "real world" where people look to have a productive system.
Call me a non-believer.
> > Technically I might be totally missing the point, but this
> > would probably require, C library/compiler essential OS
> > utils debian package management sys etc etc bundled with
> > BSD kernel.
> >
>
> Maybe -- I'm not sure what all the dependencies would be.
> It could be as "simple" as just the Debian-base system with
> a BSD kernel (compiled for BSD), followed by the ability for
> a user to apt-get source packages to build natively on their
> machine. Then the effort would simply be trying to compile
> packages and identify problems, then submit patches to correct
> build dependencies, etc., to the upstream Debian maintainer.
> This is what we do for the Hurd currently and it works
> quite well.
No, it's really, really, really not that simple. BSD is not Linux,
and you can't just interchange kernels between the two as if it's
nothing. You might as well take kernel32.dll and try to use that
in place of vmlinuz.
> > Now *bsd also uses GCC compiler, so what parts will actually
> > be diff is not clear to me.
> >
> I suspect not mutch if BSD Linux binary compatiblity is
> sufficient. Otherwise, the Debian bootstrap tools would be
> required.
Sure it would be sufficient, but why you'd want to use it for
this, I don't know.
--
Dan Papasian
(bugg@bugg.strangled.net)
Not everything that can be counted counts, and not everything
that counts can be counted.
--Albert Einstein
Reply to: