Nicely said. As a licensed user of both 900 MHz and 2.4 GHz (Amateur Radio), I find the infringement of multitudes of unlicensed services and the resulting increase in daily interference to be distasteful.
I could complain until I'm blue in the face to the people with the authority to enforce the rules (unlicensed users MUST NOT CAUSE UNDUE INTERFERENCE to licensed users of the spectrum) but the flood of unlicensed transmitters would simply drown me out in the noise.
This is not proper bandwidth allocation at all, and if the 2.4 ISM band is considered a "success" it's a pretty sad one. 900 MHz is virtually useless in most Metropolitan areas for licensed users, and 2.4 GHz is certainly headed that direction.
You do realize that the military is Primary at 420-450, even though you use it as an example of an Amateur band? NTIA is protecting it -- Amateurs are Secondary there.
There are areas of the U.S. where Amateurs are limited by location and power output levels on 420-450 to protect military installations. Areas of Texas and New Mexico come to mind.
Commercial interests would pounce on 420-450 if NTIA ever let it go. Amateurs would have a very hard time holding on to it. Be glad NTIA wants it still.
Re:That's because Linux admins are self-taught
on
Linux Is Cheaper
·
· Score: 1
So the logical solution is:
- Fire you because you're posting on Slashdot instead of working and the Windows machines don't need you any more anyway.
- Hire another Linux admin to help the overloaded guy.
Actually you missed a step or twenty. "Much simplified" is the understatement of the year.
You said:
1) Ask one of the 13 root servers which server handles.org domains.
2) Ask that server which server handles the slashdot.org domain.
3)Ask that server which server handles the www.slashdot.org zone.
And of course that last step is a bit wrong, even in a simple analogy.
Should have been:
3) Ask that server which server handles the slashdot.org zone.
***4) Ask that server for the A record for the www.slashdot.org name.
And of course, it's a lot more complex than this, as at each point you're really asking "do you have records for this zone?...
If not, do you have an NS record for the nameserver to ask for it?"... "Oh! Your timout values on those zones are X, Y, and Z? Okay... I'll cache those. Thanks."
And of course, like many big sites, you may get more than one answer for the A-record for www.slashdot.org and have to hand all of those back to the client resolver which will randomize (hopefully) which one it uses...
And at each stop, you might have to resolve something ELSE to get here... for example when it finds out that the slashdot.org zone is hosted on ns1-ns3.osdn.net, it has to start all over at the top and see if it has cached information for those and if not, ask from the root down where that name lives...
Etc etc etc...
It's quite amazing that it works as well as it does as fast as it does.
And there's not a solar panel on the planet made yet that will recover the energy used to CREATE the panel in its expected lifetime, even if illuminated constantly.
Solar panels are an excellent tool, but they do NOT produce less waste, because they're hideously inefficient to create in the first place.
And we'd still use ten times the energy *creating* the solar cell than it will ever produce in its lifetime. They're not that "efficient" in that respect, but no one ever complains about the manufacturing process...
HP wastes more money everyday via the sheer ineptitude of a huge organization run by normal people than Bruce could have cost them in a year. This is all politics. Bruce stepped on the wrong toes somewhere, methinks. Hopefully he got his point across if it was a good one, even if they did fire him.
Note to HP: Bad move. But I wasn't planning on buying any overpriced HP PC's anyway, so no big loss. IBM on the other hand, will probably get some laptop business from me... and customer references.
If there's one thing NASA knows how to do, it's to plan things. This post and the tons of others like it shows what sheep people will be when reading a/. article. It also shows a complete lack of understanding of their process, procedures, and the fact that numerous others have posted: There's multiple redundant gyro systems on board. This whole article is FUD.
Various books for reference to NASA's typical procedures exist. I enjoyed "Failure is Not An Option" by Gene Kranz (Flight Director), and "This New Ocean".
It's Monday, I'm grumpy and I'm not putting links in -- find 'em yourself and learn something.
The manufacturers are slowly headed the right direction with digital standards like APCO Project 25. Almost all major radio players now have or will have soon a P-25 offering.
I've seen this scenario over and over again... one guy who knows and understands the network, ten people standing around at the equipment trying various silly commands to fix it when it's down...
Here's some suggestions -- you probably already realize that 90% of your pain was avoidable, but everyone has to learn "the hard way" the first time, right?
We've got piles of printouts and documetation of all sorts, drawings and spreadsheets, helping us keep track of every IP and machine in this cage, yet it doesn't seem to get any clearer...
That's called bad documentation that no one ever reads.
Get your networking guys to document TROUBLESHOOTING techniques and to teach the programmers how the network is acutally set up and why. You have plenty of talent capable of understanding how it all works there.
Get more than one way (cell phone) to reach your most important network engineers. Pop for a guaranteed delivery text pager and ask them to carry that as well as the cell phone.
Yazz says, "When I arrived at Exodus, Kurt and Dave were trying every combination of things to do to get the 6509 back. But neither they nor I even knew the Cisco Passwords."
Paper. Wallet. Put them there. Better yet, PGP encrypted password escrow somewhere that anyone can get access to, and a locked cheap fire safe at the office with the public and private PGP keys on a CD-R inside -- for just this type of scenario.
So I asked the Cisco technician, Scott, to telnet into our switch...
Bad bad bad... telnet = bad. Good network security always goes out the window when the network's down...
So he's in the switch and he's disgusted and horrified by how we have it configured...
This is probably the most important hint during your entire outage... your network people either don't know what they're doing, or you're not ALLOWING them to do their jobs, or they're understaffed, or whatever other excuses can be made up... your call, but don't forget this -- if Cisco's "horrified" by your configs, there's a serious issue you need to find and correct somewhere in your organization. Everything from training, to documentation, to troubleshooting procedures needs a serious walk-through.
The one card going bad wouldn't have been such a big deal if the config in both were set up correctly. It was meant to flop to the other interface if the primary card died, which it did, but not with all the info it needed... AKA it was misconfigured...
DO FAIL-OVER TESTING. If you'd have done a fail-over test of this config you'd have known it didn't work correctly during a nice scheduled time when your network engineers are available and at the equipment, instead of the middle of the night during an outage with all of them MIA. This is so easy to avoid.
Exodus really wasn't set up to handle the type of failover the 6509 was meant to do. Thats what the Cisco folks said basically, and the Exodus people are no longer supporting this type of Cisco in their setups.
Nice of them to tell you. Who is the customer here again?
...he's talking to me on my cell phone (which disconnects every 5 minutes just to make my day more challenging)
Put a $20/month POTS line in your cabinet for goodness sake!
That's enough... I'm appalled, but hopefully you will straighten out some things now that the site was down for an extended period. Done properly, network downtime should be a rare event, usually caused by human error, not by bad configuration.
Many outages are unavoidable, your outage sounds like it was avoidable, and certain steps could have been taken to minimize the length of the outage.
IRLP is simply a way for folks to communicate through the wonderful hobby of ham radio.
As the caretaker of the IRLP Network's Denver Reflector (basically a VoIP conference bridge used to link multiple sites together), I thought I'd throw some information out here about the hobby of ham radio in general and the IRLP network more specifically.
Ham radio has always been about using one's knowledge of radio theory, basic electronics, and the generous "donation" of certain frequency ranges to radio amateurs worldwide by the various coordination and governmental entities that hold jurisdiction over those "airwaves". New technologies come along constantly for folks who like to "tinker" with to communicate.
FACTS:
- Amateur radio operation requires (in the U.S.) a licence from the FCC, which is fairly easily gained these days with recent regulation changes (some say too easy) via a multiple-choice test on FCC and International regulations, basic radio theory, basic electronic theory, and basic operating practices. More information about becoming a ham radio operator can be found at the following URL's:
- For years, ham operators have used "repeater" stations, located high above most metropolitan area for local communication via 2 meter (145 Mhz) FM signals. Other frequencies including 70cm (450 Mhz), and higher and even lower 6 meter (50 Mhz) FM repeater stations are available for use.
- IRLP mixes the use of Linux computers running Voice-over-IP software, some custom hardware, custom software written by the creator of IRLP, Dave Cameron [Callsign: VE7LTD] and physical or RF links to these repeaters to create a linked repeater system, similar to some quoted here that use RF (radio frequency) links. Control of the Linux system is done via DTMF tones, as is most control of features on local repeaters.
- Packet Loss: Many folks are claiming that "packet loss for Voice-over-IP is too high to make this usable"... hmm... that's funny. I seem to have just heard a number of stations calling others on the Reflector and having conversations just fine. What makes this work is that most PC VoIP users expect high audio quality. In fact, I just heard Dave talking from Vancouver, BC to a ham in Philadelphia via the Reflector.
- IRLP is using low-bitrate VoIP because the end points don't need supurb audio quality to communicate. Most nodes use an encoding method that requires 32KB/s of bandwidth, much lower than most broadband end-user solutions out there today. Some nodes with extremely limited bandwidth use an encoding method which only requires 8KB/s at the cost of audio quality.
-"Reflector" machines like the one I maintain need to be able to handle multiple VoIP streams outbound and a single VoIP stream inbound to maintain the "conference" of multiple IRLP nodes. My employer has graciously allowed for a set amount of bandwidth in our data centers for the IRLP project. (Similar to those companies who offer public open source mirror sites.)
- In response to the "I don't like this but I haven't had my radio on in years" folks... So what? Ham operators in the 1970's were put aback by the addition of repeaters to their local VHF and eventually UHF bands, and the response was similar. As one person said on the Reflector tonight, "Technology marches on!". Hams who used spark gap technology were probably put off by those "crazy guys" using AM to talk to each other years and years ago!
- Don't detract from others enjoyment of the hobby by bashing what they enjoy. Perhaps you like CW (morse code), Satellite, Moonbounce, HF Single-Sideband, UHF point-to-point, Amateur TV, SSTV, AMTOR, Radio Teletype, PACTOR, or Packet Radio over AX.25, or any of the other modes available. You don't see anyone involved in IRLP publicaly criticising the way you like to enjoy the hobby. (Well, a few folks here have an aversion to the Morse Code, and Bruce Perens has an excellent article about code and licensing up at http://technocrat.net/932183115/ )
Some observations about IRLP from my perspective, a long-time Linux user and Ham Operator...
- Many Hams have never played with Linux. Dave does an excellent job of helping them install Linux, get his custom software installed, and help them get their audio and RF links working properly on the network -- all on volunteer time.
[He does require that the custom hardware board be purchased from him directly, but that was mostly due to quality control issues with some of the early attempts to "open source" the project.]
Anyone that can afford to operate a repeater can certainly afford to purchase a hardware board from Dave. Repeaters are not cheap to operate, and most are funded by ham radio clubs who's members expect that a new experimental system like IRLP behave properly and not cause problems for the repeater itself on the local bands. Dave has the network and the image of IRLP at heart when he switched to this requirement, and the amount of time he spends maintaining nodes, helping folks with technical issues, and in generally keeping a happy demeanor are well worth the small price paid for the hardware board and support.
[Of course, an IRLP node *could* be set up on a simplex frequency... and some are... but there are issues with local interference and other reasons NOT to do this in large metro areas -- it's better to simply have a local club who's members decide to use a repeater system to link into -- it becomes the local "IRLP Frequency" and folks know when they hear stations from far off saying hello -- it's probably coming through the Internet link. Here locally, a short tone is added to the end of transmissions by the node radio to indicate it's an IRLP call, etc.]
For those interested in mixing technologies like Linux, the Internet, and Radios, IRLP is a spark that has rekindled interest in their hobbies.
Helping out with the Reflector and with the Denver node has been some of the most fun I've had in years.
Public thanks to Dave for creating the network, and hope to hear YOU on the air via an IRLP node soon!
Denver has been ten-digit dialing for a few years since the "Overlay" of 720 over the 303 area-code which covers mostly Denver-metro now. (It used to cover almost half the state.)
Calls to either area code are considered local as the two area-codes perfectly overlap.
During the initial roll-out plan, the original idea was that cellular (wireless), fax, and pagers would end up on 720 and the wireline-based phones would stay on 303. However, this was (rightly) shot down during the review period as unfair to the cellular carriers and unenforceable -- it would give the existing USWest (now Qwest) monopoly too much leverage. "Want to keep your 303 numbers? Stick with USWest."
So there was a little confusion for the first couple of weeks and a few PBX's and fire alarms had to be adjusted. They did a short period where the 7-digit dialing still worked but gave you a brief message reminding you to dial 303 the next time.
In all, since a vast majority of people I work with now in Denver weren't native Denver-ites they don't remember a day when seven digit dialing worked for half the state, and therefore there are very few complaints.
Meanwhile, my grandparents still have two rotary phones with real bells hardwired into their walls -- lots of changes for this little cow-town in two generations!
Here's some things I would think would give me good arguments to be able to use the software in the mixed NT and Unix environment I work in. The company I work for has standardized on the Exchange platform to handle Mail, Calendar, etc.
Due to the fact that there will be migration issues, and other issues, I would assume that the "early adopters" of software like this would be techies who want to work fully in a Unix/Linux/BSD/whatever environment -- then it could be rolled out for other users when the following criteria are met:
It should integrate with existing Exchange installations, including reading user and shared calendars already defined and able to "book" appointments with users still on Exchange. (Maybe something simliar to what the Jabber project has done with Instant Messaging...)
It should handle timezones seamlessly. Book in my time-zone, someone else reads their calendar in their time zone. (In other words, stored appointments should probably be in GMT.) Many organizations are far-flung geographically and need this type of support.
Clients should connect and send information to the server in an encrypted channel (unlike Exchange).
Database replication between servers should be supported for applications that are geographically or network distributed -- some reasonable amount of time for replication to take place would have to be defined.
Both native platform clients (speed) and web-interfaces should be created.
Something better than the current Exchange "auto-answer" type resource booking stuff for things like conference rooms and projectors, or whatever is defined as a shared resource.
Cross-platform compile, install, etc. BSD, Linux, and commercial Unices.:)
Other niceties that would help get its foot-in-the-door would be:
Using the server replication features mentioned above, if one of these servers could replicate to another one and then send those changes/updates to an Exchange server on the far end, thus losing the necessity for tons of traffic across WAN links for clients to view other client's calendars, this would be nice.
Integration with a popular web-mail application like IMP or something simlar on the web interface would be nice.
Writing the various clients in a cross-platform like Java or something similar would be nice for developers and offer less work down the road, but more up-front. This one seems somehow problematic to me in a number of ways, but it's just a thought.
There's probably a lot more, but just typing out those sounds like a ton of work. These few are just some that pop out of my head on a quick analysis. There's probably a lot more. Good luck on your project, looking forward to playing with it someday!
Lucent cards are also no longer Lucent. They're Orinoco cards now.:)
My Apple AirPort base station won't do more than 40-bit crypto, but works nicely with my (old enough to still say) Lucent card in my work NT laptop. And it was only $299. Airport cards for the two Macs were $99 each. Nice.
Linux works just fine with the Orinoco WaveLAN cards also...
The article doesn't cover crypto, Apple, or have correct information about Orinoco/Lucent equipment. If you were looking for an accurate way to compare and contrast wireless products, look elsewhere -- at least until the site is updated.
Slashdot Mirror
Nicely said. As a licensed user of both 900 MHz and 2.4 GHz (Amateur Radio), I find the infringement of multitudes of unlicensed services and the resulting increase in daily interference to be distasteful.
I could complain until I'm blue in the face to the people with the authority to enforce the rules (unlicensed users MUST NOT CAUSE UNDUE INTERFERENCE to licensed users of the spectrum) but the flood of unlicensed transmitters would simply drown me out in the noise.
This is not proper bandwidth allocation at all, and if the 2.4 ISM band is considered a "success" it's a pretty sad one. 900 MHz is virtually useless in most Metropolitan areas for licensed users, and 2.4 GHz is certainly headed that direction.
You do realize that the military is Primary at 420-450, even though you use it as an example of an Amateur band? NTIA is protecting it -- Amateurs are Secondary there.
There are areas of the U.S. where Amateurs are limited by location and power output levels on 420-450 to protect military installations. Areas of Texas and New Mexico come to mind.
Commercial interests would pounce on 420-450 if NTIA ever let it go. Amateurs would have a very hard time holding on to it. Be glad NTIA wants it still.
So the logical solution is:
- Fire you because you're posting on Slashdot instead of working and the Windows machines don't need you any more anyway.
- Hire another Linux admin to help the overloaded guy.
Cool.
... this one time, at Band Camp...
Text-to-Speech: Festival
Gee that's funny, richochet is running great here in Denver again.
The rumors of their demise are greatly exaggerated, methinks.
Hmm...
2.4 GHz is the resonant frequency of water. It's used to cook your food in your microwave oven for this reason.
Now let's see... if your head is full of...
Oh nevermind... we'll just find you something a little way below 300 GHz. That's bound to heat up the the air in there nicely.
Actually you missed a step or twenty. "Much simplified" is the understatement of the year.
.org domains.
You said:
1) Ask one of the 13 root servers which server handles
2) Ask that server which server handles the slashdot.org domain.
3)Ask that server which server handles the www.slashdot.org zone.
And of course that last step is a bit wrong, even in a simple analogy.
Should have been:
3) Ask that server which server handles the slashdot.org zone.
***4) Ask that server for the A record for the www.slashdot.org name.
And of course, it's a lot more complex than this, as at each point you're really asking "do you have records for this zone?...
If not, do you have an NS record for the nameserver to ask for it?"... "Oh! Your timout values on those zones are X, Y, and Z? Okay... I'll cache those. Thanks."
And of course, like many big sites, you may get more than one answer for the A-record for www.slashdot.org and have to hand all of those back to the client resolver which will randomize (hopefully) which one it uses...
And at each stop, you might have to resolve something ELSE to get here... for example when it finds out that the slashdot.org zone is hosted on ns1-ns3.osdn.net, it has to start all over at the top and see if it has cached information for those and if not, ask from the root down where that name lives...
Etc etc etc...
It's quite amazing that it works as well as it does as fast as it does.
And there's not a solar panel on the planet made yet that will recover the energy used to CREATE the panel in its expected lifetime, even if illuminated constantly.
Solar panels are an excellent tool, but they do NOT produce less waste, because they're hideously inefficient to create in the first place.
--
"multiband vertical VHF"... something seems wrong with that. Is it multiband, or is it VHF?!
ES 73 OM... DE WY0X
And we'd still use ten times the energy *creating* the solar cell than it will ever produce in its lifetime. They're not that "efficient" in that respect, but no one ever complains about the manufacturing process...
I believe you meant to say "I will" instead of "I'll" then.
Oh give me a break.
HP wastes more money everyday via the sheer ineptitude of a huge organization run by normal people than Bruce could have cost them in a year. This is all politics. Bruce stepped on the wrong toes somewhere, methinks. Hopefully he got his point across if it was a good one, even if they did fire him.
Note to HP: Bad move. But I wasn't planning on buying any overpriced HP PC's anyway, so no big loss. IBM on the other hand, will probably get some laptop business from me... and customer references.
Maybe that's the whole point of the Consumer Reports survey???
To paraphrase our favorite NY acting student-turned-Dell salesman, "Dude... You're gettin' a clue!"
People who read Consumer Reports are INTERESTED in the question... "How good is their tech support." They're also probably willing to PAY for it.
If there's one thing NASA knows how to do, it's to plan things. This post and the tons of others like it shows what sheep people will be when reading a /. article. It also shows a complete lack of understanding of their process, procedures, and the fact that numerous others have posted: There's multiple redundant gyro systems on board. This whole article is FUD.
Various books for reference to NASA's typical procedures exist. I enjoyed "Failure is Not An Option" by Gene Kranz (Flight Director), and "This New Ocean".
It's Monday, I'm grumpy and I'm not putting links in -- find 'em yourself and learn something.
The manufacturers are slowly headed the right direction with digital standards like APCO Project 25. Almost all major radio players now have or will have soon a P-25 offering.
They're finally eating their young!
United 238 Heavy, turn right... HEY! You sunk my BATTLESHIP!"
I've seen this scenario over and over again... one guy who knows and understands the network, ten people standing around at the equipment trying various silly commands to fix it when it's down...
Here's some suggestions -- you probably already realize that 90% of your pain was avoidable, but everyone has to learn "the hard way" the first time, right?
We've got piles of printouts and documetation of all sorts, drawings and spreadsheets, helping us keep track of every IP and machine in this cage, yet it doesn't seem to get any clearer...
That's called bad documentation that no one ever reads.
Get your networking guys to document TROUBLESHOOTING techniques and to teach the programmers how the network is acutally set up and why. You have plenty of talent capable of understanding how it all works there.
Get more than one way (cell phone) to reach your most important network engineers. Pop for a guaranteed delivery text pager and ask them to carry that as well as the cell phone.
Yazz says, "When I arrived at Exodus, Kurt and Dave were trying every combination of things to do to get the 6509 back. But neither they nor I even knew the Cisco Passwords."
Paper. Wallet. Put them there. Better yet, PGP encrypted password escrow somewhere that anyone can get access to, and a locked cheap fire safe at the office with the public and private PGP keys on a CD-R inside -- for just this type of scenario.
So I asked the Cisco technician, Scott, to telnet into our switch...
Bad bad bad... telnet = bad. Good network security always goes out the window when the network's down...
So he's in the switch and he's disgusted and horrified by how we have it configured...
This is probably the most important hint during your entire outage... your network people either don't know what they're doing, or you're not ALLOWING them to do their jobs, or they're understaffed, or whatever other excuses can be made up ... your call, but don't forget this -- if Cisco's "horrified" by your configs, there's a serious issue you need to find and correct somewhere in your organization. Everything from training, to documentation, to troubleshooting procedures needs a serious walk-through.
The one card going bad wouldn't have been such a big deal if the config in both were set up correctly. It was meant to flop to the other interface if the primary card died, which it did, but not with all the info it needed... AKA it was misconfigured...
DO FAIL-OVER TESTING. If you'd have done a fail-over test of this config you'd have known it didn't work correctly during a nice scheduled time when your network engineers are available and at the equipment, instead of the middle of the night during an outage with all of them MIA. This is so easy to avoid.
Exodus really wasn't set up to handle the type of failover the 6509 was meant to do. Thats what the Cisco folks said basically, and the Exodus people are no longer supporting this type of Cisco in their setups.
Nice of them to tell you. Who is the customer here again?
Put a $20/month POTS line in your cabinet for goodness sake!
That's enough... I'm appalled, but hopefully you will straighten out some things now that the site was down for an extended period. Done properly, network downtime should be a rare event, usually caused by human error, not by bad configuration.
Many outages are unavoidable, your outage sounds like it was avoidable, and certain steps could have been taken to minimize the length of the outage.
IRLP is simply a way for folks to communicate through the wonderful hobby of ham radio.
As the caretaker of the IRLP Network's Denver Reflector (basically a VoIP conference bridge used to link multiple sites together), I thought I'd throw some information out here about the hobby of ham radio in general and the IRLP network more specifically.
Ham radio has always been about using one's knowledge of radio theory, basic electronics, and the generous "donation" of certain frequency ranges to radio amateurs worldwide by the various coordination and governmental entities that hold jurisdiction over those "airwaves". New technologies come along constantly for folks who like to "tinker" with to communicate.
FACTS:
- Amateur radio operation requires (in the U.S.) a licence from the FCC, which is fairly easily gained these days with recent regulation changes (some say too easy) via a multiple-choice test on FCC and International regulations, basic radio theory, basic electronic theory, and basic operating practices. More information about becoming a ham radio operator can be found at the following URL's:
http://hamradio-online.com/starthere.html
http://www.arrl.org
- For years, ham operators have used "repeater" stations, located high above most metropolitan area for local communication via 2 meter (145 Mhz) FM signals. Other frequencies including 70cm (450 Mhz), and higher and even lower 6 meter (50 Mhz) FM repeater stations are available for use.
- IRLP mixes the use of Linux computers running Voice-over-IP software, some custom hardware, custom software written by the creator of IRLP, Dave Cameron [Callsign: VE7LTD] and physical or RF links to these repeaters to create a linked repeater system, similar to some quoted here that use RF (radio frequency) links. Control of the Linux system is done via DTMF tones, as is most control of features on local repeaters.
- Packet Loss: Many folks are claiming that "packet loss for Voice-over-IP is too high to make this usable"... hmm... that's funny. I seem to have just heard a number of stations calling others on the Reflector and having conversations just fine. What makes this work is that most PC VoIP users expect high audio quality. In fact, I just heard Dave talking from Vancouver, BC to a ham in Philadelphia via the Reflector.
- IRLP is using low-bitrate VoIP because the end points don't need supurb audio quality to communicate. Most nodes use an encoding method that requires 32KB/s of bandwidth, much lower than most broadband end-user solutions out there today. Some nodes with extremely limited bandwidth use an encoding method which only requires 8KB/s at the cost of audio quality.
-"Reflector" machines like the one I maintain need to be able to handle multiple VoIP streams outbound and a single VoIP stream inbound to maintain the "conference" of multiple IRLP nodes. My employer has graciously allowed for a set amount of bandwidth in our data centers for the IRLP project. (Similar to those companies who offer public open source mirror sites.)
- In response to the "I don't like this but I haven't had my radio on in years" folks... So what? Ham operators in the 1970's were put aback by the addition of repeaters to their local VHF and eventually UHF bands, and the response was similar. As one person said on the Reflector tonight, "Technology marches on!". Hams who used spark gap technology were probably put off by those "crazy guys" using AM to talk to each other years and years ago!
- Don't detract from others enjoyment of the hobby by bashing what they enjoy. Perhaps you like CW (morse code), Satellite, Moonbounce, HF Single-Sideband, UHF point-to-point, Amateur TV, SSTV, AMTOR, Radio Teletype, PACTOR, or Packet Radio over AX.25, or any of the other modes available. You don't see anyone involved in IRLP publicaly criticising the way you like to enjoy the hobby. (Well, a few folks here have an aversion to the Morse Code, and Bruce Perens has an excellent article about code and licensing up at http://technocrat.net/932183115/ )
Some observations about IRLP from my perspective, a long-time Linux user and Ham Operator...
- Many Hams have never played with Linux. Dave does an excellent job of helping them install Linux, get his custom software installed, and help them get their audio and RF links working properly on the network -- all on volunteer time.
[He does require that the custom hardware board be purchased from him directly, but that was mostly due to quality control issues with some of the early attempts to "open source" the project.]
Anyone that can afford to operate a repeater can certainly afford to purchase a hardware board from Dave. Repeaters are not cheap to operate, and most are funded by ham radio clubs who's members expect that a new experimental system like IRLP behave properly and not cause problems for the repeater itself on the local bands. Dave has the network and the image of IRLP at heart when he switched to this requirement, and the amount of time he spends maintaining nodes, helping folks with technical issues, and in generally keeping a happy demeanor are well worth the small price paid for the hardware board and support.
[Of course, an IRLP node *could* be set up on a simplex frequency... and some are... but there are issues with local interference and other reasons NOT to do this in large metro areas -- it's better to simply have a local club who's members decide to use a repeater system to link into -- it becomes the local "IRLP Frequency" and folks know when they hear stations from far off saying hello -- it's probably coming through the Internet link. Here locally, a short tone is added to the end of transmissions by the node radio to indicate it's an IRLP call, etc.]
For those interested in mixing technologies like Linux, the Internet, and Radios, IRLP is a spark that has rekindled interest in their hobbies.
Helping out with the Reflector and with the Denver node has been some of the most fun I've had in years.
Public thanks to Dave for creating the network, and hope to hear YOU on the air via an IRLP node soon!
73 (Best Regards) from N0NTZ
Denver, Colorado
He called it "The Second System of Man", and one of the tenets was "The Second System is Fat and Slow".
Buy it at Barnes & Noble if you like.
Calls to either area code are considered local as the two area-codes perfectly overlap.
During the initial roll-out plan, the original idea was that cellular (wireless), fax, and pagers would end up on 720 and the wireline-based phones would stay on 303. However, this was (rightly) shot down during the review period as unfair to the cellular carriers and unenforceable -- it would give the existing USWest (now Qwest) monopoly too much leverage. "Want to keep your 303 numbers? Stick with USWest."
So there was a little confusion for the first couple of weeks and a few PBX's and fire alarms had to be adjusted. They did a short period where the 7-digit dialing still worked but gave you a brief message reminding you to dial 303 the next time.
In all, since a vast majority of people I work with now in Denver weren't native Denver-ites they don't remember a day when seven digit dialing worked for half the state, and therefore there are very few complaints.
Meanwhile, my grandparents still have two rotary phones with real bells hardwired into their walls -- lots of changes for this little cow-town in two generations!
Due to the fact that there will be migration issues, and other issues, I would assume that the "early adopters" of software like this would be techies who want to work fully in a Unix/Linux/BSD/whatever environment -- then it could be rolled out for other users when the following criteria are met:
Other niceties that would help get its foot-in-the-door would be: There's probably a lot more, but just typing out those sounds like a ton of work. These few are just some that pop out of my head on a quick analysis. There's probably a lot more. Good luck on your project, looking forward to playing with it someday!#5 Require ISP's to throw away packets outside of their assigned IP ranges.
That would certainly help, but who'd police it? The enforcement is more problematic than the fix.
My Apple AirPort base station won't do more than 40-bit crypto, but works nicely with my (old enough to still say) Lucent card in my work NT laptop. And it was only $299. Airport cards for the two Macs were $99 each. Nice.
Linux works just fine with the Orinoco WaveLAN cards also...
The article doesn't cover crypto, Apple, or have correct information about Orinoco/Lucent equipment. If you were looking for an accurate way to compare and contrast wireless products, look elsewhere -- at least until the site is updated.