Skip site navigation (1)Skip section navigation (2)
Date:      Fri, 19 Apr 2002 01:43:51 +0200
From:      "Karsten W. Rohrbach" <karsten@rohrbach.de>
To:        Benjamin Krueger <benjamin@macguire.net>
Cc:        Jeff Palmer <scorpio@drkshdw.org>, freebsd-security@freebsd.org
Subject:   Re: FreeBSD Security Advisory FreeBSD-SA-02:21.tcpip
Message-ID:  <20020419014351.M60925@mail.webmonster.de>
In-Reply-To: <20020418154338.D23267@rain.macguire.net>; from benjamin@macguire.net on Thu, Apr 18, 2002 at 03:43:38PM -0700
References:  <4.3.2.7.2.20020417230144.032ad390@nospam.lariat.org> <200204171923.g3HJNga58899@freefall.freebsd.org> <4.3.2.7.2.20020418095356.024354c0@nospam.lariat.org> <012901c1e725$da237e90$0286a8c0@jeffrey> <20020418154338.D23267@rain.macguire.net>

next in thread | previous in thread | raw e-mail | index | archive | help

--L/bWm/e7/ricERqM
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

Benjamin Krueger(benjamin@macguire.net)@2002.04.18 15:43:38 +0000:
> Like it or not, Brett has raised a concern which is entirely valid and ec=
hoed
> by many system administrators. ( I have a feeling the number is not small=
 )

but you are missing the point that _administrators_ have the option (and
the knowledge) to upgrade from source, using a builder system, just like
most freebsd admins with larger installations do.

> FreeBSD currently does not enable easy maintainance between critical rele=
ase
> points for large server environments. Using cvsup to maintain source buil=
ds
> for environments like these ( say 400 servers or more ) is not only=20
> unacceptable without an on staff developer and release engineer, it is=20
> infeasible.=20

take your favourite spreadsheet and create a TCO estimate of
administration and maintenance of
- freebsd 4.x
- linux (your "favourite" distro)
- win32
including the points
- system setup
- first time installation of services
- customer education (for them to be able to use the system)
- maintaining system stability (sec updates, subsystem upgrades)
and all that in an automatic or semi-automatic manner with maint
contracts running 1 or 2 years.

at my previous employer we had 1000+ customer boxes out there, some with
maintenance contracts, and freebsd turned out to be the most performant,
most stable and cheapest solution. i would be delighted to see the
numbers you get under the bottom line for TCO of the three platforms.

> For those of you who would be quick to note that "Corporations with 400=
=20
> servers should be able to afford a developer and release engineer" please=
=20
> note that 400 NT, Solaris, AIX, or HP-UX servers can be maintained by a s=
mall=20
            ^^^^^^                                                        ^=
^^^^
> team of administrators, and do not require these extra resources. If you =
can=20
  ^^^^^^^^^^^^^^^^^^^^^^                     ^^^^^^^^^^^^^^^^^^^^^
so, money is not a resource at your site? freebsd is an os, _freely
available_, running on _darn cheap_ hardware. your comparison lacks a
bit of realism here, at least from the european point of view of the
software/hardware prices of the vendors mentioned above.
btw, i'd also like to have some of the stuff you smoke over there ;-)

> still convince them to go with FreeBSD despite the extra salaries and
> resources instead of the ease ( and insurance ) of buying a support contr=
act
> from the vendor, I commend you. Marketing is not my gig.
>=20
> Nobody expects a new system to replace the current and trustworthy cvsup
> method. By the same token, nobody expects The Project to support every
> possible hardware/software configuration out there. On the flip side, Fre=
eBSD
> is not like NetBSD or Linux in that we don't support 40 architectures, an=
d a
> few household appliances.=20

nevertheless, release engineering for RELENG_4_X (X!=3D5) turned out to be
pretty perfect for an opensource os, from my point of view.

> Currently, we have 2 major architectures spanning 3 processors. Intel and=
=20
> AMD processors on the PC, and Alpha. Sparc and IA64 may be considerations=
 in=20
> the future. For now, any patches or builds of this nature could very well=
 be=20
> limited to 3 supported base architectures. Typically, we have maybe 2 or 3
> critical releases of this nature per month. That comes to 3 builds three
> times a month, not a considerable strain, for the benefit of releasing=20
> patches that folks will use.
>=20
> I should like to note that this kind of system would be an excellent
> opportunity for a FreeBSD support company to pick up some slack that perh=
aps
> The Project doesn't have the resources to cover. It could potentially be a
> valuable service for customers and users alike.

i agree partly. from my experience in the freebsd community there are
quite some folks who _do_ release builds for internal use at their site.
it would rather be a coordination effort to get one or more publicly
available update releases available out there, if their employers would
spend the resources on doing this.

regards,
/k

--=20
> UNiX *IS* user friendly. It's just selective about who it's friends are.
KR433/KR11-RIPE -- WebMonster Community Founder -- nGENn GmbH Senior Techie
http://www.webmonster.de/ -- ftp://ftp.webmonster.de/ -- http://www.ngenn.n=
et/
GnuPG 0x2964BF46 2001-03-15 42F9 9FFF 50D4 2F38 DBEE  DF22 3340 4F4E 2964 B=
F46
My mail is GnuPG signed -- Unsigned ones are bogus -- http://www.gnupg.org/
Please do not remove my address from To: and Cc: fields in mailing lists. 1=
0x

--L/bWm/e7/ricERqM
Content-Type: application/pgp-signature
Content-Disposition: inline

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.6 (FreeBSD)
Comment: For info see http://www.gnupg.org

iD8DBQE8v1o3M0BPTilkv0YRAkU3AKCpxnKRnte3UjZqm175TfGA/v1lkACcDE98
Oq6dhNWKw6e97+2M8G7AaFc=
=jocT
-----END PGP SIGNATURE-----

--L/bWm/e7/ricERqM--

To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-security" in the body of the message




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20020419014351.M60925>