Once upon a time, Les Mikesell <lesmikesell@xxxxxxxxx> said: > I'd think that a distribution on the bleeding edge as fedora should be > the one leading this effort, not looking for something to join. One problem with standardization is that it tends to freeze development in some ways. A big compatibility issue is shared library sonames. For standards to emerge, you'd have to define a complete set of compatible sonames. That would mean all compatible distributions would have to be using (essentially) the same version glibc, gcc, X, GNOME, KDE, perl, python, etc. at the same time. It would require all the major open source projects to be synchronized to the same release schedule (or at least all distributions to pick up new versions of everything at the same time of year). That just isn't going to happen. For some of these things, Linux distributions are a large part of their user base (glibc, GNOME, KDE), and you might could work with them, but for things like gcc, perl, and python, Linux is only one of many targets. Usually, if you restrict yourself to building against older versions of the libraries (e.g. pick the oldest enterprise distribution you are interested in supporting), your program should run with no problems on the latest bleeding-edge distributions. For example, Adobe Acrobat Reader is linked against a long list of system-provided libraries, including GNOME. However, they do package it with some compat libraries like OpenSSL; that's a library though that has traditionally been one of the worst at ABI compatibility in the shared libraries (and there's not much Fedora can do about that). They also include libgcc and libstdc++, also libraries that have had a moving target ABI over time. -- Chris Adams <cmadams@xxxxxxxxxx> Systems and Network Administrator - HiWAAY Internet Services I don't speak for anybody but myself - that's enough trouble. -- fedora-devel-list mailing list fedora-devel-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-devel-list
