On Mon, Nov 05, 2007 at 09:11:22PM +0100, Christian Baer wrote:
> On Mon, 29 Oct 2007 17:26:50 -0400 Douglas A. Tutty wrote:
 
> 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?

Features and hardware support.  For example, my 486 has neither apm or
acpi yet all OSs have them in.  They all have drivers for hardware I
don't have; on debian that means lots of kernel modules filling up
/lib/modules/..., on OpenBSD that means a monlithic kernel taking up
ram.  Tell me why gcc keeps getting bigger and needing more resources.
I don't have a disk drive big enough for my 486 to allow any compiling
for anything.  Debian is set up for binary-only (you _can_ compile but
there are a lot of debian-specific hoops through which to jump).  

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

For a regular VT login: prompt to get to a shell (debian's bash or BSD's
ksh, sh, or csh).  For X, Debian doesn't have XFree3 (hasn't since 3.0
Woody, went to XFree4 for 3.1 Sarge, and Xorg for 4.0 Etch).  So yes,
I'm comparing XFree3 with X.org and Xorg takes 9 times longer to start;
I didn't try to compare rendering speeds for apps.  Xfree3 doesn't cause
the sytem to hit swap.  Xorg hits swap heavily right away before I start
any apps.  So any apps end up thrashing.

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

That's the joy, the problem so far is partially solved with NetBSD and
OpenBSD, except for X.  They both install and run within the system's
resources, I just can't compile on the box (unless I do things like add
drive space with NFS or something).  

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

And 3rd party kernel pieces that I don't have enough knowlege for to
unwravel.  I don't know about NetBSD's kernel.  OpenBSD's kernel is pure
and they list what 3rd party apps are in the base install.  I haven't
looked closely enough to see if they provide a "remove everything that
isn't totally free" script.

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

Note, I've been corrected off-list that the Base does have some 3rd
party GPL apps (e.g. lynx) in addition of course to gcc for which there
isn't, at the momemt, a totally free alternative.

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

Take a project leader with a particular personality type.  Give him a
vision of an OS that is different than any other out there.  Let that
vision clash with the "do whatever you have to to get it to work"
mentality in some other OSs.  Suround him with other like-minded people.
Pester the group with demands that their OS do this and that that
another OS do (here, take this GPL hack and put it in your kernel).  

You get two things:  snarky emails with no political corectness or
at times semblance of diplomacy; you also in this case get a great OS.

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

Some non-free stuff is included in the non-free debian repository (but
never on debian CDs) and multimedia stuff is in
www.debian-multimedia.org.  This also includes things like nVidia kernel
drivers pre-packaged for matching debian kernels.

But you see, you're cursing Debian for not doing what FreeBSD does.
Debian's stance is a lot like OpenBSDs but since it doesn't control the
kernel it can't see that they won't permit this or that in the kernel or
conversely that they will provide this or that.  They take the kernel
from kernel.org and add debian patches to it and remove anything that
they don't think meets debian policy.  However, things that are tightly
woven into the kernel are there.

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

There's the rub.  There is only gcc that is free in any sense.  There's
a great clamoring for a BSD/ISC compiler but it doesn't exist yet.

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

When all else fails, trust your gut.  

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

FreeBSD's target audience are large sites (e.g. yahoo! and the other
user's they boast about).  Sure others can and do use it.  Big places
like Yahoo have to pay for space and hydro for their servers.  In a data
center it pays to replace boxes with the latest and gratest because you
can do more with fewer boxes which means less power and less data-center
realestate.  In many ways, the same thing applies to Debian.  In both
cases, you get a push to support the latest hardware in the i386 and
amd64 arches.

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

That different machine would also have to be running the BSD.  The only
box I have that could compile is my Athlon64 and I don't want to get
into dual-booting or some such.  Besides, it would end up being a
cross-compile since I don't know how to tell a compiler running on an
Athlon64 3800+ with a Gig of ram that it needs to build for a 486DX4-100 with
32 MB of ram and make small binaries please.

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

When did that ever happen?  Perhaps if people are running Unstable (Sid)
or perhaps occasionally Testing (currently Lenny), but Stable (currently
Etch) has been stable since, well, Stable.  Using older package
management, you can get cruft buildup if you install and then remove a
package (the dependancies don't get removed), but with Aptitiude, it
takes care of everything.  

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

Non Spreken Doiche.  See, I don't speak German. :)  (the closest I get
is reading english translation of german philosophers).

> > OpenBSD packages put configs in /etc not /usr/pkg/PACKAGENAME/etc.
> 
> Is that good or bad?
> 

It depends.  Its a design choice.  If you're wanting to back up all your
configs before you do an upgrade its good because they're all together.
If you're wanting to remove a package manually (why?  pkg_?? should do
it), you have to remember to pull out of /etc...

I think its a good thing to have everything under /etc.

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


OK.  The kernel thing is a special case.  The OpenBSD folks believe that
the GENERIC kernel should work for everyone.  The only exceptions are if
you have ISA boards and the kernel isn't looking in the right place.
But you can modify your GENERIC kernel with config(8) without
recompiling to fix that.  If GENERIC doesn't work, its considered a
serious bug that they want to know about, they don't want you to just
recompile it to fix it.  They're also concerned about someone who
doesn't know the internals compiling a kernel that seems to work but
that now has some security problem.

They don't mind you discussing your kernel compiling woes, they just
don't want you using up their mailing list to do it.  Remember, the main
OpenBSD server is in Theo's home.

Here's my bottom line (not stopping discussion, just hit the EOF):

OpenBSD 4.2 is now out and for the first time the FTP sites include a
single 200 MB (or so) install.iso that contains all the installation
sets and boot images (if they're needed).  The OpenBSD FAQ is very good
and is in html right on the web site.  Read the FAQ while you download
the iso.  Try it.

Then try NetBSD.

On both, try adding a selection of your favorite binary packages.  If
you want, you can try installing source packages and compiling them.  

The setup between NetBSD and OpenBSD is very very similar.  Major
difference is that OpenBSD has an adduser app that you're supposed to
use (instead of NetBSD's useradd).

Try them out.  See which your particular hardware likes better.

Then consider any philosophical differences.

Then consider any legal differences (e.g. Cryptography, licenses, etc).  

Finally, consider security issues and updates.  Just as an example, a
while ago, OpenSSL had a couple of problems.  FreeBSD was the first with
a fix followed the next day by Debian.  OpenBSD took a week or two to
fix it and verify the fix (to ensure that they didn't just make things
worse).  Last I looked, NetBSD didn't have a notice of a fix yet; an
email query I sent to the list was replied that a fix had been applied
for the next version but a back-port wasn't available yet.  That was a
week after the OpenBSD patch was posted; a month after FreeBSD and
Debian had posted fixes.  I'm sure that this comes down to resources and
there's the tradeoff.

Doug.