Since my workstation had motherboard failure, I've been using a box with
UCB mail and vi ;) Please excuse the fact that I didn't quote messages
with all of the fancy >'s as much as I could of, it is all being done by
hand. (I'm going to install mutt after I finish this)
From: Dan Potter <[EMAIL PROTECTED]>
<<The nice thing is that if a good method is decided, Debian has a good
stability record that ought to carry over to most of Debian/BSD. Some
things would need more testing but it shouldn't be as big of a proposition
as, say, Debian/Win32.. which is actually real, scary enough =)>>
As a contributor to FreeBSD, I need specific things that you'd like
us to fix. FreeBSD has a good stability record too..
The message I'm getting (Which I'm damn near positive you don't want
to send) is "Well FreeBSD is great but it isn't debian so lets put
our name in front of it and use the names of our tools instead"
You seem to imply that Debian would be bringing stability to FreeBSD.
Isn't stability already there? Please elaborate.
<<As far as I can tell, in Debian, everything that goes into /usr is
something installed by the system. Of course this includes most of the
useful parts of the operating system since Debian includes not one, not
ten, but at least twenty kitchen sinks at any given time; and system
components are just another one of those pieces that goes in with the
rest. So everything that is managed by the system goes into /usr.
/usr/local is reserved almost exclusively for things installed from
source. In FreeBSD, it seems like the only things that go into just /usr
are things that come from the FreeBSD source snapshots -- the kernel, and
all the system binaries. This is kind of a weird concept if you think of
it in terms of the standard Linux way, which is probably one reason I'm
being confused =). But I like having the seperation -- things in /usr are
managed by the system, things in /usr/local are managed only by me.>>
Same with the rest of the UNIX world. (FreeBSD Included)
Things in /usr/local were installed by the user. Things in /usr were
installed by the operating system.
<<One example of this is the way that 'extra' packages are handled. In
Debian, e.g., MySQL is just a component of a vast system that I can
download and install via dselect, apt, or ftp/dpkg. It goes into /usr and
/var. And it gets an init script in the runlevel directories. I treat it
just like I would the netbase package that runs things like inetd. I just
do a "/etc/init.d/mysql start" and away it goes. The level of consistency
there is nice.>>
Except MySQL is a 3rd party package, so it shouldn't touch much below
/usr/local. It should go into /usr/local/var (or /var, depending)
and /usr/local/etc.
<<It seems like the package system in Debian is also much more comprehensive
in the way it deals with dependencies and file conflicts. For example, I
installed ja-tcsh tonight along with all of the message catalogs for the
anime characters without realizing that all these packages overwrite
eachother. I'm not sure if there's a way around this since I'm fairly new
to FreeBSD (it probably shows) but it would be nice if it at least said
that they conflict. I think you mentioned this above though, and I
understand that there are only so many hours in a day to implement this
stuff =)>>
Yes, dpkg on paper handles conflicts in a much nicer manner. There will
be conflict handling with 5-CURRENT. The user is expected to read the
README with each port to see if it conflicts, and remove older versions
before installing newer ones. Perhaps this is too much to expect, yes..
But it is still easier to just fix FreeBSD then make another OS out of
the thing :) I used Debian exclusively from when hamm was just getting
onto CDs until a month or so slink went glibc2.1.
I've been using FreeBSD for 8 months now, and contributing for 1 month.
I've had _less_ hassle with ports/pkg_add then I ever had with dpkg.
While the feature is lacking on paper, Real Life Usage(TM) shows ports/pkg_add
to be superior. (Of course, YMMV)
I don't see how Debian handles dependencies better. DEPENDS with
ports/packages works fine.
<<I'm assuming you're involved with the development of FreeBSD (from the
paragraph up above), and so I'd like to say thank you thank you thank you
for that man page! ^_^ I don't think there's anything like that in Linux
and it helped me a lot when I was getting started. I actually found it in
the motd when I logged in the first time, and that too was nice.>>
Well I'm not involved with the documentation ;)
Yes, I do fiddle with src/ and have patches commited for me, but I'm
not a commiter and I'm definetly not -core :)
So I don't represent FreeBSD in any offical way.
<<- A more robust kernel than Linux. Much as we love it, Linux has a lot of
shortcomings both in source design and stability of things outside the box
for it. I don't know how well FreeBSD deals with these things, but I keep
running into roadblocks in Linux. For example, I found that there is a
limit to the number of file systems you can mount. When you have fourty
virtual domains and they all need an NFS mount, it's not too good on the
Linux kernel. I'm guessing from the fact that users can apparently mount
their own union fs's that this is dealt with much better in BSD. Another
set of limitations has to do with the default task limits and file limits.
I had to find the hard way that there are a max of 512 processes on a
Linux box by default, and a max of something like 1024 files. That's
absurd on a decent sized server. The files-max can be changed at runtime,
the processes max cannot. And even then the limit was 4090 (until 2.3
anyway). Adding features to Linux is also something that leaves something
to be desired unless you're a seasoned kernel hacker. Just at a cursory
glance at the FS's in the FreeBSD kernel, they look much cleaner.>>
Ok, I see why you like FreeBSD, thats great :) Doesn't mean much
to me on this side of the camp.. So let me keep reading.
<<- Features I need from the FreeBSD kernel -- unionfs, nullfs, and
portalfs. I'd really love to see a full-featured userfs appear in either
kernel at this point, but I'm not good enough to hack one in yet. My
experience with QNX/Neutrino has definitely spoiled me here =)>>
More of the above: Things good with FreeBSD :) I get the feeling that
the next entries will be things that I have to defend/fix :)
<<- The Debian package archive and FS structure. The earlier is easily dealt
with in a manner very similar to the FreeBSD ports system, but with the
latter I'm sure I'm asking for a holy war =). Then again, Debian/BSD is
supposed to be Debian ("not just a kernel") so that's probably what would
happen. But either way, given how Debian packages are fairly nicely setup
for source compilation, it ought to be easy to make a dpkg method that
grabs the source archive from the Debian tree, runs the make-package
command on it, and then provides that to dpkg. I haven't seen the
internals of dpkg though, so I may once again be putting my foot in my
mouth soon =)>>
The only issue that I know about with FreeBSD packages are conflicts
and lack of version handling (i.e. bash-1.1 and bash-2.0 look like two
entirely different packages to pkg_add)
This will be addressed in 5-CURRENT. If you have some immediate patches,
send them over :)
As FreeBSD rebuilds its packages quite often (we have several fast computers
to do that for us :) it isn't much of a hassle to change formats.
As a quick check with bento (package builder) shows, all of the packages
were rebuilt Jan 30, 4:00AM. That is what, 10 hours ago? :)
Where I'm getting with this is that flaws in the package format
are easily addressed. Just fiddle with bsd.port.mk to have it not use
pkg_create and instead use dpkg_create or whatever, and you can convert
all of the 3000 ports/packages from FreeBSD's format to Debian's.
Of course, that would be more of a hassle to do then fixing our format, but
you never know :)
Centralized package building allows for painless modifications to the package
format (Although people expect that the package format will remain somewhat
constant, so this is something that can only really be done with a .0 release,
and it didn't make it for 4-CURRENT)
<<- A nice Debian package for the BSD base system. I guess this would end up
including a kernel and the equivalent of the "bin" distribution, at least
at first. Maybe it could be broken up for finer tuned upgrading later, but
I know that's generally against recommendations =) >>
The problem with the current method of managing the base system with
cvsup/make world is? (There are binary upgrades available too, via
sysinstall, but they are less popular. I've heard only good things
Now, off to install mutt via pkg_add -r mutt :)
-Dan Papasian
<[EMAIL PROTECTED]>
