[lsb-discuss] Why python was chosen as a part of LSB?

Theodore Ts'o tytso at mit.edu
Thu Jun 12 19:22:02 UTC 2014


On Wed, Jun 11, 2014 at 02:31:34AM +0300, Net Kgk wrote:
> Ruby is popular. Perl is popular. Javascript is popular. Any
> programing language, if it has some practical use is popular and have
> some community, so why chose only one of them?
> As far as I know, javascript is the most popular scripting language
> ever. Besides it is much more readable and faster than python. So why
> python? Just because of the fact that some distros like RedHat and
> Gentoo was so stupid to chose python as programming language for their
> packaging systems? Why not use Suse experience, then? Is it worst, or
> something?

Perhaps you're not aware of the LSB's primary goal --- which was not
to annoint one or more languages as willing some perceived "Language
War", but rather to promote the ability for third-party distributed
software packages (particularly those that were shipping compiled
binaries) to be usable across multiple distributions.

So originally, we were primarily focused on the shared library ABI's.
We added support for Posix.1 commands because many ISV's would include
shell scripts for installation and maintenance uses.

Several years ago, I was pushing for Java support because there were
some major ISV's, including IBM, which tended to ship products that
included executables as well as Java class files, and if we could make
it easy for IBM software products to ship LSB certified applications,
it would help assure that IBM would continue to support funding LSB
development.  (I make no apologies for the embracing the Golden Rule,
"He who gives the Gold, makes the Rules", because that's the way the
world works, and it was really painful, after the 2008 financial
implosition, to have to tell contracting partners who had done such an
excellent work on LSB test infrastructure that we could no longer
afford continue to fund them all, knowing that a non-trivial number of
engineers would be out of a job as a result.  It's something that
really sucks, and I hope to never have to do something like that
again.)

Anyway, it turned out the Java push didn't work out, because we
couldn't get the necessary tests licensed from Oracle that would be
needed so we could certify LSB runtime and applications which use
Java.  Which is the other aspect of why we might or might not be able
to include a language into the LSB.  There needs to be a formal and
*STABLE* specification of the interfaces between the LSB runtime
(i.e., the distribution) and the LSB application (i.e., the product
shipped by the ISV); this could include series of shell commands that
can be used by a LSB portable shell script, or it could include the
Java byte codes, or it could include the Perl or Python language spec.

There also needs to be tests so we can independently verify that the
LSB runtime (distirbution) and LSB application meet the contract
guarantees specified in the formal specification.


So given that, what might be necessary for Ruby or Javascript to be
included in a future LSB version (or future LSB module)?  First of
all, soemone needs to provide the formal written specification, and
someone needs to provide the necessary comprehensive test suites.  And
since this is often a non-trivial amount of work, very often it will
require a community or company to sponsor doing this work, and very
often this is most likely to happen when there is real money on the
table.  For example, if there were significant numbers of commercial
products that shipped Javascript or Ruby programs that ran on the
server or the desktop, that might make it more likely for a company to
be willing to donate the time or money necessary to create or refine
the specification and tests to the required levels of quality.

Now, if there is a set of open source developers who feels that their
honor has been insulted because Python was included but their favorite
language wasn't, and this was sufficient for them to do all of the
necessary work to create the formal specs and the comprehensive
runtime and application tests, that's wonderful!  I personally think
this is a good thing to do on general principles, since it tends to
expose ambiguities, and creating test suites can also help in
improving the quality of future releases of the language.  So if your
indignation is enough to drive you to want to go down that path, I'm
sure lots of people would quite happy to see it happen.

What is not so realistic, is for you to expect that *your* righteous
indignation is justification to cause *other* people to do the work
you want.  So in the terms that many open source maintainers are very
fond are saying, "if you want that feature, feel free to submit a
patch".  :-)

Cheers,

							- Ted


More information about the lsb-discuss mailing list