EL6 RPMs for Fedora 14 Issue
joel.sherrill at OARcorp.com
Thu Dec 22 13:48:00 UTC 2011
On 12/22/2011 06:50 AM, Ralf Corsepius wrote:
> On 12/22/2011 01:09 PM, Peter Dufault wrote:
>> On Dec 22, 2011, at 6:49 , Ralf Corsepius wrote:
>>> CentOS is a server distro, which is aiming at "long term API stability".
>>> In general, it's a good choice to run a web-server or a data base server
>>> on it, but is a bad choice for development purposes.
>> I would have agreed until I found the EPEL (Extra Packages for Enterprise Linux) packages. Centos/Epel may not be good for working on the head, but it is good for working on products, and with the EPEL packages I've only had to build a few things myself.
> Well, EPEL doesn't change much about the key weakness of CentOS: The API
> and ABI freeze CentOS is based on.
> I.e. one sooner or later one gets stuck in CentOS being tied to ancient
> ABI/APIs which will prevent packages on it to take advantage of new
> features or from being added to CentOS at all.
And that's what is good about it for "products" as Peter referred to
them. From my background, we refer to them as deployed applications.
Whatever the term, the RTEMS application that is running on products
in the field was developed on RTEMS version X using a particular RHEL
or CentOS version. The RTEMS version on that product will not be
changed because that's the way embedded systems work. Thus the
development environment and RTEMS version are essentially frozen
for production of bug fixes and minor updates to their fielded product.
Three years ago, I saw a DEC Alpha workstation at SLAC that solely
existed to support a single application that was not scheduled to
be replaced. At that point, they had 100s of Multibus II boards which
are from the late 80's. This is not atypical.
Look at the space applications we know about. RTEMS 4.0.x is circling
Mars in Electra. Herschel and Planck are on 4.5. Even commercial users
have extreme cycles. We have a building controller user and I have no
idea how old the RTEMS version is that was used in their first product is.
But you can bet that they will support that product for 10-15 years from
release without updating RTEMS.
When the products/hardware is updated, The RTEMS version will be
updated to the latest with matching tools and development OS. It may
be foreign to your experience but it is the way products with over an
18 month lifespan are supported.
> This isn't much of a problem for RH and CentOS, because of the very
> small set of packages they provide and because of the man-power RH
> deploys to RHEL, but it is an actual problem for EPEL and is a problem
> for RTEMS.
> Real world example from RTEMS: Some time ago, I could not avoid to stop
> supporting CentOS4, because it did not supply necessarily recent
> versions of packages RTEMS needs. ATM, ... CentOS5 is at a comparable
> stage as CentOS4 was then :-)
> That said, it's not a matter of if we once will be forced to abandon
> certain versions of CentOS, it's only a question of when.
> rtems-users mailing list
> rtems-users at rtems.org
More information about the users