On Mon, 5 Nov 2007 16:50:35 -0500 Douglas A. Tutty wrote:

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

I guess people are forgetting these slower machines. When I started out
with Linux, building your own kernel war almost mandatory. The amount of
RAM an average computer had back then (8megs were considered absolutely
high-end) would have been pretty much filled with the kernel alone. The
kernel on one of my older machines still running FreeBSD 4 is a little
over 2MB in size - and this is a custom kernel, where I threw everything
out I didn't need, including (for example) IDE discs! The generic kernel
is almost twice as big. Granted, FreeBSD 4 is passed the time I am talking
about here but I still don't see running it on one of these old babes.

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

Compiling has always been something that requires a lot of drive space -
especially if you want to compile a whole OS. :-) The the amount of
hardware out there is getting bigger and the machines are always getting
faster, I don't really see that changing at all. It is however possible
that better mechanisms will be created to allow easy updating of a slow
system with the help of a fast one.

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

Most of these 3rd party apps are GPL, so if you don't modify them, you can
use them pretty much als you like too.

> Take a project leader with a particular personality type. 

Very delicately put. :-)

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

I'm one of these people who have often missed something in my OS, but at
the same time I am rather more quiet about it. In the 90s I was using a
number of SCSI-Controllers from Buslogic (later taken over by Mylex). I
considered these controllers to be amoung the best there were at the time
because of their stability, performance and the great BIOS setup which was
IMHO second to none (not even Adaptec). The problem was that these
controllers were never supported by FreeBSD. I can code myself, including
in C or C++, but porting a driver from Linux to FreeBSD would have been a
major task, especially when I knew that Mylex wasn't going to continue the
Series I had. Now I have quite a few BT-930, 950 and even 952 lying
around. Ok, they are completely out-dated now (UW only, no LVD), but they
were quite useful at the time. Having to use Linux on any box with one of
these babies was a major pain because that meant I had another OS to
administrate and watch over (and I never really trusted ext2).

So I understand people who want to add a certain functionality to their
OS. I just don't complain as much because I know they are doing their work
for free and I have no right to demand anything. Just the same, I know how
frustrating it can be if "my" OS just won't run certain hardware I would
like to use (like my webcam) while the Windows people can use just about
any hardware they like without any trouble finding drivers - even for
hardware that is sometimes completely outdated.

> 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'm not sure if the things you listed will *always* result in a great
operating system. I suppose they could actually also result in a war. :-)
But in this case you are right. OpenBSD is a very secure and usable OS,
which doesn't mean that I have to agree with the militant attitude though.
I have to put up with quite a few complete losers who all think they are
computer experts but are really to dumb to pee a hole in the snow. You
won't find me hitting them in the face with that. I *know* how thick they
really are but I keep that to myself. BTW. None of them read this mailing
list - I hope. :-)

What I am trying to say is that you don't really need a militant leader
and staff for a good OS. This may be a side-effect of OpenBSD but I think
neither is a direct result of the other.

> But you see, you're cursing Debian for not doing what FreeBSD does.

No! You got that wrong!

The choice is not only between completely free and non-free, as in
"Software with non-free licences is woven into random parts of the
system". There is also a middle-way of seperating the free and non-free
parts of the system.

I was cursing Debian because the hardware list contained my AVM B1 (that's
an ISDN card) and indeed the drivers were all there. The thing that wasn't
was the card's BIOS, which is uploaded with every start. The BIOS wasn't
(and probably still isn't) free. The manual told me to download that via
the internet, which is quite a drag if you have no connection because your
ISDN card won't work without its BIOS. This was all in a time pre
broadband, so the ISDN was my only way to connect to the internet.

I guess I was mainly cursing Debian for lacking this information. Today, *I*
wouldn't need that information but I still don't think it's ok if anyone
else who doesn't have my knowledge has to find out the same way I did.

The middle way could be (as I had suggested) to put the non-free stuff on
a seperate disc. This way everyone who installs from the discs knows what
he or she is getting into.

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

That's all ok with me. Even if that could be a problem for someone who
doesn't know the licences.

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

There is pcc, but that isn't anywhere near the gcc yet, especially in
respect to all the languages/dialects and plattforms that gcc supports.
I'm not sure that this is really such a rub though. gcc is gpl, sure, but
if someone creates a closed source product based on OpenBSD, he or she
probably won't inlcude the gcc anyway. Where there is no source, there is
no compiler needed. :-)

