[linux-audio-user] (OSS vs. RME) vs. (OSS + RME) [slightly OT]

vord vordhosbn at gmail.com
Thu Dec 16 23:30:15 EST 2004


On Thu, 16 Dec 2004 20:14:12 -0700, thewade <pdman at aproximation.org> wrote:
> > Correct me if I'm wrong here ... but ... lack of supported hardware is
> > part of the reason people don't migrate to *nix operating systems; and
> > another is the frightening complexity involved in doing anything with
> > *nix which the OS and its software inherits from the relatively small,
> > disorganized, underfunded community.
> 
> Minor correction: More hardware is supported in linux then in windows/mac
> as far as I can tell. For example when I bought my 64 bit laptop there
> was already a kernel and it took about 1 month to get most of the devices
> working: one exception - Ralink rt2500 (just recently because of GPL
> release of drivers).
> Everything else basically works. 

[sniped]

In my experience this is not the case. Perhaps I should clarify by
stating "full compatibility" rather than mere compatibility; I feel
compatibility itself is enough to keep my point valid, though -- if
people know their hardware will work in Linux as it does in Win32 they
can no longer use compatibility as an excuse.

> You are correct about the problem with complexity of setup and operation.
> One problem with Windows/Mac; if you make the interface simple to use the
> user of the computer becomes simple as a consequence. If you know about
> your hardware, are forced to learn, then you know something and are
> wiser. People are generally either lazy or too busy for linux.

definitely.

[snip]

> Finally to address your issue about RME: It sounds like a short term
> solution. Sure they release drivers, it works now. What happens when
> something new comes along and thoes drivers need to be rewritten or
> modified? You have to wait for RME to get around to fixing it, and who
> knows what the quality of their solution would be? We would be
> sacrificing that power we gain from having a worldwide distribution
> of coders pouring over the code and constantly evolving it.

The "short-term" nature of the solution is actually the whole point.
Our development entity, by virtue of creating full linux compatibility
for their hardware, opens their market to linux users. Profits
increase for them, community increases for us. But thats only part of
the trade-off -- the major gain for us comes after their market
expands. Slowly but surely they will build linux compatibility into
their organization, taking over where we left off -- otherwise their
margins go down [which is incentive enough not to do it] -- and thus
the involvement of that development team is necessarily short-term,
and is so by design.

But yes, in the meanwhile the burden is on the development entity to
keep the manufacturers linux-using customers satisfied [if they don't,
they risk wasting their time and making people switch off of linux];
and this is, I admit, an ironic position in which to put any
developer. At any rate, if enough Linux users are visibly purchasing
their hardware and using our drivers [and i assure you, we can make
this very visible], the manufacturer will no doubt do one of two
things with reference to their new hardware lines or firmware updates
to existing lines, depending on their resources: (1) as stated above,
hire people to develop the necessary code to give
support/compatibility to CURRENT and FUTURE customers using linux, [or
perhaps start paying the initial development people to do it?] (2)
give our development team advanced warning and/or access to their new
designs in advance in order to not alienate the linux community -- and
this is what we want, simply to not be left out. So it isn't RME who
has to fix anything, its the people who've signed the NDA who're
responsible. And you are right about the sacrifice involved since more
than likely most manufacturers would opt to keep their code closed, at
least in the beginning. To me, though, it is still an improvement on
the current situation to have support for linux ... even if we cant
[immediately] have the code.

So rather than making my model out to be a "short-term solution" to
the compatibility problem, it is best to view the problem you bring up
as a problem that only exists before the change is made on their end
[the inevitable change toward accommodating the linux community in one
way or another once the linux community becomes a visible and proven
market] -- more precisely, as a short-term problem that inevitably
goes away.
 
The nature of business [profitability] and the nature of OSS are
currently butting heads. Apparently catering to linux users is not
viewed as profitable so there is no incentive to do so -- all I
suggest is that we give them some, and that we do so by testing our
principles in the real world in a new way. If the OSS model is truly
better for everyone [or at least enough of everyone such that hardware
should come with drivers for it] we have to prove it to the people who
make hardware -- we do this by stepping up to the plate and doing what
we do best: fearlessly sharing our knowledge and skills.

> My 2 cents,
> -thewade

and mine,
--vord



More information about the Linux-audio-user mailing list