Debian Enterprise (not a Starfleet metaphor)

[Karsten M. Self]

--82I3+IH0IqGh5yIs
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

on Wed, Dec 17, 2003 at 02:03:47AM -0800, Rick Moen (rick@linuxmafia.com) w=
rote:
> Quoting Karsten Self (kmself@ix.netcom.com):
>=20
> > I'm working on a pitch, part of which addresses the "you get what you
> > pay for" objection to GNU/Linux (or Debian).=20
>=20
> Honestly, when you encounter the (very common) cultural assumption of
> valuing things solely at acquisition cost, the best counter-measure by
> far is, quite simply, to charge a lot of money.  Don't sell Debian as an
> invoice line item -- sell (e.g.) a corporate e-mail solution.

In the context of a cash-strapped school district, illuminating
breakdown of costs, benefits, and (for the lemmings) existing users of a
product may be of benefit.

My (limited) experience in demonstrating GNU/Linux to legacy MS Windows
users is that there is a not insignificant population who's fully
familiar with the limitations and pitfalls of their current platform.

Different strokes.


> > > *) we often have some piece of proprietary software that says it
> > > will only run on RH X.Y.
> >=20
> > Response:  Then get RH specifically for $PROPRIETARY_SW ....
>=20
> I realise Oracle is the extreme-outlier case,=20

That's the one I had in mind...

> and that it might be more practical for other examples, but might
> someone create and maintain Debian contrib package
> "oracle9i-rdbms-support" with no contents other than the necessary
> Depends lines?  If the Depends packages were all available, then
> installing that package (and, if necessary, putting it on "hold"
> status) would answer the functional part of pointy-hair objections,
> right?
>=20
> There remains Oracle Corp. platform certification,=20

More specifically:  support.

At the large enterprise level, there _is_ such a thing as true customer
support, and it's often not cheap.  My own experience is largely with
SAS Institute, and while I rely very strongly on the SAS-L mailing list
for general language lawyering and algorithms, when you run across a
system error or a clear divergence between documentation and
performance, it's phone Cary time.  Tier 1 is generally competent, and
tier 2 is universally excellent.  Costs per call were estimated at $50
in 1997, and the company supports some 30,000 installations worldwide.
I've spent two hours with the DATA step INPUT specialist walking through
IBM packed/zone decimal fields, and know several of the techs by name,
fondly.

On the legacy MS Windows side it's even worse:  support scripts tend to
be specific to walking the user through menus and click actions.  The
uniformity of the legacy MS Windows interface provides a certain benefit
of consistency here (hold your guffaws).  And while readers of _this_
list will be comfortable walking the distinctions between dpkg, rpm,
apt-get, and up2date, as well as poking through /proc and filtering
output with pipes and grep, this is beyond the level of large number of
nominally 'Nix-experienced technical folks.

I've argued that this can be balanced by the ability to provide scripts
for diagnostic purposes (and have developed a few of these myself,
'system-info' being one).  Few ISVs have gone this route however.


> but that would seem feasible if the meta-package mechanism described
> works well enough, given Oracle RDBMS's insanely finicky and fragile
> requirements.  (The "Depends" might, for example, have to include some
> cruddy kernel and glibc combo borrowed from a Red Hat release.)

I agree that this is technically feasible, and quite likely better
supported by Debian's package management and dependencies system.
Question is whether or not Oracle finds it to its fiduciary benefit to
pursue the course.


> > Note too that for any two bits of sufficiently complex proprietary SW,
> > constraints may well mean you have to dedicate a system to it.
>=20
> That's always my answer in the case of Oracle RDBMS:  It's not much
> imposition to put up with Red Hat on that one machine, because it'll
> basically have to be a dedicated Oracle appliance, anyway, and thus
> will be left severely alone.

=2E..and also gets to the question of why Oracle abandoned its "Raw Iron"
Linux-based highly specialized Oracle OS.  Frankly, I suspect this would
be a superior solution.


> > The one remaining problem is getting Debian up on newer HW.  Simply:
> > the installer doesn't support a lot of stuff.  My fix here is to use one
> > of the installation options above, bootstrapped from Knoppix, LNX-BBC,
> > or similar bootable media.  You get the best of both worlds:  a system
> > that's autoconfigured for HW at boot using current tweaks, and a known
> > good Debian install.
>=20
> The "Debian won't install on my hardware" line doesn't wash anymore.

I don't believe you're interpreting my remarks that way.  However, the
default, official, distributed installer _won't_ install on newer
hardware.  One solution (as Ricka and I have undertaken) is to identify
and publicize alternatives, including both dedicated installers and
alternative methods such as chroot installs.  Another would be for
Debian to provide more frequent point release of installers with updated
kernels and (possibly) HW autodetection ;-)


> People said this without fear of contradiction before all the ways of
> dealing with hardware obstacles were widely understood and documented
> -- a form of information friction.  I've tried to help the process
> with a page of condensed information about Debian installation
> routines.  See "Installers" on http://linuxmafia.com/kb/Debian .

Quite.  And appreciated.


Peace.

--=20
Karsten M. Self <kmself@ix.netcom.com>        http://kmself.home.netcom.com/
 What Part of "Gestalt" don't you understand?
  Hey, Jim, it's me, Susie Lillis from the laundromat.  You said you were
  gonna call and it's been two weeks.  What's wrong, you lose my number?

--82I3+IH0IqGh5yIs
Content-Type: application/pgp-signature
Content-Disposition: inline

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.3 (GNU/Linux)

iD8DBQE/4L9BefG8443k044RAl/TAJ48kzlPfLfipXgcdQqxAWNuiGRxJACdGomc
TICZJ4sTX4ch3SDDwz22gXc=
=nrND
-----END PGP SIGNATURE-----

--82I3+IH0IqGh5yIs--