All of lore.kernel.org
 help / color / mirror / Atom feed
From: Joe Miklojcik <jmik@nbcs.rutgers.edu>
To: linux-sound@vger.kernel.org
Subject: Re: [linux-audio-dev] Re: 4D-NXs (was Re: Sync Issues)
Date: Thu, 28 Oct 1999 18:08:35 +0000	[thread overview]
Message-ID: <marc-linux-sound-94114191816205@msgid-missing> (raw)

Dan Hollis wrote:

> On Wed, 27 Oct 1999, Paul Barton-Davis wrote:
> >       * "we don't have enough programmers to do that"
>
> If the drivers are being written for them by volunteers, I dont see how
> this is relevant.

They just can't imagine anybody who isn't in their shop writing a driver.
It's a really crappy job.

> >       * "we don't have any written documentation to give you guys -
> >          we wrote the driver by having the software group sit in with
> >        the hardware group"
>
> This should be a warning sign to anyone thinking of purchasing their
> hardware. If a company cant be bothered to internally document the
> hardware, what happens if key engineers leave the company? Oh dear, their
> project is *permanently screwed*, which means zero support for end users.
> This is no way to run a company.

I agree.  A couple of years ago, I badgered Opcode into giving me specs for
their 8Port/SE under NDA so I could write a Linux driver for myself.  It
took three passes just to convince them that I could do it if I had the
specs, even if I didn't work in their shop.  It took two more passes to
convince them that I would honor the NDA as I would any other legal
obligation, and that I would furnish any results I gained working with
NDA protected material back to them.  Never mind Open Source, these guys
didn't want me to know their deep dark "how to use a parallel
port" secrets.  Turns out the real reason it was pulling teeth to get their
spec is that the spec revealed how shoddy of an engineering job the 8Port/SE
was.  I wound up destroying the spec and giving the unit to a Windows
sufferer.

>
> >       * "we think our hardware's proprietary secrets will be revealed
> >          if there is a source code driver"
>
> Uh, isnt this what patents are for? If someone reverse engineers their
> card, they are *completely screwed* unless they have patent protection.

Shhh :)  They haven't figured that out yet.  It's the only thing saving us
on a lot of the hardware Linux supports.  I'm not a lawyer, but I think that
they can deny the right to reverse engineer in a user license, which would
make some drivers illegal.  This leads to the silly phrase

"If drivers are outlawed, only outlaws will have drivers."

--
Joe Miklojcik - NBCS System Programmer - http://oss.rutgers.edu
The purpose of computing is insight, not numbers. --Richard W. Hamming, 1962

             reply	other threads:[~1999-10-28 18:08 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
1999-10-28 18:08 Joe Miklojcik [this message]
1999-10-28 18:14 ` [linux-audio-dev] Re: 4D-NXs (was Re: Sync Issues) Dan Hollis

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=marc-linux-sound-94114191816205@msgid-missing \
    --to=jmik@nbcs.rutgers.edu \
    --cc=linux-sound@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.