Re: OT: RH end-of-life
R P Herrold <[email protected]> Tue, 28 Jan 2003 13:58:18 -0500 (EST)
| Newsgroups | gmane.network.up2date.current.devel |
|---|---|
| Message-ID | <[email protected]> |
On Tue, 28 Jan 2003, a couple of comments crossed the list.
Cameron Logie offered:
> It should be fairly easy to upgrade your desktop systems though using some
> cunning kickstart scripts in update mode.
> I appreciate that that involves man hours if you've got a LOT of them to do.
heh -- 'In theory, there should be no difference between
theory and practice. In practice, there is.' It is not as
simple as it looks. Tracking detail differences across Red
Hat major, and some point releases would tax the skills of an
old-time Kremlin-ologist. Automating it is even more tricky.
> Why don't you consider LTSP ? (http://www.ltsp.org)
> That'd give you just a bunch of diskless remote X terminals to look after.
> All you'd need to keep 'up2date' is the main server.
and Stephen Smoogen offered:
> There are several small companies (owlriver comes to mind)
> who would be willing to support RH 6.2/7.3/etc beyond Red
> Hat's end of life. The problem I have found when I was
> researching doing this was that there are very few people
> who want to pay..
Concur. As one who admins a large (200 seat) ltsp install,
you want to be VERY careful to not inadvertently 'maintain
away' items which end users have found and started to use. I
removed some kde games the other days, and got korganizer,
because I knew that I had not trained anyone on it ...
up2date, current, autorpm, yum, and all the cluster of
automated mainentance tools are not perfect -- nothing human
is; and they get to work with product produced in the 'black
box' which is Red Hat's development process.
At that production LTSP facility, an auto-maintain tool broke
the xinetd (which tftp booting interacts with); and also
pushed the glibc security update in, which exposed the
broken-ness of the MySQL dns resolver code. With a single
user machine. it is no big deal to revert in a leisurely
fashion. With 200 people sitting on their hands, stress takes
on new meanings.
On the topic of third party RPM-based system updaters, I've
done and sold backporting to clients for years on EOL'd
software. I'm delighted to sell it more widely, and work with
local admins across the country on 'white box consulting'
outsourcing of the backend.
For the past few users I've used and helped the development of
autorpm and a cluster of surrounding tools. yum, also from
Duke, is the rising star for me at the moment with the nice
dependency resolution, and apt-ish useability. What Stephen
mentioned is what I've said before elsewhere, and I have
updated our webpage section to address this RH EOL topic
expressly
http://www.owlriver.com/support/#rheol
On the topic of commercial prospects of OSS, I think that the
only commercial market in Open Source software is in selling
consulting services: design, configuration, specification,
implementation, maintainence and admin, by the hour or on a
retainer basis.
-- Russ Herrold