[239] in magellan
Linux/Athena Discovery minutes from 14 July 1999
daemon@ATHENA.MIT.EDU (Thomas Bushnell, BSG)
Wed Jul 28 11:50:17 1999
Date: Wed, 28 Jul 1999 11:49:19 -0400 (EDT)
Message-Id: <199907281549.LAA241165@pusey.mit.edu>
From: tb@MIT.EDU (Thomas Bushnell, BSG)
To: linux-disc@MIT.EDU
Cc: magellan@MIT.EDU, vkumar@MIT.EDU
Linux/Athena Discovery Team
14 July 1999
Present: Bill Cattey, Thomas Bushnell, Greg Hudson, Abby Fox, Oliver
Thomas, Karl Ramm, Heather Harrison, Emil Sit.
We discussed
possible cluster hardware purchases
possible support sinkholes and how to avoid them
levels of support to provide
Hardware choices
----------------
We decided that the discovery report should include current prices for
Dell PC's, with a similar hardware complement to a Sun Ultra 5 as we
currently purchase them. We would recommend 10 pilot workstations in
a cluster (probably W-20) and 12 for development and support.
Based upon an initial look at the prices, two things became clear: we
may well not get a discount of the list Dell price by going through
our preferred vendor thingie, and the prices of PC's are very very
competitive with Suns.
We would also spec out a higher end model as a server suggestion.
Both of these would be listed in the report for consideration and
evaluation; the actual hardware decisions might well be different and
would probably include a couple more options too.
We would also list the cost of some common peripherals, like SCSI
controllers with disks, and ZIP drives.
Support sinkholes
-----------------
"I have thus and such hardware, and Linux/Athena doesn't work on it"
(for hardware not on the supported list)
1) We can't and don't support unsupported hardware.
2) Layered Athena may be for you.
3) If RedHat supports the device but it's not installed by default,
then a custom Athena install may be for you.
"Patchy" deployed systems (systems with lots of piecemeal patches over
time)
1) Patches that were for supported things ("best effort" support)
will go into the next release, and the customer will then merge
back.
2) For unsupported things ("minimal effort" support) then they just
diverge.
"I can't purchase anything on the supported configuration list becase
the vendor no longer sells it"
Generally this is relevant to new processors and increased memory
and such; for that we can say "... is available, and we've tested up
to ..."
"I have an optional add-on package foo and it doesn't install"
Out Of Scope.
"I want to buy something newer and spiffier than the supported
hardware list"
We may be able to make it work by special arrangement with dev; at
least that involves buying an extra one for us so we can test.
"It doesn't run on my computer? But this is what my parents bought me
when I left for MIT!"
Publicity and education are the only tools here.
Scenario: User is using unsupported hardware, but it happens to Just
Work. Then an autoupdate breaks it.
This should be rare, and we can avoid it without much trouble.
Levels of support
-----------------
Defined supported configuration Your problem is our problem.
Tested & supported hardware Best effort
Not tested but trusted Best effort
RedHat supports it but we don't Minimal effort
RedHat lists it but doesn't support it Not Our Problem.
Linux includes it but RH doesn't list it Not Our Problem.
There's a driver somewhere on the net. Not Our Problem.
