I'm going to have to read Fahrenheit 451. From the excerpts I've read here and elsewhere it sounds omniously scary.
Please, citizens of the US, stop your government before it's too late.
I normally don't push libertarianism in this forum, other than via my sig, but this is getting way out of control. If we want to do something about this long-term we need to work on getting people in office which share our ideals.
After being fed up the last presidential election with the Republicrats, I decided to go out and look at the different parties. After much searching I discovered the Libertarian party.
Without going into a long post about their ideals, I'll just summarize by saying I hear a large portion of the vocal slashdot community spouting those ideals. Perhaps the most relevant portion of their platform to this discussion is this:
We oppose any abridgment of the freedom of speech through government censorship, regulation or control of communications media...
I'll spew one or more two references and then shut up. If you'd like to figure out where your views really fit in with politics, the libertarian party has The World's Smallest Political Quiz which is a set of ten questions which will rank you into which area you best fit.
For more info on the Libertarian party, click on the link in my sig...
Obviously what the author wants is a shell which implements just the POSIX standard and nothing else. Or maybe expanding just a little bit, wants a shell which JUST implements the Bourne syntax which is available in all Bourne-compatible shells.
I can understand the reason for this when writing an install script - specifically it is desirable to write to the lowest common denominator and thus make it compatible with everything.
However, I can't think of a single shell which actually implements just POSIX, or Bourne syntax for that matter. There are dozens of shells out there which all will chew on a real POSIX or Bourne script and spit out something which is pretty close to what the script author intended. However it seems that all of the shell authors have done stuff a little differently than each other so if you've only written and tested on one shell, you might have problems running on any one (or all) of the other shell(s).
The best thing to do is to pick something small which is as close to just POSIX implementation as you can get (ash perhaps?) and write/develop in that shell and then thouroughly test it on things like bash, ksh and other POSIX shells.
I always like to through out the fact that most systems now have perl available on them and in some cases it is probably just as appropriate if not more so to script install stuff in perl.
I haven't seen a good post to attach my comments to so I'll just stuff it here.
I have shipped many many packages with many many carriers over the years and I have never lost anything due to damage, other than when I knowingly didn't package something adequately.
Sure I've seen packages which were pretty well beat up, but like others have said, a well-packaged box will pretty much guarantee safe arrival.
The boxes used look like they weren't designed for shipping use. A LOT of boxes won't withstand the crushing which naturally occurs during shipping and will burst. This is what looks like happened. Once the box burst, all bets were off as to how well the contents would arrive.
I usually use the two-box method for heavier items. Pack the heavy item inside a box just slightly bigger than the item, filling the space between the item and the box tightly with newspaper or bubble wrap, etc. Don't use peanuts here.
After you get this box packaged, put it in a larger box with at least 2-4" of peanuts all the away around (and on the bottom and top), packed fairly tightly but not overly so. The goal is to suspend the smaller box inside the bigger one so that any damage which is done to the outside box doesn't end up going through to the inside one.
I've never seen anything packaged this way not arrive intact. On the other hand, I have seen numerous items which the shipper did exactly what the poster did (wrap the piss out of it with bubble wrap and stick it in a big box) arrive damaged. The *WORST* thing to do is to put a heavy object (such as a laser printer) just directly in a big box with peanuts. The thing won't survive, and if it does it will be filled with peanut shreds when it arrives.
For when this was probably first written, this was perfectly valid advice, as most Hard Drives DIDN'T auto-park like modern drives.
If anything, the addition of this statement adds credibility to the referenced page - as they knew enough when they wrote it to know that this was necessary.
The article doesn't really do a good job of saying what this is really about, and the report several people have linked to does provide detailed information, but again you need to have some context to understand it.
What they are really saying is that there are large chunks of the internet which can't talk to each other. This isn't because of firewalling or "hiding" behind a NAT box or the like, but is instead a result of the peering "politics" (which better describes what goes on than policies) between carriers.
Let me explain. If I am ISP A and I connect via peering to ISP B, I can't talk to ISP C's customers through B even if ISP B and C are connected. That is, unless I have an arrangement with ISP B to provide transit to ISP C. ISP C also has to agree to accept my routes even if ISP B provides transit to me.
Generally the big "Tier 1" ISP's peer with each other and generally don't exchange or buy transit from each other (except in some limited cases). Smaller ISP's generally buy transit from one or more Tier 1 ISP's. Some of the smaller Tier 1's both peer and buy transit.
It is not altogether unexpected that with hundreds of ISP's out there that certain ISP pairs just plain do not have connectivity between them. It would be almost impossible both economically, politically, and technically to insure that each ISP could talk to every other ISP out there.
Add on to that that there are some ISP's who set arbitrary limits on how many addresses you have to announce together in one chunk (prefix) before they will even listen to them. If you have a small ISP with insufficiently sized address blocks you may find that your connectivity to the internet suffers.
The other piece which WAS said fairly well is that most people don't notice the problem as 99% of the people out there don't use more than the most popular 1% of the internet. And THOSE sites are almost 100% connected (and if you ran an ISP which wasn't connected to the big sites, you would quickly find yourself without a customer base).
Note that I've taken some liberties with this description so there is some minor technical/political breakage in the description above. Or probably better put, this isn't meant as a technical reference piece on peering policies....
You know, I just figured out why there have been so many "what is it like at..." or "I'm looking for a job where should I go" postings recently...
Obviously CmdrTaco and the crew have figured out that VA isn't where *THEY* want to work any more and are trying to figure out where to go next.
It's the only explanation that fits...
Now, on a directly related topic, I wouldn't trust anyone at WorldCom/UUNET/ALTER.NET to run *ANY* of my business traffic. Every time I have a problem getting somewhere it inevitably ends up being a problem on the ALTER.NET backbone, and if they treat their employees like their employees treat people who call their NOC *I* sure wouldn't want to work for them.
OSPF isn't much harder to configure than RIPv2 and solves a lot of the RIP-type problems that v2 didn't such as count-to-infinity loops and slow convergence.
As others have already mentioned Zebra and GateD, I won't be redundant and give you a URL. Both of these do OSPF in addition to RIPv2.
There's another reason why ISP's aren't going to support this: Cost.
Most of the dial equipment in place is near it's end of life. Lots of smaller ISP's use PM3's which won't have a v.92 upgrade available. Not sure about the PM4's. Upgrading these units to v.92 would cost the ISP thousands of dollars with very little hope of ever seeing any return on investment.
In addition, the Ascend (lucent) MAX gear and the 3com/USR Total Control units aren't upgradeable unless the ISP carries a service contract on the gear. A LOT of ISP's have dropped the service contracts on their dialup equipment as the existing software is stable, the phone support sucks (most ISP techs know more about the equipment than the manufacturer techs do), and it is a lot cheaper just to buy used spares for everything, thus minimizing downtime by being able to keep a hot spare on the shelf.
Again, the added cost of adding maintenance to permit the addition of V.92 support to their dial pool has very little real liklihood of return on investment.
I'd say don't worry about the v.92 stuff, and just get a robust hardware-based v.90 modem.
I've been doing wireless ISP stuff for quite a while so I know what you're talking about.
Here's the key points:
5.xGHz is EXPENSIVE. I can't in good faith recommend it for ISP to customer links, except for those customers who need to have solid, VERY high speed links. Use 5.x GHz for your backbone between pops.
5.xGHz tends to be ROCK SOLID. There are actually two chunks of bandwidth up there which are useful this. I personally have used the UNII band stuff which is below 5.8 (three bands - the highest at 5.7GHz), and I can't say I've been really interfered with. This is in a community where 2.4GHz in parts of town is completely saturated.
So if you want expensive but rock solid use the 5.8 GHz stuff.
What we tend to do is use the 5.8GHz for Backhaul from our repeater "cell" sites and use the 2.4GHz for our "last mile". Keeping the cell cites small and using polarization, channels, and sectoral antennas to your advantage is the key.
Well, in all reality the 2.4GHz band IS the band where microwave ovens operate. See here
If you pull up a Lucent/Avaya/ORiNOCO wavelan card control panel under windows, you will find there's a "Microwave Oven Robustness" setting which is designed to help make these work in the presence of a microwave oven.
The official supported platform list is actually the 1700, 2600, 3600, 7200, 7500, 12000 and ubr920 series routers. Although I wouldn't be surprised if it actually works on any Cisco router...
The real limitation is that you must have an IPSec capable image on your router. Not usually a big deal.
I fully agree with their keyboard assessment. I've got a "genuine" IBM Model E on my desk (Circa 1987). I also greedily hang onto any Model E's I get given so when this dies. I've got enough spares to last me pretty much until I die 50 or 60 years from now, or at least until a "old fashioned" keyboard is irrelevant.
I type around 90 WPM if I'm on the Model E. Anything Else, I'm lucky to get 50. The other's just don't give you the necessary feedback when the key is down for your brain to realize it is ok to push the next key.
Also important is the fact that some of the really really cheap newer keyboards have problems where the keys all don't trigger at the same point in their downward stroke. Since I type fast enough that I actually (subconciously, mind you) "overlap" my keystrokes - that is one key is actually going down milliseconds behind the next one - I have seen some really bad keyboards this way that will actually reorder my keystrokes because even though I pushed key B after key A, key B shows up first. Needless to say, this causes some inaccuracies.
The problem with solar and wind is that you get it when it is there - NOT WHEN YOU NEED IT. Thus you have to store it. Batteries are not economically viable to do this with on a large scale (aka power grid). Why not use the energy to split water into hydrogen and oxygen. Release the oxygen and "bottle" the hydrogen. It can then be transported and used on demand.
True it is always better to use the energy without conversion. But even 50% energy loss is better than the 100% energy loss if you aren't able to use the "free energy source".
Another poster mentioned that the Klingon appearance wasn't explained, merely brushed away for later. About the first contact though.. it has been hinted at that those bad guys are time travelish. Which would suggest they can play god with the ST universe, as this is different than what happened.
There is a quote in there from the bad guys that the "Humans and the Vulcans weren't supposed to be involved yet". Perhaps this is *exactly* the story arc that is being used... We just don't know it yet.
I'm sorry, but am I the only one who wonders why in the @()#*$ didn't AMD build in at least something to power down the chip when it got too hot?
I've seen MANY MANY MANY shipped computers which had the heatsink not on the processor when it arrived at the destination. Having the processor be able to destroy itself when you loose a heatsink is just bad karma...
Not to mention that the processor obviously gets hot enough to catch something on fire if it happened to be in the wrong spot in the case.
Product liability lawsuit anyone? This makes me want to reconsider my AMD is better than intel position.
I'd recommend you take a good look at FreeBSD. Hop over to http://www.freebsd.org/ and take a look around. In most cases, all you need to get going is a couple of floppy disks and the instructions found here. The installation disks will automagically download the entire distribution via the net.
I don't want to start a FreeBSD vs. Linux war, but if you're looking for a server replacement, FreeBSD is a great choice. If you are wanting to use it on your desktop as a workstation, then perhaps Linux is the better choice, although I still wouldn't discount FreeBSD 100%.
Let me put it this way. Dolby spent a lot of time and money coming up with the Technology behind AC3. They also patented the method of encoding/decoding AC3. If you think about the complexity of developing a coding scheme in which even "golden ears" can't really tell the difference, while still doing quite heavy compression then you'll realize that this is probably one of the few areas where a patent is probably justified.
If it's patented, then you can't reproduce it without paying whatever royalties the patent owner wants, period.
As much as I feel that things that are obvious should not be patented, Even I agree that something so difficult to do should be afforded patent protection.
Also, read the tone of the letter. It's "please remove this and let's talk about what options we have, but if you don't we'll have to pursue legal means" as opposed to the "appear in court on this date" method which the people who don't have what I consider "patentable" technology tend to employ.
I've found that the most insightful part of an interview is what questions the candidate asks.
Forget asking them about ls and rm and tcpdump, etc., but instead show them the equipment room, talk about what you are doing, etc..
A true tech "geek" will almost immediately forget he's on an interview and start asking questions like "You're whole building is wired with fiber?", Or "What OS are you running on these?", etc., etc., etc.. Sharing war stories also seems to bring out the best in geeks.
You will find out very quickly whether the person knows anything or not, and their relative clue level, although you do have to give some leeway for the occasional stupid question/comment. You can also insert a few leading questions in the discussion. "Oh yeah, we just got done installing those switches last week. Have you played with that brand yet?"
You also will probably be able to tell how much a person really wants to be involved in your company by how they respond during the "show and tell".
The last person we hired was basically interviewed this way. She obviously knew the questions to ask, could deal with our kind of always-hectic environment (darn users anyways), and her eyes lit up when she saw our equipment room. We hired her and we haven't regretted it for a microsecond since.
Not only that, but if you encounter aliens, you will have a leg up on how to use alien technology. After all, that IS the only reasonable explanation for the sendmail config file....
Takedown - Tsutomu Shimomura - The story of the pursuit and capture of Mitnick. This is a good read. There's also one that I haven't read which tells Mitnick's story - perhaps someone else can point us toward that one.
There is another I've read which talks about the Steve Jackson Games incident - and a lot of the other Secret Service activities in that era. Again, I can't provide a reference.
Yep, I can't tell you how many lines of BASIC I wrote on a Model 200 plugged into a CP/M via a terminal cable. Sometimes I wish I had one floating around. But then I think about how much I like my Vaio. However...
Battery life was wonderful. AA's that worked seemingly forever, although we got in the habit of cycling NiCD's through it. It survived the environment we used it in which was a oily, dirty, industrial sawmill. Never complained, and worked like a champ.
Let me prefix this with the fact that I used a 300bps modem back in about 87. A lot in fact.
My typing has been around 60-90 wpm since about that time, depending on keyboard, what I am typing, etc. etc.
90 wpm = 450 cpm = 7.5 cps.
300bps = 30cps. (8 data, no parity, one start, one stop bit= 10 bits/byte).
I can't remember ever overtyping the modem.
What I can remember is that I definately could *read* faster than 30cps. Especially painful was when something started spewing a file to you which was way too big.
I can ALSO remember downloading 20kbyte programs and waiting 10 mins. A 100k program was almost an hour.
I also remember typing faster than either the net (meaning GTE Telenet/Tymnet) plus the host (The Vaxen (If I recall correctly) which were The Source) could handle, so you could get ahead.
As far as a 300bps not performing near it's theoretical throughput, I would have to say that that statement is technically incorrect. A 300bps modem would ALWAYS work at exactly 300bps. Now, occasionally you'd get line noise, and it would show up at exactly 300bps.
Remeber 300bps modems didn't have error correction or compression or anything like that. Basically they listened for two tones on the line. If there was a blast of noise which contained either or both tones, you'd get crap. Usually {'s and other similar characters.
Generally, if you couldn't use a line, you'd just redial. OR filter it, etc. etc. etc.
I remember when The Source offered a 2400bps modem paid for over several monthly bills. I could not pass it up. I was in *HEAVEN* at 2400bps.
The only problem was that I had to write my own interrupt driven modem software for my Epson PX-8 Laptop, as the builtin stuff would loose characters at 2400bps.
To answer the posters question, I think this will likely need some programming or at least scripting. Generally, what you would want is a modem which does ring detection, probably a voice modem, and have a script watch for the distinctive ring report from the modem. RING 0, etc., depending on the modem. When it sees it, launch an appropriate program.
However, the problem I'm running into is finding a PCI-based Non-Winmodem which does voice. I have a similar application I need to find one for. Everyone recommends the Zyxel modems, but they don't currently make an internal model, and as far as I can tell the 1496 was only available in ISA. For my app, this must be internal as it's going in a rack mount environment where we pay per rack inch.
From what I can tell, the vast majority of the PCI Voice modems out there are WinModems. I happen to be a FreeBSD user, so of course I need a real "hardware modem".
Maybe one of the other readers can shed some light on this....
I haven't seen a response that I felt hit on this point adequately.
You don't necessarily need your direct upstream provider to do multicast natively. If you can find a provider willing to provide you a tunnel then you just need an appropriate piece of hardware/software to become your end of the tunnel. Linux and FreeBSD boxes work great for this, along with most "real" cisco routers.
Start with your upstream and ask them two things. 1) If they will provide you with a tunnel and 2) If not, who are their providers so you can get a tunnel from one of them. Generally, the multicast people are fairly open to providing tunnels to people who are even indirectly connected to them, although YMMV.
Look around a bit with some Google searches and you should be able to find someone who will give you a tunnel.
Slashdot Mirror
Please, citizens of the US, stop your government before it's too late.
I normally don't push libertarianism in this forum, other than via my sig, but this is getting way out of control. If we want to do something about this long-term we need to work on getting people in office which share our ideals.
After being fed up the last presidential election with the Republicrats, I decided to go out and look at the different parties. After much searching I discovered the Libertarian party.
Without going into a long post about their ideals, I'll just summarize by saying I hear a large portion of the vocal slashdot community spouting those ideals. Perhaps the most relevant portion of their platform to this discussion is this:
We oppose any abridgment of the freedom of speech through government censorship, regulation or control of communications media...
I'll spew one or more two references and then shut up. If you'd like to figure out where your views really fit in with politics, the libertarian party has The World's Smallest Political Quiz which is a set of ten questions which will rank you into which area you best fit.
For more info on the Libertarian party, click on the link in my sig...
I can understand the reason for this when writing an install script - specifically it is desirable to write to the lowest common denominator and thus make it compatible with everything.
However, I can't think of a single shell which actually implements just POSIX, or Bourne syntax for that matter. There are dozens of shells out there which all will chew on a real POSIX or Bourne script and spit out something which is pretty close to what the script author intended. However it seems that all of the shell authors have done stuff a little differently than each other so if you've only written and tested on one shell, you might have problems running on any one (or all) of the other shell(s).
The best thing to do is to pick something small which is as close to just POSIX implementation as you can get (ash perhaps?) and write/develop in that shell and then thouroughly test it on things like bash, ksh and other POSIX shells.
I always like to through out the fact that most systems now have perl available on them and in some cases it is probably just as appropriate if not more so to script install stuff in perl.
I have shipped many many packages with many many carriers over the years and I have never lost anything due to damage, other than when I knowingly didn't package something adequately.
Sure I've seen packages which were pretty well beat up, but like others have said, a well-packaged box will pretty much guarantee safe arrival.
The boxes used look like they weren't designed for shipping use. A LOT of boxes won't withstand the crushing which naturally occurs during shipping and will burst. This is what looks like happened. Once the box burst, all bets were off as to how well the contents would arrive.
I usually use the two-box method for heavier items. Pack the heavy item inside a box just slightly bigger than the item, filling the space between the item and the box tightly with newspaper or bubble wrap, etc. Don't use peanuts here.
After you get this box packaged, put it in a larger box with at least 2-4" of peanuts all the away around (and on the bottom and top), packed fairly tightly but not overly so. The goal is to suspend the smaller box inside the bigger one so that any damage which is done to the outside box doesn't end up going through to the inside one.
I've never seen anything packaged this way not arrive intact. On the other hand, I have seen numerous items which the shipper did exactly what the poster did (wrap the piss out of it with bubble wrap and stick it in a big box) arrive damaged. The *WORST* thing to do is to put a heavy object (such as a laser printer) just directly in a big box with peanuts. The thing won't survive, and if it does it will be filled with peanut shreds when it arrives.
If anything, the addition of this statement adds credibility to the referenced page - as they knew enough when they wrote it to know that this was necessary.
What they are really saying is that there are large chunks of the internet which can't talk to each other. This isn't because of firewalling or "hiding" behind a NAT box or the like, but is instead a result of the peering "politics" (which better describes what goes on than policies) between carriers.
Let me explain. If I am ISP A and I connect via peering to ISP B, I can't talk to ISP C's customers through B even if ISP B and C are connected. That is, unless I have an arrangement with ISP B to provide transit to ISP C. ISP C also has to agree to accept my routes even if ISP B provides transit to me.
Generally the big "Tier 1" ISP's peer with each other and generally don't exchange or buy transit from each other (except in some limited cases). Smaller ISP's generally buy transit from one or more Tier 1 ISP's. Some of the smaller Tier 1's both peer and buy transit.
It is not altogether unexpected that with hundreds of ISP's out there that certain ISP pairs just plain do not have connectivity between them. It would be almost impossible both economically, politically, and technically to insure that each ISP could talk to every other ISP out there.
Add on to that that there are some ISP's who set arbitrary limits on how many addresses you have to announce together in one chunk (prefix) before they will even listen to them. If you have a small ISP with insufficiently sized address blocks you may find that your connectivity to the internet suffers.
The other piece which WAS said fairly well is that most people don't notice the problem as 99% of the people out there don't use more than the most popular 1% of the internet. And THOSE sites are almost 100% connected (and if you ran an ISP which wasn't connected to the big sites, you would quickly find yourself without a customer base).
Note that I've taken some liberties with this description so there is some minor technical/political breakage in the description above. Or probably better put, this isn't meant as a technical reference piece on peering policies....
Obviously CmdrTaco and the crew have figured out that VA isn't where *THEY* want to work any more and are trying to figure out where to go next.
It's the only explanation that fits...
Now, on a directly related topic, I wouldn't trust anyone at WorldCom/UUNET/ALTER.NET to run *ANY* of my business traffic. Every time I have a problem getting somewhere it inevitably ends up being a problem on the ALTER.NET backbone, and if they treat their employees like their employees treat people who call their NOC *I* sure wouldn't want to work for them.
OSPF isn't much harder to configure than RIPv2 and solves a lot of the RIP-type problems that v2 didn't such as count-to-infinity loops and slow convergence.
As others have already mentioned Zebra and GateD, I won't be redundant and give you a URL. Both of these do OSPF in addition to RIPv2.
Most of the dial equipment in place is near it's end of life. Lots of smaller ISP's use PM3's which won't have a v.92 upgrade available. Not sure about the PM4's. Upgrading these units to v.92 would cost the ISP thousands of dollars with very little hope of ever seeing any return on investment.
In addition, the Ascend (lucent) MAX gear and the 3com/USR Total Control units aren't upgradeable unless the ISP carries a service contract on the gear. A LOT of ISP's have dropped the service contracts on their dialup equipment as the existing software is stable, the phone support sucks (most ISP techs know more about the equipment than the manufacturer techs do), and it is a lot cheaper just to buy used spares for everything, thus minimizing downtime by being able to keep a hot spare on the shelf.
Again, the added cost of adding maintenance to permit the addition of V.92 support to their dial pool has very little real liklihood of return on investment.
I'd say don't worry about the v.92 stuff, and just get a robust hardware-based v.90 modem.
I've been doing wireless ISP stuff for quite a while so I know what you're talking about.
Here's the key points:
5.xGHz is EXPENSIVE. I can't in good faith recommend it for ISP to customer links, except for those customers who need to have solid, VERY high speed links. Use 5.x GHz for your backbone between pops.
5.xGHz tends to be ROCK SOLID. There are actually two chunks of bandwidth up there which are useful this. I personally have used the UNII band stuff which is below 5.8 (three bands - the highest at 5.7GHz), and I can't say I've been really interfered with. This is in a community where 2.4GHz in parts of town is completely saturated.
So if you want expensive but rock solid use the 5.8 GHz stuff.
What we tend to do is use the 5.8GHz for Backhaul from our repeater "cell" sites and use the 2.4GHz for our "last mile". Keeping the cell cites small and using polarization, channels, and sectoral antennas to your advantage is the key.
If you pull up a Lucent/Avaya/ORiNOCO wavelan card control panel under windows, you will find there's a "Microwave Oven Robustness" setting which is designed to help make these work in the presence of a microwave oven.
The real limitation is that you must have an IPSec capable image on your router. Not usually a big deal.
I type around 90 WPM if I'm on the Model E. Anything Else, I'm lucky to get 50. The other's just don't give you the necessary feedback when the key is down for your brain to realize it is ok to push the next key.
Also important is the fact that some of the really really cheap newer keyboards have problems where the keys all don't trigger at the same point in their downward stroke. Since I type fast enough that I actually (subconciously, mind you) "overlap" my keystrokes - that is one key is actually going down milliseconds behind the next one - I have seen some really bad keyboards this way that will actually reorder my keystrokes because even though I pushed key B after key A, key B shows up first. Needless to say, this causes some inaccuracies.
True it is always better to use the energy without conversion. But even 50% energy loss is better than the 100% energy loss if you aren't able to use the "free energy source".
There is a quote in there from the bad guys that the "Humans and the Vulcans weren't supposed to be involved yet". Perhaps this is *exactly* the story arc that is being used... We just don't know it yet.
I've seen MANY MANY MANY shipped computers which had the heatsink not on the processor when it arrived at the destination. Having the processor be able to destroy itself when you loose a heatsink is just bad karma...
Not to mention that the processor obviously gets hot enough to catch something on fire if it happened to be in the wrong spot in the case.
Product liability lawsuit anyone? This makes me want to reconsider my AMD is better than intel position.
I'd recommend you take a good look at FreeBSD. Hop over to http://www.freebsd.org/ and take a look around. In most cases, all you need to get going is a couple of floppy disks and the instructions found here. The installation disks will automagically download the entire distribution via the net.
I don't want to start a FreeBSD vs. Linux war, but if you're looking for a server replacement, FreeBSD is a great choice. If you are wanting to use it on your desktop as a workstation, then perhaps Linux is the better choice, although I still wouldn't discount FreeBSD 100%.
If it's patented, then you can't reproduce it without paying whatever royalties the patent owner wants, period.
As much as I feel that things that are obvious should not be patented, Even I agree that something so difficult to do should be afforded patent protection.
Also, read the tone of the letter. It's "please remove this and let's talk about what options we have, but if you don't we'll have to pursue legal means" as opposed to the "appear in court on this date" method which the people who don't have what I consider "patentable" technology tend to employ.
I think he forgot to close his sarcasm tag in his previous post.....
Forget asking them about ls and rm and tcpdump, etc., but instead show them the equipment room, talk about what you are doing, etc..
A true tech "geek" will almost immediately forget he's on an interview and start asking questions like "You're whole building is wired with fiber?", Or "What OS are you running on these?", etc., etc., etc.. Sharing war stories also seems to bring out the best in geeks.
You will find out very quickly whether the person knows anything or not, and their relative clue level, although you do have to give some leeway for the occasional stupid question/comment. You can also insert a few leading questions in the discussion. "Oh yeah, we just got done installing those switches last week. Have you played with that brand yet?"
You also will probably be able to tell how much a person really wants to be involved in your company by how they respond during the "show and tell".
The last person we hired was basically interviewed this way. She obviously knew the questions to ask, could deal with our kind of always-hectic environment (darn users anyways), and her eyes lit up when she saw our equipment room. We hired her and we haven't regretted it for a microsecond since.
--
Although I would highly recommend most of these, there are also a few non-reference books which I think people should consider:
Fire in the Valley" Paul Freiberger, Michael Swaine - Basically the story of the early days of the personal computer. Talks about early days at Apple, Microsoft, etc. etc.
The Soul of a New Machine Tracy Kidder - The story of a team of engineers at Data General who built a 32 bit minicomputer in one year.
The Cuckoo's Egg Clifford Stoll - The story of how Stoll tracks a cracker through the maze of the phone system.
Takedown - Tsutomu Shimomura - The story of the pursuit and capture of Mitnick. This is a good read. There's also one that I haven't read which tells Mitnick's story - perhaps someone else can point us toward that one.
There is another I've read which talks about the Steve Jackson Games incident - and a lot of the other Secret Service activities in that era. Again, I can't provide a reference.
--
Battery life was wonderful. AA's that worked seemingly forever, although we got in the habit of cycling NiCD's through it. It survived the environment we used it in which was a oily, dirty, industrial sawmill. Never complained, and worked like a champ.
--
My typing has been around 60-90 wpm since about that time, depending on keyboard, what I am typing, etc. etc.
90 wpm = 450 cpm = 7.5 cps.
300bps = 30cps. (8 data, no parity, one start, one stop bit= 10 bits/byte).
I can't remember ever overtyping the modem.
What I can remember is that I definately could *read* faster than 30cps. Especially painful was when something started spewing a file to you which was way too big.
I can ALSO remember downloading 20kbyte programs and waiting 10 mins. A 100k program was almost an hour.
I also remember typing faster than either the net (meaning GTE Telenet/Tymnet) plus the host (The Vaxen (If I recall correctly) which were The Source) could handle, so you could get ahead.
As far as a 300bps not performing near it's theoretical throughput, I would have to say that that statement is technically incorrect. A 300bps modem would ALWAYS work at exactly 300bps. Now, occasionally you'd get line noise, and it would show up at exactly 300bps.
Remeber 300bps modems didn't have error correction or compression or anything like that. Basically they listened for two tones on the line. If there was a blast of noise which contained either or both tones, you'd get crap. Usually {'s and other similar characters.
Generally, if you couldn't use a line, you'd just redial. OR filter it, etc. etc. etc.
I remember when The Source offered a 2400bps modem paid for over several monthly bills. I could not pass it up. I was in *HEAVEN* at 2400bps.
The only problem was that I had to write my own interrupt driven modem software for my Epson PX-8 Laptop, as the builtin stuff would loose characters at 2400bps.
--
However, the problem I'm running into is finding a PCI-based Non-Winmodem which does voice. I have a similar application I need to find one for. Everyone recommends the Zyxel modems, but they don't currently make an internal model, and as far as I can tell the 1496 was only available in ISA. For my app, this must be internal as it's going in a rack mount environment where we pay per rack inch.
From what I can tell, the vast majority of the PCI Voice modems out there are WinModems. I happen to be a FreeBSD user, so of course I need a real "hardware modem".
Maybe one of the other readers can shed some light on this....
--
You don't necessarily need your direct upstream provider to do multicast natively. If you can find a provider willing to provide you a tunnel then you just need an appropriate piece of hardware/software to become your end of the tunnel. Linux and FreeBSD boxes work great for this, along with most "real" cisco routers.
Start with your upstream and ask them two things. 1) If they will provide you with a tunnel and 2) If not, who are their providers so you can get a tunnel from one of them. Generally, the multicast people are fairly open to providing tunnels to people who are even indirectly connected to them, although YMMV.
Look around a bit with some Google searches and you should be able to find someone who will give you a tunnel.
--
--