On Tue, Oct 15, 2013 at 2:03 PM, Yasha Karant <[email protected]> wrote:
> From a terminal application within gnome, my default Python is: > > [ykarant@jb344 ~]$ python > Python 2.6.6 (r266:84292, Feb 21 2013, 19:26:11) > [GCC 4.4.7 20120313 (Red Hat 4.4.7-3)] on linux2 > Type "help", "copyright", "credits" or "license" for more information. > >>> > > despite having to install whatever the BlueGriffon build required. > > A number of the responses concerning the build of BlueGriffon further > underscore the general lack of polymorphism and encapsulation in the Linux > environment as distributed. In a proper modern OS environment, an > application that requires non-system versions of applications (other than > the core libraries required by the OS itself, a more daunting problem) > would have only these in the path of both the building steps and during the > execution of the built application, preferably still allowing a dynamic > rather than a static image of the built application. > > You've gone on about this before, and it's just not going to happen with this OS. SL is a rebuild of a server class operating system, not a maximal flexibility operating system. The trade-off is that there is a hope for stability and interoperability and consistent behavior from day to day, due to the consistent library versions, package layouts, and build environments. And such a multi-component, multi featured system is vulnerable to serious incompatiblities between even minor library or feature changes. Python 2.6 and Python 2.7, for example, have notable feature and syntax differences. So at run-time of particular Python modules, which is the default to select? Do all python scripts have to be written as "/usr/bin/python2.6" or "/usr/bin/python2.7"? And how is a tool author writing their Makefile or configure.ac to know? Or even just running a remote shell script. Do not get me *started* on software tools that auto-update your local workspace databases to enable new features and make it impossible to revert back to the older binaries, such as Subversion and RPM. running both versions on the same system at the same time is *fraught* with adventure. This is just not a "Linux" problem. It's a "consistent environment" problem. there have been attempts to deal with the need for multiple versions of components at the same time with the /usr/bin/Java and /usr/bin/gcc symlink fun and games, but it's an unavoidable problem, especially in a system for which the paying customers need a consistent environment and a 10 year life cycle (which our favorite upstream vendor currently provides.)
