Re: Demonizing generic Linux issues as Fedora

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]



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

[Index of Archives]     [CentOS]     [CentOS Announce]     [CentOS Development]     [CentOS ARM Devel]     [CentOS Docs]     [CentOS Virtualization]     [Carrier Grade Linux]     [Linux Media]     [Asterisk]     [DCCP]     [Netdev]     [Xorg]     [Linux USB]
  Powered by Linux