response 25 of 80:

Sep 8 01:15 UTC 2006

Microsoft Windows 2003 Data Center isn't an option for Grex? *duck*

response 27 of 80:

Sep 8 15:40 UTC 2006

What about OpenSolaris? If not, why not?

response 29 of 80:

Sep 8 20:51 UTC 2006

Regarding #26; No, someone should do it.  By all means, go ahead.  If you make
someone scratch their head, that's a good thing.

Regarding #27; Becasue, frankly, no one is interested in OpenSolaris.

response 31 of 80:

Sep 9 05:40 UTC 2006

Grex is too insignificant for that.

response 33 of 80:

Sep 9 17:53 UTC 2006

i'm a party pooper

response 35 of 80:

Sep 12 01:04 UTC 2006

   So, I finally have extra free time to respond to this item.

   First, I'll agree that the two only real choices for Grex are
OpenBSD and FreeBSD.  I actually like FreeBSD, and its absolutely
the second best op system I know of.  Had OpenBSD not been around
I'm pretty sure that both Marcus and I would have advocated that.

   The comments Dan has made about the faults in OpenBSD are
interesting, so I'll comment on them:

 - Potential admins less familiar with it.  Thats true to a point,
but the biggest differences in maintaing the system are the lowest
level things, like disk management.  I'm not sure that counts for
much, because anyone who wants to be staff (or a system administrator
in general) should be versed in multiple OS's.

 - Differences between FreeBSD's and OpenBSD's ports system.  Yup,
thats right, and the changes in the ports system by Marc Espie has
been nothing short of incredible.  You can update a bunch of packages
now with really complete checking of dependencies, such that everything
is updated correctly.

   - Significantly fewer ports available.  In terms of raw numbers,
yes, OpenBSD trails, but I think the overall quality of them is very
good, and for Grex, most of what we have been using is already compiled.
The 4.0 package collection consists of 3600+ items for i386.  Are there
other things which Grex might benefit from having that aren't in the
tree right now? Sure!  But we can port them, and its a whole lot easier
to get stuff to OpenBSD than SunOS was becoming.  So not perfect but 
very good.

 - Deficient Java.  That is just flat out WRONG.  Kurt Miller has done
a great job of keeping Java 1.3, 1.4 and 1.5 working.  Java and OpenBSD
is an excellent combination.

 - A less stable system because of overall less testing.  Again, I think
that is just plain wrong.  A lot of testing goes on for OpenBSD by a lot
of people, and when you don't have hardware problems, OpenBSD is just
rock rock solid.  My main webserver at work will be seven years old in
a couple of months with zero problems, and less than 4 hours of downtime
in that period.  My own testing of OpenBSD, keeping more than 100 processes
running continuously for more than 3 months last year proved to be more
reliable than MSUs power. Are there bugs? Again, sure.

 - The engineering is less polished.   I'm not sure how to respond to that.
I certainly don't think it is, but I'l quite willing to talk of specifics.


   One of the reasons Marcus and I pushed for OpenBSD was to be in an
environment of trying to do things "right" over speed and flashy items
was important.  Security comes from a lot of things, but attention to
little details, like string manipulation is important and provides
benefits that aren't readily forseen, ie fixing problems just because
something was done in a bad way.  This means that various items in OpenBSD
aren't as advanced as in FreeBSD or others.  Dan's examples of 1, 2 and 3
are correct in that there is room for improvement.  I can't agree that
SMP support is "weak": I've seen multi processor systems and they
scream.  They'd scream even more with kernel threads, yes indeed.  Marcus
has bemoaned the lack of this for a long time. 6 starts to get into
areas where I can't comment that much on; I'm learning about more
kernel stuff.  Suffice it to say that I'll agree that there is room
for improvement.

response 37 of 80:

Sep 12 02:22 UTC 2006

 I believe what mic mostly means by "modern" is "good Java support."

response 39 of 80:

