From alsa-devel-owner@alsa.jcu.cz  Tue Mar  2 20:17:31 1999
Received: from linuxmaster.corel.eng (internet.corel.ca [209.167.40.2])
	by marvin.jcu.cz (8.9.1a/8.9.1) with ESMTP id UAA24043
	for <alsa-devel@alsa.jcu.cz>; Tue, 2 Mar 1999 20:15:50 +0100
Received: (from news@localhost)
	by linuxmaster.corel.eng (8.8.7/8.8.7) id OAA03031
	for alsa-devel@alsa.jcu.cz; Tue, 2 Mar 1999 14:15:19 -0500
From: uo3fieoe@umail.furryterror.org (Zygo Blaxell)
Subject: Re: (SB Live) Free drivers or not? (fwd)
Date: 2 Mar 1999 14:15:10 -0500
Message-ID: <7bhdbu$u5p$1@naga.corel.eng>
References: <3.0.32.19990301130329.00969bb0@mail.inprise.com>
To: alsa-devel@alsa.jcu.cz
Reply-To: alsa-devel@alsa.jcu.cz
Sender: alsa-devel-owner@alsa.jcu.cz
Precedence: list

In article <3.0.32.19990301130329.00969bb0@mail.inprise.com>,
Kevin Duffey <alsa-devel@alsa.jcu.cz> wrote:
>Ahh..interesting. Ok..so from what you said, if I write a program using
>glibc (I guess thats libc6 right?), then as newer glibc modules come out,
>my program will still work under them? What about libc5 apps..do they work
>under glibc? Or did they have to be recompiled? 

You can install libc5 and glibc on your system and then run both libc5 and
glibc applications.  libc6 and glibc are the same thing.

If you're really sadistic, you can compile for libc4 (a.out format) and
then run on libc4, 5, _and_ 6 systems--if your users feel like installing
50 megabytes of backward-compatibility libraries on their systems.

Backward compatibility is available, but that doesn't mean you want to
use it except in unusual circumstances.

One thing that you might think will work but doesn't is to statically
compile your program, so it doesn't use any shared libraries at all
(they are built into the executable instead).  It won't work because the
kernel interfaces do change every few years.  The shared libraries are
updated at the same time, so applications linked against a shared library
will remain compatible but statically compiled applications won't.

>Familiar..nope. Not at all. I am "still" trying to set up Linux the way I
>want it, which is the basic kernel stuff, XFree86, Enlightenment and GNome.
>I haven't a clue yet as to how to do all this. My idea of learning Linux..I
>decided I was going to install the minimum on my Redhat so as to get it up
>and running. 

Big mistake.  It's much smarter to install everything on Red Hat and
then replace/remove stuff you aren't using than it is to figure out what
you need.

>Then, I would download the latest RELEASE version of each item
>I needed. I found out there are a LOT of dependencies using RPM and I am a
>little pissed on trying to use it. 

Well, you don't get something for nothing.  If you want to do package
management by yourself you need to handle dependencies between packages
by yourself.  rpm helps a lot by telling you about those dependencies
it knows about, but it's nothing like Debian that provides you with a
GUI tool for installing packages _with_ all their dependencies...

That said, you can do some pretty nifty stuff with rpm.  Example:

	zblaxell@naga:~$ rpm -q --requires vim-minimal
	vim-common  
	ld-linux.so.2  
	libc.so.6  
	libtermcap.so.2  

So 'vim-minimal' requires ld-linux.so.2.  Which package on my system 
provides that?

	zblaxell@naga:~$ rpm -q --queryformat '%{NAME} %{PROVIDES}\n' -a | grep ld-linux.so.2
	glibc ld-linux.so.2

