Skip site navigation (1)Skip section navigation (2)
Date:      Wed, 02 Apr 2003 14:56:17 -0800
From:      Terry Lambert <tlambert2@mindspring.com>
To:        John Baldwin <jhb@FreeBSD.org>
Cc:        freebsd-current@freebsd.org
Subject:   Re: Removing Sendmail
Message-ID:  <3E8B6A91.821EBA6B@mindspring.com>
References:  <XFMail.20030402142930.jhb@FreeBSD.org>

next in thread | previous in thread | raw e-mail | index | archive | help
John Baldwin wrote:
> On 02-Apr-2003 Jens Rehsack wrote:
> > I really think splitting the base in some sub-parts would it make much
> > easier to do NO_SENDMAIL on my own. So I had to remove each not required
> > file separately. That's no good solution.
> 
>  [stepping back a bit ]
> 
> I find an odd situation here whenever this topic comes up.  One the
> one hand, people are always wanting to split the entire base system
> up into small packages for each little piece of the base.  On the
> other hand, one of FreeBSD's selling points in real-world environments
> is that it doesn't have a bunch of little packages for the base system
> like Linux distros.  Do people really prefer something like having
> rpm's for /bin/ps to having one lump base dist for all of /bin, /sbin,
> etc.?


I don't think so.

I think people just want to get to the same place with layered
software that VAX/VMS and VAX/Ultrix achieved back in 1985 or so.

In other words, we want to get to the point where, when people
complain about some base system component, we can tell them:

1.	pkg_delete FOO
2.	pkg_add FEE
3.	Go away

Works for Sendmail vs. Postfix, works for TenDRA vs. Gcc, etc.;
also lets you tell people to "Go away" if they install non-default
components, since they are not "Tested configurations".

The important part is that we are tired of revisiting this same
ground, over and over, every time there's a CERT advisory against
a "default" component, particularly when we just *replaced* it
with some other functionally similar former default component
because of a CERT advisory.

And we are tired of CERT advisories listing FreeBSD as vulnerable,
instead of blaming the third party software, because we install
the third party software by default (I think that was the original
motiviation for the delete request this time... and last time).

Or to recap, the issues, IMO, always boil down to:

1)	Technical support load shedding
2)	Disconnecting politics from process
3)	Advocacy

-- Terry



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?3E8B6A91.821EBA6B>