Introduction
With the birth of each new Distribution comes slight deviations in design, coding, filesystem structure, all done in the interest of enhancing some aspect of the Linux experience, be it a set of pre-installed applications, a specific graphical user interface or a specific stack of applications implemented and provisioned for a special business or consumer purpose. (Image Credit: IBM Press Redbooks)
This quilt-work of Distributions reflects a strong willingness to invest development efforts in Linux and is a positive indicator of just how popular it has become.
By the same token, there is a corresponding perceived risk that inconsistencies and incompatibilities may arise born of the need to make changes driven by special interests and the need to make functional improvements. There is also in addition to natural variation an increased possibility for introduction of unintended errors, the result of neglect of implied standards of one kind or another that should be adhered to, but go unnoticed until after production general release.
A Standards Group is Established
The realization that there ought to be some form of standardization was recognized by the Linux Foundation which on June 29, 2001 established version 1.0 of the Linux Standard Base (LSB).
From the Linux Foundation's LSB website 'Workgroups' page opening paragraph:
"The Linux Standard Base was created to lower the overall costs of supporting the Linux platform. By reducing the differences between individual Linux distributions, the LSB greatly reduces the costs involved with porting applications to different distributions, as well as lowers the cost and effort involved in after-market support of those applications."
That short summary encapsulates the intentions of LSB fairly well.
A list of LSB-certified Linux Distributions is found here.
LSB has gone through revisions reaching version 4.11 on February 16, 2011.
The LSB Misnomer and Misconception
The misnomer:
Is LSB achieving it's goals, or, does fragmentation live on despite the clear need for standardization? That, in essence, is the misnomer. A standard misapplied or largely ignored is not a standard at all when other 'de facto' standards eclipse it.
The misconception:
The misconception stems from resistance offered by Developer 'camps' who perceive standardization as a form of unwanted change or a form of unwelcome 'control', when, in fact, standardization would potentially streamline and reduce complexities inherent in the diverse Linux ecosystem, lowering operating costs, simultaneously achieving increased ease of use and conferring an automatic rise in popularity.
Continuing with the argument for the need for standardization, add to the mix variations in upstream development interests and you begin to see a large potential for conflicts of interest:
Some developers simply might not take interest in work or maintenance to an upstream package unless it effects 'their' Distro, for example. Or, if it is a large body of developers, such as the Debian community, software release management policy may dictate that work move pragmatically and in some cases at an arbitrarily slow pace which may become unacceptable in today's Internet time scale where technology changes almost by the minute.
The perceived risk for lack of standardization is quite real and there are indeed resultant variations, structural and feature-based inconsistencies, along with an array of independently-developed package management systems. Taking Debian for example:
Depending on which Distro is chosen, dictates which package manager can or cannot be used. As such, there has been no universal package manager that would allow an application to reliably install on any Distro.
Diverging methodologies and interests formed naturally through time and the popularity of Debian and it's sibling derivative Ubuntu has resulted in the Apt-get package management ecosystem becoming a virtual 'de facto' standard, for example. Resistance to using that which appears 'foreign' regardless of its intended benefit becomes human nature. Thus 'loyalties' and political interests develop centered around use of specific technologies independent of whether a broader standard would accrue a realized benefit.
Uniformity and Ease of Software Development
As an example of the effect of uniformity, it is acknowledged that Microsoft Windows has been a singular success by virtue of being largely 'one set of code' with one API code path for all Developers to follow (arguments for minor variations in 32- vs 64-bit code trees aside).The result during the nineties up to present starting with Windows 3.1 has been adoption of a singular API. Every Developer could and still can assume that when they write to Windows, it will run on all Windows PCs, irrespective of the OEM hardware vendor.
Should not this be the case for Linux? I submit the answer should be yes, but regret that it isn't generally true that writing an App for Linux confers automatic ability for it to run on all Distros and, much less, on all hardware.
Reducing common denominators, unifying file structures, joining up to embrace a standard which employs a 'common' package management system all are standards-based compliance issues for Linux to truly broaden its World user base. If this isn't done, there will continue to be fractious, limited, smaller communities with orbiting spheres of politically-driven interests, localized to the technical merits of one particular Distro seeking competing market share over others.
Unix has done well largely because of A.T. & T. Unix as a commercial product. Apple and Windows both surface for developers their own unified APIs which can safely be followed ensuring that side-effect bugs will be minimal. As popular as Linux is, adoption of standards such as POSIX shows that choosing your path wisely can ensure a truly portable operating system and/or application.
LSB Compliancy Test Kit
The argument for standardization is clear. As demand for increased Linux commercial and consumer-based production grows, so, too, will demand for increased uniformity, simplification and standardization follow.
If your organization has plans to adopt and scale up use of Linux-based system deployment, it would behoove them to certify and use only those Distros which are fully LSB-compliant.
To determine whether your preferred Distro is Linux Standard Base compliant, you may download a test kit here.
-- Dietrich
0 comments:
Post a Comment