Subject: Re: changing to NetBSD, still not quite sure... :-/
To: None <netbsd-users@netbsd.org>
From: Christian Baer <christian.baer@uni-dortmund.de>
List: netbsd-users
Date: 11/05/2007 21:11:22
On Mon, 29 Oct 2007 17:26:50 -0400 Douglas A. Tutty wrote:

Ok, first of all, sorry for the long delay. I'm running behind on my mail
(and other stuff as well). The post I am replying to here is quite lengthy
and I wanted to have enough time to go through all of it in one go.

I certainly hope reading my reply will be worth it. :-)

>> That could be a problem if the connection between those two is just the
>> internet and the access you get in Germany doesn't typically allow much
>> more than ssh on a text basis.
> OK, put one application server near a few slow desktops; I don't know
> the ratio, but keep them on your ethernet.

I'm not too sure that can be done due to the spread of the things. But I
will keep your idea in mind!

>> > I haven't tried FreeBSD for one reason:  Debian works pretty well for my
>> > big box and the things I disagree with about Linux seem to be happening
>> > or have happend to FreeBSD.i
>> Would you care to elaborate on that?
>
> Debian (and any Linux now) and FreeBSD are both targeted at the same
> hardware:  fairly new i386 and amd64.  Well, Debian will also run on
> fairly new other arches but I don't have an S/390 in my basement.  The
> memory and disk requirements mean that I have to do a drive swap to put
> it on my 486 and even then it runs really slowly. The Debian Developers
> admit that they link to many libraries that I don't need to support
> corner situations out-of-the-box and that means that: 1) there is more
> stuff stuck in memory; and 2) that there are more instructions that have
> to be executed for everything I need to do.  

That is a problem about trade-offs. What is the drawback of saving
resources? Slower perfomance on faster systems? I doubt that. Or is that
done so as to not miss out on any feature? What ever happened to compiling
apps and kernel yourself and deactivating the things you don't need?

> So, for example, on the 486 at login, it takes 30 seconds of 100% CPU
> utilization to get to a command line.  X takes 3 minutes to start.  
> On OpenBSD with X version 3, it takes about 20 seconds.

Is this the comparison between Debian and OpenBSD? Are both versions of X the
same or did you compare XFree3 with X.org 7?

> My understanding of the philosophical direction of FreeBSD is that they
> are also ensuring that those corner situations are covered which means
> that I couldn't get FreeBSD to install on my 486 (ran out of drive space
> during install); I don't know how well it would run once installed.

What corner situations are you referring to and why shouldn't it be
possible to solve the problems with OpenBSD or NetBSD?
 
> This is another philosophical difference to which I'm sensitive.
> FreeBSD is all about ensuring that things work (on new hardware) so that
> if a piece of hardware will only work with a windows driver, they'll
> find a way to make the windows driver work.  I don't want a windows
> driver on my box.  I also have a problem with a mix-licence kernel.  It
> doesn't apply to my current situation but if they're willing to play
> mix-n-match then how can I trust that I can do what I'm doing with the
> box without reading the licences in the source tree. 

You can't. It didn't apply to me (yet) but I have also noticed that
FreeBSD has deviated from its former mission, to create an OS that anyone
can use for anything - no strings attached. These strings are being woven
into the system in the form of 3rd party software with different licences.

Ok, it does make things work that may not work (to their full potential)
otherwise, but in the long run, I'm not too sure this road is really a
good idea.

> Both Debian and OpenBSD are very very particular about what licences
> they will allow into their main distro.  For OpenBSD its the BSD licence
> only.  For Debian, its any free licence that meets their policy: BSD,
> GPLv2 and a couple of others (but not, e.g., GPLv3 with invariant
> sections).

OpenBSD isn't only particular, I think the word militant comes to mind -
not only about licences though. This rather militant attitude is what made
me not consider OpenBSD for my project, although the functions and
features of OpenBSD are impressive.

I remember cursing Debian a few years back because of the restrictions to
what licences they allowed because I needed to get an AVM B1 to run and
hat no other way to connect to the internet. The B1's firmware was not GPL
and therefore not on the Debian discs. I had to go for a drive to get the
firmware from a friend. My suggestion to include software with different
licences, in order to get it to work on a seperate CD was never adopted.
This would be one way to get the most of the two worlds: A completely free
system but also non-free software where needed. Because of the seperate CD
there could never be a mixup about how free the system really is.

Speaking of free: What compilers does OpenBSD currently come with?

> The other issue is the drive to add more features vs the drive to ensure
> that the features that are included are as bug-free as possible.  I.e.
> quality vs quantity.  With Linux (not debian-specific) the drive seems
> to be toward more quantity and away from quality.  Specific example is
> the udev system that has to be used with the kernels now; many people
> are having lots of problems with it but on the other hand it makes
> hardware discovery more like Windows and many people think that this is
> a good thing.  That some find their ethernet card keeps getting
> renumbered is a pain, especially for people who's only access to the box
> is via ssh.

