Les wrote:
A large eco-system from which test reporters, bug fixes, developers and
new ideas spring.
Why would these people wanting new ideas be interested in running old
stable releases?
If the *only* goal is to continue the evolution of the OS and a fixed
set of applications you are right.
That's the goal of fedora.
> But if the goal is one of promoting
the use of the OS, to continue to acquire and populate the user base by
retaining existing users, then a degree of stability in what works is
necessary, and desirable.
That's the goal of RHEL. Personally I think they have done themselves a
disservice by no longer permitting free unsupported downloads of their
branded product and requiring the CentOS distribution to remove their
branding so it looks like a different product even though it is compiled
from the same source and inherits the same support.
The OS now supports multiple users, servers, parallel processing,
distributed processing (at least offers some facilities for this), and a
large application base which may or may not work. Among the application
base are a number of GUI's (Gnome, KDE, XFCE, and others), Open Office,
a group of development tools and almost the full pantheon of languages.
Antivirus software Clam, Spamassisn and others. Currently I am working
on getting croquet working, and I have some difficulty with video and
audio on the Internet which I must get working to make Croquet
accomplish what I want. I also need comprehensive video to remain up to
date on other developments in the world.
Yes, it is a complex system built out of uncoordinated upstream
components. It's not going to work right the first time no matter how
much you wish it would. Fedora is the place where it is made to work
eventually.
I have no desire to maintain two OS's, with the attendant costs,
complexity, and especially the viral susceptability of windows. I want
Linux to be the OS of choice because I think it offers me many services
that are not available in the Windows platform. Yes, there are other
distributions available. But what I like so far is the community here.
That is the conundrum, isn't it?
Not once you realize that if you want the latest but risky code you run
fedora, and on boxes where stability and long-term update availability
is more important you run RHEL or CentOS. The installation and
administration procedures are close enough that you'll barely notice the
difference. If you want a compromise, you can install fedora in the 2nd
half of its life cycle when most of the early problems have been
fixed, but plan on a huge update download after the install and having
to repeat for the next version within a year. Frequent installs aren't
particularly difficult if you've planned for them, but if you aren't
using fedora as it is released you have to admit you aren't helping with
the process.
I have no answers for all of this, but the answers will come. This
software is not really "free". Here we pay for it by the testing and
fixing of bugs, which then get replicated into RHEL (and other places).
This takes our time, and our effort. However, what is our return for
that investment? One return is the use and access to thousands of
programs, internet access, and of course this wonderful community of
other like minded individuals (although the like mindedness is often in
flux ;) ).
Plus, the bug you report may be something that other people don't see as
a bug yet, so your participation may result in something tuned to your
particular needs.
But still it would be nice to have some assurance that things will work
tomorrow that worked today.
The baggage that comes with that is that all the same things that don't
work today either won't work tomorrow or they take additional work to
backport to old distributed versions without changing behavior. This
isn't much of a problem on the server side of things, since linux server
applications have been mostly feature-complete and stable for years, but
it is a big problem on the desktop where the applications are still
changing rapidly.
> I saw a proposal about segmenting the
applications into stable and current state of the art. I think that has
some merit. But the os then will have to be stable so that the bugs
that appear will develop a known causality, and you can separate the OS
issues with a known bug base vs the application via its own bugbase.
The bugbases already exist for most applications. Maybe this bears some
discussion and a proposal to be developed to put before the community?
I'd like to see something different where you would be able to keep a
working version of the kernel and its device drivers but update any or
all applications to current or close to current versions if you want.
This would basically amount to running a centosplus kernel with
everything from fedora rebuilt for it and it would give you a way to use
new apps without having to install an experimental kernel likely to
crash your machine. The standard C library and the ones required for
the desktop environments are sort-of a middle ground though. Sometimes
you need them to match the latest applications and installing them can
break old things you might still need. Personally I think it is a
mistake that RPM only allows you have one version of things installed at
once even though the OS is perfectly happy to have multiple versions
controlled by PATH and LD_LIBRARY at the same time. I suppose the
workaround will be the overkill of virtualizing the whole machine so you
can run both old and new without any memory sharing.
--
Les Mikesell
lesmikesell@xxxxxxxxx
