I have 5.8GHz phones. They don't interfere with 802.11[bg] at all. They don't even interfere with 802.11a because the frequencies there are approx 5.4GHz.
Michael Eisner is quoted in the press as saying that he didn't want to risk having certain tax benefit revoked by distributing a film that was so political.
Kirk has been involved with FreeBSD since forever and knows damn well that FreeBSD isn't documenting where code contributions come from any differently than Linux is.
FreeBSD commmit messages routinely contain submitted by: lines. The commit logs are routinely scrubbed for contributors that wind up in the handbook. FreeBSD has been using CVS for 8 years longer than Linus has been using bk, which documents where changes come from much better than linux's former source code control system. The FreeBSD core team polices the FreeBSD committers to ensure that these policies are followed (I'm on the core team, and we get maybe about 1 or 2 failed attributions a year our of thousands of changes I'd guess).
Linux has been much more cavalier about documenting where code came from in the past. The situation is being changed, but to say that isn't so is to engage in revisionist history. Kirk knows what he's talking about here, and was fair in his characterization of the current state of affairs in the Linux world.
In theory, you need a CVS diff list at least. However, unless the commit comments are linked to a meaningful entry somewhere that shows where a change come from, you will have problems. It doesn't matter whether you use CVS or BK, you still need underlying mechanisms. One issue with Linux, is that it has a lot more contributors than *BSD, which tends to make things more complicated.
cvs annotate is an excellent first start to see where code came into the tree. Other tools allow one to see where the code really came from in the face of formatting changes and the like.
Like I've said in prior posts, having this information is invaluable. It also allows one to more easily back out changes that might be tainted, reguardless of where they come from, since you know all the parts to that change, which is impossible with the changelog data. In this respect, bk is better than cvs since bk's change mechanism links multiple files that have changed, while CVS does not.
In the commercial world, you have change numbers which link to a documentation trail which shows who implemented something and why and who approved it. Linus is trying at least to improve the code provenance by looking at a certification chain between the patch generator, the maintainer and eventually Linus as release manager. Unfortunately, it still looks like a hunt through LKML for the documentation as you suggest.
You *MAY* have this, or you may not. There are many shops that don't have this level of beaurocracy. However, I've never worked for any place that has had this independent of an underlying source code control system (and many places that didn't have source code control systems, let alone change numbers).
The issue can be further complicated if there's been a cross fertilization between projects for things like device drivers. Project A figures out how to do feature Z and project B integrates it. B then figures out Y and project A integrates that. Project C takes code from a data sheet and includes that under license X and Project A then takes it and incldues it under license Y and then Project B wants to bring it it, but is unsure if they can because they see substantially similar code under both X and Y licenses, not being aware of the common datasheet code example being present and gets confused. In situations like this, a clear SCM trail can help sort out who to talk to and how to resolve what might appear to be something bad.
I've seen many organic patches/drivers grow up over the years in linux that are litterally impossible to track down who wrote what originally. Some have email addresses, some do not, some have had them removed, some email addresses are stale, etc. In such a chaotic enviornment, it can be difficult to know where code came from. There are many strengths to this model, but code history isn't one of them.
The changelog is insufficient documentation. It contains vague attributions that something changed somewhere in the code. It isn't specific as to what lines of code changed. Later, when you go back and try to find where a set of lines came from, a changelog doesn't help much.
With a source code control system, you know that so and so added on such and such a date. You can then go to that person and ask them where they got it from if there's ever any question.
In the BSD world (I do a lot with FreeBSD), this has come in very handy when code disputes come up. Being able to talk to the actual people that inserted the code into FreeBSD has helped to clear up what otherwise might have been viewed as something improper.
I've tried to do similar things with versions of linux in the past, only to discover that I could, at best, find what version they came into the tree at, and who collected the patch and sent it to Linus. I wasn't able to track it further without searching public mailing lists for the information (with mixed results).
while you might believe that it will take 20 minutes to identify the code in question, my guess is that's overly optimistic, unless the code in question was contributed since bk. It usually takes me at least 5 minutes to find out where code comes from in FreeBSD when there's a question, and cvs annotate makes the process *MUCH* faster.
I'm not sure I'd disagree with your comments about SCO being able to come up with where the code came from relative to Linux.
Part of the problem with free trade is that the capital is free to move from place to place, but the labor isn't. That's what creates this problem. If indians could come to the US, that would drive up prices in the indian market and drive down prices in the us because things would equalize. There's two reasons this doesn't happen: 1) taking advantage of inqueities is what makes the capitalists money and 2) no domestic politician wants to look weak on imigration that takes jobs away from americans.
That's not wearing out, that's becoming obsolete. The OS does the same things now, on the same hardware as it did then.
You miss my point. You are evaluating a narrow set of criteria like an engineer (does it do exactly the same thing on the same hardware), where most people evaluate things on a higher level (does it get X job done). Software wears out by becoming obsolete for the task you bought it, just as a car wears out when you can no longer drive it to work. This could be because it is obsolete, or it could be because it costs to much to fix.
Re:The Microsoft line of products is still support
on
Oldest Supported Software?
·
· Score: 4, Insightful
A car company will still provide parts for their older products for decades.
They are only required by law to support it for a limited number of years (like 15). I have a 1992 Toyota Passeo and it is getting harder and harder to find parts for it. There are regulations that vary from country about how long a car has to have spare parts available for it.
The other side of it is, of course, software usually doesn't wear out over time.
This is a falacy. While it doesn't wear out in the traditional sense of physical wear and tear, it does wear out in other ways. Software written for an industry in 1990 will be ill equipt to handle changes in regulation and other external forces. It may have implemented the meta function of 'sells widgets to customers in 1990' perfectly, but it will decay in its ability to support the meta function 'sells widgets to customers under today's regs' as it gets further from 1990.
Finally, OSes also wear out. How? because the hardware that they were originally deployed on breaks over time, and is replaced by newer hardware. Often time the newer hardware needs additional support not present in the old hardware. Window 3.1 would have problems with many of today's motherboard because they do interrupt routing differently than was done way back when. It would also not support newer hardware that's easier to buy than older hardware. There may also be issues with memory size, disk size, etc that keep it from operating correctly, even though it has grown no new 'bugs' over the years.
Copyright law is the basis of the GPL. Copyright law says that the original holder of the copyright has the exclusive right to copy a work. The only way you can copy a work that has Copyright protection is with the permission of the author (or some other cases involving fair use that aren't relevant to this post). Most Copyright business happens as a result of contracts between the Copyright holder and those that make copies. In the book industry, the author sells his right to make copies, in some fashion, to the publisher. The publisher then creates the copies consistant with the contract, sells them and gives the author the amount of money that he or she is due (sometimes this figure is $0). This is no different than the FSF granting permission to copy a work based on a set of terms and conditions. People that publish 'political' or 'religious' works often do similar things. Many pamphlets I see contain words to the effect of "verbatum copies of this may be made without charge or further permission of X, the lawful copyright holder of this work." The GPL is based solidly in contract law, and is very similar to other software licenses in that it grants the ability to copy in a certain way, so long as certain terms are obeyed. The fact that the details of these terms differs is somewhat irrelevant when one is testing the validity of the licenese. To the extent that they are lawful is the only test that matters. And since they are lawful, SCO's claims not-with-standing, the contract is valid.
SCO's claims do merrit some analysis. The core of their complaint, is that federal law precludes copying. However, the copyright law specifically states that the copying cannot happen, absent permission. They seem to have conveniently overlooked the permission part.
Title 17, chapter 1, section 106 states:
the owner of copyright under this title has the
exclusive rights to do and to authorize any of the following:
(1)..to reproduce the copyrighted work in copies...
The other sections of the copyright act just restrict the extent to which restrictions can be made on the restrictions to make copies.
Section 117 is the one that sco is likely relying on. Notice its wording:
(a) Making of Additional Copy or Adaptation by Owner of Copy. -
Notwithstanding the provisions of section 106, it is not an infringement for the owner of a copy of a computer program to make or authorize the making of another copy or adaptation of that computer program provided:
(1) that such a new copy or adaptation is created as an essential step in the utilization of the computer program in conjunction with a machine and that it is used in no other manner, or
(2) that such new copy or adaptation is for archival purposes only and that all archival copies are destroyed in the event that continued possession of the computer program should cease to be rightful.
Notice here how the law allows additional rights to copy. It does not say that other types of copying is necessarily prohibited, just that the author cannot prohibit the actions listed. SCO's argument seems to state that it is the other way around: since federal law requires copyright holders to allow these sorts of copies, it only allows these sorts of copies to be made. That's a stretch by my standards.
FreeBSD already supports gdb over firewire using the firewire bridge ability to DMA to/from any location of memory. Very handy for remote kernel debugging.
Leap seconds are evil. As someone who has spent way too many hours programming high precision time distribution systems to deal with leap seconds, I'd say 'good riddance, don't let the door hit you on the way out. Sites that have to deal with them typically shut down near leap seconds to avoid any glitches. The amount of time wasted on this problem boggles the mind.
BSD was able to give AT&T the finger by rewriting the entire code base.
Note entirely true. 4.3BSD NET2 had some USL code in it. That's what the 1995 lawsuit was about. The various BSD projects replaced their 4.3NET2 based code with 4.4LITE code which was explicitly covered by the AT&T/UCB agreements. Part of that agreement was that a certain number of files that were alleged to contain USL code were explicitly released under the BSD license.
Chances are good that someone saw these copyright notices and failed to read them far enough:
* Copyright (c) 1982, 1986, 1990, 1991, 1993
* The Regents of the University of California. All rights reserved.
* (c) UNIX System Laboratories, Inc.
* All or some portions of this file are derived from material licensed
* to the University of California by American Telephone and Telegraph
* Co. or Unix System Laboratories, Inc. and are reproduced herein with
* the permission of UNIX System Laboratories, Inc.
Notice the "reproduced herein with the permission of" in there.:-)
USL and UCB have an explicit agreement that allows
for certain files to be distributed under the BSD license in 4.4-LITE and 4.4-LITE2. {Open,Net,Free}BSD distribute the code under that license, adhereing to those terms. I strongly believe that there's no violation of USL's other IP at all, unless there are patent issues that are being claimed. I suspect that somebody downloaded the source, freaked out and is trying to rewrite the settlement of the 1995 lawsuit to get more money from their revenue stream. I don't know if the 1995 lawsuit covered patents or not, but most of the core patents for Unix have passed into the public domain through explicit action, or the passage of time.
I don't know about Windows or MacOS, but I don't believe Linux or Open/Free/NetBSD use any copywritten UNIX IP code in their kernels. Do they?
4.4 Lite does have about a dozen files that have
USL copyright notices on them. These files are explicitly covered by the USL/UCB lawsuit settlement of 1995. I don't know about Linux, but
since *BSD is derived from 4.4-LITE, chances are good they all have them. I know for sure that FreeBSD has them.
My Personal opinion is that this is a tempest in a teapot by someone who doesn't know history or the agreements that they purchased along with the IP from SCO.
Re:Similar problem with Adaptec
on
Sun vs. OpenBSD?
·
· Score: 2
So maybe I'm just not talking to the right person, but it does look like the company is saying one thing and doing another.
Have you even tried getting on the phone and calling their documentation department? In the past I've found no register level docs on the web site, but was able to get paper copies w/o much hassle by calling them and ordering it.
Also, the ahc/ahd drivers are still the amoung the best supported drivers in FreeBSD. They deal with all the various quirks of the chips very well, and kick ass in terms of performance. Justin Gibbs has been writing these drivers for years and years and years, even before going to work for adaptec.
The driver is full source, even source for the sequencer on the chip. Most other vendors don't go to that level of source code availaibilty. Most vendors give a binary blob to load onto the card for the on-board sequencer.
In short, I don't think that you have the first clue what you are talking about here.
As to Theo and Adaptec, well, he's a total pain to deal with and seems to be telling a radically different story about his experiences with Adaptec than the folks that work for Adaptec tell. I suspect that a similar thing is going on with Sun. I have friends that are doing the FreeBSD sparc64 work and they have indicated that Sun has been forthcoming with documetnation and hardware for their efforts. Maybe Theo isn't getting what he wants because he's a total jerk to people and they react to that.
Not as much of a stretch maybe as Parker Brothers claiming the word clue.com.;)
It was Hasbro that also tried to claim clue.com and ultimately wound up losing, not parker brothers. I know the owner of clue.com personally, and got to hear all about the multi-year legal battle.
any project above 50 KLOCs and with 100 revisions on average would be pushing the limits.
Tell that to FreeBSD, OpenBSD, NetBSD, XFree86,
all of which are orders of magnitude larger than the linux kernel. All of them have been using CVS for the past 8-10 years (depending on how you count things). Sure, cvs has its limitations, but the Linux kernel with its small number of developers with write access isn't pushing the limits. FreeBSD has over 250 people committing to its tree right now, for example.
Keeping up with rescent trends in technology and always not to be outdone, FreeBSD 4.5-RELEASE now comes with the 'Self-Power'
option.
...
All that is needed is a 9V battery to kick start the system into effect
Actually, you misunderstand. The Self-Power option is so that FreeBSD can be the first OS to ship in the "potateo powered web server" configuration out of the box, rather than needing
patches to the base OS to do that.
IPtables and Rusty's Netfilter code has been kicking ipfilter's
proverbial ass since the first release of Linux 2.4, both in terms of features and security
Except that isn't true. there have been a number of issues with the way that iptables/netfilter in linux interacts with some systems. A number of problems related to timers in the state engine have come to light and do cause real problems for some systems. Also, 2.4 was relatively recent in history, so all the problems and issues with iptables/netfitler cannot be known yet. To assert otherwise is to ignore the history of software. All software has a hype cycle: The latest thing is always the best, then experience shows that it doesn't handle this or that right, followed by the disillusionment phase followed by the adopting another product that's in the hype phase. ipfilter is much farther along in this process and is maturing nicely. We have not had the history to know yet if iptables/netfilter will be the same.
If you don't believe me, go back and look at the press that each new Linux release gets. Then look at how people talk about that release 3-6 months later, and then 1-2 years later. It takes time for problems to be diagnoised and understood.
You've described good OO boundaries in some ways. I've seen good OO and bad OO in the engeering field. I've seen good OO where the stats stuff was written once and everybody used it. I've seen bad OO where stats were rewritten all over the place by people of different skill levels.
Stats is just one example of several. We do control systems and have control system base classes that allow us to model the control system by breaking it up into a measurement side and a control side and treating things generically. It works very well.
As you gain a wider experience, you'll find that most systems can be modeled with a good set of abstract concepts. We've found it has helped up tremendously. For example, when we write a new control system, generally all we need to do is to write measurement and control objects for the hardware that we don't already have these objects for and then write some custom plumbing code to tie all the objects together to match the wiring of the actual system (well, more or less, but that gives the right flavor). We don't have to write PID controllers each time, or simple alignment operations or any of the more complex data filtering algorithms we use to keep the control systems stable.
Yes, I know I'm being a little vague, but to fully describe things would take more space than is appropriate for this forum. Then again, the question was kinda vague...
If you had two access points talking to each other via special external antennas, then extra power would be a good thing, assuming you are under the FCC limits.
100mW is still well below the threshold of RF heating. I'd be surprised if even standing in
the beem of the 24dBi dish antennas would be harmful. I know several people that have done so with no ill effects.
But I guess that experience is no substitute for good theory:-)
I guess my point was WHICH registers are set and
how can I tweak the FreeBSD wi driver to have an
ioctl to allow me to set them for orinoco cards.
I have a wireless link that is based on FreeBSD boxes and a few extra db is all I need to overcome
the leaves in the summer, and snow storms in the
winter.
Since I control both ends, I can boost the power
symetrically and still be within the FCC guidelines for radiated power (I'm about 10dBi
under the limit if I read the power meter I have
correctly). Yes, I've taken the gain of my
antennas into account. No, I can't buy larger
antennas because 24dBi is the largest that will
mount on my roof.
So I'm left with getting an amp, or having the
cards put out more power. I'd like to avoid an
amp...
Well, a card is cheaper, but a card, and an adapter and a computer isn't. The access points
are in the $100 range, and the card takes up at least $75 of that. It takes a lot of scrounging to put together a machine with ethernet for $25.
And the access points are a lot more convenient to reset.
And the Linux AP code still has some issues, so
it needs kicking more often than the access points
do (at least that's what people that have used
both tellme, I don't run the Linux AP code).
And an access point takes up less power than the
$25 486 DX + ethernet card + monitor (well, if you
are lucky, you can run serial) that you were able
to scrounge.
Slashdot Mirror
I've been using my 5.8GHz phones for some time now, and I've had no interference with my 802.11a network at all. My phone doesn't use 2.4GHz at all.
I have 5.8GHz phones. They don't interfere with 802.11[bg] at all. They don't even interfere with 802.11a because the frequencies there are approx 5.4GHz.
No. 5.8GHz won't interfere with your wireless network. 802.11[bg] is at 2.4GHz, and 802.11a is at 5.4GHz.
Michael Eisner is quoted in the press as saying that he didn't want to risk having certain tax benefit revoked by distributing a film that was so political.
FreeBSD commmit messages routinely contain submitted by: lines. The commit logs are routinely scrubbed for contributors that wind up in the handbook. FreeBSD has been using CVS for 8 years longer than Linus has been using bk, which documents where changes come from much better than linux's former source code control system. The FreeBSD core team polices the FreeBSD committers to ensure that these policies are followed (I'm on the core team, and we get maybe about 1 or 2 failed attributions a year our of thousands of changes I'd guess).
Linux has been much more cavalier about documenting where code came from in the past. The situation is being changed, but to say that isn't so is to engage in revisionist history. Kirk knows what he's talking about here, and was fair in his characterization of the current state of affairs in the Linux world.
cvs annotate is an excellent first start to see where code came into the tree. Other tools allow one to see where the code really came from in the face of formatting changes and the like.
Like I've said in prior posts, having this information is invaluable. It also allows one to more easily back out changes that might be tainted, reguardless of where they come from, since you know all the parts to that change, which is impossible with the changelog data. In this respect, bk is better than cvs since bk's change mechanism links multiple files that have changed, while CVS does not.
You *MAY* have this, or you may not. There are many shops that don't have this level of beaurocracy. However, I've never worked for any place that has had this independent of an underlying source code control system (and many places that didn't have source code control systems, let alone change numbers).
The issue can be further complicated if there's been a cross fertilization between projects for things like device drivers. Project A figures out how to do feature Z and project B integrates it. B then figures out Y and project A integrates that. Project C takes code from a data sheet and includes that under license X and Project A then takes it and incldues it under license Y and then Project B wants to bring it it, but is unsure if they can because they see substantially similar code under both X and Y licenses, not being aware of the common datasheet code example being present and gets confused. In situations like this, a clear SCM trail can help sort out who to talk to and how to resolve what might appear to be something bad.
I've seen many organic patches/drivers grow up over the years in linux that are litterally impossible to track down who wrote what originally. Some have email addresses, some do not, some have had them removed, some email addresses are stale, etc. In such a chaotic enviornment, it can be difficult to know where code came from. There are many strengths to this model, but code history isn't one of them.
Warner
The changelog is insufficient documentation. It contains vague attributions that something changed somewhere in the code. It isn't specific as to what lines of code changed. Later, when you go back and try to find where a set of lines came from, a changelog doesn't help much.
With a source code control system, you know that so and so added on such and such a date. You can then go to that person and ask them where they got it from if there's ever any question.
In the BSD world (I do a lot with FreeBSD), this has come in very handy when code disputes come up. Being able to talk to the actual people that inserted the code into FreeBSD has helped to clear up what otherwise might have been viewed as something improper.
I've tried to do similar things with versions of linux in the past, only to discover that I could, at best, find what version they came into the tree at, and who collected the patch and sent it to Linus. I wasn't able to track it further without searching public mailing lists for the information (with mixed results).
while you might believe that it will take 20 minutes to identify the code in question, my guess is that's overly optimistic, unless the code in question was contributed since bk. It usually takes me at least 5 minutes to find out where code comes from in FreeBSD when there's a question, and cvs annotate makes the process *MUCH* faster.
I'm not sure I'd disagree with your comments about SCO being able to come up with where the code came from relative to Linux.
Part of the problem with free trade is that the capital is free to move from place to place, but the labor isn't. That's what creates this problem. If indians could come to the US, that would drive up prices in the indian market and drive down prices in the us because things would equalize. There's two reasons this doesn't happen: 1) taking advantage of inqueities is what makes the capitalists money and 2) no domestic politician wants to look weak on imigration that takes jobs away from americans.
You miss my point. You are evaluating a narrow set of criteria like an engineer (does it do exactly the same thing on the same hardware), where most people evaluate things on a higher level (does it get X job done). Software wears out by becoming obsolete for the task you bought it, just as a car wears out when you can no longer drive it to work. This could be because it is obsolete, or it could be because it costs to much to fix.
Copyright law is the basis of the GPL. Copyright law says that the original holder of the copyright has the exclusive right to copy a work. The only way you can copy a work that has Copyright protection is with the permission of the author (or some other cases involving fair use that aren't relevant to this post). Most Copyright business happens as a result of contracts between the Copyright holder and those that make copies. In the book industry, the author sells his right to make copies, in some fashion, to the publisher. The publisher then creates the copies consistant with the contract, sells them and gives the author the amount of money that he or she is due (sometimes this figure is $0). This is no different than the FSF granting permission to copy a work based on a set of terms and conditions. People that publish 'political' or 'religious' works often do similar things. Many pamphlets I see contain words to the effect of "verbatum copies of this may be made without charge or further permission of X, the lawful copyright holder of this work." The GPL is based solidly in contract law, and is very similar to other software licenses in that it grants the ability to copy in a certain way, so long as certain terms are obeyed. The fact that the details of these terms differs is somewhat irrelevant when one is testing the validity of the licenese. To the extent that they are lawful is the only test that matters. And since they are lawful, SCO's claims not-with-standing, the contract is valid.
SCO's claims do merrit some analysis. The core of their complaint, is that federal law precludes copying. However, the copyright law specifically states that the copying cannot happen, absent permission. They seem to have conveniently overlooked the permission part.
The other sections of the copyright act just restrict the extent to which restrictions can be made on the restrictions to make copies. Section 117 is the one that sco is likely relying on. Notice its wording: Notice here how the law allows additional rights to copy. It does not say that other types of copying is necessarily prohibited, just that the author cannot prohibit the actions listed. SCO's argument seems to state that it is the other way around: since federal law requires copyright holders to allow these sorts of copies, it only allows these sorts of copies to be made. That's a stretch by my standards.FreeBSD already supports gdb over firewire using
the firewire bridge ability to DMA to/from any
location of memory. Very handy for remote kernel
debugging.
Leap seconds are evil. As someone who has spent way too many hours programming high precision time distribution systems to deal with leap seconds, I'd say 'good riddance, don't let the door hit you on the way out. Sites that have to deal with them typically shut down near leap seconds to avoid any glitches. The amount of time wasted on this problem boggles the mind.
I hate them and will not morn their passing.
Note entirely true. 4.3BSD NET2 had some USL code in it. That's what the 1995 lawsuit was about. The various BSD projects replaced their 4.3NET2 based code with 4.4LITE code which was explicitly covered by the AT&T/UCB agreements. Part of that agreement was that a certain number of files that were alleged to contain USL code were explicitly released under the BSD license.
Chances are good that someone saw these copyright notices and failed to read them far enough:
Notice the "reproduced herein with the permission of" in there.
My Personal opinion is that this is a tempest in a teapot by someone who doesn't know history or the agreements that they purchased along with the IP from SCO.
Also, the ahc/ahd drivers are still the amoung the best supported drivers in FreeBSD. They deal with all the various quirks of the chips very well, and kick ass in terms of performance. Justin Gibbs has been writing these drivers for years and years and years, even before going to work for adaptec.
The driver is full source, even source for the sequencer on the chip. Most other vendors don't go to that level of source code availaibilty. Most vendors give a binary blob to load onto the card for the on-board sequencer.
In short, I don't think that you have the first clue what you are talking about here.
As to Theo and Adaptec, well, he's a total pain to deal with and seems to be telling a radically different story about his experiences with Adaptec than the folks that work for Adaptec tell. I suspect that a similar thing is going on with Sun. I have friends that are doing the FreeBSD sparc64 work and they have indicated that Sun has been forthcoming with documetnation and hardware for their efforts. Maybe Theo isn't getting what he wants because he's a total jerk to people and they react to that.
It was Hasbro that also tried to claim clue.com and ultimately wound up losing, not parker brothers. I know the owner of clue.com personally, and got to hear all about the multi-year legal battle.
Tell that to FreeBSD, OpenBSD, NetBSD, XFree86,
all of which are orders of magnitude larger than the linux kernel. All of them have been using CVS for the past 8-10 years (depending on how you count things). Sure, cvs has its limitations, but the Linux kernel with its small number of developers with write access isn't pushing the limits. FreeBSD has over 250 people committing to its tree right now, for example.
Actually, you misunderstand. The Self-Power option is so that FreeBSD can be the first OS to ship in the "potateo powered web server" configuration out of the box, rather than needing patches to the base OS to do that.
Except that isn't true. there have been a number of issues with the way that iptables/netfilter in linux interacts with some systems. A number of problems related to timers in the state engine have come to light and do cause real problems for some systems. Also, 2.4 was relatively recent in history, so all the problems and issues with iptables/netfitler cannot be known yet. To assert otherwise is to ignore the history of software. All software has a hype cycle: The latest thing is always the best, then experience shows that it doesn't handle this or that right, followed by the disillusionment phase followed by the adopting another product that's in the hype phase. ipfilter is much farther along in this process and is maturing nicely. We have not had the history to know yet if iptables/netfilter will be the same.
If you don't believe me, go back and look at the press that each new Linux release gets. Then look at how people talk about that release 3-6 months later, and then 1-2 years later. It takes time for problems to be diagnoised and understood.
You can abuse any tool. OO code also lets you make complex problems look like a managable set of simple ones.
You've described good OO boundaries in some ways. I've seen good OO and bad OO in the engeering field. I've seen good OO where the stats stuff was written once and everybody used it. I've seen bad OO where stats were rewritten all over the place by people of different skill levels.
Stats is just one example of several. We do control systems and have control system base classes that allow us to model the control system by breaking it up into a measurement side and a control side and treating things generically. It works very well.
As you gain a wider experience, you'll find that most systems can be modeled with a good set of abstract concepts. We've found it has helped up tremendously. For example, when we write a new control system, generally all we need to do is to write measurement and control objects for the hardware that we don't already have these objects for and then write some custom plumbing code to tie all the objects together to match the wiring of the actual system (well, more or less, but that gives the right flavor). We don't have to write PID controllers each time, or simple alignment operations or any of the more complex data filtering algorithms we use to keep the control systems stable.
Yes, I know I'm being a little vague, but to fully describe things would take more space than is appropriate for this forum. Then again, the question was kinda vague...
If you had two access points talking to each other via special external antennas, then extra power would be a good thing, assuming you are under the FCC limits.
:-)
100mW is still well below the threshold of RF heating. I'd be surprised if even standing in
the beem of the 24dBi dish antennas would be harmful. I know several people that have done so with no ill effects.
But I guess that experience is no substitute for good theory
I guess my point was WHICH registers are set and
how can I tweak the FreeBSD wi driver to have an
ioctl to allow me to set them for orinoco cards.
I have a wireless link that is based on FreeBSD boxes and a few extra db is all I need to overcome
the leaves in the summer, and snow storms in the
winter.
Since I control both ends, I can boost the power
symetrically and still be within the FCC guidelines for radiated power (I'm about 10dBi
under the limit if I read the power meter I have
correctly). Yes, I've taken the gain of my
antennas into account. No, I can't buy larger
antennas because 24dBi is the largest that will
mount on my roof.
So I'm left with getting an amp, or having the
cards put out more power. I'd like to avoid an
amp...
Well, a card is cheaper, but a card, and an adapter and a computer isn't. The access points
are in the $100 range, and the card takes up at least $75 of that. It takes a lot of scrounging to put together a machine with ethernet for $25.
And the access points are a lot more convenient to reset.
And the Linux AP code still has some issues, so
it needs kicking more often than the access points
do (at least that's what people that have used
both tellme, I don't run the Linux AP code).
And an access point takes up less power than the
$25 486 DX + ethernet card + monitor (well, if you
are lucky, you can run serial) that you were able
to scrounge.