[2722] in Release_7.7_team
Minor revision to my Laptop Linux CD Cost doc.
daemon@ATHENA.MIT.EDU (Bill Cattey)
Thu Apr 26 18:44:15 2001
Message-ID: <4uu_Gw1z0001Ryc0lC@mit.edu>
Date: Thu, 26 Apr 2001 22:44:12 +0000 ()
From: Bill Cattey <wdc@MIT.EDU>
To: longpd@MIT.EDU, hallisey@MIT.EDU, owls@MIT.EDU
CC: release-team@MIT.EDU
Here is the latest version. As per my promise at the owls meeting, I
added the specifics on the hardware configuration issues for Laptops
i.e. video, sound, and network interface.
Share and enjoy,
-wdc
----
Cost Estimate
Production of Laptop Install CD for Linux
Bill Cattey
Last revised: 26 April 2001
Introduction:
I was charged with making cost estimates on the following items
with regards to a laptop image install CD for Linux :
1. Determine software load
2. Write Installers for Linux apps
3. Test installers
4. Write ReadMe/instructional info
5. Make CD/image
6. Establish update process
7. Write Docs/web pages
Instead of answering the question 'How much it would cost?", I have
come back with a lot of questions to be answered before the cost can
be computed. I hope this note is useful in that it describes the
relative costs of different tradeoffs, and gives a sense of some of
the hiterto obscure tradeoffs made by Athena.
Circulate this document freely. The more people who understand these
issues and tradeoffs, the better. I plan to share this document with
the Athena Release Team and Owls to help influence existing work in a
direction useful long term to 1 to 1 computing.
I've attempted to identify primary drivers of cost, and suggest the
tradeoffs, along with a favorite among the choices. I've also tried
to describe what I see as boundry cases and attempted to relate them to
the farther future goals of ubiquitous personally owned laptop
systems. My goal is to maximize the benefit to the long term from the
immediate work.
For each of the seven cost areas, I provide a brief narative of what I
see drives the cost, and then provide as much of an estimate as I feel
able to.
Areas 4 and 7, Write ReadMe/instructional info, and Write Docs/web
pages are special: The Documentation group needs to provide those
estimates. But it is unreasonable to expect the Documentation group
to do that in the absense of a more detailed description of the CD
image, and its documentation requirements. In my descriptions below,
I call out what would result in larger or smaller scope documentation
requirements.
For all specific estimates I give 3 point estimates:
Min, Max, Most likely and then the units.
----
1. Determine software load
Two parameters need to be nailed down:
What third party software to bundle in?
What, if any Athena software or services?
As shown below, producing installers should not a big issue for Linux.
For third party software in this task the primary cost driver is the
time taken to license the software for individual installation, and
the cost factor of licensing the software for each person. So we're
talking calendar time elapsed and dollars spent here.
For Athena third party software and services, there are two costs:
Generate a list of candidate Athena packages, and assess which packages
can just be installed if desired, and which ones require additional
development to work in the sometimes-disconnected environment of a
laptop. Make estimates of that development effort for each package.
Estimate: Min 1/2 day, Max 4 days, Most likely 1 day.
The second cost would be in whatever development was made to make the
desired packages work in sometimes-disconnected mode.
Recommendation:
Find out the deadline for a CD image, and work backwards in time.
Gather as many third party and Athena packages as can be delivered
before the deadline. Be flexible about what gets put in, but not
about the deadline. Comission mini projects to get a prioritized
bunch of Athena services into the distribution. For example, Zephyr
would be highly desirable, but currently will not work at all well in
a sometimes-disconnected mode.
Expect that there are going to be some packages that will end up being
installed by the end-users. Establish the principle to minimize that
number, but to balance against licensing costs.
Note: The Athena Linux release has Athena versions of some significant
packages such as Emacs which are installed instead of the Red Hat
versions. This is done as infrequently as possible, but examples of
reasons why are: Closes a security hole not yet closed in the generic
package. Sets defaults that are what Athena usability testing
required instead of the generic. Special changes to accomodate AFS or
Kerberos. The Athena-replaced package list would have to be reviewed
for the laptop Linux distribution.
Note also: AFS very strongly assumes that it is connected to the net
100% of the time. While some careful folks, and some wizardly folks
can be relied upon only to start AFS when connected to the net, and to
shut it down when disconnecting, this is NOT something we can assume
average users will be able to do.
Recommendation:
Do not install AFS on the laptop systems.
Investigate other filesystems such as Coda. Invite the Open AFS
community to investigate disconnected operation. One estimate of the
work required is 2 fte's for 2 years full time.
----
2. Write Installers for Linux apps.
The vast majority of Linux software, uses the Linux RPM format
to package, distribute and install it.
Recommendation:
Use only software that already has Linux RPM installers written.
There may be a little custom tailoring, but with RPM's already present
this cost is near zero.
----
3. Test installers
The subsystem test implied by this item pretty much goes away when one
constrains installers to all have RPM's.
----
4. Write ReadMe/instructional info
The Documentation group needs to cost this out once there is a clear
sense of what, exactly, the install looks like. It could end up being
as simple as a single page that gives the answers to one or two
questions aske by the install process. If a less customized install
is produced, it may involved subtle modification to existing
documentation from the software and/or hardware vendors.
Recommendation:
Discuss the balance between lots of documentation versus lots of
development time to customize and maintain a customized installation
to establish what exactly is the user interface seen by the end user.
----
5. Make CD/image
The crucial questions to answer here are:
A. Will a stock Red Hat distribution work?
B. Is a custom install script required?
C. What precisely are the network setup requirements?
A. Will a stock Red Hat distribution work?
If the hardware deployed is one of the configurations explicitly
supported by RedHat, one way to 'make an image' is to hand end-users a
Red Hat Distribution. This has the advantage that no additional
development work is required. It has the disadvantage that the
end-user would be expected to follow the Red Hat installation
process. This may create additional documentation work, and may
presume a higher level of expertise than our intended clientele
actually has.
It turns out that very few laptops are explicitly supported by Red
Hat:
As of 5 April 2001, Red Hat lists exactly 4 laptop systems
that will just work out of the box with their install (for Red Hat 7)
at http://hardware.redhat.com. All of them are from Dell:
Inspiron 4000
Inspiron 8000
Lattitude C600
Lattitude CPx(H500GT)
This probably means that if MIT deploys anything other than these four
systems that additional development work would be required to make
sure that the hardware are adequately supportable, and that
configuration files are properly crafted for them.
With a laptop, there are three areas of concern:
Network Interface
Video Display Driver
Sound
In each of these three areas, it has been observed that laptop makers
may use chip sets that don't have drivers for Linux. It is important,
that any laptop chosen be validated with the Linux on Laptops web site
(http://www.linux-laptop.net/), and/or with the Red Hat supported
hardware web site (http://www.redhat.com/support/hardware/) to confirm
that drivers exist.
Recommendation:
Stick to hardware with well-established drivers, and purchase a test
system and validate it before making bulk purchases. Recognize that
laptop makers, even more than desktop makers, change chipsets. Often
minor chipset revisions require major interventions to get drivers to
continue working. Try to stay with vendors and product lines with
proven stability.
There are two components to getting Video working: a proper driver,
and a proper XF86Config configuration file setup. Make sure both are
in hand and validated before making bulk purchases.
Compared to video and network interfaces sound has, by far, widest
proliferation of chips and levels of support. The SIPB adopted a
principle that I would recommend following: Tell customers, "Sound is
luxury you cannot afford unless you do the work yourself to learn how
to make it work." If the decision is made that 1 to 1 computing will
support sound, then it is important that laptops be chosen that not
only have rock solid Linux drivers, but also which include headphone
jacks so that users will not disturb others. (Yes, that's right, not
all laptops come with headphone jacks.)
B. Is a custom install script required?
The Athena Linux install does not presently use the Red Hat install
script. Instead the lower level RPM packages are utilized by our own
scripts that understand very well exactly what few hardware platforms
are being deployed. Configuration files are pre-packaged with Athena
versions of certain RPMs. The Athena Linux install has the advantage
that end users are asked very few questions and the answers are easily
documented. It has the disadvantage that hardware configurations are
explicitly added one by one.
Between the two poles, Athena with its few questions to users and
Red Hat with its many questions, lies some acceptable middle ground.
The Student Information Processing Board has investigated a modified
Red Hat install script that is more tailored to the expectations of
hardware and clientele expected at MIT. Crafting a modification to
the Red Hat installer is tricky because it is written in the
not-widely understood scripting language, Python, and because the
script is very complex. Learning Python is comparatively easy.
Making a modification to the messy script while minimizing unintended
consequences requires an adept.
Estimate: Ramp up time to understand Red Hat script, given the core
technical competency of managing and modifying complex software: Min 1
week, Max 2 months, Likely 3 weeks.
Estimate: Time to craft a custom install which pre-answers relevant
questions: Min 1 week, Max 2 weeks, likely 2 weeks.
The custom install work will need to be repeated every time a new Red
Hat distribution is supported by MIT, and whenever the deployed
hardware changes sufficiently to require updates to the pre-supplied
configuration answers.
Recommendation:
Review the Red Hat install and identify areas that are candidates for
simplification with a modified install process. Identify areas that
are going to require asking questions. Determine if there is enough
value to getting rid of questions to proceed with a custom script. It
may be that so many areas require questions be answered that the right
use of effort is in documenting the existing process.
C. What precisely are the network setup requirements?
In some of the informal discussion about what this 'Cost estimate a
Linux Image CD' task was really about, someone said they'd like to
have the networking be pre-configured for the end-user.
Interestingly, the only question that the Athena install cannot
presume a default answer for is the IP address of the machine being
installed. This is because it is expected that an Athena system might
be installed anywhere on campus, but a custom configuration may be
required for it. Our install servers coexist with generic install
servers. Our install servers made the simplifying assumption that we
could rely on a user-supplied IP address to differentiate the system
being installed from the generic, and to identify any custom aspects
required.
If the customization resides entirely on the CD, or if the systems are
constrained to install at particular places at MIT where location can
be used to differentiate, then systems could be pre-configured to use
just DHCP.
But this raises a new issue: Accounting for network service. The
present rate model is to associate network service charges with a
particular host. A customer acquires a static IP address and pays
monthly charges for it. When a customer enrolls in DHCP service, that
static IP address is used to get onto a web page that reads the
ethernet hardware address out of the machine for the user, and to
store that address in the DHCP tables as someone who is paying his or
her network bill.
Recommendation:
Think very hard before you decide to require a customer to learn what
an ethernet hardware address is, and to type that in rather than
learning what an IP address is, and typing that in. IP addresses are
MUCH easier for the less technically adept to deal with.
The alternative is to require the customer to pick up a
system from some IS-created depot where the configuration and
registration is done by trained personnel.
----
6. Establish update process
The Linux RPM format and utilities offer a leg up here. A
comprehensive install/update system is available for the Debian
distribution, but the majority, including Athena, runs Red Hat. (Red
Hat is the market leader, and it ostensibly does not use the Debian
update system. This is a case of market leadership coming from being
very generic and at the expense of being behind in satisfying an
important requirement.) Everyone's update system is layered on top of
RPM packages. Athena's is a set of scripts.
Red Hat offers a remote update facility. Customers can enroll, and
run a daemon that checks for packagage updates, downloads them, and
installs them. Unfortunately, this system will not do the
installation of a kernel update. The Red Hat remote update daemon is
not going to risk replacing a customer's possibly modified kernel, nor
will it risk disrupting running jobs.
The Athena update will handle kernel updates, but it presumes a
generic kernel, and a development staff who can validate that the
update is justified. The Athena update is run either by hand, or from
inside login. From inside login it avoids disruption by running when
nobody is logged on. It assumes there are no significant jobs running
when nobody is logged on, and that it's ok to reboot the system.
Both the Red Hat and Athena updates operate by keeping a list of what
packages are cared about for updating, and synchronizing what is
installed to what is supposed to be present. Athena tries to minimize
the amount of initial and ongoing maintenance of that list. Cost
estimate: Min 1 hour, Max 1 day, Most likely 4 hours a month to keep
such a list up to date. It would definitely have to start off as a
separate list from the Athena package list because the environment is
going to be very different from Athena.
There are four posible scenarios:
Never update
Update requires user be clueful
Red Hat update service
Develop update script like Athena's update-ws.
Current laptop Linux owners often find it so difficult to reproduce
the custom drivers and parameters needed for their laptop that they
avoid much of any updating until they replace the laptop. Even so,
SOME updating occurs all the time to close security holes and to
install new applications, or to update applications. 'Never update'
is not a viable recommendation.
This leads into the next scenario: Update requires user be clueful.
Is it the expectation that a user would be sufficiently clueful about
doing software updates and installations, say, to take a Windows
Service pack update? If so, the RPM's embodying the various updates
can be made available, and the reasons why users should take them can
be published, and the users can be asked to run the 'rpm' program to
take the update. My understanding is that we would prefer users not
have to learn how to do this.
The Red Hat update service scenario: This requires less skill on the
part of the user, but may still involve our producing documentation to
give a recommended set of parameters. If a security problem comes
along that makes us strongly desire users get a kernel update, this
solution becomes rather problematic. In practice, Athena has taken
few if any kernel updates in patch releases. This is a viable
alternative. The Red Hat update service is currently free to an
individual for a single machine. The for-pay service for additional
machines is currently $9.95 per month with a plan to increase the cost
to 19.95 a month at some point in the future.
The update script customized to MIT is the one that allows minimizing
the amount a user needs to learn, but maximizes the amount of
development. The good news here is that the update-ws script from
Athena is probably very close to able to fit the bill, and we have
existing Athena documentation that does the job. (One complication is
that we'll have to use something other than AFS to fetch the packages,
but this should not be significant effort.) Estimate: Min 2 days,
Max 3 weeks, Most likely 2 weeks to produce this.
Recommendation:
Choose either Red Hat update service which might end up costing users
$19.95 a month, or we pay enterprise-wide, or develop the update-ws
script.
----
7. Write Docs/web pages
Here again, I am not the one to cost this out. The documentation
requirements need to be further fleshed out as we understand what work
is asked for in the other parts of the breakdown and use that to
specify the desired documentation in adequate detail.
Recommendation:
Discuss the balance between lots of documentation versus lots of
development time to customize and maintain a customized installation
to establish what exactly is the user interface seen by the end user.
