30 Oct
2004
30 Oct
'04
8:10 a.m.
On Sat, 2004-10-30 at 02:23, Ivica Ico Bukvic wrote:
LINUX AS A STANDARD
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.
PLANET CCRMA/DeMuDi/THAC'S RPMS/AUDIOSLACK
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
idea).
KERNELS
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.
APPLICATIONS
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
products.
Good luck with your paper.
Jan