[linux-audio-dev] Linux and Standards

Jan Depner eviltwin69 at cableone.net
Sat Oct 30 12:25:31 UTC 2004

On Sat, 2004-10-30 at 02:23, Ivica Ico Bukvic wrote:

> I feel that considering linux as a standard is on one hand a kind of a
> paradox as it is built on the premise that individual truly can tweak it to
> heart's content and therefore it is relatively unlikely that any two Linux
> boxes would look and/or perform the same. Yet, on the flip-side of the coin
> Linux stands as a most successful offspring of the GNU movement and as such
> it is the most revolutionary and therefore the standard-setting OS in a
> category where it has no competition. Furthermore, this diversity it offers
> perhaps stands in its own light as a kind of a standard offering the
> end-user to shape their computer as a personalized instrument.
> The diversity seemingly suggests lack of standards, yet the software
> packages in most cases seamlessly compile on various distributions. This
> diversity is simply a byproduct of the diversity of the commercial Linux
> distributions. This is where lies perhaps the biggest problem with Linux,
> and that is the issue of different file tree across the different
> distributions which introduces hurdles for the "compile-from-the-source"
> crowd and in part feeds the demand for the prebuilt distros and subsequent
> fragmentation (a vicious circle if you like).
	One standard that you are missing here is the Executable and Linking
Format (ELF).  Yes, there are different distributions but an ELF object
built on one distribution will run on any other distribution as long as
all of the needed libraries (also ELF) are there.  We're all still
running Linux.  Maybe different versions of the kernel but *not*
different operating systems.  Compared to Windows and Mac OS/? this is a
major advantage.  Try running some Windows 98 programs on XP or Mac OS/9
on Mac OS/X (not that I think switching to BSD on Apple's part was a bad

> There is no "standard" audio kernel even though some of the kernel releases
> in conjunction with patches yield better performance. This diversity is
> however irrelevant as most of the applications work just fine on different
> sub-versions of the same kernel without a recompile. Therefore such
> disparity is more of a nuisance for the end-user than a potential
> standard-breaking anomaly. Furthermore the fix for such disparity is
> provided via aforementioned distributions.

	Not standard but optimized.  This is something that can't be done on a
system with a proprietary OS.  You don't have to optimize your kernel
(lowlat, preempt...) but if you don't then you'll get the same kind of
performance that you get on Windows or Macs where your only recourse is
to throw more money at the problem.

> The powerful thing about Linux is that while everyone is welcome to
> contribute their own ideas or even design their own applications from
> ground-up, the strongest concepts rather than most developed applications
> are the ones who set the standard (i.e. JACK, ALSA, etc.) which is not
> always the case with the commercial proprietary World where often PR plays a
> critical role (i.e. VHS vs. BETAMAX -- although this is not the best example
> as this is not software-related but you get my point). 

	How about Microsoft Office vs any other office suite.  There were
better ones available when the MS PR machine/monopoly made it almost a
moot point.

> That being said, Linux has its own share of disparate formats which impede
> the development of a standard (i.e. every sequencing software has a
> different format for saving the sessions). However, it is my feeling that
> this is simply a transitional phase and in due time the strongest will
> prevail.

	This is not just a Linux problem.  Every proprietary system uses a
different format.  There needs to be an open standard for session
formats and it probably won't come from a proprietary software vendor.

> One final remark on Linux standards as a whole is that Linux holds an upper
> hand when it comes to longevity of their standards as they are not
> encumbered by the IP limitations imposed by a particular company and
> therefore directly dependant on the company's longevity.

	This is possibly *the* most important point - our software vendor will
never go out of business.  If a developer decides to stop supporting an
open source project and it is important to us we can either maintain it
ourselves or pay for support from a third party.  The only way you can
do this in the proprietary world is to have some sort of agreement with
the company that if they go out of business they will open their code. 
This is often done in large corporate or government contracts but I have
never heard of anything like it in the case of off-the-shelf commercial

	Good luck with your paper.


More information about the Linux-audio-dev mailing list