response 51 of 80:

Sep 14 17:43 UTC 2006

Regarding #49; That's an opinion that you posit as fact, and then ignore the
parity between their ongoing security efforts when you make statements to
support your opinion.  I'm refuting that, and asking you to give me a
substantive argument that justifies your opinion.  Repeating, "FreeBSD is very
good, but not as good as OpenBSD..." over and over again will not convince
me.  This is not the Bush administration, after all....  :-)

response 53 of 80:

Sep 14 19:44 UTC 2006

Heh.

response 55 of 80:

Sep 14 20:51 UTC 2006

With all due respect, STeve, if someone reminds you more than a few times 
(and is promised that he will get it in a short period more than a few 
times, and never got it) they just give up and do it for themselves 
because of a lack of respect.

When I do stuff, like programming, build scripts etc through my work -- 
I always document as I'm doing the activity.  Any responsible IT 
professional does this - if not, they are hardly worthy of being in a 
team in my opinion.  

response 57 of 80:

Sep 14 20:58 UTC 2006

And making use of it without documentation is considered to be statutory reap.

response 59 of 80:

Sep 14 22:08 UTC 2006

Regarding #54; I never said FreeBSD was perfect.  But I am implying that these
things are more mature on that platform.  Part of that is that it has a larger
user base, so snarky problems (that are difficult to reproduce, like grex's
issues with the softupdates code) get exposed more rapidly - and thus fixed.
Further, since more businesses depend on FreeBSD, there are more loud voices
(and willing eyes) joining the chorus to have these problems fixed.  But
that's what you get when you have a more mature and larger installed base in a
server oriented system.  Linux could have this, too, had they not adopted the
hacker of the month model for development (I remain largely unconvinced that
Eric Raymond's "bazaar" model really works beyond a certain threshold of
complexity and size).

Regarding #58; Two years is quite a transition period.  But then, had we run a
system that more sysadmin types were familiar with, would it have taken two
years?  And that's part of my point.  Perhaps the *worst* problem we had was
the memory problem, but it certainly wasn't the *only* one, and that it has
taken two years to get to the point where problems with the systems software
have been masked speaks to the unsuitability of that software for the task at
hand.  I earnestly believe that we could have done better.  Whether that is
true or not, the data shows that we didn't do all that well (at the least,
grex should have gotten ECC memory - about which all the stink was made).

I'm not sure how being better about upgrades would put us in a better position
with respect to Java.  On *my* OpenBSD system - running the latest stable code
(that is, 3.9-stable from about two weeks ago), Java doesn't exist in the
ports collection, either.  Surely you aren't suggest that we run the
unsupported, unstable developer -current tree, which is what OpenBSD 4.0 will
be forked from once it stabilizes?  This cannot be what you mean by, "being
better about upgrades."  What's more, I cannot find credible your (implied)
claim that Java support on OpenBSD will be as mature as on FreeBSD once
OpenBSD 4.0 is released: Java has run on FreeBSD for years.  It is quite new
on OpenBSD, and simply cannot be as well tested.

What's more, as you know, many Java programs rely heavily on threading for
concurrency.  The Java threading implementation, in turn, exists on top of the
POSIX threads suite.  That suite under OpenBSD exists entirely in a user-land
library, with no support for thread concurrency from the kernel.  This means
that, if a process should call some sort of blocking system call, every thread
running in that process will hang until the operating system returns from that
system call.  On FreeBSD, threads are (if I'm reading the man pages right)
scheduled by the kernel (they also have a user-level threads library - great
for applications that do lots of thread switching with little chance of
blocking).

Having programmed in Java, I can say that I don't care for their threading
model: it's an architectural throwback to the 1960's, critical section
protected, cooperative coroutine model that's too low level and not as
expressive as, say, CSP-based concurrency systems.  But, the fact is that Java
threading just won't work as well on OpenBSD.

As for the logger problem, OpenBSD touts itself as "secure out of the box" and
takes a stance of not really trusting the local user.  Why, then, not protect
the system logger, which could be used for a denial of service attack, at the
very least?  But I see your point that it's a policy issue rather than an
actual software flaw (I'd say it's more of a configuration issue).  MY point
is that we chose this system for security, and then failed to adequately
secure it.  No system, no matter how good or bad its security, is going to
remain secure if its configured insecurely (how's that for a tautalogical
statement?).  Since we didn't properly secure grex on OpenBSD, what then, was
the point of choosing OpenBSD based on its security record?  I'm just not sure
I buy the security argument, and I remain unconvinced.

Steve, if there are specific points on which OpenBSD does demonstrably better
than FreeBSD (with respect to security or anything else), I'd really like to
hear them.  So far, all I've heard is impressions and opinions, with little
recourse to facts of measurable data.  While those things are fine for
starting to form an opinion, major decisions should not be based on them, and
opinions and intuitions should be subject to change based on observed
behavior.  In the absense of sound technical argument in favor of OpenBSD, I
simply don't see how the decision to go with that operating system can be
objectively justified.

With respect to Java, I specifically remember Mic asking for it when the
discussions of what operating system to go with post SunOS 4 were being held.
Item 123 in the old Garage conference has postings from October, 2003 where
it's mentioned.

And for the record, lest it be said otherwise: I'm not "against" OpenBSD.  I
run it on several of my own systems.  But I really want to understand why it's
appropriate for grex, and I really don't understand that and don't believe
that it is.

response 61 of 80:

Sep 15 00:01 UTC 2006

I'm not talking about the package collection, I'm talking about the ports
collection.  The former is pre-built packages, the latter are built from
source (and he mechanism by which the former are created).  The threading
issue isn't just about speed, it's also about reliability and expected
behavior: if I have an application that utilizes n threads, and I expect that
n - 1 of them will ccontinue running even if 1 of them blocks on a system
call, and then I try to run it on OpenBSD and it doesn't work right, I won't
be happy (particularly if the Java spec or something says that it should keep
running).  Surely things like this *are* cause for concern?

The problem with the logger had nothing to do with syslog.conf, it had to do
with the fact that people could write to the log socket.  It could be masked
by judicious tweaking of syslog.conf (which, you are right, surely should be
modified to be brought into accord with local system policies), but that's
just treating the symptom, not the disease.  Personally, I don't think that
ordinary users should be able to write to the logging socket *by default*:
If I want to enable it, that's another matter.  And I would further suggest
that it *is* a systems security issue in that it can be used as the basis for
a denial of service attack.  Random junk spewed into the logs can also mask
actual system attacks, and greatly reduce the value of information in log
files.  If the system log rotation policy favors size over time when deciding
to rotate a file, real information may be lost.

Perhaps FreeBSD wouldn't magically have fixed all of grex's problems, but
we'll never know since we didn't try it.  I submit that several of the
problems we experienced with OpenBSD wouldn't have shown up, and if they had,
there would have been a larger user community to draw from to get them sorted
out.  As it is, we still have OS related problems: Grex isn't configured to
support enough terminal devices for the number of users who want to use it.
No one seems to have figured out how to get OpenBSD to allow more.  Hmm.

I think that it's telling that Jan Wolter, who did the majority of work in
getting grex running under OpenBSD, ended up not liking it very much that
experience.  See, for instance, item 170 in the old garage conference.

response 63 of 80:

Sep 15 01:55 UTC 2006

I think Grex needs less local staff considering the pool of volunteers is
likely to come from abroad.  Spooked and cross are on opposite sides of the
planet but are well equipped to patch and lock down FreeBSD.

response 65 of 80:

Sep 15 13:22 UTC 2006

Given that the pool of local volunteers is approaching 0, the chances of
finding volunteers from other places seems to be more likely each year.

response 67 of 80:

Sep 15 18:09 UTC 2006

re #66
Silly man.  Abroad=anywhere outside the Planet of Ann Arbor (aka perpetual
high school mentality land)

response 69 of 80:

Sep 16 20:45 UTC 2006

Mine too.

response 71 of 80:

Sep 30 13:56 UTC 2006

Err, that was why I made the correction...?  How does this address my other
points?

response 73 of 80:

Jan 7 16:16 UTC 2013

People talk about security in the abstract when discussing projects like
 OpenBSD without asking the two critical questions:

    1) what resource or value are you trying to secure?
    2) What threat are you trying to secure it against?

If Cyberspace Communications BOD is interested in, for example, 
protecting availability of the forum and the near-real-time chat-room, 
there are radically different concerns than if they were interested in 
protecting the confidentiality of messages, either at-rest or in-flight.
 Does the BOD give guidance on what to protect, and from whom? Without 
answering those two simple questions, discussion about security is at 
best supposition and partisan shouting.  -DTK