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