David Boyes wrote:

I wish the distributors would use it (or at least be friendly to it) rather
than these proprietary update hacks like YOU or RHN. It'd save them a hell
of a lot of bandwidth.


Even more important than intercompany bandwidth is the ability to
control what
software is going to come to you. We control our own (APT) repository and we
decide when new code is promoted to the 'stable' repository, which
happens after
testing and when we want the servers to use it. Automatic upgrade in
that case is
very feasable.
This means there will not be any surprises when you upgrade the server
to the latest
code. If you upgrade from a public update repository managed by someone
else you
can never tell whether the next server upgrade will be the same as the
previous one.
Yes, I know you get prompted with a list of 387 pkgs, but I rather
control it at some
other point in time.

When the distributor would not use proprietary tools for their
maintenance, it would
be trivial for someone else to grab their distribution and sell
maintenance on top of it
using the distributor's tools like YOU or up2date. I want to believe
such issues is
also why the re-packaging of SuSE rpm's like k_deflt is so cumbersome.

Rob

Reply via email to