On Sat, 2005-05-28 at 05:30, Bryan J. Smith wrote:
> Okay Lee, we all agree, Red Hat makes stupid decisions, adopts buggy
> software - especially the kernel and Red Hat is to blame for the decisions
> in the kernel, and also stupidly backports fixes instead of adopting newer
> versions with the fixes.
> And there is absolutely no need for Red Hat to do so.
>
> Happy?
No, I am looking for a solution that provides what a typical user needs,
not what a particular vendor feels like supporting this week. I didn't
really want this to be about motives for vendor's business decisions but
I think Johnny Hughes nailed it in saying the push for 2.6 was because
SLES 9 had it. Their decision wasn't stupid, but my point is that it
wasn't the best thing for some number of their old users.
I do understand that the particular bundles that RH arranges fit some
needs, and that in the big picture, most of this stuff lands on server
farms where one machine runs one program so if the next-version
distro runs on that machine, you take whatever else comes and it
doesn't matter. I have a fair number of machines in that world,
including some that go all the way back to when VALinux was in the
hardware business and shipped with a paid copy of RH installed.
However, I also support a number of general-purpose servers and some
desktops where a larger mix of applications need to be integrated
along with a variety of oddball hardware that has, over the years
been connected and supported one way or another. In this scenario
you are very likely to want to upgrade a single application and
find that you can't do it RedHat's-way(tm) because the bundled
upgrade will break something else that you need to keep running.
Explaining the reason the vendor made the decision that doesn't
work in my case isn't particularly helpful. You might as well
try to explain to me why upgrading or installing certain MS
products require moving the whole enterprise to Active Directory
first. I'm not really interested in playing a 'vendor lock-in'
game. I started using Linux in the first place to avoid that and
have a system where different components from different sources
could interoperate independently. A system as bundled by Red Hat
is going back to the DLL-hell that windows users used to experience.
I can support this argument with details from my own experience but
I'd only expect anyone to care in the context of what a large number
of people need. For that, I'd suggest browsing the k12ltsp project's
archives at http://www.redhat.com/mailman/listinfo/k12osn.
This project combines a fedora install with the ability to network-boot
thin clients so they run their desktop and apps from the server. As
such they present the worst of all possible worlds in terms of needing
server-stability and up-to-date apps on the same distribution and it
has to run on an odd assortment of hardware. Judging from the list
postings and my own testing, I'd guess that on the switch from the
FC1 to FC2 or FC3 based distros, people had about a 1 in 4 chance that
something would go drastically wrong in terms of hardware support
ranging from random crashes to lack of disk controller support and
perhaps a 50/50 chance that the ethernet interfaces would be dectected
with different names. Maybe 10% would have serious enough problems
that they had to re-install the FC1 based version.
Now, is there a better solution? I don't really want to hear another
rendition of why RH chooses not to provide current apps in a
distribution with a proven kernel, or why what's good for RH is good
for the whole world. What I want is for this discussion to be about how
to get the product that I think a lot of people need, not about
brand loyalty to something that doesn't provide it. In the early
days of freshrpms.net, I thought that 3rd party update repositories
had a lot of promise but they ran into their own conflicts and in the
consolidation effort seem to have focused on adding apps not included
in the core product rather than updates to versions beyond stock.
Centosplus seems headed the same direction - and perhaps that's the best
anyone can do if they intend to offer any kind of testing and support.
What's missing is something that fills the gap between a user having
to rebuild from source himself and subsequently support the updates
the same way forever and the downrev repository versions. Finding
firefox backed into the FC1 legacy update repository is the sort of
exception to the rule that I'd like to see expanded although it isn't
precisely the same change as going to (say) evolution 2.x.
For a simple example, let's say someone can run Centos 3.x but not 4.x
for any number of reasons, and they want current application features.
Can we, without degenerating into vendor bashing again, discuss how
such a thing would be possible in a way that every person who wants
this does not have to repeat every possible thing that could go wrong
in a local custom install, and repeat it again for every bugfix update?
Maybe Xen is the right direction to head to avoid this in the future.
If the apps really will only work right when bundled into a massive
distribution, then we should start planning for an emulated hardware
environment so the other parts of the next bundle can't break our
existing infrastructure. I'd guess that currently the best real-world
solution is to keep running certain apps on the old box and install new
hardware for the ones you want to upgrade. In practice the price might
even be right going that way, but it just doesn't appeal to my
engineering sense.
--
Les Mikesell
lesmikesell@xxxxxxxxx