>> 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'm pretty sure this isn't the right way to make choices of this kind. :-)

> 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 should believe that both Open- as NetBSD will do just as well on
high-end AMD64 hardware as FreeBSD will - provided you don't have more
than one CPU. SMP is an area where FreeBSD is far ahead of the other two
BSDs. I have read about a major effort being started to change that on
NetBSD - which is a very good idea since all new CPUs get there speed by
actually being more that one CPU on the same die. It won't take long
before we have 8 CPUs in one AMD64 or Intel Core2. SparcT1 is already
there.

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

Hmm, I know the compiler settings but I haven't done that either (yet), so
I can't help you at present. :-)
  
>> 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.  

I can't tell you when it happened. I just remember reading about it.
Probably in some newsgroup. I only used Debian for a rather short time and
that was over when I read this note, so I never got into much detail
there. I don't think it's worth investigating right now, so I won't. :-)
 
>> 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).

Yes, I can see you don't speak German. :-) As long a you keep you English
up, we should be able to communicate though. :-)

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

None those two things seems to be bad. It probably doesn't make any
difference once the app is up and running. So from that point of view it's
neutral. :-) But at least it's consistant. FreeBSD put that configs for
apps under /usr/local/etc. Some apps (like Postfix) have their own
directory, some don't. Being consistant may be good in itself, but it may
also be useless. A single configuration file in it's own directory doesn't
really help anyone.

There is one directoy that I have been shouting for for years now: ~/.etc
or something like that. Putting all configuration files in ~ makes a home
directory look pretty messy after a while. I know I could set that up
myself (and in many cases I did) but I'm still looking for other people
who think that's a good idea too.

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

Why?

FreeBSD has only the system-stuff in there. Configs of all apps don't have
to be on the same partition as /. They won't run without /usr anyway. And
/etc could become pretty big with time. :-)

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

Valid point. To me the desire to create a custom and thus maybe smaller
kernel for old hardware is also valid. But I guess I could live with both
because noone will actually stop me making my own kernel if I think I need
it. :-)

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

Well, mailing lists don't use up that much bandwith. I know because I
serve a few of those on my home line. :-) But ok, there is no right to a
certain subject and if they don't want it on their own mailing lists,
maybe someone will start a thread on another one.

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

Bin there, done that. :-)

> Then try NetBSD.

Done that too. :-)

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

In handling I couldn't find any differences off hand. The shells were
different but that can be changed if needed. There was no difference I
could make out performance-wise.

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

The cryptography is a very important part for me. With FreeBSD I am using
geli(8) to some extent. NetBSD's cgd seems to be very similar in design,
even if there are some differences in the handling and a few concepts
(metadata is stored in a file by cgd while geli stores it on the provider
that is being encrypted). OpenBSD's vnd seems to be completely different.
It doesn't encrypt partitions but "containers" (files which contain file
systems). I'm not sure I like the concept of that because performance can
be bad if the file system in the container tries to optimize reading and
writing for a hard disc of the size of the container. The next thing I
noticed that vnd (or rather svnd) only supports blowfish-cbc which is not
trusted for large file systems. Truecrypt only supports blowfish in
LRW-mode, but won't even let the user create new volumes of this type
because even in LRW-mode the developers consider blowfish to be too
insecure (compared with AES, Twofish and Serpant).

On the upside, OpenBSD does support several types of cryptographic
hardware, while NetBSD doesn't support any (that I can find).

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

Yeah, I watched this issue quite closely because I have to webservers to
maintain that heavily use OpenSSL. Both run Linux though because the ISP
set them up that way. I was more than surprised that NetBSD hasn't fixed
that hole yet. Especially those people running production systems don't
like updating the (complete) system just for a security patch. So normally
I would expect a patch to be there even for older systems.

Is this something that happens a lot (NetBSD is the last to close a
security hole)?

Regards
Chris