OK, now what if I don't have the package installed?  Can I find it on the
Red Hat CD?

	zblaxell@naga:~$ mount /mnt/cdrom 
	zblaxell@naga:~$ rpm -q --queryformat '%{NAME} %{PROVIDES}\n' -p /mnt/cdrom/RedHat/RPMS/*.rpm | grep ld-linux.so.2
	glibc ld-linux.so.2

>So..I decided I would download the
>.tar.gz source files of each product, figure out how to compile them and
>what dirs they go in, and work from there. Any pointers on this would be
>appreciated. :) 

Basically you only want to do this when you absolutely have to, i.e. after
you've checked:

	Red Hat's official Linux CD-ROM
	Red Hat's official Powertools CD-ROM
	ftp://updates.redhat.com/
	ftp://rawhide.redhat.com/
	ftp://contrib.redhat.com/

and you still can't get a RPM for your architecture, or you need a newer
version, or the version you have isn't compiled correctly, or you're
developing the package in question.

>>	OSS is a standard right now.  If you write for OSS, you are
>>basically guaranteed to work on almost all platforms, unless you do it
>>wrong.   [...]
>True. OSS means giving out the source right? GPL is part of OSS, or vice

Warning!

	OSS = Open Source Software (i.e. releasing your source code)

	OSS = Open Sound System (i.e. the current kernel sound driver,
				 as opposed to ALSA)

>versa? As long as source is available, anyone can compile it for their
>version and tweak it if necessary. As Eric said, its more common that when
>someone tweaks it in some way, they let me know about the change..etc
>right? So I could somehow incorporate that into a new release or fix. Is
>that how it usually works?

Generally people who fix bugs in your code will make sure that nobody
else has to go through the effort again.  Also if their code is merged
into yours then it's less work the next time you release a version.
And you get features, ports, and bugfixes for free sometimes.

I used to patch the Linux kernel GUS driver for almost five years.
I finally got around to getting my last diffs merged in a couple of
months ago, when I got annoyed at my patch breaking for the Nth time
that I wrote an email with a patch and an offer they couldn't refuse.  ;-)

Now that Alan Cox is maintaining the sound drivers in the kernel things
are actually getting fixed.  No offense to Hannu, but he did keep leaving
out little pieces of my patches everywhere...

>I hear of Wine. Looks promising. Let me ask this. If I were to run an
>"exact" program made specifically for Linux and X, compared to one targeted
>for Win95/NT. Lets assume it has the exact same functionality, but they are
>two different platforms. Would the X version run faster, better, and less
>prone to crashes? I have heard a number of people say X and Linux are MUCH
>faster (what percentage if known??) than Windows. 

Basically the big gap between Linux and Windows perceived speed is
video drivers.  I've never seen Linux and X running video faster than
Windows on any hardware.  This is probably the fault of video hardware
vendors who do not supply adequate driver support or the technical data
required to create it, and might also be due to a lot of X applications
using crappy legacy code (e.g. Motif) which manages to be really slow on
any platform.  Note that on _some_ video cards with really awful Windows
video drivers, XFree86 is faster than the Windows drivers on the same
hardware, but then again so is a better set of Windows drivers.

Everything _but_ video seems to be faster in Linux than in Windows,
so that might change perceived speed a bit.  For example X programs
tend to queue graphic events and send them to the X server in batches
rather than using an RPC-like mechanism as in Windows.  This is better
for cache performance and context switching overhead among other things.
Also if the speed difference on non-graphic operations is bigger than
the speed difference on graphic operations then there's a net speed
improvement anyway even if the video is actually slower.

A lot of the time the only thing that distinguishes one OEM hardware
card from another is the software that comes with it.  BT848-based video
capture boards, for example, are all virtually identical (they're a BT848
chip, a mounting bracket, and a tuner chip of some kind on a card; not
much room for variation there), but if you look at the features listed on
the box you'd think that they were as different as a car and a microwave.
The difference?  Bundled software.

>So my goal was to write a music application that would be cheap yet very
>powerful. Cheap in that the "core" I would give away. The cores sole
>purpose is a simple executable and a plug-in engine. The engine loads all
>plug-ins and manages them. Basically, once a DLL (in windows) or a .so in
>Linux is loaded, it doesn't do much else but sit idle. But..it maintains a
>list of plug-ins, their library handles to keep them in memory (and later
>free them), and keeps all version info, names, types, etc. 

So why not release that as open-source?  This sounds like you're trying
to build an infrastructure, and open-source is ideal for building
infrastructure like operating systems, network servers, and development
libraries.  If you're building a closed-source infrastructure and you're
not already the market leader then everyone will ignore you because
they would prefer to pay an infrastructure tax to one of the established
market leaders (no matter how awful their product is) than to you (who
they've never heard of).  This is the way the business world works.

>That said and done, the next step are the plug-ins. I have created what I
>believe to be a far more open plug-in architecture than any current
>application uses. Basically, a plug-in is a full-blown app if need be, but
>in library form instead of executable. However, the idea is to keep to the
>original app plan..which is music. Its possible to do anything in plug-ins,
>but hopefully developers would keep the original target in mind..music and
>computers. 

You can sell all but the most trivial plug-ins as closed-source,
especially user-interface applications (but maybe leave an "example"
application that allows raw data manipulation open-source).  If you
want Intel to license one of their niftier codecs to you you'll have to
tolerate binary plug-ins anyway.

>The list goes on and on. I dont mean to publish my whole idea here. :) I
>wont go into depth. I would really love some 3rd party plug-in developers
>to eventually help me out once I get the basics working. I do have to make
>a simpel Piano Roll editor, and a track view. I plan to have a project
>manager so as to allow multiple songs loaded at once. I have tons of ideas
>for plug-ins..but since each plug-in can take from a couple of hours (an
>EVENTS editor) to many months (Score editor) to complete, I dont know if in
>the next year or so I would even have a decently running sequencer. 

<shameless plug> It won't happen any sooner if you don't release the
source you have.  ;-)

>Oh yeah..I forgot to mention the other reason why I started my music
>project. The MAIN reason is..I got so sick and tired of waiting for
>Cakewalk or Cubase to release a new version with not only bug fixes but
>KEWL kick ass features that I wanted. AND..it never would happen. Cubase

I hope you weren't seriously thinking of adding yet another Cakewalk
or Cubase to the market.  If you're going to release a closed-source
app then that's exactly what you're doing.  If you ever got a user base
then your users would think of your release schedule the same way that
you think of Cakewalk/Cubase, etc.  You end up fracturing the market
and doing more harm than good, or you become one of the market leaders
you don't like so much.

If you release an open-source replacement for these tools, then you'll
actually be doing something new and significant that benefits people in
ways you can't imagine at the moment.  Since you're open-source and your
competitors are not, you can just accumulate a critical mass of users
and then just assimilate your competition.  :-)  (OK, it's a little harder
than that in real life...)

>I want my app to allow 3rd party
>developers to develop plug-ins that make my app much more powerful, adn
>thus one day the defacto standard for music!! :) 

>I also would like to see
>studios use it, and as such plug-ins could be written to do special
>functions. 

Charge studios for installation, support, and custom development
contracts.  Use your ownership of the project (including any associated
trademarks and positive reputations in the user community) to aggressively
market yourself as _the_ supplier of support for your application.
Milk them for every penny they are worth; just don't price your services
so high that studios can finance entire third-party consulting firms
just from their cost savings of not dealing with you directly.  ;-)

Let the Red Hat's of the world integrate your application into their
OS distributions.  Think of the revenue you're not getting as marketing
expenses for your software consulting business, or arrange your services
by retainer with a company that can provide first-line support itself but
will pay you for development and significant problems.

You might want to consider the Aladdin business model--they develop
Ghostscript in non-GPL form, then some years later (always a constant
number of years) they re-release the code under the GNU license.
That means anyone who needs your latest-and-greatest pays Aladdin for
the privilege, while everyone else just waits for the re-released version
or implements their own.

There's lots of ways you can do this and still be open-source at the end
of the day.

>So..Will Linux do the job?

RT-Linux might.  The interrupt servicing jitters are pretty big on
vanilla Linux even with the realtime scheduler support for applications;
you're looking at <4 milliseconds of jitter under disk/network load
and <9 milliseconds under calculation load.  On RT-Linux the jitter is
<15 _micro_seconds under heavy disk/network/CPU load.  That on a P120, BTW.

All but the poorest studio clients will be more than happy to load a
custom Linux kernel for a production music workstation.  Heck, you could
probably sell them an entire machine pre-loaded and pre-configured.

On the other hand, with no load on the system even plain Linux can
get within a few hundred microseconds of real-time deadlines, both for
interrupt response and time interval generation.

See http://www.zentropix.com/realtime/testing.html

-- 
Zygo Blaxell, Linux Engineer, Corel Corporation, zygob@corel.ca (work),
zblaxell@furryterror.org (play).  It's my opinion, I tell you! Mine! All MINE!
Size of 'diff -Nurw [...] winehq corel' as of Tue Mar  2 13:14:00 EST 1999
Lines/files:  In 4440 / 4, Out 13185 / 221, Both 17550 / 223

