On Saturday 28 May 2005 14:30, Les Mikesell wrote:
> No, I am looking for a solution that provides what a typical user needs,
Who is the typical user? CIPE users aren't, for one. Neither are radio
astronomers, for that matter. :-)
> I think Johnny Hughes nailed it in saying the push for 2.6 was because
> SLES 9 had it.
That's part of it, I'm sure, but there's more than that, or SLES9 wouldn't
have had it either. So SuSE and Red Hat BOTH have it, and there has to be a
reason. The biggest reason is that 2.6 supports enterprise-class hardware
that 2.4 does not. 2.6's enterprise features are better in many ways than
2.4's features. There are some non-marketing reasons for going 2.6, but
marketing reasons are just as valid as technical ones when the goal is to
stay in business and make money.
> could interoperate independently. A system as bundled by Red Hat
> is going back to the DLL-hell that windows users used to experience.
Not exactly. RPM dependency issues can be solved with intelligent library
versioning; for the most part binaries that run under RHEL3 can run under
RHEL4 using the compat-* packages built for that purpose. There are
exceptions, of course, CIPE being one. The DLL problems under windows are
mostly due to the lack of DLL versioning like we have available, in that
multiple versions of a library can coexist on a system. Take, for example,
all the various OpenSSL versions and how you might have three different
versions of the openssl libraries at any given time installed. You cannot do
this on Windows.
For the most part, the same problem does not exist on Linux. Take, for
instance, the way theKompany distributes RPMs. They have a single binary RPM
for each package, with a 'thekompany-support' base RPM for the basic
differences between systems. For the most part, this single binary will
install on virtually all modern RPM-based Linux dists.
Or Codeweaver's CrossOver Office product; it is available in a Loki-installer
setup or as an RPM. The one RPM works on all their supported platforms,
which includes 2.4 and 2.6 kernel-based distributions.
So the lib versioning problem can be addressed, but it has to be very
carefully addressed. The most extreme example is Cinelerra, which, last I
looked, was built fully statically linked and would basically run anywhere.
> 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.
Ah, but there is more than one 'it' in the LTSP case. The server doesn't
necessary have to run on odd hardware; it's the thin client that must run on
oddball hardware (I know how it works; I'm beginning to deploy an LTSP setup
at a private school on CentOS4 (with KDE-Redhat to get the modern desktop
apps).
> 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,
2.6 IS a proven kernel at this point in time, at least for the vast majority
of users. There are exceptions; but, then again, Debian Stable is still a
2.2 kernel.
> 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.
CentOS4 is the product that I need as it stands for the majority of what I
need. For the other needs I use the solution that fits best; for instance,
CentOS4 is not my firewall/VPN router OS, SmoothWall Corporate Server
3.0+SmoothTunnel3.1 is. Adding KDE-Redhat to CentOS 4, and then adding DAG
to that covers 99% of my use cases.
But remember the CentOS core mission: Community Enterprise Linux. Designed to
be a rebuilt RHEL and nothing more, because a very large number of users need
that exact functionality. Why as close as possible? To leverage the
development and the security updates, as well as the third-party repos that
will support 'el4' packages (like DAG, ATrpms, KDE-Redhat, etc).
> 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.
With the notable exception of KDE-Redhat. And I ask why there are third party
conflicts? The RPMforge project aims to reduce those conflicts, but even
then there still are some. The biggest reason these repos focus on 'extra'
packages is that, the more you change the base OS the more difficult it
becomes to coordinate updates' dependencies.
> 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.
It's called Gentoo, and while you need to rebuild from source once there is a
binary distribution mechanism available. But even then, the way Gentoo is
built you could end up with some really odd dependency issues.
> 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.
So I ask, what is required to backport Ev 2.x to FC1 (the answer is 'alot more
work than it's worth for most people' because Ev 2.x requires massive updates
to core libs).
> 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.
Use KDE-Redhat for current KDE. For Gnome I wouldn't know, as I don't use
GNOME. The source for KDE-Redhat is kde-redhat.sourceforge.net and is
available for Red Hat 7.3 and 9, Fedora Cores 1, 2, and 3, and Red Hat
Enterprise Linux 3 and 4. The goal of the project is the latest KDE release
on all those distributions, and it works. It requires nearly a complete
CD-worth of packages for it to work, but it does work. That first download
is a real doozy.
> 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?
Ask the KDE-Redhat maintainer how much work it is. His name is Rex Dieter.
You do it the same way you release a distribution in the first place: you
apply a lot of time and a lot of hard work to get the details in order. And
dependency agnosticism, while somewhat possible, is a matter of juggling an
immense number of details, which requires a large umber of man hours that
someone must put in.
Rebuilding from source RPM with an intelligent source depsolver (Gentoo does
this in their ebuild system) would work; it would basically mean everyone
would need a buildsystem setup somewhere. Maybe virtual hardware ala Xen is
part of the answer, but the bigger problem is API/ABI stability. And the
problem with Open Source is enforcing interface stability: it won't happen in
this world due to the independent nature of each of the 1000 parts.
But then there's Fedora Alternatives, which hasn't even started yet. What
you're after is a 'RHEL-Alternatives' that isn't there yet.
But at the end you'll have to motivate people to do the work; and those people
will need to have roughly the same goals you do.
In the case of KDE-Redhat, there are a lot of people rather unhappy with stock
Red Hat KDE and decided to do something about it. Rex is the most vocal of
the group, but I don't think he does it alone (although I could be wrong).
So, rather than just gripe about the state of Red Hat's KDE, the KDE-Redhat
group did something about it.
So, I can have a CentOS 3 system and a CentOS 4 system running essentially the
same desktop applications from KDE using kde-redhat. But, again, it's a lot
of work that the KDE-Redhat developers are doing.
--
Lamar Owen
Director of Information Technology
Pisgah Astronomical Research Institute
1 PARI Drive
Rosman, NC 28772
(828)862-5554
www.pari.edu
