On Mon, Oct 29, 2007 at 04:08:58PM +0100, Christian Baer wrote:
> On Sun, 28 Oct 2007 21:47:20 -0400 Douglas A. Tutty wrote:
 
> > It also depends on how many desktops you're talking about.  If there are
> > more than a couple, it would make sense to have one OS for all desktops,
> > even if it meant running a particular application on an application
> > server via ssh if it won't run on the desktop hardware/OS directly.
> 
> 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.

> 
> > It also comes down to your own piddly details.  For example, I'm on slow
> > dialup.  All things being equal, Debian's aptitude is the easiest to
> > keep up-to-date since it handles interruptions (need the phone line)
> > very gracefully and will resume.  I have a 486 that won't run debian but
> > OpenBSD's pkg_add will also resume, however a minimal OpenBSD is a bit
> > bigger than NetBSD so it depends on what hard drive I put in the 486.
> 
> I have to admit, that OpenBSD wasn't taken into consideration.
> 
> > 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.  

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.

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.

> 
> > OTOH, my big Athlon64 box has an nVidia video card and OpenBSD doesn't
> > do binary blob drivers. I don't like binary blob drivers but I like the
> > fine detail when watching a DVD so I need it.
> 

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.  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).

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 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.

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

> Does that mean, you don't actually use NetBSD but instead OpenBSD?

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.

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.

For the uses to which I put my old boxes, once things are installed,
there is no difference between NetBSD and OpenBSD in day-to-day use.  I
find OpenBSD a bit easier to set up.  Partly, its a philosophical
difference in the design:  NetBSD is designed so that tweaking (custom
compiling) is, while not manditory, quite common.  Therefore, pkgsrc is
a lot about installing the source and compiling it and it includes a way
to install a pkg if you like.  OpenBSD is designed so that tweaking is
discouraged.  The only time compiling is recomended is when a security
patch tells you to, or you can't get a kernel to work (but then they
want to know about it since GENERIC should work even if you need to
Config(8) it a bit).

Then again, I have a book in front of me about OpenBSD (Absolute
OpenBSD); I couldn't find a book on NetBSD.  Both have good FAQ books on
their web sites.  Both have good man pages (although OpenBSD seems to
have a man page for absolutly everything).  OpenBSD packages put configs
in /etc not /usr/pkg/PACKAGENAME/etc.

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

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

Doug.