Sep 13 21:24 UTC 2006

It's the nature of grex that you can't easily see what you're responding to as
you respond.  So, I'll respond to Steve's posts in parts, so that I can
actually see what I'm replying to.

I'll first thank Steve for responding.  I always find these technical
discussions (really, they're more like debates) on grex fun.  But that's just
me....  However, I do find that his post reads more like an advertisement for
OpenBSD and less like a seriously thought out technical argument.  But more on
that as I go on.

The problems for potential administrators isn't just confined to low-level
interfaces; in fact, I find that the from the sysadmin point of view, the disk
structures are nearly the same (except that FreeBSD got rid of block I/O
devices a while back).  While it is indeed good for a sysadmin to be familiar
with more than one system, as I think I acknowledged when Jeff posted it, it's
also useful for a system to conform to standard interfaces to minimize
differences.  For instance, on grex, the BSD login.conf mechanism is used to
deal with grex's weird password hashing algorithm.  But this is different
from, say, the PAM system used on FreeBSD and almost every other Unix-like
system out there.  So administrators who want to deal with Grex's
authentication system have yet another - and in this case, not so trivial -
interface to master.  Is this bad?  Maybe not; but in a disaster, it might be
a real achilles heal.

OpenBSD's ports system is nice when it comes to the updating stuff, but I'll
say that (a) this is relatively recent (like, OpenBSD 3.6 or  3.7 or
something) and certainly wasn't a consideration when grex was switching to
OpenBSD several years ago.  However, lack of port coverage, or outdated ports
certainly was, and certain applications (like aspell) were ported to grex by
hand instead of using the ports collection.  Consequently, the process for
putting grex together required many manual steps that, on FreeBSD, could have
been automated.  Why expend precious staff time and energy porting
applications to OpenBSD when they're already ported to FreeBSD?  And the
OpenBSD 4.0 packages collection isn't particularly useful to look at, since
OpenBSD 4.0 hasn't been released yet (though, if I'm not mistaken, it should
be out soon).

If Java support is so good, why hasn't it been in the ports collection until
recently?  Users have asked for Java since this version of grex went online,
which has been over a year (i *think* nearly two now).  Attempts to install it
from ports haven't met with much success - because it hasn't been in ports.
Indeed, it's not in /usr/ports on grex right now.

And of course OpenBSD is less tested.  Quite simply, FreeBSD goes through more
cycles in a day than OpenBSD probably does in a week or maybe even a month.
That's just more testing, whether formal or not.  And experience with grex has
shown that OpenBSD is anything but "rock rock solid."  Indeed, the softupdates
related crashes weren't due to hardware by any accounts, and yet the system
crashed more than once from it (sometimes staying down for very long times
indeed).  Since moving to OpenBSD, we've seen several extended outages that
were not related to hardware bugs: this is not the hallmark of a reliable
operating system.  Now, it's true that grex could have benefited from more in
the way of server class hardware (and I never understood why, after all the
noise that was made by Marcus about ECC memory, non-parity memory was
purchased instead), but it's also impossible to deny that the software has
been unreliable at times.  Empirically, Steve's claim that the software is
reliable enough for grex have already been shown to be false - on grex itself.

As for the engineering being less polished, this is my sense rather than
something I can formally define.  My impression is that there's a small group
of individuals who guard the source base diligently.  They are quite "good" at
what they do in some senses, but leave out things like formalized process,
setting project milestones and tracking them, etc.  On the other hand, FreeBSD
actually has something resembling a process and a design guiding their
implementation.  OpenBSD is more, "hey, I thought this was cool, so I made it
happen...."  My experience is that that can work, but only to a point, and
after a while, you hit a critical mass point where the model breaks down and
you need to impose some sort of order onto the process.  OpenBSD just isn't
there.

