Re: Re: Wow, hadn't realized this list was active
>I don't see any good reason to fork the FreeBSD kernel. As I see it, it is
>completely within Debian standard practice to create patches as needed to
>make things work in Debian, and submit those patches to the original
>developers.
Thats good. I had gotten a different feeling from irc.openprojects.net
channel #debian, they felt that if it wasn't the easy way out for Debian,
then it shouldn't be done.
Of course, that went against everything I remember from being a Debian
user. Glad to know things haven't changed that much ;)
>Obviously, it would be good to make any patches minimal, and submit them
>back to FreeBSD. This is normal practice, however.
Good! Eivind, a prominent FreeBSD developer (EE is his handle if he isn't
using eivind) said he was looking forward to patches.
>I don't agree with that comment, either, or I wouldn't be interested in
>doing anything with it...
>I don't see where you discuss this on your page. You say why you think it
>may be a bad idea, but not why it is not needed. Those aren't the same
>thing exactly... And I think that with appropriate use of CVS and package
>dependacies, it should be possible to manage everything except the CURRENT
>tree without any serious difficulties or without major code forking.
What about changes to the -STABLE tree? FreeBSD doesn't remain static
from release to release, there are (sometimes daily) commits to STABLE.
Will Debian GNU/FreeBSD users be limited to only running releases?
>Why? Because when a FreeBSD release comes out, it can be pulled into a CVS
>and merged in with a Debianized source package. As long as there aren't any
>packages requiring drastic changes, (we should avoid that like the plague,
>IMHO) the only thing to left is simply depending the system binary packages
Only ps, top, and other packages dealing closely to the kernel.
If you'd like, give us patches to help fix this relationship to make
it less painless for the developers :D
>on the kernel release. That should take care of it nicely, unless upgrading
>the system binaries before rebooting with the new kernel would break...
"system binary packages" like ps, top, etc? Well, how will users get
these installed? Via a debian method or from a freebsd source tree?
>I have to wait until I can get a little time and a couple spare boxes. I
>figure on building a normal FreeBSD box and a test system to try things on.
I guess I could hook a few of you up with an account on my old 3.2-R
box. Its a shame you guys won't be able to play with sysinstall or
packages or ports, however, because you won't learn what the true
beauty of the FreeBSD userland is (which you'll need to know if you want
to make changes)
>If I can get permission from my boss, I may be able to provide logins for
>people wanting to do actual work.
See above.
>Depends on what's worthwhile to you. That's really the whole point of this
>discussion. I think that if Debian can successfully be ported to a BSD
>kernel and to the Hurd, then it has just become a (somewhat) portable unix
>userland rather than just a Linux distro. That seems to me to be quite
>worthwhile. Porting glibc might just improve it. Porting it to FreeBSD
>might well bring bugs in both to the light. (Which can then be fixed...)
Exactly what do you mean by "port the userland" ?
Its time to start looking for specific things you'd like to see on FreeBSD.
Most of the userland is already the same.. ls is ls, rm is rm, grep is grep,
find is find, etc.
>So in that case, why would it be so difficult to port it? Unless glibc in
>the /compat/linux is already "halfassed"?
Its of decent quality, but isn't a native port as it uses the Linux ELF
compatiblity and syscall translator (we call this linux compatiblity)
>Perhaps it would be simplest to adapt that compatibility mode to support
>most of the Debian userspace? I'd guess that this is really just support
>for the Linux ELF format, some libraries, and maybe some syscall
>compatability support.
I'm sure it already does. You have that as an option.
>I personally don't consider myself a zealot. I am interested in the FreeBSD
>kernel as an alternate kernel under the Debian userland. I'm just not in
>the least interested in dealing with the FreeBSD userland. I'd like to be
>able to manage it like I do with Debian today.
How can you judge the FreeBSD userland to know you want to replace it with
the Debian userland if you've never, and never plan on, work with the
FreeBSD userland?
You'd be surprised to know that being a FreeBSD admin is at _LEAST_
as easy as being a debian admin. While YMMV, for me its a thousand times
easier.
>I see no reason to spend a lot of time anguishing over what it will do to
>either Debian or FreeBSD. Both exist now, and have separate, but not
>completely incompatible goals. I see no reason why any improvements made by
>Debian wouldn't be submitted to FreeBSD (IIRC it's normal Debian practice
>to put patches to BSD licensed source under BSD license), nor any reason
>why Debian couldn't track the FreeBSD CVS trees if it wants to.
>I think the biggest danger to FreeBSD (or Debian) in this is probably
>negative attitude and unwillingness to cooperate.
Amen.
>I don't see why the FreeBSD project should be damaged. There are certainly
>things that Debian users will want that would be good for FreeBSD as a
>whole.
What to the debian users want, and are they sure that is what they want?
>For instance it would be good for the FreeBSD kernel to be able to boot and
>function from an ext2fs. Don't know if it already can, but if it can't, I'd
>expect someone will probably try to implement it. This is NOT a bad thing
>for FreeBSD, any more than it is bad for Linux to support the bsd
>disklabels and filesystem in the kernel.
You don't want ext2fs. Its an icky filesystem that corrupts very easily.
I speak from experience.
We have OK support now.. i quote LINT:
# Add support for the EXT2FS filesystem of Linux fame. Be a bit
# careful with this - the ext2fs code has a tendency to lag behind
# changes and not be exercised very much, so mounting read/write could
# be dangerous (and even mounting read only could result in panics.)
#
options EXT2FS
It is a lot better than LINT says, from what I hear its quite usable.
>Similarly, Debian might find it convenient to fix fdisk so that the intel
>version has bsd disklabel support. (The upstream source is broken.) Or
>include a mkfs for FFS. This sort of thing isn't bad.
Knock yourself out :)
>People in the FreeBSD project AND the Debian project need to think
>rationally about this: there is no particular reason why cooperating with
>each other needs to be a bad thing. It would definitely be different, but
>there's no reason for it to be bad unless people make it that way. In
>fact, I think that FreeBSD people could easily ensure that no code fork
>takes place, simply by helping instead of attacking.
I'm here to help.
If I came off as otherwise, my bad.
>Religous attitudes about licenses and not-invented-here need to be relaxed
>on both sides. If that can happen, I think that FreeBSD should benefit as
>much as Debian. FreeBSD could get more people using it's kernel, (and being
>exposed to it at all) while Debian can become less Linux dependent and more
>portable. Good for both. Jordan Hubbard has a good article here:
>http://freshmeat.net/news/1998/07/13/900364444.html Please read it. I
>quote:
> "[...] What we can do, however, is to continue to *strongly* promote
> any and all ties between the various free software groups and also
> actively encourage users to familiarize themselves with each and
> every one of the various types of free software out there, whether
> they're currently "pledged" to a given cause or not. Not only will
> this experience help to shatter some of the walls of mistrust and
> general acrimony between the various clans, but it can also
> benefit those who are firmly convinced that they wish to stick with
> a certain one."
I agree. You guys can start by making dpkg/apt portable.
I also would like to point that that "familiarize" part. Use FreeBSD
and appreciate its kernel AND USERLAND before you want to change it.
>I have not heard that Debian has been bad to deal with for upstream
>developers of applications. I think that this need not be different. (In
>terms of cooperation.)
Goodie :D
-Dan Papasian (bugg)
Reply to: