From: "Nicholas A. Preyss" <nalp@gmx.net>
To: BlueZ Mailing List <bluez-devel@lists.sourceforge.net>
Subject: Re: [Bluez-devel] Questions about BlueZ in commercial use
Date: Sun, 27 Jun 2004 23:42:33 +0200 [thread overview]
Message-ID: <20040627214233.GA26576@gmx.net> (raw)
In-Reply-To: <1088369388.3774.88.camel@pegasus>
On 0, Marcel Holtmann <marcel@holtmann.org> wrote:
> the current USB subsystem (as of 2.6.7) is not as bad as you think.
> Actually it is working very nice and even the hci_usb driver didn't
> crash anymore. Anyhow the problem is not USB. We made all of them by
> ourself :(
I think the problem is USB. It is too complicated for the least cost
market. So many manufacturers built chips or firmware for USB devices
which are not spec compliant. Additionaly there are so many bad
programmed driver.
I think this is a design failure, even if it only appears as bad driver
implementations.
> > The debian project shows that if you really want such high quality
> > standards for use in embedded devices e.g. it is possible to keep your
> > own stable branch. I think it is very easy with a good Changelog.
>
> I really like the Debian way of forking a stable version and only doing
> security or bugfixes. The problem is that this needs a lot of man power
> and costs a lot of time. I know what I am talking about, because I did
> all the 2.4 kernel backports of the Bluetooth subsystem.
A company would need to do this for the version they use in production
systems only. So it should be possible.
> If we got a number of companies that help sponsoring the BlueZ itself
> and its official qualification I can think of such a fork. At that point
> it makes sense to me and is worth the extra work.
I didn't thought of you maintaining such a stable fork. But like in the
debian project, the developers who need this high quality standard, care
for the branch themselves. Then you need to assure only, that all fixes you
apply are documented and published, even if you fix them with a new feature
that doesn't go into the stable tree.
nicholas
-------------------------------------------------------
This SF.Net email sponsored by Black Hat Briefings & Training.
Attend Black Hat Briefings & Training, Las Vegas July 24-29 -
digital self defense, top technical experts, no vendor pitches,
unmatched networking opportunities. Visit www.blackhat.com
_______________________________________________
Bluez-devel mailing list
Bluez-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bluez-devel
next prev parent reply other threads:[~2004-06-27 21:42 UTC|newest]
Thread overview: 33+ messages / expand[flat|nested] mbox.gz Atom feed top
2004-06-27 9:47 [Bluez-devel] Questions about BlueZ in commercial use KeiHachi
2004-06-27 12:52 ` Nicholas A. Preyss
2004-06-27 14:45 ` KeiHachi
2004-06-27 17:13 ` Nicholas A. Preyss
2004-06-28 16:30 ` KeiHachi
2004-06-28 17:22 ` Marcel Holtmann
2004-06-27 18:29 ` Marcel Holtmann
2004-06-28 16:33 ` KeiHachi
2004-06-28 17:45 ` Marcel Holtmann
2004-06-28 14:39 ` Ademar de Souza Reis Jr.
2004-06-28 14:48 ` Marcel Holtmann
2004-06-28 15:19 ` Ademar de Souza Reis Jr.
2004-06-28 15:38 ` Marcel Holtmann
2004-06-28 15:59 ` Stephen Crane
2004-06-28 17:06 ` Ademar de Souza Reis Jr.
2004-06-28 17:15 ` Marcel Holtmann
2004-06-27 18:09 ` Marcel Holtmann
2004-06-27 19:10 ` Nicholas A. Preyss
2004-06-27 19:09 ` Marcel Holtmann
2004-06-27 20:34 ` Nicholas A. Preyss
2004-06-27 20:49 ` Marcel Holtmann
2004-06-27 21:42 ` Nicholas A. Preyss [this message]
2004-06-28 7:37 ` Marcel Holtmann
2004-06-28 16:28 ` KeiHachi
2004-06-28 17:13 ` Marcel Holtmann
2004-06-29 17:08 ` KeiHachi
2004-06-29 17:41 ` Marcel Holtmann
2004-06-30 16:22 ` KeiHachi
2004-06-30 18:11 ` Marcel Holtmann
2004-07-04 8:57 ` KeiHachi
2004-07-04 11:38 ` Marcel Holtmann
2004-07-04 13:19 ` Peter Favrholdt
2004-07-04 13:47 ` Marcel Holtmann
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=20040627214233.GA26576@gmx.net \
--to=nalp@gmx.net \
--cc=bluez-devel@lists.sourceforge.net \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox