RE: Is it _really_ dead?
> > 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! :)
>
Yes, exactly. BSD upstreams stay BSD. GPL'd upstream stays GPL.
The problem is with new software specifically created for an effort.
> > > 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 we achieve is a BSD system that uses our existing source base.
We already experience bandwidth problems with our current FTP sites
because of the large size of Debian's core system ports (to i386,
PowerPC, SPARC, MIPS, Acorn, m68K, etc.), plus the reams of add-on
software.
> 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.
>
But I could turn this around on you as well ;-), why *not* use the
GNU tools? We already have these in place, are familiar with them, and
would be more than happy to fork patches into their sources to
either make them compile natively on BSD's, or work better in the
BSD framework.
Debian already has several BSD-utility packages to provide many of
the core utilities found in BSD on top of a Linux system.
> 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?
>
Not sure. I certainly have had trouble with ext2fs under the Hurd,
but not with Linux. It sounds like your experiences with it may
have been long ago? Or perhaps we've just been lucky.... ;-)
> > 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?
>
As another poster pointed out, upgradability. I'm sure the ports
tree is a good system, or else it wouldn't be in use. But the dpkg
and apt toolset is what we like, and a Debian-BSD would probably be
based on them.
I guess I'm confused by what *you* would want in Debian at all, if
you don't like the GNU tools, apt-get sources, etc., etc. What's
in Debian that would be of any use to BSD then?
> >
> > > 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
[ ... snip ... ]
> > >
> > 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.
>
Sure -- I'll buy that. But again -- if Debian's GNU tools are not
of interest, you want to continue to use the BSD ports system (i.e.,
not a sythesis of ports and apt-get sources), and you don't think
Debian has more software available, then what of value do we provide?
Maybe if you explained that I could better understand your goals.
[ ... snip ... ]
> If you're looking to unify something, perhaps Debian joining up
> with openpackages would be a better idea.
>
Well, sure it would be useful to see what they are doing and perhaps
try to be compatible or at least functionally similar, but we may
be trying to solve different problems. And I don't think we'll be
giving up our system any time soon without a good technical reason
to do so. It works quite well, and is very well liked by most of
the Debian community.
> > > 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.
>
I'm not suggesting a textbook experiment. What I am saying is that
it seems possible to extend the apt-source tools to unpack software
packages into a BSD ports tree to allow a native BSD build of software.
It could handle build-dependencies which would be an advantage over
the existing BSD system as I understand it.
> > 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.
>
Come on Dan, you're being hyperbolic here :-) BSD and Linux share
many similarities, or else the linux emulator tools would not function
at all.
Most Linux packages will build correctly on the various BSD without
issues. It's not as if we sit around writing most of the software.
It's developed on Solaris boxes and Irix's and AIX users and HP/UX
users and on and on. I am sure certain low-level tools and kernel
utilities are unique, but you can't tell me 'ls', 'vi', and any
of a hundred other pieces of software require special handling for
BSD. GNU configure is a great tool for these purposes.
Regards,
-Brent
Reply to: