On Thu, 5 Oct 2000, Bruce McCulley wrote:
> The only reason for installing any OS is to run some set of packages.

  This is my point.  I'm not saying OpenBSD doesn't have a better security
policy; they do.  I'm saying their claims of "no remote exploits" are highly
misleading, because their configuration for this claim is effectively the same
as a box with the power off.  Assuming one actually *uses* their OpenBSD box,
the number is not zero.  I think OpenBSD has enough true advantages that they
don't have to lie about it.

> first, there are fewer inherent vulnerabilities in the platform;

  I dislike this statement.  It is too vague, and impractical to prove.  Say,
instead: Their overall design approach lends itself to better security.

> second, you get to choose your poison rather than getting everything
> installed and enabled by default (viz RedHat).

  While Red Hat does install an awful lot of packages in their "ready made"
install profiles, you can quite easily unselect packages such that only the
services you need are installed.  Furthermore, they provide a nice,
centralized management interface to all services, such that you can easily
control what is started, or not.  So, while I think their default stance could
definitely use improvement, it is not as bad as you make it out to be.

> And yes, a shoe box is better.  For some applications.  Ever tried storing
> shoes in a mini-tower system? :-)

  Actually, I *have*, but only because at one point I had several empty PC
cases in my bed room and it was a convenient spot.  I suspect I'm in the
minority.  :-)

On Thu, 5 Oct 2000, Derek Martin wrote:
> Their distribution is geared more towards enterprise support, so the focus
> of their various install options is on giving you most of what you need
> for a particular purpose, without a lot of fuss.  This speeds up the
> install process, which is a welcome feature for most admins.

  I'm not so sure I agree with this entirely.  Even if Red Hat is targeting
mainly "enterprise customers", that does not mean they should leave everyone
else out in the cold.  More importantly, I think they could pick a safer
default stance in some cases.  Specifically, they don't make use of chroot
jails when they could and/or should, and if you install a package, it is
automatically enabled.  I'm aware of the argument "If you don't want it
enabled, you should not install it".  I don't buy that; I may want something
installed so I can enable it later; In the mean time, I have to spend time to
secure the system.  It may only be five minutes, but still.  Meanwhile,
services in their default configuration are almost never useful; you need to
put some data in them first.  Part of that process can be to enable the
service.

>  A fast install and ease of administration is more valuable to a great
> many administrators...

  I don't think a secure by default stance is necessarily harder to
administer.  Turning features on or off should not be hard.  If it is hard,
then securing the box will be hard, and I would rather security be easy.

> And yes, RedHat does release buggy software, but they're also usually
> pretty good about fixing it.

  Okay, who are you, and what have you done with Derek?  ;-)

> Would I like to see a "base install" option?  Yeah, I would.

  AOL!  Especially when installing onto a bitty box that is short on hard
drive space.  Hmmmm, how about this as an idea:  Give packages "Priorities",
so that the installer can make reasonably intelligent guesses as to what can
be dropped and what must be kept.  For example, "ls" is more important then
"gcc", but "gcc" is more important then "xboing".

-- 
Ben Scott <[EMAIL PROTECTED]>
| "Sure, 90% of science fiction is crud.  That's because 90% of everything |
|  is crud."              --  Theodore Sturgeon                            |


**********************************************************
To unsubscribe from this list, send mail to
[EMAIL PROTECTED] with the following text in the
*body* (*not* the subject line) of the letter:
unsubscribe gnhlug
**********************************************************

Reply via email to