On Wednesday 23 July 2003 05:00, Robert LeBlanc wrote:
As a case in point, if I happen to use IBM DB2 as my database of
choice
(or necessity) on a given server, I'll end up having to (re)build
packages like PHP from sources in order to configure --with-ibm-db2 or
somesuch.
The problem at the root of all this is that if I ever need to rebuild
anything from sources, I break the auto-update chain for that package.
What's the Big Picture/Goal?
RHL Project users get no "Support" from RH. Apparently this does not
preclude RH from collecting money for RHN subscriptions to distribute
and apply updates. Obviously for the example above, RH is going to
provide support for DB2 in RHEL. RH's goal isn't to supply the serious
do it yourselfer like Robert with everything he needs in RHL Project but
instead in RHEL. Robert however, like myself, doesn't want to pay big
bucks for support that we will almost never use (maybe his is willing
but RH didn't speakup and say, "that's in RHEL"). We need to find a
balance in all this. I see RH is being very careful but maybe too
careful. If RH actually "is" willing support an array of PHP rpms, etc,
for various configurations to cover the needs of people like Robert but
"only" in RHEL and Robert is willing to pay for the convienence then
that dialog needs to happen. Obviously RH is a large company which needs
to make money so this is understandable but RH is being a little tight
lipped about what they have going in RHEL and probably haven't decided
it all yet.
On the other hand for people like Robert and myself who "aren't" willing
to pay big bucks when we can do it ourselves but are willing to
contribute to RHL Project, RH needs to work with us or lose us. I
personally am considering moving to RHEL when 3.0 is released but I need
to check it out first. They have said to me, "Talk to us, we give volume
discounts. At low volumes." Not formalizing and publishing the volume
discounts is very short sighted because more than half of the
prospective RHEL customers my size never talk to them after seeing the
price and multiplying it times the number of servers (7 in my case). We
just say to our selves, "forget it, it cost too much".
If RHL Project is supported only by the community, then the community
will move to one of the free update distribution systems if RH does not
work with us. For example RHL Project is GPL. I can install it on 10
computers or 50 computers. RHEL has a satellite RHN server. Because it's
technically easy for the community to write a light version of this, we
will (and have) if RH does not. We are do it yourselfers. Include in RHL
Project a light RHN satellite that only the do it yourselfer can use:
rpm -i rhn-sat....
dhcp.conf: update_server=192.168.0.1
Done! Simple but not automatic. The masses will have one computer and
pay for update the way they are now.
With this RH collects $100 / year / channel (or whatever) for a
subscription which feeds the rhn-satellite all the updates only once.
Then "Do it Yourself IT" can have an infinate number of installs in
their company and RH never has to answer a single support call but is
making just a little money from *many* small businesses. IMHO RH can not
reserve convienient security updates for RHEL. But if they approach it
from the right angle they can succeed big time. The other companies
which are willing to spend $500K to save $2M will use RHEL for all the
other advantages it has.
As for updating custom installs here is what is needed for both RHL
Project and RHEL. Someone sugguested something close to this: All
updates are released as not only bin and src rpms but also a src-diff
rpm which installs patches for the update in an "unapplied patches" dir
in the src tree for that package. This rpm is dependent on prior patches
and the original src rpm. The only thing the do it yourselfer needs to
do to take advantage of this when he needs to modify a package is to
force the uninstall of the binary rpm first and then compile and install
from the src rpm. Up2date will then do the right thing without mods. If
we don't get carried away with diffs from every point to every point
then this won't be very much extra work to support, just one patch rpm
in addition to the src rpm (correct me if making a dif rpm is labor
intensive). If the diff rpm cats an entry in a "src-update" log file
then after running up2date -u the do-it-yourselfer only needs to check
it for new entries to know which packages need recompiled. He then
applies, compiles and then moves the patches to the "applied patches"
folder and he's all set. Perhaps rpm can be taught to update a src rpm,
simulating the diff rpm above, to accomplish all this without any other
changes! A single update to rpm and a howto and it's all done!
I honestly believe RH can be a raving success if they strike a good
balance between the do-it-yourselfer and the enterprise.
Sorry for being so wordy but I hope it helps.
Scott Becker