Date: Thu, 07 Nov 2002 17:31:43 -0800 From: Maksim Yevmenkin <myevmenk@exodus.net> To: Terry Lambert <tlambert2@mindspring.com> Cc: Sam Leffler <sam@errno.com>, Julian Elischer <julian@elischer.org>, arch@FreeBSD.ORG, "Long, Scott" <Scott_Long@adaptec.com>, re@FreeBSD.ORG, Murray Stokely <murray@freebsdmall.com> Subject: Re: Bluetooth code Message-ID: <3DCB13FF.14F7BD79@exodus.net> References: <Pine.BSF.4.21.0211071328530.5860-100000@InterJet.elischer.org> <038501c286b2$5efb1890$52557f42@errno.com> <3DCAFCA8.DF1FF47A@mindspring.com> <03fc01c286c1$59e2a170$52557f42@errno.com> <3DCB0EF9.617D66B5@mindspring.com>
next in thread | previous in thread | raw e-mail | index | archive | help
Terry Lambert wrote: > > Sam Leffler wrote: > > > The counterargument is "port NetGraph to NetBSD, OpenBSD, and BSDI". > > > > > > The issue that's being raised here is "Who gets to lead the parade?"; > > > the answer "Be a follower, not a leader" isn't very satisfying to > > > anyone. > > > > The issue is should we commit something to the source tree that may be of > > limited use to people. If the software provides functionality to a > > significant group of people then I'm open to its inclusion regardless of > > whether it's present in any other system. However one must not lose sight > > that adding code to the source tree has a cost, independent of whether it is > > "hooked up to the build". If the code doesn't have someone to maintain it > > as the system changes then it can become a boat anchor. > > Well, the Bluetooth code has an active developer, it has some > applications that are available for it already, and it's severable > from the main source tree in a way that boat anchors aren't. > > There's some small argument that's valid, that if ports are written > to use a Netgraph bluetooth stack, they won't be that portable to > other BSD's that don't have Netgraph. This is a valid argument, > but it appears that NetBSD doesn't even have real Bluetooth at this, > point, so it's kind of moot. the ports *will not* be tied to the Netgraph. they *never were*. there is no reason to re-invent the wheel. my current ports are from Linux BlueZ include SDP, RFCOMM, hcidump and l2test. ports *do use* similar API - Bluetooth sockets. what i do is 1) remove autoconf 2) fix #include's 3) fix constant's etc. 4) remove/rewrite some Linux specific stuff it usually takes about 4 hours to make a complete working port (including basic interoperability testing). BlueZ author and i currently discussing common API to make porting even easier. Linux is more advanced in Bluetooth (Linux has three(!) stacks: BlueZ, Affix and OpenBT). i'm trying to learn from them and do not make the same mistakes. > > Code rot is unhealthy for maintaining quality software. Code rot > > happens quickly when noone uses it. > > I disagree. There is no such thing as code rot. There are only > jerks who changes working interfaces, and fail to maintain the > code that uses them. I have an example list a mile long on that > one, too. Institutionalizing the acceptability of "code rot" is > institutionalizing the acceptability of being a jerk. It's a > completely seperate issue from whether or not code falls into > disuse. max To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?3DCB13FF.14F7BD79>