On 10/16/2013 03:46 AM, Nico Kadel-Garcia wrote:
On Tue, Oct 15, 2013 at 2:03 PM, Yasha Karant <ykar...@csusb.edu <mailto:ykar...@csusb.edu>> 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 <http://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.)
You may oppose modern software engineering design and implementation principles and practices. I have never proposed a lack of stability or reliability in any environment, whether that environment is an operating system or an end-user application specific to only one segment of the population.
Indeed, the designed language or environment that is required by a build should be specified in the build. If Application N.m is required, it should be specified.
As you factually point out, a number of the core applications (such as RPM or other production maintenance utilities) routinely are updated by TUV and even by the community (other software application maintainers, both for-profit and commons) and then auto-update, and do not necessarily maintain backward compatibility.
In some cases, there is no choice due to either an algorithmic shortcoming or a fundamental implementation shortcoming, typically one that results in the possibility of a major security compromise on a network-attached node ("hack" or "attack" vulnerability to exploit). In most cases, however, the cause merely is new capabilities or features, or a change in the underlying standard due to newer technologies and loss of other technologies from the wild.
One can have a stable environment with polymorphism and encapsulation, but this is not easy, particularly for heritage implementations.
Yasha Karant