With respect to SMP being deficient, I was specifically referring to the lack
of fine-grained locking in the kernel and the fact that most of the kernel can
only run on one processor at a time.  This inherently limits scalability in an
SMP setting.  This is what Steve refers to as, "kernel threads": a multi-
threaded kernel.  Unfortunately, problems in Unix's basic design are so
deep it requires massive effort to get a truly multithreaded kernel going
without starting from scratch.

Given the above, I fail to see how OpenBSD is doing things "right."  So they
audit their source base looking for string problems and using some sophmoric
routines they wrote to fix them: so does the FreeBSD team (indeed, members of
the FreeBSD team read the OpenBSD commit logs and track those changes, too,
applying them to their own source base!).  Some of the responses Steve makes
to my issues with OpenBSD weren't valid at the time OpenBSD was chosen for
grex, and have only recently become factors: ie, OpenBSD is only now catching
up.  Hmm.

Yes, OpenBSD leaves lots of room for improvement, but what's the point of
sticking it and waiting for them when FreeBSD already gives you all the
benefits today?  And why, *really* was it chosen over three years ago to
run grex?

response 41 of 80:

Sep 13 23:49 UTC 2006

   Why was it chosen?  In just a few words, paying attention to security
issues, starting with strcat().  I'm in a meeting right now. More later.

response 43 of 80:

Sep 14 03:43 UTC 2006

   Right, but where did they come from?  OpenBSD.  FreeBSD *does* do a whole
lot right.  I have said before and will say again that its a great operating
system, and absolutely the second best choice for Grex.  You might be surprised
to learn that I steered a friend from OpenBSD to FreeBSD, given the nature and
load of a web site being spec'd out.  But for Grex, I think--I know--that we
need every bit of help we can get.

   A comparison might be interesting, but there is more to things than
a numeric count.  I'm running out of time right now, sigh.  A lot of
the external things (sendmail, bind, openssl) are going to be very
similar, so I'll bet that the majority of interesting differences is
going to be kernel/library things in each os.

response 45 of 80:

Sep 14 11:44 UTC 2006

Regarding #43; You totally discount FreeBSD's own auditing efforts.  They
don't *just* "get it from OpenBSD."  And I'd say that their auditing effort
is roughly contemporaneous with OpenBSD's and has been going on for years.
They even audit many of their ported applications, and release security
advisories for insecure ports.  Can you point to any independently verifiable
data that says that OpenBSD is more secure (by any metric) than FreeBSD?  Or,
again, is this your intuition?  I'm not saying that intuition is bad, but
given OpenBSD's less than stellar track record on grex, I think some
justification beyond, "they do it better" (which has empirically been shown
to be false) is warranted.

response 47 of 80:

Sep 14 16:58 UTC 2006

Mic, how the in the world is OpenBSD "horrendously unreliable"?  We had 
hardware problems earlier.  NO OPERATING SYSTEM IS GOING TO WORK WELL WITH
BAD MEMORY.  Say whatever else you want about OpenBSD, but to so completely
misrepresent the stability problems we've had as endemic to the operating
system itself shows that you either don't understand the issues here, or
you are really blinded by your dislike of OpenBSD.

We've had crashes due to hardware problems, a failed disk, an obscure bug
in the soft dependency code and kern.maxproc not set high enough.  I still
can't reproduce the softdep bug myself, and that I know of no one else has,
else it would have very likely been in the OpenBSD bug tracking system.

Every OS needs to be tuned to some extent.  Now that we've done that we've
had uptimes of 72 days, and currently 42 days.

That is "horrendously unreliable"?  Give me a break.

response 49 of 80:

Sep 14 17:29 UTC 2006

  Re #45: I do not totally discount FreeBSD's auditng efforts.  I keep on
saying--and you don't seem to hear me--that FreeBSD is a very good operating
system, second only to OpenBSD.  I'm getting tired of having to say this.
If Grex magically appeared on a FreeBSD system in the next hour, it would
work.  I hope I'm getting through.  It's a matter of degrees.

   Crap, I'm out of time at the moment.