I can't really put my finger on it but I have the same feeling as you.
It's not something I can prove with numbers or with facts that I
collected, it's more of a gut-feeling. Don't start hating my guts because
of that. :-)

I first looked at FreeBSD at the end of the 3-era. When FreeBSD 4.0 came
out and Greg Lehey updated his book, I bought that. "His" main advantage
of FreeBSD over Linux was that Linux was still (and always) "bleeding
edge", while FreeBSD was aimed at being stable and clean. I liked this
concept and soon my machines changed from Linux to FreeBSD. Ok, I liked
other things about FreeBSD too, like the fact, that it wasn't just a
kernel with the other apps stuffed in there by the distributor. But the
"stable and clean" aspect really looked good for me, because I had made
the mistake of adopting the 2.2.x Linux kernel pretty early.

Today, I still have two of my boxes running FreeBSD 4. They still work and
do what I need. Ok, FreeBSD 4 lacks some of the new features, but it was
as really rock solid as the website promised.

Now I have the feeling that FreeBSD is just about as "bleeding edge" as
Linux is and somehow there is a hype about it. Ok, I don't mind the hype
that much - as long it doesn't influence the system itself.

> I can't really speak specifically against FreeBSD since I haven't
> sacrificed my big Athlon64 box to it to test since that would mean
> pulling it out of production without a replacement. None of my other
> boxes are capable of testing it properly.

Works fine on my amd64 and sparc64 - apart from the problems mentioned in
this thread. But is has grown quite a bit since 4. I'm going to have to
reinstall an OS on that machine pretty soon anyway because the hard drive
gave up a few days ago. :-/ So I might as well give NetBSD a try.

> Feature-wise, FreeBSD seems to have everything.  Vinum looks impressive
> as long as it really works.

Yeah, there were some issues about that. I read a few complaints but never
used Vinum (or GVinum) myself, so I can't really say anything about that.

> At the moment (i.e. this week), I have one box on NetBSD (486) since the
> drive is small.  I'm not using X on it; its a glorified thin client
> (text only) via ssh.  It was installing on this box that I discovered
> the difficutly with installing packages over an unreliable phone
> connection.  If I need X on the 486 things get interesting with its
> S3Vision864 with sdac video.  It needs a version 3 xfree86 to work well;
> Xorg works less well.  OpenBSD comes with the version 3 drivers _and_
> Xorg in the base install so I can get X without adding any additional
> packages.  I understand that to do that on NetBSD I have to install from
> pkgsrc.  Since that means I have to work out the dependancies and
> dowload the tarballs one at a time manually (due to needing to
> interrupt the phone), its a major headache.

Depends. :-)

You could always compile the stuff you need on a different machine.

> None of my very old boxes have a hard drive big enough to compile
> anything so they can't be kept up-to-date (unless I got into NFS).
> Since they're behind two firewalls I'm not concerned about them.  There
> are no functional bugs that need fixing.  If they will run Debian,
> updates are simple and easy.

Although I have read of people who were not to happy about the Debian
updates because they left out some dependancies and thus left the system
unstable or completely broken. I haven't had much contact with Debian in
years so I can't say anthing about that myself either.

> Then again, I have a book in front of me about OpenBSD (Absolute
> OpenBSD); I couldn't find a book on NetBSD. 

There is one book in German but that's a little outdated: 1.6. :-)

> OpenBSD packages put configs in /etc not /usr/pkg/PACKAGENAME/etc.

Is that good or bad?

> Quality wise (from a user's perspecive) they seem the same.  Performance
> wise they seem the same (i.e. no problem at all).

Yeah, I kinda expected that.

> OTOH, the NetBSD mailing list is a lot more comfortable than the OpenBSD
> list.

That was one of the main reasons for not wanting to use OpenBSD. You can
already get a good impression about what the mailing lists are about by
looking at the OpenBSD documentation: How to configure and compile a
kernel. It's ok that the developers say they won't help with a custom
kernel, although making this a rule seems more like nit picking than
anything else. But telling the user he will make a dick of himself if he
breaks his system with a custom kernel seems to be going a few miles too
far. Being open also means open to new ideas and open to letting the user
keep his freedom. It's ok to say that anything non-standard cannot be
supported (due to limited resources) but inviting others to laugh a
someone who tried something and is now looking for help isn't what I call
freedom. Damn, I crashed a few kernels in my time - mainly because I just
forgot something. I managed to recover from all of those crashes (somehow)
but I don't see any problem in people discussing their experiments on the
mailing lists.

Regards
Chris