On 10/16/2013 03:46 AM, Nico Kadel-Garcia wrote:
> On Tue, Oct 15, 2013 at 2:03 PM, Yasha Karant <[log in to unmask]
> <mailto:[log in to unmask]>> 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